[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: commit: ldap/libraries/libldap getdn.c



On Wed, Dec 05, 2001 at 11:01:17AM +0100, Pierangelo Masarati wrote:
> I think this will go in between ldap_str2dn and ldap_dn2str inside
> the new dnNormalize; this should also be done selectively on the 
> values of the attributes whose syntax allows UTF-8 data.

I must confess I haven't looked at your code, but I think that in all
cases where you consider casefolding (uppercasing), you should think
about Unicode. Of course if you know that some string (or part of
string) is plain ASCII you can ignore Unicode there.

> We cannot work at the string level because all UTF-8 that is not 
> plain ascii is already represented as '\' + HEXPAIR; my guess is 

Yes, so either we need to normalize it before it is escaped or we
need to actually have something that reads in hex like this, and
outputs new hex values. To me it sounds reasonable to do it before
it is escaped, but I haven't looked at your code...

> we need to implement the schema aware dnNormalize to have UTF-8
> normalization in place in an efficient manner, although we have
> to deal with the overhead of finding the AttributeDescription of 
> each ava in the LDAPDN structure.  To this purpose we could store
> it in the LDAPAVA as well, possibly only if inside the server and
> if explicitly required by a flag. Sort of:

I need to look at your code, but are you (or should we) perhaps
internally store the dn as a list of rdns, and have pointers to
ldap_ava structs in there? And then only translate the dn into a
string when necessary? The translated value can be stored/cached
somewhere and reused.

Well, just some stray comments, I should look at the your code.

Stig