I finally found an RFC Errata Report (<a href="http://www.rfc-editor.org/errata_search.php?rfc=4122">http://www.rfc-editor.org/errata_search.php?rfc=4122</a>) that states: In Appendix B, it says: <pre class="rfctext">uuid_create_md5_from_name(): e902893a-9d22-3c7e-a7b8-d6e313b71d9f </pre> It should say: <pre class="rfctext">uuid_create_md5_from_name(): 3d813cbb-47fb-32ba-91df-831e1593ac29 </pre> Notes: The given value e902... etc. is based on a calculation swapping the eight octets 0..3, 4..5, 6..7 twice, for the name space UUID, and for the MD5 output, as foreseen for little endian input, but the example values were already big endian. I can reproduce the example and the proposed fix, see <<a href="http://omniplex.blogspot.com/2008/03/md5-16-pop3-and-uuid.html">http://omniplex.blogspot.com/2008/03/md5-16-pop3-and-uuid.html</a>>. The blog entry contains links to an identical older error report, and two (different) examples from third parties also agreeing with that theory. --- I will take Robby's advice and have one definition and have an optional Boolean argument to force the 'buggy' behaviour. The default will be the 'correct' encoding per the Unix uuid command. Now, I have the following test output: ... (make-uuid-3 namespace-DNS "<a href="http://www.widgets.com">www.widgets.com</a>") = #<uuid 3d813cbb-47fb-32ba-91df-831e1593ac29> (make-uuid-3 namespace-DNS "<a href="http://www.widgets.com">www.widgets.com</a>" #t) = #<uuid e902893a-9d22-3c7e-a7b8-d6e313b71d9f> ... I think this is the correct resolution. Doug <div class="gmail_quote">On Tue, Dec 15, 2009 at 9:03 PM, Robby Findler <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I would say that the right thing is an optional (or keyword) argument that defaults to the value of a parameter, so the default can easily be changed for a range of code. Robby <div><div></div><div class="h5"> On Tue, Dec 15, 2009 at 9:46 PM, Doug Williams <<a href="mailto:m.douglas.williams@gmail.com">m.douglas.williams@gmail.com</a>> wrote: > I've implemented RFC 4122 Universally Unique Identifiers (UUIDs) and have an > interesting dilemma. Two of the types of UUIDs are generated based on a > namespace UUID and name using either MD5 (a type 3 UUID) or SLA-1 (a type 5 > UUID) hashes. I implemented the type 3 and type 5 UUIDs in accordance with > RFC 4122 - in particular, my result for the type 3 example in the RFC > matches the result I get; there is no type 5 example. Then I checked it > against the Python implementation and got a different answer. After a bit of > a search I found a post by the original author of the Python code that said > he felt the RFC implementation was in error. Anyway, the Unix uuid command > matches the Python answer, but I have found others (e.g., Apache and PHP > that match (or did match) the RFC). For the curious, the difference has to > do with byte-swapping to/from network order. > > I've implemented type 3 and type 5 UUIDs both ways and have separate calls - > for example, make-uuid-3 and make-uuid-3*. For now, I have make-uuid-3 > matching the Unix uuid command and make-uuid-3* matching the RFC. The same > goes for type 5 UUIDs. > > The first question is whether there are any web gurus on the mailing list > that might know which really is the correct/preferred implementation. I > haven't found any addenda or anything for RFC 4122 that suggests that the > IETF considers the RFC to be in error. On the other hand, the Unix and > Python implementations are widely used. > > The second question is whether to two functions as described above or a > single function with an optional argument to specify which of the two > alternatives to use. My initial decision is to use two functions as above, > where the Unix uuid values are the unstarred version. So, make-uuid-3 > returns the same value as the Unix 'uuid -v3' command and make-uuid-3* > returns the same value as the RFC reference implementation. [My assumption > being that the Unix uuid version is the more wide used, but I may be totally > wrong.] > > I do feel I should provide both, since both seem to exist 'in the wild' and > the purpose of type 3 and 5 UUIDs is to be repeatable. > > For those interested, the package also produces type 1 (time-based) and type > 4 (random) UUIDs. > > Doug > </div></div>> _________________________________________________ > For list-related administrative tasks: > <a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme" target="_blank">http://list.cs.brown.edu/mailman/listinfo/plt-scheme</a> > > </blockquote></div>