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

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto: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.

So I guess turning back-ldap into a translating gateway isn't
the best of ideas...? (That was the ultimate goal.)

> 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).

In this configuration (master, slave, slurpd in between) I don't see
what else needs munging. Of course, that's bad enough already given
that LDAPv3's "LDAPString" syntax is much more liberal than LDAPv2's.
What to do with LDAPv3 DNs with non-Latin characters on an LDAPv2
app is a bit of a puzzle.

At least, when you're just dealing with LDIF in a replog you don't
have to translate controls, extended requests and other LDAPv3 protocol
additions.

> >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

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

OK, I guess there's not much reason to pursue this.

> >Can anyone shed some more light on this?
> (transferred as T.61 in v2, UTF-8 ISO 10646 in v3) when read using LDAP.
> Fun, eh?

Ugh. Now I remember all those discussions about choice encodings. Been
a while since I had to think about that.

> 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.

Works for me...

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc  
  Symas: Premier OpenSource Development and Support