RE: SFTP v6?

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

Firstly, with regard to the "file-share" method of Joseph's proposal - if in
the end that is the solution picked, I will agree.

Secondly, with regard to Niels's message:


>   Server S, that supports version 3 and version 6 of the protocol.
>   Client O (old), supporting version 3 and version 4.
>   Client N (new), supporting only version 6.
> 
> S wants to interoperate with O. Using the traditional version 
> negotiation will fail (server advertises version 6, O 
> advertises version 4, which leads to version 4 being 
> selected, which S doesn't support). Hence S *must* implement 
> the proposed extension. It always advertises version 3, and 
> intends to use the proposed extension to negotiate version 6 
> in the second phase.
> 
> Now N connects to S. If N uses the traditional version 
> exchange only, communication will fail (N advertises 6, S 
> advertises 3, which leads to version 3 being selected, which 
> N doesn't support. So if N wants to interoperate with S, it 
> too *must* implement the extension.

Reading this it seems to me like you're not at all taking into account that
S doesn't "advertise", it responds. Unlike the SSH version string which is
sent by both parties upfront, the server's SFTP version packet is a response
sent to the client. If S prefers version 6 and N advertises 6, it would be
senseless for S to send 3. S can send 6 in response to N's 6, and still be
interoperable at highest version with client X that supports non-contiguous
versions 3 and 6 and implements extended version exchange (i.e. sending 3
and then negotiating up to version 6).


> I don't usually to GUI programming. From my limited 
> experience, if you have some kind of options dialog or menu, 
> adding one more checkbox to that dialog is about the same 
> amount of work as adding one more command line option to a 
> command line tool.

That depends on what your aesthetic criteria are. Certainly if you don't
care about how the program looks it can be as simple as you described. Not
so if you're already running out of space and need to rearrange things just
to make room for the new configuration option and then arrange it in a way
that is aesthetically attractive as well as clear and non-confusing to the
operator.

Then comes the work of documenting the option; implementing a user friendly
interface guiding the user towards that option when required so that they
will be intuitively led to use it; updating the configuration schema to work
correctly with the new option; interlinking all the various configuration
and program modules that now need to use that option.

And still, after all that work has been performed, the user will be
confused, will not understand why the connection is not working and will
post messages on the forum requiring help from technical support.

In the end, if there is no version negotiation scheme allowing support for
non-contiguous versions, it becomes a better solution to implement all of
the version range, rather than having to deal with the consequences of
supporting only 2 selected versions but no solid version negotiation scheme
in place.