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

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

On Sat, 2013-03-30 at 00:13 -0400, Mouse wrote:
> > Now you have two different programs floating around on the Internet
> > that claim to support the same protocol, but they don't agree on what
> > that protocol means.
> 
> We _already_ have that.  I've seen (relatively) numerous embedded
> devices that claim to speak ssh, including using port 22, but actually
> speak a closely related protocol in which the private-part@domain
> extensibility mechanism does not work the way it does in ssh.  (I
> haven't probed the envelope of the issue enough to know whether it is
> completely busted or busted only partially; I just know that when I
> don't turn that stuff off, they ungracefully close the connection on me
> when talking with moussh.)

<sigh>  What's supposed to happen here is that you match on the server
version, turn off the features that cause it to break, and then stop
buying from that vendor until they fix their stuff.  :-)

Unfortunately, for that to be effective, you usually have to be large
and/or numerous.  Either that, or you file a bug report, and they fix
it.  I've heard that sometimes that works, against all reasonable
expectations.  Sometimes.


> Of course, even this much is still only advisory in most respects.  The
> IETF, IANA, and related bodies have no ability, either de jure or de
> facto, to prevent you, me, or anyone else from running not-quite-ssh
> software such as you'd now get by checking out moussh's IUTF8 branch
> (which now includes IUTF8 with value 42, as discussed upthread).

True, and this is as it should be.  We do seem to have a lot of
influence over what actually gets deployed, so the system seems to
mostly work.  In the meantime, I like to think that being "opt-in" gives
us the flexibility to be fairly particular about things.  For that
matter, the same is true of the @domain stuff - since it's easy for
others to accept extensions, we don't have to standardize everything
anyone might want to do.



> ...this is just as well, actually, because ssh as specified is
> basically unimplementable on many - most? - Unix variants.

Hm?  That seems fairly surprising, given that we had what claimed to be
working implementations before we ever finished the specs.  Perhaps
you'd care to elaborate (maybe in a new thread) ?

-- Jeff