Re: RFC 1779 / DN with leading spaces

["Pierangelo Masarati" <ando@sys-net.it>]

> 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.
>
> 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?

RFC 2253;

you may want to try

cn=\ EMO,dc=addressbook,o=mehome

or

cn=\20EMO,dc=addressbook,o=mehome

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it