Mark acting as Tim's proxy: the ftp section of the URL document

["Mark P. McCahill" <[e-mail]>]

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
[e-mail]
612 625 1300 (voice)      612 625 6817 (fax)