Re: Question on Your Comment

[Kathy Dally <kdally@mitre.org>]

Hi Kurt and Steven!

My conclusion concerning the OBSOLETE field is that a server can return
a value of any of the schema element attributes (e.g., attributeTypes,
nameForms) with the substring "OBSOLETE" included or not without regard
to whether or not the BNF definition of the element includes the word
"OBSOLETE".  

In RFCs 2252 and 2256 (and 2251), this field is not discussed, relying
entirely on the X.500 semantics.  In X.501, an OBSOLETE field is defined
only in the syntaxes of the schema definition operational attributes and
is cannot appear in any "paper" attribute specifications.  LDAPv3,
however, put the OBSOLETE field into the directory object superclass
definition of attributes.  This allows an OBSOLETE field to be defined
in any attribute specification separately from the syntax of the
attribute.  This means that a user attribute type can be written as:

	( 1.2.3.4.5.6 NAME 'newAttr' 
	  OBSOLETE
	  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

In this case, what would OBSOLETE mean in the standard or documentation?

It seems to me that RFC 2252bis should explicitly state that the
OBSOLETE field cannot occur in any written attribute specifications.  It
should also, refer to the X.501 "OBSOLETE mechanism".  Otherwise, I fear
an interoperability problem with LDAP implementations that make some
proprietary use of the OBSOLETE field.

Thanks for your help,
Kathy


"Kurt D. Zeilenga" wrote:
> 
> At 12:37 PM 2001-11-13, Kathy Dally wrote:
> >Hi Steve!
> >
> >In your comments on RFC 2252bis, I do not understand the last one in
> >section 2.1:
> >
> >> >    Servers are not required to provide the same or any text in the
> >> >    description part of the subschema values they maintain.
> >>
> >> The same should apply to the NAME and OBSOLETE fields of all the subschema
> >> operational attribute values. In X.500, the information which is required
> >> to be invariant with respect to an associated object identifier is that
> >> which is given in the ATTRIBUTE, MATCHING-RULE, OBJECT-CLASS and NAME-FORM
> >> information objects. These information objects map into subcomponents of
> >> the AttributeTypeDescription, MatchingRuleDescription,
> >> ObjectClassDescription,
> >> and NameFormDescription ASN.1 types (respectively) with the component
> >> identifier "information". The components of the above ASN.1 types
> >> corresponding to the NAME, DESC and OBSOLETE fields in the LDAP
> >> representation are all outside the "information" component (it just isn't
> >> evident from the BNF).
> >
> >The problem is that the OBSOLETE field does not have any text.  What
> >have I missed?  I'm concerned, too, about extending the statement to the
> >NAME field in the AttributeTypeDescription.  I don't think the server
> >can change the name value arbitrarily because of the necessity for the
> >client to use the name in order to know which attribute is present.
> 
> In general, the necessity is upon the client to discover which
> NAMEs to use retrieving the controlling subschema.   As schema
> and other key information is held in operational attributes,
> LDAP does place the following requirement upon servers:
>    The server MUST be capable of recognizing all the mandatory
>    attribute type names and implement the syntaxes specified in
>    [RFC2252].  Servers MAY also recognize additional attribute
>    type names.  [RFC2251, Section 6.1]
> 
> where RFC2252 says:
>    Servers MUST implement all the attribute types referenced in sections
>    5.1, 5.2 and 5.3.
> 
>    Servers MAY recognize additional names and attributes not listed in
>    this document, and if they do so, MUST publish the definitions of the
>    types in the attributeTypes attribute of their subschema entries.
> 
> However, clients SHOULD discover all other NAMEs.
> 
> That is, I believe Steven is quite correct.  Servers can muck with
> NAME and DESC fields for all attribute types.  But for
> createTimeStamp, modifyTimestamp, creatorsName, modifiersName,
> subschemaSubentry, attributeTypes, objectClasses, matchingRules,
> matchingRuleUse, namingContexts, altServer, supportedExtension,
> supportedControl, supportedSASLMechanisms, supportedLDAPVersion,
> and ldapSyntaxes, the server MUST recognize these attribute
> type by these names (yet MAY recognize them by other names as
> indicated in the controlling subschema).