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:

> Regarding global and channel requests... I believe more
> information on failure and more flexibility on success
> is needed.

Why? I believe global requests should always be answered in order, and
channel_requests on the same channel should also be answered in order.
This is analogous to the requirements for userauth-requests, which I
think are spelled out more clearly in the documents.

If you really want to be able to permute responses, you should add a
an id to each request, but I don't think that is really needed. Adding
just the request-name to the responses seems useless.

> - In the connection draft, section 2, we should change
> 
>      byte      SSH_MSG_REQUEST_SUCCESS
> 
>   to
> 
>      byte      SSH_MSG_REQUEST_SUCCESS
>      string    request-name
>      ... request-specific data follows

I don't think adding the request name here is terribly useful. As for
request specific data, that might be useful, but we don't need to do
anything about that now.

The day I invent a request where it makes sense to have additional
data, I'll add it. Implementations that don't know about the new
request will never see the extended response packet, because they
never send the new request.

>   If existing implementations won't safely ignore the extra
>   packet data, we should change the packet number and
>   deprecate the existing one.

Datapoint: LSH generally do *not* allow extra data on random packets,
and will generally treat that as a fatal protocol error.

> - In the connection draft, section 2, we should change
> 
>     byte      SSH_MSG_REQUEST_FAILURE
> 
> 
>   to
> 
>     byte      SSH_MSG_REQUEST_FAILURE
>     string    request-name
>     uint32    reason
>     string    additional text (UTF-8)
>     string    language

That makes more sense (although the request-name is still redundant,
under the assumption that requests are still answered in order).

>   I think existing implementations should simply ignore the
>   extra data.  If not, we should give this code a new value,
>   i.e., SSH_MSG_REQUEST_FAILURE2, and deprecate the old
>   message.

You can't do that, what you can do is add new _request_ messages.

> - If global requests are issued asynchronously (is this allowed?)
>   are there any guarantees for order of completion?  Do we need
>   to be able to tag requests?

I think the only reasonable thing is to require that responses are
sent in the right order (requests on different channels can be
answered in any order, though).

Summary: I disagree with you're proposed changes, except for adding
some more information to failure messages.

Resonses should be sent in the right where "right order" is defined in
my first paragraph.

It's too late to replace "reply-in-order" with
"add-id-to-all-requests", and I think reply-in-order is adequate.

Regards,
/Niels