Re: Returning name or oid of search attributes

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

At 03:43 PM 2002-12-05, Jim Sermersheim wrote:
>Two issues:
>
>1) Neither [Protocol] nor [Models] contains Paragraph 4 or Section 4.1.4 in RFC 2251.  If a server knows the name of an attribute it MUST return the name instead of the OID in search results).

I'll cover this in a separate message.

>In fact, much of 4.1.4 is missing.

RFC 2251:
>4.1.4. Attribute Type
>        
>   An AttributeType takes on as its value the textual string associated
>   with that AttributeType in its specification.
>
>        AttributeType ::= LDAPString

Covered by [Protocol, 4.1.4] with reference to [Models, 2.5].

>   Each attribute type has a unique OBJECT IDENTIFIER which has been
>   assigned to it.

Covered by [Models, 2.5.2]:
    Each attribute type is identified by an object identifier (OID)
    and, optionally, one or more short names known as descriptors.

>   This identifier may be written as decimal digits
>   with components separated by periods, e.g. "2.5.4.10".

Covered by [Models, 1.3]:
    Object identifiers are represented in LDAP using a dot-decimal      
    format conforming to the ABNF:
         numericoid = number *( DOT number )


>   A specification may also assign one or more textual names for an 
>   attribute type.

Covered by [Models, 2.5.2]:
    Each attribute type is identified by an object identifier (OID)
    and, optionally, one or more short names known as descriptors.

>   These names MUST begin with a letter, and only
>   contain ASCII letters, digit characters and hyphens.  They are case
>   insensitive.  (These ASCII characters are identical to ISO 10646
>   characters whose UTF-8 encoding is a single byte between 0x00 and
>   0x7F.)

Covered by [Models, 1.3]:
     Descriptors are case insensitive and conform to the ABNF:
        descr = keystring

>   If the server has a textual name for an attribute type, it MUST use a
>   textual name for attributes returned in search results.   The dotted- 
>   decimal OBJECT IDENTIFIER is only used if there is no textual name
>   for an attribute type.

As noted above, I'll cover this in a separate message.

>   Attribute type textual names are non-unique, as two different
>   specifications (neither in standards track RFCs) may choose the same
>   name.

Covered in [Models, 6.2].

>   A server which masters or shadows entries SHOULD list all the
>   attribute types it supports in the subschema entries, using the
>   attributeTypes attribute.

Covered in [Models, 4.2].  But, I'd like to also change last
paragraph of 7.2 to read:
  Servers MAY implement additional schema elements.  Servers SHOULD
  provide the definitions of all schema elements they support in
  subschema (sub)entries.

(this will cover another issue noted below)

>   Servers which support an open-ended set of
>   attributes SHOULD include at least the attributeTypes value for the
>   'objectClass' attribute.

Since there is a general SHOULD for publishing attributeTypes, this
SHOULD is redundant.

>   Clients MAY retrieve the attributeTypes
>   value from subschema entries in order to obtain the OBJECT IDENTIFIER
>   and other information associated with attribute types.

Covered in [Models, 4.4].

>   Some attribute type names which are used in this version of LDAP are
>   described in [5].

I think this is covered by [Roadmap] and various other statements
as to where attribute types are defined.

>        Servers may implement additional attribute types.

This would be made clear by the "schema elements" clarification
suggested above.

So, aside from the one issue I skipped, I'm thinking only one
clarification is needed. Comments?