Re: Open Issues from Recent Comments

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

> > The way I see it, the recent discussion has made clear that the
> > benefit of requiring usernames and passwords to be normalized when
> > sent as utf8 on the wire, is very questionable.
>
> I see the value of specifying the charset on the wire at all as
> questionable, since it demands that they be character strings; an
> encoding-agnostic system has no way to convert its octet strings to
> character strings.
>
> As long as these things are specified as character strings on the wire,
> I can't see anything sensible for an encoding-agnostic OS to do,
> regardless of what encoding is chosen, regardless of normalization (if
> applicable to the encoding), regardless of almost everything else in
> this area.

I will argue strenuously against removing the UTF-8 for user names
and passwords.

There is a way for 'octet' systems to handle UTF-8.  It has
been discussed here previously.  I believe that in
my implementation for 'octet' systems, I can hit very very
close to 100% of all cases by allowing the user to specify
what charset his password is in in a user specific dot file
that I can read before authentication.  (And I believe I can
probably get 'good-enough' just by allowing the admin to
specify the charset of the passwd database.)

If we remove the requirement, I simply CAN NOT get 100%
in my windows servers.  My server would have to guess
the charset of the client.

This isn't actually something that an admin can reasonably
configure.  I could allow the each user to configure the
server for the charset of their client, but I can easily
imagine that lots of users use more than one client, and
some subset of those might use clients with different
charsets.  (Imagine a user working in a foreign office
that uses one charset when they connect from the office
machine, but a different charset when they connect from
their personal machine.)

So given that I think it is possible for an implementation
on an 'octet' machine to get 100% functionality using utf-8,
and impossible for a 'charset' machine to get 100% functionality
using octets, I think we ought to leave the draft alone.

If people find that completely unacceptable, I think we
have no choice but to introduce "publickey2", "password2",
etc., that require the client to send both the UTF-8
and the 'octet' form of the username and password.

Thanks,

Joseph