RE: SFTP v6?

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

> A client that wishes to support discontigous ranges
> will behave as follows:
> 
>    1. It must send version 3 or higher during initial
>       exchange, because if it doesn't the server can't
>       send back an extension packet describing it's
>       extended version options.
> 
>       This implies that in order to support server's
>       that don't implement the new version scheme, which
>       include v3,4, and 5 servers (of which I know of at
>       least on of each), it MUST actually support the version
>       3 protocol variant.  YUCK.

I proposed in my previous email to the list the following simple change
which solves this problem:

If the client supports a contiguous range of versions, it should send the
highest version it supports in INIT. Otherwise it should send the highest of
the first contiguous set of versions it supports, e.g. if it supports 3,4,6,
it should send 4.

This means that if the client supports 4,6 it can send 4 and does not need
to implement 3. No yuck here. :)


> So I'll make an alternate proposal:

The SFTP module can be implemented separately from the SSH server, as we do.
This proposal requires the SSH server to know about complexities of the SFTP
protocol and to invoke the SFTP module differently depending on what verb
was used to start it.

This also violates independence of SFTP from the SSH protocol. Each
underlying protocol must now think up its own rules for starting old versus
new versions of SFTP.

I think that's much uglier.

Doesn't my proposal above solve all of the gripes about people having to
advertise versions they don't actually support? It's a straightforward
change and if that's the only real problem thus far identified we have a
good solution I think (if Niels agrees).


denis