RE: SFTP v6?

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

Niels,

if the version extension scheme we're talking about is what I proposed, it
does seem to solve the problem at hand in the simplest complete way.

If in the future the 3->6 problem indeed becomes forgotten and obsolete,
clients will simply send "23" as their version (or whatever the highest
version exists at that time) and will bomb out if the server responds with
anything lower than "17". Fine.

If a client is concerned about the 3-6 problem though and wants to avoid the
chance that the server might reply to 6 with 4 or 5, I believe my proposal
is simple and complete.

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.

On the server side, this method will burden you only if you wish to offer
your highest version to clients which support non-contiguous version ranges.
But do you not wish your server to be well interoperable with such clients?
Is it not legitimate for clients to have a non-contiguous version
requirement?

Note that the solution has almost 0 impact on sessions where the client is
not one that supports non-contiguous version ranges.

I don't know why you label it as "fancy", because fancy is not what it is.
It just solves the problem with the smallest possible negative impact. The
only alternative with even less burden is to ignore the problem exists in
the first place.

I, for one, see myself implementing a client with non-contiguous version
support. And I would appreciate if the new servers allowed my client to do
so.


> -----Original Message-----
> From: nisse%lysator.liu.se@localhost [mailto:nisse%lysator.liu.se@localhost] 
> Sent: Thursday, October 28, 2004 09:42
> To: Joseph Galbraith
> Cc: denis bider; ietf-ssh%NetBSD.org@localhost
> Subject: Re: SFTP v6?
> 
> 
> Joseph Galbraith <galb-list%vandyke.com@localhost> writes:
> 
> > - Add 'versions' extension to allow server to express non-contigous
> >    set of supported versions to client, and 'version' extension
> >    from client-to-server for server to pick one.
> 
> As I said before, I really don't think this is the right way to go.
> 
> I can accept a "fancy version negotiation"-extension only if 
> it is specified in such a way that implementations that don't 
> care about disjunct version intervals (e.g. the common case 
> of an implementation supporting only version x, or supporting 
> only version x and version
> x+1) don't need to implement or otherwise care about the extension.
> 
> I view the fancy-version-negotioation thing only as a 
> temporary kludge needed for the unfortunate version 3 -> 
> version 6+ upgrade. It will be totally unneeded bloat and 
> uglyness once this is over and the protocol specification 
> stabilizes. (I don't see any value whatsoever in fancy 
> version negotiation in the longer run. Simply advertising the 
> highest supported version number provides for adequate 
> backwards compatibility for everybody else's protocols, and I 
> think it really ought to work also for sftp).
> 
> And I don't think it is appropriate at all to consider things 
> like round-trip optimization for a temoprary kludge. Just 
> solve the problem at hand in a simple a way as possible. Both 
> the problem and the solution will be forgotten a few years from now.
> 
> Regards,
> /Niels
>