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: [email protected]
_______________________________________________
