Re: commit: ldap/libraries/libldap dntest.c Makefile.in getdn.c ldap-int.h schema.c

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 02:17 PM 2001-10-18, Pierangelo Masarati wrote:
>> For example, say an attribute foo of syntax UCS4String whose
>> string representation was a sequence of UCS-4 characters had
>> a value of "X" (U+00000058) was used to name an entry.  This
>> RDN could be represented as "foo=\00\00\00\20".  When parsed by
>> str2dn, the value should be the four octets 00 00 00 58
>> and length 4 as that is the String encoding of the value.  And
>> callling dn2str with this LDAPDN would result in
>> "foo=\00\00\00\20" for both RFC 1777 and 2253 forms.
>
>I'm afraid I don't see any '\' HEXPAIR in rfc1779;

Whoops.  Okay, the correct answer is that this LDAPDN
cannot be converted to a RFC 1779 string, an error should
result.

>At this point it sounds like having full rfc2253/1779
>and some other representation compliance is kinda hard to obtain
>by simple parsing.

Yes! str2dn only parses, dn2str only generates.  To do anything
which requires string<->binary conversion, string transliteration
or other v2<->v3 string format conversions, requires schema.

The existence of LDAP_AVA_UTF8STRING implies that there is some
particular relevance to whether hex pair escaping was used to
represent a string value.   I fail to see any such relevancy.