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

[Pierangelo Masarati <masarati@aero.polimi.it>]

> At 10:08 AM 2001-10-18, Pierangelo Masarati wrote:
> >I'm committing this stuff because I haven't been able to work on it 
> >for the last week, so maybe it's time I get some feedback while I
> >work on other tasks.
> >
> >It works for simple cases; it should handle most of the "conventional"
> >cases, but there's much to do on unicode and there's still a number of
> >FIXME in the code (which means: am I doing right?).
> 
> I think there should only be two value types: string and binary
> (BER).  No transliteration of the character encoding should be
> done by either str2dn() or dn2str().  The fact that a HEXPAIR
> was used to represent the value does not change the value, it's
> still a string value.

Sure. I did not mean it becomes binary; what I mean is that
as per rfc 2253 non-printable chars can be represented as HEXPAIR,
while as per rfc 1779 __ALL__ the value should be encoded, right?
All I'm doing is converting '\' + HEXPAIR in the corresponding byte
back and forth from str2dn to dn2str.

> 
> Maybe it would help to understand the meaning of "string" vs
> "binary".  String means the value is encoded as a sequence
> of octets (which may or may not be characters) in a format
> described by the LDAP syntax.  Binary means the value is
> BER encoded per the ASN.1 syntax associated with the LDAP
> syntax.

Correct. At present I'm leaving strings and chars as they are.

> 
> It should be noted that the string encoding is not restricted
> to any particular character set.  DN hex pair escaping is used
> when octets of the string encoding are outside the range allowed
> by the DN string representation.
> 
> 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; this is the
reason I decided to add a data type modifier, which I gave the
misleading name LDAP_AVA_UTF8STRING meaning "this value will
need some '\' HEXPAIR escape according to rfc2253, or full
HEX encoding according to rfc 1779, depending on the required
format (not to mention DCE :).

> 
> One cannot convert between String and Binary encodings of
> values without knowledge of schema as without knowledge of
> the LDAP syntax of the attribute, one does not know the String
> encoding format nor the ASN.1 data definition.

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

Pierangelo.