[Standards] UPDATED: XEP-0201 (Best Practices for Message Threads)
stpeter at stpeter.im
Fri Feb 8 22:34:07 UTC 2008
Jérôme Carretero wrote:
> On Thu, 07 Feb 2008 08:45:07 -0700 Peter Saint-Andre
> <stpeter at stpeter.im> wrote:
>> What do you mean by "time-based UUID"? Could you show us an example
>> or provide a reference to a specification?
> Time-based UUIDs are explained in the section 4.2 of the RFC4122¹.
Well it would help if I read the specs more carefully. :)
> When talking about UUIDs, there are : - time-based UUIDs, consisting
> in a timestamp, some random data, and the MAC address - name-based
> UUIDs, consisting in some stuff that make them invariant over time -
> random-based UUIDs, with just random data in them
> You could use random-based UUIDs for ThreadID, but I don't know why,
> I'm not very fan of it, even if it's simpler !
Well for things like resource binding (rfc3920bis) those might be fine.
I don't see a good reason for those to be time-based.
> You could use
> name-based UUIDs for it (based on the hash of the message and JID
> maybe). You could use time-based UUIDs. It's true that the spec says
> they embed the MAC address, which is not thinkable in the context of
> IM, so it can be replaced by a 48-bit hash ( one algorithm that could
> be used is HMAC-MD5-48 [RFC2104]² ) or a random sequence.
> Just saying “the thread ID must be an UUID” might result in different
> implementations. I think we should take a decision concerning the
> kind of UUID to use.
> The simplest are random-based UUIDs, and it
> sticks well with the idea of opaqueness. Time-based UUIDs, a lot more
> complicated, could help for some stuff, can be considered as
> not-so-opaque by those data-miners wanting to obtain information from
> them (ie. when was a thread started, making thread trees with just
> their ThreadIDs).
It's not clear to me what feature we're trying to build by saying that a
ThreadID must or should be time-based. At least in a MUC room, the order
of messages in time will be handled by the chat service (e.g., in the
context of room history or message logging).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards