Subject: Re: DN revision

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 18 Apr 2001 00:06:05 -0600

I agree with this. When a client asks to "read" (base scope, objectclass=* filter) an object, a server is now free to return a DN that looks like the DN originally passed to it.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 4/17/01 1:48:14 AM >>>
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.

Comments?