Thanks for your answer! I’ve had a lengthy discussion with another developer about „one-to-one chat sessions“ in general and we are having difficulties to understand what is really meant by this term.
We’ve read the following documents/paragraphs which involve „chat sessions“: http://xmpp.org/rfcs/rfc6121.html#message-chat http://xmpp.org/extensions/xep-0201.html http://xmpp.org/extensions/xep-0085.html http://xmpp.org/extensions/xep-0296.html Questions that occurred are: 1. Are chat sessions considered between two users/contacts or between two clients/resources? As I have understood the above documents, chat sessions are always between contacts, i.e. chat sessions are tracked on the bare JID of a user and can be locked/unlocked to a specific resource. My discussion partner understood that chat sessions are per resource, i.e. are tracked on full JIDs. (but in this case resource locking would be meaningless). XEP-201 expands on these rules and basically says, chat sessions are tracked on <thread/> AND bare JID, doesn’t it?! 2. What is the scope of a chat session? XEP-0085 says, upon receiving <gone/> chat state, a new <thread/> should be started, which means for me terminating the existing session and start a new one (by the means of XEP-0201). On the other hand XEP-0296 says, it should merely be unlocked (in which case the same thread would still be used). 3. What if one client uses <thread/>, but another doesn’t? Let’s say Juliet writes a chat message without thread to Romeo, who would then create a new thread („abc“) and use it in its replies (as per XEP-201). Therefore Romeo would associate thread-less messages received from Juliet with the thread „abc“. Now Juliet switches her client and sends further chat messages from another device, which also do not include a thread id. Should Romeo now create a new <thread/> or should it re-use the existing thread „abc“ for its replies to the new resource? This is similar to question 1, tracking per bare or full JID. Tracking per full JID would invalidate the „resource locking“ concept in my opinion, but nonetheless it wasn’t clear during our discussion, so we decided to ask the XSF. — Christian Am 05.01.2015 um 23:12 schrieb Lance Stout <[email protected]>: > It makes sense to me, given that XEP-0085's rules are overriding the general > guidelines in XEP-0201. > > > I think the confusing part between the two XEPs is that they use the same > example action in two different contexts. > > > In XEP-0201, closing a chat window exemplifies merely disengaging from the > chat session. In XEP-0085, closing a chat window exemplifies terminating a > chat session. > > Similar but different semantics. > > > > > > Unfortunately, most clients treat closing a chat window as terminating the > chat session, but that doesn't have to always be the case. > > > Consider an app that works like Apple Messages does, which lists all of your > recent conversations in a side bar alongside the main chat window, but can > also pop open individual chats inside their own windows. > > Closing an individual chat session window in this case would be disengaging > from a chat session, but the session is still alive (and listed in the > conversations sidebar). Triggering a gone event would not be appropriate here. > > However, clicking the X to remove a conversation from the sidebar would be > terminating the chat session, and trigger a gone event. Starting a new > conversation with the same person (or the other person sending messages) > should start a new thread. > > > > Of course, the recipient might never have received the gone, because they > were offline at the time and the message was dropped. So if they wanted to > continue sending a message in the same conversation, it would have the old > thread id because it doesn't know otherwise. I would say there is an implicit > business rule that maybe should be made explicit, which is that a client > should handle receiving a message from a thread that it has tried to > terminate; the chat session isn't truly "terminated" until the other side > starts using a new thread id or the client starts using a new thread id > itself. > > > — Lance
