RE: DN "published table" opinion

[<rmoats@coreon.net>]

Thoughts in line, Ryan

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

I think I can live with this as a compromise to make progress.

However, I disagree that this position means no change
to the TS. My reading of -01 is that it does
not allow implementations to accept strings that aren't
in the table.  So, I'd like a statement of
the type "Implementations MAY/SHOULD accept an AttributeType
string that is not in the table in lieu of OIDs" to actually 
codify this "be liberal" approach.  I don't know if the 
level should be MAY or SHOULD and I'm open to discussion.
If somebody can point out text that allows implementations
to "be liberal," that would be great, but in the interim,
I'm going to push something specific to make this clear.

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