Re: global and channel requests -- more information on failure, more flexibility on success

["Joseph Galbraith" <galb-list%vandyke.com@localhost>]

> These two forms seems a little awkward, but I'm not sure what is the
> best way to deal with it. I'm not terribly concerned about backwards
> compatibility here, if the new fields are really needed, I'd prefer to
> abandon the first shorter form completely. If you need to have an old
> version talking to a new server, you can still get them to
> interoperate by simply disabling all features that result in a
> SSH_MSG_CHANNEL_FAILURE, so I think it may work well to skip the
> backwards-compatibility complexity in this case. But perhaps I'm
> naive.

Actually, old client to new server would be the worst,
because the client sends a whole bunch of requests
(pty, shell, subsystem, agent, etc.) and if any of
them failed, the client would notice too much data
in the response and report a protocol error.

Imagine an SFTP client -- you can't really disable
subsystem requests, which might generate failures.

I'd be willing to rework the wording a little and
see if we can't get the idea expressed a little
less awkwardly.  For example, something along
the lines of "unless otherwise specified, a request
uses the basic version of the response messages.  New
requests SHOULD use the extended version of the failure
message which is defines as follows ... "

Would that make you happier?

> * The new tcpip-bind requests:
> 
>         byte      SSH_MSG_GLOBAL_REQUEST
>         string    "tcpip-bind"
>         boolean   want reply
>         string    address to bind (e.g. "0.0.0.0")
>         uint32    port number to bind
> 
>        'Address to bind' and 'port number to bind' specify the IP address
>        and port to which the socket to be listened is bound.  The address
>        should be "0.0.0.0" if connections are allowed from anywhere.
> 
> I'd prefer to change the last sentence to 
> 
>        The address should be "" if connections are allowed from
>        anywhere. 

I like that -- we talked about several possiblities
for this during the working group meeting, but that one wasn't
mentioned -- I like it better then anything that was.

What do other people think about this?

> * And finally, I feel a little uneasy about creating new request types
>   for all this.
> 
> Do we need that much backwards compatibility? As far as I see, the
> cases that matters at all from a backwards-compatibility point of view
> are (i) failure cases (see above), and (ii) binding port 0, which is
> something that no old client should try, and which an old server
> should simply refuse.
> 
> So do we really need to create new request types?

Well, that was what the consensus at the meeting --
I think just doing something different in the case
of zero came up, and was felt to be a little ugly.

I actually I think the new messages are for the best,
since the old drafts didn't actually disallow binding
to port 0 (even if it wasn't specifically allowed either.)

SecureCRT probably doesn't check to make the port isn't
zero -- and there might be other clients out there that
would allow it to happen if the user requested it.

Also, do old servers actually refuse, or does it succeed --
I'd bet succeed -- but I don't have easy access right now
to test -- but it seems like I tested this once.

- Joseph