On 2 Oct 2016, at 18:47, Florian Schmaus <f...@geekplace.eu> wrote: > > 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.
I don’t think that was clear from 359. My reading of 359 was that this was another client-generated ID, and that it was the client that stamped it. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
