Re: [Standards] XEP-0359 Client vs. non-client IDs
I appreciate the implementation-related argument too. I don't think that that argument should outweigh the value of applying clear, concise naming. Removing the "client/server" role is a big improvement there. There's no use-case for this XEP where the 'by' is left out by an entity that's not an 'origin' entity? On 3 October 2016 at 11:11, Kevin Smith wrote: > > > On 2 Oct 2016, at 18:46, Florian Schmaus wrote: > > > > On 29.09.2016 20:18, Kevin Smith wrote: > >> On 29 Sep 2016, at 19:08, Florian Schmaus wrote: > >>> > >>> On 29.09.2016 19:22, Guus der Kinderen wrote: > Hi, > > What's the purpose of the distinction between "Unique Stanza IDs" and > "Client generated stanza IDs"? Why not add a unbounded list of > stanza-id > elements (each with a unique 'by' attribute value), and not worry > about > what entity is serving in a client-capacity? > >>> > >>> It was designed that way to avoid leaking the client's XMPP address in > >>> cases like MUC. Notice that has a 'by' attribute whereas > >>> has not. I should add that rationale to the XEP. > >> > >> That makes sense, but why not just say something like “the stanza-id > without a by is the originating entity”. > > > > That's the other approach I could have taken when designing the protocol > > (and I find myself often in the situation where I have to decide between > > those two approaches when working on new extension protocols for XMPP). > > > > I personally find the variance it introduces, that the 'by' attribute > > can either exit or not, less desirable. Instead I enjoy the fact that I > > can look at the element's name and tell if it requires a non-empty 'by' > > attribute or that it must not have one. I find this preferable when > > writing parsers, designing classes for extension elements (e.g. a method > > "getBy()" will always return a JID for the class > > represents), or writing the XEP itself. > > I can buy that argument. > > > > >> Else sometimes the orginating entity stamps with a client-id (when it’s > a client) or doesn’t (when it’s a server), or you have servers stamping > with client-id, or whatever. > > > > Fair point. How about 's/client-id/origin-id/‘? > > Or just origin? Either way, I think an improvement, yes. > > /K > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359 Client vs. non-client IDs
> On 2 Oct 2016, at 18:46, Florian Schmaus wrote: > > On 29.09.2016 20:18, Kevin Smith wrote: >> On 29 Sep 2016, at 19:08, Florian Schmaus wrote: >>> >>> On 29.09.2016 19:22, Guus der Kinderen wrote: Hi, What's the purpose of the distinction between "Unique Stanza IDs" and "Client generated stanza IDs"? Why not add a unbounded list of stanza-id elements (each with a unique 'by' attribute value), and not worry about what entity is serving in a client-capacity? >>> >>> It was designed that way to avoid leaking the client's XMPP address in >>> cases like MUC. Notice that has a 'by' attribute whereas >>> has not. I should add that rationale to the XEP. >> >> That makes sense, but why not just say something like “the stanza-id without >> a by is the originating entity”. > > That's the other approach I could have taken when designing the protocol > (and I find myself often in the situation where I have to decide between > those two approaches when working on new extension protocols for XMPP). > > I personally find the variance it introduces, that the 'by' attribute > can either exit or not, less desirable. Instead I enjoy the fact that I > can look at the element's name and tell if it requires a non-empty 'by' > attribute or that it must not have one. I find this preferable when > writing parsers, designing classes for extension elements (e.g. a method > "getBy()" will always return a JID for the class > represents), or writing the XEP itself. I can buy that argument. > >> Else sometimes the orginating entity stamps with a client-id (when it’s a >> client) or doesn’t (when it’s a server), or you have servers stamping with >> client-id, or whatever. > > Fair point. How about 's/client-id/origin-id/‘? Or just origin? Either way, I think an improvement, yes. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0308: Last Message Correction and Carbons
On 03.10.2016 10:08, Kevin Smith wrote: > On 2 Oct 2016, at 18:47, Florian Schmaus wrote: >> >> On 30.09.2016 18:12, Kevin Smith wrote: >>> On 30 Sep 2016, at 10:01, Dave Cridland wrote: On 30 September 2016 at 09:49, Kevin Smith wrote: > >> On 29 Sep 2016, at 22:58, Dave Cridland wrote: >> >> >> On 29 Sep 2016 22:00, "Kevin Smith" wrote: >>> >>> On 29 Sep 2016, at 21:17, Dave Cridland 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 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. Sorry, that was meant as reply to "We could mark just the reflected stanza, couldn't we?". The idea was that clients will recognize their own stanzas by the , which will stay unchanged unlike the stanza id of the header. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0308: Last Message Correction and Carbons
On 2 Oct 2016, at 18:47, Florian Schmaus wrote: > > On 30.09.2016 18:12, Kevin Smith wrote: >> On 30 Sep 2016, at 10:01, Dave Cridland wrote: >>> >>> On 30 September 2016 at 09:49, Kevin Smith wrote: > On 29 Sep 2016, at 22:58, Dave Cridland wrote: > > > On 29 Sep 2016 22:00, "Kevin Smith" wrote: >> >> On 29 Sep 2016, at 21:17, Dave Cridland 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 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 ___