Re: Escaping within distinguished names: RFC 2253

["Andrew S. Neumann" <aneumann@progress.com>]

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