RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 9 records.

Status: Verified (5)

RFC 4122, "A Universally Unique IDentifier (UUID) URN Namespace", July 2005

Source of RFC: IETF - NON WORKING GROUP
Area 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: 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.)

Status: Reported (4)

RFC 4122, "A Universally Unique IDentifier (UUID) URN Namespace", July 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 4975
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Joseph Boon
Date Reported: 2017-03-22

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: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: GLOBAL UUID DATABASE
Date Reported: 2018-11-25

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: 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.

Errata ID: 4976
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Joseph Boon
Date Reported: 2017-03-22

Throughout the document, when it says:

Set the two most significant bits (bits 6 and 7) of the
clock_seq_hi_and_reserved to zero and one, respectively.

It should say:

Set the two most significant bits (bits 7 and 6) of the
clock_seq_hi_and_reserved to one and zero, respectively.

Notes:

The original wording appears in sections 4.2.2, 4.3, and 4.4. It can lead to confusion about which bit is most significant (6 or 7), and does not align neatly with the table of Variants in section 4.1.1 (which shows 1 followed by 0 for msb0 and msb1). The revised wording specifies the bits in msb order, which helps the reader more clearly correlate the bit values with section 4.1.1. It is noted that the revised wording would not match other parts of the document which give the lsb number first (e.g. "bits 32 through 47"), but this case is different because it is specifying fixed values for two bits, and the sentence starts with "Set the two most significant bits".

Report New Errata