[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.
Fine.
>
> >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.
Pierangelo.
--
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 |
http://www.aero.polimi.it/~masarati