Re: Returning Matched Values with LDAPv3

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 04:08 PM 10/21/00 +0100, David Chadwick wrote:
>From:                   "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
>
>> At 01:44 PM 10/17/00 -0500, david.a.cahlander@syntegra.com 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'*)
>> 
>> 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. 
>
>Kurt, I dont understand why changing the example to retrieve cn 
>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 
>everyone already knows the definition of cn, one might ask why are 
>we wanting to retrieve this definition!

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.

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

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.

>> >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.
>> 
>> You need an LDAP extension to return only the matched values.
>> 
>> >An example to retrieve an "objectClasses" attribute would help.
>
>to retrieve the objectClasses attribute definition the 
>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.

>>   (objectClasses=2.5.4.0)
>
>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.