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

On Fri, 2013-03-29 at 18:32 +0100, David Madore wrote:

> > 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' to have it added to the
> list".

On the contrary, that's exactly what you should do.  What you should
generally _not_ do is appear out of nowhere and say "here's code that
uses this IANA-managed code point that hasn't been registered; please
distribute and run it", because that creates interoperability problems.
What happens when someone else comes along and uses that code to mean
something else?  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.  It's not the same as making a change
that's only visible to programs that link against your library; this
change is visible to the entire Internet.

The answer is that we avoid that problem by having a central authority
(IANA) whose job is to maintain a record of which codes mean what, and
to avoid assigning or registering conflicting values.  In this case,
mostly because the number of available codes is small(*), the only way
to obtain a code is to publish an IETF consensus document(+) which
allocates the number and (presumably) describes its use.



That said, it's certainly not unreasonable to implement things that are
still under discussion to see whether they will work.  In fact, the SSH
community has traditionally been very proactive in this regard,
resulting in an unusually short delay from when a new feature is
standardized to when it becomes generally available.  The only part
that's a problem is letting such test code "escape" onto the open
internet, such that people think they're running an implementation of
SSH when really they're running an implementation of something slightly
different from SSH.


If you were to write an I-D, using the templates Chris said he'd
forward, you should expect no significant trouble getting it published.

-- Jeff





(*) In fact, my sense of the prevailing philosophy in the IETF at the
time SSHv2 was standardized was that, with certain notable exceptions,
such namespaces should have relatively high bars for registration, even
when space was not so scarce.  Things have changed somewhat since then,
but this is a scarce namespace and would likely still have a fairly
restrictive policy were the document published today.  Note that most of
SSHv2's namespaces are easily extensible by anyone with a registered
domain name, and that a number of others, such as message numbers, are
designed so that portions of the namespace can be reused across
different parts of the protocol.  We tried pretty hard to be liberal in
this regard, and it has paid off.

(+) essentially, an RFC which has gone through the correct series of
consensus calls and approvals on the way to publication