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
msg01458/pgp00000.pgp
Description: PGP signature
