[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt
At 05:17 PM 5/13/2003, Steven Legg wrote:
>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.
Noted.
>Also, why are you defining new matching rules that are exactly the same
>as octetStringMatch and octetStringOrderingMatch ?
Because UUID syntax has its own LDAP-specific string encoding.
>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.
I think not. The UUID syntax differs from other OCTET STRING
derived syntaxes, such as JPEG, in that it has a different
LDAP-specific string encoding than that prescribed for OCTET
STRINGs. That is, the octets of the UUID are not transferred
"unconverted" like an OCTET STRING, converted to a string
representation for transfer.
>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