Hi, 1. It is impossible to guarantee that an identifier is "globally unique", thus this requirement should not end up in any specification. 2. The session ID is already required to be random as per XEP-0166.
What is the problem that you want to solve here? Looking at the protocol, the only thing where it is relevant that ids are collision free is the tie breaking. But that's far away from global uniqueness. Further more, the tie breaking could just be modified to include the initiators full jid as a second ordering criteria, which is guaranteed to be collision free. Marvin On Fri, 2023-01-06 at 04:31 +0100, Thilo Molitor wrote: > Well, thanks for all your explanations and recommendations. > I'll go with "This identifier MUST be globally unique, and therefore > it is > RECOMMENDED to use UUIDv4." > I updated the PR accordingly: https://github.com/xsf/xeps/pull/1262 > > -tmolitor > > > Am Donnerstag, 5. Januar 2023, 14:27:22 CET schrieb Dave Cridland: > > On Thu, 5 Jan 2023 at 10:19, Florian Schmaus <[email protected]> > > 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. > > > > For a long time, it tended to be the opposite problem - people > > would add an > > optional attribute or child element, and then bump the namespace. > > That's > > irritating (and harms interoperability in a safe manner), but not > > as bad as > > introducing incompatible changes and *not* bumping the namespace. > > > > > 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 think we have that, modulo that if we introduce an incompatible > > change, > > we bump the namespace. And in many cases, you can handle both > > namespaces > > easily with one or two conditionals, so if you're closely tracking > > a XEP in > > your implementation, it's usually OK. > > > > The advantage of our model is that if people are not working > > closely > > together, it's still safe. > > > > > 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. > > > > Well... An Experimental XEP maps to an I-D, except we've made ours > > safe to > > implement in the wild (fairly) safely. > > > > RFCs map to DraftStable/Final XEPs. These still might change, but > > this > > really ought to be pretty rare, especially with Final. The fact > > they're not > > immutable is, I agree, not ideal - but the static nature of RFCs > > brings its > > own set of problems and I'm not really sure which is the better > > option. > > > > I think the thing I'm missing is that I sometimes want to be able > > to find > > the latest XEP version covering a particular namespace, but that > > requires > > tooling changes etc and I don't care enough to fix it myself, so... > > > > Dave. > > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
