Network Working Group A. McKenzie Request for Comments: 454 BBN NIC: 14333 16 February 1973 FILE TRANSFER PROTOCOL Meeting Announcement and a New Proposed Document Attached is a new proposal for a File Transfer Protocol. The document is an extensive update to RFC 354 and, I believe, incorporates solutions to most of the objections to RFC 354. It now seems appropriate to make another attempt to reach final agreement on FTP. Accordingly, I am calling a meeting of interested parties, to be held at BBN on March 16, for discussion of this and other proposals. This note is directed to the network community at large, rather than specifically to the old FTP committee, because I don't believe that the FTP committee membership includes all the individuals who have contributed to the current state of FTP design. Nevertheless, it is intended that the meeting proceed from the current state, rather than bringing new members up-to-speed. Prospective attendees should therefore be familiar with at least the following documents: RFC 354 RFC 385 RFC 414 RFC 418 RFC 438 Anyone wishing to attend this meeting should contact Alex McKenzie (NIC Ident aam) at BBN, 50 Moulton Street, Cambridge, Mass. 02138. My telephone number is: (617) 491-1850 ext.441 When there is some indication of the number of individuals planning to attend, a meeting room will be reserved and more specific information will be directed to attendees. McKenzie [Page 1] RFC 454 File Transfer Protocol July 1972 PROPOSED FILE TRANSFER PROTOCOL This document is the outcome of a meeting held 25 January 1973 in Cambridge, Massachusetts, by the following people: Abhay Bhushan (MIT - DMCG) Bob Bressler (BBN - NET) Bob Clements (BBN - TENEX) Alex McKenzie (BBN - NET) Nancy Neigus (BBN - NET) Ken Pogran (MIT - MULTICS) Marc Seriff (MIT - DMCG) The basis of the document is RFC 354 with considerations drawn from RFC's 385, 414, 418, and 438 and personal communication with network participants. McKenzie [Page 2] RFC 454 File Transfer Protocol July 1972 PROPOSED FILE TRANSFER PROTOCOL INTRODUCTION The File Transfer Protocol (FTP) is a protocol for file transfer between HOSTs (including terminal IMPs), on the ARPA Computer Network (ARPANET). The primary function of FTP is to transfer files efficiently and reliably among HOSTs and to allow the convenient use of remote file storage capabilities. The objectives of FTP are 1) to promote sharing of files (computer programs and/or data), 2) to encourage indirect or implicit (via programs) use of remote computers, 3) to shield a user from variations in file storage systems among HOSTs, and 4) to transfer data reliably and efficiently. FTP, though usable directly by a user at a terminal, is designed mainly for use by programs. The attempt in this specification is to satisfy the diverse needs of users of maxi-HOSTs, mini-HOSTs, TIPs, and the Datacomputer, with a simple, elegant, and easily implemented protocol design. This paper assumes knowledge of the following protocols: 1) The HOST-HOST Protocol (NIC #8246) 2) The Initial Connection Protocol (NIC #7101) 3) The TELNET Protocol (NWG/RFC #318, NIC #9348) II. DISCUSSION In this section, the terminology and the FTP model are discussed. The terms defined in this section are only those that have special significance in FTP. II.A Terminology ASCII The USASCII character set as defined in NIC #7104. In FTP, ASCII characters are defined to be the lower half of an eight bit code set (i.e., the most significant bit is zero). access controls Access controls define users' access privileges to the use of a system, and to the files in that system. Access controls are necessary to prevent unauthorized or accidental use of files. It is the prerogative of a server-FTP process to provide access controls. McKenzie [Page 3] RFC 454 File Transfer Protocol July 1972 byte size The byte size specified for the transfer od data. The data connection is opened with this byte size. Data connection byte size is not necessarily the byte size in which data is to be stored in a system, and may not be related to the structure of data. data connection A simplex connection over which data is transferred, in a specified byte size, mode and type. The data transferred may be a part of a file, an entire file or a number of files. The data connection may be in either direction (server-to-user or user-to-server). data socket The socket on which a User-FTP process "listens" for a data connection. EOF The end-of-file condition that defines the end of a file being transferred. EOR The end-of-record condition that defines the end of a record being transferred. error recovery A procedure that allows a user to recover from certain errors such as failure of either HOST system or transfer process. In FTP, error recovery may involve restarting a file transfer at a given checkpoint. FTP commands A set of commands that comprise the control information flowing from the user-FTP to the server-FTP process. file An ordered set of computer data (including programs) of arbitrary length uniquely identified by a pathname. mode The mode in which data is to be transferred via the data connection. The mode defines the data format including EOR and EOF. The transfer modes defined in FTP are described in Section III.C. NVT The Network Virtual Terminal as defined in the ARPANET TELNET Protocol. McKenzie [Page 4] RFC 454 File Transfer Protocol July 1972 NVFS The Network Virtual File System. A concept which defines a standard network file system with standard commands and pathname conventions. FTP only partially embraces the NVFS concept at this time. pathname Pathname is defined to be the character string which must be input to a file system by a user in order to identify a file. Pathname normally contains device and/or directory names, and file name specification. FTP does not yet specify a standard pathname convention. Each user must follow the file naming conventions of the file systems he wishes to use. record A sequential file may be structured as a number of contiguous parts called records. Record structures are supported by FTP but are not mandatory. reply A reply is an acknowledgement (positive or negative) sent from server to user via the TELNET connections in response to FTP commands. The general form of a reply is a completion code (including error codes) followed by an ASCII text string. The codes are for use by programs and the text is for human users. server-FTP process A process or set of processes which perform the function of file transfer in cooperation with a user-FTP process. The server-FTP process must interpret and respond to user commands and initiate the data connection. server site A HOST site which has a server-FTP process. server-TELNET A TELNET process which listens on a specified socket for an ICP initiated by a user-TELNET, and performs in accordance with the ARPANET TELNET Protocol. TELNET connections The full-duplex communication path between a user-TELNET and a server-TELNET. The TELNET connections are established via the standard ARPANET Initial Connection Protocol (ICP). McKenzie [Page 5] RFC 454 File Transfer Protocol July 1972 type The data representation type used for data transfer and storage. Type implies certain transformations between the time of data storage and data transfer. The representation types defined in FTP are described in Section III.B. user A process on behalf of a human being or a human being wishing to obtain file transfer service. user site A HOST site satisfying any of the following conditions: 1) The site where a user is located, 2) a site where a user-FTP process is located, 3) a site to which a data connection is made by a server. In the normal case, the sites defined by 1, 2, and 3 are the same site, but nothing in FTP requires that this be so. user-FTP process A process or set of processes which perform the function of file transfer in cooperation with a server-FTP process. The user-FTP process 1) initiates the ICP (via a user-TELNET), 2) initiates FTP commands and 3) "listens" on the data socket for the data connection. In some obvious cases (use from TIPs and other mini- HOSTs) a user-FTP process will be subsumed under the term "user". user-TELNET A TELNET process which initiates an ICP to a specified server-TELNET socket, and performs in accordance with the ARPANET TELNET protocol. II.B The FTP Model With the above definitions in mind, the following model (shown in Figure 1) may be diagramed for an FTP service. In the model described in Figure 1, the user-TELNET initiates the TELNET connections. Standard FTP commands are then generated by the user and transmitted to the server site via the TELNET connections. FTP commands are in ASCII, in accordance with NVT conventions and the TELNET protocol. Note that commands may be initiated by the user directly through the user-TELNET or via a user-FTP process. Standard replies are sent from the server to the user in response to the commands over the TELNET connections. McKenzie [Page 6] RFC 454 File Transfer Protocol July 1972 The FTP commands specify the parameters for the data connection (data socket, byte size, transfer mode, representation type, and format) and the nature of file system operation (store, retrieve, append, delete, etc.). The user-FTP process or its designate should "listen" on the specified data socket, and it is the server's responsibility to initiate the data connection and data transfer in accordance with the specified data connection parameters. It should be noted that the data socket need not be in the same HOST that initiates the FTP commands via the TELNET connections, but the user or his user-FTP process must ensure a "listen" on the specified data socket. A practical example of such file transfer to third HOSTs is a maxi-HOST user (who may actually be a TIP user) wishing to transmit a file to or from an I/O device attached to a TIP. It should also be noted that two data connections, one for send and the other for receive, may exist simultaneously. TELNET Connections +-----+ +-------+ +------+ +------+ +-------+ +-----+ | File|<->|Server-|<->|Server|<----------|User |<->|User- |<->|File | |Sys | |FTP | |TELNET| FTP Cmds |TELNET| |FTP | |Sys- | | -tem| |Process| | |---------->| | |Process| | tem | +-----+ | | +------+FTP Replies+------+ | | +-----+ | | | | | |<------------------------------->|Data | | | Data Connection(s) |Socket | +-------+ +-------+ | | +------+ | | | USER | | | +------+ Notes: 1. The data connection may be in either direction. 2. The data connection need not exist all of the time. 3. The distinctions between user-FTP and user-TELNET, and between server-FTP and server-TELNET may not be as clear-cut as shown above. For example, a user-TELNET may be directly driven by the user. FIGURE 1 Model for FTP Use McKenzie [Page 7] RFC 454 File Transfer Protocol July 1972 The protocol requires that the TELNET connections be open while data transfer is in progress. It is the responsibility of the user to close the TELNET connections when finished using the FTP service. The server may abort data transfer if the TELNET connections are closed. III. DATA TRANSFER FUNCTIONS Data and files are transferred only via the data connection. The transfer of data is governed by FTP data transfer commands received on the TELNET connections. The data transfer functions include establishing the data connection to the specified data socket in the specified HOST (using the specified byte size), transmitting and receiving data in the specified representation type and transfer mode, handling EOR and EOF conditions, and error recovery (where applicable). III.A Establishing Data Connection The user site shall "listen" on the specified data socket, prior to sending a transfer request command. The FTP request command determines the direction of data transfer, and the socket number (odd or even) which is to be used in establishing the data connection. The server on receivin