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 <thread> > 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: <message from='A/res' to='B'> <body>hi!</body> </message> <message from='B/res' to='A/res' type='chat'> <body>hi back!</body> </message> <message from='A/res' to='B/res' type='chat'> <body>wow, a chat session!</body> </message> <message from='B/res' to='A/res' type='chat'> <body>yeah, but I gotta run!</body> </message> <message from='A/res' to='B/res' type='chat'> <body>OK, bye!</body> </message> However, I would recommend the following kind of flow, with sharing of directed presence: <message from='A/res' to='B'> <body>hi!</body> </message> <message from='B/res' to='A/res' type='chat'> <body>hi back!</body> </message> [ ... some optional client prompt for presence sharing here ... ] <presence from='B/res' to='A/res'/> <presence from='A/res' to='B/res'/> <message from='A/res' to='B/res' type='chat'> <body>wow, a chat session!</body> </message> <message from='B/res' to='A/res' type='chat'> <body>yeah, but I gotta run!</body> </message> <message from='A/res' to='B/res' type='chat'> <body>OK, bye!</body> </message> <presence from='B/res' to='A/res' type='unavailable'/> <presence from='A/res' to='B/res' type='unavailable'/> 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 <thread> 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 <thread>, 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 <thread> 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
