I also agree that a recommendation to use UUID is totally sufficient here (call it RECOMMENDED or SHOULD, I don't care). There is no need to require a UUID. Adding a recommendation for UUID is also inherently backwards compatible and therefor does not require a namespace bump.
I also doubt the necessity for a 122 bits of randomness for this specific usecase, that is the id of a jingle session, which by definition is both short-lived and only between two entities. These two parameters make an accidental collision highly unlikely while intentional collisions should only harm the communication of the two parties. Finally, the obsession with use of UUID as "unique strings" in XMPP seems a bit weird to me. The hex-encoding with dashes and version information is far away from an efficient encoding of 122 bits of randomness. The only reason we started with UUIDs was that previously, clients did not use actual randomness to generate message ids, thereby causing collisions. Using a UUIDv4 became a way for a client to signal to other clients "my ids are actually random and collision free". This probably will remain relevant for message/iq ids in the future, but it is not for any other ids. Which brings me to the conclusion: If we want to gauarantee a certain amount of randomness in any id field, we should just state exactly that, e.g. "the id SHOULD include at least 120 bits of randomness, for example by using an UUIDv4" (and then we might see people in the wild just encode 15 random bytes using base64, saving 16 bytes on the wire with every id). Marvin On Thu, 2023-01-05 at 11:18 +0100, Florian Schmaus wrote: > > On 05/01/2023 10.51, Dave Cridland wrote: > > * The argument that this doesn't need a namespace bump is wrong > > because > > "experimental" has no effect here. The entire point of those > > 'versioned' > > namespaces was to ensure that we could freely implement > > Experimental > > XEPs without worrying about causing compatibility nightmares. The > > argument that there's no implementation is counter-productive - if > > there's nobody implementing, then by definition it doesn't matter > > if you > > bump the namespace. > > +1 > > I see a recent trend in the community that it is acceptable to > introduce > backwards incompatible changes in 'experimental' XEPs. I think we are > moving along a dangerous path if this trend continues. > > However, I believe that this trend is part a symptom of a larger > problem. Namely that we e are missing a workflow where people can > work > together on a standards document, while implementing what is > described > in that document and still be able to react agile regarding protocol > changes. The latter means, amongst other things, being able to > introduce > backwards incompatible changes without a namespace bump. > > I become more and more convinced that we may be better with an IETF > I-D > / RFC style standardization process. Where an I-D is a mutable, > living > document on the road to become an immutable RFC. > > > > * In general, I think ids expected to be reasonably unique ought to > > be > > UUIDv4. I mean, why not? But I'm hesitant to mandate this > > absolutely, > > such as in this change, because although I'd like *senders* to > > always > > use a UUIDv4, I'm a bit concerned about *receivers* making that > > assumption, and trying to parse out a UUIDv4 and storing it in a > > 128-bit > > number or something. In some cases, that'd be a handy thing (I've > > done > > this internally with MAM identifiers, for example), but I think we > > should be very careful about when this is the right choice. > > > > So, I'd suggest "SHOULD" here at most, and I might choose to phrase > > it > > as "RECOMMENDED", which has the same RFC 2119 meaning, but somewhat > > different implicit meaning in English. > > I also would prefer this approach. Simply because I believe that MUST > should only be used when it is strictly necessary. In this case, it > appears to be enough to just say the requirements of the ID value and > recommend (as in suggest) implementations to use UUIDv4. Unless I am > missing a a reason the protocol absolutely requires UUIDv4 and would > break otherwise? > > - Flow > _______________________________________________ > 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 _______________________________________________
