[Date Prev][Date Next]
Re: DN with semicolon does not work
> 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
> 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
>>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
>>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.
No comment here, you're definitely right.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497