I hope I didn’t ask dumb questions... An answer would be appreciated! Thanks.
Christian Am 11.01.2015 um 20:08 schrieb Christian Schudt <[email protected]>: > 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 >
