RE: DN "published table" opinion

["Ryan Moats" <rmoats@coreon.net>]

Tim-

As you can see from the archives, I was pushing for additional
attributes.  I see the additional statement as a compromise in the
name of making progress.  If you can solve Kurt's ambiguity
problems for additional attributes, I'd be interested in
hearing the solution.

Ryan

-----Original Message-----
From: owner-ietf-ldapbis@OpenLDAP.org
[mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Timothy Hahn
Sent: Monday, March 12, 2001 11:06 AM
To: rmoats@coreon.net
Cc: Kurt D. Zeilenga; ietf-ldapbis@OpenLDAP.org
Subject: RE: DN "published table" opinion



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