Re: UTF8

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

> In fact, since all input systems, either local or remote, connected
> to a 'octet' based system, MUST use the same encoding system to
> provide passwords,

I've seen others claim basically this, and it simply isn't true.

If my password is the octet string 0x20 0xe7 0x22, it doesn't matter
whether I type that 0xe7 in a way that the input method thinks is an
8859-1 c-cedilla or an 8859-7 eta or whatever; it still works.
(Assuming, of course, that the channel between the typing and the
checking is an octet-string channel.)

> For example, if a user sits down at a X-Station and logs on via XDM,
> the characters he types on the keyboard are encoded in a certain way.
> (This is irregardless of whether the passwd database is storing
> octets or not.)

> If the user then walks over to a VT320 terminal that is encoding the
> keystrokes in a different way, he will not be able to log in.

This is true only if the user not only insists on thinking of the
password as a character sequence rather than an octet sequence, but
also insists on typing it that way rather than adjusting to the
difference.  The login failure is really due to the mismatch between
the user's concept of the password as a character string and the
system's implementation of the password as an octet string.  (Such a
user would be better served by a character-string system, but that's
neither here nor there.)

> All the input devices capable of taking username/password input MUST
> encode input characters identically.

No, they simply must be capable of generating the necessary octets.
What characters the input method thinks they correspond to is
irrelevant.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B