[Date Prev][Date Next]
Re: DNs (Was: namedref updates)
> 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
> 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.