Subject: Re: IETF ldapbis WG Last Call: draft-ietf-ldapbis-dn-05.txt

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 18 Jul 2001 10:37:42 -0600

>>> "Kurt D. Zeilenga" <[email-masked]> 05/11/01 02:18PM >>>

>I note that RFC 2253's ABNF required '=' (as well as non-leading '#')
>to be escaped but RFC 2253's Section 2 clearly allows '=' (as well
>as non-leading '#') to used unescaped.  In this I-D, the ABNF was
>made consistent with Section 2 as this is the RECOMMENDED method
>for generating DNs.  The alternative, requiring '=' (as well as
>non-leading '#') to be escaped, would like have rendered many
>existing implementations non-complaint.  It is noted that existing
>implementations generally don't care of '=' (as well as non-leading
>'#') are escaped or not.

Do *all* existing implementations not care whether a non-leading # is escaped or not? I'm curious because we've got a defect logged against us wishing us to enforce the escapement of the # (per RFC2253 BNF). We currently don't like non-leading # char's to be escaped (not yet liberal in what we accept). If we were to apply the fix and follow the 2253 BNF, we're at odds with section 2.4. Assuming the bis DN doc will stay the way it is, we will change our implementation to accept either escaped or unescaped #, =, and space. But I'm wondering how many other implementations will be affected.

One nit about the # character, it is called an octothorpe in section 2.4 and a SHARP or sharp sign in other sections (specifically the BNF).

Jim

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 19 Jul 2001 15:05:54 -0700

At 07:37 AM 7/18/2001, Jim Sermersheim wrote:
>Do *all* existing implementations not care whether a non-leading # is escaped or not?

I'd hate to say *all*, but am under the impression that most don't
care as most are fairly liberal in what they accept.  That could be
a false impression.  I suggest we leave the I-D as is for now and
what we find in doing the Implementation Report.

>One nit about the # character, it is called an octothorpe in section 2.4 and a SHARP or sharp sign in other sections (specifically the BNF).

We clean that up as an editorial change.