Re: FW: commit: ldap/libraries/libldap t61.c

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

At 07:46 PM 2002-01-31, Howard Chu wrote:
>Perhaps this was an exercise in futility,

Supporting both LDAPv2 and LDAPv3 per their specifications
in one application (client or server) is futile... namely
because interoperability with existing LDAPv2 applications
requires ignoring much of LDAPv2 specification.

Generally, I suggest to use LDAPv3 (openldap v2) to master
the data and then to provide legacy slaves for LDAPv2 (openldap
v1)... with a script between the master replogs and slurpd to
munge the data as needed (including character encodings, but more).

>but I've added functions to convert
>between T.61 and UTF-8. Considering that the ITU-T has withdrawn the T.61 spec
>it seems pointless to spend a lot of time on this, but it also seems like it is
>still necessary as long as LDAPv2 interoperability is needed.

And the IETF should soon move LDAPv2 to Historic status as well.

>Also I can't reconcile the fact that RFC1777 only mentions the IA5 character
>set, which is in fact a superset of the 7-bit T.61 space. I.e., 7-bit T.61 (as
>described in RFC 1345) has no backslash, caret, backquote, left curly bracket,
>right curly bracket, or tilde. Yet the LDAP RFCs are littered with backslashes
>and curly brackets, regardless.
>It's quite ironic to read this example in RFC
>1617 (page 25)
>    localityName=Zuerich
>    localityName=Zurich
>    localityName={T.61}Z\c8urich
>given that "{T.61}" is not legal in the T.61 character set...
>
>Can anyone shed some more light on this?

A little.  First, the '{T.61}' is not transferred on the wire.  Its an
indication of the directory string syntax choice (the default being
printable).  Note that in X.500, the choice is explicit on the wire.
In LDAPv2, the choice is thrown away; all values are transliterated
to T.61 for transfer.  Meaning that an X.500 attribute with two values
        cn={Printable}FOO
        cn={T.61}FOO
added using DAP will be returned as:
        cn: FOO
        cn: FOO
(transferred as T.61 in v2, UTF-8 ISO 10646 in v3) when read using LDAP.
Fun, eh?

RFC 1617 says:
   Whenever an attribute needs a character not in PrintableString and the
   attribute syntax allows the use of the T.61 character set, it is recommended
   that the attribute should be supplied as multi-valued attribute both in T.61
   string and in a transliterated PrintableString notation.

This has demonstrated to cause lots of problems.  Just use LDAPv3 and UTF-8
encoded ISO 10646.

>The discrepancy between 7-bit T.61 and
>8-bit T.61 is somewhat disturbing too: 7-bit has '#' as x23, the usual value,
>but 8-bit leaves that code undefined and moves '#' to xA6. Similarly they fudge
>the usual '$' in x24, and locate it at xA4. Do existing LDAPv2 implementations
>follow the T.61 spec exactly, or do they just use plain US-ASCII for x00-x7F?

Most LDAPv2 implementations just splat octets without care...

Kurt