[Standards-JIG] XEP-0136 Thoughts and Musings

Ian Paterson ian.paterson at clientside.co.uk
Thu Nov 9 00:32:20 UTC 2006

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 depends on XEP-0189 (Public Key Publishing). This XEP needs to be 
> moved along to Draft.

Good point. See my post about PEP earlier today.

> Collections seem insufficient for given heavy IM usage over a long 
> period of time. A Mechanism to tag collections with keywords and 
> metadata seems needed. The <note/> mechanism that’s there seems 
> insufficient. An automated mechanism for having the server create 
> collections based on conversations, and dates seems like it would be good.

I'm assuming that by "An automated mechanism for having the server 
create collections" you meant telling the server when you want 
conversations to start/end. If so then isn't <thread/> sufficient?

> Being able to add tasks and other items into these collections, such 
> as “Task Item”, “Important!” or “Follow up on 11/29/2006” would be 
> nice. I don’t want to spec all these now, but having a mechanism for 
> adding them later is needed.

I like that idea. Since you want this to be extensible, would it be 
sufficient to (simply) define a protocol that allows a single x:data 
form (with the 'urn:xmpp:archive' FORM_TYPE field) to be uploaded to a 
collection (and subsequently edited and removed)?

Do we need a general building-block XEP that specifies how to do that 
for any protocol?

> Conversations that migrate from 1:1 to MUC don't seem to be addressed.

Yes this would be nice to have too. We could define a new child element 
of a collection that links one (1:1) collection to another (groupchat) 
collection. (I now understand that you mean the user's XEP-0136 record 
of the groupchat while he/she was in the room, not the MUC room's 
history of the room.)

- Ian

More information about the Standards mailing list