Re: DN with semicolon does not work

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

At 01:23 PM 5/7/2004, Pierangelo Masarati wrote:
>> Okay, I think "1\2C2\3B" is easier to read than "1\2C2\;3".
>> The latter requires me to recognize and understand two
>> different escaping methods instead of just one.
>
>Fine.  I note that right now normalized and pretty DN are
>exactly the same (same flag is passed to DN parsing/stringifying
>routines); all we need to do is add the special chars to the
>mcros that decide if they have to be escaped as chars or
>hexpairs.  I note that this part of code has been already mucked
>with by defining the PRETTY_ESCAPE macro at the beginning of
>library/libldap/getdn.c; I guess that if we simply undefine it,
>we get hexpair escaping of all specials.

I suggest we do that for HEAD.  For RE2.2, we should fix the
bug but leave the normalized form alone (don't want to change
DB representations).

>I've just committed an essential DN write test, based on your
>draft.  Unfortunately, the first thing this did was to reveal
>that back-bdb's ITS#3063 (empty suffix) bug is still there;
>now, instead of a sigsegv we get that only one entry can be
>added to the database.

I note that you could implement the test using the
member attribute of a group...  then you'd only hve
to do one add and one search.

Kurt

>So, the test currenlty works only with ldbm.
>
>Another issue is that currently slapd considers most of the LDAPv2
>syntaxes invalid (e.g. "<DN>", "RDN;RDN;RDN", "OID.1.2.3=value"
>and so) because the DN parse routines don't get passed the
>LDAPv2 ccompatibility flag.  I think this was done on purpose,
>so the ';' as rdn separator is now really a moot point.

Yes.

At present, we don't claim to support LDAPv2 as specified
in RFC 1777.  When a v2 bind is requested, we (like most
other implementations) instead limit LDAP to a subset of
LDAPv3.

Kurt