IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: SFTP v6?
"denis bider" <ietf-ssh%denisbider.com@localhost> writes:
> I will reply with the technical aspects first.
Thanks.
> > > If you don't care to implement it, it won't burden your client
> > > implementation at all - you can continue to send the
> > > highest version you support and that will work just as fine.
> >
> > Is that really correct? If I connect to a 3,6 server, that
> > server will advertise version 3 (it *has* to, if it wants to
> > interoperate with old 3,4 clients, and that is the entire
> > point of the extended version negotion, right?).
>
> If your client sends version 6 and the server supports version 6 it can
> respond with version 6.
I'm afraid that makes absolutely no sense to me. It is possible that I
have misunderstood the vesrion extension in some fundamental way, so I
should probably shut up until I've reread the proposal (which may take
a long time, since I'm pretty busy with work for the rest of this
year).
Anyway, I'll summarize my current understanding of the proposal.
Given:
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.
> Right now our SSH server still supports SFTP version 2 only. The features of
> SFTP version 2 are all that's needed in a Windows server, so we didn't yet
> upgrade.
When you upgrade, you will have a server that supports version 2 and
6, or version 2,3 and 6, right? I don't see why that should pose a
problem.
The problem is only implementations that *advertice version 4 and 5*.
Any body who knows about deployment of such versions, please speak up.
I'd like to see some evidence for the existence of the problem the
extension is trying to solve.
> Niels - are any of your clients and servers graphical? Textual configuration
> is easy. But providing good and well working graphical configuration for
> ANYTHING is much, much more difficult than extending the protocol for it to
> work automatically. Adding a new option can even take more than a day some
> times. It's an important consideration when implementing anything.
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.
Regards,
/Niels
Home |
Main Index |
Thread Index |
Old Index