It's unclear to the reader who has no background with RFC 2253 or earlier why the characters DQUOTE, and SEMI must be escaped, and it's somewhat puzzling why LANGLE and RANGLE must be escaped until one reads Appendix A.
Even after reading Appendix A, I'm not sure why we need to make this provision. Most prose which chooses to distinguish a DN or any other value from the surrounding text can use whatever delimiters it wants and qualify it by stating making the statement "excluding the surrounding <c> characters" (excluding the surrounding " characters, and replacing <c> with the character(s) they have chosen). Is the whole point of escaping LANGLE and RANGLE just so we can avoid putting such statements into prose?
Anyway, I diverge. I agree we can't remove DQUOTE (or even SEMI) as escaped characters in order to support existing clients, but I think some historical note should be added which addresses DQUOTE and SEMI to avoid future head scratching.
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 10/18/04 11:06:18 PM >>>
At 09:15 PM 10/18/2004, Ramsay, Ron wrote:
>Nothing to do with 'C'. The quoting in RFC 2254 uses '\'.
>That "Section 2 of RFC 2253 says the RDN is written: ..." is actually the *point* of the thread!
I think the point of this thread is that, regardless of why,
both [LDAPDN] and [RFC2253] require double quotes in
distinguished values to be escaped and lifting that requirement
in [LDAPDN] would be problematic. It would hinder implementation
support for alternative representations and hence simple
presentation in prose, but that pales into comparison to the
interoperability problems that lifting the requirement would
>So, you want to add \" to the ABNF so that you will able to 'quote' DN's in your email?
No, I am saying that "cn=RL \"Bob\" Morgan" is clearly a
presentation of the DN string:
cn=RL \"Bob\" Morgan
cn=RL "Bob" Morgan
because the latter is invalid per RFC 2253 (and [LDAPDN]).
If one were to remove the " escaping requirement, then
its not clear which DN string is being presented.
>From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>Sent: Tuesday, 19 October 2004 13:05
>To: Ramsay, Ron
>Subject: RE: Quoted values in string DN
>At 06:39 PM 10/18/2004, Ramsay, Ron wrote:
>>"cn=RL \"Bob\" Morgan,dc=example,dc=com" is not an escaping *within* DNs. In fact, if you pre-escape the quotes in the DN, you would probably have to write "cn=RL \\\"Bob\\\" Morgan,dc=example,dc=com"
>maybe in C or other programming language, but I was talking
>in English prose (such as in an email message like this):
>If the distinguished value of the cn naming attribute is
> RL "Bob" Morgan
>then Section 2 of RFC 2253 says the RDN is written:
> cn=RL \"Bob\" Morgan
>>so I don't see that it helps!
>Because one quote the (R)DN string in prose, e.g.
>"cn=RL \"Bob\" Morgan", without ambiguity as to where
>that string starts and stops.
>> [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga
>>Sent: Tuesday, 19 October 2004 03:57
>>To: Jim Sermersheim
>>Cc: ietf-ldapbis@OpenLDAP.org ; Ravi Kiran Jayanthi; Tom Doman;
>>Subject: Re: Quoted values in string DN
>>At 09:52 AM 10/18/2004, Jim Sermersheim wrote:
>>>I'm told that the VSLDAP test suite requires that v3 servers parse DN values containing quoted values.
>>>I know the string dn bis document removed Section 4 from RFC 2253. Justification is given in < http://www.openldap.org/lists/ietf-ldapbis/200012/msg00065.html > http://www.openldap.org/lists/ietf-ldapbis/200012/msg00065.html . I have two questions:
>>>1) can we summarize the justification, and add it to bullet #5 in Appendix B of string DN?
>>In response to a previous comment (from Hallvard?), I plan to
>>replace the bullet:
>>- Replaced specification of additional requirements for LDAPv2
>> implementations which also support LDAPv3 (RFC 2253, Section 4)
>> with a statement (in Section 3) allowing recognition of
>> alternative string representations.
>>with the following two:
>>- Removed specification of additional requirements for LDAPv2
>>implementations which also support LDAPv3 (RFC 2253, Section 4)
>>as LDAPv2 is now Historic.
>>- Allow recognition of alternative string representations.
>>>2) why did we reserve the need to escape double quote characters (see DQUOTE in escaped, in the ABNF)?
>>For two reasons. 1) To allow recognition of alternative string representations in which DQUOTEs are special. 2) To allow
>>DQUOTEs (like <>s) to be used to quote whole DN strings (e.g., a
>>DN string can be written "cn=RL \"Bob\" Morgan,dc=example,dc=com"
>>without confusing the wrapping quotes as being part of the DN