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

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