[Date Prev][Date Next]
Re: UTF8 case insensitive matching
- To: openldap-devel@OpenLDAP.org
- Subject: Re: UTF8 case insensitive matching
- From: Michael Ströder <email@example.com>
- Date: Wed, 01 Nov 2000 17:00:29 +0100
- Organization: stroeder.com
- References: <firstname.lastname@example.org>
"Kurt D. Zeilenga" wrote:
> 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,
What does "unnecessary escaping" mean?
This whole thing is weird: If you e.g. parse a RFC2253 DN string
with hex-escaped UTF-8 chars it's pretty hard to figure out if the
hex-escaped chars should be kept as is or transferred to UTF-8.
> 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.
AFAIK RFC1779 allows ; as DN component delimiter instead of ,. How
do you determine whether ; or , is used as delimiter? Or you add it
to your "avoid-list".
Even worse: In my application I have to deal with ASN.1 structure of
certificate DNs and mapping it to LDAP DNs...