Escaping within distinguished names: RFC 2253

[Scott Seligman <scott.seligman@eng.Sun.COM>]

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