[Date Prev][Date Next]
RE: FW: commit: ldap/libraries/libldap t61.c
> -----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
> >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
> 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
Symas: Premier OpenSource Development and Support