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.sm...@isode.com >>> <mailto:kevin.sm...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
