Re: UTF8 case insensitive matching

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

There are a number of additional DN issues which need to be addressed.
LDAPv2 and LDAPv3 have different DN encoding requirements.  Though the
LDAPv3 DN form (RFC 2253) can be viewed as a subset of the LDAPv2
specification (RFC 1779) form, but there are other requirements
(e.g.: LDAPv2 restricts an LDAPDN to IA5, LDAPv3 restricts to UTF-8).

When talking LDAPv2, a server must accept and produce RFC 1779 DNs.
When talking LDAPv3, a server must accept and produce the restricted
 DN form defined RFC 2253s.

I suggest we allow the more liberal RFC1779 in both LDAPv2 and LDAPv3
but only store (and produce) DNs in the RFC 2253 restricted form for
both LDAPv2 and LDAPv3.  I also suggest we ignore the LDAPv2 IA5
restriction.

This implies that we not only validation and normalization functions,
but a DN "pretty" function.  To "pretty" the DN, the DN would be parsed
per RFC 1779 and then rebuilt per RFC 2253, Section 2.  We'd avoid
unnecessary escaping, use the hexpair escaping form verses the escape
prefix form, avoid OIDs, avoid BER encoded values, etc.  To normalize,
we'd parse per RFC 1779, normalize the value per its syntax, then
rebuild per RFC 2253.

>Ideally, I would like to fix the dn_validate() function so that all three of these strings normalize to the same result. While I don't think that I'll be able to fix things so that any arbitrary DN can be normalized, I would like to get as close as possible.

Note that we don't have to implement all possible DN forms.  A number of the
forms we may disallow.  It particular, we may be quite selective of what values
we accept in BER form.

>One problem that I have, though, is that since DNs must currently be normalized in place,

The long term approach is to replace dn_validate/dn_normalize with
dnValidate/dnNormalize/dnPretty.  This resolves the in place issue.

>Similarly, if I always normalized to a quoted representation,

Note that we must not produce the quoted representation in LDAPv3.  It's only
allowed in LDAPv2.

>If an alternative solution (i.e., one that allows normalization to increase the length of a DN) will be available, then I will abandon my current approach and wait until a cleaner solution can be implemented.

We need to shift to using dnValidate/dnNormalize/dnPretty....
This is significant work.