[Standards-JIG] XEP-0136 Thoughts and Musings
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'
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.)
More information about the Standards