[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

David,

> -----Original Message-----
> From: owner-ietf-ldapbis@OpenLDAP.org
> [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of David Chadwick
> Sent: Sunday, 29 October 2000 2:38
> To: Kurt D. Zeilenga
> Cc: ietf-ldapbis@OpenLDAP.org
> Subject: Re: attributeTypes value variences (Was: Returning Matched
> Values with LDAPv3)
> 
> 
> 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

[snip]
 
> > 
> > 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)

I'm not sure you and Kurt are talking about the same thing. I believe
Kurt was talking about extensions to the syntax of an attribute type,
and in particular the syntaxes of the schema operational attributes,
rather than more general changes to the schema definitions of already
defined schema elements (attribute types, object classes, name forms,
etc). So for example, the discussion is about "what if an extra field
is added to the AttributeTypeDescription ASN.1 type" instead of "what
if the equality matching rule for commonName is changed to
caseExactMatch".
 
> 
> > 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.

The ASN.1 type extension mechanism has been used in X.500 to extend
existing attribute syntaxes without the allocation of new OIDS.
The obvious example is the DistinguishedName syntax which is different
in X.500:2000 compared to X.500:1993, however I don't see new attribute
type definitions to replace seeAlso, member, etc. Backward compatible
extensions to attribute syntaxes obviously can be, and have been,
accommodated.

An example of an extension that fits what I think Kurt was allowing for
would be a new OBJECT IDENTIFIER component added to the
AttributeTypeDescription ASN.1 type to hold the LDAP syntax OID.
Would we really want to deprecate the attributeTypes operational
attribute and define a new attributeTypesV2 attribute to hold the
revised definition of AttributeTypeDescription ? And if such a field
is added to the ATTRIBUTE information object as well does this
mean we have to replace most of the existing attribute types
because they are now technically different ?

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

One of the advantages of having an algorithmic relationship between
the LDAP string encoding and the ASN.1 type (like the generic string
encoding rules I've defined in draft-legg-ldapext-component-matching)
is that every one knows what the new LDAP string encoding is, whether it
is the old syntax extended or a new syntax to replace the old, just by
looking at the new ASN.1 type definition.

Regards,
Steven

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