Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


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
 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
 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
          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.
                         File Access Protocol
                               John Day


 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.


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


 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.


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

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


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

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.
 258      480
 402      481
 450      482
 452      500-507

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] 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.
 258      480
 402      481
 450      482
 452      500-507


 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.



 OPEN <direction> <pathname> CRLF
 SETP <byte pointer arg> 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] RFC 520 A Proposed File Access Protocol Specification 25 June 1973


 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc520.txt · Last modified: 2001/07/17 17:38 by

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki