Re: Unimplementability [was Re: adding IUTF8 to encoded terminal modes in SSH Protocol Assigned Numbers]

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> If my username - or password - is (hex) 4d f8 b5 a7 eb, [... 8859-1
>> device ... 8859-7 device ...]
> And if you're on a device using utf-8, you're going to have some
> difficulty generating the right octets.

Well, sure, same as if I'm on an ASCII device, or anything else that
doesn't generate them.  The same, in fact, as trying to generate UTF-8
octet streams with an 8859-1 device (which is someetimes possible but
often not possible; many UTF-8 octet streams involve 0x80-0x9f octets,
which are not 8859-* printables and may well be difficult to generate
on an input device designed for an 8859-* encoding).

It is possible at all for 8859-1 and 8859-7 only because the sets of
octets that encode printables are so similar between the two encodings.
It quite likely would border on impossible for, say, ASCII and EBCDIC.

My point was not that it's possible or impossible.  My point is that
the issue is pushed out far enough that it's user-visible.

> Now, if you're logging in from another unix system, you could always
> start an xterm in a latin1 locale

...because, of course, all Unix systems run X, or can otherwise handle
arbitrary encodings.

> (which you might want to do anyway, to handle the encoding in the
> channel data better), and use that for logging in, and things should
> work just fine.

Depends.  Even in X, there is the keyboard issue; I don't know what
xterm does when it gets Greek keysyms but is running in an 8859-1
locale, or conversely, but I doubt it Just Works.  (mterm will not Just
Work; it uses XLookupString, which is - or at least is documented as
being - Latin-1-specific.  Fine for my personal use so far, but hardly
a general-purpose right answer.)

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