IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: IUTF8 pseudo-terminal mode





On Monday, January 02, 2006 04:43:58 PM -0600 Nicolas Williams <Nicolas.Williams%sun.com@localhost> wrote:

On Mon, Jan 02, 2006 at 05:29:40PM -0500, Bill Sommerfeld wrote:
In response to later messages:
> While setting LANG et al is indeed useful, it's not enough to make the
> kernel's terminal driver do the right thing when erasing characters in
> cooked mode. That's why the termios flag was invented.

I think Nicolas was implying that a request from the client to use a
UTF8 locale would cause the server to set up the pseudoterminal it
creates/allocates/... appropriately for the requested locale.  But
that's perhaps at odds with the existing strategy within the protocol of
making termios-level details visible on the wire.

I think I was a bit more explicit about this, but, yes, this would be a
hack, and very POSIX-specific (and I was explicit about that too).  But
such a hack would also probably make most users happy :^/ at the expense
of elegance and code complexity for SSHv2 servers running on POSIXy
platforms.

SSHv2's pty negotiation could certainly improve in this regard, I don't
deny it!

But I suspect saying "UTF-8" is not enough here.  What options are
there?  Should the pty driver reject non-UTF-8 sequences?  Should it
normalize?  Pass input through raw?  I suspect most users wouldn't want
much of a pty UTF-8 input mechanism as their clients, presumably, have a
decent UTF-8 input method already -- but then, maybe they don't.

I definitely think this should be a WG work item, if nothing else to
ensure it gets more eyeballs because I18N requires care.

The original request wasn't really about standardizing handling of UTF-8 in SSH data streams. That's really outside the scope of the protocol -- unlike telnet, SSH doesn't provide a "virtual terminal"; it connects the shell running on the server to the user's real terminal, and experience has shown this is basically the right thing to do.

The request here was to enable SSH to pass a platform-specific TTY mode bit which it doesn't currently handle. The bit in question causes the tty driver on Linux systems to behave in a particular way; specifically, it tells the driver that the user is typing in UTF-8, and that when the user types the ERASE character, the driver should remove a complete character (possibly a multi-byte UTF-8 sequence) from the input buffer.

One could argue that an SSH server running on such a system should look at the configured locale and configure the PTY appropriately, and that's probably even a good idea. However, a user using 'stty' to change terminal modes at the remote end of an ssh connection has an expectation that the change will propagate to the local terminal as much as possible, and the point of defining a bit for IUTF8 is to help make that possible.

-- Jeff



Home | Main Index | Thread Index | Old Index