Comments on File Access Protocol
RFC 535

Document Type RFC - Unknown (July 1973; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 535 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          B. Thomas
Request for Comments: 535                                      BBN-TENEX
NIC: 17454                                                     July 1973
Categories: Protocols, FTP
References: RFC 520

                    Comments on File Access Protocol

   A file access protocol (FAP) of the sort proposed by John Day in RFC
   520 is a good idea.  The following comments suggest improvements
   (mostly additions) to the protocol described in RFC 520.

   1.  (Philosophical comment)  The intent of both FTP and FAP is to
       make it possible for a user to remotely access files.  In effect,
       FTP provides means for a user to have (parts of) file activity of
       the sort typically initiated at the command language level
       "slaved" across the network to the site where the file resides.
       In a similar way the intent of FAP is to provide a mechanism
       which allows activity of the sort typically initiated by programs
       at the operating system or monitor level to be "slaved" across
       the network to the site where the file resides.  The OPEN, CLOS,
       SETP, etc.  commands of FAP can be viewed as attempts to define
       "generic" file system monitor calls.  The suggestions made below
       are further attempts to make features typically available to
       local users also available to remote users via FAP.

   2.  The OPEN command should allow for a third OPEN mode called A for
       append.  In terms of its action with respect to a file and file
       pointer, the command

          OPEN A FOO

       would be equivalent to the sequence:

          OPEN W FOO
          SETP E

       The difference would be with respect to access control.  Many
       systems allow a user to control separately write and append
       access to a file (e.g., on TENEX a user usually sets the
       protection on his MESSAGE.TXT file such that anyone can append to
       it but only he can write it).  For such systems the append OPEN
       would succeed in many cases in which the write OPEN would fail.
       The principle here is that FAP (to as large as degree as is
       practical) should allow remote users to access files in the same
       way as local users may.

Thomas                                                          [Page 1]
RFC 535             Comments on File Access Protocol           July 1973

   3.  The protocol as proposed allows for the creation of non-
       sequential files but provides no convenient way for remotely
       accessing them after they are created.  For example if sent to a
       TENEX server, the sequence:

               OPEN W FOO     //byte size assumed = 36
               SETP B
               WRITE 512
               SETP 1024
               WRITE 512
               CLOS

       would create a file FOO with two pages (on TENEX a page = 512 36
       bit words).  The two pages would be page #0 and page #2; because
       page #1 does not exist the file is said to have a "hole" in it.
       Access to FOO via FAP would be difficult unless the remote user
       knew its (page) structure prior to access.  To support remote
       access to files such as FOO, FAP should have means for a user to
       determine a file's structure.  Consider a value-returning command
       that returns the value the file pointer should be set to in order
       to point to the first byte of the next used page (block or
       record) beyond the current position of the file pointer.  With
       such a command, call it FNUB (Find Next Used Block), the
       following sequence could be used to retrieve a holey file such as
       FOO:

               OPEN R FILE
               SETP B
       a:      FNUB               //let x=the value returned
               if x=null
                  then CLOS
                  else ( SETP x
                         READ 512   //page size=512
                         goto a )

       This presumes that the remote user knows the block (page) size so
       that he can properly access the file.  One can imagine files
       having blocks of variable size; perhaps FNUB should return two
       values: the file pointer position of the next block and the size
       of that block in bytes.

   4.  FAP should provide means for a remote user to acquire certain
       status and "descriptor" information about a given file.  The
       following is a (non-exhaustive) list of information which would
       be useful to a user remotely accessing TENEX files:

         - user's access to file; can he read, write, execute or append
           the file?

Thomas                                                          [Page 2]
RFC 535             Comments on File Access Protocol           July 1973

         - size information; byte size used in last write access (OPEN
           W) of the file; file size in bytes (of that size).

         - file access dates; date of create, last read, last write.
Show full document text