RE: DN "published table" opinion

["Timothy Hahn" <hahnt@us.ibm.com>]

Ryan and Kurt,

I agree with the direction of being liberal in what we expect and strict in what we emit.

Unfortunately, doing so still has compatibility issues, I fear.

I don't see another alternative, but the inclusion of the "MUST" regarding what the server emits is going to cause implementers (and exploiters) alot of "pain".

Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

Sent by:        owner-ietf-ldapbis@OpenLDAP.org

To:        "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
cc:        ietf-ldapbis@OpenLDAP.org
Subject:        RE: DN "published table" opinion



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

This covers my concerns quite nicely.  Thanks Kurt.

Ryan