UTF-8 support and other quirks in the LDAP backend (in 2.2.4).

[Steve Langasek]

On Tue, Jun 18, 2002 at 07:05:25PM +0200, Stefan (metze) Metzmacher wrote:

> >One problem we uncovered is that the backend needs to convert all strings
> >stored in LDAP to/from UTF-8. This mainly affects users real names which
> >look quite borked if they contain non 7bit ASCII chars. Some LDAP servers
> >will let you use any charset but OpenLDAP likes to enforce UTF-8 (also the
> >LDAPv3 standard mandates it).

> >Binding to the LDAP server with v3 of the protocol would be nice, since v2
> >is deprecated in OpenLDAP v2.1 (OK, so v2.1 isn't ready for prime time
> >yet, but it's still nice to get it done).

> >Sane defaults need to be added for optional attributes, for example
> >pwdMustChange ought to be never if it's not present in the users
> >record.

> >My question is if anyone is actively working on the LDAP backend and if
> >the above problems will be fixed soon. Else I will start working on it
> >myself and submit some patches.

> I didn't know that someone is actually working on this,
> but it was discussed to make the whole passdb subsystem using multibyte 
> charsets.
> I remeber UTF-8 for LDAP and UCS2 for tdb..

I do hope that tdb ends up going with UTF-8.  UCS2 is not particularly
pleasant to work with under Unix; it's not endian-neutral, it doesn't
provide ASCII as a compatibility subset, and it has to be converted to
something else before it can be used by the majority of Unix tools.
Granted, to a certain extent this is already true with tdb because it's
a binary format, but making the import/export tools more complex gives
you less margin for error.  Unless Samba chooses UCS-2 as an internal
format for string processing (which I also don't think is the best idea
in the world ;), using UCS-2 as a backend charset seems like an
all-around bad idea, IMHO.

Steve Langasek
postmodern programmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20020618/644562e3/attachment.bin