RFC Errata
Found 9 records.
Status: Verified (8)
RFC 4122, "A Universally Unique IDentifier (UUID) URN Namespace", July 2005
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 1352
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Frank Ellermann
Date Reported: 2008-03-08
Verifier Name: Alexey Melnikov
Date Verified: 2009-12-04
In Appendix B, it says:
uuid_create_md5_from_name(): e902893a-9d22-3c7e-a7b8-d6e313b71d9f
It should say:
uuid_create_md5_from_name(): 3d813cbb-47fb-32ba-91df-831e1593ac29
Notes:
The given value e902... etc. is based on a calculation swapping the eight octets 0..3, 4..5, 6..7 twice, for the name space UUID, and for the MD5 output, as foreseen for little endian input, but the example values were already big endian. I can reproduce the example and the proposed fix, see <http://omniplex.blogspot.com/2008/03/md5-16-pop3-and-uuid.html>.
The blog entry contains links to an identical older error report, and two (different) examples from third parties also agreeing with that theory.
Errata ID: 1428
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2008-05-22
Verifier Name: Alexey Melnikov
Date Verified: 2009-12-04
Section 3 says:
UUIDs, as defined in this document, can also be ordered lexicographically. For a pair of UUIDs, the first one follows the second if the most significant field in which the UUIDs differ is greater for the first UUID. The second precedes the first if the most significant field in which the UUIDs differ is greater for the second UUID.
It should say:
UUIDs, as defined in this document, can also be ordered lexicographically. For a pair of UUIDs, the first one follows the second if the most significant field in which the UUIDs differ is greater for the first UUID. The second follows the first if the most significant field in which the UUIDs differ is greater for the second UUID.
Notes:
The second and third sentences in the paragraph as originally written are
inconsistent. I have proposed one of the possible fixes. There are others
that will make them consistent.
Errata ID: 3641
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Douglas Ray
Date Reported: 2013-06-06
Verifier Name: Barry Leiba
Date Verified: 2013-06-06
Throughout the document, when it says:
Advice on generating cryptographic-quality random numbers can be found in RFC1750 [5].
It should say:
Advice on generating cryptographic-quality random numbers can be found in RFC4086 [5].
Notes:
(Above sample is from section 4.5).
References to RFC 1750 should currently refer to RFC 4086.
(Likewise in Appendix A.)
The note [5] actually references RFC4086, but this is the only
point that is updated, ie, the document is inconsistent in its references.
The references in Appendix A are not cross-referenced to note [5].
------------------------ Verifier notes ------------------------
This is correct: reference [5] was updated to point to 4086, but the text in the
document body was not changed accordingly.
Errata ID: 4975
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joseph Boon
Date Reported: 2017-03-22
Verifier Name: Orie Steele
Date Verified: 2024-04-24
Section 4.1 says:
The UUID format is 16 octets; some bits of the eight octet variant field specified below determine finer structure.
It should say:
The UUID format is 16 octets; some bits of the variant field specified below determine finer structure.
Notes:
The original wording implies the variant field is 8 octets long. It is between 1 and 3 bits long. An alternative correction would be:
"The UUID format is 16 octets; some bits of the variant
field in octet 8 specified below determine finer structure."
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
Errata ID: 184
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tim Wilson-Brown
Date Reported: 2006-05-03
Verifier Name: Alexey Melnikov
Date Verified: 2009-12-04
Section 4.3 says:
The UUIDs generated from the same name in two different namespaces
should be different with (very high probability).
It should say:
The UUIDs generated from the same name in two different namespaces
should be different (with very high probability).
Notes:
The brackets should be set similarly to the other points.
Errata ID: 3476
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Kissane
Date Reported: 2013-02-02
Verifier Name: Barry Leiba
Date Verified: 2013-02-03
Section Appendix A,B says:
In Appendix A, the line:
uuid_create_md5_from_name(&u, NameSpace_DNS, "www.widgets.com", 15);
In Appendix B, the line:
uuid_create_md5_from_name(): e902893a-9d22-3c7e-a7b8-d6e313b71d9f
It should say:
In Appendix A, the line:
uuid_create_md5_from_name(&u, NameSpace_DNS, "www.example.com", 15);
In Appendix B, the line:
uuid_create_md5_from_name(): 5df41881-3aed-3515-88a7-2f4a814cf09e
Notes:
Per RFC2606 section 5, it is best practice for standards and other documentation (including RFCs) to use the reserved example domains (e.g. example.com) rather than domains which could be in actual use. Indeed, the domain in question (www.widgets.com) is in actual use at the time of writing. So this proposed change uses "www.example.com" instead, and changes the example output accordingly. (Note that original output was wrong for the original input, as already noted in verified errata 1352.)
Errata ID: 6665
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrzej Koszela
Date Reported: 2021-08-25
Verifier Name: Orie Steele
Date Verified: 2024-03-29
Section Appendix A says:
static unsigned16 true_random(void);
/* uuid_create -- generator a UUID */
int uuid_create(uuid_t *uuid)
{
uuid_time_t timestamp, last_time;
It should say:
static unsigned16 true_random(void);
/* uuid_create -- generate a UUID */
int uuid_create(uuid_t *uuid)
{
uuid_time_t timestamp, last_time;
Notes:
The comment above the declaration of uuid_create() uses "generate a UUID", so the comment above the definition is likely intended to be identical.
Status: Reported (1)
RFC 4122, "A Universally Unique IDentifier (UUID) URN Namespace", July 2005
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 6225
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Marschall
Date Reported: 2020-07-07
Section 4.3 says:
ISO Object IDs (OIDs)
It should say:
Object Identifiers (OIDs)
Notes:
An Object Identifier (OID) is an identification mechanism jointly developed by ITU-T and ISO/IEC.
It makes no sense saying that it is an "ISO OID". Actually, it can be very confusing, because people could think that "ISO OID" means an OID which is a descendant of { iso(1) }, which would exclude OIDs descending from { itu-t(0) } and { joint-iso-itu-t(2) }.
Also in Appendix C, "Name string is an ISO OID" should be changed to "Name string is an OID".
Maybe it would also be good to mention how the OID should be formatted. I guess the intention of the author is the normal dot-notation "2.999" which is passed as ASCII text to the name-based UUID generation function.