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

[nisse%lysator.liu.se@localhost (Niels Möller)]

"Joseph Galbraith" <galb-list%vandyke.com@localhost> writes:

> Yes, I think I've been mostly talked around --
> see my email
> 
>     "New requests to support binding port 0"
> 
> for a new proposal that is completely backwards
> compatible -- there is no change in the response
> protocols for currently defined requests.

I was replying to mail in order... Now I have read your more recent
proposals.

* Ordering for channel requests:

    3.4.1 Multiple requests and ordering

       The client is allowed to send further messages without waiting for
       the response to the request.  The recipient must respond to messages
       in the order received so that responses can be matched to requests.

Requests on separate channels should be independent, with no ordering
constraints. Is that obvious, or should the spec say that explicitly?

* The two forms of failure messages:

        byte      SSH_MSG_CHANNEL_FAILURE
        uint32    recipient_channel
        ...request specific data

and

        byte      SSH_MSG_CHANNEL_FAILURE
        uint32    recipient_channel
        uint32    reason
        string    descriptive-text [UTF8]
        string    language
        ... further request-specific data follows

It seems odd to refer to the three optional fields as "request
specific", when they are in fact required to be the same for all
requests. 

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.

The same reasoning applies to SSH_MSG_FAILURE.

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

That means, listen on all interfaces, be they ipv4 or ipv6. "0.0.0.0"
and "::" can also be used, but they would be needed only in special
circumstances. 

(I'd also like to be allowed to use dns names everywhere in the
protocol, but that's an extension that it's simple to make later.It
might also be nice to have a defined way to say "listen on localhost
only, no matter if ipv4 or ipv6 is used". Perhaps the string
"localhost" could be used for that).

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

Best regards,
/Niels