Alexander Tsvyashchenko wrote: > > Peter, > >> About threads, I missed some text in XEP-0136... > > ... skipped ... > >> >> 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. > > Ok, but "parent" linking for collections still needs to be added to > XEP-136 if you agree with the approach we've discussed. > >>>> 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. > > Hm, I would say that enforcing 1 <-> 1 mapping between > threads/collections and the requirement to respect "parent" link might > be considered as parts of the specification, no? Although the > requirement to have "thread" attribute, as it's written in XEP-136, > already implies 1 <-> 1 mapping, I would say it's better to state that > explicitly to avoid any ambiguities. > > I agree that the other things are more up to the implementation - though > I'd prefer having these notes available somewhere if I had started > working on mod_archive_odbc now, as they would save me some time, so I > think they still might be useful to other implementors.
Yes I will figure out how to work this information into the spec sometime soon. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
