RE: DN "published table" opinion

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

At 10:24 PM 2/23/01 -0800, Kurt D. Zeilenga wrote:
>At 02:25 PM 2/23/01 -0600, Ryan Moats wrote:
>>As I read this, I see what you are opposing, but what are you
>>proposing in its place?
>I do hope to offer a proposal for discussion by IETF#50.

In a recent post, I discussed my concern that the document needs
to provide an unambiguous string representation of a DN.
The DN TS's "published" table approach clearly solves this
problem.

The proposal I was considering was to require (MUST) names in
the TS's table to used, but also allow (MAY) names in an IANA
maintained table.  This would continue to provide an unambiguous
string representation, but I have three significant concerns with
this approach:
        1) doesn't allow "local" tables (and hence doesn't
          address the problem you raised),
        2) raised interoperability concerns, and
        3) appropriateness under our charter.

In particular, I was quite concerned with interoperability
issues.  The key here is not what string type names an
implementation may use in generating the DN string
representation, but how an implementation determines what
string type names its protocol peer recognizes.  For
interoperability sake, an implementation would be forced
to restrict itself to the TS defined table unless it had
some prior knowledge that the peer accepted other names
[which is same assurances offered to those taking
liberties with the current published table approach].

I am also quite concerned regarding the appropriateness of
redesigning a well-engineered DN TS (RFC 2253) due to
liberties taken by various implementations.  I personally
find it difficult to justify changes to the TS to accommodate
what I believe are non-conformant implementations
(even though I myself maintain one such implementation).
I especially have difficulty when the suggested changes
would introduce serious interoperability problems.

Lastly, I was concerned that this approach does not appear
to actually resolve the issue you raised.

So, my current (continuing) proposal is to rely on the
general IETF implementation guideline that says (paraphrased)
"implementation may be liberal in what they accept" (meaning
they may accept names not listed in the table) and
"implementations should be strict in what they produce"
(meaning they should only use names which are listed in the
table).  That is, I believe that no actual change to the TS
should be made to allow generation of DN of attribute type
names other than those in the published table nor require
implementations to recognize any name not in the published
table.

If anyone has an alternative approach to offer, please do.

However, before we undertake any substantive change to
the DN string TS, we should be sure that the circumstances
dictate such changes be made.  I am not convinced, but I
remain open to further discussion of this issue.

Kurt