Hello, We have a PerlDAP based application (PerLDAP 1.4 compiled against Mozilla C SDK 4.x) that is able to write ISO-8859-1 Characterset encoded entries into our iPlanet Directory Server 4.16 solution with no problems. After being written to the directory the entry can be queried and the resulting data set will return all the data in the same format as it was added. This includes characters such as the "ä" (small a, umlaut) and the "õ" (small o, tilde) characters.
We are migrating to IBM Directory Server 5.2. When running the same application against IBM Directory Server, entries can be successfully added EXCEPT when attributes such as sn, cn, & givenname (among others) the contain the following characters: ÁÂÃÄÅÇÈÉÊËÌÍÎÏÐÑÈÒÓÔÕÖØÙÚÛÜÝàáâãäåçèéêëìíîïðñòóôõöøùúûüýÿ. IBM Directory Server returns an "Operations Error" to the client. We have been told that IBM Directory Server 5.2, being a modern directory server unlike iPlanet Directory Server 4.16, only accepts UTF8 encoded data via LDAP and that while iPlanet Directory Server 4.16 allowed non-UTF8 encoded data to be added, modern directory servers expect that the LDAP client convert any data from the local codepage to UTF8 before the client adds data to the directory server. Is this true? Are the ways iPlanet Directory Server 4.16 and IBM Directory Server 5.2 handle data-encoding that different? One other suggestion offered to us is to recompile PerLDAP against the latest Mozilla, Netscape, or SunOne C SDKs instead of Mozilla C SDK 4. The thought it the older Mozilla C SDK 4 didn't default to UTF8 when performing add operations against the directory, and that the latest C SDKs will. In this scenario, the PerLDAP based application continues to run with modification (at a Perl level) but the new C SDK will behind the scenes solve the communications errors we are having with IBM Directory Server because it defaults to UTF8. We know there is some truth to what IBM is telling us because all of our Java based directory applications have no issues with either iPlanet Directory Server 4.16 or IBM Directory 5.2 when adding those special characters. We've been told that is because Java uses Unicode (ie UTF8) as a default for JNDI and Mozilla Java SDK operations. In fact, our only time our IBM Directory Server 5.2 isn't accepting the special characters is when PerLDAP is used to add the data. All of our other LDAP APIs are working just fine. Throwing away our PerLDAP applications is not an option for us right now due to tight timelines (we can't even move to Net::LDAP) so I am wondering if someone else has solved this problem. Of course we have considered performing UTF8 conversions (using a perl UTF8 module) on all the attribute strings before we write the entry within PerLDAP, but due to the number of applications involved and the tight timelines, we'd prefer something more simple like updating the C SDK to something newer if that works. Any ideas, advice, comments on our dilemma would be greatly appreciated. Regards, Amit Kothari [EMAIL PROTECTED] _______________________________________________ mozilla-directory mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-directory
