[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt
At 07:18 PM 5/13/2003, Steven Legg wrote:
>Kurt D. Zeilenga wrote:
>> At 05:17 PM 5/13/2003, Steven Legg wrote:
>> >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.
>
>Doesn't matter. Matching rules operate on the abstract value,
>not any particular encoding of the abstract value.
While true, the OID of the matching rule identifies both
the abstract type AND the LDAP string encoding to use.
>> >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.
>
>Doesn't matter. The underlying data type is still OCTET STRING,
>and as far as X.500 is concerned, they are all eligible to be
>matched by octetStringMatch.
Problem is with LDAP.
>> That is, the octets of the UUID are not transferred
>> "unconverted" like an OCTET STRING, converted to a string
>> representation for transfer.
>
>An OCTET STRING is transfered differently depending on whether
>it is BER, GSER or XER encoded, but that doesn't preclude matching
>with octetStringMatch. A difference in encoding based on which
>LDAP syntax the OCTET STRING belongs to is equally unimportant
>for matching purposes.
>
>You've defined uuidMatch to be semantically the same as octetStringMatch
>so they must be interchangeable, by definition. If you think
>octetStringMatch
>is inadequate then the current definition of uuidMatch must also be
>inadequate.
>If you mean for the matching to be on the ISO 11578 string representation
>then you should be using a character string type for the syntax,
>not OCTET STRING.
>
>Regards,
>Steven
>
>>
>>
>>
>>
>> >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
>>
>
>_______________________________________________
>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