[Standards-JIG] XEP-0136 Thoughts and Musings

Robert B Quattlebaum, Jr. darco at deepdarc.com
Thu Nov 9 02:17:05 UTC 2006

On Nov 8, 2006, at 4:32 PM, Ian Paterson wrote:

> Chris Mullins wrote:
>> Section 5.2 forbids logging Message Thread Identifiers. It seems  
>> like these would be very natural ways of grouping messages, and  
>> tagging with metadata. Many clients use these today. Why are they  
>> forbidden?
> They are forbidden to prevent redundant data - since every stanza  
> in the collection would (necessarily) have identical thread  
> elements. The 'with' and 'start' attributes already uniquely  
> identify the conversation. I suppose we could add an optional new  
> 'thread' attribute to the <store/> element (in addition to the  
> existing 'subject', 'with' and 'start' attributes). But I'm not  
> absolutely sure that is necessary...
> RFC 3921(bis) rightly makes it very clear that thread elements must  
> not contain any discernable information other than a unique opaque  
> identifier. So do we need to keep the thread if we already have  
> 'with' and 'start'?
> Perhaps there are going to be examples where it is necessary either  
> to correlate XEP-0136 archives with thread-based message collection  
> stores, or to correlate two independently compiled XEP-0136  
> archives that have recorded slightly different 'start' values. But  
> can we imagine *real-life* use cases?

It is entirely conceivable that between two users there are multiple  
"threads" in progress. Say, for example, a chess game, a whiteboard,  
and a conversation. Or multiple whiteboards. Heck if someone's brain  
was able to wrap their head around it, a two users could have two (or  
more) chat threads on different subjects concurrently.

As long as the logging system can handle these cases and ensure that  
messages with the same thread are somehow grouped together, even when  
there is more than one thread between two JID's concurrently, then I  
don't really care if the specific value of the <thread> element is  

HOWEVER... Tossing out the <thread> element will allow for a covert  
communication channel between JID's that will never be logged, which  
can be bad. If you are trying to set up a logging system in a  
corporate environment for accountability purposes, it could be easily  
circumvented by putting the data payload in the thread element. This  
would be, of course, entirely against spec—but we are talking about a  
*naughty* person.

Robert Quattlebaum
Jabber: darco at deepdarc.com
eMail:  darco at deepdarc.com
www:    http://www.deepdarc.com/

More information about the Standards mailing list