Re: adding IUTF8 to encoded terminal modes in SSH Protocol Assigned Numbers

[David Madore <david+generic%madore.org@localhost>]

On Fri, Mar 29, 2013 at 09:31:37AM -0400, Mouse wrote:
> Er, no.  One particular set of SSH implementors, perhaps.  moussh has
> supported IUTF8 (as far as I can tell - I don't run anything that has
> the bit, making it difficult for me to test) since shortly after I
> first saw the issue mentioned.  (Supported it using the same extension
> I use to support ECHOPRT and other bits not in the ssh RFCs, but
> still.)

Please correct me if I'm wrong, but I seem to understand that moussh
supports the IUTF8 mode using a private channel approach, which
achieves the same purpose but in a different way from what I'd like to
see standardized.  I assume the reason you chose to use a private
channel is precisely that the value for the IUTF8 terminal mode is not
standardized: so this supports my statement "SSH implementors will not
implement the feature unless it is normalized" (although the word
"feature" was probably badly chosen: I meant something like "protocol
token").

Would you be willing to create - if only for testing purposes - a
version of moussh that implements the IUTF8 mode using protocol
encoded terminal mode 42?  I'm attaching a patch that I think will do
this, based on the source code I found in <URL:
http://ftp.rodents-montreal.org/mouse/local/src/moussh/moussh/
 >, which may or may not be the appropriate version to use.  It would
be great if we could check interoperability with the patched version
of OpenSSH I just posted on the Debian bug tracker (<URL:
ftp://quatramaran.ens.fr/pub/madore/misc/openssh-with-iutf8/
 >).

> Given what it is, in this case, I think the right way is to spec the
> bit even in the absence of any ssh implementations actually using it.
> (Not that I have any particular authority to do so.)

I'm willing to try this, but I somehow success that somebody is going
to say "you can't just appear out of nowhere and publish an Internet
draft that says 'now number 42 will mean this' to have it added to the
list".

>							But, on the other
> hand, if "tty drivers have this bit" were reason enough, they
> wouldn't've left out the bits that prompted me to create the extension
> I mentioned above.

I imagine nobody cared strongly enough about them.  But if the red
tape barriers do not turn out to be insurmountable and it is possible
to get IUTF8 added to the protocol assigned numbers, it might be an
occasion to add other missing ones as well.  Could you recall to me
what they are?

-- 
     David A. Madore
   ( http://www.madore.org/~david/ )

diff -puN moussh.orig/client.c moussh/client.c
--- moussh.orig/client.c	2012-12-05 02:32:52.000000000 +0100
+++ moussh/client.c	2013-03-29 18:16:52.000000000 +0100
@@ -3091,6 +3091,9 @@ static void request_pty(CSESSION *s)
 #ifdef IMAXBEL
     FOO(c_iflag,IMAXBEL);
 #endif
+#ifdef IUTF8
+    FOO(c_iflag,IUTF8);
+#endif
 #ifdef ISIG
     FOO(c_lflag,ISIG);
 #endif
diff -puN moussh.orig/msgs.h moussh/msgs.h
--- moussh.orig/msgs.h	2011-01-17 05:25:08.000000000 +0100
+++ moussh/msgs.h	2013-03-29 18:17:12.000000000 +0100
@@ -112,6 +112,7 @@
 #define TTY_OP_IXANY     39
 #define TTY_OP_IXOFF     40
 #define TTY_OP_IMAXBEL   41
+#define TTY_OP_IUTF8     42
 #define TTY_OP_ISIG      50
 #define TTY_OP_ICANON    51
 #define TTY_OP_XCASE     52
diff -puN moussh.orig/server.c moussh/server.c
--- moussh.orig/server.c	2012-12-05 02:32:59.000000000 +0100
+++ moussh/server.c	2013-03-29 18:17:52.000000000 +0100
@@ -352,6 +352,9 @@ static void set_tty_modes_std(PTY_REQ *r
 #ifdef IMAXBEL
        case TTY_OP_IMAXBEL: bit = IMAXBEL; } if (0) {
 #endif
+#ifdef IUTF8
+       case TTY_OP_IUTF8:   bit = IUTF8;   } if (0) {
+#endif
 #ifdef INLCR
        case TTY_OP_INLCR:   bit = INLCR;   } if (0) {
 #endif