Re: SFTP extensions draft should be submitted as working group item

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

>>> 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.
>
>> So I think the SFTP name is accurate, it's all
>> the additional cruft that's missing the point.
>>
> Agree 100%.

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.