attributeTypes value variences (Was: Returning Matched Values with LDAPv3)

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

At 07:58 PM 10/21/00 +0100, David Chadwick wrote:
[trimmed]
>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. 

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


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

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.

>> >> 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 believe so.  I've cc'ed ldapbis in my reply.


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

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