Subject: RE: DN "published table" opinion

From: "Timothy Hahn" <[email-masked]>
Date: Mon, 12 Mar 2001 12:05:35 -0500

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: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

Sent by:        [email-masked]
To:     "Kurt D. Zeilenga" <[email-masked]>
cc:     [email-masked] 
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

---

From: "Ryan Moats" <[email-masked]>
Date: Mon, 12 Mar 2001 13:27:16 -0600

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Timothy Hahn
Sent: Monday, March 12, 2001 11:06 AM
To: [email-masked]
Cc: Kurt D. Zeilenga; [email-masked]
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.

Regards,
Tim Hahn

cannot
actually
AttributeType

Ryan