[Date Prev][Date Next]
RE: Revisited: NON-ASCII chars in userPassword
Yes, I was thinking more clearly AFTER I wrote the message than during!
Latin-1 has to be transcoded into UTF-8. I don't know about 'passwords',
though, as I don't see that they need be words from some language, unless
this is the meaning you would like LDAP to give them. I don't think UTF-8
helps anyway as the password may not have a representation in another
language and so would have to be treated as a sequence of bytes. The fact
that the bytes are syntactically UTF-8 is of no help.
To put it another way, if the password is e'te' (e-acute t e-acute), the
only way I could send it to a server would be to pass an opaque octet string
as (obviously) I cannot type it in.
From: Michael Ströder [mailto:email@example.com]
Sent: Wednesday, 31 October 2001 18:42
To: Ramsay, Ron
Subject: Re: Revisited: NON-ASCII chars in userPassword
"Ramsay, Ron" wrote:
> Personally, I can't see the connection between LDAP credentials and user
> logons. And what is a user logon?
I'm not sure what you mean. I'm solely talking about simple bind:
You need a bind DN and a password credential for the "logon". The
syntax of the bind DN is already well-defined in RFC2253. The syntax
of the password is not. It should be mandated to be UTF-8 encoded
ISO-10646 Unicode for clients having a chance to be interoperable.
Today e.g. Netscape Navigator sends ISO-8859-1 and MS Outlook sends
UTF-8 encoded Unicode.
> It would be interesting to see the data generated by a logon in Japan.
No problem with UTF-8 encoded Unicode.
> I say, leave it alone. It is a piece of data that a client provides to
> authenticate to a server.
Yes, that's exactly what I'm talking about. The client has to know
in advance which character set and encoding to use for passwords.
> PS Isn't 8859-1 a subset of UTF-8? (rhetorical)
Actually you're mixing character set and character encoding here...
(also rhetorical ;-)