Subject: RE: SFTP extensions draft should be submitted as working group item

From: "Richard Whalen" <[email-masked]>
Date: Tue, 6 Dec 2005 13:58:25 -0500

I think that the filexfer extensions draft should be a working group item and should remain a separate draft.

I suggested that the extensions be a separate item so that the filexfer draft could stabilize and proceed without the interference of new extensions being added.

Richard Whalen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Joseph Galbraith
Sent: Tuesday, December 06, 2005 1:49 PM
To: denis bider
Cc: [email-masked]
Subject: Re: SFTP extensions draft should be submitted as working group
item

denis bider wrote:
> By the way, Joseph -
> 
> I think your filexfer extensions draft contains very useful extensions which I will be implementing, or indeed already have.
> 
> I think it's a pity that this draft should be lost to casual implementors who come to the secsh working group page to get their latest SSH and SFTP specifications. It is difficult to even know that your extensions exist without semi-privileged knowledge. (It was published individually as draft-galb-filexfer-extensions-00.txt.)
> 
> I suggest that further iterations of the extensions draft be published as a secsh group work item so that they will appear on the secsh group page as one of its drafts.

I would like to do that...

I'm not sure if Bill will accept a consensus of two or three
though :-)

I've been tempted to post and ask whether we want to keep it
as a separate working group draft or roll it back in to the
main draft.

Thanks,

Joseph

PS. In terms of time lines, I believe that we are getting very
close to being ready to call the SFTP draft done.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 09 Dec 2005 15:40:26 -0500

On Tuesday, December 06, 2005 01:58:25 PM -0500 Richard Whalen 
<[email-masked]> wrote:

> I suggested that the extensions be a separate item so that the filexfer
> draft could stabilize and proceed without the interference of new
> extensions being added.

I'm not sure if I care whether all the extensions work happens.  I 
certainly don't object to it.  But like Richard, I think it should remain a 
separate draft.

It seems like every time I turn around, someone is suggesting adding yet 
another complex feature to SFTP.  Often the argument is "when applications 
do XXX to a file in the filesystem, they need semantics YYY, so we should 
make sure sftp can provide those semantics".

I'm sorry, but I guess I was under the impression that SFTP was intended to 
be a "Secure File Transfer Protocol", not a network filesystem. 
Filesystems are fun, but they're also hugely complex and, I dare say, not 
within the charter of the Secure Shell working group.

Can we _please_ finish a standards-track _File Transfer_ protocol before we 
spend any more time specifying a complete filesystem?

-- Jeff

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Fri, 9 Dec 2005 16:19:34 -0700

> spend any more time specifying a complete filesystem?

I too would like to see it finished.

Having said that, I've never been convinced that SFTP was a Secure File
Transfer Protocol...  it doesn't even have PUT and GET like FTP.  Because
one must use read and write, it is harder than it should be to implement simple
transfers where both sides are 100% sure that a whole file has been transferred
(as opposed to part of a file).

--Jeff

---

From: denis bider <[email-masked]>
Date: Sat, 10 Dec 2005 03:52:44 +0100

> Because one must use read and write, it is harder than it
> should be to implement simple transfers where both sides
> are 100% sure that a whole file has been transferred

That is precisely it, SFTP is NOT a file transfer protocol, it is a remote filesystem protocol, and the SFTP acronym is just a totally misleading name. 

People come to us all the time with the preconception that SFTP is FTP over an SSH connection. But it isn't, and I, for one, find this architectural decision welcome. On the other hand, indeed, it makes it a bit more difficult to define what an "upload" and what a "download" is, but I don't consider that a major problem.

I find Jeffrey's frustration understandable, but I think we have potentially the best, the cleanest and most straightforward remote file access protocol on our hands. It requires a few more tweaks to be complete, and I find that all these latest tweaks that were made were necessary. Now we can either specify a few simple tweaks, or botch that and leave those things unspecified, resulting in a standardization void, an implementation chaos and new standardization efforts attempting to fix that in 10 years' time.

I'm fine if OpenSSH doesn't see the need to implement anything other than SFTP version 3. That's totally OK with me, because you know what? It makes it that much easier to compete with them on quality. But I, for one, find the additions of the latest SFTP versions - ACLs, the check-file request that's in the extensions draft, the TEXTMODE flag, the REALPATH behavior change - quite necessary if SFTP is to become a universally useful network protocol. And that is something I want it to be.

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 12 Dec 2005 20:34:15 +1300

denis bider <[email-masked]> writes:

>That is precisely it, SFTP is NOT a file transfer protocol, it is a remote
>filesystem protocol, and the SFTP acronym is just a totally misleading name.

Hmm, I'm sure there are many who would want to dispute that :-).  When asked
to describe it, I've always referred to it as "An RPC mechanism for the Posix
filesystem API".  However virtually everyone I've ever talked to about it has
seen it as "FTP with extras".  So I think the SFTP name is accurate, it's all
the additional cruft that's missing the point.

Peter.

---

From: Damien Miller <[email-masked]>
Date: Mon, 12 Dec 2005 19:29:59 +1100

Peter Gutmann wrote:
> filesystem API". 

The later drafts present an ad-hoc selection of features and semantics
from the filesystem APIs of _several_ operating systems assembled
without the architectual coherence of NFSv4.

> So I think the SFTP name is accurate, it's all

Agree 100%.

-d

---

From: denis bider <[email-masked]>
Date: Tue, 13 Dec 2005 14:10:01 +0100

>>> That is precisely it, SFTP is NOT a file transfer protocol,
>>> it is a remote filesystem protocol, and the SFTP acronym is
>>> just a totally misleading name.
>> Hmm, I'm sure there are many who would want to dispute that :-).
>> When asked to describe it, I've always referred to it as "An RPC
>> mechanism for the Posix filesystem API".
>>
> The later drafts present an ad-hoc selection of features and
> semantics from the filesystem APIs of _several_ operating systems
> assembled without the architectual coherence of NFSv4.
>

It is easy to see how someone who's environment is Unix will perceive everything that departs from the POSIX filesystem API as "cruft". Of course, if one works in an environment where 99% of the time the POSIX interface has everything, all those additions are pointless.

For people on other platforms though, the POSIX interface may only be satisfactory 70% or less of the time. To people on such platforms, those additions are important and make all the sense in the world. And non-POSIX platforms are NOT in minority in the world!

We need an SFTP that is useful across platforms. What's needed is something less complex than NFS, but also something more complete than SFTP version 3. I don't care for the "architectural coherence of NFSv4" if its architecture is such that it's a pain to adapt for use over SSH. Why else doesn't anyone implement an SSH+NFS server?

There is a middle ground, and we need a protocol that will be there.

It's not bad to have multiple designs for perhaps somewhat similar things. It's evolution; the most useful design wins.