Re: DN with semicolon does not work

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

At 09:12 AM 5/7/2004, Pierangelo Masarati wrote:
>> 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 think you're looking at this from an implementation perspective,
and from that perspective, I agree that there isn't a problem.

But consider an administrator who is trying to write an ACL
which matches upon specials within the value portions of the
DN string.  She has to write the regex to match \2C for comma
but \; for semi.  This will be hard for her to learn (even
if we were to provide clear documentation), just because
learning exceptions to rules is harder than just learning
the rule.

When I use the term inconsistencies, I am referring to exceptions
in our encoding rule.

>> 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,

Well, I think "1\2C2\;3" is uglier than "1\2C2\3B".

>and as I explained before, there should really be no ambiguity.

I agree that there is no ambiguity.

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

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.

Kurt