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

Re: DN-alt issues

At 07:04 AM 2002-08-21, Mark C Smith wrote:
>RL 'Bob' Morgan wrote:
>
>>If the "published table" had been well-established and had actually been
>>extended since 2252 was published, then we wouldn't be talking about
>>changing its nature.  But it's the lack of clarity on what the table is in
>>the first place that's the reason we're discussing it.  Deciding that a
>>table that in practice has never been extended is now by definition
>>non-extensible is within scope, in my opinion.
>
>I agree, but we could also agree on a new definition for the table. Our goal is clarity and interoperability, but we also do not want to retroactively label a lot of LDAP deployments as "non standard" if we do not have to.

draft-ietf-ldapbis-dn causes, to the best of my knowledge, to
become "non standard".

>One  approach would be to say that strings may be used in DNs instead of OIDs for any attribute type that is defined in a document that is part of the LDAP technical standard.

This is already allowed in draft-ietf-ldapbis-dn,
just not recommended (due to interoperability reasons).

  Implementations MUST recognize AttributeType string type names
  (keywords) listed in the Section 2.3 table, but MAY recognize
  other names. Implementations MAY recognize other DN string
  representations (such as that described in RFC 1779). As there
  is no requirement for other names or alternative DN string
  representations to be recognized, implementations SHOULD only
  generate DN strings in accordance with Section 2 of this document. 

That is, "FOO=foo,BAR=bar" is a valid LDAPv3 DN string.
However, this form is not recommended for the reasons
discussed in Section 5.3.

Kurt