rfc520.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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 [phone].

                                    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
   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]

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]