RE: SFTP version negotiation

["denis bider" <ietf-ssh%denisbider.com@localhost>]

> We could have the server send it's list of supported versions
> as part of the FXP_VERSION packet and then allow the client
> to request that the server switch to one of the listed
> versions... but that doesn't save the round trip, since the
> client still has to do the switch as an extension w/ a round
> trip.

It does save a round trip because if the server includes a "versions" extension
and the client elects to send a request for one of those higher versions, the
client can fire-and-forget that request and proceed with other requests
immediately. The spec could mandate that the server MUST always respond
positively to a well-formed client request for a higher version if that version
was advertised by the server in the extensions of SSH_FXP_VERSION.

It could look something like this:

 -> SSH_FXP_INIT
    version: x

 <- SSH_FXP_VERSION
    version: x
    ext name: "versions"
    ext data: "x+3,x+1"

 -> SSH_FXP_SELECTVERSION
    version: x+3
 -> SSH_FXP_REALPATH
    request id: 0
    path: "."

 <- SSH_FXP_VERSIONSELECTED
 <- SSH_FXP_NAME
    request id: 0
    count: 1
    filename
    attributes

The spec would mandate:

- The highest version number that a client should ever send is "x" (the last
version number before this 2nd mechanism was introduced - say 5 at this point
if the extension is introduced in SFTP v6).

- A server supporting versions >x MUST send the "versions" extension
enumerating the versions higher than x that it supports. Mentioning versions
<=x is pointless, we should recommend people not do it lest someone overeager
populate this with 4,3,2,1.

  The "versions" extension should be sent whenever the version sent by the
client indicates that the client supports SSH_FXP_VERSION extensions. So, this
should be sent even if the client advertises e.g. version 3. This is so that a
client supporting 3 and 6 can advertise 3 and get 3 against version 5 servers,
but select 6 when the server is 6+.

- If the client wishes to do so, it can switch protocol version to one of the
higher versions advertised by the server by a direct reply to the server's
SSH_FXP_VERSION message. This can be done with SSH_FXP_SELECTVERSION (newly
invented). There is no request ID because it is not necessary, the message can
only appear in immediate response to SSH_FXP_VERSION, cannot appear multiple
times.

- The server replies to that with SSH_FXP_VERSIONSELECTED. This is just to
maintain the request-reply dynamic of the SFTP protocol and is not really
necessary. If the client's request was faulty, the server cannot do much but
close the channel anyway. If the client's request was alright, the server must
honor it. We could just as well do without this response message in fact -
unless someone has something to say for it, I propose we might even drop this
response.

- The client need not wait for SSH_FXP_VERSIONSELECTED, and when this message
arrives it can be ignored. The client can pipeline requests immediately after
sending SSH_FXP_SELECTVERSION.

Seems like an OK solution to me - no roundtrip problem, and has immediate
benefit of solving the issue of the client supporting only versions 3 and 6.

Votes?

denis