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] _______________________________________________
