Re: IUTF8 pseudo-terminal mode

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

>>>           42    IUTF8       Assume input characters are UTF-8 encoded.
>> Actually, if you're going to be adding such things, how about adding
>> bits for ECHOPRT, ALTWERASE, NOKERNINFO, and character size
>> (CS5..CS8)?
> (You have CS7 and CS8 already, although you have to be sensible about
> which combinations you enable.)

Yes, it seems odd to have a CS7 boolean and a CS* boolean, rather than
a CS field which takes an argument like 7 or 8.

> Well, the IETF seems to care more about UTF-8 than those other
> things. :)

Given that there's PENDIN present, which has no business being present
at all (it's transient internal state which is exposed so that userland
can set it to provoke a reprint, not something that it makes any sense
to push across the wire at connection setup), I don't see why they
wouldn't include ECHOPRT, ALTWERASE, and NOKERNINFO.  CS5 and CS6 are a
little iffier....

There's also the question of what to do if the input and output
character sizes differ, since there's only one character-size field in
the protocol, not one in each direction.

> Given that the SSH protocol doesn't assign any semantics to these
> terminal modes -- they are just tokens passed from one side to the
> other -- it's a shame that they don't have extensibility and
> private-use facilities, unlike most of the rest of the protocol.

Sure they do.  Just not in the way you're thinking of.  You can always
do it the way I did - use a private CHANNEL_REQUEST to carry other
stuff.  Not interoperable between different independent versions, but
that's true of pretty much any private-use extensibility mechanism.

/~\ 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