[Standards-JIG] XEP-0136 Thoughts and Musings

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Thu Nov 9 08:37:46 UTC 2006


Ian, in order to avoid the redundancy you mention, we may be better off
having the thread as an attribute of the collection. Unless you have the
possibility to store several "thread" in one collection. 

>From experience (but you are free to not believe me ;), correlation of
archives with thread-based message collection are more common than you think
in real life. They occur constantly at service providers and in enterprise.
And the problem is exactly what you suspect: un-synchronized 'start' values.

You may also want to check with people familiar with real time data
acquisition, and they will explain that a unique identifier is the only way
to correlate time based data series issued by different sub systems. 
And in real life, batch processing of time based logs coming form different
sources are very common.

I agree with you that "with" and "start" look sufficient from a pure
"normal" form stand point, but other commercial servers developers would
certainly agree it is not so in reality.

Jean-Louis

-----Original Message-----
Date: Thu, 09 Nov 2006 00:32:20 +0000
From: Ian Paterson <ian.paterson at clientside.co.uk>
Subject: Re: [Standards-JIG] XEP-0136 Thoughts and Musings
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <45527714.10902 at clientside.co.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed

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 thats 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 dont 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