Re: Returning Matched Values with LDAPv3

["David Chadwick" <d.w.chadwick@salford.ac.uk>]

Date sent:      	Sat, 21 Oct 2000 08:32:09 -0700
To:             	d.w.chadwick@salford.ac.uk
From:           	"Kurt D. Zeilenga" <Kurt@OpenLDAP.org>

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

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.

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

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?


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

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
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
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

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