RE: DN "published table" opinion

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

At 11:53 AM 3/10/01 -0500, rmoats@coreon.net wrote:
>I think I can live with this as a compromise to make progress.

Me, too!

>However, I disagree that this position means no change
>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
>not allow implementations to accept strings that aren't
>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
>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.

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 
>level should be MAY or SHOULD and I'm open to discussion.

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.

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

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.