[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Returning Matched Values with LDAPv3
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
***************************************************