[Uuidrev] Concerns regarding backwards compatibility in draft-davis-uuidrev-uuid-long-00

[Brian Mottershead <[e-mail]>]

Hi all,

I would like to express a concern regarding
[draft-davis-uuidrev-uuid-long-00] the recent Internet-Draft specifying
"Long UUIDs". In essence, this draft proposes a new universally unique
identifier format to be standardized by the IETF. "Long UUIDs" are:

* Between 160 and 3968 bits in length.

* Prefixed by a 32-bit introducer sequence giving the length and generation
algorithm of the identifier.

Although the identifier is described as a "Long UUID", it is actually an
entirely new identifier format that is neither backwards- nor
forwards-compatible with standard UUIDs:

1. Parsing Constraints: Software designed for standard 128-bit UUIDs will
not be able to store or parse "Long UUIDs" due to the 32-bit prefix and a
minimum length of 160 bits.  The variant bits (and for variants 1 and 2,
the version byte) will be offset 32-bytes but standard UUID-parsers won't
know that.

2. Variant Collisions: The bits corresponding to the standard UUID variant
field force Long UUIDs into Variant 3 (1 1 1 x), which is
reserved/undefined in RFC 9562. Consequently, no Long UUID is a valid
traditional UUID.

3. Reverse Incompatibility: No valid traditional UUID is a Long UUID.
Standard UUIDs lack the introducer sequence, are too short, and contain
something other than 0xF in the nominal "variant" position of the Long UUID
layout.

Section 6 of the draft claims backwards compatibility based on the idea
that traditional UUIDs can be translated into Long UUIDs. This is not
really backwards compatibility, and the translation mechanism is in any
case flawed.

The translation consists of prepending the UUID with a Long UUID
subvariant/ length prefix, and replacing the variant byte with 0xF. The
problems with this are:

* Lossy Translation: This mechanism only works seamlessly for DCE Variant 1
UUIDs, and not even all versions, because only versions 1,4-8 have defined
Long UUID prefixes.  No prefixes are defined at all for Variants 0, 2, or 3.

* Data Obliteration: Substituting the 0xF variant completely obliterates
the original variant byte. Because the low bits of that byte contain data,
the translation becomes lossy and strictly one-way.

To improve compatibility, I suggest the following modifications to the Long
UUID specification:

1. Modify the Sub-Variant Scheme: Change the scheme so that sv0aa
represents a Long UUID where the first 128 bits following the prefix are
precisely a valid RFC 9562 UUID, retaining its original variant and version
bits. If the identifier exceeds 160 bits, the initial 128 bits, by
themselves, must still uniquely identify the same primary entity, while
trailing bits provide extended context (e.g., greater timestamp precision
as defined by the aa algorithm). The generating algorithm is as defined in
RFC 9562.

2. Eliminate the 0xF Variant in Long UUIDs: The 0xF variant adds no unique
information and actively obliterates data in translated UUIDs. An
identifier's status as a Long UUID is already uniquely declared by its
extended length and its 32-bit introducer sequence. Removing the 0xF
variant requirement eliminates unnecessary bit manipulation.

With these changes, the translation back and forth becomes a simple matter
of adding and removing the prefix, and when going from Long to regular
UUIDs, the trailing bits.

Thanks,
Brian Mottershead