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

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

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.

But, it does make it legal for new requests to
define responses that carry additional, request-
specific information.

(And defines a couple of new requests that
use both new response and new failure protocols.)

Thanks for your comments.  Please read the new
proposal and let me know what you think of it.

- Joseph

----- Original Message -----
From: "Niels Möller" <nisse%lysator.liu.se@localhost>
To: "Joseph Galbraith" <galb-list%vandyke.com@localhost>
Cc: <ietf-ssh%netbsd.org@localhost>
Sent: Wednesday, August 08, 2001 1:31 PM
Subject: Re: global and channel requests -- more information on failure,
more flexibility on success


> "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
>