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?
This is true. All clients must convert data to utf8 format before storing in the directory servers. Directory servers are only supposed to accept data in UTF8 format. If Netscape/iPlanet DS 4.x accepted other charsets, then it could be a bug, but AFAIK there is no LDAP standard that says the directory server must check for non-UTF8 chars and reject them. It is the responsibility of the client to convert the data to UTF8. Nowhere in the LDAP standards does it say that the server must check the encoding of the string and reject it with an Operations Error if it is not in UTF8. I would be pleased if your IBM representative would care to prove me wrong.
So, in a nutshell, the client application was not standards compliant and got caught because of a switch to a more rigid standards compliant server vendor.
(I also take offence to the suggestion that iPlanet DS 4.16 is not a "modern" directory server).
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.
No, it won't, unless you change your client application. However, I know that later versions of the ldap command line programs supplied with the sdk (like ldapsearch, ldapmodify, etc.) support a command line option to automatically convert the local charset (assuming the environment variables like LANG, etc. are setup correctly) to UTF8. I believe this is 5.08 or later. So what you might want to do is to search through the code on mozilla.org to see if this option is present in the libraries and not just the command line executables and, if so, how to turn it on.
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.
What other non-Java APIs are you using?
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.
Worst case, you would have to modify the C SDK and recompile it yourself. However, since newer versions of the command line programs already support this option, you could probably just cut and paste that code into the C SDK.
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
