OASIS Open

Mitre Corporation

No

I have seen no logical rationale provided for precluding the use of RFC 1422 compliant UUIDs other than UUIDv4.

I have seen several comments asserting that somehow "allowing" users/implementers to use RFC 1422 compliant UUIDs that are deterministically generated somehow "requires" the TC to define and agree on THE method (algorithm and parameter properties) that must be used for deterministic generation and that UUIDv4 would not be possible. This is a mischaracterization of the issue in question as has been explained by multiple people on the list.

It is completely possible to "allow" the use of RFC 1422 compliant UUIDs other than UUIDv4 without "requiring" anything from users/implementers other than what they would need to do if you required UUIDv4.

All you need to do is require that the UUIDs are RFC 1422 compliant and that they should be presumed to be opaque (you don't know how they were generated). Individual organizations or trust communities can choose to override the presumption of opaqueness for themselves but any party outside of that organization or trust community can just treat them as any randomly generated UUID.

It is as simple as that.

The fact that one party in the TC does not plan to utilize some capability should not preclude others from doing so if inclusion of that capability places no barrier or burden on the party not wishing to utilize it.