RE: UTF8

["denis bider" <ietf-ssh%denisbider.com@localhost>]

> > 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.

Given that you present this as a special case ("not only ... but also ..."),
I wonder what kind of users your software is targeting.

I have yet to meet a user that wouldn't fall into this "special" category.

But then again, we write our software for people, not for cyborgs. :)


> 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.

And when there is such a mismatch, who is right? The machine, or the user?

(My answer is, definitely, most always, the user.)


> (Such a user would be better served by a character-string system,
> but that's neither here nor there.)

And if I translate this into ordinary-speak ;) it says: virtually every user
would be better served by such a system.

It makes no sense to write our software as though it's aimed for cyborgs
when it's aimed for real people who mostly don't even know what the ASCII
code for the letter 'b' is (and probably don't even know where to look it
up, or what an ASCII code is in the first place); let alone being able to
manipulate input so as to successfully enter a password when the input
charset has been set incorrectly.

Maybe there are wiz kids out there who do this, but maybe they too would be
better off simply correcting the code page setting so that the password can
be entered normally.

The vast majority of people cannot enter binary data from a password prompt,
and most SSH clients will probably not even allow them to.

On the other hand, if you have programs connecting to other programs
unattended, you can use other modes of authentication better suited for that
purpose than arbitrarily-encoded binary passwords.

It seems to me too that interoperability and user expectations are better
served by treating usernames and passwords as character strings, not
arbitrary binary data.


Best regards,

denis