Re: Question on Your Comment

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

X.511(93), 14.7 says:
   A number of subschema policy operational attributes defined
   in the following clauses contain an obsolete component.  This
   component is used to indicate whether the definition is active
   or obsolete in the subschema administrative area.

Hence, I suggest you paraphrase this for 2252bis:
   The OBSOLETE term is used to indicate whether the definition
   is active or obsolete in the subschema.  Only active
   definitions regulate the directory [X.511].

Kurt


At 02:38 PM 2001-11-14, Kathy Dally wrote:
>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).