IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: SFTP version negotiation



Henrick Hellström <henrick%streamsec.se@localhost> writes:

> I was mostly interested in (a) if there was a "better" way that didn't
> require the SFTP sub system to be closed and re-opened, plus (b) why
> this version negotiation mechanism was selected to begin with, and not

As for b), my guess is that it was expected that

1. version updates would mostly be backwards compatible, and that

2. the number of versions in use at any given time would be small,
   typically one old version and one newer.

I think these are reasonable assumptions, once the sftp spec matures.


> e.g. one in which the client would send a list of each supported
> version (which is more or less how the rest of SSH works).

The ssh version exchange (section 4.2 of the transport draft) does't
work the way you describe. To me, it makes a lot of sense to treat
version exchange and algorithm negotiation (which I suspect is what
you're referring to) quite differently.

I don't think it is motivated to introduce any more complex version
negotiation at this time. If I were to read a protocol specification
with two different version negotiation mechanism in it, my immediate
reaction would be that the spec must be a bloated comittee product.

Let's keep things simple.

Regards,
/Niels



Home | Main Index | Thread Index | Old Index