[Standards] UPDATED: XEP-0201 (Best Practices for Message Threads)

Peter Saint-Andre stpeter at stpeter.im
Thu Feb 7 00:24:44 UTC 2008


Peter Saint-Andre wrote:
> Jérôme Carretero wrote:

>> I also think that relying on a thread hierarchy (ie. using a <thread
>> parent="parent.UUID">UUID</thread> than using only the "in reply to"
>> field is semantically more correct, in the sense that when you reply
>> to a message, you could either be in the same topic (same thread +
>> in-reply-to), or deliberately derivate (new thread plus parent
>> information). 

<snip/>

> So you recommend adding a 'parent' attribute to the <thread> element in
> rfc3921bis, correct? I think that change would be backwards-compatible,
> we just need to make sure that it is clearly specified.

I looked a bit more into email and netnews threading (that's what we're
trying to emulate, right?). Those systems tend to use the "References"
header defined in RFC 1036. However, the References header contains a
list of references, which are the parent, grandparent, great-grandparent
(etc.) of the message. Would that be useful to us at all, or do we
really care only about the parent (because once we know the parent we
can trace the grandparent etc. if necessary)? In the IM context
(specifically the MUC context), I think it is enough to know the parent,
since it is highly unlikely that intermediate messages would be deleted
(as they are in email) and we are referring to threads, not messages.

Next I will investigate what changes need to be made to XEP-0201 and
rfc3921bis to accommodate this functionality...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080206/7523f7ef/attachment.bin>


More information about the Standards mailing list