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

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

Date sent:      	Sat, 21 Oct 2000 13:28:06 -0700
To:             	d.w.chadwick@salford.ac.uk
From:           	"Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject:        	attributeTypes value variences (Was: Returning Matched Values
 	with LDAPv3)
Copies to:      	ietf-ldapext@netscape.com, ietf-ldapbis@OpenLDAP.org
Priority:       	non-urgent

Kurt
Apologies for the delay, but the message got dumped into my 
LDAPbis folder not my LDAPExt one. (Unfortunately mail clients are 
not intelligent enough to put one copy into each folder instead of 
both into the first one that meets a filtering rule.)


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

agreed. Except there is no real mechanism for creating standard 
track names, is there? Unless this simply refers to every schema 
element published in a standards track RFC.

> 
> I believe the schema description extension mechanism is
> provided to support extension of the underlying ASN.1.

I dont believe so. This has been discussed before by the X.500 
group but no concesus was reached for allowing it. THe current 
standard assumes that if you change a schema definition, you 
allocate a new OID to it, and when you want to phase the old one 
out you mark it obselete (which is allowed for in the definition)

> RFC 2251 says that implementations must ignore elements of
> SEQUENCE encodings whose tags they do not recognize. 

This extension mechanism, which came from DAP, was purely to 
allow extensions to the protocol, but not to the schema. LDAP 
adopted this with its controls mechanism.

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

For protocol only. It is an extension of the extensions mechanism, to 
use it for schema descriptions. I have not heard this discussed 
before.

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

There are two views here. If tomorrows spec uses new OIDs for 
new definitions, then do we use new LDAP strings to represent this, 
or do we continue using the old LDAP strings, in which case your 
question above would be valid.

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

We can define new rules for ways to extend schema, I dont 
remember anyone specifying these before, which is part of the 
reason for the current confusion.

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

Controls are a perfect mechanism for this. This is what they were 
designed for. And the logic here is "if you understand this, go for it, 
else ignore it (unless I have marked it critical)." But what is the logic 
behind " here is a schema id, I think it means one thing, you might 
think it means something different, heck, I dont know what it 
actually means anymore as it has been redefined so many times"
(Only joking, but you get the point)

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

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