Subject: Re: IUTF8 pseudo-terminal mode

From: Vincent Lefevre <[email-masked]>
Date: Mon, 4 Feb 2013 16:02:20 +0100

On 2005-12-31 16:05:59 +0000, Colin Watson wrote:
> Recent versions of the Linux kernel support an IUTF8 flag (see
> http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod) which allows the
> character-erase function in cooked mode to handle UTF-8 characters
> correctly. I would like to allow this mode to be preserved by SSH, but
> there is no assignment for it at present.
> 
> Could this line be added to the appropriate place in
> draft-ietf-secsh-connect and draft-ietf-secsh-assignednumbers to create
> this assignment? 42 seems like a reasonable place for it.
> 
>           42    IUTF8       Assume input characters are UTF-8 encoded.
> 
> Thanks,

The problem is still there in the Debian packages from openssh 6.0p1-3.
There is a workaround, which is to set the IUTF8 flag from the .ssh/rc
file when need be, but this needs to detect the locales via LC_* env
variables (e.g. by using "locale charmap"), which are not necessarily
correctly passed (e.g. due to Debian bug 313317 / OpenSSH bug 1346).

Note: the cooked mode itself doesn't mind about the value of the LC_*
env variables; this is just a terminal problem.

-- 
Vincent Lefèvre <[email-masked]> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 04 Feb 2013 14:43:55 -0500

> The problem is still there in the Debian packages from openssh 6.0p1-3.

Yes, I'm sure it is.  The requested number was not added to the draft,
because it was too late to do so before publication.  A few days later,
Bill Sommerfeld, who was WG chair at the time, posted the following:

> So what needs to happen to get this standardized is for someone to write
> an internet-draft documenting this extension and advance it as either a
> working group item or as an individual submission.

That remains the case today.  The registration policy for that registry
is "IETF Consensus", which means that getting a new number assigned
requires publishing an RFC.  For this sort of thing, that could happen
relatively quickly, once someone writes an internet-draft.

-- Jeff

---

From: Mouse <[email-masked]>
Date: Tue, 5 Feb 2013 00:39:51 -0500 (EST)

>> So what needs to happen to get this standardized is for someone to
>> write an internet-draft documenting this extension and advance it as
>> either a working group item or as an individual submission.
> That remains the case today.  The registration policy for that
> registry is "IETF Consensus", which means that getting a new number
> assigned requires publishing an RFC.  For this sort of thing, that
> could happen relatively quickly, once someone writes an
> internet-draft.

Or, anyone who's as fed up as I am with the "rough consensus, running
code, and a whole lot of stupid hoop-jumping" way the IETF runs today
and who holds a domain can define an extension, with no coordination
with anyone else needed, and have it working in the time it takes to
implement it.

In support of this notion, I think I just now added it to
[email-masked] in moussh, alongside the other
four pieces of tty state my ssytems have but standard ssh doesn't have
support for (ECHOPRT, ALTWERASE, NOKERNINFO, and the CSIZE bits).  I
can't be sure; I don't run any systems which define IUTF8, so I can't
really test it.  Most of the code is not conditional, though, so I
think it probably should be fine - well, assuming I guessed right which
c_*flag it goes in (I picked c_iflag).  Of course, I updated
private-algs.txt; anyone who cares to bother is welcome to implement it
too.  (For those unfamiliar with moussh, feel free to clone
git://git.rodents-montreal.org/moussh and take a look around.)

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

---

From: Mouse <[email-masked]>
Date: Tue, 5 Feb 2013 15:44:37 -0500 (EST)

>> Or, anyone who's as fed up as I am with the "rough consensus,
>> running code, and a whole lot of stupid hoop-jumping" way the IETF
>> runs today and who holds a domain can define an extension, with no
>> coordination with anyone else needed, and have it working in the
>> time it takes to implement it.
> However, no one did that, either.

Well, except for the "other people implement it" part, I did.  To the
extent I can tell, at least; as I wrote, I can't really test it because
I don't run any systems that have IUTF8.

> I'm sorry if you feel that writing and submitting an internet-draft
> to get number assigned in a finite namespace is "stupid
> hoop-jumping".

It's more that writing an I-D at all these days demands it.

RFCs were originally supposed to be "float an idea".  Then they got
ringed about with bureaucracy.  So I-Ds were invented to be the "just
float an idea" mechanism.  Now _they_ have been ringed about with
bureaucracy - if I have to include a hundred lines of boilerplate in
order to float a five-line technical idea, something is broken.  That
is the hoop-jumping I refer to.

I would be happy to write up a document outlining the proposed
assignment for IUTF8 - though there's really no need, as someone
already did that upthread.  I not, however, willing to jump through the
stupid "include this boilerplate on this condition, that boilerplate
always, this other boilerplate if your age is prime or it's a
Wednesday" hoops which are necessary (or were last I checked) for it to
be accepted as a valid I-D.

> Someone asked about getting a number allocated, and Bill and I just
> described what would be required given the policy _for that registry_
> as specified _by the secsh working group_ back when the documents
> were published.  I'm pretty sure you were there at the time.

I was.  There were numerous respects in which I considered the
doucments flawed.  I spoke out about some of the ones I considered most
important; I don't think this was one of them, though if those changes,
the ones I considered important, had been made I may have worked my way
down to items this minor eventually.  (I don't really consider this a
failing of the ssh spec, but rather a failing of IETF procedure in
general.  That is, I blame the current meaning of "IETF consensus", not
the ssh spec, for IETF consensus being too high a bar for this.)

> Then again, given the number of times people have spoken up in the
> last 7 years about wanting a number, maybe it just doesn't matter.

Well, I would have liked to have a number or four myself, for the four
pieces of tty state that I put into
[email-masked].  But I didn't bother saying
anything _because_ I knew the procedure would be ridiculously
bureaucratic; it was far easier to just use an extension and be done
with it.  (I also had no will to push something like that, especially
after just having done my best to get a much more important problem
with the spec fixed and gotten nowhere.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 05 Feb 2013 15:01:41 -0500

> with anyone else needed, and have it working in the time it takes to

Yes, you can certainly define a "private" channel extension to carry
this additional extension, document it, and other people can implement
it and interoperate.  That's a fine way to handle this -- the protocol
was designed to be extensible in that fashion -- and was even discussed
as a possibility in the original thread.  However, no one did that,
either.

I'm sorry if you feel that writing and submitting an internet-draft to
get number assigned in a finite namespace is "stupid hoop-jumping".
Someone asked about getting a number allocated, and Bill and I just
described what would be required given the policy _for that registry_ as
specified _by the secsh working group_ back when the documents were
published.  I'm pretty sure you were there at the time.

I happen to agree that "IETF Consensus" is too high a bar for this
particular registry.  Perhaps its time to revisit the registration
policies and switch to something like "Expert Review".  Then again,
given the number of times people have spoken up in the last 7 years
about wanting a number, maybe it just doesn't matter.

-- Jeff