[Standards] XEP-136 and XEP-59 implementation comments
stpeter at stpeter.im
Tue Mar 25 15:53:22 UTC 2008
About threads, I missed some text in XEP-0136...
Peter Saint-Andre wrote:
> Alexander Tsvyashchenko wrote:
>> To be true, I think that this issue is out of the scope of XEP-136 - I
>> would expect that <thread> behavior either should be specified by
>> XEP-201 (or somewhere else) or left as implementation-defined; on the
>> other hand, XEP-136, probably, should just take into account <thread>
>> values and use them for its business like described above.
> Agreed. So perhaps we need to say how threads are used in archiving. I
> see that we've left that out so far.
Right now XEP-0136 says:
If an opaque thread ID (found in the <thread/> children of the
<message/> elements whose content is stored in the collection) is
associated with the conversation then it MUST be specified with a
So I think the ThreadID is already being incorporated already.
>> So, for me it looks like the following could be specified in XEP-136:
>> 1) If no <thread> element exist, server may use its own
>> implementation-defined strategies for mapping messages and conversations
>> to collections and also may treat resources in implementation-defined way.
>> Maybe some heuristic can be suggested such as the one I described in my
>> first letter for "conversations tracking", but I doubt anything 100%
>> reliable can be proposed.
>> 2) If <thread> element is present, the mapping is exactly 1 <-> 1 (one
>> thread element to one collection). If "parent" attribute is present for
>> thread - the link should be created of type "parent" to the appropriate
> That seems reasonable.
>> Resources can be treated as follows: when receiving first message with
>> full JID it's allowed to overwrite previous bare JID of collection by
>> new, full JID; if previous JID was already full and the new one is also
>> full, and differs from the previous one - assume that we have
>> "multi-resource" case, modify collection's JID to bare one and forbid
>> all its further overwrites.
> That, too, seems reasonable.
I think those points belong in the implementation notes.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards