Memo to FTP group: Proposal for File Access Protocol
RFC 520

Document Type RFC - Unknown (June 1973; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 520 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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                                                             [Page 1]
RFC 520      A Proposed File Access Protocol Specification  25 June 1973

   reply with two for specific categories (such as Primary access, FTP
   results, etc.) and two for specific results.  In the meantime, the
   NWG should begin considering a general scheme for reply codes -- one
   that doesn't need revising every two years.

   Comments, complaints, etc. are welcomed.  I may be reached through
   network mail at ISI (DAY) or Multics (DAY Cnet) or by phone at the
   University of Illinois (217) 333-6544.

                                    A
                                 Proposed
                           File Access Protocol
                               Specification

                                 John Day

                                  6/7/73

I. INTRODUCTION

   The purpose of the File Access Protocol is to provide a method for
   processes to access non-local files in either a sequential or non-
   sequential manner.  Unlike the proposed Mail Protocol, FAP is an
   extension of FTP and not a subsystem.  In general FAP is compatible
   with the rest of FTP.  Those modifications which are necessary are
   specified below.

   The intent of this protocol is to allow processes to specify to the
   remote file system where in the file they wish the next operation to
   start and how much data to move.  Thus only the part of a file
   necessary for a process' computation need be transferred, rather than
   the entire file.  Thus transmission times and storage requirements
   may be held down.  In short, the rationale for a File Access Protocol
   on the network is the same as the rationale for "random-accessed"
   files in a standard operating system.

   The file Access Protocol uses the connection model, data
   representations, and transmission methods of the File transfer
   Protocol.  All data transmissions in FAP are handled according to the
   description in FTP Section III.C with the following modifications.
   In Stream mode, the minimum byte size is increased to 4 bits.
   Another control code (value 4) is used to indicate "end of
   transmission".  An combination of EOT, EOR, or EOF may be indicated
   by the proper control code.  With this method it is not necessary to
   close the connection after each access; a practice not highly
   recommended.  In Block mode, bit 5 of the descriptor field of the
   header is set noting that this block is the end of transmission.  In
   addition to this, FAP uses a File Pointer (FP).  The file pointer

Day                                                             [Page 2]
RFC 520      A Proposed File Access Protocol Specification  25 June 1973

   points into the file and is the point at which the next FAP read or
   write will commence.  The file pointer is a general mechanism for
Show full document text