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

Re: Question on Your Comment



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