[plt-scheme] UUID Question

I finally found an RFC Errata Report (
http://www.rfc-editor.org/errata_search.php?rfc=4122) that states:

In Appendix B, it says:

uuid_create_md5_from_name(): e902893a-9d22-3c7e-a7b8-d6e313b71d9f

It should say:

uuid_create_md5_from_name(): 3d813cbb-47fb-32ba-91df-831e1593ac29

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 <
http://omniplex.blogspot.com/2008/03/md5-16-pop3-and-uuid.html>.

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 "www.widgets.com") = #<uuid
3d813cbb-47fb-32ba-91df-831e1593ac29>
(make-uuid-3 namespace-DNS "www.widgets.com" #t) = #<uuid
e902893a-9d22-3c7e-a7b8-d6e313b71d9f>
...

I think this is the correct resolution.

Doug

On Tue, Dec 15, 2009 at 9:03 PM, Robby Findler
<robby at eecs.northwestern.edu>wrote:

> 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
>
> On Tue, Dec 15, 2009 at 9:46 PM, Doug Williams
> <m.douglas.williams at gmail.com> 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
> >
> > _________________________________________________
> >  For list-related administrative tasks:
> >  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20091216/76d44547/attachment.html>