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

Re: DN-alt issues

At 03:46 AM 2002-08-25, Scott Seligman wrote:
>"Kurt D. Zeilenga" <Kurt@OpenLDAP.org> writes:
>> At 10:24 AM 2002-08-21, Mark C Smith wrote:
>>> That is, some implementations such as the Netscape Directory Server
>>> will generate (send) DN strings that use attribute type names that
>>> are not listed in the table...
>> draft-ietf-ldapbis-dn doesn't prohibit this behavior.
>The draft requires some editing to clarify this point.

How about if the Section 2 paragraph:
  The following sections define the RECOMMENDED algorithm for
  converting from an ASN.1 structured representation to a UTF-8
  [RFC2279] string representation. 

were followed by:
  Other documents may describe other algorithms for converting a
  distinguished name to a string, but only strings which conform
  to the grammar defined in Section 3 SHOULD be produced by
  LDAP implementations.

SHOULD here for consistency with Section 3 requirements.

This would not only clarify that other algorithms may be
documented, but also clarify that those algorithms are
restricted to the Section 3 grammar.

I see no reason to single out additional short names.  Other
algorithms may differ from the recommended algorithm in a
number of ways.  We don't need to enumerate all the differences
which are allowed, we need state which differences are not
allowed.

>Second, Netscape is not the only server to do this.  Adding a
>"SHOULD NOT" restriction against a common (majority?) practice seems
>like it may be taking things too far for a BIS update.

RFC 2026: 
   Implementors should treat Proposed Standards as immature     
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.
   However, since the content of Proposed Standards may be changed if
   problems are found or better solutions are identified, deploying
   implementations of such standards into a disruption-sensitive
   environment is not recommended.

>Note that I'm not questioning the existence of interoperability issues
>relating to attribute type string names, and I do support the draft
>giving clear guidance on this.

Noted.

Kurt