On 30 Sep 2016, at 17:25, Dave Cridland <[email protected]> wrote: > > On 30 September 2016 at 17:12, Kevin Smith <[email protected]> wrote: >> On 30 Sep 2016, at 10:01, Dave Cridland <[email protected]> wrote: >>> >>> On 30 September 2016 at 09:49, Kevin Smith <[email protected]> wrote: >>>> >>>>> On 29 Sep 2016, at 22:58, Dave Cridland <[email protected]> wrote: >>>>> >>>>> >>>>> On 29 Sep 2016 22:00, "Kevin Smith" <[email protected]> wrote: >>>>>> >>>>>> On 29 Sep 2016, at 21:17, Dave Cridland <[email protected]> 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. >> > > I was thinking simply <this-is-your-reflection-message > xmlns='urn:xmpp:reflection'/> actually. Could include the original > stanza id, but I can't think of a use-case. > > I suppose '308 might prefer if the original id were there in the > broadcast message in case you want to correct a message before you've > even seen the reflected copy, though.
Right. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
