Subject: [eman] Fwd: [Errata Held for Document Update] RFC4122 (3546)

From: Benoit Claise <[email-masked]>
Date: Wed, 20 Mar 2013 16:39:10 +0100

FYI, since the UUID is used in EMAN

Regards, Benoit

-------- Original Message --------
Subject: 	[Errata Held for Document Update] RFC4122 (3546)
Date: 	Wed, 20 Mar 2013 08:28:20 -0700 (PDT)
From: 	RFC Errata System <[email-masked]>
To: 	[email-masked], [email-masked], 
[email-masked], [email-masked]
CC: 	[email-masked], [email-masked], [email-masked]

The following errata report has been held for document update
for RFC4122, "A Universally Unique IDentifier (UUID) URN Namespace".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4122&eid=3546

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Askar Safin <[email-masked]>
Date Reported: 2013-03-14
Held by: Barry Leiba (IESG)

Section: 4.1.3

Original Text
-------------
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).

Corrected Text
--------------
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).

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

--------------------------------------
RFC4122 (draft-mealling-uuid-urn-05)
--------------------------------------
Title               : A Universally Unique IDentifier (UUID) URN Namespace
Publication Date    : July 2005
Author(s)           : P. Leach, M. Mealling, R. Salz
Category            : PROPOSED STANDARD
Source              : IETF - NON WORKING GROUP
Area                : N/A
Stream              : IETF
Verifying Party     : IESG