--On Monday, January 23, 2006 1:40 PM -0500 Mark Swanson <[EMAIL PROTECTED]> wrote:
Are these custom clients? What prevents them from using the telephoneNumber attribute? At the least, it sounds like the clients you have querying your service are horribly broken.Clients: Cell phones, Outlook, Thunderbird, ScheduleWorld, Evolution, KMail, OS/X mail, etc.. Take a cell phone - the numbers it pushes to an LDAP server are often not compliant with SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32}. I would have to write some code to translate arbitrary UTF-8 TEL strings into ...121.1.50 - which is guaranteed to not work perfectly (then back again into UTF-8 -lossless, which is guaranteed not to work perfectly). If I don't do perfect translation to/from 121.1.50 (which is impossible) all LDAP clients (Thunderbird, OS/X mail, Outlook, etc..) will get the incorrectly translated number, and eventually push that back to the phone. Also, a good percentage of raw phone numbers entered in Outlook/Thunderbird/OSX mail, etc.. that I see from folks around the globe do not conform to ...121.1.50. It's not just a cell phone problem, but any non-LDAP software that wants to stay in sync with the LDAP server. I don't want to disable schema checking. Though, that seems like the only realistic option as modifying schema_prep.c (thank Frank) sounds like a maintenance problem. Have I missed anything? I hope so because if not I will have to move to another LDAP server.
Given that what you are talking about is an RFC defined SYNTAX for all LDAP servers, how is moving to a different LDAP server going to help you? The basic problem here is data entry by the users of those devices, it sounds like, rather than a problem with the LDAP server. Of course, user education is one of the hardest things to achieve.
--Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
