Network Working Group                                         A. Bhushan
Request for Comments: 114                                MIT Project MAC
NIC: 5823                                                  16 April 1971


                        A FILE TRANSFER PROTOCOL


I. Introduction

   Computer network usage may be divided into two broad categories --
   direct and indirect.  Direct usage implies that you, the network
   user, are "logged" into a remote host and use it as a local user.
   You interact with the remote system via a terminal (teletypewriter,
   graphics console) or a computer.  Differences in terminal
   characteristics are handled by host system programs, in accordance
   with standard protocols (such as TELNET (RFC 97) for teletypewriter
   communications, NETRJS (RFC 88) for remote job entry).  You, however,
   have to know the different conventions of remote systems, in order to
   use them.

   Indirect usage, by contrast, does not require that you explicitly log
   into a remote system or even know how to "use" the remote system.  An
   intermediate process makes most of the differences in commands and
   conventions invisible to you.  For example, you need only know a
   standard set of network file transfer commands for your local system
   in order to utilize remote file system.  This assumes the existence
   of a network file transfer process at each host cooperating via a
   common protocol.

   Indirect use is not limited to file transfers.  It may include
   execution of programs in remote hosts and the transfer of core
   images.  The extended file transfer protocol would facilitate the
   exchange of programs and data between computers, the use of storage
   and file handling capabilities of other computers (possibly including
   the trillion-bit store data computer), and have programs in remote
   hosts operate on your input and return an output.

   The protocol described herein has been developed for immediate
   implementation on two hosts at MIT, the GE645/Multics and the PDP-
   10/DM/CG-ITS (and possibly Harvard's PDP-10).  An interim version
   with limited capabilities is currently in the debugging stage. [1]
   Since our implementation involves two dissimilar systems (Multics is
   a "service" system, ITS is not) with different file systems (Multics
   provides elaborate access controls, ITS provides none), we feel that
   the file transfer mechanisms proposed are generalizable.  In
   addition, our specification reflects a consideration of other file
   systems on the network.  We conducted a survey [2] of network host




 
RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


   systems to determine the requirements and capabilities.  This paper
   is a "first cut" at a protocol that will allow users at any host on
   the network to use the file system of every cooperating host.

II.  Discussion

   A few definitions are in order before the discussion of the protocol.
   A file is an ordered set consisting of computer instructions and/or
   data.  A file can be of arbitrary length [3].  A named file is
   uniquely identified in a system by its file name and directory name.
   The directory name may be the name of a physical directory or it may
   be the name of a physical device.  An example of physical directory
   name is owner's project-programmer number and an example of physical
   device name is tape number.

   A file may or may not have access controls associated with it.  The
   access controls designate the users' access privileges.  In the
   absence of access controls, the files cannot be protected from
   accidental or unauthorized usage.

   A principal objective of the protocol is to promote the indirect use
   of computers on the network.  Therefore, the user or his program
   should have a simple and uniform interface to the file systems on the
   network and be shielded from the variations in file and storage
   systems of different host computers.  This is achieved by the
   existence of a standard protocol in each host.

   Criteria by which a user-level protocol may be judged were described
   by Mealy in RFC 91, as involving the notion of logical records,
   ability to access files without program modifications, and
   implementability.  I would add to these efficiency, extendibility,
   adaptability, and provision of error-recovery mechanisms.

   The attempt in this specification has been to enable the reliable
   transfer of network ASCII (7-bit ASCII in 8-bit field with leftmost
   bit zero) as well as "binary" data files with relative ease.  The use
   of other character codes, such as EBCDIC, and variously formatted
   data (decimal, octal, ASCII characters packed differently) is