[Standards] thread destruction

Peter Saint-Andre stpeter at stpeter.im
Tue Jul 15 12:28:10 UTC 2008

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 

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. :)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080715/3c79cebf/attachment.bin>

More information about the Standards mailing list