Re: UTF-8 support for libldap

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Julio Sanchez Fernandez writes:

> It gets worse than that.  If they try write access, they are supposed to
> get a referral to the master server that uses a different encoding for
> the protocol...  Well, that's only specified for v3, but it gets pretty
> scary...

That's simple enough: Don't give the slaves write access to the master.
Or make the slaves read-only and make them believe they are masters.
What v3 says isn't so important here since we are talking about
disobeying the protocol in any case...

> So that approach only works for read access.  It is a dead end.

If you want write access, yes.

> If all options could be made to work on the same server (hey, it could
> listen on several ports if no other method can be found), we could
> still allow write access.

Yup.

>> No.  Servers need to support "locale-charset-on-wire" if they want to
>> support lazy clients that don't bother with charset translation.
> 
> Cannot it be done in the library?

If I have access to the client source code and can recompile it, yes.
But I provide this as a service provider: Because there are users out
there with clients that don't handle charsets.

> What are those clients that absolutely want latin1 and cannot be
> re-linked?

* clients at other sites,
* clients at other sites,
* clients that are provided as binaries,
    A fine example is Netscape 4.06/Mission Control:
    It uses  UTF-8 LDAPv2   for LDAP URLs,
    but     latin-1 LDAPv2  for configuration info read over LDAP.
* clients at other sites,
* clients that the sysadmin doesn't want to spend time on fixing,
* clients that are provided as binaries,

...oh, and since you are aiming for UTF-8 LDAPv2:

* clients that need another library than openldap, and that library is
  written for standard (T.61) LDAP.

> Some sites (like yours, I guess) will have to support it for some time,
> but clients speaking latin1 (or somesuch) on the wire belong to an
> endangered species...

Optimist.  I do hope you are right, though.

>> But your changes don't need to worry about that, since they are on the
>> client side.  Besides, I'm sure you support it already.  You do allow us
>> to *not* do charset translation in the library, I hope?:-)
> 
> I have not tried, but the code is supposed to obey
> ldap_enable_translation().  If it worked for T.61, I see no reason for
> it not to work with UTF-8.  It's the same code, only that pointers to
> different functions are stored in the LDAP struct.

For switching from T.61 to UTF-8, yes.  But for switching to "no charset
translation" (i.e. "local charset over the wire"), the client should
simply *not* do ldap_enable_translation().

-- 
Hallvard