Subject: Returning Matched Values with LDAPv3

From: [email-masked]
Date: Tue, 17 Oct 2000 13:44:36 -0500 (CDT)

In reference to

	http://www.ietf.org/internet-drafts/draft-ietf-ldapext-matchedval-04.txt

I don't understand the filter used in example (3):

    ValuesReturnFilter control is set to (userCertificate:2.5.13.35:=USE'001'B)
	
Some reference to a source of "string to filter" for

	USE'001'B

would help.

It is not clear from the description if example (2) could return the result
on the basis of the name 'gunk' instead of on the basis of the OID.

Does the substring filter capability allow a filter of the form:

	(attributeTypes=*'gunk'*)

If I knew the OID number of "gunk", the entire "attributeTypes" attribute of
the schema entry has probably been read, and I don't need the LDAP extension
to read it.

An example to retrieve an "objectClasses" attribute would help.  I assume
that this could be:

	(objectClasses:NAME:=inetOrgPerson)

Is that correct?  Would the filter

	(objectClasses=*'inetOrgPerson'*)

work to get this string?

Thanks.
-- 
David A. Cahlander  651-415-3171 Syntegra [email-masked]

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 17 Oct 2000 12:08:20 -0700

>        (attributeTypes=*'gunk'*)

There is no substrings matching rule for attributeTypes, so this
assertion is 'Undefined'.

I suggest the example use (attributeTypes=2.5.4.3) as the equality
matching rule for attributeTypes is objectIdentifierFirstComponentMatch
which requires an assertion value of syntax OID.  Some servers
support (attributeTypes=cn) as well.

>the schema entry has probably been read, and I don't need the LDAP extension

You need an LDAP extension to return only the matched values.

>An example to retrieve an "objectClasses" attribute would help.

  (objectClasses=2.5.4.0)

or
  (objectClasses=objectclass)  // supported by some servers

Kurt

---

From: "Steven Legg" <[email-masked]>
Date: Wed, 18 Oct 2000 16:25:22 +1100

David,

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, 18 October 2000 5:45
> To: [email-masked]
> Subject: Returning Matched Values with LDAPv3
> 
> 
> In reference to
> 
> 	

The assertion syntax here is actually incorrect.
The filter should read:

(userCertificate:2.5.13.35:=( USE '001'B ))

> Some reference to a source of "string to filter" for

It is an encoding of a <CertificateAssertion> defined in Section 3.2 of
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-schema-01.txt,
which example (3) already references.
 
> 	(objectClasses=*'inetOrgPerson'*)

Kurt has already pointed out that substring matching on attributeTypes
or objectClasses is undefined. However matching attributeTypes or
objectClasses values by name is something that is supported by
the component matching rules draft that I've nearly finished writing up.
The filters in this case would look like:

	(attributeTypes:componentFilterMatch:=item:{ component "name.*",
		rule caseIgnoreMatch, value "gunk" })

	(objectClasses:componentFilterMatch:=item:{ component "name.*",
		rule caseIgnoreMatch, value "inetOrgPerson" })

They could be used in a search filter or a ValuesReturnFilter.

Regards,
Steven

---

From: "David Chadwick" <[email-masked]>
Date: Sat, 21 Oct 2000 16:08:23 +0100

From:           	"Kurt D. Zeilenga" <[email-masked]>

> At 01:44 PM 10/17/00 -0500, [email-masked] wrote: >It
> is not clear from the description if example (2) could return the
> result >on the basis of the name 'gunk' instead of on the basis of the
> OID. > >Does the substring filter capability allow a filter of the
> form: > >        (attributeTypes=*'gunk'*)
> 
> matching rule for attributeTypes is
> objectIdentifierFirstComponentMatch which requires an assertion value
> of syntax OID. 

Kurt, I dont understand why changing the example to retrieve cn 
rather than gunk will help the understanding. Further, since 
everyone already knows the definition of cn, one might ask why are 
we wanting to retrieve this definition!

> Some servers support (attributeTypes=cn) as well.

Then we need to formally specify a stringThirdComponent matching 
rule as an equality matching rule for attributeTypes, if we are to 
widely support this. (Note this is counting NAME as the second 
component). Should we do this? 

> 
> >If I knew the OID number of "gunk", the entire "attributeTypes"
> >attribute of the schema entry has probably been read, and I don't
> >need the LDAP extension to read it.
> 

to retrieve the objectClasses attribute definition the 
valuesReturnFilter would be ((attributeTypes=2.5.21.6))

to retrieve the complete objectClasses attribute from an entry, you 
dont need the valuesReturnFilter as you want all the values to be 
returned

to retrieve a specific objectClasses attribute value from the 
objectClasses attribute of an entry, the valuesReturnFilter would be
((objectClasses=<the oid of the object class you want to be 
returned>))

>   (objectClasses=2.5.4.0)

Kurt, I am not quite sure what the above filter is meant to be

David

>   (objectClasses=objectclass)  // supported by some servers

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 21 Oct 2000 08:32:09 -0700

At 04:08 PM 10/21/00 +0100, David Chadwick wrote:
>rather than gunk will help the understanding.

I changed (attributeTypes=*'gunk'*) to (attributeTypes=2.5.4.3)
namely because as attribute types has no substrings matching rule,
the name/OID itself doesn't matter.

>Further, since 

Sadily enough, my value may not be the same as yours!  Note
that there are some alterations allowed by the RFC 2252.  In
particular, an implementation is free to recognize alternative
names and to add private experiments (X- terms) to standard
track schema items.

>component). Should we do this? 

You could define another matching rule, but the practice is actually
to overload the existing equality matching rule.  Given that we
overload NAMEs/OIDs most everywhere else, it seems natural to me to
overload it here as well.

>valuesReturnFilter would be ((attributeTypes=2.5.21.6))

I meant an example to retreive an specific objectClasses
value, e.g. ((objectClasses=1.2.3.4)), would be nice to include.

>Kurt, I am not quite sure what the above filter is meant to be

It should be ((objectClasses=2.5.4.0))... match the objectClasses
value with OID 2.5.4.0.

---

From: "David A. Cahlander" <[email-masked]>
Date: Sat, 21 Oct 2000 11:57:08 -0500

I think that I now understand your answer to the question about the
operation
of example (2).  The attribute filter:

    ((attributeTypes=1.2.3.4.5))

should return the same results as

    ((attributeTypes=gunk))

since the right hand side of the "attributeTypes=" needs to go through
some string to OID conversion.  This conversion would return the same
results for both filter values.

In particular, this produces a very useful operation for a client.

The user creates an LDAP search operation with a baseObject set to
cn=subschema subentry, o=myorg, a scope of base, a filter set to
(objectClass=subschema), the list of attributes to be returned set to
"objectClasses", and the ValuesReturnFilter set to
((objectClasses=inetOrgPerson))

The search result returned by the server would consist of the
following entry:

dn: cn=subschema subentry, o=myorg
objectClasses: ( 2.16.840.1.113730.3.2.2
    NAME 'inetOrgPerson'
    SUP organizationalPerson
    STRUCTURAL
    MAY (
        audio $ businessCategory $ carLicense $ departmentNumber $
        displayName $ employeeNumber $ employeeType $ givenName $
        homePhone $ homePostalAddress $ initials $ jpegPhoto $
        labeledURI $ mail $ manager $ mobile $ o $ pager $
        photo $ roomNumber $ secretary $ uid $ userCertificate $
        x500uniqueIdentifier $ preferredLanguage $
        userSMIMECertificate $ userPKCS12
    )
)

Thanks.
---
David Cahlander [email-masked]  651-415-3171

---

From: "David Chadwick" <[email-masked]>
Date: Sat, 21 Oct 2000 19:58:33 +0100

Send reply to:  	"David A. Cahlander" <[email-masked]>
From:           	"David A. Cahlander" <[email-masked]>

> operation of example (2).  The attribute filter:
> 

I also now see where you are coming from, and I agree that it is an 
improvement to the ID to add the facility for the user to present the 
string of the schema element rather than its OID.

This does require a change somewhere in the LDAP specs to say 
that schema names and OIDs can be used interchangably in the 
protocol. I am not sure where this change should go, but will ask 
Mark to comment on this.

Were you wanting the following example to go into the ID, or are 
you happy with the attribute example being enough

David

>         labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $
>         roomNumber $ secretary $ uid $ userCertificate $

David Chadwick

---

From: "David Chadwick" <[email-masked]>
Date: Sat, 21 Oct 2000 19:58:34 +0100

Date sent:      	Sat, 21 Oct 2000 08:32:09 -0700
To:             	[email-masked]
From:           	"Kurt D. Zeilenga" <[email-masked]>

> names and to add private experiments (X- terms) to standard

Clearly a private implementation can do what the heck it likes, but 
that does not mean that we should support or condone it. I can build 
an IP intranet using your IP addresses if I want, but I would not 
expect the Internet to support me when I tried to connect into it. 
Consequently we should not provide any hooks for private 
directories that take standard schema definitions/OIDs and add 
their own bits to it. And I am including here MS and Netscape who I 
believe have both altered the definition of oc top - in different ways 
of course - whilst keeping the X.500 oid.

Thus we should be stating somewhere that if an implementation 
uses a standard OID then it MUST use the standard definition to go 
along with it. As there is no shortage of OIDs that I am aware, they 
can redine standard schema elements to their heart's content, as 
long as they use private OIDs for their new definitions.

> >Then we need to formally specify a stringThirdComponent matching rule
> >as an equality matching rule for attributeTypes, if we are to widely
> >support this. (Note this is counting NAME as the second component).
> >Should we do this? 
> 

I agree, providing that somewhere it is clearly specified that OIDs 
and string names are freely interchangeable and implementation 
MUST support this. Should this be sent to the bis list?

> It should be ((objectClasses=2.5.4.0))... match the objectClasses

there wont be any, as all of 2.5.4 are reserved for attribute types. 
This is why I was confused by your example. X.500 OCs all start 
with 2.5.6

David

David Chadwick

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 21 Oct 2000 13:28:06 -0700

At 07:58 PM 10/21/00 +0100, David Chadwick wrote:
[trimmed]
>their own bits to it. 

RFC 2252 only allows limited alternation by implementations.

In particular, it allows for implementation to recognize
attribute types by alternative names.  This allows a server
to recognize 'commonName' as a alternative to 'cn'.  This
allows a  server to provide compatibility to clients which
don't yet use standard track names WITHOUT breaking clients 
adhering to the specification.  This is good.

I believe the schema description extension mechanism is
provided to support extension of the underlying ASN.1.
RFC 2251 says that implementations must ignore elements of
SEQUENCE encodings whose tags they do not recognize.  LDAP
schema descriptions are string representations of SEQUENCE
elements.  It's my belief that the extension mechanism is
provided so that the string representation can adapt to
future changes in to the SEQUENCE.  This is good.

To support such change, RFC 2252 allows for various schema
descriptions formats to be updated.  It hoped that such changes,
if necessary, can be made in manner which provides both forward
and backwards compatibility.  Regrettably, the extension
mechanism for standard track extensions doesn't provide the
same compatibility as the private extensions mechanism does
(because standard track extensions term are not restricted
to being followed by <qdstrings>).  (LDAPbis might want to
consider adding such a restriction).

>along with it.

Today's spec or tomorrow's?  I believe we need to provide
means for updating the specification in a manner which
provides forward and backwards compatibility.  I believe
the schema extensions mechanisms and allowed variences are
designed to, and when used appropriately, improve
interoperability.

I also support mechanisms designed to allow private
experimentation in manner which doesn't break implementations
which conform to the standard track specification.  There
are a number of such extensions which I hope will eventually
become standard track.  (For example, extensions indicating
which LDAP syntaxes the server allows/requires ;binary transfer
for).

I concur that implementations should not make any change
which are not allowed by the specifications.  There are some
cases where the specifications likely need to be tightened.
In particular, if a server should not return a requested
standard track attribute by a non-standard track names unless
explicitly requested to do so.

>MUST support this.  Should this be sent to the bis list?

I believe so.  I've cc'ed ldapbis in my reply.

>This is why I was confused by your example. X.500 OCs all start 

Sorry for the confusion. 

BTW, I suggest using OID/NAMES from RFC 2252/2256 in examples.
(note that implementations are not required to provide all
schema elements detailed in the "core" specification).

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 21 Oct 2000 14:00:20 -0700

At 07:58 PM 10/21/00 +0100, David Chadwick wrote:
>This [(attributeTypes=desc) matching] does require a change somewhere in the LDAP specs to say 

RFC 2252, 4.1/8.1/8.4 indicate that matching rules should
support "descr" OID forms.  Some clarification here may be
appropriate.

Kurt