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/
smime.p7s
Description: S/MIME Cryptographic Signature
