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

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

"Kurt D. Zeilenga" wrote:
> 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.

well, instead of detecting the presence of non-printable chars 
while trying to represent the string as per rfc1779, one would 
know in advance the value is not representable; 't was a sort
of "optimization", that's it.


Dr. Pierangelo Masarati               | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale                | fax:   +39 02 2399 8334
Politecnico di Milano                 | mailto:masarati@aero.polimi.it
via La Masa 34, 20156 Milano, Italy   |