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

> Please correct me if I'm wrong, but I seem to understand that moussh
> supports the IUTF8 mode using a private channel approach,

Yes.

> (although the word "feature" was probably badly chosen: I meant
> something like "protocol token").

Ah.  Then, yes.  The `feature' I as I understood it was something more
like "IUTF8 in the tty driver modes".

> 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?

Certainly...though, as I think I remarked, it is difficult for me to
test such a thing, since I don't run any OSes which have IUTF8.

> I'm attaching a patch that I think will do this, [...]

Offhand, your patch looks correct, though it's possible there's
something else which needs to be changed which doesn't come to mind
immediately - I'd grep for one of the other c_iflag bits to look for
any such possible places.  It's certainly very close.

> which may or may not be the appropriate version to use.

It's close enough for this.  The master copy of moussh is kept as a git
tree (clonable from git://git.rodents-montreal.org/moussh); in case you
care, I've just now updated the FTPable copy to match the current tip
of the master branch.  I'll create a branch IUTF8 and add IUTF8 as if
it were standard with value 42 there, to be merged (or, more likely,
cherry-picked) into master if-and-when appropriate.

>> 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'

That much, I believe you can; I-Ds get published with some pretty wacky
content (draft-terrell-logic-analy-bin-ip-spec-ipv7-ipv8-08.txt comes
to mind; it's probably expired, but if there's no current version I can
send you a copy I saved).  The question is whether anyone will pay
attention to it.  In this case, I think people will...

> to have it added to the list".

Promotion from I-D to RFC, and implementations, are the interesting
parts here.  Once there's a spec, even as an I-D, I'd expect it to be
an easier sell to get ssh implementors to implement it, and, given a
few implementations, I'd expect (though I'm hardly an expert on this
point) it to be just a matter of bureaucratic hoop-jumping to turn it
into an RFC.  I'd certainly support it, and, while that's not usually
significant, in the case of ssh it might be.

>> 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.

Apparently not.

> 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?

ECHOPRT, ALTWRERASE, NOKERNINFO, and the CSIZE bits (CS5/CS6/CS7/CS8).
You can find the extension in question described in the moussh source;
search for MOUSETTY_OP_ and missing-pty-modes to find the relevant
pieces, including an English description in private-algs.txt.  I'm not
sure what the best way to handle the CSIZE bits within the standard
framework is; I don't think it's worth holding up the rest of them for
that.

I can also copy it here if anyone finds that easier, but I'm inclined
to doubt anyone cares who hasn't already grabbed the moussh source.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B