Subject: RE: DN "published table" opinion

From: <[email-masked]>
Date: Sat, 10 Mar 2001 11:53:24 -0500

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
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 10 Mar 2001 10:10:52 -0800

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

Me, too!

>to the TS.

Well, my primary objection is to substantive changes.
There is room for a "clarification".

>My reading of -01 is that it does
>in the table.

Like RFC 2253, -01 does not say implementations cannot accept
DNs with other type name strings, it says implementations cannot
generate DN strings with other type names strings.  That is,
there is room to be "liberal in what you accept" but not
"loose in what you generate".

>So, I'd like a statement of
>codify this "be liberal" approach.

How about we add a statement to section 3:
        Implementations MUST recognize AttributeType string
        type names (keywords) listed in the Section 2 table.
        Though implementations MAY recognize other AttributeType
        string type names (keywords), DN conformant to this
        specification MUST be generated as described in
        Section 2.

This codifies the "be liberal in what you accept, be strict
in what you produce" approach.  

>I don't know if the 

I believe MAY is the more appropriate in this case as
SHOULD would actually induce more interoperability problems
than MAY by implying that Section 2 string type name requirement
is not MUST.

>I'm going to push something specific to make this clear.

The fact that Section 3 does not confine the set of keywords
implies implementations are free to recognize names not listed
in the table.  However, a clarification does make this more
clear.