> 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.
Really, so do I. Certainly I don't know anyone who thinks of theirusername or password as being an octet string. Nor do I know of anyone who would put up with this sort of behaviour from software, instead of just getting something that actually works for them.
I'm not the chair of this group, so I don't get to decide when we do or don't have consensus here. However, it sure looks to me like we have "rough consensus" that these things are in fact character strings, not octet strings, and that the SSH protocol should behave accordingly. Once such a consensus has been reached, it's generally considered bad form for the one dissenting voice to keep repeating the same argument over and over again, particularly with no new information.
Someone commented to me the other day that it seemed like almost no one in this group had actually _read_ IETF character set policy as defined in RFC2277. I would suggest that anyone wishing to participate further in this discussion take a break right now to do so. The entire document is only 9 pages long, and besides providing a variety of useful advice, it also represents the consensus of the IETF as to how protocols must behave with respect to character sets.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+%cmu.edu@localhost> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA