    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

    Bhushan                                                         [Page 1]

    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
       facilitated by inclusion of data type in descriptor headings.  An
       alternative mechanism for defining data is also available in the form
       of attributes in file headings.  The format control characters
       reserved for the syntax of this protocol have identical code
       representation in ASCII and EBCDIC.  (These character are SOH, STX,
       ETX, DC1, DC2, DC3, US, RS, GS, and FS.)

    Bhushan                                                         [Page 2]

    RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971

       The notion of messages (the physical blocks of data communicated
       between NCP's) is suppressed herein and that of "logical" records and
       transactions is emphasized.  The data passed by the NCP is parsed
       into logical blocks by use of simple descriptors (code and count
       mechanisms) as described in Section III.  The alternative to count is
       fixed length blocks or standard end-of-file characters (scan data
       stream).  Both seem less desirable than count.

       The cooperating processes may be "daemon" processes which "listen" to
       agreed-upon sockets, and follow the initial connection protocol much
       in the same way as a "logger" does.  We recommend using a single
       full-duplex connection for the exchange of both data and control
       information [4], and using CLS to achieve synchronization when
       necessary (a CLS is not transmitted until a RFNM is received).

       The user may be identified by having the using process send at the
       start of the connection the user's name information (either passed on
       by user or known to the using system) [5].  This user name
       information (a sequence of standard ASCII characters), along with the
       host number (known to the NCP), positively identifies the user to the
       serving process.

       At present, more elaborate access control mechanisms, such as
       passwords, are not suggested.  The user, however, will have the
       security and protection provided by the serving system.  The serving
       host, if it has access controls, can prevent unprivileged access by
       users from other host sites.  It is up to the using host to prevent
       its own users from violating access rules.

       The files in a file system are identified by a pathname, similar to
       the labels described in RFC 76 (Bouknight, Madden, and Grossman).
       The pathname contains the essential information regarding the storage
       and retrieval of data.

       In order to facilitate use, default options should be provided.  For
       example, the main file directory on disk would be the default on the
       PDP-10/ITS, and a pool directory would be the default on Multics.

       The file to be transferred may be a complete file or may consist of
       smaller records.  It may or may not have a heading.  A heading should
       contain ASCII or EBCDIC characters defining file attributes.  The
       file attributes could be some simple agreed-upon types or they could
       be described in a data reconfiguration or interpretation language
       similar to that described in RFC 83 (Anderson, Haslern, and Heffner),
       or a combination.

    Bhushan                                                         [Page 3]

    RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971

       The protocol does not restrict the nature of data in the file.  For
       example, a file could contain ASCII text, binary core image, graphics
       data or any other type of data.  The protocol includes an "execute"
       request for files that are programs.  This is intended to facilitate
       the execution of programs and subroutines in remote host computers
       [6].

    III.  SPECIFICATIONS

    1. Transactions

       1A.   The protocol is transaction-oriented.  A transaction is defined
             to be an entity of information communicated between cooperating
             processes.

       1B.   Syntax

             A transaction has three fields, a 72-bit descriptor field and
             variable length (including zero) data and filler fields, as
             shown below.  The total length of a transaction is (72 + data +
             filler) bits.

       | <code><filler count><NUL><data count><NUL> |    <data><filler>   |
       | |____||____________||___||__________||___| |    |____________|   |
       |   |         |         |        |       |   |          |          |
       | 24-bits   8-bits    8-bits  24-bits  8-bits|    variable length  |
       | <-------descriptor field 72-bits---------> |<--data and filler-->|
       |                                            |                     |

       1C.   Semantics

             The code field has three 8-bit bytes.  The first byte is
             interpreted as transaction type, the second byte as data type
             and the third byte as extension of data type.

             The filler count is a binary count of bits used as "filler"
             (i.e., not information) at the end of a transaction [7].  As
             the length of the filler count field is 8-bits, the number of
             bits of filler shall not exceed 255 bits.

             The data count is a binary count of the number of data (i.e.,
             information) bits in the data field, not including filler bits.
             The number of data bits is limited to (2^24-1), as there are 24
             bits in the data count field.

    Bhushan                                                         [Page 4]

    RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971

             The NUL bytes are inserted primarily as fillers in the
             descriptor field and allow the count information to appear at
             convenient word boundaries for different word length machines
             [8].

    2.  Transaction Types

       2A.   A transaction may be of the following four basic types:
             request, response, transfer and terminate.  Although large
             number of request and transfer types are defined,
             implementation of a subset is specifically permitted.  Host
             computers, on which a particular transaction type is not
             implemented, may refuse to accept that transaction by
             responding with an unsuccessful terminate.

             The following transaction type codes are tentatively defined:

             Transaction Type                       Transaction Type Code

                                                 ASCII   Octal   Hexidecimal

             Request
                     Identify                        I       111     49
                     Retrieve                        R       122     52
                     Store                           S       123     53
                     Append                          A       101     41
                     Delete                          D       104     44
                     Rename                          N       116     4E
                     addname (Plus)                  P       120     50
                     deletename (Minus)              M       115     4D
                     Lookup                          L       114     4C
                     Open                            O       117     4F
                     Close                           C       103     43
                     Execute [9]                     E       105     45

             Response
                     ready-to-receive (rr)           <       074     3C
                     ready-to-send (rs)              >       076     3E

             Transfer
                     complete_file                   *       052
                     heading                         #       043     23
                     part_of_file                    '       054     2C
                     last_part                       .       056     2E

             Terminate
                     successful (pos.)               +       053     2B
                     unsuccessful (neg.)             -       055     2D

    Bhushan                                                         [Page 5]

    RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971

       2B.   Syntax

             In the following discussion US, RS, GS, FS, DC1, DC2, and DC3
             are the ASCII characters, unit separator (octal 037), record
             separator (octal 036), group separator (octal 035), file
             separator (octal 034), device control 1 (octal 021), device
             control 2 (octal 022), and device control 3 (octal 023),
             respectively.  These have an identical interpretation in
             EBCDIC.

       2B.1  Requests

             Identify, retrieve, store, append, delete, open, lookup and
             execute requests have the following data field:

                           <path name>

                    Rename request has the data field:

                           <path name> GS <name>

                    Addname and deletename requests have the data field:

                           <path name> GS <filenames>

             where pathname [10], name and filenames have the following
             syntax (expressed in BNF, the metalanguage of the ALGOL 60
             report):

             <pathname> ::= <device name>|<name>|<pathname>US<name>
             <device name> ::= DC1<name>

             <name> ::= <char> | <name> <char>
             <char> ::= All 8-bit ASCII or EBCDIC characters except

                     US, RS, GS, FS, DC1, DC2, AND DC3.

             <filenames> ::= <name>|<filenames> RS <name>

             The data type for the request transaction shall be either A
             (octal 101 for ASCII, or E (octal 105) for EBCDIC [11].

             Some examples of pathname are:

             DC1 MT08
             DC1 DSK 1.2 US Net<3> US J.Doe US Foo
             udd US proj. US h,n/x US user US file
             filename 1 filename 2

    Bhushan                                                         [Page 6]

    RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971

       2B.2  Responses

             The response transactions shall normally have an empty data
             field.

       2B.3  Transfers

             The data types defined in section 4 will govern the syntax of
             the data field in transfer transactions.  No other syntactical
             restrictions exist.

       2B.4  Terminates

             The successful terminate shall normally have an empty data
             field.  The unsuccessful terminate may have a data field
             defined by the data types A (octal 101) for ASCII, E (octal
             105) for EBCDIC, or S (octal 123) for status.

             A data type code of 'S' would imply byte oriented error return
             status codes in the data field.  The following error return
             status codes are defined tentatively:

             Error Code Meaning                        Error Code
                                                 ASCII   Octal  Hexadecimal

             Undefined error                       U       125     55
             Transaction type error                T       124     54
             Syntax error                          S       123     53
             File search failed                    F       106     46
             Data type error                       D       104     44
             Access denied                         A       101     41
             Improper transaction sequence         I       111     49
             Time-out error                        O       117     4F
             Error condition by system             E       105     45

       2C.   Semantics

       2C.1  Requests

             Requests are always sent by using host.  In absence of a device
             name or complete pathname, default options should be provided
             for all types of requests.

             _Identify_ request identifies the user as indicated by
             <pathname> from serving to using host.

             _Retrieve_ request achieves the transfer of file specified in
             <pathname> from serving to using host.

    Bhushan                                                         [Page 7]

    RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971

             _Store_  request achieves the transfer of file specified in
             <pathname> from using to serving host.

             _Append_ request causes data to be added to file specified in
             pathname.

             _Rename_ request causes name of file specified in <pathname> to
             be replaced by name specified in <name>.

             _Delete_ request causes file specified in <pathname> to be
             deleted.  If an extra level of protection for delete is desired
             (such as the query 'Do you wish to delete file x?'), it is to
             be a local implementation option.

             _Addname_ and _deletename_ requests cause names in <filenames>
             to be added or deleted to existing names of file specified in
             <pathname>.  These requests are useful in systems such as
             Multics which allow multiple names to be associated with a
             file.

             _Lookup_ request achieves the transfer of attributes (such as
             date last modified, access list, etc) of file specified in
             <pathname>, instead of the file itself.

             _Open_ request does not cause a data transfer, instead file
             specified in <pathname> is "opened" for retrieve (read) or
             store (write).  Subsequent requests are then treated as
             requests pertaining to the file that is opened till such a time
             that a close request is received.

             _Execute_ request achieves the execution of file specified in
             <pathname>, which must be an executable program.  Upon receipt
             of rr response, using host will transmit the necessary input
             data (parameters, arguments, etc).  Upon completion of
             execution serving host will send the results to using host and
             terminate [12].

       2C.2  Response

             Responses are always sent by serving host.  The rr response
             indicates that serving host is ready to receive the file
             indicated in the preceding request.  The rs response indicates
             that the next transaction from serving host will be the
             transfer of file indicated in the preceding request.

    Bhushan                                                         [Page 8]

    RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971

       2C.3  Transfers

             Transfers may be sent by either host.  Transfer transactions
             indicate the transfer of file indicated by a request.  Files
             can be transferred either as complete_file transactions or as
             part_of_file transactions followed by last_part transactions.
             The file may also have a heading transaction in the beginning.
             The syntax of a file, therefore, may be defined as:

             <file> ::= <text> | <heading> <text>
             <text> ::= <complete_file> | <parts> <last_part>
             <parts> ::= <part_of_file> | <parts> <part_of_file>

             Headings may be used to communicate the attributes of files.
             The form of headings is not formally specified but is discussed
             in Section IV as possible extension to this protocol.

       2C.4  Terminates

             The successful terminate is always sent by serving host.  It
             indicates to using host that serving host has been successful
             in serving the request and has gone to an initial state.  Using
             host will then inform user that his request is successfully
             served, and go to an initial state.

             The unsuccessful terminate may be sent by either host.  It
             indicates that sender of the terminate is unable to (or does
             not not wish to) go through with the request.  Both hosts will
             then go to their initial states.  The using host will inform
             the user that his request was aborted.  If any reasons for the
             unsuccessful terminate (either as text or as error return
             status codes) are received, these shall be communicated to the
             user.

    3.    Transaction Sequence

       3A.   The transaction sequence may be defined as an instance of file
             transfer, initiated by a request and ended by a terminate [13].
             The exact sequence in which transactions occur depends on the
             type of request.  A transaction sequence may be aborted anytime
             by either host, as explained in Section 3C.

       3B.   Examples

             The identify request doesn't require a response or terminate
             and constitutes a transaction sequence by itself.

    Bhushan                                                         [Page 9]

    RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971

             Rename, delete, addname, deletename and open requests involve
             no data transfer but require terminates.  The user sends the
             request and the server sends a successful or an unsuccessful
             terminate depending on whether or not he is successful in
             complying with the request.

             Retrieve and Lookup requests involve data transfer from the
             server to the user.  The user sends the request, the server
             responds with a rs, and transfers the data specified by the
             request.  Upon completion of the data transfer, the server
             terminates the transaction sequence with a successful terminate
             if all goes well, or with an unsuccessful terminate is errors
             were detected.

             Store and Append requests involve data transfer from the user
             to server.  The user sends the request and the server responds
             with a rr.  The user then transfers the data.  Upon receiving
             the data, the server terminates the sequence.

             Execute request involves transfer of inputs from user to
             server, and transfer of outputs from server to user.  The user
             sends the request to which the server responds with rr.  The
             user then transfers the necessary inputs.  The server
             "executes" the program or subroutine and transfers the outputs
             to the user.  Upon completion of the output transfer, the
             server terminates the transaction sequence.

       3C.   Aborts

             Either host may abort the transaction sequence at any time by
             sending an unsuccessful terminate, or by closing the connection
             (NCP to transmit a CLS for the connection).  The CLS is a more
             drastic type of abort and shall be used when there is a
             catastrophic failure or when an abort is desired in the middle
             of a long file transfer.  The abort indicates to the receiving
             host that the other host wishes to terminate the transaction
             sequence and is now in the initial state.  When CLS is used to
             abort, the using host will reopen the connection.

    4.    Data Types

       4A.   The data type code together with the extension code defines the
             manner in which the data field is to be parsed and interpreted
             [14].  Although a large number of data types are defined,
             specific implementations may handle only a limited subset of
             data types.  It is recommended that all host sites accept the

    Bhushan                                                        [Page 10]

    RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971

             "network ASCII" and "binary" data types.  Host computers which
             do not "recognize" particular data types may abort the
             transaction sequence and return a data type error status code.

       4B.   The following data types are tentatively defined.  The code in
             the type and extension field is represented by its ASCII
             equivalent with 8th bit as zero.

    Bhushan                                                        [Page 11]

    RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971

            Data Type                                    Code
                                         Byte Size       Type     Extension
    ASCII character, bit8=0 (network)       8             A          NUL

    ASCII characters, bit8=1                8             A          1

    ASCII characters, bit8=even parity      8             A          E

    ASCII characters, bit8=odd parity       8             A          O

    ASCII characters, 8th bit info.         8             A          8

    ASCII characters, 7 bits                7             A          7

    ASCII characters, in 9-bit field        9             A          9
    ASCII formatted files (with SOH,
            STX, ETX, etc.)                 8             A          F
    DEC-packed ASCII (5 7-bit char.,
            36th bit 1 or 0)                36            A          D
    EBCDIC characters                       8             E         NUL
    SIXBIT characters                       6             S         NUL
    Binary data                             1             B         NUL
    Binary bytes (size is binary ext.)      1-255         B        (any)
    Decimal numbers, net ASCII              8             D          A
    Decimal numbers, EBCDIC                 8             D          E
    Decimal numbers, sixbit                 6             D          S
    Decimal numbers, BCD (binary coded)     4             D          B
    Octal numbers, net. ASCII               8             O          A
    Octal numbers, EBCDIC                   8             O          E
    Octal numbers, SIXBIT                   6             O          S
    Hexadecimal numbers, net. ASCII         8             H          A
    Hexadecimal numbers, EBCDIC             8             H          E
    Hexadecimal numbers, SIXBIT             6             H          S
    Unsigned integers, binary (ext.
            field is byte size)             1-225         U        (any)
    Sign magnitude integers (field is
            binary size)                    1-255         I        (any)
    2's complement integers (ext.
            field is byte size)             1-255         2        (any)
    1's complement integers (ext.
            field is byte size)             1-255         1        (any)
    Floating point (IBM360)                 32            F          I
    Floating point (PDP-10)                 36            F          D
    Status codes                            8             S         NUL

    Bhushan                                                        [Page 12]

    RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971

       4C.   The data type information is intended to be interpretive.  If a
             host accepts a data type, it can interpret it to a form suited
             to its internal representation of characters or numbers [15].
             Specifically when no conversion is to be performed, the data
             type used will be binary.  The implicit or explicit byte size
             is useful as it facilitates storing of data.  For example, if a
             PDP-10 receives data types A, A1, AE, or A7, it can store the
             ASCII characters five to a word (DEC-packed ASCII).  If the
             datatype is A8 or A9, it would store the characters four to a
             word.  Sixbit characters would be stored six to a word.  If
             conversion routines are available on a system, the use of
             system program could convert the data from one form to another
             (such as EBCDIC to ASCII, IBM floating point to DEC floating
             point, Decimal ASCII to integers, etc.).

    5. Initial Connection, CLS, and Identifying Users

       5A.   There will be a prearranged socket number [16] for the
             cooperating process on the serving host.  The connection
             establishment will be in accordance with the initial connection
             protocol of RFC 66 as modified by RFC 80.  The NCP dialog would
             be:

                  user to server:    RTS<us><3><p>

             if accepted, server to user:    STR<3><us><CLS><3><us>
                  server to user on link p:  <ss>
                  server to user:    STR<ss+1><us>RTS<ss><us+1><q>
                  user to server:    STR<us><ss+1>RTS<us+1><ss><r>

             This sets up a full-duplex connection between user and server
             processes, with server receiving through local socket ss from
             remote socket us+1 via link q, and sending to remote socket us
             through local socket ss+1 via link r.

       5B.   The connection will be broken by trading a CLS between the
             NCP'S for each of the two connections.  Normally the user will
             initiate the CLS.

             CLS may also be used by either the user or the server to abort
             a data transmission in the middle.  If a CLS is received in the
             middle of a transaction sequence, the whole transaction
             sequence will be aborted.  The using host will then reopen the
             connection.

       5C.   The first transaction from the user to server will be the
             identify transaction.  The users will be identified by the
             pathname in data field of the transaction which should be a

    Bhushan                                                        [Page 13]

    RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971

             form acceptable to the server.  The server is at liberty to
             truncate pathnames for its own use.  Since the identify
             transaction does not require a response or terminate, the user
             can proceed directly with other requests.

    IV.  Extensions to Protocol

       The protocol specified above has been designed to be extendable.  The
       obvious extensions would be in the area of transaction types (new
       types of requests), error return status words, and data types.  Some
       of the non-obvious extensions, that I can visualize are provisions of
       access control mechanisms, developing a uniform way of specifying
       file attributes in headings of files, increasing the scope of the
       execute command to include subroutine mediation, and the provision of
       transaction sequence identification numbers to facilitate handling of
       multiple requests over the same connection pair.

       Users of protected file systems should be able to have a reasonable
       degree of confidence in the ability of the serving process to
       identify remote users correctly.  In the absence of such confidence,
       some users would not be willing to give access to the serving process
       (especially write access).  Inclusion of access control mechanisms
       such as passwords, is likely to enhance the indirect use of network
       by users who are concerned about privacy and security.  A simple
       extension to the protocol would be to have the serving host sent a
       transaction type "password?" after it receives user name.  Upon
       receipt of "password?" the using host will transmit the password,
       which when successfully acknowledged, would indicate to the user that
       requests may proceed.

       There are a number of file attributes which properly belong in the
       heading of a file rather than the file itself or the data type in
       descriptors of transactions.  Such attributes include access control
       lists, date file was last modified, information about the nature of
       file, and description of its contents in a data description or data
       reconfiguration language.  Some uniformity in the way file attributes
       are specified would be useful.  Until then, the interpretation of the
       heading would be up to the user or the using process.  For example,
       the heading of files which are input to a data reconfiguration (form)
       machine may be the desired transformations expressed in the
       reconfiguration language.

       The "execute" command which achieves the execution of programs
       resident in remote hosts is a vital part of indirect use of remote
       hosts.  The present scope of the execute command, as outlined in the
       specifications, is somewhat limited.  It assumes that the user or

    Bhushan                                                        [Page 14]

    RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971

       using process is aware of the manner in which the arguments and
       results should be exchanged.  One could broaden the scope of the
       execute command by introducing a program mediation protocol [17].

       The present specification of the protocol does not allow the
       simultaneous transfer and processing of multiple requests over the
       same pair of connections.  If such a capability is desired, there is
       an easy way to implement it which only involves a minor change.  A
       transaction sequence identification number (TSid) could replace a NUL
       field in the descriptor of transactions.  The TSid would facilitate
       the coordination of transactions, related to a particular transaction
       sequence.  The 256 code combinations permitted by the TSid would be
       used in a round-robin manner (I can't see more than 256 outstanding
       requests between two user-processes in any practical implementation).
       An alternate way of simultaneous processing of requests is to open
       new pairs of connection.  I am not sure as to how useful simultaneous
       processing of requests is, and which of the two is a more reasonable
       approach.

    V. Conclusions

       I tried to present a user-level protocol that will permit users and
       using programs to make indirect use of remote host computers.  The
       protocol facilitates not only file system operations but also program
       execution in remote hosts.  This is achieved by defining requests
       which are handled by cooperating processes.  The transaction sequence
       orientation provides greater assurance and would facilitate error
       control.  The notion of data types is introduced to facilitate the
       interpretation, reconfiguration and storage of simple and limited
       forms of data at individual host sites.  The protocol is readily
       extendible.

    Endnotes

       [1] The interim version of the protocol, limited to transfer of ASCII
       files, was developed by Chander Ramchandani and Howard Brodie of
       Project MAC.  The ideas of transactions, descriptors, error recovery,
       aborts, file headings and attributes, execution of programs, and use
       of data types, pathnames, and default mechanisms are new here.
       Howard Brodie and Neal Ryan have coded the interim protocol in the
       PDP-10 and the 645, respectively.

       [2] The network system survey was conducted last fall by Howard
       Brodie of Project MAC, primarily by telephone.

       [3] PDP-10 Reference Handbook, page 306.

    Bhushan                                                        [Page 15]

    RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971

       [4] We considered using two full-duplex links, one for control
       information, the other for data.  The use of a separate control link
       between the cooperating processes would simplify aborts, error
       recoveries and synchronization.  The synchronization function may
       alternatively be performed by closing the connection (in the middle
       of a transaction sequence) and reopening it with an abort message.
       (The use of INR and INS transmitted via the NCP control link has
       problems as mentioned by Kalin in RFC 103.)  We prefer the latter
       approach.

       [5] Identifying users through use of socket numbers is not practical,
       as unique user identification numbers have not been implemented, and
       file systems identify users by name, not number.

       [6] This subject is considered in detail by Bob Metcalfe in a
       forthcoming paper.

       [7] Filler bits may be necessary as particular implementations of
       NCP's may not allow the free communication of bits.  Instead the
       NCP's may only accept bytes, as suggested in RFC 102.  The filler
       count is needed to determine the boundary between transactions.

       [8] 72-bits in descriptor field are convenient as 72 is the least
       common multiple of 6, 8, 9, 18, 24 and 30, the commonly encountered
       byte sizes on the ARPA network host computers.

       [9] The execute request is intended to facilitate the indirect
       execution of programs and subroutines.  However, this request in its
       present form may have only limited use.  A subroutine or program
       mediation protocol would be required for broader use of the execute
       feature.  Metcalfe considers this problem in a forthcoming paper.

       [10] The pathname idea used in Multics is similar to that of labels
       in RFC 76 by Bouknight, Madden and Grossman.

       [11] We, however, urge the use of standard network ASCII.

       [12] The exact manner in which the input and output are transmitted
       would depend on specific mediation conventions.  Names of input and
       output files may be transmitted instead of data itself.

       [13] The transactions (including terminate) are not "echoed", as
       echoing does not solve any "hung" conditions.  Instead time-out
       mechanisms are recommended for avoiding hang-ups.

       [14] The data type mechanism suggested here does not replace data
       reconfiguration service suggested by Harslem and Heafner in RFC 83
       and NIC5772.  In fact, it complements the reconfiguration.  For

    Bhushan                                                        [Page 16]

    RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971

       example, data reconfiguration language can be expressed in EBCDIC,
       Network ASCII or any other code that form machine may "recognize".
       Subsequent data may be transmitted binary, and the form machine would
       reconfigure it to the required form.  I have included in data types,
       a large number suggested by Harslem and Heafner, as I do not wish to
       preclude interpretation, reconfiguration and storage of simple forms
       of data at individual host sites.

       [15] The internal character representation in the hosts may be
       different even in ASCII.  For example PDP-10 stores 7-bit characters,
       five per word with 36th bit as don't care, while Multics stores them
       four per word, right-justified in 9-bit fields.

       [16] It seems that socket 1 has been assigned to logger and socket 5
       to NETRJS.  Socket 3 seems a reasonable choice for the file transfer
       process.

       [17] The term program mediation was suggested by Bob Metcalfe who is
       intending to write a paper on this subject.

             [ This RFC was put into machine readable form for entry ]
                 [ into the online RFC archives by Ryan Kato 6/01]

    Bhushan                                                        [Page 17]