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

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 13 May 2003 09:53:55 -0700

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?

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/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                                      
>                      <[email-masked]        cc:       [email-masked]                                                        
>                      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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Ludovic Poitou <[email-masked]>
Date: Tue, 13 May 2003 19:26:32 +0200

>counter arguments they would like to make?
No.. Please remove the ordering matching rule.

Ludovic.

-- 
Ludovic Poitou
Sun Microsystems Inc.
Sun ONE products - Directory Server Group - Grenoble - France

---

From: "Steven Legg" <[email-masked]>
Date: Wed, 14 May 2003 10:17:39 +1000

Kurt,

> 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

> >                      g>                       Subject:  Re: 
> [ldapext] I-D ACTION:draft-zeilenga-ldap-uuid-00.txt                
> >                                                             
>                                                                     
> >                      05/13/2003 10:58                       
>                                                                     
> >                      AM                                     
>                                                                     
> >                                                             
>                                                                     
> >                                                             
>                                                                     
> >
> >
> >
> >

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 13 May 2003 17:43:08 -0700

>a different ordering relationship by using an extensible match.

Noted.

>as octetStringMatch and octetStringOrderingMatch ?

Because UUID syntax has its own LDAP-specific string encoding.

>Sections 5.1 and 5.2.19

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.

---

From: "Steven Legg" <[email-masked]>
Date: Wed, 14 May 2003 12:18:33 +1000

Kurt,

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

> 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

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 13 May 2003 19:34:22 -0700

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

>matched by octetStringMatch.

Problem is with LDAP.

---

From: "Steven Legg" <[email-masked]>
Date: Wed, 14 May 2003 13:15:40 +1000

Kurt,

Kurt D. Zeilenga
> the abstract type AND the LDAP string encoding to use.

... for the assertion value. Yes, okay, fair point.

Regards,
Steven

---

From: "Steven Legg" <[email-masked]>
Date: Wed, 14 May 2003 13:47:51 +1000

> ... for the assertion value. Yes, okay, fair point.

More an observation than a suggestion for change: if the equality
matching rule for the entryUUID attribute was allComponentsMatch
and the LDAP-specific encoding for the UUID syntax was the GSER
encoding then the UUIDs would appear as hexadecimal digit character
strings in LDAP, in both the attribute values and assertion values,
and they would be matched in the same way as octetStringMatch.
I assume that the ISO 11578 string representation isn't anything
special and that all you care about is that the UUIDs normally appear
as displayable characters rather than raw octets.

There isn't an allComponentsOrderingMatch though.

Regards,
Steven

---

From: [email-masked] (Mark C Smith)
Date: Wed, 14 May 2003 09:08:33 -0400

> as displayable characters rather than raw octets.

I suspect the ISO 11578 string representation is special to some people 
and some existing code. It seems wise to use it rather than something 
that will be directory specific.

-- 
Mark Smith
Netscape Directory Product Development
My words are my own, not my employer's.