[Standards] thread destruction
stpeter at stpeter.im
Tue Jul 15 07:28:10 CDT 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
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
So my conclusion is that further thought is required. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20080715/3c79cebf/attachment-0001.bin
More information about the Standards