Subject: RE: Specifying file names in SSH File Transfer Protocol

From: Richard Whalen <[email-masked]>
Date: Fri, 8 Mar 2002 11:51:53 -0500

I meant each server will do the concatenation, as the server has to do the
job of accessing the file.  Of course the clients can also concatenate, to
give the user some information about the name of the file being accessed.

-----Original Message-----
From: Simon Tatham [mailto:[email-masked]]
Sent: Friday, March 08, 2002 11:45 AM
To: [email-masked]
Subject: Re: Specifying file names in SSH File Transfer Protocol

Richard Whalen  <[email-masked]> wrote:
> A file name is composed of a sequence of strings.  The first string
> specifies the file system.  The last string specifies the file name.  The
> intermediate strings specify each element of the directory path.  This
will
> allow each system to compose the appropriate syntax by concatenating the
> strings with the appropriate separators.

It isn't entirely clear what you mean by `each system'. Do you mean
that the _client_ will use its own local convention for
concatenating the file name components (so that running sftp on Unix
will make every remote system look like a Unix, and likewise on
Windows, VMS or whatever)? Or do you mean that the server will do
the concatenation (sending over a concatenated file name as well as
the separated components)? Or that the server will specify how the
client should do the concatenation, or what?
-- 
Simon Tatham         "Every person has a thinking part that wonders what
<[email-masked]>    the part that isn't thinking isn't thinking about."

---

From: Darren Moffat <[email-masked]>
Date: Fri, 8 Mar 2002 09:21:11 -0800 (PST)

I don't really like the suggestion of breaking the path and filename
up into components.  This is basically what NFSv2 did, when WebNFS was
added to NFSv3 (client RFC 2054 and server RFC 2055) they went to
a mechanism more like what sftp has today (See section 6 in RFC 2054).

If I understand what was being proposed it would also still be in a single
packet rather than the multiple round trips that NFS had until multi-component 
lookup arrived.

Exactly what problem does the current filename mechanism pose ?
	a) As far as the over the wire protocol is concerned ?
	b) For implementors of clients ?
	c) For implementors of servers ?
	d) Most importantly for users ?

There are already implementations of the protocol that work between
Windows and UNIX platforms and they use different separators natively.
	
Adding the complexity of ASN.1 is going to hurt adoption of the
protocol.  Also remember that this stuff is already deployed and being
actively used by a large number of people so making massive changes like
switching to ASN.1 probably isn't a good idea.

Personally I've been using WebNFS over SSH rather than sftp recently,
but that isn't available to everyone (AFAIK Solaris has the only WebNFS
server but there are plugins for the nfs URL in some on Solaris based
web browsers.

--
Darren J Moffat

---

From: Darren Moffat <[email-masked]>
Date: Fri, 8 Mar 2002 11:16:23 -0800 (PST)

>Does NFSv3 or WebNFS address the file permissions problem in
>a better fashion than SFTP or FTP?

NFSv4 does.

NFSv3 is basically a remove UNIX filesystem - Sun has an sideband
protocol for dealing with ACLs on Solaris.

WebNFS is a set of extensions to NFSv3 to make it easier to use
through firewalls and to help performance over WANs.

I have continued concern that we don't need to reinvent the wheel here.
What is the goal of the file transfer protocol ?  Is it supposed to be
equivalent to what people do with FTP but over a secure link ?  Or is
it supposed to be a remote filesystem running over the SSH protocol ?

Unless we know the answer too this we will never know if we are adding
the correct features and we will never know when we have met the requirements.

I really think we need to stop and thing about the problem we are trying
to solve and if a solution is needed at all, is this the correct group
to be solving it - especially given that the current sftp protocol
doesn't really depend on anything from SSH (it can run over other transports).

However having said that we have an already deployed system so I don't
think the answer can easily be "do nothing", but we do need to know the
problem space.

--
Darren J Moffat