RE: [uddi-spec] Comments on the recommended V3 key hashing algorithm

["John Colgrave" <colgrave@hursley.ibm.com>]

Bob,

It looks like we need a Change Request either way.  I am quite bullish about
these things, at least until an implementation is released, so I would
prefer to do the right thing, even though it means regenerating a couple of
dozen or so keys.  The biggest issue I see is that I think we would have to
release an updated spec. if we did this, but then I think we are almost at
the point where we need to do that anyway, based on the Change Requests that
have already been raised.

Option 1

If we continue with the current approach of presenting the details of the
algorithm, then I think we should make it clear that it is only the string
form that is used (which is "big-endian" regardless of whether the UUID was
generated as big-endian or little-endian).

Shouldn't the final five octets be reversed in the little-endian case?  All
the other multi-octet "fields" are, but the final five are the same in both
little-endian and big-endian cases.

Option 2

This is my preferred option whereby we remove most of the details of the
algorithm and just say that it is an implementation of the standard
name-based algorithm, with a single name space ID (UUID) which we define.

John Colgrave
IBM


-----Original Message-----
From: Bob Atkinson [mailto:bobatk@Exchange.Microsoft.com] 
Sent: 30 May 2003 18:55
To: John Colgrave
Cc: uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Comments on the recommended V3 key hashing
algorithm

I agree: the sequence from 10.1.1 to which you refer does indeed seem,
damn it, to be a little-endian version-4 UUID, not a big-endian one. If
we truly wish to fix this, yes, we'd have to regen the keys. 'Not clear
to me though whether on balance it's worth doing that vs. just living
with things as-is. Probably the latter, at first blush...

BTW: The link 

	http://uddi.org/Pubs/draft-leach-uuids-guids-01.txt

in 10.1.1 is now broken; it should be instead

	http://www.uddi.org/pubs/draft-leach-uuids-guids-01.txt

The description of both little endian and big endian forms is intended,
I think, to the give appropriate algorithm depending on whether one runs
on a big or little endian machine.

I'm sure the prose could be clearer...

	Bob

-----Original Message-----
From: John Colgrave [mailto:colgrave@hursley.ibm.com] 
Sent: Friday, May 30, 2003 4:34 AM
To: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] Comments on the recommended V3 key hashing
algorithm

Having had occasion to look at section 10.1.1 again recently, I was
reminded
of some issues that I had with it that have not been addressed.  If
necessary I will write a CR but, like Claus, I thought I would float the
issues in an e-mail first.

1) The spec. does not say so but the algorithm presented is clearly
meant to
be an instance of the algorithm presented in section "3.3 Algorithm for
creating a name-based UUID" in draft-leach-guids-01.txt.  It may be
better
for us to remove the duplication of the algorithm so that if people
already
have access to code to generate a name-based UUID they can use that,
subject
to a couple of extra constraints, rather than being led to believe that
they
have to implement a specific UDDI algorithm.

2) Unfortunately, there is a bug in the 16-byte sequence given in step
1a
which means that the algorithm is not a valid instance of the standard
name-based algorithm.  In the terms of the standard name-based UUID
algorithm, we need a UUID to use as a "name space ID" for all UUIDs
generated from names in that name space.  The algorithm in section
10.1.1
requires the use of a single name space and the 16-byte sequence is
meant to
be the UUID to use for that name space.  However, the "official"
algorithm
says that the name space ID should be put in network byte order before
being
concatenated with the name (in our case the V3 key) and hashed using the
MD5
algorithm.  The bug is that the 16-byte sequence given in 10.1.1 is not
in
network byte order.  It appears to be a little-endian random UUID.

3) I don't understand why we present the option of using either
big-endian
or little-endian, and I think the method of constructing the
little-endian
version contains a mistake.  The endian-ness should not affect the
string
representation of the UUID, which is what we care about.

My recommendation is that we remove the explicit description of the
algorithm in section 10.1.1 and just say that the recommended algorithm
is
that from section 3.3 of draft-leach-guids-01.txt with the extra
constraints
that: 1) a single name space ID (UUID) must be used, and we give a
correct
16-byte sequence in network byte order to be used; 2) the string
representation of the resulting UUID is to be used, as that should be
independent of the byte order used.

Unfortunately, this would mean that we would have to derive all the
V1/V2
keys again.

John Colgrave
IBM




You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_wor
kgroup.php




You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgro
up.php