Subject: Question on Your Comment

From: Kathy Dally <[email-masked]>
Date: Tue, 13 Nov 2001 15:37:47 -0500

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.

Regards,
Kathy Dally

---

From: "Steven Legg" <[email-masked]>
Date: Wed, 14 Nov 2001 16:18:28 +1100

Kathy,

Kathy Dally wrote:
> have I missed?

I was speaking in a general sense that servers should not be required
to exactly duplicate the NAME, DESC and OBSOLETE fields as they appear
in the source definition.

> I'm concerned, too, about extending the 
> statement to the

Removing the name isn't normally a prudent thing to do but it may be
necessary if a subschema has to contain two distinct definitions using
the same name.

Also, being able to put in additional localized names isn't a bad thing.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 14 Nov 2001 09:07:11 -0800

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

---

From: Kathy Dally <[email-masked]>
Date: Wed, 14 Nov 2001 17:38:47 -0500

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 16 Nov 2001 10:24:13 -0800

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