I don't have a copy of the spec handy. An Internet Draft that Paul Leach
wrote (I found a copy at
http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/draft-l/draft-leach-uuids-guids-01.txt)
is probably close enough for addressing this question.
The DCE UUID spec allows for various algorithms for generating UUIDs,
reflected by a set of variant/version bits in the UUID. Four variants are
identified in the draft. One variant includes a timestamp, another uses
random numbers, and I believe another uses a hash of the timestamp and
adapter address to prevent folks from determining if UUIDs come from the
same machine. The timestamp variant puts the bytes of the timestamp in
reverse order -- "lo" bytes, "mid" bytes, then "hi" bytes. So ordering
even within that variant probably doesn't make sense, and the fact that
there are multiple variants suggests that ordering in general is not
meaningful.
John McMeeking
"Kurt D.
Zeilenga" To: John McMeeking/Rochester/IBM@IBMUS
<Kurt@OpenLDAP.or cc: ldapext@ietf.org
g> Subject: Re: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt
05/13/2003 10:58
AM
At 06:49 AM 5/13/2003, John McMeeking wrote:
2.3 'uuidOrderingMatch' Matching Rule
Why do you define an ordering matching rule for UUIDs?
For completeness. UUID ordering was discussed in the DCE
UUID specification.
I wonder though if the ordering applies to non-DCE UUID
forms allowed by my draft (I need to buy a copy of the ISO
specification) and, even if so, whether a DSA can be
reasonably expected to commit objects in UUID order.
Anyways, I wanted some discussion before deciding whether
or not to support UUID ordering matching here and that's
easier to do with a specification for it.
So, I ask, should UUID ordering support stay or be removed
from this I-D?