Re: DN with semicolon does not work

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

> I'm concerned by the lack of consistency here and how that
> impacts administration of slapd(8).   For instance, when
> writing regexes to match DNs, one has to know precisely how
> the string is normalized.

But I don't see this as a big problem; regexes, for instance,
are always applied to normalized DNs, so when looking at
DN separators, or other significant chars, it should be clear
that only the comma (',') is a valid DN separator, so there is
no chance that a comma in a DN is anything but a DN separator.
All other occurrences of commas will be represented as '\2C'.
The same applies to '=', to '+' and to '\'.
All other special chars, which were special in older versions
of the protocol, should not be considered as such when dealing
with normalized DNs.  leading ' ' and '#', and trailing ' '
are again treated as special and hexpair escaped in normalized
DNs; everything should be pretty consistent, since we never get
to ACLs (or limits, or backend selection or so) before doing
nromalization/pretty.  The fact that pretty uses '\<char>' escape
in some cases where normalization uses '\<hexpair>' s is really
not an issue, because the only chars we need to regard as special
will be hexpair escaped.

> I hope it wasn't me who objected.

Maybe Stig?  No problem, really.  Only, I think this doesn't affect
consistency, provided we use the appropriate calls to re-parse
normalized/pretty stuff.

>
> Anyways, I do think it important that the both pretty and normalized
> forms use hex escaping for ALL specials that require escaping (and no
> escaping otherwise).  That is, mandatory-to-escape characters
> are always hex escaped, non-mandatory-to-escape characters are
> always not escaped.

OK; although I concur that some not-too-bad strings would look ugly, and
as I explained before, there should really be no ambiguity.

>
>>escaping all would have required to make DNs unnecessarily longer and
>> awkward to read (I was in favour of hexpair escaping non-ascii UTF-8 as
>> well :)
>
> But that can happen even where there is no escaping changes made.
> Consider attribute type name normalization and Unicode normalization.

Yes.  This argument is really cheap; I think human readability should be a
stronger argument.

>
>>My point is that it appears that few DN parsing macros in slap.h
>>are not in sync with the corresponding macros used in DN parsing/string
>> representation.
>
> Noted.
>
>>Actually, there should be no need to assert (c) != ';', because a ';'
>> in a DN, no matter if pretty or normalized, can only be escaped and
>> takes no special meaning.
>
> If we move to hex escaping for mandatory-to-escape characters such as
> ';', then we could assert (c) != ';' to verify that we've
> properly done the normalization/prettying.
>
>>DN_SEPARATOR() really should on test for ',', and
>>NDN_SEPARATOR() should not be really used at all.
>
> Yes.

No comment here, you're definitely right.

p.


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




    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497