RFC 4122, "A Universally Unique IDentifier (UUID) URN Namespace", July 2005Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app
Errata ID: 3546
Status: Held for Document Update
Reported By: Askar Safin
Date Reported: 2013-03-14
Held for Document Update by: Barry Leiba
Date Held: 2013-03-20
Section 4.1.3 says:
The version number is in the most significant 4 bits of the time stamp (bits 4 through 7 of the time_hi_and_version field).
It should say:
The version number is in the most significant 4 bits of the time stamp (bits 0 through 3 of the time_hi_and_version field).
We use network order (as far as I know, we use network order in this RFC both for bits and bytes). So, the most significant bits comes first and they are located in first bytes. So, 0 through 3.
---VERIFIER NOTES ---
This erratum is correct as far as it goes, but, given other text in the RFC, so is erratum 1957. There is a pervasive problem in this RFC with inconsistent and unclear usage of bit numbering, which switches between several conventions. The diagram in Section 4.1.2 uses left-to-right bit numbering (the most significant bit is numbered 0), but much of the text (such as in Section 4.2.2) uses right-to-left bit numbering (the least significant bit is numbered 0). Most of the text uses big-ending byte order (network byte order), but some seems to assume little-ending, probably mistakes that come from the authors' familiarity with that convention.
With respect to the text in question, the first sentence of Section 4.1.3, we have the following situation:
- The original text is correct if we assume right-to-left bit numbering and little-endian byte order.
- Erratum 1957 is correct if we assume right-to-left bit numbering and big-endian byte order. This change also makes the first sentence of Section 4.1.3 consistent with the sixth bullet in Section 4.2.2.
- Erratum 3546 is correct if we assume left-to-right bit numbering and big-endian byte order.
In the end, the real point is that this document needs a revision that carefully and thoroughly fixes every instance of byte numbering (or removes the byte numbering and refers only to "most significant" and "least significant"). Such a revision should also double-check the sample code in Appendix A to be sure it works in both big-ending and little-endian machines.
Happily, it's not likely that misunderstandings here will cause actual interoperability problems: this isn't a situation where things need to be disassembled and reassembled. The algorithm merely turns a UUID into a URN, and the URN is thereafter a "black box", an unchanged identifier. The only issue would be whether different interpretations of the document would turn two different UUIDs into the same URN, and, given the number of bits involved, the likelihood of collisions in practice is small.