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/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
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 <bclaise at cisco.com>
Date: Wed, Mar 20, 2013 at 11:39 AM
Subject: [eman] Fwd: [Errata Held for Document Update] RFC4122 (3546)
To: eman mailing list <eman at ietf.org>
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 <rfc-editor at rfc-editor.org> <rfc-editor at rfc-editor.org> To:
safinaskar at mail.ru, paulle at microsoft.com, michael at refactored-networks.com,
rsalz at datapower.com CC: barryleiba at computer.org, iesg at ietf.org,
rfc-editor at rfc-editor.org
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 <safinaskar at mail.ru> <safinaskar at mail.ru>
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
eman at ietf.orghttps://www.ietf.org/mailman/listinfo/eman
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20130320/fa569eaa/attachment-0001.html>