[Standards] UPDATED: XEP-0201 (Best Practices for Message Threads)
stpeter at stpeter.im
Wed Feb 6 23:23:06 UTC 2008
Jérôme Carretero wrote:
> On Thu, 30 Aug 2007 21:36:05 -0500 (CDT) XMPP Extensions Editor
> <editor at xmpp.org> wrote:
>> Version 0.4 of XEP-0201 (Best Practices for Message Threads) has
>> been released. [...] URL:
> Hi all,
Hi CJ, thanks for posting. :)
> I have a suggestion concerning message threading.
> My point is to enable tree-based jabber clients for MUC. This would
> require a simple way to make nodes containing the messages of a
> thread. See  for an example ...
> In order to do that, first, I thought about thread ids with a
> variable length (like origin-subthread-subthread-...) but that's
> definitely not good.
> But extending XEP-0201 with an element can work. I'll talk about that
> in a few lines.
> The XEP-0201 talks about using UUIDs for thread identification ; I
> think it should be wise to precise that it's time-based UUIDs.
> Time-based UUIDs can be sorted by date.
Do you mean something like UtcDateTime.UUID for the ThreadID?
> I don't think that giving
> one's MAC address can be a security threat on the internet, but some
> people here are looking at potential breaches so I mention it.
Using the Internet is a security threat. ;-)
> 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
That's a good point.
> Clients who don't care would ignore the "parent"
> attribute and use "classical" (just like e-mail) threading and lose
> some information.
Yes, that makes sense.
> Links :  pseudo-screenshot of an imaginary "tree" client :
> http://cj.is-a-geek.org/XEP-0201.png * uuid rfc :
> http://tools.ietf.org/html/rfc4122#section-4.2.2 * uuidgen manual :
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.
(Speaking of the bis drafts, we might want to have the XMPP Council
formally review them before we send them to the IESG for approval, as
well as seek a "last call" on this list. I'll think about how we want to
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards