DN-alt issues

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

I've been thinking through the alternative DN approach.
Basically, I've tried to find a way to rework the Section
2.3 table restriction such that any registered descriptor
could be used.  I, however, haven't found a way to do so
without creating future interoperability problems,
causing breakage of existing implementations, or other
problems.

Maybe somebody else can.  I'd be happy to assist anyone
who is willing and able to author an alternative approach.

The current I-D says:
  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, the current I-D allows other descriptors to be used
in DNs.

Unless we state that only registered descriptors can be
used in DNs and any descriptor not known to be registered by
an implementation is to be treated as unrecognized, we won't
gain anything.  And even if we adopt these restrictions,
we'd still have to recommend against use of descriptors
not in the 2.3 table as an implementation cannot assume that
all other implementations will recognize other descriptors
(registered or not).

Basically, changing "other names are not recommended" to
"registered names are not recommended" does not buy us anything.
We'd still have to recommend against use of any name not
in the 2.3 table to prevent interoperability problems.

So, I think we need to go back and study why the change
is desired its proponents to see if there is another way
to address the issue they raise.  In reviewing past discussions, 
I find that proponents of the change raise user interface
(presentation) issues, not protocol issues.

The RFC 2253 DN representation, unlike the one provided by
RFC 1779, is not intended to be presented to users without
translation.  RFC 2253 describes the on-the-wire representation
of a DN.

It's my personal opinion that these presentation issues, while
interesting, shouldn't be resolved by changing the on-the-wire
representation.  This would only cause interoperability problems.
The presentation issues should be resolved above the protocol,
by a presentation layer.

I do, however, believe some clarifications to the current
I-D are needed.  In particular, the I-D should clearly state
that the table is not extensible. 

It might also be appropriate to discuss the most basic of
presentation of RFC 2253 DN issues (because, like it or not,
some users (especially admins) have to deal with DN strings
at times).  Basically, the I-D should say that where DN strings
are presented to users, they are to be treated as an identifier
(like a URI) and not mucked with.

I also have a one or two unrelated clarifications which I
like the WG to consider (to resolve issues which only recently
came to my attention).  I summarize these in a separate thread.

Kurt