Date: Sun, 13 Mar 94 12:10:18 CST
Message-Id: <9403131810.AA00856@boombox.micro.umn.edu>
From: "Mark P. McCahill" <mpm@boombox.micro.umn.edu>
To: uri@bunyip.com
Subject: Mark acting as Tim's proxy: the ftp section of the URL document
Comments:
- How the information about to do transfers (binary, tenex, or ascii
mode) is not covered in Tim's revision.
- It would be good to be a bit more explicit about what I think is
an implicit assumption made for differentiating between files and
directories in Tim's proposal. I think he is implying that if the
ftp path is specificed as /x/y/z you assume that there is a sequence
of CWD followed by a RETR of file z, and if the path is /x/y/z/ the
URL is pointing to a dorectory rather than a document.
If this sort of syntax works for people, then the thing that needs to
be added is simply a tag to specify transfer mode (binary, ascii, tenex)
Anyway, here is the ftp section I found by crawling through Tim's
not-yet-completed revisions of the URL draft:
---------------------------------------------------------------------------
FTP
The ftp: prefix indicates a file which is to be picked up from the file system
of the given host. The FTP protocol is used, as defined in RFC957 or any
successor. The port number, if present, gives the port of the FTP server if not
the FTP default. (A client may in practice use local file access to retrieve
objects which are available though more efficient means such as local file open
or NFS mounting, where this is available and equivalent).
The syntax allows for the inclusion of a user name and even a password for
those systems which do not use the anonymous FTP convention. The default,
however, if no user or password is supplied, will be to use that convention,
viz. that the user name is "anonymous" and the password the user's
Internet-style mail address.
The FTP protocol allows for a sequence of CWD commands (change working
directory) prior to a RETR (retrieve) which actually accesses a file. The
arguments of any CWD commands are successive segment parts of the URL, and
the filename argument to the RETR command is the final segment of the URL
path.
Note
In the case in which the file system of the server is known or guessed by the
client, the path may possibly converted into a filename. This may (in some
cases) allow the file to be retrieved in one RETR command with no CWD command.
In the case of unix, the filename will in fact look the same as the URI path.
This must NOT be taken to indicate that the URL is a unix filename. In
practice, as many FTP servers in fact have or emulate unix file systems, it
may in fact be time-efficient to attempt first a direct retrieval guessing unix
syntax, and, if that fails, to attempt the official sequence of succession of
directory changes followed by a RETR command.
There is no common hierarchical model to the FTP protocol, so if a directory
change command has been given, it is impossible in general to deduce what
sequence should be given to navigate to another directory for a second
retrieval, if the paths are different. The only reliable algorithm is to
disconnect and reestablish the control connection. However, if no directory
changes have been made, but direct retrieval has been done, then the control
connection may be kept. Another possible uninvestigated method is to use CDUP
on the trial assumption of a hierarchical structure to return a point in common
between the first and second URLs.
-----------------------------------------------------------------------------
Mark P. McCahill
gopherspace engineer/University of Minnesota
mpm@boombox.micro.umn.edu
612 625 1300 (voice) 612 625 6817 (fax)