Re: DN revision

["Jim Sermersheim" <jimse@novell.com>]

I kind of thought this was what was argued against in Minneapolis. My feeling is that this will automatically break many existing implementations, and at best will cause server implementations to incorporate some kind of 'switch' that will be flipped on when performing interoperability tests and off otherwise. 

Unfortunately, many users of commonly found LDAP directories often name entries with textual names not found in the Section 2 table. My guess is that if you poll client implementors, you'll find lots of objections.

The purist in me says: "Yeah, right on, that's a great move", but the pragmatist says: "Danger danger Will Robinson". Unfortunately, I'd rather we word it such that: 

"...Implementations MAY recognize other DN string
representations (such as that described in RFC 1779) but SHOULD only
generate DN strings in accordance with Section 2 of this document, but 
MAY recognize other DN string representations..."

<sorry> Can you restate the problem(s) that we bring on ourselves by allowing servers to generate other names?

Jim

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 4/2/01 11:51:47 AM >>>
This revision incorporates language to codify a "be liberal
in what you accept, be strict in what you produce" requirement
as discussed prior to and at IETF#50.  In particular, the
following paragraph was added to Section 3 of the I-D:

  Implementations MUST recognize AttributeType string type names
  (keywords) listed in the Section 2 table, but MAY recognize other
  names (keywords).  Implementations MAY recognize other DN string
  representations (such as that described in RFC 1779) but SHALL only
  generate DN strings in accordance with Section 2 of this document.

Does the addition of this paragraph, specifically the first
sentence, adequately address concerns resulting from the previous
Section 2 clarification of "a published table" to be the table
published in Section 2?  If no, what sort of change do you believe
is necessary? (specific suggestions welcomed)

Does the addition of this paragraph, specifically the second
sentence, adequately address concerns resulting from the previous
removal of the "Relationship to LDAPv2 and RFC 1779" section?
If no, what sort of change do you believe is necessary? (specific
suggestions welcomed)

I note that at IETF#50, there was agreement to form an engineering
team to produce recommendation(s) on how to resolve the significant
outstanding issues with this I-D.  That's still the plan.  Your
answers to the above questions is meant as input to this engineering
team.

Regards, Kurt