RFC Errata
RFC 4122, "A Universally Unique IDentifier (UUID) URN Namespace", July 2005
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
See Also: RFC 4122 w/ inline errata
Errata ID: 5560
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: GLOBAL UUID DATABASE
Date Reported: 2018-11-25
Verifier Name: Orie Steele
Date Verified: 2024-04-24
Section 4.1.1 says:
The following table lists the contents of the variant field, where
the letter "x" indicates a "don't-care" value.
Msb0 Msb1 Msb2 Description
0 x x Reserved, NCS backward compatibility.
1 0 x The variant specified in this document.
It should say:
The following table lists the contents of the variant field, where
the letter "x" indicates a "don't-care" value.
Msb0 Msb1 Msb2 Description
0 x x Reserved, NCS backward compatibility.
1 0 0 The variant specified in this document.
Notes:
If Msb2 is a « don't-care » value, this means it's not wrong to set the bit to 0 or 1.
In the case of UUIDv3 and UUIDv5, this does not specify if the bit from the hash output should be left untouched or not.
It's not stated that it's illegal to reset it to 0 when setting Msb0 and Msb1 altogether (as libuuid does), since it's a « don't-care » value.
But letting it untouched whenever it's set to 1 by the hash output (as the Python stdlib does) causes two UUIDv{3,5} to be different for the same input namespaces and data. (Example: NS=Nil UUID, data = 0x44 («D»).
The RFC should enforce the value of the bit to 0 or 1, or clarify if it should be left untouched depending on the context-dependent data (Clock ID {1,2}, hash output {3,5}, random input {4}). (Which would mean it's then just a libuuid bug to forcibly set Msb2 to 0 when it should be untouched.)
See also : https://uuid.pirate-server.com/blog/brother-uuids-or-why-uuids-are-not-unique.html