Peter Saint-Andre wrote:
Someone pointed out to me the following discrepancy between XEP-0085 and XEP-0201...XEP-0085 says: Upon receiving a <gone/> event, a client MUST NOT re-use the same Thread ID and MUST generate a new Thread ID for any subsequent chat messages sent to the conversation partner.
BTW the <gone/> state is defined as follows: ***User has not interacted with the chat interface, system, or device for a relatively long period of time (e.g., 2 minutes), or has terminated the chat interface (e.g., by closing the chat window).
***
XEP-0201 says: An entity ... SHOULD NOT destroy the thread if a human user merely disengages from the chat session (e.g., by closing a window in a client interface). Clearly these two recommendations are in conflict, so we need to reconcile them. I'm not yet sure which way I lean. Feedback is welcome.
Seeing no feedback, I'll weigh in. :)XEP-0085 defines the protocol for chat state notifications. When we defined that protocol, it made sense to say that a thread is tied to a chat interface because the protocol is all about whether the person you're chatting with in a one-to-one chat session is paying attention to the chat interface. (Yes, XEP-0085 makes a passing mention of chat state notifications in groupchat rooms, but the focus is on one-to-one chat sessions.)
XEP-0201 talks about threads in general, not threads in relation to chat interfaces or one-to-one chat sessions. In particular, one of the ideas behind XEP-0201 is that a thread might last across XMPP sessions, and certainly that a conversation can continue after a chat interface has been destroyed. [IIRC, we started to work on XEP-0201 after we realized that the concept of a "conversation" was not clear in XEP-0136 (Message Archiving) and XEP-0155 (Stanza Session Negotiation).]
Another input is the concept of a "chat session" from rfc3921bis. There I defined a chat session as a somewhat large number of messages sent within a relatively brief period of time -- a kind of conversational burst, if you will.
Now, I realize that all these ideas are somewhat vague, but that's because we can't neatly demarcate a chat session as (say) more than 10 messages exchanged in less than 5 minutes. We all engage in chat sessions every day, and we know them when we're in them, but there is no hard-and-fast definition of a chat session. Furthermore, if we map (say) newsgroup or web forum messages to XMPP messages of type "normal" then clearly threads can last across XMPP sessions. And that's not even to mention threads in groupchat rooms, where you might have more than one conversation thread happening at once.
Clearly, threads can mean different things in the context of different message types, and if we're going to define thread handling we need to think about what threads mean for messages of type "chat", "groupchat", "normal", and even "headline". However, even in the context of "chat" messages I think the rule "MUST destroy the thread when you receive a <gone/> event" in XEP-0085 is too strong. Unfortunately, the rule "SHOULD NOT destroy the thread if the other party disengages from the chat interface" in XEP-0201 is merely negative and doesn't provide any positive guidance to client developers about when to generate a new thread ID.
So my conclusion is that further thought is required. :) /psa
smime.p7s
Description: S/MIME Cryptographic Signature
