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

Peter Saint-Andre stpeter at stpeter.im
Wed Mar 26 21:43:19 UTC 2008

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 Saint-Andre

-------------- 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/20080326/9253af6e/attachment.bin>

More information about the Standards mailing list