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

[Peter Saint-Andre]

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.

Right.

> 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. 

Agreed.

> 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).

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/20080208/1327acb7/attachment.bin