Re: [Standards] Messages to unsubscribed contacts and resources
Hi Joe, thanks for the reply! On Fri, Dec 14, 2007 at 07:09:26AM -0800, Joe Hildebrand wrote: > > On Dec 12, 2007, at 7:04 AM, Robin Redeker wrote: > >Ok, I have another question: > > > >We have: Contact A with one resource (resource is 'res1'): > > > > [EMAIL PROTECTED]/res1 > > > >And Contact B with two resources: > > > > [EMAIL PROTECTED]/res1 priority 20 > > Assume you mean contact_b. Yes, indeed :) > > > [EMAIL PROTECTED]/res2 priority 10 > > > >They are not subscribed to each other and do NOT share any presence > >information. > > Even directed presence? The cool side effect of sending a directed > presence is that everyone to whom you have sent directed presence will > get an unavail when you go offline. Yes, even directed presence not. I know that directed presence makes things easier in this case, but I assume here that there are still clients and people that don't do or don't want to send the presence. [.snip.] > >Should he make a second 'chat session', which is probably not very > >intuitive for the user because he just wanted to talk to contact B and > >when he got two options to send the message, what should he do (he > >doesn't even know which resource is the 'right' one, or whether 'res1' > >maybe went offline)? > > You're correct that there shouldn't be a new visible session. There > were clients that did that back in the day (or with each new thread!) > and it turned out to be pretty confusing. You should just rebind to > the new resource. Ok, that also makes things easier in the code. > >What if they share presence, should contact A's client determine from > >the highest priority resource where the message should go to? > > Absolutely not. You should just unbind at least when res1 goes > offline, and perhaps whenever you get a presence change from > contact_b. Keep in mind that b's server might be doing much more > sophisticated "most available" calculations. But what if contact B first replied from the resource 1 and also sent a directed presence to contact A, _and_ then changes to resource 2 to talk to contact A, should contact A rebind (I would guess that would make sense)? > Alternate question: What if contact_b's server is using RAP > (XEP-168)? Then contact_a can know what the new most available > resource is? My answer to that is that if the resource contact_a is > bound to was the primary resource, and now isn't, you should unbind, > otherwise not. Well, what in the case I explained in my last paragraph (about contact B, who changes the resource without changing presence settings)? Should contact A still send to the primary resource or still rebind to the last resource he got a message from? Sorry for my complicated and very technical questions, I just want to get it right :) Thanks for your time! Robin -- Robin Redeker | Deliantra, the free code+content MORPG [EMAIL PROTECTED] / [EMAIL PROTECTED] | http://www.deliantra.net http://www.ta-sa.org/ |
Re: [Standards] Messages to unsubscribed contacts and resources
On Dec 12, 2007, at 7:04 AM, Robin Redeker wrote: Ok, I have another question: We have: Contact A with one resource (resource is 'res1'): [EMAIL PROTECTED]/res1 And Contact B with two resources: [EMAIL PROTECTED]/res1 priority 20 Assume you mean contact_b. [EMAIL PROTECTED]/res2 priority 10 They are not subscribed to each other and do NOT share any presence information. Even directed presence? The cool side effect of sending a directed presence is that everyone to whom you have sent directed presence will get an unavail when you go offline. Contact A sends a bare JID message to contact B. Contact B receives the message at res1 (due to highest priority), and answers from that resource. Contact A receives the full JID of that resource now and 'binds' the conversation to it and they chat. Later Contact B switches to his laptop, with another client bound to the other resource 'res2'. And he sends a message to the bare JID (because the client there doesn't know the full JID of contact A) of contact A. How should contact A proceed? Should he bind (and reply) the conversation to res2? Should he make a second 'chat session', which is probably not very intuitive for the user because he just wanted to talk to contact B and when he got two options to send the message, what should he do (he doesn't even know which resource is the 'right' one, or whether 'res1' maybe went offline)? You're correct that there shouldn't be a new visible session. There were clients that did that back in the day (or with each new thread!) and it turned out to be pretty confusing. You should just rebind to the new resource. What if they share presence, should contact A's client determine from the highest priority resource where the message should go to? Absolutely not. You should just unbind at least when res1 goes offline, and perhaps whenever you get a presence change from contact_b. Keep in mind that b's server might be doing much more sophisticated "most available" calculations. Alternate question: What if contact_b's server is using RAP (XEP-168)? Then contact_a can know what the new most available resource is? My answer to that is that if the resource contact_a is bound to was the primary resource, and now isn't, you should unbind, otherwise not. -- Joe Hildebrand
Re: [Standards] Messages to unsubscribed contacts and resources
On Tue, Dec 11, 2007 at 10:28:55AM -0700, Peter Saint-Andre wrote: > Robin Redeker wrote: > > Hi! > > > > Some days ago I had a mail discussion on the jdev@ mailing list > > about messages to unsubscribed contacts and contacts in general. > > Tomasz said that messages should generally go to the bare JID instead of > > the full JID, and that the local routing is up to the server. > > > > He meant, chat sessions should be kept track of with the > > element, which completly makes sense to me. [.snip.] > > Please also note that the term 'chat session' in that paragraph is quite > > undefined, or at least it's meaning is a bit fuzzy to me. > > At its simplest, I think this is a chat session: > [.snip.] > > The sharing of directed presence gives both parties more knowledge about > availability, but I think it should be initiated by the recipient (and > subject to client prompt on a per-session basis, or configuration in the > client to auto-share directed presence). > [.snip.] > > Of course, If I don't have to keep track of the resources, that would > > _greatly_ simplify everything for me. Just sending to the bare JID and > > leaving the rest up to and the contacts routing settings > > would make enormous sense to me. > > Sending every message to the bare JID is not the custom. > > > Back to section 5.1.1, the sections somehow contradicts the section > > 8.3.1.1 (Message): > > > >For a message stanza of type "chat", "error", "groupchat", or > >"normal", the server SHOULD deliver the stanza to the > >highest-priority available resource. > > > > That 'feature' only makes sense if at least the initial message goes to > > a bare JID. But if it is routed to a resource by the server and I have > > no knowledge about the presence of that resource (eg. if I'm not > > subscribed), where should the next message go to, to the full JID I > > received a reply from? > > You should keep sending to the bare JID until you receive a reply from a > full JID, then start sending to the full JID. > Ok, I have another question: We have: Contact A with one resource (resource is 'res1'): [EMAIL PROTECTED]/res1 And Contact B with two resources: [EMAIL PROTECTED]/res1 priority 20 [EMAIL PROTECTED]/res2 priority 10 They are not subscribed to each other and do NOT share any presence information. Contact A sends a bare JID message to contact B. Contact B receives the message at res1 (due to highest priority), and answers from that resource. Contact A receives the full JID of that resource now and 'binds' the conversation to it and they chat. Later Contact B switches to his laptop, with another client bound to the other resource 'res2'. And he sends a message to the bare JID (because the client there doesn't know the full JID of contact A) of contact A. How should contact A proceed? Should he bind (and reply) the conversation to res2? Should he make a second 'chat session', which is probably not very intuitive for the user because he just wanted to talk to contact B and when he got two options to send the message, what should he do (he doesn't even know which resource is the 'right' one, or whether 'res1' maybe went offline)? What if they share presence, should contact A's client determine from the highest priority resource where the message should go to? Robin -- Robin Redeker | Deliantra, the free code+content MORPG [EMAIL PROTECTED] / [EMAIL PROTECTED] | http://www.deliantra.net http://www.ta-sa.org/ |
Re: [Standards] Messages to unsubscribed contacts and resources
On Tue, Dec 11, 2007 at 10:28:55AM -0700, Peter Saint-Andre wrote: > Robin Redeker wrote: > > Hi! > > > > Some days ago I had a mail discussion on the jdev@ mailing list > > about messages to unsubscribed contacts and contacts in general. > > Tomasz said that messages should generally go to the bare JID instead of > > the full JID, and that the local routing is up to the server. > > [.snip.] > > Please also note that the term 'chat session' in that paragraph is quite > > undefined, or at least it's meaning is a bit fuzzy to me. > > At its simplest, I think this is a chat session: > [.interesting examples snipped.] Thanks for the examples, that was what I thought was the other option. > > The sharing of directed presence gives both parties more knowledge about > availability, but I think it should be initiated by the recipient (and > subject to client prompt on a per-session basis, or configuration in the > client to auto-share directed presence). > > > And is somewhere described how full JIDs and play together? If at > > all? > > http://www.xmpp.org/extensions/xep-0201.html Thanks :) > > If routing is up to the local server side, makes it sense to reveal > > resources at all? Wasn't there a progress towards randomized resources? > > http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-04.html#bind-servergen Nice :) [.snip.] > > IMHO, threads are *not* required to have a chat session. Ok. > > But before I can implement anything resembling 'chat sessions' that > > term must be more explictly defined. > > See above for an example. I can easily write a formal definition too. Well, that example was what I imagined what a 'chat session' would be. I don't know how important this is for others, I guess most client developers don't have a problem with this. > > Of course, If I don't have to keep track of the resources, that would > > _greatly_ simplify everything for me. Just sending to the bare JID and > > leaving the rest up to and the contacts routing settings > > would make enormous sense to me. > > Sending every message to the bare JID is not the custom. Ok. > > Back to section 5.1.1, the sections somehow contradicts the section > > 8.3.1.1 (Message): > > > >For a message stanza of type "chat", "error", "groupchat", or > >"normal", the server SHOULD deliver the stanza to the > >highest-priority available resource. > > > > That 'feature' only makes sense if at least the initial message goes to > > a bare JID. But if it is routed to a resource by the server and I have > > no knowledge about the presence of that resource (eg. if I'm not > > subscribed), where should the next message go to, to the full JID I > > received a reply from? > > You should keep sending to the bare JID until you receive a reply from a > full JID, then start sending to the full JID. Ok, that makes much sense with the behaviour described in the URL you posted below. > > > Will my messages, if that contacts resource goes > > offline, be dropped without my knowledge? > > No, they will probably go to offline storage, because of this: > > http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-04.html#rules-fulljid-availnomatch > > I agree that these customary practices are not spelled out very well, so > I will fix that in the next version of rfc3921bis. I guess that would be a nice addition. Thanks! Robin -- Robin Redeker | Deliantra, the free code+content MORPG [EMAIL PROTECTED] / [EMAIL PROTECTED] | http://www.deliantra.net http://www.ta-sa.org/ |
Re: [Standards] Messages to unsubscribed contacts and resources
On Tuesday 11 December 2007 1:08 pm, Tomasz Sterna wrote: > On Wt, 2007-12-11 at 15:59 -0500, Greg Hudson wrote: > > It's not what clients do currently, though. I'm not sure whether it's > > wise to encourage such a fundamental change at this point. > > It's not a change... yet. > There are clients that do one, and others that do the other, by the > authors preference. > > RFC3921bis will be encouraging only one approach. And then it will be > hard to change it. It was decided long ago that replies should go to the full JID. It was even documented in RFC 3921 (see Section 4.1) from 2004. No need to bring the bis into this. This is absolutely fundamental Jabber behavior that has existed for as long as I've been involved (2001?). It's a "SHOULD", so you're probably free to deviate with the understanding that you're deviating. :) -Justin
Re: [Standards] Messages to unsubscribed contacts and resources
I also feel like bare jid sending would have better behavior in the presence of multiple client connections. I don't see why you wouldn't want your existing conversations to follow you when you switch from one device to another. I actually find it annoying beyond words to be logged in from two places at once, holding a conversation on one and then come back to find just half of the conversation sitting on the screen on the other. (AIM, I am looking at you.) It's not what clients do currently, though. I'm not sure whether it's wise to encourage such a fundamental change at this point. Why not just differentiate between type normal and type chat? Right now, most clients do not really differentiate anymore, and just handle everything as chat, so 'normal' is largely unused. Maybe we should have normal be recommended to always be sent to the bare-JID, and the server would deliver as appropriate (to all resources, or to the highest-priority, or whatever). Like e-mail, where you can read it from whatever client. Chat could then continue to use the current logic, which honestly makes more sense to me. -- Rachel Blackman <[EMAIL PROTECTED]> Trillian Messenger - http://www.trillianastra.com/
Re: [Standards] Messages to unsubscribed contacts and resources
On Wt, 2007-12-11 at 15:59 -0500, Greg Hudson wrote: > It's not what clients do currently, though. I'm not sure whether it's > wise to encourage such a fundamental change at this point. It's not a change... yet. There are clients that do one, and others that do the other, by the authors preference. RFC3921bis will be encouraging only one approach. And then it will be hard to change it. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Messages to unsubscribed contacts and resources
I also feel like bare jid sending would have better behavior in the presence of multiple client connections. I don't see why you wouldn't want your existing conversations to follow you when you switch from one device to another. It's not what clients do currently, though. I'm not sure whether it's wise to encourage such a fundamental change at this point. On Tue, 2007-12-11 at 21:22 +0100, Tomasz Sterna wrote: > On Wt, 2007-12-11 at 13:10 -0700, Peter Saint-Andre wrote: > > Because that's what it means to be in a chat session with someone -- > > you have a FullJID-to-FullJID connection, as it were. > > This is kind of "it is like this, because it is like this" answer. > > And as Robin pointed "a chat session" is a very fuzzy "definition". > > I still se no advantage in this approach. > And Robin and I pointed a few advantages of bare JID messaging. > > > > And remember that these messages are not necessarily human-readable > > text. What if you're sending a file via In-Band Bytestreams? Does half > > the file go to one resource and half to another? Ick. > > Is a IBB a "chat session"? Really? > This makes "chat session" definition even more fuzzy... > > > And I have a feeling of deja-vu. > We had this talk before and IIRC concluded that bare JID messaging is > better and is what we should recommend it and discourage the existing > full JID binding. > > Instead, we documented the full JID binding in RFC3921bis and encourage > it even more... :-/ > >
Re: [Standards] Messages to unsubscribed contacts and resources
On Wt, 2007-12-11 at 13:10 -0700, Peter Saint-Andre wrote: > Because that's what it means to be in a chat session with someone -- > you have a FullJID-to-FullJID connection, as it were. This is kind of "it is like this, because it is like this" answer. And as Robin pointed "a chat session" is a very fuzzy "definition". I still se no advantage in this approach. And Robin and I pointed a few advantages of bare JID messaging. > And remember that these messages are not necessarily human-readable > text. What if you're sending a file via In-Band Bytestreams? Does half > the file go to one resource and half to another? Ick. Is a IBB a "chat session"? Really? This makes "chat session" definition even more fuzzy... And I have a feeling of deja-vu. We had this talk before and IIRC concluded that bare JID messaging is better and is what we should recommend it and discourage the existing full JID binding. Instead, we documented the full JID binding in RFC3921bis and encourage it even more... :-/ -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Messages to unsubscribed contacts and resources
Tomasz Sterna wrote: > On Wt, 2007-12-11 at 10:28 -0700, Peter Saint-Andre wrote: >> You should keep sending to the bare JID until you receive a reply from >> a full JID, then start sending to the full JID. > > What is the rationale for this behavior? > I mean, what advantage does it have over sticking to bare JID sending? Because that's what it means to be in a chat session with someone -- you have a FullJID-to-FullJID connection, as it were. And remember that these messages are not necessarily human-readable text. What if you're sending a file via In-Band Bytestreams? Does half the file go to one resource and half to another? Ick. I could write up some scenarios about this if people are really interested. And in any case I'll define it more precisely in the next version of rfc3921bis and then people can have something more stable to comment on. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Messages to unsubscribed contacts and resources
On Wt, 2007-12-11 at 10:28 -0700, Peter Saint-Andre wrote: > You should keep sending to the bare JID until you receive a reply from > a full JID, then start sending to the full JID. What is the rationale for this behavior? I mean, what advantage does it have over sticking to bare JID sending? -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Messages to unsubscribed contacts and resources
Robin Redeker wrote: > Hi! > > Some days ago I had a mail discussion on the jdev@ mailing list > about messages to unsubscribed contacts and contacts in general. > Tomasz said that messages should generally go to the bare JID instead of > the full JID, and that the local routing is up to the server. > > He meant, chat sessions should be kept track of with the > element, which completly makes sense to me. > > On the other side RFC3921bis says: > >Section 5.1.1: > >If the message is being sent in reply to a message previously >received from an address of the form <[EMAIL PROTECTED]/resource> (e.g., >within the context of a chat session), the value of the 'to' address >SHOULD be of the form <[EMAIL PROTECTED]/resource> rather than of the form ><[EMAIL PROTECTED]> unless the sender has knowledge (via presence) that the >intended recipient's resource is no longer available. > > That of course also makes sense, but my problem was: What if the sending > contact does not know about the presence of that resource? When should > he stop sending to [EMAIL PROTECTED]/resource? Should he, if he has no > knowledge about the presence, send to [EMAIL PROTECTED] generally? IMHO it is a best practice for users who do not normally share presence to send directed presence during a chat session. > Please also note that the term 'chat session' in that paragraph is quite > undefined, or at least it's meaning is a bit fuzzy to me. At its simplest, I think this is a chat session: hi! hi back! wow, a chat session! yeah, but I gotta run! OK, bye! However, I would recommend the following kind of flow, with sharing of directed presence: hi! hi back! [ ... some optional client prompt for presence sharing here ... ] wow, a chat session! yeah, but I gotta run! OK, bye! The sharing of directed presence gives both parties more knowledge about availability, but I think it should be initiated by the recipient (and subject to client prompt on a per-session basis, or configuration in the client to auto-share directed presence). > And is somewhere described how full JIDs and play together? If at > all? http://www.xmpp.org/extensions/xep-0201.html > If routing is up to the local server side, makes it sense to reveal > resources at all? Wasn't there a progress towards randomized resources? http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-04.html#bind-servergen > Sorry for so many questions, but I'm a little bit confused. I try to get > the conversation aspect in my client right, and one problem I stumbled > accross was the fact that my client has no 'windows' or 'tabs' which > could control the extend of a 'chat session'. In my client there is > always a 'tab' to a contact, and the extends of a 'chat session' are > very fuzzy and undefined. > If the term 'chat session' in XMPP means I have to keep track of the > session via some special hacks with resources and , I would have > to complicate the whole thing a bit. That is of course maybe only an issue > with my special client. IMHO, threads are *not* required to have a chat session. > But before I can implement anything resembling 'chat sessions' that > term must be more explictly defined. See above for an example. I can easily write a formal definition too. > Of course, If I don't have to keep track of the resources, that would > _greatly_ simplify everything for me. Just sending to the bare JID and > leaving the rest up to and the contacts routing settings > would make enormous sense to me. Sending every message to the bare JID is not the custom. > Back to section 5.1.1, the sections somehow contradicts the section > 8.3.1.1 (Message): > >For a message stanza of type "chat", "error", "groupchat", or >"normal", the server SHOULD deliver the stanza to the >highest-priority available resource. > > That 'feature' only makes sense if at least the initial message goes to > a bare JID. But if it is routed to a resource by the server and I have > no knowledge about the presence of that resource (eg. if I'm not > subscribed), where should the next message go to, to the full JID I > received a reply from? You should keep sending to the bare JID until you receive a reply from a full JID, then start sending to the full JID. > Will my messages, if that contacts resource goes > offline, be dropped without my knowledge? No, they will probably go to offline storage, because of this: http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-04.html#rules-fulljid-availnomatch I agree that these customary practices are not spelled out very well, so I will fix that in the next version of rfc3921bis. Thanks for the questions! Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] Messages to unsubscribed contacts and resources
Hi! Some days ago I had a mail discussion on the jdev@ mailing list about messages to unsubscribed contacts and contacts in general. Tomasz said that messages should generally go to the bare JID instead of the full JID, and that the local routing is up to the server. He meant, chat sessions should be kept track of with the element, which completly makes sense to me. On the other side RFC3921bis says: Section 5.1.1: If the message is being sent in reply to a message previously received from an address of the form <[EMAIL PROTECTED]/resource> (e.g., within the context of a chat session), the value of the 'to' address SHOULD be of the form <[EMAIL PROTECTED]/resource> rather than of the form <[EMAIL PROTECTED]> unless the sender has knowledge (via presence) that the intended recipient's resource is no longer available. That of course also makes sense, but my problem was: What if the sending contact does not know about the presence of that resource? When should he stop sending to [EMAIL PROTECTED]/resource? Should he, if he has no knowledge about the presence, send to [EMAIL PROTECTED] generally? Please also note that the term 'chat session' in that paragraph is quite undefined, or at least it's meaning is a bit fuzzy to me. And is somewhere described how full JIDs and play together? If at all? If routing is up to the local server side, makes it sense to reveal resources at all? Wasn't there a progress towards randomized resources? Sorry for so many questions, but I'm a little bit confused. I try to get the conversation aspect in my client right, and one problem I stumbled accross was the fact that my client has no 'windows' or 'tabs' which could control the extend of a 'chat session'. In my client there is always a 'tab' to a contact, and the extends of a 'chat session' are very fuzzy and undefined. If the term 'chat session' in XMPP means I have to keep track of the session via some special hacks with resources and , I would have to complicate the whole thing a bit. That is of course maybe only an issue with my special client. But before I can implement anything resembling 'chat sessions' that term must be more explictly defined. Of course, If I don't have to keep track of the resources, that would _greatly_ simplify everything for me. Just sending to the bare JID and leaving the rest up to and the contacts routing settings would make enormous sense to me. Back to section 5.1.1, the sections somehow contradicts the section 8.3.1.1 (Message): For a message stanza of type "chat", "error", "groupchat", or "normal", the server SHOULD deliver the stanza to the highest-priority available resource. That 'feature' only makes sense if at least the initial message goes to a bare JID. But if it is routed to a resource by the server and I have no knowledge about the presence of that resource (eg. if I'm not subscribed), where should the next message go to, to the full JID I received a reply from? Will my messages, if that contacts resource goes offline, be dropped without my knowledge? Thanks for your time :) Robin -- Robin Redeker | Deliantra, the free code+content MORPG [EMAIL PROTECTED] / [EMAIL PROTECTED] | http://www.deliantra.net http://www.ta-sa.org/ |
