adding IUTF8 to encoded terminal modes in SSH Protocol Assigned Numbers

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

Hi,

I am writing to you since you are the authors of RFC 4250 "The Secure
Shell (SSH) Protocol Assigned Numbers", so I suppose you are a good
starting point towards seeking IETF consensus on adding a terminal
mode assigned in this protocol.  If not, could you please redirect me
to more appropriate recipients?

The problem is this: many Unix terminal drivers have historically been
broken on UTF-8 (or indeed, any multibyte) encoding because, for
example, the "backspace" key will remove only one byte from the buffer
whereas the terminal will remove one character.  To solve this, Linux
added an "iutf8" terminal input mode, which lets the kernel terminal
driver know that characters should be assumed to have their UTF-8
width (note that this concerns the terminal mode and is independent
from any locale setting).  Unfortunately, for this to have an effect
through SSH, it is necessary for the SSH client and server to
communicate on this, hence, to obtain an number assigned to do so.

(There are, of course, various approaches to handling UTF-8 terminals,
including full locale passing, but since the SSH terminal modes have
historically reflected the Unix terminal driver flags faithfully, and
since this approach does not preclude doing something better through
other mechanisms, it is not necessary to have an all-encompassing
solution to go forward.)

This is why I'd like to try to get things moving towards creating a
consensus around the assignment (ultimately to be added to section
4.5.2 of the RFC):

         42    IUTF8       Assume input characters are UTF-8 encoded.

matching the "iutf8" stty setting under Linux.

Now I realize, of course, that one doesn't just add a number to the
list.  But there seems to be a bootstrap problem: SSH implementors
will not implement the feature unless it is normalized (see <URL:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=337041
 >), and the feature cannot be normalized until there is consensus on
its implementation.  How does one break this deadlock?

Is there some way to request at least a temporary, or provisional,
reservation, so that SSH implementations can be convinced to use this
number, which might be normalized later?

Best regards,

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