[Standards] XEP-0308: Last Message Correction and Carbons

Florian Schmaus flo at geekplace.eu
Thu Sep 29 15:59:07 UTC 2016


On 29.09.2016 12:55, Florian Schmaus wrote:
> On 27.09.2016 11:06, Tobias M wrote:
>>> On 27 Sep 2016, at 00:33, Kevin Smith <kevin.smith at isode.com
>>> <mailto:kevin.smith at isode.com>> wrote:
>>>> What do you think? Do you have further comments on this issue?
>>>
>>> I think there’s also a concern that different resources may use the
>>> same IDs. Perhaps we should be moving away from using stanza IDs for
>>> this, and move towards something like 359 (although 359 has the
>>> client-id, stanza-id oddity which we should probably fix at some point
>>> and just use multiple stanza-id stamps with the relevant ‘by’ instead).
>>
>> Aren’t stanza IDs supposed to be UUIDs, i.e. unique? XEP-0359 could
>> provide a solution if we can’t rely on unique and stable stanza IDs.
>> It’s not discussed in XEP-0359, but I guess it’s the reason for its
>> existence, that stanza IDs may only be stable/unique regarding one XMPP
>> stream and might change in a multi-hop routing like C-to-S -> S-to-S ->
>> S-to-C or C-to-S -> MUC -> S-to-C.
> 
> Correct

Although I believe that non-xep359 stanza IDs should be stable in the
"c2s → s2s → s2c" case you gave, as error stanzas and IQ responses could
not be matched any more otherwise. But your MUC example is correct. I
remember that people have found that xep45 allows MUC services to change
the stanza id when the stanza is reflected by the service. Which causes
some trouble for client developers. Another potential use case for
xep359 are, of course, archiving services like MAM.

- Florian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160929/c4c4fa69/attachment.sig>


More information about the Standards mailing list