"Kurt D. Zeilenga" <Kurt@OpenLDAP.org> Sent by: owner-ietf-ldapbis@OpenLDAP.org
04/17/2001 03:48 AM
To: "Jim Sermersheim" <jimse@novell.com>
cc: <ietf-ldapbis@OpenLDAP.org>
Subject: Re: DN revision
At 12:43 AM 4/17/01 -0600, Jim Sermersheim wrote:
><sorry> Can you restate the problem(s) that we bring on ourselves by allowing servers to generate other names?
First, s/servers/implementations/. The issues and requirements
apply to all protocol peers.
By allowing implementations to generate other DN forms (then
described in section 2), one is effectively mandating that all
other implementations recognize these forms. The question
should not be "what MAY implementations generate?", but "what
MUST implementations recognize?".
That is, while implementations MAY be liberal in what they
accept, they SHOULD be strict in what they produce and they
SHOULD not expect others to offer any particular liberty.
While I personally believe last SHOULD to be a MUST, but I
think I could live with a SHOULD if we state why the
requirement is present. Hence, I suggest replacing the
paragraph in section 3 with:
Implementations MUST recognize AttributeType string type names
(keywords) listed in the Section 2 table, but MAY recognize
other names. Implementations MAY recognize other DN string
representations (such as that described in RFC 1779). As there
is no requirement for other names or alternative DN string
representations be recognized, implementations SHOULD only
generate DN strings in accordance with Section 2 of this document.
In addition, security considerations related to the use of other
names and/or alternative DN string representations should be
detailed.