[Date Prev][Date Next]
Charset handling in the LDAP C API (Was: VM/ESA patches)
- To: Openldap-devel@OpenLDAP.org
- Subject: Charset handling in the LDAP C API (Was: VM/ESA patches)
- From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Date: Wed, 17 Mar 1999 20:35:53 -0800
- Cc: Neale Ferguson <neale@VMA.TABNSW.COM.AU>
- Organization: OpenLDAP <http://www.openldap.org/>
- References: <36E9A8A7.50872465@OpenLDAP.Org> <36ED717D.5CD8162@OpenLDAP.Org> <36F021C2.firstname.lastname@example.org> <36F0511A.EFFFC7A3@OpenLDAP.Org> <36F07DE1.E7E36D97@mailbox.tabnsw.com.au>
I've been review Neale Ferguson's patches for VM/ESA. Besides
the usual issues from lacking (POSIX) interfaces, EBCDIC support
raises a number of charset handling issues to the foreground.
OpenLDAP is a (very incomplete) implementation of the IETF draft
LDAP C API specification. The specification states that all
strings be passed between the application and the implementaton
(the library) be represented in the charset native to protocol.
That is, while the API is being used for LDAPv2, the strings should
be represented in T.61 or ASCII. For LDAPv3, UTF-8. Translation
between application required charsets and the API required
charset is left as an exercise for the developer. (please see
LDAPext mailing list archives for background on this requirement).
So that each developer need not implement their own translations,
we should provide a set of translation functions. Some of these
are needed to implement the server:
t61 <-> utf8
Others are needed to support local character sets, for VM/ESA
these would include:
ebcdic <-> t61
ebcdic <-> utf8
These later set of routines would NOT be called by the implementation,
but would be made available by the implementation for application
Charset handling actually impacts almost all LDAP applications
regradless of platform. A number of different translation
interfaces are possible. Suggestions/comments regrading such
interfaces is welcomed.
To get the ball rolling, here are a few possibilities. (I've
purposely avoided specification of function prototypes for now).
They could be implemented using two pairs of translators per
or they could be implemented such that the t61 vs utf8 choice
was specified implicit with a session handle.
or they could be implemented such that the local charset was
specified as an argument:
ldap_encode(ld, "ebcdic", ...)
ldap_decode(ld, "ebcdic", ...)
BTW, folks interested in designing or implementing a
charset translation infrastructure for OpenLDAP are
more than welcomed to do so.