path: root/doc/rfc/rfc520.txt

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]
^L
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]
^L
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
   addressing a file and should be flexible enough to handle both stream
   and record oriented systems.

II.  PROBLEMS OF IMPLEMENTATION

   As usual, not all systems will be able to implement this protocol in
   its full generality.  The approach that should be taken is that no
   host should be required to provide for network users (in the name of
   complete protocol implementation) service it does not provide its
   local users.

   Some systems allow "random" access to some kinds of files on its
   system and not to others.  In this case, this should be their
   implementation, i.e., not all operations are valid for all kinds of
   files.

   Some systems cannot move the byte pointer backwards without opening
   and closing the file.  They should not be required to do this
   (although they may if they wish), but they should allow "spacing"
   down a file some distance before starting a transfer.

   Some systems may not allow read and write access to be available
   without closing and reopening the file.  Systems should not be
   required to do both.

      In general, the rules of implementation are:

      1) If a system normally allows that particular kind of access to
      that particular file then it should be allowed; if not, the system
      should not be forced to implement it. (In many cases, the legality
      cannot be known until the operation is attempted; i.e., it cannot
      be told of the first two cases above if they are legal when the
      file is opened but only on the read or write which violates the
      implementation restrictions).

      2) A system should not try to simulate a facility if the
      simulation has side effects.  For example, if simulating the
      capability of moving the byte pointer to the desired position has
      some side effects, then the simulation should be left to the
      process accessing the file.

      3) All implementors should make known the capabilities of their
      implementations via NIC documents.






Day                                                             [Page 3]
^L
RFC 520      A Proposed File Access Protocol Specification  25 June 1973


III.  FILE ACCESS PROTOCOL

   The FAP extension to FTP includes 6 new commands and the file
   pointer.  Any implementation requires the file pointer and all six
   commands.  But, as described above, it is not necessary to implement
   the commands in their full generality.

III.1 THE FILE POINTER

   The file pointer represents an index or address within the file.  The
   units by which the index is measured, is "logical byte size" and does
   not include any bytes related to transmission or structure.  In
   particular, for transmission mode Stream and structure Record, the
   EOR and EOF markers are not counted.  Local transformations on data
   must be taken into account.  For example, Multics stores CRLF as NL.
   In this case, NL counts as two ASCII bytes since it was transmitted
   to or will be sent from Multics as CRLF.  If transmission Mode is
   Image then the logical byte size is taken as the transmission byte
   size.  There are two commands which operate on the file pointer: 1)
   SETP to move the pointer and 2) GETP to find out where it is at.
   These are described below in more detail.

   The file pointer may take on three classes of values.  All may be
   mapped to some decimal number.  The value B represents the beginning
   of the file (Byte 0).  The value E represents the end of the file (or
   Byte n for a file n bytes long).  The byte pointer may also take on
   any value between 0 and n.

                       A file of n bytes

                          ..........
     |----|----|----|----|-----------|----|----|----|----|
     ^    1    2    3    4          n-4  n-3  n-2  n-1   ^
     |                                                   |
     0                                                   n
     B                                                   E

   If a file is stored under set of parameters (TYPE, etc.) and
   operations are attempted on it under different parameters, the server
   does not guarantee that the information will be valid.

III.2 COMMANDS

III.2.1 OPEN <direction> <pathname>

   This command instructs the server to "open" the file <pathname> for
   access in the direction specified.  The directions are read, R write,
   W; or both, B. A read direction implies that the data connection is



Day                                                             [Page 4]
^L
RFC 520      A Proposed File Access Protocol Specification  25 June 1973


   from server to user; write, from user to server; and both implies
   connections each ways.  Functionally, this command corresponds to
   RETR or STOR.  Therefore, all the FTP parameter commands (TYPE, MODE,
   etc.)  must be sent before the file is opened.  If the direction is
   write (W) and the file specified by the pathname does not exist,
   there is an implied create with the open.  The success of this
   create, is, of course, dependent on local access privileges and
   possibly whether or not an ALL command was sent.  If applicable, the
   file created should be of the most general kind of file on which
   "random" access is allowed. (This is to allow the largest degree of
   compatibility with operations that may follow).  This should be
   ignored if some site specific command has already specified the kind
   of file.  This command identifies the file on which subsequent
   operations are to be performed.  After the file is opened, the file
   pointer is at B and any of the other five FAP commands may be sent.
   It is acknowledged that some systems cannot open a file for access in
   both directions; an error reply 402 should be sent for this response.

   Replies
   -------
   258      451       500       504       550
   402      454       501       505
   434      455       502       506
   4550     457       503       507

III.2.2 SETP <argument>

   This command causes the file pointer to be set to the number
   specified in the argument.  This value will be the ordinal number of
   the starting position of the next operation. (Byte 0 is the first
   byte in the file).  The argument may take on two other values besides
   <decimal number> : B, for BEGIN, which sets the file pointer at the
   beginning of a file (i.e. 0) and E, for END, which sets the file
   pointer to the last byte in the file.  Two error conditions are
   possible.  If the argument specifies an illegal change of file
   pointer (such as moving it backwards on some systems), then the error
   reply 402 should be sent.  If the argument attempts to move the file
   pointer off the end of the file, then the EOF: <byte number> reply
   should be sent with the address of the end of the file (E), and the
   file pointer left at E.

   Replies
   -------
   258
   402
   480





Day                                                             [Page 5]
^L
RFC 520      A Proposed File Access Protocol Specification  25 June 1973


III.2.3 GETP

   This command requests the server to return the value of the file
   pointer as a decimal number.

   Reply
   -----
   483
   504

III.2.4 READ <arg>

   This command instructs the server to move as many bytes as specified
   (of size logical byte size) from the server to the user.  The values
   the argument may take on are <decimal number> and ALL.  ALL is
   interpreted as all data from the present position of the file pointer
   to the end-of-file.  If a read requests more bytes than in the file,
   the number of bytes from the present position to the end of file
   should be transferred and an EOF: <byte number> response returned
   noting the position of the end of file.  If the file is Record
   structured and a READ requests more bytes than in the record, then
   the number of bytes in the record from the file pointer are moved and
   the EOR: <byte number> reply is sent noting the end of record.  The
   action of a READ leaves the file pointer at the position before the
   read plus the number of bytes moved, (i.e., updated).  The EOF
   condition leaves it at E.

   Replies
   -------
   258      480
   402      481
   450      482
   452      500-507
   455

III.2.5 WRITe <arg>

   This command instructs the server to accept as many bytes as
   specified from the user.  The result updates the value of the file
   pointer.  The values the argument may take on are <decimal number> or
   ALL.  ALL is interpreted as all data from the present position of the
   byte pointer to the end-of-file (or beyond).  Associated with the
   write is an implied "append", if necessary previous information has
   been sent (such as allocation) and if the file's access privilege
   allow the append.  If a write specifies more bytes than there are
   between the file pointer and the end-of-file, and expansion is not
   allowed, no data is sent and the file pointer is not moved.  An error
   is returned specifying the byte position of the EOF.  If the file is



Day                                                             [Page 6]
^L
RFC 520      A Proposed File Access Protocol Specification  25 June 1973


   Record structured and a WRIT attempts to move more bytes than there
   are in the record, the file pointer is not moved and the EOR: <byte
   number> reply is sent noting the end of record.

   Replies
   -------
   258      480
   402      481
   450      482
   452      500-507
   453

III.2.6 CLOS

   This command instructs the server to "close" the presently open file,
   if any.  The receipt of a CLOS without an open file is not an error.
   The effect is to notify the server that further operations are not
   directed at the file which is presently open.  If an open is received
   by the server and it has a file open, it should close the open file
   and open the new one.

   Reply
   -----
   258

IV.  SUMMARY

IV.1 SYNTAX

   OPEN <direction> <pathname> CRLF
   CLOS CRLF
   SETP <byte pointer arg> CRLF
   GETP CRLF
   READ <transfer argument> CRLF
   WRIT <transfer argument> CRLF

   <direction>::= R|W|B

   <byte pointer argument>::= B|E|<decimal number>

   <transfer argument>::=ALL|<decimal number>

   <byte number>::= <decimal number>








Day                                                             [Page 7]
^L
RFC 520      A Proposed File Access Protocol Specification  25 June 1973


IV.2 REPLIES USED BY FAP

   258    Operation successful
   402    Command not implemented for requested value or action
   433    Cannot transfer files w/o valid account. Enter account &
          resend command.
   450    FTP: file not found
   451    FTP: file access denied
   452    FTP: file transfer incomplete, data connection closed.
   453    FTP: file transfer incomplete, insufficient storage space.
   454    FTP: cannot connect to your data socket
   455    FTP: file system error not covered by other reply codes.
   457    FTP: transfer parameters in error.
   480    EOR: <byte number>
   481    EOF: <byte number>
   482    File not open for operation
   483    FP: <byte pointer>
   500    Last command line completely unrecognized.
   501    Syntax of last command is incorrect.
   502    Last command invalid (ignored), illegal parameter combination.
   504    Last command invalid, action not possible at this time.
   505    Last command conflicts illegally with previous command(s).
   506    Last command not implemented by the server.
   507    Catchall error reply.
   550    Bad pathname specification (e.g., syntax error).


         [ This RFC was put into machine readable form for entry ]
               [ into the online RFC archives by Via Genie ]






















Day                                                             [Page 8]
^L