Subject: Specifying file names in SSH File Transfer Protocol

From: Richard Whalen <[email-masked]>
Date: Fri, 8 Mar 2002 10:33:49 -0500

http://www2.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-02.txt states
that filenames use Unix syntax.

This would be fine if all the computers in the world were Unix, but they are
not.  FTP (RFC 959) recognize that file specification syntax varied by
ignoring it.

I recognize that the SSH File Transfer Protocol wants to have a defined
method of specifying a file so that it can do things like implement a
recursive copy of a directory tree.

While it is possible to use translation routines to translate between the
local system's naming structure and the Unix style, the variety of
implementations that already exist do not always use the same string for the
same user input.  This makes it harder to get the translator to work
correctly all of the time.

I would like to propose a more flexible method of specifying a file, that I
believe will not have these problems.

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.

A change will also be needed to be made to each of the commands that take a
file specification to note which style of file specification is to be used.

----------------------
Richard Whalen
Process Software

---

From: Simon Tatham <[email-masked]>
Date: Fri, 08 Mar 2002 16:44:34 +0000

> 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: Derek Fawcus <[email-masked]>
Date: Fri, 8 Mar 2002 16:56:24 +0000

On Fri, Mar 08, 2002 at 04:44:34PM +0000, Simon Tatham wrote:
> It isn't entirely clear what you mean by `each system'.

I took him as meaning the client will take the effort to translate
pathnames it sends into this format.  So that where it currently
sends 'string pathname',  that string will itself be composed of
a set of strings.

Therefore we have a common over the wire format for pathnames which
all clients have to translate into,  and all server translate from.

(As I recall pathnames aren't sent from server to client,  just filenames)

DF

---

From: "Dan O'Reilly" <[email-masked]>
Date: Fri, 08 Mar 2002 10:01:02 -0700

>(As I recall pathnames aren't sent from server to client,  just filenames)

Perhaps this is a job for an ASN.1 representation of a complete filename?

------
+-------------------------------+---------------------------------------+
| Dan O'Reilly                  |                                       |
| Principal Engineer            |  "Why should I care about posterity?  |
| Process Software              |   What's posterity ever done for me?" |
| http://www.process.com        |                    -- Groucho Marx    |
+-------------------------------+---------------------------------------+

---

From: Markus Friedl <[email-masked]>
Date: Fri, 8 Mar 2002 18:02:36 +0100

> Perhaps this is a job for an ASN.1 representation of a complete filename?

you really want ASN.1 in a slim protocol?

---

From: "Dan O'Reilly" <[email-masked]>
Date: Fri, 08 Mar 2002 10:10:40 -0700

>you really want ASN.1 in a slim protocol?

Witness the last few message exchanges.  To date, everything has assumed a
UNIX-style filename.  Demonstrably, VMS and UNIX are different, as are other
potential candidates down the road.  ASN.1 obviates filename and path
mapping translation issues.  Now, if there's a better option than ASN.1, I
have no quarrel with using it.  But the functionality supplied by ASN.1
handles this better than anything I can think of.  I grant the point, though,
that it's potentially overkill in this protocol, but you need the 
functionality.

------

---

From: Markus Friedl <[email-masked]>
Date: Fri, 8 Mar 2002 18:13:30 +0100

> that it's potentially overkill in this protocol, but you need the 

even then
	int32	num_components
	string	component0
	...
	string	componentn
wrapped into a string

would be simpler, and more like the rest of the protocol.

---

From: "Dan O'Reilly" <[email-masked]>
Date: Fri, 08 Mar 2002 10:17:24 -0700

>would be simpler, and more like the rest of the protocol.

I agree.  I think that would work pretty well.

Next question: is there a need for a system identifier?  In our work here
for VMS, we would have found it useful to know something about the other
side of the transaction.  Specifically, if the system is UNIX, there's
exactly 1 file structure.  However, on VMS, there are multiple file
structures, so knowing the other side is VMS would be important.  I'm not
suggesting that be part of the above message, but perhaps something in the
initial message exchange could incorporate that functionality.

------

---

From: Niels Provos <[email-masked]>
Date: Fri, 8 Mar 2002 13:58:15 -0500

> initial message exchange could incorporate that functionality.
Do not complicate things. KISS is still a good moto.  ASN.1 is the
biggest mess to ever have entered the IETF.

I am sure that there is a canonical filename transformation from VMS
to UNIX and vice versa.  This is an application problem and I do not
see any need to further burden the ssh protocols.

Niels.

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Fri, 8 Mar 2002 12:06:49 -0700

> see any need to further burden the ssh protocols.

Personally, I'm not convinced changing SFTP is the right solution
(it's widely deployed and very UNIX specific in many ways), but I
do believe there is a need to address this problem without forcing
all of the burden onto the applications.

The problem goes beyond filenames.  I'd like to be able to manipulate
file permissions remotely.  And, the current UNIX model of file
permissions is too simple to map to Windows NT.

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

Jeff P. Van Dyke
[email-masked]