[Date Prev][Date Next]
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
> >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:email@example.com
via La Masa 34, 20156 Milano, Italy |