[Date Prev][Date Next]
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 ).
* 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
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.
>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.
>(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.