Re: UTF8

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

> > I will say that windows can and does use non-ascii usernames and
> > passwords, and it is not an uncommon operating system, though it
> > is not the most common of server platforms.
>
>
> I'm under the impression that those windows systems all use utf-8, not
> different character sets on different systems or for different users.
> Then, they don't matter, because they don't have a problem. Right?

True with the current drafts.  However, if we changed the drafts to
send passwords as 'octets' instead of 'utf-8', it would be a problem.

In fact, in such a scenario, I would either have to assume that
all clients are using 'utf-8' (BAD) or that all clients are using
the same thread locale as the windows operating system, for example,
for a japanese install of windows, SJIS.

In fact, geez, the problem seems fairly familiar!  It is the same
problem that 'octet' systems face now... except, instead trying to
guess what 'charset' the client is using, they are trying to guess
what 'charset' their password database is using.

So, we have two possible scenarios here:

a. We put utf-8 on the wire.  A 'octet' server must guess
   what charset the password database is using (or what charset
   the user was using last time they ran 'passwd')
b. We put 'octets' on the wire.  A server that stores username /
   passwords in a know charset must now guess what charset the
   client is using.

I suppose if we really want to solve this problem, we do the following,
we could introduce a new set of authentication messages where the
client sends BOTH the UTF-8 and the raw data entered by the user.
Then the server can pick which to use.  The client knows the users 
LC_TYPE, and can therefore safely translate to UTF-8.

I don't think we should do this, but if we want to do anything
in the space, I think this is what we have to do.

Thanks,

Joseph