Re: DNs (Was: namedref updates)

[Pierangelo Masarati <masarati@aero.polimi.it>]

> At 01:03 AM 2001-10-26, Pierangelo Masarati wrote:
> >I'll soon (tonight?) commit a more complete version 
> >of ldap_str2dn/dn2str; I also re-coded (under conditional 
> >compiling) the ldap_dn2ufn, ldap_dn2dcedn, dlap_dcedn2dn, 
> >ldap_explode_dn (I also added a non-standard ldap_explode_rdn 
> >and a ldap_dn2ad_canonical).
> >
> >I made conditionally compilable the (bare-bone) utf-8 support,
> >that is, you can use ldap_utf_* routines to parse strings, or
> >simply look at bytes, turning '\' + 'HEXPAIR' into its byte
> >equivalent, and, on the converse, turning everything that is not
> >printable ( (c) >= '' && (c) <= '~' ) into '\' + 'HEXPAIR';
> >perhaps a better alternativeis to encode everything that matches
> >( (c) & 0x80 ) != 0x00 ).
> 
> #ifdef PARSE_UTF8
>                 /*
>                  * here I guess I need to decode
>                  * the byte; let's also check
>                  * the resulting encoding is a legal
>                  * UTF-8 char
>                  */
> #endif
> 
> No.  The resulting ava_value can be of any (octet) string
> encoding, it's not restricted to UTF-8.  Just unescape
> and store.

Then I'll remove the PARSE_UTF8.

> 
> The only place you need to check for non-UTF8 (or
> non ASCII for LDAPv2) octet sequences in generating a
> (textual) string representation of the DN.

Sorry, this sentence is obscure to me. If I understand it
right, you say that I need to check in ldap_dn2str, not
in ldap_str2dn; but I'm doing it here because I want 
to know in advance if the value can be represented.
Sounds like an optimization attempt, though I'm not really
sure of what I'm saving. If it is a problem I can move the 
check to ldap_dn2str.

> 
> >The big part that is missing, I guess, is converting strings 
> >into ber-encoded binary when a non-printable string.
> 
> It is not possible to reverse many string value encodings to
> to their BER value encoding.  In particular, string values of
> directory string syntax cannot be reversed as the string 
> value encoding has no indication of the directory string
> CHOICE has.  See 7.2 of RFC 2253.

All right, I think I finally got it :)

> 
> >(that can exploit case by case '\' + 'HEXPAIR' encoding 
> >in LDAPv3) must be represented in LDAPv2; I guess I'd better 
> >do the same for DCE/AD, even though I'm not sure they understand
> >'#' + 'HEX'. Finally, what about UFN? We might understand it
> >as implicitly accepting utf-8 ('\' + 'HEXPAIR') or restrict
> >it to printable, reverting to '#' + 'HEX' in other cases.
> 
> If the particular LDAPDN cannot be represented in a particular
> format (LDAPv2, UFN, DCE), generate an error.

Fine. Then I think the code is nearly ready (except for optimization
and possible bugs). I might commit the changes this weekend.

Pierangelo.