[Standards] XEP-136 and XEP-59 implementation comments

Peter Saint-Andre 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
'thread' attribute.

***

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

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/20080325/32b0b2f6/attachment.bin>


More information about the Standards mailing list