[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt
Kurt,
Kurt D. Zeilenga wrote:
> I concur that this is a strong argument that the ordering matching
> rule should be removed from the draft. Does anyone have any
> counter arguments they would like to make?
There is value in having an ordering relationship defined, even if it
is completely arbitrary, just so that sorting and less-than and
greater-than filter items are well-defined. A client can always impose
a different ordering relationship by using an extensible match.
Also, why are you defining new matching rules that are exactly the same
as octetStringMatch and octetStringOrderingMatch ? Sections 5.1 and 5.2.19
of draft-ietf-ldapbis-syntaxes-05.txt allow octetStringMatch to be applied
to the UUID syntax. By implication, so can octetStringOrderingMatch.
Regards,
Steven
>
> Kurt
>
> At 09:40 AM 5/13/2003, John McMeeking wrote:
>
>
>
>
> >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/d
> raft-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?
> >
> >Kurt
>
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext
>
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext