On 30.09.2016 18:12, Kevin Smith wrote: > On 30 Sep 2016, at 10:01, Dave Cridland <d...@cridland.net> wrote: >> >> On 30 September 2016 at 09:49, Kevin Smith <kevin.sm...@isode.com> wrote: >>> >>>> On 29 Sep 2016, at 22:58, Dave Cridland <d...@cridland.net> wrote: >>>> >>>> >>>> On 29 Sep 2016 22:00, "Kevin Smith" <kevin.sm...@isode.com> wrote: >>>>> >>>>> On 29 Sep 2016, at 21:17, Dave Cridland <d...@cridland.net> wrote: >>>>>> (And please, folks, unless you can think of something I can't, a >>>>>> randomish string prefix and a counter is fine). >>>>> >>>>> The dangers of using counters in stanza IDs and leaking information :) >>>> >>>> Yes, quite. I meant to argue against generating UUIDs and otherwise using >>>> a lot of entropy, and got carried away - but a random key and hmaccing a >>>> counter should be okay. >>>> >>>> Point being, if the stanza id attribute is causing us a problem, that can >>>> be fixed in compatible ways. >>> >>> Possibly true, yes. It doesn’t resolve the MUC issue, but maybe it does >>> everything else. We should probably explicitly call out in carbons and MAM >>> the importance of preserving the id in the header. >> >> The MUC reflection-detection issue? I *think* that's the only use-case >> after however many years. >> >> We could mark just the reflected stanza, couldn't we? > > You mean add an element into the outgoing MUC message saying original-id-was > X? Seems that would work.
That's exactly what XEP-0359's <client-id/> was meant for. - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________