Subject: [IPP] Fwd: Errata for RFC 4122 (UUID-based URN)

From: Ira McDonald <[email-masked]>
Date: Wed, 20 Mar 2013 12:22:57 -0400

Hi,

It turns out that RFC 4122 has some serious problems of
inconsistent numbering of bits and bytes in the UUID.

Please read carefully - implementors beware, if you are
trying to *construct* a UUID by this spec, you may have
implementation bugs - if you are only taking OS-generated
UUID values and wrapping them in the URN syntax, then
you will not have problems.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

---------- Forwarded message ----------
From: Benoit Claise <[email-masked]>
Date: Wed, Mar 20, 2013 at 11:39 AM
Subject: [eman] Fwd: [Errata Held for Document Update] RFC4122 (3546)
To: eman mailing list <[email-masked]>

 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]> <[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]> <[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

_______________________________________________
eman mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/eman

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp