attachment

Hi,<br><br>It turns out that RFC 4122 has some serious problems of <br>inconsistent numbering of bits and bytes in the UUID.<br><br>Please read carefully - implementors beware, if you are<br>trying to *construct* a UUID by this spec, you may have<br> implementation bugs - if you are only taking OS-generated<br>UUID values and wrapping them in the URN syntax, then<br>you will not have problems.<br clear="all"><div><br>Cheers,<br>- Ira <br><br><br>Ira McDonald (Musician / Software Architect)<br> Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG IPP WG<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - TCG Embedded Systems Hardcopy SG<br>IETF Designated Expert - IPP & Printer MIB<br> Blue Roof Music/High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br> mailto:<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Winter� 579 Park Place� Saline, MI� 48176� 734-944-0094<br>Summer� PO Box 221� Grand Marais, MI 49839� 906-494-2434<br><br><div style="display:inline"> </div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div></div> <br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Benoit Claise</b> <span dir="ltr"><<a href="mailto:bclaise@cisco.com">bclaise@cisco.com</a>></span><br>Date: Wed, Mar 20, 2013 at 11:39 AM<br> Subject: [eman] Fwd: [Errata Held for Document Update] RFC4122 (3546)<br>To: eman mailing list <<a href="mailto:eman@ietf.org">eman@ietf.org</a>><br><br><br> <div text="#000000" bgcolor="#FFFFFF"> FYI, since the UUID is used in EMAN<br> <br> Regards, Benoit<br> <div><br> <br> -------- Original Message -------- <table border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <th align="RIGHT" nowrap valign="BASELINE">Subject: </th> <td>[Errata Held for Document Update] RFC4122 (3546)</td> </tr> <tr> <th align="RIGHT" nowrap valign="BASELINE">Date: </th> <td>Wed, 20 Mar 2013 08:28:20 -0700 (PDT)</td> </tr> <tr> <th align="RIGHT" nowrap valign="BASELINE">From: </th> <td>RFC Errata System <a href="mailto:rfc-editor@rfc-editor.org" target="_blank"><rfc-editor@rfc-editor.org></a></td> </tr> <tr> <th align="RIGHT" nowrap valign="BASELINE">To: </th> <td><a href="mailto:safinaskar@mail.ru" target="_blank">safinaskar@mail.ru</a>, <a href="mailto:paulle@microsoft.com" target="_blank">paulle@microsoft.com</a>, <a href="mailto:michael@refactored-networks.com" target="_blank">michael@refactored-networks.com</a>, <a href="mailto:rsalz@datapower.com" target="_blank">rsalz@datapower.com</a></td> </tr> <tr> <th align="RIGHT" nowrap valign="BASELINE">CC: </th> <td><a href="mailto:barryleiba@computer.org" target="_blank">barryleiba@computer.org</a>, <a href="mailto:iesg@ietf.org" target="_blank">iesg@ietf.org</a>, <a href="mailto:rfc-editor@rfc-editor.org" target="_blank">rfc-editor@rfc-editor.org</a></td> </tr> </tbody> </table> <br> <br> <pre>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: <a href="http://www.rfc-editor.org/errata_search.php?rfc=4122&eid=3546" target="_blank">http://www.rfc-editor.org/errata_search.php?rfc=4122&eid=3546</a> -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Askar Safin <a href="mailto:safinaskar@mail.ru" target="_blank"><safinaskar@mail.ru></a> 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 </pre> <br> </div> <br> </div> <br>_______________________________________________<br> eman mailing list<br> <a href="mailto:eman@ietf.org">eman@ietf.org</a><br> <a href="https://www.ietf.org/mailman/listinfo/eman" target="_blank">https://www.ietf.org/mailman/listinfo/eman</a><br> <br></div><br> <br />-- <br />This message has been scanned for viruses and <br />dangerous content by <a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is <br />believed to be clean.