[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]