[Council] Message threads

[Kevin Smith]

As promised, here is some nonsense which could be used to pad out the  
Message Threads XEP, flames apppreciated:

Motivation:
+ * Allow clients to distinguish between different conversation  
threads when presenting a user's message and chat histories,  
providing a more coherent user interface (e.g. by collapsing threads  
to a single history entry).

Semantics:
I think there should be no emphasis placed on chat threads over  
message threads, so I'd quite like to see this changed to something  
like:

The primary use of the XMPP <thread/> element is to uniquely identify  
a conversation thread or "chat session" between two entities  
instantiated by <message/> stanzas of type 'chat' or 'normal'.  
However, the XMPP <thread/> element may also be used to uniquely  
identify an analogous thread between two entities instantiated by  
<message/> stanzas of type 'headline', or among multiple entities in  
the context of a multi-user chat room instantiated by <message/>  
stanzas of type 'groupchat'. It can also be used for <message/>  
stanzas not related to a conversation, such as a game session or  
between plugins.

Uniqueness:
I support the long-term uniqueness, as I want threads to be  
indefinitely lifetimed too. It creates a slightly strange situation  
though - "For messages of type 'groupchat', the value of the <thread/ 
 > element MUST be unique in the context of the multi-user chat room,  
as long as the room remains in existence" - how does a client that's  
just joined the chat know that a thread hasn't previously been used?  
This is also true between single entities, as they may be using  
different clients. For MUC, it is (later) said that there could be a  
method to ask for a unique thread, but that it's out of scope - we  
should probably give a reference to some place that it's in scope if  
we can.

Handling:
Again, here I'd quite like to see it changed for equal emphasis on  
non-chat messages, plus I've changed the handling related to the user  
interface:
---
In the context of <message/> stanzas of type 'chat' exchanged between  
two entities, the value of the <thread/> element shall be considered  
equivalent to a unique identifier for the chat session or  
conversation thread. If an entity receives such a message with a new  
or unknown ThreadID, it SHOULD treat the message as part of a session  
with unnegotiated parameters (i.e., as equivalent to the first  
message in a chat session that has been negotiated via XEP-0155 with  
no parameters specified). An entity SHOULD destroy the thread when it  
sends or receives a XEP-0155 "terminate" action and MAY destroy the  
thread when it goes offline. Within a user interface, a client MAY  
start a new thread (destroying the old) if the user opens a new chat  
window to a contact having closed the old, but SHOULD resume the  
previous thread if receiving a 'chat' <message/> stanza with a  
previously used <thread/> element, even when the user has closed a  
chat window in the interim.

When sending a <message/> stanza of type 'normal', the value of the  
<thread/> element is used to uniquely identify a conversation thread  
which may not be progressing in real-time. A <message/> stanza of  
type 'normal' SHOULD always use a new <thread/> element identifier  
unless it is written in direct reply to another <message/> stanza, in  
which case the <thread/> element of the original <message/> should be  
used. Determining what constitutes a <message/> stanza written in  
reply to another is a matter left to individual implementation, but  
it is envisaged that in most cases it would be the result of, e.g.,  
the user clicking a 'reply' button when reading the contents of the  
previous stanza.

To ensure the uniqueness of ThreadIDs in the context of a multi-user  
chat room, the multi-use chat service MAY provide a way for room  
occupants to request a unique ThreadID; definition of such methods is  
out of scope for this specification.

There are no special handling requirements related to threads in the  
context of sending <message/> stanzas of type 'headline'.

When displaying historical conversations within the user interface, a  
client SHOULD provide a visual indication of thread membership of  
messages. Methods for such indications include (non-exhaustively) the  
grouping of all messages within a thread together, providing an index  
of threads, or formatting all messages within a thread in a cohesive  
manner, e.g. with a uniform coloring.
---

Inclusion:
I'd like normal to be changed to RECOMMENDED if people don't  
vehemently object.


The next time I do this, I'm not going to attempt to do it within a  
mail - I hope what is above is at least vaguely understandable - what  
do the authors think?

Best,
/K

-- 
Kevin Smith
Psi XMPP client project leader - http://psi-im.org