[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt



Kurt,

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.

> >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.

> 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