Subject: Returning name or oid of search attributes

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 05 Dec 2002 16:43:29 -0700

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). In fact, much of 4.1.4 is missing.

2) Does this MUST apply even when the client asked for the attribute by OID? This seems unreasonable.

Jim

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 05 Dec 2002 19:06:41 -0800

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?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 05 Dec 2002 19:37:29 -0800

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

RFC 2252 contained the statement:
   When encoding 'oid' elements in a value, the descr encoding option
   SHOULD be used in preference to the numericoid. An object descriptor
   is a more readable alias for a number OBJECT IDENTIFIER, and these
   (where assigned and known by the implementation) SHOULD be used in
   preference to numeric oids to the greatest extent possible.  Examples
   of object descriptors in LDAP are attribute type, object class and
   matching rule names.

One could argue that despite the first sentence saying "in a value",
that this paragraph applies to all <descr> encodings, especially
given the examples and the phrase "greatest extent possible".

>2) Does this MUST apply even when the client asked for the attribute by OID?

I think its RECOMMENDED that clients use short names.  If they
don't, then it follows that they should be prepared to handle
either short names or OIDs.

>This seems unreasonable.

I think the MUST is unreasonable.  There are likely cases (such
as when the server knows multiple attributes in separate entries
of a search result set share the same short name) where returning
a numericoid is better than returning a short name.  That is,
the MUST may actually disallow servers from preventing
misinterpretation of short names.  This is not only an interop
issue, but likely a security consideration.

So, my suggestion to resolving this issue is to simply delete
"in a value" from:
  The <descr> form is preferred.  When a production <oid> is encoded
  in a value, the <descr> encoding option SHOULD be used instead of
  the <numericoid> encoding option.

This could be echoed in section 6.2.

We should also note not only change by the reasons for the change
in either [Models] or [Protocol].

I also think it is important that we treat all short names,
regardless of whether they refer to an attribute type, object
class, or other schema/protocol, element the same.  I find it
odd that RFC 2251 only placed this MUST on attribute type
short names/OIDs.

Kurt