Re: RFC 1779 / DN with leading spaces

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 07:32 AM 4/10/2003, Marian Eichholz wrote:
>Hello!
>
>I have a problem understanding the storage of significant whitespace and
>other pathological characters in DN and the retrieval.
>
>My first guess was RFC 1485 which is obsoleted by RFC 1779 (thank You, Tony)
>with the possibility of hexadecimal (sedecimal) coding.

RFC 1779 and the rest of LDAPv2 is Historic.  See RFC 2253.
In particular, sections 2 and 3. (Ignore section 4.)

Kurt


>However, it does not work:
>
>ldapsearch -b 'cn=#454D4F,dc=addressbook,o=mehome'
>ldapsearch -b 'cn=EMO,dc=addressbook,o=mehome'
>
>are not equivalent (what I expected). They refer to completely different
>nodes.
>
>This way I hoped to store something like " EMO" with a leading space like
>this:
>
>        dn: cn=#20454D4F,dc=addressbook,o=mehome
>
>and to be able to retrieve pathological and "normal" objects with the same
>DN attribute encoding.
>
>Ok, if and when RFC 1779 defines no equivalency between the alternate
>encodings (in fact, there is not even an example of the hex-variant):
>
>        What is the RFC to refer to for portable(!) encoding of
>distinguished names? Of course, one can escape characters in whatever
>fashion he/she likes, but application level is not what I search for.
>
>Of course the question is: What RFC do ldapsearch and ldapadd adhere to?
>
>Thank You for expertise!
>
>- Marian