RE: Escaping within distinguished names: RFC 2253

[Christopher Oliva <Chris.Oliva@entrust.com>]

I think the grammar of section 3 should be followed when generating string
DNs.

When parsing though, the "#" only has significance when it appears as the
very first character in the value. However according to the grammar all "#"
characters need to be escaped. In other words, the parsing should handle
escaped or non-escaped "#" symbols but applications should only generate
values that follow the grammar.

Chris.

> ----------
> From: 	Andrew S. Neumann[SMTP:aneumann@progress.com]
> Sent: 	Tuesday, May 25, 1999 3:42 PM
> To: 	Scott Seligman
> Cc: 	ietf-ldapext@netscape.com; ldap@umich.edu
> Subject: 	Re: Escaping within distinguished names: RFC 2253
> 
> I was also curious about the wording regarding the presence of
> either "#" or <space> at the beginning of a name.  It was unclear
> to me if all such characters at the beginning of a name needed to
> be prefaced by a backslash, or if only the first instance needed
> such special treatment.
> 
> As an example, consider the following two names:
>   "cn=#somename, ou=someunit, o=airius.com"
>   "cn=##somename, ou=someunit, o=airius.com"
> 
> From an interpretation of the RFC, the first name should be
> entered as:
>   "cn=\#somename, ou=someunit, o=airius.com"
> 
> Should the second name be written as:
>   "cn=\##somename, ou=someunit, o=airius.com"
> or
>   "cn=\#\#somename, ou=someunit, o=airius.com"?
> 
> I suspect the latter, but am not certain.  The same applies
> for leading and trailing <space> on a name.  Can anyone
> clarify the correct approach?
> 
> thanks,
> Andy
> 
> ------------------------------------
> Andrew S. Neumann
> Apptivity Product Unit
> Progress Software Corp.
> 
> 
> Scott Seligman wrote:
> 
> > There are a few minor inconsistencies and ambiguities in RFC 2253.
> > This results, in practice, in LDAP client and server implementations
> > differing widely in how they handle some issues such as names
> > containing embedded whitespace, leading to interoperability failures.
> > The rules need clarification.
> >
> > I'd like to collect input on how existing client and server
> > implementations resolve these specification problems, and how list
> > members believe that they ought to be resolved, as the first step in
> > clarifying the RFC.
> >
> > One ambiguity is in Section 4, where it states that the ','
> > separator may have whitespace present on either side of it.
> >
> > 1.  What is the precise meaning of "whitespace" as used here?
> >
> > The following are inconsistencies in the spec, where the rules for
> > formating a string in Section 2 result in a string that cannot be
> > parsed by the grammar in Section 3.
> >
> > 2.  Section 2.4 allows the '=' character to appear in a value
> >     unescaped.  For example:
> >         CN=x=y
> >     This violates the grammar in section 3.
> >
> > 3.  Section 2.4 allows the '#' character to appear in a value
> >     unescaped, as long as it is not the value's first character.
> >     For example:
> >         CN=a#b
> >     This violates the grammar in section 3.
> >
> > For both of the above two inconsistencies, I believe that the
> > cleanest resolution is to consider the grammar to be correct, and
> > section 2.4 to be incorrect (or incomplete).
> >
> > The following are related to the earlier issue about whitespace:
> >
> > 4.  Section 2.4 allows values that end with characters such as
> horizontal
> >     tab <HT> or carriage return <CR> to appear in the formated string
> >     unescaped.  For example:
> >         CN=ab   ,OU=cd                  // value of CN is "ab<HT>"
> >         ,C=US                           // value of OU is "cd<CR>"
> >     If such characters are considered to be whitespace, then the rule
> >     in Section 4 about ignoring whitespace will result in an
> >     incorrectly parsed string.
> >
> > 5.  Section 2.4 allows values that begin with a carriage return to
> >     appear in the formated string unescaped.  For example:
> >         CN=
> >         ab                              // value of CN is "<CR>ab"
> >     The rule in Section 4 allowing (requiring?) the parsing of
> >     RFC-1779-compliant string names leads to the carriage return
> >     being lost when the string is parsed.
> >
> > The cleanest resolution here, I believe, is to not allow whitespace
> > to appear unescaped either at the beginning or at the end of a
> > value.  Carriage return should be included among the whitespace
> > characters.
> >
> > Thanks for your feedback.
> >
> > Scott Seligman
> > Java Software Engineering
> > Sun Microsystems
>