Consider impact of proposed UUIDv8

[garethsb]

From AMWA Slack - https://amwatv.slack.com/archives/C03L1NBR57Z/p1693925191322769

The internet-draft https://datatracker.ietf.org/doc/html/draft-ietf-uuidrev-rfc4122bis-10 updates RFC4122 to include some new UUID versions. The interesting one of these is UUIDv8 which defines a modern equivalent to UUIDv3/v5 supporting secure hash algorithms (e.g. SHA2_256).
I tried switching some of our IS-04 UUIDs to use UUIDv8 and discovered the IS-05 test suite fails validation against the response schema (the schema requires the version nibble to be 1-5). The IS-04 suite doesn't report any errors on this, though it uses the same regex in the schema.
Should we consider relaxing the UUID validation to only require the correct string pattern, not specific UUID versions? The data model doesn't impose any requirement on UUIDs except that they must not be reused. If it's not possible to update the schema (either before or after the update is ratified) then some documentation updates will be required to make it clear that the new UUID types cannot be used.

For those interested in a quick peek at UUIDv8 for names, in true hashing style, its definition seems to quite defused throughout the draft! The fourth paragraph of 5.5. UUID Version 5 (https://datatracker.ietf.org/doc/html/draft-ietf-uuidrev-rfc4122bis-10#name-uuid-version-5) seems a better place to start!

[peterbrightwell]

Discussed on ARG call 2024-09-11. We think the UUID validation should be relaxed -- constraining UUIDs isn't helpful here. This will need to be done for all ISs.