Subject: DN "Relationship with LDAPv2 and RFC1779" Removal

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Dec 2000 19:49:36 -0800

As previously noted, I have removed the "Relationship with LDAPv2
and RFC1779" section and references to it from the DN revision I-D
as this section only appears relevant if parsing DNs generated by
an LDAPv2 client.

My interpretation assumes:
 - An LDAPv2 client talks LDAPv2 (RFC1777) to a LDAPv2 server
 - An LDAPv3 client talks LDAPv3 (RFC2251) to a LDAPv3 server
 - There may be implementations which support both
 LDAPv2 and LDAPv3 but use one or the other when talking
 with a particular peer.
 - RFC2253 obsoletes RFC1779
 - RFC2253 has no normative reference to RFC1779

Section 3 says:
  Server implementations parsing a DN string generated by an LDAPv2
  client MUST also accept (and ignore) the variants given in section 4
  of this document.

As an LDAPv3 server is never faced with parsing a DN string
generated by an LDAPv2 client, no LDAPv3 server is required
to accept (and ignore) the variants given in section 4.

As an LDAPv2 server is required by RFC 1777/1779 to parse
DNs generated by LDAPv2 clients and RFC 2253 (with or without
these variants) is more restrictive syntax than RFC 1779,
the requirement is redundant.

When I apply the my assumptions to the remainder of the RFC 2253,
including the grammar, comments within the grammar, and Section 4
itself, I arrives at a consistent interpretation that Section
4 does not place restrictions upon LDAPv3 implementations.

If there other interpretations of LDAPv2/RFC1779 relationship,
I would be quite interested in how such interpretations are
arrived at.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Dec 2000 23:42:33 -0800

Playing devil's advocate...

>  client MUST also accept (and ignore) the variants given in section 4

Assume:
   The syntax given in this document is more restrictive than the syntax
   in RFC 1779.  Implementations parsing a string generated by an LDAPv2
   client MUST accept the syntax of RFC 1779.  Implementations MUST NOT,
   however, generate any of the RFC 1779 encodings which are not
   described above in section 2.

was meant to be interpreted as saying:

   Implementations MUST accept the syntax of RFC 1779 but MUST generate
   DNs per section 2.

As all the additional variants with the section are required by the
RFC 1799 syntax, the rest of section 4 is redundant.  Given this,
one can replace all of section 4 by refining the section 3 statement:

   "Server implementations parsing a DN string generated by an LDAPv2
   client MUST also accept (and ignore) the variants given in section
   4 of this document."

to read:

   "All implementations MUST also accept the syntax of RFC 1779 but
   MUST generate DNs per section 2."

Now, as we cannot have a normative reference to RFC 1779, we need to
incorporate all the variants of RFC 1779's syntax into the Section 3
grammar.... and at this point we might as well drop "MUST generate
DNs per section 2" requirement.

However, I was under the impression that the more restrictive
syntax was introduced to ease the encoding and decoding of the DN
string.  It seems to me that the interpretation that all implementations
must parse RFC 1779 syntax is not consistent with the introduction of
the more restrictive syntax.

It also seems very odd to me that RFC 2253 appears to place different
requirements upon LDAPv3 servers than LDAPv2 clients.  I believe this
is inconsistent with the interpretation that all implementations must
parse RFC 1779 syntax (as well as just not making much sense).

The only reasonable explanation I can come up with is that RFC2253
requires dual server implementations to support the RFC 1779 syntax when
using LDAPv2 and the more restrictive RFC 2253 syntax when using LDAPv3
and just didn't consider the dual client implementations.

MarkW, do you have any insight how the Section 4 was intended to be
interpeted?