RFC 520 (rfc520) - Page 1 of 8

Memo to FTP group: Proposal for File Access Protocol

Alternative Format: Original Text Document
Next >
Network Working Group                                             J. Day
Request for Comments: 520                Center for Advanced Computation
NIC: 16819                                                  25 June 1973


             A Proposed File Access Protocol Specification

   Attached is a proposal for the File Access Protocol.  FAP is an
   extension to FTP.  I believe the specification is fairly general and
   should provide a good jumping-off place.  I hope the protocol is
   specified in such a way as to fit with idiosyncrasies of most
   systems.  If the protocol would cause an inordinate amount of burden
   on your system for one reason or another I would like to hear about
   it.

   At some later date when the difficulties of implementation are better
   known, I would like to see several levels of implementation specified
   and implementation be done in terms of those levels.

   From rumors I have heard I believe this will also allow creation and
   transfer of what TENEX calls "holey" files.  But, I am not sure of
   all of the implications of that, or what would happen (or should
   happen) when a "holey" file is moved to a site that doesn't really
   have such a thing, per se.  Comments from the TENEX crowd would be
   appreciated.

   I think some further work could be done to make FAP easier for record
   oriented systems.  This would probably require an extra command or
   parameter to specify all operations are in terms of records.
   Comments are invited.

   In the long run though, I would like to see FAP thrown away.  The
   commands as they are described merely add a finer structure to the
   present RETR, STOR, and APPE without much additional overhead.  The
   sequence:

      OPEN R FOO.BAR CRLF
            READ ALL CRLF
            CLOS CRLF

   is equivalent to RETR FOO.BAR CRLF.  FAP could be merged with FTP to
   give a much richer, coherent whole.

   In writing this document, I ran into the deficiency of reply codes
   for protocols.  Three digits is no where near enough.  I would like
   to suggest that as another interim solution we go to a five digit





Day
Next >