[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: DN "published table" opinion
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