michael@0: michael@0: michael@0: Network Working Group J. Postel michael@0: Request for Comments: 959 J. Reynolds michael@0: ISI michael@0: Obsoletes RFC: 765 (IEN 149) October 1985 michael@0: michael@0: FILE TRANSFER PROTOCOL (FTP) michael@0: michael@0: michael@0: Status of this Memo michael@0: michael@0: This memo is the official specification of the File Transfer michael@0: Protocol (FTP). Distribution of this memo is unlimited. michael@0: michael@0: The following new optional commands are included in this edition of michael@0: the specification: michael@0: michael@0: CDUP (Change to Parent Directory), SMNT (Structure Mount), STOU michael@0: (Store Unique), RMD (Remove Directory), MKD (Make Directory), PWD michael@0: (Print Directory), and SYST (System). michael@0: michael@0: Note that this specification is compatible with the previous edition. michael@0: michael@0: 1. INTRODUCTION michael@0: michael@0: The objectives of FTP are 1) to promote sharing of files (computer michael@0: programs and/or data), 2) to encourage indirect or implicit (via michael@0: programs) use of remote computers, 3) to shield a user from michael@0: variations in file storage systems among hosts, and 4) to transfer michael@0: data reliably and efficiently. FTP, though usable directly by a user michael@0: at a terminal, is designed mainly for use by programs. michael@0: michael@0: The attempt in this specification is to satisfy the diverse needs of michael@0: users of maxi-hosts, mini-hosts, personal workstations, and TACs, michael@0: with a simple, and easily implemented protocol design. michael@0: michael@0: This paper assumes knowledge of the Transmission Control Protocol michael@0: (TCP) [2] and the Telnet Protocol [3]. These documents are contained michael@0: in the ARPA-Internet protocol handbook [1]. michael@0: michael@0: 2. OVERVIEW michael@0: michael@0: In this section, the history, the terminology, and the FTP model are michael@0: discussed. The terms defined in this section are only those that michael@0: have special significance in FTP. Some of the terminology is very michael@0: specific to the FTP model; some readers may wish to turn to the michael@0: section on the FTP model while reviewing the terminology. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 1] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: 2.1. HISTORY michael@0: michael@0: FTP has had a long evolution over the years. Appendix III is a michael@0: chronological compilation of Request for Comments documents michael@0: relating to FTP. These include the first proposed file transfer michael@0: mechanisms in 1971 that were developed for implementation on hosts michael@0: at M.I.T. (RFC 114), plus comments and discussion in RFC 141. michael@0: michael@0: RFC 172 provided a user-level oriented protocol for file transfer michael@0: between host computers (including terminal IMPs). A revision of michael@0: this as RFC 265, restated FTP for additional review, while RFC 281 michael@0: suggested further changes. The use of a "Set Data Type" michael@0: transaction was proposed in RFC 294 in January 1982. michael@0: michael@0: RFC 354 obsoleted RFCs 264 and 265. The File Transfer Protocol michael@0: was now defined as a protocol for file transfer between HOSTs on michael@0: the ARPANET, with the primary function of FTP defined as michael@0: transfering files efficiently and reliably among hosts and michael@0: allowing the convenient use of remote file storage capabilities. michael@0: RFC 385 further commented on errors, emphasis points, and michael@0: additions to the protocol, while RFC 414 provided a status report michael@0: on the working server and user FTPs. RFC 430, issued in 1973, michael@0: (among other RFCs too numerous to mention) presented further michael@0: comments on FTP. Finally, an "official" FTP document was michael@0: published as RFC 454. michael@0: michael@0: By July 1973, considerable changes from the last versions of FTP michael@0: were made, but the general structure remained the same. RFC 542 michael@0: was published as a new "official" specification to reflect these michael@0: changes. However, many implementations based on the older michael@0: specification were not updated. michael@0: michael@0: In 1974, RFCs 607 and 614 continued comments on FTP. RFC 624 michael@0: proposed further design changes and minor modifications. In 1975, michael@0: RFC 686 entitled, "Leaving Well Enough Alone", discussed the michael@0: differences between all of the early and later versions of FTP. michael@0: RFC 691 presented a minor revision of RFC 686, regarding the michael@0: subject of print files. michael@0: michael@0: Motivated by the transition from the NCP to the TCP as the michael@0: underlying protocol, a phoenix was born out of all of the above michael@0: efforts in RFC 765 as the specification of FTP for use on TCP. michael@0: michael@0: This current edition of the FTP specification is intended to michael@0: correct some minor documentation errors, to improve the michael@0: explanation of some protocol features, and to add some new michael@0: optional commands. michael@0: michael@0: michael@0: Postel & Reynolds [Page 2] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: In particular, the following new optional commands are included in michael@0: this edition of the specification: michael@0: michael@0: CDUP - Change to Parent Directory michael@0: michael@0: SMNT - Structure Mount michael@0: michael@0: STOU - Store Unique michael@0: michael@0: RMD - Remove Directory michael@0: michael@0: MKD - Make Directory michael@0: michael@0: PWD - Print Directory michael@0: michael@0: SYST - System michael@0: michael@0: This specification is compatible with the previous edition. A michael@0: program implemented in conformance to the previous specification michael@0: should automatically be in conformance to this specification. michael@0: michael@0: 2.2. TERMINOLOGY michael@0: michael@0: ASCII michael@0: michael@0: The ASCII character set is as defined in the ARPA-Internet michael@0: Protocol Handbook. In FTP, ASCII characters are defined to be michael@0: the lower half of an eight-bit code set (i.e., the most michael@0: significant bit is zero). michael@0: michael@0: access controls michael@0: michael@0: Access controls define users' access privileges to the use of a michael@0: system, and to the files in that system. Access controls are michael@0: necessary to prevent unauthorized or accidental use of files. michael@0: It is the prerogative of a server-FTP process to invoke access michael@0: controls. michael@0: michael@0: byte size michael@0: michael@0: There are two byte sizes of interest in FTP: the logical byte michael@0: size of the file, and the transfer byte size used for the michael@0: transmission of the data. The transfer byte size is always 8 michael@0: bits. The transfer byte size is not necessarily the byte size michael@0: in which data is to be stored in a system, nor the logical byte michael@0: size for interpretation of the structure of the data. michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 3] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: control connection michael@0: michael@0: The communication path between the USER-PI and SERVER-PI for michael@0: the exchange of commands and replies. This connection follows michael@0: the Telnet Protocol. michael@0: michael@0: data connection michael@0: michael@0: A full duplex connection over which data is transferred, in a michael@0: specified mode and type. The data transferred may be a part of michael@0: a file, an entire file or a number of files. The path may be michael@0: between a server-DTP and a user-DTP, or between two michael@0: server-DTPs. michael@0: michael@0: data port michael@0: michael@0: The passive data transfer process "listens" on the data port michael@0: for a connection from the active transfer process in order to michael@0: open the data connection. michael@0: michael@0: DTP michael@0: michael@0: The data transfer process establishes and manages the data michael@0: connection. The DTP can be passive or active. michael@0: michael@0: End-of-Line michael@0: michael@0: The end-of-line sequence defines the separation of printing michael@0: lines. The sequence is Carriage Return, followed by Line Feed. michael@0: michael@0: EOF michael@0: michael@0: The end-of-file condition that defines the end of a file being michael@0: transferred. michael@0: michael@0: EOR michael@0: michael@0: The end-of-record condition that defines the end of a record michael@0: being transferred. michael@0: michael@0: error recovery michael@0: michael@0: A procedure that allows a user to recover from certain errors michael@0: such as failure of either host system or transfer process. In michael@0: FTP, error recovery may involve restarting a file transfer at a michael@0: given checkpoint. michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 4] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: FTP commands michael@0: michael@0: A set of commands that comprise the control information flowing michael@0: from the user-FTP to the server-FTP process. michael@0: michael@0: file michael@0: michael@0: An ordered set of computer data (including programs), of michael@0: arbitrary length, uniquely identified by a pathname. michael@0: michael@0: mode michael@0: michael@0: The mode in which data is to be transferred via the data michael@0: connection. The mode defines the data format during transfer michael@0: including EOR and EOF. The transfer modes defined in FTP are michael@0: described in the Section on Transmission Modes. michael@0: michael@0: NVT michael@0: michael@0: The Network Virtual Terminal as defined in the Telnet Protocol. michael@0: michael@0: NVFS michael@0: michael@0: The Network Virtual File System. A concept which defines a michael@0: standard network file system with standard commands and michael@0: pathname conventions. michael@0: michael@0: page michael@0: michael@0: A file may be structured as a set of independent parts called michael@0: pages. FTP supports the transmission of discontinuous files as michael@0: independent indexed pages. michael@0: michael@0: pathname michael@0: michael@0: Pathname is defined to be the character string which must be michael@0: input to a file system by a user in order to identify a file. michael@0: Pathname normally contains device and/or directory names, and michael@0: file name specification. FTP does not yet specify a standard michael@0: pathname convention. Each user must follow the file naming michael@0: conventions of the file systems involved in the transfer. michael@0: michael@0: PI michael@0: michael@0: The protocol interpreter. The user and server sides of the michael@0: protocol have distinct roles implemented in a user-PI and a michael@0: server-PI. michael@0: michael@0: michael@0: Postel & Reynolds [Page 5] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: record michael@0: michael@0: A sequential file may be structured as a number of contiguous michael@0: parts called records. Record structures are supported by FTP michael@0: but a file need not have record structure. michael@0: michael@0: reply michael@0: michael@0: A reply is an acknowledgment (positive or negative) sent from michael@0: server to user via the control connection in response to FTP michael@0: commands. The general form of a reply is a completion code michael@0: (including error codes) followed by a text string. The codes michael@0: are for use by programs and the text is usually intended for michael@0: human users. michael@0: michael@0: server-DTP michael@0: michael@0: The data transfer process, in its normal "active" state, michael@0: establishes the data connection with the "listening" data port. michael@0: It sets up parameters for transfer and storage, and transfers michael@0: data on command from its PI. The DTP can be placed in a michael@0: "passive" state to listen for, rather than initiate a michael@0: connection on the data port. michael@0: michael@0: server-FTP process michael@0: michael@0: A process or set of processes which perform the function of michael@0: file transfer in cooperation with a user-FTP process and, michael@0: possibly, another server. The functions consist of a protocol michael@0: interpreter (PI) and a data transfer process (DTP). michael@0: michael@0: server-PI michael@0: michael@0: The server protocol interpreter "listens" on Port L for a michael@0: connection from a user-PI and establishes a control michael@0: communication connection. It receives standard FTP commands michael@0: from the user-PI, sends replies, and governs the server-DTP. michael@0: michael@0: type michael@0: michael@0: The data representation type used for data transfer and michael@0: storage. Type implies certain transformations between the time michael@0: of data storage and data transfer. The representation types michael@0: defined in FTP are described in the Section on Establishing michael@0: Data Connections. michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 6] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: user michael@0: michael@0: A person or a process on behalf of a person wishing to obtain michael@0: file transfer service. The human user may interact directly michael@0: with a server-FTP process, but use of a user-FTP process is michael@0: preferred since the protocol design is weighted towards michael@0: automata. michael@0: michael@0: user-DTP michael@0: michael@0: The data transfer process "listens" on the data port for a michael@0: connection from a server-FTP process. If two servers are michael@0: transferring data between them, the user-DTP is inactive. michael@0: michael@0: user-FTP process michael@0: michael@0: A set of functions including a protocol interpreter, a data michael@0: transfer process and a user interface which together perform michael@0: the function of file transfer in cooperation with one or more michael@0: server-FTP processes. The user interface allows a local michael@0: language to be used in the command-reply dialogue with the michael@0: user. michael@0: michael@0: user-PI michael@0: michael@0: The user protocol interpreter initiates the control connection michael@0: from its port U to the server-FTP process, initiates FTP michael@0: commands, and governs the user-DTP if that process is part of michael@0: the file transfer. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 7] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: 2.3. THE FTP MODEL michael@0: michael@0: With the above definitions in mind, the following model (shown in michael@0: Figure 1) may be diagrammed for an FTP service. michael@0: michael@0: ------------- michael@0: |/---------\| michael@0: || User || -------- michael@0: ||Interface|<--->| User | michael@0: |\----^----/| -------- michael@0: ---------- | | | michael@0: |/------\| FTP Commands |/----V----\| michael@0: ||Server|<---------------->| User || michael@0: || PI || FTP Replies || PI || michael@0: |\--^---/| |\----^----/| michael@0: | | | | | | michael@0: -------- |/--V---\| Data |/----V----\| -------- michael@0: | File |<--->|Server|<---------------->| User |<--->| File | michael@0: |System| || DTP || Connection || DTP || |System| michael@0: -------- |\------/| |\---------/| -------- michael@0: ---------- ------------- michael@0: michael@0: Server-FTP USER-FTP michael@0: michael@0: NOTES: 1. The data connection may be used in either direction. michael@0: 2. The data connection need not exist all of the time. michael@0: michael@0: Figure 1 Model for FTP Use michael@0: michael@0: In the model described in Figure 1, the user-protocol interpreter michael@0: initiates the control connection. The control connection follows michael@0: the Telnet protocol. At the initiation of the user, standard FTP michael@0: commands are generated by the user-PI and transmitted to the michael@0: server process via the control connection. (The user may michael@0: establish a direct control connection to the server-FTP, from a michael@0: TAC terminal for example, and generate standard FTP commands michael@0: independently, bypassing the user-FTP process.) Standard replies michael@0: are sent from the server-PI to the user-PI over the control michael@0: connection in response to the commands. michael@0: michael@0: The FTP commands specify the parameters for the data connection michael@0: (data port, transfer mode, representation type, and structure) and michael@0: the nature of file system operation (store, retrieve, append, michael@0: delete, etc.). The user-DTP or its designate should "listen" on michael@0: the specified data port, and the server initiate the data michael@0: connection and data transfer in accordance with the specified michael@0: parameters. It should be noted that the data port need not be in michael@0: michael@0: michael@0: Postel & Reynolds [Page 8] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: the same host that initiates the FTP commands via the control michael@0: connection, but the user or the user-FTP process must ensure a michael@0: "listen" on the specified data port. It ought to also be noted michael@0: that the data connection may be used for simultaneous sending and michael@0: receiving. michael@0: michael@0: In another situation a user might wish to transfer files between michael@0: two hosts, neither of which is a local host. The user sets up michael@0: control connections to the two servers and then arranges for a michael@0: data connection between them. In this manner, control information michael@0: is passed to the user-PI but data is transferred between the michael@0: server data transfer processes. Following is a model of this michael@0: server-server interaction. michael@0: michael@0: michael@0: Control ------------ Control michael@0: ---------->| User-FTP |<----------- michael@0: | | User-PI | | michael@0: | | "C" | | michael@0: V ------------ V michael@0: -------------- -------------- michael@0: | Server-FTP | Data Connection | Server-FTP | michael@0: | "A" |<---------------------->| "B" | michael@0: -------------- Port (A) Port (B) -------------- michael@0: michael@0: michael@0: Figure 2 michael@0: michael@0: The protocol requires that the control connections be open while michael@0: data transfer is in progress. It is the responsibility of the michael@0: user to request the closing of the control connections when michael@0: finished using the FTP service, while it is the server who takes michael@0: the action. The server may abort data transfer if the control michael@0: connections are closed without command. michael@0: michael@0: The Relationship between FTP and Telnet: michael@0: michael@0: The FTP uses the Telnet protocol on the control connection. michael@0: This can be achieved in two ways: first, the user-PI or the michael@0: server-PI may implement the rules of the Telnet Protocol michael@0: directly in their own procedures; or, second, the user-PI or michael@0: the server-PI may make use of the existing Telnet module in the michael@0: system. michael@0: michael@0: Ease of implementaion, sharing code, and modular programming michael@0: argue for the second approach. Efficiency and independence michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 9] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: argue for the first approach. In practice, FTP relies on very michael@0: little of the Telnet Protocol, so the first approach does not michael@0: necessarily involve a large amount of code. michael@0: michael@0: 3. DATA TRANSFER FUNCTIONS michael@0: michael@0: Files are transferred only via the data connection. The control michael@0: connection is used for the transfer of commands, which describe the michael@0: functions to be performed, and the replies to these commands (see the michael@0: Section on FTP Replies). Several commands are concerned with the michael@0: transfer of data between hosts. These data transfer commands include michael@0: the MODE command which specify how the bits of the data are to be michael@0: transmitted, and the STRUcture and TYPE commands, which are used to michael@0: define the way in which the data are to be represented. The michael@0: transmission and representation are basically independent but the michael@0: "Stream" transmission mode is dependent on the file structure michael@0: attribute and if "Compressed" transmission mode is used, the nature michael@0: of the filler byte depends on the representation type. michael@0: michael@0: 3.1. DATA REPRESENTATION AND STORAGE michael@0: michael@0: Data is transferred from a storage device in the sending host to a michael@0: storage device in the receiving host. Often it is necessary to michael@0: perform certain transformations on the data because data storage michael@0: representations in the two systems are different. For example, michael@0: NVT-ASCII has different data storage representations in different michael@0: systems. DEC TOPS-20s's generally store NVT-ASCII as five 7-bit michael@0: ASCII characters, left-justified in a 36-bit word. IBM Mainframe's michael@0: store NVT-ASCII as 8-bit EBCDIC codes. Multics stores NVT-ASCII michael@0: as four 9-bit characters in a 36-bit word. It is desirable to michael@0: convert characters into the standard NVT-ASCII representation when michael@0: transmitting text between dissimilar systems. The sending and michael@0: receiving sites would have to perform the necessary michael@0: transformations between the standard representation and their michael@0: internal representations. michael@0: michael@0: A different problem in representation arises when transmitting michael@0: binary data (not character codes) between host systems with michael@0: different word lengths. It is not always clear how the sender michael@0: should send data, and the receiver store it. For example, when michael@0: transmitting 32-bit bytes from a 32-bit word-length system to a michael@0: 36-bit word-length system, it may be desirable (for reasons of michael@0: efficiency and usefulness) to store the 32-bit bytes michael@0: right-justified in a 36-bit word in the latter system. In any michael@0: case, the user should have the option of specifying data michael@0: representation and transformation functions. It should be noted michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 10] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: that FTP provides for very limited data type representations. michael@0: Transformations desired beyond this limited capability should be michael@0: performed by the user directly. michael@0: michael@0: 3.1.1. DATA TYPES michael@0: michael@0: Data representations are handled in FTP by a user specifying a michael@0: representation type. This type may implicitly (as in ASCII or michael@0: EBCDIC) or explicitly (as in Local byte) define a byte size for michael@0: interpretation which is referred to as the "logical byte size." michael@0: Note that this has nothing to do with the byte size used for michael@0: transmission over the data connection, called the "transfer michael@0: byte size", and the two should not be confused. For example, michael@0: NVT-ASCII has a logical byte size of 8 bits. If the type is michael@0: Local byte, then the TYPE command has an obligatory second michael@0: parameter specifying the logical byte size. The transfer byte michael@0: size is always 8 bits. michael@0: michael@0: 3.1.1.1. ASCII TYPE michael@0: michael@0: This is the default type and must be accepted by all FTP michael@0: implementations. It is intended primarily for the transfer michael@0: of text files, except when both hosts would find the EBCDIC michael@0: type more convenient. michael@0: michael@0: The sender converts the data from an internal character michael@0: representation to the standard 8-bit NVT-ASCII michael@0: representation (see the Telnet specification). The receiver michael@0: will convert the data from the standard form to his own michael@0: internal form. michael@0: michael@0: In accordance with the NVT standard, the sequence michael@0: should be used where necessary to denote the end of a line michael@0: of text. (See the discussion of file structure at the end michael@0: of the Section on Data Representation and Storage.) michael@0: michael@0: Using the standard NVT-ASCII representation means that data michael@0: must be interpreted as 8-bit bytes. michael@0: michael@0: The Format parameter for ASCII and EBCDIC types is discussed michael@0: below. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 11] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: 3.1.1.2. EBCDIC TYPE michael@0: michael@0: This type is intended for efficient transfer between hosts michael@0: which use EBCDIC for their internal character michael@0: representation. michael@0: michael@0: For transmission, the data are represented as 8-bit EBCDIC michael@0: characters. The character code is the only difference michael@0: between the functional specifications of EBCDIC and ASCII michael@0: types. michael@0: michael@0: End-of-line (as opposed to end-of-record--see the discussion michael@0: of structure) will probably be rarely used with EBCDIC type michael@0: for purposes of denoting structure, but where it is michael@0: necessary the character should be used. michael@0: michael@0: 3.1.1.3. IMAGE TYPE michael@0: michael@0: The data are sent as contiguous bits which, for transfer, michael@0: are packed into the 8-bit transfer bytes. The receiving michael@0: site must store the data as contiguous bits. The structure michael@0: of the storage system might necessitate the padding of the michael@0: file (or of each record, for a record-structured file) to michael@0: some convenient boundary (byte, word or block). This michael@0: padding, which must be all zeros, may occur only at the end michael@0: of the file (or at the end of each record) and there must be michael@0: a way of identifying the padding bits so that they may be michael@0: stripped off if the file is retrieved. The padding michael@0: transformation should be well publicized to enable a user to michael@0: process a file at the storage site. michael@0: michael@0: Image type is intended for the efficient storage and michael@0: retrieval of files and for the transfer of binary data. It michael@0: is recommended that this type be accepted by all FTP michael@0: implementations. michael@0: michael@0: 3.1.1.4. LOCAL TYPE michael@0: michael@0: The data is transferred in logical bytes of the size michael@0: specified by the obligatory second parameter, Byte size. michael@0: The value of Byte size must be a decimal integer; there is michael@0: no default value. The logical byte size is not necessarily michael@0: the same as the transfer byte size. If there is a michael@0: difference in byte sizes, then the logical bytes should be michael@0: packed contiguously, disregarding transfer byte boundaries michael@0: and with any necessary padding at the end. michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 12] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: When the data reaches the receiving host, it will be michael@0: transformed in a manner dependent on the logical byte size michael@0: and the particular host. This transformation must be michael@0: invertible (i.e., an identical file can be retrieved if the michael@0: same parameters are used) and should be well publicized by michael@0: the FTP implementors. michael@0: michael@0: For example, a user sending 36-bit floating-point numbers to michael@0: a host with a 32-bit word could send that data as Local byte michael@0: with a logical byte size of 36. The receiving host would michael@0: then be expected to store the logical bytes so that they michael@0: could be easily manipulated; in this example putting the michael@0: 36-bit logical bytes into 64-bit double words should michael@0: suffice. michael@0: michael@0: In another example, a pair of hosts with a 36-bit word size michael@0: may send data to one another in words by using TYPE L 36. michael@0: The data would be sent in the 8-bit transmission bytes michael@0: packed so that 9 transmission bytes carried two host words. michael@0: michael@0: 3.1.1.5. FORMAT CONTROL michael@0: michael@0: The types ASCII and EBCDIC also take a second (optional) michael@0: parameter; this is to indicate what kind of vertical format michael@0: control, if any, is associated with a file. The following michael@0: data representation types are defined in FTP: michael@0: michael@0: A character file may be transferred to a host for one of michael@0: three purposes: for printing, for storage and later michael@0: retrieval, or for processing. If a file is sent for michael@0: printing, the receiving host must know how the vertical michael@0: format control is represented. In the second case, it must michael@0: be possible to store a file at a host and then retrieve it michael@0: later in exactly the same form. Finally, it should be michael@0: possible to move a file from one host to another and process michael@0: the file at the second host without undue trouble. A single michael@0: ASCII or EBCDIC format does not satisfy all these michael@0: conditions. Therefore, these types have a second parameter michael@0: specifying one of the following three formats: michael@0: michael@0: 3.1.1.5.1. NON PRINT michael@0: michael@0: This is the default format to be used if the second michael@0: (format) parameter is omitted. Non-print format must be michael@0: accepted by all FTP implementations. michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 13] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: The file need contain no vertical format information. If michael@0: it is passed to a printer process, this process may michael@0: assume standard values for spacing and margins. michael@0: michael@0: Normally, this format will be used with files destined michael@0: for processing or just storage. michael@0: michael@0: 3.1.1.5.2. TELNET FORMAT CONTROLS michael@0: michael@0: The file contains ASCII/EBCDIC vertical format controls michael@0: (i.e., , , , , ) which the printer michael@0: process will interpret appropriately. , in exactly michael@0: this sequence, also denotes end-of-line. michael@0: michael@0: 3.1.1.5.2. CARRIAGE CONTROL (ASA) michael@0: michael@0: The file contains ASA (FORTRAN) vertical format control michael@0: characters. (See RFC 740 Appendix C; and Communications michael@0: of the ACM, Vol. 7, No. 10, p. 606, October 1964.) In a michael@0: line or a record formatted according to the ASA Standard, michael@0: the first character is not to be printed. Instead, it michael@0: should be used to determine the vertical movement of the michael@0: paper which should take place before the rest of the michael@0: record is printed. michael@0: michael@0: The ASA Standard specifies the following control michael@0: characters: michael@0: michael@0: Character Vertical Spacing michael@0: michael@0: blank Move paper up one line michael@0: 0 Move paper up two lines michael@0: 1 Move paper to top of next page michael@0: + No movement, i.e., overprint michael@0: michael@0: Clearly there must be some way for a printer process to michael@0: distinguish the end of the structural entity. If a file michael@0: has record structure (see below) this is no problem; michael@0: records will be explicitly marked during transfer and michael@0: storage. If the file has no record structure, the michael@0: end-of-line sequence is used to separate printing lines, michael@0: but these format effectors are overridden by the ASA michael@0: controls. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 14] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: 3.1.2. DATA STRUCTURES michael@0: michael@0: In addition to different representation types, FTP allows the michael@0: structure of a file to be specified. Three file structures are michael@0: defined in FTP: michael@0: michael@0: file-structure, where there is no internal structure and michael@0: the file is considered to be a michael@0: continuous sequence of data bytes, michael@0: michael@0: record-structure, where the file is made up of sequential michael@0: records, michael@0: michael@0: and page-structure, where the file is made up of independent michael@0: indexed pages. michael@0: michael@0: File-structure is the default to be assumed if the STRUcture michael@0: command has not been used but both file and record structures michael@0: must be accepted for "text" files (i.e., files with TYPE ASCII michael@0: or EBCDIC) by all FTP implementations. The structure of a file michael@0: will affect both the transfer mode of a file (see the Section michael@0: on Transmission Modes) and the interpretation and storage of michael@0: the file. michael@0: michael@0: The "natural" structure of a file will depend on which host michael@0: stores the file. A source-code file will usually be stored on michael@0: an IBM Mainframe in fixed length records but on a DEC TOPS-20 michael@0: as a stream of characters partitioned into lines, for example michael@0: by . If the transfer of files between such disparate michael@0: sites is to be useful, there must be some way for one site to michael@0: recognize the other's assumptions about the file. michael@0: michael@0: With some sites being naturally file-oriented and others michael@0: naturally record-oriented there may be problems if a file with michael@0: one structure is sent to a host oriented to the other. If a michael@0: text file is sent with record-structure to a host which is file michael@0: oriented, then that host should apply an internal michael@0: transformation to the file based on the record structure. michael@0: Obviously, this transformation should be useful, but it must michael@0: also be invertible so that an identical file may be retrieved michael@0: using record structure. michael@0: michael@0: In the case of a file being sent with file-structure to a michael@0: record-oriented host, there exists the question of what michael@0: criteria the host should use to divide the file into records michael@0: which can be processed locally. If this division is necessary, michael@0: the FTP implementation should use the end-of-line sequence, michael@0: michael@0: michael@0: Postel & Reynolds [Page 15] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: for ASCII, or for EBCDIC text files, as the michael@0: delimiter. If an FTP implementation adopts this technique, it michael@0: must be prepared to reverse the transformation if the file is michael@0: retrieved with file-structure. michael@0: michael@0: 3.1.2.1. FILE STRUCTURE michael@0: michael@0: File structure is the default to be assumed if the STRUcture michael@0: command has not been used. michael@0: michael@0: In file-structure there is no internal structure and the michael@0: file is considered to be a continuous sequence of data michael@0: bytes. michael@0: michael@0: 3.1.2.2. RECORD STRUCTURE michael@0: michael@0: Record structures must be accepted for "text" files (i.e., michael@0: files with TYPE ASCII or EBCDIC) by all FTP implementations. michael@0: michael@0: In record-structure the file is made up of sequential michael@0: records. michael@0: michael@0: 3.1.2.3. PAGE STRUCTURE michael@0: michael@0: To transmit files that are discontinuous, FTP defines a page michael@0: structure. Files of this type are sometimes known as michael@0: "random access files" or even as "holey files". In these michael@0: files there is sometimes other information associated with michael@0: the file as a whole (e.g., a file descriptor), or with a michael@0: section of the file (e.g., page access controls), or both. michael@0: In FTP, the sections of the file are called pages. michael@0: michael@0: To provide for various page sizes and associated michael@0: information, each page is sent with a page header. The page michael@0: header has the following defined fields: michael@0: michael@0: Header Length michael@0: michael@0: The number of logical bytes in the page header michael@0: including this byte. The minimum header length is 4. michael@0: michael@0: Page Index michael@0: michael@0: The logical page number of this section of the file. michael@0: This is not the transmission sequence number of this michael@0: page, but the index used to identify this page of the michael@0: file. michael@0: michael@0: michael@0: Postel & Reynolds [Page 16] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: Data Length michael@0: michael@0: The number of logical bytes in the page data. The michael@0: minimum data length is 0. michael@0: michael@0: Page Type michael@0: michael@0: The type of page this is. The following page types michael@0: are defined: michael@0: michael@0: 0 = Last Page michael@0: michael@0: This is used to indicate the end of a paged michael@0: structured transmission. The header length must michael@0: be 4, and the data length must be 0. michael@0: michael@0: 1 = Simple Page michael@0: michael@0: This is the normal type for simple paged files michael@0: with no page level associated control michael@0: information. The header length must be 4. michael@0: michael@0: 2 = Descriptor Page michael@0: michael@0: This type is used to transmit the descriptive michael@0: information for the file as a whole. michael@0: michael@0: 3 = Access Controlled Page michael@0: michael@0: This type includes an additional header field michael@0: for paged files with page level access control michael@0: information. The header length must be 5. michael@0: michael@0: Optional Fields michael@0: michael@0: Further header fields may be used to supply per page michael@0: control information, for example, per page access michael@0: control. michael@0: michael@0: All fields are one logical byte in length. The logical byte michael@0: size is specified by the TYPE command. See Appendix I for michael@0: further details and a specific case at the page structure. michael@0: michael@0: A note of caution about parameters: a file must be stored and michael@0: retrieved with the same parameters if the retrieved version is to michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 17] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: be identical to the version originally transmitted. Conversely, michael@0: FTP implementations must return a file identical to the original michael@0: if the parameters used to store and retrieve a file are the same. michael@0: michael@0: 3.2. ESTABLISHING DATA CONNECTIONS michael@0: michael@0: The mechanics of transferring data consists of setting up the data michael@0: connection to the appropriate ports and choosing the parameters michael@0: for transfer. Both the user and the server-DTPs have a default michael@0: data port. The user-process default data port is the same as the michael@0: control connection port (i.e., U). The server-process default michael@0: data port is the port adjacent to the control connection port michael@0: (i.e., L-1). michael@0: michael@0: The transfer byte size is 8-bit bytes. This byte size is relevant michael@0: only for the actual transfer of the data; it has no bearing on michael@0: representation of the data within a host's file system. michael@0: michael@0: The passive data transfer process (this may be a user-DTP or a michael@0: second server-DTP) shall "listen" on the data port prior to michael@0: sending a transfer request command. The FTP request command michael@0: determines the direction of the data transfer. The server, upon michael@0: receiving the transfer request, will initiate the data connection michael@0: to the port. When the connection is established, the data michael@0: transfer begins between DTP's, and the server-PI sends a michael@0: confirming reply to the user-PI. michael@0: michael@0: Every FTP implementation must support the use of the default data michael@0: ports, and only the USER-PI can initiate a change to non-default michael@0: ports. michael@0: michael@0: It is possible for the user to specify an alternate data port by michael@0: use of the PORT command. The user may want a file dumped on a TAC michael@0: line printer or retrieved from a third party host. In the latter michael@0: case, the user-PI sets up control connections with both michael@0: server-PI's. One server is then told (by an FTP command) to michael@0: "listen" for a connection which the other will initiate. The michael@0: user-PI sends one server-PI a PORT command indicating the data michael@0: port of the other. Finally, both are sent the appropriate michael@0: transfer commands. The exact sequence of commands and replies michael@0: sent between the user-controller and the servers is defined in the michael@0: Section on FTP Replies. michael@0: michael@0: In general, it is the server's responsibility to maintain the data michael@0: connection--to initiate it and to close it. The exception to this michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 18] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: is when the user-DTP is sending the data in a transfer mode that michael@0: requires the connection to be closed to indicate EOF. The server michael@0: MUST close the data connection under the following conditions: michael@0: michael@0: 1. The server has completed sending data in a transfer mode michael@0: that requires a close to indicate EOF. michael@0: michael@0: 2. The server receives an ABORT command from the user. michael@0: michael@0: 3. The port specification is changed by a command from the michael@0: user. michael@0: michael@0: 4. The control connection is closed legally or otherwise. michael@0: michael@0: 5. An irrecoverable error condition occurs. michael@0: michael@0: Otherwise the close is a server option, the exercise of which the michael@0: server must indicate to the user-process by either a 250 or 226 michael@0: reply only. michael@0: michael@0: 3.3. DATA CONNECTION MANAGEMENT michael@0: michael@0: Default Data Connection Ports: All FTP implementations must michael@0: support use of the default data connection ports, and only the michael@0: User-PI may initiate the use of non-default ports. michael@0: michael@0: Negotiating Non-Default Data Ports: The User-PI may specify a michael@0: non-default user side data port with the PORT command. The michael@0: User-PI may request the server side to identify a non-default michael@0: server side data port with the PASV command. Since a connection michael@0: is defined by the pair of addresses, either of these actions is michael@0: enough to get a different data connection, still it is permitted michael@0: to do both commands to use new ports on both ends of the data michael@0: connection. michael@0: michael@0: Reuse of the Data Connection: When using the stream mode of data michael@0: transfer the end of the file must be indicated by closing the michael@0: connection. This causes a problem if multiple files are to be michael@0: transfered in the session, due to need for TCP to hold the michael@0: connection record for a time out period to guarantee the reliable michael@0: communication. Thus the connection can not be reopened at once. michael@0: michael@0: There are two solutions to this problem. The first is to michael@0: negotiate a non-default port. The second is to use another michael@0: transfer mode. michael@0: michael@0: A comment on transfer modes. The stream transfer mode is michael@0: michael@0: michael@0: Postel & Reynolds [Page 19] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: inherently unreliable, since one can not determine if the michael@0: connection closed prematurely or not. The other transfer modes michael@0: (Block, Compressed) do not close the connection to indicate the michael@0: end of file. They have enough FTP encoding that the data michael@0: connection can be parsed to determine the end of the file. michael@0: Thus using these modes one can leave the data connection open michael@0: for multiple file transfers. michael@0: michael@0: 3.4. TRANSMISSION MODES michael@0: michael@0: The next consideration in transferring data is choosing the michael@0: appropriate transmission mode. There are three modes: one which michael@0: formats the data and allows for restart procedures; one which also michael@0: compresses the data for efficient transfer; and one which passes michael@0: the data with little or no processing. In this last case the mode michael@0: interacts with the structure attribute to determine the type of michael@0: processing. In the compressed mode, the representation type michael@0: determines the filler byte. michael@0: michael@0: All data transfers must be completed with an end-of-file (EOF) michael@0: which may be explicitly stated or implied by the closing of the michael@0: data connection. For files with record structure, all the michael@0: end-of-record markers (EOR) are explicit, including the final one. michael@0: For files transmitted in page structure a "last-page" page type is michael@0: used. michael@0: michael@0: NOTE: In the rest of this section, byte means "transfer byte" michael@0: except where explicitly stated otherwise. michael@0: michael@0: For the purpose of standardized transfer, the sending host will michael@0: translate its internal end of line or end of record denotation michael@0: into the representation prescribed by the transfer mode and file michael@0: structure, and the receiving host will perform the inverse michael@0: translation to its internal denotation. An IBM Mainframe record michael@0: count field may not be recognized at another host, so the michael@0: end-of-record information may be transferred as a two byte control michael@0: code in Stream mode or as a flagged bit in a Block or Compressed michael@0: mode descriptor. End-of-line in an ASCII or EBCDIC file with no michael@0: record structure should be indicated by or , michael@0: respectively. Since these transformations imply extra work for michael@0: some systems, identical systems transferring non-record structured michael@0: text files might wish to use a binary representation and stream michael@0: mode for the transfer. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 20] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: The following transmission modes are defined in FTP: michael@0: michael@0: 3.4.1. STREAM MODE michael@0: michael@0: The data is transmitted as a stream of bytes. There is no michael@0: restriction on the representation type used; record structures michael@0: are allowed. michael@0: michael@0: In a record structured file EOR and EOF will each be indicated michael@0: by a two-byte control code. The first byte of the control code michael@0: will be all ones, the escape character. The second byte will michael@0: have the low order bit on and zeros elsewhere for EOR and the michael@0: second low order bit on for EOF; that is, the byte will have michael@0: value 1 for EOR and value 2 for EOF. EOR and EOF may be michael@0: indicated together on the last byte transmitted by turning both michael@0: low order bits on (i.e., the value 3). If a byte of all ones michael@0: was intended to be sent as data, it should be repeated in the michael@0: second byte of the control code. michael@0: michael@0: If the structure is a file structure, the EOF is indicated by michael@0: the sending host closing the data connection and all bytes are michael@0: data bytes. michael@0: michael@0: 3.4.2. BLOCK MODE michael@0: michael@0: The file is transmitted as a series of data blocks preceded by michael@0: one or more header bytes. The header bytes contain a count michael@0: field, and descriptor code. The count field indicates the michael@0: total length of the data block in bytes, thus marking the michael@0: beginning of the next data block (there are no filler bits). michael@0: The descriptor code defines: last block in the file (EOF) last michael@0: block in the record (EOR), restart marker (see the Section on michael@0: Error Recovery and Restart) or suspect data (i.e., the data michael@0: being transferred is suspected of errors and is not reliable). michael@0: This last code is NOT intended for error control within FTP. michael@0: It is motivated by the desire of sites exchanging certain types michael@0: of data (e.g., seismic or weather data) to send and receive all michael@0: the data despite local errors (such as "magnetic tape read michael@0: errors"), but to indicate in the transmission that certain michael@0: portions are suspect). Record structures are allowed in this michael@0: mode, and any representation type may be used. michael@0: michael@0: The header consists of the three bytes. Of the 24 bits of michael@0: header information, the 16 low order bits shall represent byte michael@0: count, and the 8 high order bits shall represent descriptor michael@0: codes as shown below. michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 21] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: Block Header michael@0: michael@0: +----------------+----------------+----------------+ michael@0: | Descriptor | Byte Count | michael@0: | 8 bits | 16 bits | michael@0: +----------------+----------------+----------------+ michael@0: michael@0: michael@0: The descriptor codes are indicated by bit flags in the michael@0: descriptor byte. Four codes have been assigned, where each michael@0: code number is the decimal value of the corresponding bit in michael@0: the byte. michael@0: michael@0: Code Meaning michael@0: michael@0: 128 End of data block is EOR michael@0: 64 End of data block is EOF michael@0: 32 Suspected errors in data block michael@0: 16 Data block is a restart marker michael@0: michael@0: With this encoding, more than one descriptor coded condition michael@0: may exist for a particular block. As many bits as necessary michael@0: may be flagged. michael@0: michael@0: The restart marker is embedded in the data stream as an michael@0: integral number of 8-bit bytes representing printable michael@0: characters in the language being used over the control michael@0: connection (e.g., default--NVT-ASCII). (Space, in the michael@0: appropriate language) must not be used WITHIN a restart marker. michael@0: michael@0: For example, to transmit a six-character marker, the following michael@0: would be sent: michael@0: michael@0: +--------+--------+--------+ michael@0: |Descrptr| Byte count | michael@0: |code= 16| = 6 | michael@0: +--------+--------+--------+ michael@0: michael@0: +--------+--------+--------+ michael@0: | Marker | Marker | Marker | michael@0: | 8 bits | 8 bits | 8 bits | michael@0: +--------+--------+--------+ michael@0: michael@0: +--------+--------+--------+ michael@0: | Marker | Marker | Marker | michael@0: | 8 bits | 8 bits | 8 bits | michael@0: +--------+--------+--------+ michael@0: michael@0: michael@0: Postel & Reynolds [Page 22] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: 3.4.3. COMPRESSED MODE michael@0: michael@0: There are three kinds of information to be sent: regular data, michael@0: sent in a byte string; compressed data, consisting of michael@0: replications or filler; and control information, sent in a michael@0: two-byte escape sequence. If n>0 bytes (up to 127) of regular michael@0: data are sent, these n bytes are preceded by a byte with the michael@0: left-most bit set to 0 and the right-most 7 bits containing the michael@0: number n. michael@0: michael@0: Byte string: michael@0: michael@0: 1 7 8 8 michael@0: +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ michael@0: |0| n | | d(1) | ... | d(n) | michael@0: +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ michael@0: ^ ^ michael@0: |---n bytes---| michael@0: of data michael@0: michael@0: String of n data bytes d(1),..., d(n) michael@0: Count n must be positive. michael@0: michael@0: To compress a string of n replications of the data byte d, the michael@0: following 2 bytes are sent: michael@0: michael@0: Replicated Byte: michael@0: michael@0: 2 6 8 michael@0: +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ michael@0: |1 0| n | | d | michael@0: +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ michael@0: michael@0: A string of n filler bytes can be compressed into a single michael@0: byte, where the filler byte varies with the representation michael@0: type. If the type is ASCII or EBCDIC the filler byte is michael@0: (Space, ASCII code 32, EBCDIC code 64). If the type is Image michael@0: or Local byte the filler is a zero byte. michael@0: michael@0: Filler String: michael@0: michael@0: 2 6 michael@0: +-+-+-+-+-+-+-+-+ michael@0: |1 1| n | michael@0: +-+-+-+-+-+-+-+-+ michael@0: michael@0: The escape sequence is a double byte, the first of which is the michael@0: michael@0: michael@0: Postel & Reynolds [Page 23] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: escape byte (all zeros) and the second of which contains michael@0: descriptor codes as defined in Block mode. The descriptor michael@0: codes have the same meaning as in Block mode and apply to the michael@0: succeeding string of bytes. michael@0: michael@0: Compressed mode is useful for obtaining increased bandwidth on michael@0: very large network transmissions at a little extra CPU cost. michael@0: It can be most effectively used to reduce the size of printer michael@0: files such as those generated by RJE hosts. michael@0: michael@0: 3.5. ERROR RECOVERY AND RESTART michael@0: michael@0: There is no provision for detecting bits lost or scrambled in data michael@0: transfer; this level of error control is handled by the TCP. michael@0: However, a restart procedure is provided to protect users from michael@0: gross system failures (including failures of a host, an michael@0: FTP-process, or the underlying network). michael@0: michael@0: The restart procedure is defined only for the block and compressed michael@0: modes of data transfer. It requires the sender of data to insert michael@0: a special marker code in the data stream with some marker michael@0: information. The marker information has meaning only to the michael@0: sender, but must consist of printable characters in the default or michael@0: negotiated language of the control connection (ASCII or EBCDIC). michael@0: The marker could represent a bit-count, a record-count, or any michael@0: other information by which a system may identify a data michael@0: checkpoint. The receiver of data, if it implements the restart michael@0: procedure, would then mark the corresponding position of this michael@0: marker in the receiving system, and return this information to the michael@0: user. michael@0: michael@0: In the event of a system failure, the user can restart the data michael@0: transfer by identifying the marker point with the FTP restart michael@0: procedure. The following example illustrates the use of the michael@0: restart procedure. michael@0: michael@0: The sender of the data inserts an appropriate marker block in the michael@0: data stream at a convenient point. The receiving host marks the michael@0: corresponding data point in its file system and conveys the last michael@0: known sender and receiver marker information to the user, either michael@0: directly or over the control connection in a 110 reply (depending michael@0: on who is the sender). In the event of a system failure, the user michael@0: or controller process restarts the server at the last server michael@0: marker by sending a restart command with server's marker code as michael@0: its argument. The restart command is transmitted over the control michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 24] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: connection and is immediately followed by the command (such as michael@0: RETR, STOR or LIST) which was being executed when the system michael@0: failure occurred. michael@0: michael@0: 4. FILE TRANSFER FUNCTIONS michael@0: michael@0: The communication channel from the user-PI to the server-PI is michael@0: established as a TCP connection from the user to the standard server michael@0: port. The user protocol interpreter is responsible for sending FTP michael@0: commands and interpreting the replies received; the server-PI michael@0: interprets commands, sends replies and directs its DTP to set up the michael@0: data connection and transfer the data. If the second party to the michael@0: data transfer (the passive transfer process) is the user-DTP, then it michael@0: is governed through the internal protocol of the user-FTP host; if it michael@0: is a second server-DTP, then it is governed by its PI on command from michael@0: the user-PI. The FTP replies are discussed in the next section. In michael@0: the description of a few of the commands in this section, it is michael@0: helpful to be explicit about the possible replies. michael@0: michael@0: 4.1. FTP COMMANDS michael@0: michael@0: 4.1.1. ACCESS CONTROL COMMANDS michael@0: michael@0: The following commands specify access control identifiers michael@0: (command codes are shown in parentheses). michael@0: michael@0: USER NAME (USER) michael@0: michael@0: The argument field is a Telnet string identifying the user. michael@0: The user identification is that which is required by the michael@0: server for access to its file system. This command will michael@0: normally be the first command transmitted by the user after michael@0: the control connections are made (some servers may require michael@0: this). Additional identification information in the form of michael@0: a password and/or an account command may also be required by michael@0: some servers. Servers may allow a new USER command to be michael@0: entered at any point in order to change the access control michael@0: and/or accounting information. This has the effect of michael@0: flushing any user, password, and account information already michael@0: supplied and beginning the login sequence again. All michael@0: transfer parameters are unchanged and any file transfer in michael@0: progress is completed under the old access control michael@0: parameters. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 25] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: PASSWORD (PASS) michael@0: michael@0: The argument field is a Telnet string specifying the user's michael@0: password. This command must be immediately preceded by the michael@0: user name command, and, for some sites, completes the user's michael@0: identification for access control. Since password michael@0: information is quite sensitive, it is desirable in general michael@0: to "mask" it or suppress typeout. It appears that the michael@0: server has no foolproof way to achieve this. It is michael@0: therefore the responsibility of the user-FTP process to hide michael@0: the sensitive password information. michael@0: michael@0: ACCOUNT (ACCT) michael@0: michael@0: The argument field is a Telnet string identifying the user's michael@0: account. The command is not necessarily related to the USER michael@0: command, as some sites may require an account for login and michael@0: others only for specific access, such as storing files. In michael@0: the latter case the command may arrive at any time. michael@0: michael@0: There are reply codes to differentiate these cases for the michael@0: automation: when account information is required for login, michael@0: the response to a successful PASSword command is reply code michael@0: 332. On the other hand, if account information is NOT michael@0: required for login, the reply to a successful PASSword michael@0: command is 230; and if the account information is needed for michael@0: a command issued later in the dialogue, the server should michael@0: return a 332 or 532 reply depending on whether it stores michael@0: (pending receipt of the ACCounT command) or discards the michael@0: command, respectively. michael@0: michael@0: CHANGE WORKING DIRECTORY (CWD) michael@0: michael@0: This command allows the user to work with a different michael@0: directory or dataset for file storage or retrieval without michael@0: altering his login or accounting information. Transfer michael@0: parameters are similarly unchanged. The argument is a michael@0: pathname specifying a directory or other system dependent michael@0: file group designator. michael@0: michael@0: CHANGE TO PARENT DIRECTORY (CDUP) michael@0: michael@0: This command is a special case of CWD, and is included to michael@0: simplify the implementation of programs for transferring michael@0: directory trees between operating systems having different michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 26] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: syntaxes for naming the parent directory. The reply codes michael@0: shall be identical to the reply codes of CWD. See michael@0: Appendix II for further details. michael@0: michael@0: STRUCTURE MOUNT (SMNT) michael@0: michael@0: This command allows the user to mount a different file michael@0: system data structure without altering his login or michael@0: accounting information. Transfer parameters are similarly michael@0: unchanged. The argument is a pathname specifying a michael@0: directory or other system dependent file group designator. michael@0: michael@0: REINITIALIZE (REIN) michael@0: michael@0: This command terminates a USER, flushing all I/O and account michael@0: information, except to allow any transfer in progress to be michael@0: completed. All parameters are reset to the default settings michael@0: and the control connection is left open. This is identical michael@0: to the state in which a user finds himself immediately after michael@0: the control connection is opened. A USER command may be michael@0: expected to follow. michael@0: michael@0: LOGOUT (QUIT) michael@0: michael@0: This command terminates a USER and if file transfer is not michael@0: in progress, the server closes the control connection. If michael@0: file transfer is in progress, the connection will remain michael@0: open for result response and the server will then close it. michael@0: If the user-process is transferring files for several USERs michael@0: but does not wish to close and then reopen connections for michael@0: each, then the REIN command should be used instead of QUIT. michael@0: michael@0: An unexpected close on the control connection will cause the michael@0: server to take the effective action of an abort (ABOR) and a michael@0: logout (QUIT). michael@0: michael@0: 4.1.2. TRANSFER PARAMETER COMMANDS michael@0: michael@0: All data transfer parameters have default values, and the michael@0: commands specifying data transfer parameters are required only michael@0: if the default parameter values are to be changed. The default michael@0: value is the last specified value, or if no value has been michael@0: specified, the standard default value is as stated here. This michael@0: implies that the server must "remember" the applicable default michael@0: values. The commands may be in any order except that they must michael@0: precede the FTP service request. The following commands michael@0: specify data transfer parameters: michael@0: michael@0: michael@0: Postel & Reynolds [Page 27] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: DATA PORT (PORT) michael@0: michael@0: The argument is a HOST-PORT specification for the data port michael@0: to be used in data connection. There are defaults for both michael@0: the user and server data ports, and under normal michael@0: circumstances this command and its reply are not needed. If michael@0: this command is used, the argument is the concatenation of a michael@0: 32-bit internet host address and a 16-bit TCP port address. michael@0: This address information is broken into 8-bit fields and the michael@0: value of each field is transmitted as a decimal number (in michael@0: character string representation). The fields are separated michael@0: by commas. A port command would be: michael@0: michael@0: PORT h1,h2,h3,h4,p1,p2 michael@0: michael@0: where h1 is the high order 8 bits of the internet host michael@0: address. michael@0: michael@0: PASSIVE (PASV) michael@0: michael@0: This command requests the server-DTP to "listen" on a data michael@0: port (which is not its default data port) and to wait for a michael@0: connection rather than initiate one upon receipt of a michael@0: transfer command. The response to this command includes the michael@0: host and port address this server is listening on. michael@0: michael@0: REPRESENTATION TYPE (TYPE) michael@0: michael@0: The argument specifies the representation type as described michael@0: in the Section on Data Representation and Storage. Several michael@0: types take a second parameter. The first parameter is michael@0: denoted by a single Telnet character, as is the second michael@0: Format parameter for ASCII and EBCDIC; the second parameter michael@0: for local byte is a decimal integer to indicate Bytesize. michael@0: The parameters are separated by a (Space, ASCII code michael@0: 32). michael@0: michael@0: The following codes are assigned for type: michael@0: michael@0: \ / michael@0: A - ASCII | | N - Non-print michael@0: |-><-| T - Telnet format effectors michael@0: E - EBCDIC| | C - Carriage Control (ASA) michael@0: / \ michael@0: I - Image michael@0: michael@0: L - Local byte Byte size michael@0: michael@0: michael@0: Postel & Reynolds [Page 28] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: The default representation type is ASCII Non-print. If the michael@0: Format parameter is changed, and later just the first michael@0: argument is changed, Format then returns to the Non-print michael@0: default. michael@0: michael@0: FILE STRUCTURE (STRU) michael@0: michael@0: The argument is a single Telnet character code specifying michael@0: file structure described in the Section on Data michael@0: Representation and Storage. michael@0: michael@0: The following codes are assigned for structure: michael@0: michael@0: F - File (no record structure) michael@0: R - Record structure michael@0: P - Page structure michael@0: michael@0: The default structure is File. michael@0: michael@0: TRANSFER MODE (MODE) michael@0: michael@0: The argument is a single Telnet character code specifying michael@0: the data transfer modes described in the Section on michael@0: Transmission Modes. michael@0: michael@0: The following codes are assigned for transfer modes: michael@0: michael@0: S - Stream michael@0: B - Block michael@0: C - Compressed michael@0: michael@0: The default transfer mode is Stream. michael@0: michael@0: 4.1.3. FTP SERVICE COMMANDS michael@0: michael@0: The FTP service commands define the file transfer or the file michael@0: system function requested by the user. The argument of an FTP michael@0: service command will normally be a pathname. The syntax of michael@0: pathnames must conform to server site conventions (with michael@0: standard defaults applicable), and the language conventions of michael@0: the control connection. The suggested default handling is to michael@0: use the last specified device, directory or file name, or the michael@0: standard default defined for local users. The commands may be michael@0: in any order except that a "rename from" command must be michael@0: followed by a "rename to" command and the restart command must michael@0: be followed by the interrupted service command (e.g., STOR or michael@0: RETR). The data, when transferred in response to FTP service michael@0: michael@0: michael@0: Postel & Reynolds [Page 29] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: commands, shall always be sent over the data connection, except michael@0: for certain informative replies. The following commands michael@0: specify FTP service requests: michael@0: michael@0: RETRIEVE (RETR) michael@0: michael@0: This command causes the server-DTP to transfer a copy of the michael@0: file, specified in the pathname, to the server- or user-DTP michael@0: at the other end of the data connection. The status and michael@0: contents of the file at the server site shall be unaffected. michael@0: michael@0: STORE (STOR) michael@0: michael@0: This command causes the server-DTP to accept the data michael@0: transferred via the data connection and to store the data as michael@0: a file at the server site. If the file specified in the michael@0: pathname exists at the server site, then its contents shall michael@0: be replaced by the data being transferred. A new file is michael@0: created at the server site if the file specified in the michael@0: pathname does not already exist. michael@0: michael@0: STORE UNIQUE (STOU) michael@0: michael@0: This command behaves like STOR except that the resultant michael@0: file is to be created in the current directory under a name michael@0: unique to that directory. The 250 Transfer Started response michael@0: must include the name generated. michael@0: michael@0: APPEND (with create) (APPE) michael@0: michael@0: This command causes the server-DTP to accept the data michael@0: transferred via the data connection and to store the data in michael@0: a file at the server site. If the file specified in the michael@0: pathname exists at the server site, then the data shall be michael@0: appended to that file; otherwise the file specified in the michael@0: pathname shall be created at the server site. michael@0: michael@0: ALLOCATE (ALLO) michael@0: michael@0: This command may be required by some servers to reserve michael@0: sufficient storage to accommodate the new file to be michael@0: transferred. The argument shall be a decimal integer michael@0: representing the number of bytes (using the logical byte michael@0: size) of storage to be reserved for the file. For files michael@0: sent with record or page structure a maximum record or page michael@0: size (in logical bytes) might also be necessary; this is michael@0: indicated by a decimal integer in a second argument field of michael@0: michael@0: michael@0: Postel & Reynolds [Page 30] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: the command. This second argument is optional, but when michael@0: present should be separated from the first by the three michael@0: Telnet characters R . This command shall be michael@0: followed by a STORe or APPEnd command. The ALLO command michael@0: should be treated as a NOOP (no operation) by those servers michael@0: which do not require that the maximum size of the file be michael@0: declared beforehand, and those servers interested in only michael@0: the maximum record or page size should accept a dummy value michael@0: in the first argument and ignore it. michael@0: michael@0: RESTART (REST) michael@0: michael@0: The argument field represents the server marker at which michael@0: file transfer is to be restarted. This command does not michael@0: cause file transfer but skips over the file to the specified michael@0: data checkpoint. This command shall be immediately followed michael@0: by the appropriate FTP service command which shall cause michael@0: file transfer to resume. michael@0: michael@0: RENAME FROM (RNFR) michael@0: michael@0: This command specifies the old pathname of the file which is michael@0: to be renamed. This command must be immediately followed by michael@0: a "rename to" command specifying the new file pathname. michael@0: michael@0: RENAME TO (RNTO) michael@0: michael@0: This command specifies the new pathname of the file michael@0: specified in the immediately preceding "rename from" michael@0: command. Together the two commands cause a file to be michael@0: renamed. michael@0: michael@0: ABORT (ABOR) michael@0: michael@0: This command tells the server to abort the previous FTP michael@0: service command and any associated transfer of data. The michael@0: abort command may require "special action", as discussed in michael@0: the Section on FTP Commands, to force recognition by the michael@0: server. No action is to be taken if the previous command michael@0: has been completed (including data transfer). The control michael@0: connection is not to be closed by the server, but the data michael@0: connection must be closed. michael@0: michael@0: There are two cases for the server upon receipt of this michael@0: command: (1) the FTP service command was already completed, michael@0: or (2) the FTP service command is still in progress. michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 31] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: In the first case, the server closes the data connection michael@0: (if it is open) and responds with a 226 reply, indicating michael@0: that the abort command was successfully processed. michael@0: michael@0: In the second case, the server aborts the FTP service in michael@0: progress and closes the data connection, returning a 426 michael@0: reply to indicate that the service request terminated michael@0: abnormally. The server then sends a 226 reply, michael@0: indicating that the abort command was successfully michael@0: processed. michael@0: michael@0: DELETE (DELE) michael@0: michael@0: This command causes the file specified in the pathname to be michael@0: deleted at the server site. If an extra level of protection michael@0: is desired (such as the query, "Do you really wish to michael@0: delete?"), it should be provided by the user-FTP process. michael@0: michael@0: REMOVE DIRECTORY (RMD) michael@0: michael@0: This command causes the directory specified in the pathname michael@0: to be removed as a directory (if the pathname is absolute) michael@0: or as a subdirectory of the current working directory (if michael@0: the pathname is relative). See Appendix II. michael@0: michael@0: MAKE DIRECTORY (MKD) michael@0: michael@0: This command causes the directory specified in the pathname michael@0: to be created as a directory (if the pathname is absolute) michael@0: or as a subdirectory of the current working directory (if michael@0: the pathname is relative). See Appendix II. michael@0: michael@0: PRINT WORKING DIRECTORY (PWD) michael@0: michael@0: This command causes the name of the current working michael@0: directory to be returned in the reply. See Appendix II. michael@0: michael@0: LIST (LIST) michael@0: michael@0: This command causes a list to be sent from the server to the michael@0: passive DTP. If the pathname specifies a directory or other michael@0: group of files, the server should transfer a list of files michael@0: in the specified directory. If the pathname specifies a michael@0: file then the server should send current information on the michael@0: file. A null argument implies the user's current working or michael@0: default directory. The data transfer is over the data michael@0: connection in type ASCII or type EBCDIC. (The user must michael@0: michael@0: michael@0: Postel & Reynolds [Page 32] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: ensure that the TYPE is appropriately ASCII or EBCDIC). michael@0: Since the information on a file may vary widely from system michael@0: to system, this information may be hard to use automatically michael@0: in a program, but may be quite useful to a human user. michael@0: michael@0: NAME LIST (NLST) michael@0: michael@0: This command causes a directory listing to be sent from michael@0: server to user site. The pathname should specify a michael@0: directory or other system-specific file group descriptor; a michael@0: null argument implies the current directory. The server michael@0: will return a stream of names of files and no other michael@0: information. The data will be transferred in ASCII or michael@0: EBCDIC type over the data connection as valid pathname michael@0: strings separated by or . (Again the user must michael@0: ensure that the TYPE is correct.) This command is intended michael@0: to return information that can be used by a program to michael@0: further process the files automatically. For example, in michael@0: the implementation of a "multiple get" function. michael@0: michael@0: SITE PARAMETERS (SITE) michael@0: michael@0: This command is used by the server to provide services michael@0: specific to his system that are essential to file transfer michael@0: but not sufficiently universal to be included as commands in michael@0: the protocol. The nature of these services and the michael@0: specification of their syntax can be stated in a reply to michael@0: the HELP SITE command. michael@0: michael@0: SYSTEM (SYST) michael@0: michael@0: This command is used to find out the type of operating michael@0: system at the server. The reply shall have as its first michael@0: word one of the system names listed in the current version michael@0: of the Assigned Numbers document [4]. michael@0: michael@0: STATUS (STAT) michael@0: michael@0: This command shall cause a status response to be sent over michael@0: the control connection in the form of a reply. The command michael@0: may be sent during a file transfer (along with the Telnet IP michael@0: and Synch signals--see the Section on FTP Commands) in which michael@0: case the server will respond with the status of the michael@0: operation in progress, or it may be sent between file michael@0: transfers. In the latter case, the command may have an michael@0: argument field. If the argument is a pathname, the command michael@0: is analogous to the "list" command except that data shall be michael@0: michael@0: michael@0: Postel & Reynolds [Page 33] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: transferred over the control connection. If a partial michael@0: pathname is given, the server may respond with a list of michael@0: file names or attributes associated with that specification. michael@0: If no argument is given, the server should return general michael@0: status information about the server FTP process. This michael@0: should include current values of all transfer parameters and michael@0: the status of connections. michael@0: michael@0: HELP (HELP) michael@0: michael@0: This command shall cause the server to send helpful michael@0: information regarding its implementation status over the michael@0: control connection to the user. The command may take an michael@0: argument (e.g., any command name) and return more specific michael@0: information as a response. The reply is type 211 or 214. michael@0: It is suggested that HELP be allowed before entering a USER michael@0: command. The server may use this reply to specify michael@0: site-dependent parameters, e.g., in response to HELP SITE. michael@0: michael@0: NOOP (NOOP) michael@0: michael@0: This command does not affect any parameters or previously michael@0: entered commands. It specifies no action other than that the michael@0: server send an OK reply. michael@0: michael@0: The File Transfer Protocol follows the specifications of the Telnet michael@0: protocol for all communications over the control connection. Since michael@0: the language used for Telnet communication may be a negotiated michael@0: option, all references in the next two sections will be to the michael@0: "Telnet language" and the corresponding "Telnet end-of-line code". michael@0: Currently, one may take these to mean NVT-ASCII and . No other michael@0: specifications of the Telnet protocol will be cited. michael@0: michael@0: FTP commands are "Telnet strings" terminated by the "Telnet end of michael@0: line code". The command codes themselves are alphabetic characters michael@0: terminated by the character (Space) if parameters follow and michael@0: Telnet-EOL otherwise. The command codes and the semantics of michael@0: commands are described in this section; the detailed syntax of michael@0: commands is specified in the Section on Commands, the reply sequences michael@0: are discussed in the Section on Sequencing of Commands and Replies, michael@0: and scenarios illustrating the use of commands are provided in the michael@0: Section on Typical FTP Scenarios. michael@0: michael@0: FTP commands may be partitioned as those specifying access-control michael@0: identifiers, data transfer parameters, or FTP service requests. michael@0: Certain commands (such as ABOR, STAT, QUIT) may be sent over the michael@0: control connection while a data transfer is in progress. Some michael@0: michael@0: michael@0: Postel & Reynolds [Page 34] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: servers may not be able to monitor the control and data connections michael@0: simultaneously, in which case some special action will be necessary michael@0: to get the server's attention. The following ordered format is michael@0: tentatively recommended: michael@0: michael@0: 1. User system inserts the Telnet "Interrupt Process" (IP) signal michael@0: in the Telnet stream. michael@0: michael@0: 2. User system sends the Telnet "Synch" signal. michael@0: michael@0: 3. User system inserts the command (e.g., ABOR) in the Telnet michael@0: stream. michael@0: michael@0: 4. Server PI, after receiving "IP", scans the Telnet stream for michael@0: EXACTLY ONE FTP command. michael@0: michael@0: (For other servers this may not be necessary but the actions listed michael@0: above should have no unusual effect.) michael@0: michael@0: 4.2. FTP REPLIES michael@0: michael@0: Replies to File Transfer Protocol commands are devised to ensure michael@0: the synchronization of requests and actions in the process of file michael@0: transfer, and to guarantee that the user process always knows the michael@0: state of the Server. Every command must generate at least one michael@0: reply, although there may be more than one; in the latter case, michael@0: the multiple replies must be easily distinguished. In addition, michael@0: some commands occur in sequential groups, such as USER, PASS and michael@0: ACCT, or RNFR and RNTO. The replies show the existence of an michael@0: intermediate state if all preceding commands have been successful. michael@0: A failure at any point in the sequence necessitates the repetition michael@0: of the entire sequence from the beginning. michael@0: michael@0: The details of the command-reply sequence are made explicit in michael@0: a set of state diagrams below. michael@0: michael@0: An FTP reply consists of a three digit number (transmitted as michael@0: three alphanumeric characters) followed by some text. The number michael@0: is intended for use by automata to determine what state to enter michael@0: next; the text is intended for the human user. It is intended michael@0: that the three digits contain enough encoded information that the michael@0: user-process (the User-PI) will not need to examine the text and michael@0: may either discard it or pass it on to the user, as appropriate. michael@0: In particular, the text may be server-dependent, so there are michael@0: likely to be varying texts for each reply code. michael@0: michael@0: A reply is defined to contain the 3-digit code, followed by Space michael@0: michael@0: michael@0: Postel & Reynolds [Page 35] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: , followed by one line of text (where some maximum line length michael@0: has been specified), and terminated by the Telnet end-of-line michael@0: code. There will be cases however, where the text is longer than michael@0: a single line. In these cases the complete text must be bracketed michael@0: so the User-process knows when it may stop reading the reply (i.e. michael@0: stop processing input on the control connection) and go do other michael@0: things. This requires a special format on the first line to michael@0: indicate that more than one line is coming, and another on the michael@0: last line to designate it as the last. At least one of these must michael@0: contain the appropriate reply code to indicate the state of the michael@0: transaction. To satisfy all factions, it was decided that both michael@0: the first and last line codes should be the same. michael@0: michael@0: Thus the format for multi-line replies is that the first line michael@0: will begin with the exact required reply code, followed michael@0: immediately by a Hyphen, "-" (also known as Minus), followed by michael@0: text. The last line will begin with the same code, followed michael@0: immediately by Space , optionally some text, and the Telnet michael@0: end-of-line code. michael@0: michael@0: For example: michael@0: 123-First line michael@0: Second line michael@0: 234 A line beginning with numbers michael@0: 123 The last line michael@0: michael@0: The user-process then simply needs to search for the second michael@0: occurrence of the same reply code, followed by (Space), at michael@0: the beginning of a line, and ignore all intermediary lines. If michael@0: an intermediary line begins with a 3-digit number, the Server michael@0: must pad the front to avoid confusion. michael@0: michael@0: This scheme allows standard system routines to be used for michael@0: reply information (such as for the STAT reply), with michael@0: "artificial" first and last lines tacked on. In rare cases michael@0: where these routines are able to generate three digits and a michael@0: Space at the beginning of any line, the beginning of each michael@0: text line should be offset by some neutral text, like Space. michael@0: michael@0: This scheme assumes that multi-line replies may not be nested. michael@0: michael@0: The three digits of the reply each have a special significance. michael@0: This is intended to allow a range of very simple to very michael@0: sophisticated responses by the user-process. The first digit michael@0: denotes whether the response is good, bad or incomplete. michael@0: (Referring to the state diagram), an unsophisticated user-process michael@0: will be able to determine its next action (proceed as planned, michael@0: michael@0: michael@0: Postel & Reynolds [Page 36] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: redo, retrench, etc.) by simply examining this first digit. A michael@0: user-process that wants to know approximately what kind of error michael@0: occurred (e.g. file system error, command syntax error) may michael@0: examine the second digit, reserving the third digit for the finest michael@0: gradation of information (e.g., RNTO command without a preceding michael@0: RNFR). michael@0: michael@0: There are five values for the first digit of the reply code: michael@0: michael@0: 1yz Positive Preliminary reply michael@0: michael@0: The requested action is being initiated; expect another michael@0: reply before proceeding with a new command. (The michael@0: user-process sending another command before the michael@0: completion reply would be in violation of protocol; but michael@0: server-FTP processes should queue any commands that michael@0: arrive while a preceding command is in progress.) This michael@0: type of reply can be used to indicate that the command michael@0: was accepted and the user-process may now pay attention michael@0: to the data connections, for implementations where michael@0: simultaneous monitoring is difficult. The server-FTP michael@0: process may send at most, one 1yz reply per command. michael@0: michael@0: 2yz Positive Completion reply michael@0: michael@0: The requested action has been successfully completed. A michael@0: new request may be initiated. michael@0: michael@0: 3yz Positive Intermediate reply michael@0: michael@0: The command has been accepted, but the requested action michael@0: is being held in abeyance, pending receipt of further michael@0: information. The user should send another command michael@0: specifying this information. This reply is used in michael@0: command sequence groups. michael@0: michael@0: 4yz Transient Negative Completion reply michael@0: michael@0: The command was not accepted and the requested action did michael@0: not take place, but the error condition is temporary and michael@0: the action may be requested again. The user should michael@0: return to the beginning of the command sequence, if any. michael@0: It is difficult to assign a meaning to "transient", michael@0: particularly when two distinct sites (Server- and michael@0: User-processes) have to agree on the interpretation. michael@0: Each reply in the 4yz category might have a slightly michael@0: different time value, but the intent is that the michael@0: michael@0: michael@0: Postel & Reynolds [Page 37] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: user-process is encouraged to try again. A rule of thumb michael@0: in determining if a reply fits into the 4yz or the 5yz michael@0: (Permanent Negative) category is that replies are 4yz if michael@0: the commands can be repeated without any change in michael@0: command form or in properties of the User or Server michael@0: (e.g., the command is spelled the same with the same michael@0: arguments used; the user does not change his file access michael@0: or user name; the server does not put up a new michael@0: implementation.) michael@0: michael@0: 5yz Permanent Negative Completion reply michael@0: michael@0: The command was not accepted and the requested action did michael@0: not take place. The User-process is discouraged from michael@0: repeating the exact request (in the same sequence). Even michael@0: some "permanent" error conditions can be corrected, so michael@0: the human user may want to direct his User-process to michael@0: reinitiate the command sequence by direct action at some michael@0: point in the future (e.g., after the spelling has been michael@0: changed, or the user has altered his directory status.) michael@0: michael@0: The following function groupings are encoded in the second michael@0: digit: michael@0: michael@0: x0z Syntax - These replies refer to syntax errors, michael@0: syntactically correct commands that don't fit any michael@0: functional category, unimplemented or superfluous michael@0: commands. michael@0: michael@0: x1z Information - These are replies to requests for michael@0: information, such as status or help. michael@0: michael@0: x2z Connections - Replies referring to the control and michael@0: data connections. michael@0: michael@0: x3z Authentication and accounting - Replies for the login michael@0: process and accounting procedures. michael@0: michael@0: x4z Unspecified as yet. michael@0: michael@0: x5z File system - These replies indicate the status of the michael@0: Server file system vis-a-vis the requested transfer or michael@0: other file system action. michael@0: michael@0: The third digit gives a finer gradation of meaning in each of michael@0: the function categories, specified by the second digit. The michael@0: list of replies below will illustrate this. Note that the text michael@0: michael@0: michael@0: Postel & Reynolds [Page 38] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: associated with each reply is recommended, rather than michael@0: mandatory, and may even change according to the command with michael@0: which it is associated. The reply codes, on the other hand, michael@0: must strictly follow the specifications in the last section; michael@0: that is, Server implementations should not invent new codes for michael@0: situations that are only slightly different from the ones michael@0: described here, but rather should adapt codes already defined. michael@0: michael@0: A command such as TYPE or ALLO whose successful execution michael@0: does not offer the user-process any new information will michael@0: cause a 200 reply to be returned. If the command is not michael@0: implemented by a particular Server-FTP process because it michael@0: has no relevance to that computer system, for example ALLO michael@0: at a TOPS20 site, a Positive Completion reply is still michael@0: desired so that the simple User-process knows it can proceed michael@0: with its course of action. A 202 reply is used in this case michael@0: with, for example, the reply text: "No storage allocation michael@0: necessary." If, on the other hand, the command requests a michael@0: non-site-specific action and is unimplemented, the response michael@0: is 502. A refinement of that is the 504 reply for a command michael@0: that is implemented, but that requests an unimplemented michael@0: parameter. michael@0: michael@0: 4.2.1 Reply Codes by Function Groups michael@0: michael@0: 200 Command okay. michael@0: 500 Syntax error, command unrecognized. michael@0: This may include errors such as command line too long. michael@0: 501 Syntax error in parameters or arguments. michael@0: 202 Command not implemented, superfluous at this site. michael@0: 502 Command not implemented. michael@0: 503 Bad sequence of commands. michael@0: 504 Command not implemented for that parameter. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 39] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: 110 Restart marker reply. michael@0: In this case, the text is exact and not left to the michael@0: particular implementation; it must read: michael@0: MARK yyyy = mmmm michael@0: Where yyyy is User-process data stream marker, and mmmm michael@0: server's equivalent marker (note the spaces between markers michael@0: and "="). michael@0: 211 System status, or system help reply. michael@0: 212 Directory status. michael@0: 213 File status. michael@0: 214 Help message. michael@0: On how to use the server or the meaning of a particular michael@0: non-standard command. This reply is useful only to the michael@0: human user. michael@0: 215 NAME system type. michael@0: Where NAME is an official system name from the list in the michael@0: Assigned Numbers document. michael@0: michael@0: 120 Service ready in nnn minutes. michael@0: 220 Service ready for new user. michael@0: 221 Service closing control connection. michael@0: Logged out if appropriate. michael@0: 421 Service not available, closing control connection. michael@0: This may be a reply to any command if the service knows it michael@0: must shut down. michael@0: 125 Data connection already open; transfer starting. michael@0: 225 Data connection open; no transfer in progress. michael@0: 425 Can't open data connection. michael@0: 226 Closing data connection. michael@0: Requested file action successful (for example, file michael@0: transfer or file abort). michael@0: 426 Connection closed; transfer aborted. michael@0: 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2). michael@0: michael@0: 230 User logged in, proceed. michael@0: 530 Not logged in. michael@0: 331 User name okay, need password. michael@0: 332 Need account for login. michael@0: 532 Need account for storing files. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 40] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: 150 File status okay; about to open data connection. michael@0: 250 Requested file action okay, completed. michael@0: 257 "PATHNAME" created. michael@0: 350 Requested file action pending further information. michael@0: 450 Requested file action not taken. michael@0: File unavailable (e.g., file busy). michael@0: 550 Requested action not taken. michael@0: File unavailable (e.g., file not found, no access). michael@0: 451 Requested action aborted. Local error in processing. michael@0: 551 Requested action aborted. Page type unknown. michael@0: 452 Requested action not taken. michael@0: Insufficient storage space in system. michael@0: 552 Requested file action aborted. michael@0: Exceeded storage allocation (for current directory or michael@0: dataset). michael@0: 553 Requested action not taken. michael@0: File name not allowed. michael@0: michael@0: michael@0: 4.2.2 Numeric Order List of Reply Codes michael@0: michael@0: 110 Restart marker reply. michael@0: In this case, the text is exact and not left to the michael@0: particular implementation; it must read: michael@0: MARK yyyy = mmmm michael@0: Where yyyy is User-process data stream marker, and mmmm michael@0: server's equivalent marker (note the spaces between markers michael@0: and "="). michael@0: 120 Service ready in nnn minutes. michael@0: 125 Data connection already open; transfer starting. michael@0: 150 File status okay; about to open data connection. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 41] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: 200 Command okay. michael@0: 202 Command not implemented, superfluous at this site. michael@0: 211 System status, or system help reply. michael@0: 212 Directory status. michael@0: 213 File status. michael@0: 214 Help message. michael@0: On how to use the server or the meaning of a particular michael@0: non-standard command. This reply is useful only to the michael@0: human user. michael@0: 215 NAME system type. michael@0: Where NAME is an official system name from the list in the michael@0: Assigned Numbers document. michael@0: 220 Service ready for new user. michael@0: 221 Service closing control connection. michael@0: Logged out if appropriate. michael@0: 225 Data connection open; no transfer in progress. michael@0: 226 Closing data connection. michael@0: Requested file action successful (for example, file michael@0: transfer or file abort). michael@0: 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2). michael@0: 230 User logged in, proceed. michael@0: 250 Requested file action okay, completed. michael@0: 257 "PATHNAME" created. michael@0: michael@0: 331 User name okay, need password. michael@0: 332 Need account for login. michael@0: 350 Requested file action pending further information. michael@0: michael@0: 421 Service not available, closing control connection. michael@0: This may be a reply to any command if the service knows it michael@0: must shut down. michael@0: 425 Can't open data connection. michael@0: 426 Connection closed; transfer aborted. michael@0: 450 Requested file action not taken. michael@0: File unavailable (e.g., file busy). michael@0: 451 Requested action aborted: local error in processing. michael@0: 452 Requested action not taken. michael@0: Insufficient storage space in system. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 42] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: 500 Syntax error, command unrecognized. michael@0: This may include errors such as command line too long. michael@0: 501 Syntax error in parameters or arguments. michael@0: 502 Command not implemented. michael@0: 503 Bad sequence of commands. michael@0: 504 Command not implemented for that parameter. michael@0: 530 Not logged in. michael@0: 532 Need account for storing files. michael@0: 550 Requested action not taken. michael@0: File unavailable (e.g., file not found, no access). michael@0: 551 Requested action aborted: page type unknown. michael@0: 552 Requested file action aborted. michael@0: Exceeded storage allocation (for current directory or michael@0: dataset). michael@0: 553 Requested action not taken. michael@0: File name not allowed. michael@0: michael@0: michael@0: 5. DECLARATIVE SPECIFICATIONS michael@0: michael@0: 5.1. MINIMUM IMPLEMENTATION michael@0: michael@0: In order to make FTP workable without needless error messages, the michael@0: following minimum implementation is required for all servers: michael@0: michael@0: TYPE - ASCII Non-print michael@0: MODE - Stream michael@0: STRUCTURE - File, Record michael@0: COMMANDS - USER, QUIT, PORT, michael@0: TYPE, MODE, STRU, michael@0: for the default values michael@0: RETR, STOR, michael@0: NOOP. michael@0: michael@0: The default values for transfer parameters are: michael@0: michael@0: TYPE - ASCII Non-print michael@0: MODE - Stream michael@0: STRU - File michael@0: michael@0: All hosts must accept the above as the standard defaults. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 43] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: 5.2. CONNECTIONS michael@0: michael@0: The server protocol interpreter shall "listen" on Port L. The michael@0: user or user protocol interpreter shall initiate the full-duplex michael@0: control connection. Server- and user- processes should follow the michael@0: conventions of the Telnet protocol as specified in the michael@0: ARPA-Internet Protocol Handbook [1]. Servers are under no michael@0: obligation to provide for editing of command lines and may require michael@0: that it be done in the user host. The control connection shall be michael@0: closed by the server at the user's request after all transfers and michael@0: replies are completed. michael@0: michael@0: The user-DTP must "listen" on the specified data port; this may be michael@0: the default user port (U) or a port specified in the PORT command. michael@0: The server shall initiate the data connection from his own default michael@0: data port (L-1) using the specified user data port. The direction michael@0: of the transfer and the port used will be determined by the FTP michael@0: service command. michael@0: michael@0: Note that all FTP implementation must support data transfer using michael@0: the default port, and that only the USER-PI may initiate the use michael@0: of non-default ports. michael@0: michael@0: When data is to be transferred between two servers, A and B (refer michael@0: to Figure 2), the user-PI, C, sets up control connections with michael@0: both server-PI's. One of the servers, say A, is then sent a PASV michael@0: command telling him to "listen" on his data port rather than michael@0: initiate a connection when he receives a transfer service command. michael@0: When the user-PI receives an acknowledgment to the PASV command, michael@0: which includes the identity of the host and port being listened michael@0: on, the user-PI then sends A's port, a, to B in a PORT command; a michael@0: reply is returned. The user-PI may then send the corresponding michael@0: service commands to A and B. Server B initiates the connection michael@0: and the transfer proceeds. The command-reply sequence is listed michael@0: below where the messages are vertically synchronous but michael@0: horizontally asynchronous: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 44] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: User-PI - Server A User-PI - Server B michael@0: ------------------ ------------------ michael@0: michael@0: C->A : Connect C->B : Connect michael@0: C->A : PASV michael@0: A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2 michael@0: C->B : PORT A1,A2,A3,A4,a1,a2 michael@0: B->C : 200 Okay michael@0: C->A : STOR C->B : RETR michael@0: B->A : Connect to HOST-A, PORT-a michael@0: michael@0: Figure 3 michael@0: michael@0: The data connection shall be closed by the server under the michael@0: conditions described in the Section on Establishing Data michael@0: Connections. If the data connection is to be closed following a michael@0: data transfer where closing the connection is not required to michael@0: indicate the end-of-file, the server must do so immediately. michael@0: Waiting until after a new transfer command is not permitted michael@0: because the user-process will have already tested the data michael@0: connection to see if it needs to do a "listen"; (remember that the michael@0: user must "listen" on a closed data port BEFORE sending the michael@0: transfer request). To prevent a race condition here, the server michael@0: sends a reply (226) after closing the data connection (or if the michael@0: connection is left open, a "file transfer completed" reply (250) michael@0: and the user-PI should wait for one of these replies before michael@0: issuing a new transfer command). michael@0: michael@0: Any time either the user or server see that the connection is michael@0: being closed by the other side, it should promptly read any michael@0: remaining data queued on the connection and issue the close on its michael@0: own side. michael@0: michael@0: 5.3. COMMANDS michael@0: michael@0: The commands are Telnet character strings transmitted over the michael@0: control connections as described in the Section on FTP Commands. michael@0: The command functions and semantics are described in the Section michael@0: on Access Control Commands, Transfer Parameter Commands, FTP michael@0: Service Commands, and Miscellaneous Commands. The command syntax michael@0: is specified here. michael@0: michael@0: The commands begin with a command code followed by an argument michael@0: field. The command codes are four or fewer alphabetic characters. michael@0: Upper and lower case alphabetic characters are to be treated michael@0: identically. Thus, any of the following may represent the michael@0: retrieve command: michael@0: michael@0: michael@0: Postel & Reynolds [Page 45] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: RETR Retr retr ReTr rETr michael@0: michael@0: This also applies to any symbols representing parameter values, michael@0: such as A or a for ASCII TYPE. The command codes and the argument michael@0: fields are separated by one or more spaces. michael@0: michael@0: The argument field consists of a variable length character string michael@0: ending with the character sequence (Carriage Return, Line michael@0: Feed) for NVT-ASCII representation; for other negotiated languages michael@0: a different end of line character might be used. It should be michael@0: noted that the server is to take no action until the end of line michael@0: code is received. michael@0: michael@0: The syntax is specified below in NVT-ASCII. All characters in the michael@0: argument field are ASCII characters including any ASCII michael@0: represented decimal integers. Square brackets denote an optional michael@0: argument field. If the option is not taken, the appropriate michael@0: default is implied. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 46] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: 5.3.1. FTP COMMANDS michael@0: michael@0: The following are the FTP commands: michael@0: michael@0: USER michael@0: PASS michael@0: ACCT michael@0: CWD michael@0: CDUP michael@0: SMNT michael@0: QUIT michael@0: REIN michael@0: PORT michael@0: PASV michael@0: TYPE michael@0: STRU michael@0: MODE michael@0: RETR michael@0: STOR michael@0: STOU michael@0: APPE michael@0: ALLO michael@0: [ R ] michael@0: REST michael@0: RNFR michael@0: RNTO michael@0: ABOR michael@0: DELE michael@0: RMD michael@0: MKD michael@0: PWD michael@0: LIST [ ] michael@0: NLST [ ] michael@0: SITE michael@0: SYST michael@0: STAT [ ] michael@0: HELP [ ] michael@0: NOOP michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 47] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: 5.3.2. FTP COMMAND ARGUMENTS michael@0: michael@0: The syntax of the above argument fields (using BNF notation michael@0: where applicable) is: michael@0: michael@0: ::= michael@0: ::= michael@0: ::= michael@0: ::= | michael@0: ::= any of the 128 ASCII characters except and michael@0: michael@0: ::= michael@0: ::= | michael@0: ::= printable characters, any michael@0: ASCII code 33 through 126 michael@0: ::= michael@0: ::= , michael@0: ::= ,,, michael@0: ::= , michael@0: ::= any decimal integer 1 through 255 michael@0: ::= N | T | C michael@0: ::= A [ ] michael@0: | E [ ] michael@0: | I michael@0: | L michael@0: ::= F | R | P michael@0: ::= S | B | C michael@0: ::= michael@0: ::= any decimal integer michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 48] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: 5.4. SEQUENCING OF COMMANDS AND REPLIES michael@0: michael@0: The communication between the user and server is intended to be an michael@0: alternating dialogue. As such, the user issues an FTP command and michael@0: the server responds with a prompt primary reply. The user should michael@0: wait for this initial primary success or failure response before michael@0: sending further commands. michael@0: michael@0: Certain commands require a second reply for which the user should michael@0: also wait. These replies may, for example, report on the progress michael@0: or completion of file transfer or the closing of the data michael@0: connection. They are secondary replies to file transfer commands. michael@0: michael@0: One important group of informational replies is the connection michael@0: greetings. Under normal circumstances, a server will send a 220 michael@0: reply, "awaiting input", when the connection is completed. The michael@0: user should wait for this greeting message before sending any michael@0: commands. If the server is unable to accept input right away, a michael@0: 120 "expected delay" reply should be sent immediately and a 220 michael@0: reply when ready. The user will then know not to hang up if there michael@0: is a delay. michael@0: michael@0: Spontaneous Replies michael@0: michael@0: Sometimes "the system" spontaneously has a message to be sent michael@0: to a user (usually all users). For example, "System going down michael@0: in 15 minutes". There is no provision in FTP for such michael@0: spontaneous information to be sent from the server to the user. michael@0: It is recommended that such information be queued in the michael@0: server-PI and delivered to the user-PI in the next reply michael@0: (possibly making it a multi-line reply). michael@0: michael@0: The table below lists alternative success and failure replies for michael@0: each command. These must be strictly adhered to; a server may michael@0: substitute text in the replies, but the meaning and action implied michael@0: by the code numbers and by the specific command reply sequence michael@0: cannot be altered. michael@0: michael@0: Command-Reply Sequences michael@0: michael@0: In this section, the command-reply sequence is presented. Each michael@0: command is listed with its possible replies; command groups are michael@0: listed together. Preliminary replies are listed first (with michael@0: their succeeding replies indented and under them), then michael@0: positive and negative completion, and finally intermediary michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 49] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: replies with the remaining commands from the sequence michael@0: following. This listing forms the basis for the state michael@0: diagrams, which will be presented separately. michael@0: michael@0: Connection Establishment michael@0: 120 michael@0: 220 michael@0: 220 michael@0: 421 michael@0: Login michael@0: USER michael@0: 230 michael@0: 530 michael@0: 500, 501, 421 michael@0: 331, 332 michael@0: PASS michael@0: 230 michael@0: 202 michael@0: 530 michael@0: 500, 501, 503, 421 michael@0: 332 michael@0: ACCT michael@0: 230 michael@0: 202 michael@0: 530 michael@0: 500, 501, 503, 421 michael@0: CWD michael@0: 250 michael@0: 500, 501, 502, 421, 530, 550 michael@0: CDUP michael@0: 200 michael@0: 500, 501, 502, 421, 530, 550 michael@0: SMNT michael@0: 202, 250 michael@0: 500, 501, 502, 421, 530, 550 michael@0: Logout michael@0: REIN michael@0: 120 michael@0: 220 michael@0: 220 michael@0: 421 michael@0: 500, 502 michael@0: QUIT michael@0: 221 michael@0: 500 michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 50] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: Transfer parameters michael@0: PORT michael@0: 200 michael@0: 500, 501, 421, 530 michael@0: PASV michael@0: 227 michael@0: 500, 501, 502, 421, 530 michael@0: MODE michael@0: 200 michael@0: 500, 501, 504, 421, 530 michael@0: TYPE michael@0: 200 michael@0: 500, 501, 504, 421, 530 michael@0: STRU michael@0: 200 michael@0: 500, 501, 504, 421, 530 michael@0: File action commands michael@0: ALLO michael@0: 200 michael@0: 202 michael@0: 500, 501, 504, 421, 530 michael@0: REST michael@0: 500, 501, 502, 421, 530 michael@0: 350 michael@0: STOR michael@0: 125, 150 michael@0: (110) michael@0: 226, 250 michael@0: 425, 426, 451, 551, 552 michael@0: 532, 450, 452, 553 michael@0: 500, 501, 421, 530 michael@0: STOU michael@0: 125, 150 michael@0: (110) michael@0: 226, 250 michael@0: 425, 426, 451, 551, 552 michael@0: 532, 450, 452, 553 michael@0: 500, 501, 421, 530 michael@0: RETR michael@0: 125, 150 michael@0: (110) michael@0: 226, 250 michael@0: 425, 426, 451 michael@0: 450, 550 michael@0: 500, 501, 421, 530 michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 51] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: LIST michael@0: 125, 150 michael@0: 226, 250 michael@0: 425, 426, 451 michael@0: 450 michael@0: 500, 501, 502, 421, 530 michael@0: NLST michael@0: 125, 150 michael@0: 226, 250 michael@0: 425, 426, 451 michael@0: 450 michael@0: 500, 501, 502, 421, 530 michael@0: APPE michael@0: 125, 150 michael@0: (110) michael@0: 226, 250 michael@0: 425, 426, 451, 551, 552 michael@0: 532, 450, 550, 452, 553 michael@0: 500, 501, 502, 421, 530 michael@0: RNFR michael@0: 450, 550 michael@0: 500, 501, 502, 421, 530 michael@0: 350 michael@0: RNTO michael@0: 250 michael@0: 532, 553 michael@0: 500, 501, 502, 503, 421, 530 michael@0: DELE michael@0: 250 michael@0: 450, 550 michael@0: 500, 501, 502, 421, 530 michael@0: RMD michael@0: 250 michael@0: 500, 501, 502, 421, 530, 550 michael@0: MKD michael@0: 257 michael@0: 500, 501, 502, 421, 530, 550 michael@0: PWD michael@0: 257 michael@0: 500, 501, 502, 421, 550 michael@0: ABOR michael@0: 225, 226 michael@0: 500, 501, 502, 421 michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 52] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: Informational commands michael@0: SYST michael@0: 215 michael@0: 500, 501, 502, 421 michael@0: STAT michael@0: 211, 212, 213 michael@0: 450 michael@0: 500, 501, 502, 421, 530 michael@0: HELP michael@0: 211, 214 michael@0: 500, 501, 502, 421 michael@0: Miscellaneous commands michael@0: SITE michael@0: 200 michael@0: 202 michael@0: 500, 501, 530 michael@0: NOOP michael@0: 200 michael@0: 500 421 michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 53] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: 6. STATE DIAGRAMS michael@0: michael@0: Here we present state diagrams for a very simple minded FTP michael@0: implementation. Only the first digit of the reply codes is used. michael@0: There is one state diagram for each group of FTP commands or command michael@0: sequences. michael@0: michael@0: The command groupings were determined by constructing a model for michael@0: each command then collecting together the commands with structurally michael@0: identical models. michael@0: michael@0: For each command or command sequence there are three possible michael@0: outcomes: success (S), failure (F), and error (E). In the state michael@0: diagrams below we use the symbol B for "begin", and the symbol W for michael@0: "wait for reply". michael@0: michael@0: We first present the diagram that represents the largest group of FTP michael@0: commands: michael@0: michael@0: michael@0: 1,3 +---+ michael@0: ----------->| E | michael@0: | +---+ michael@0: | michael@0: +---+ cmd +---+ 2 +---+ michael@0: | B |---------->| W |---------->| S | michael@0: +---+ +---+ +---+ michael@0: | michael@0: | 4,5 +---+ michael@0: ----------->| F | michael@0: +---+ michael@0: michael@0: michael@0: This diagram models the commands: michael@0: michael@0: ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV, michael@0: QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, and TYPE. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 54] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: The other large group of commands is represented by a very similar michael@0: diagram: michael@0: michael@0: michael@0: 3 +---+ michael@0: ----------->| E | michael@0: | +---+ michael@0: | michael@0: +---+ cmd +---+ 2 +---+ michael@0: | B |---------->| W |---------->| S | michael@0: +---+ --->+---+ +---+ michael@0: | | | michael@0: | | | 4,5 +---+ michael@0: | 1 | ----------->| F | michael@0: ----- +---+ michael@0: michael@0: michael@0: This diagram models the commands: michael@0: michael@0: APPE, LIST, NLST, REIN, RETR, STOR, and STOU. michael@0: michael@0: Note that this second model could also be used to represent the first michael@0: group of commands, the only difference being that in the first group michael@0: the 100 series replies are unexpected and therefore treated as error, michael@0: while the second group expects (some may require) 100 series replies. michael@0: Remember that at most, one 100 series reply is allowed per command. michael@0: michael@0: The remaining diagrams model command sequences, perhaps the simplest michael@0: of these is the rename sequence: michael@0: michael@0: michael@0: +---+ RNFR +---+ 1,2 +---+ michael@0: | B |---------->| W |---------->| E | michael@0: +---+ +---+ -->+---+ michael@0: | | | michael@0: 3 | | 4,5 | michael@0: -------------- ------ | michael@0: | | | +---+ michael@0: | ------------->| S | michael@0: | | 1,3 | | +---+ michael@0: | 2| -------- michael@0: | | | | michael@0: V | | | michael@0: +---+ RNTO +---+ 4,5 ----->+---+ michael@0: | |---------->| W |---------->| F | michael@0: +---+ +---+ +---+ michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 55] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: The next diagram is a simple model of the Restart command: michael@0: michael@0: michael@0: +---+ REST +---+ 1,2 +---+ michael@0: | B |---------->| W |---------->| E | michael@0: +---+ +---+ -->+---+ michael@0: | | | michael@0: 3 | | 4,5 | michael@0: -------------- ------ | michael@0: | | | +---+ michael@0: | ------------->| S | michael@0: | | 3 | | +---+ michael@0: | 2| -------- michael@0: | | | | michael@0: V | | | michael@0: +---+ cmd +---+ 4,5 ----->+---+ michael@0: | |---------->| W |---------->| F | michael@0: +---+ -->+---+ +---+ michael@0: | | michael@0: | 1 | michael@0: ------ michael@0: michael@0: michael@0: Where "cmd" is APPE, STOR, or RETR. michael@0: michael@0: We note that the above three models are similar. The Restart differs michael@0: from the Rename two only in the treatment of 100 series replies at michael@0: the second stage, while the second group expects (some may require) michael@0: 100 series replies. Remember that at most, one 100 series reply is michael@0: allowed per command. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 56] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: The most complicated diagram is for the Login sequence: michael@0: michael@0: michael@0: 1 michael@0: +---+ USER +---+------------->+---+ michael@0: | B |---------->| W | 2 ---->| E | michael@0: +---+ +---+------ | -->+---+ michael@0: | | | | | michael@0: 3 | | 4,5 | | | michael@0: -------------- ----- | | | michael@0: | | | | | michael@0: | | | | | michael@0: | --------- | michael@0: | 1| | | | michael@0: V | | | | michael@0: +---+ PASS +---+ 2 | ------>+---+ michael@0: | |---------->| W |------------->| S | michael@0: +---+ +---+ ---------->+---+ michael@0: | | | | | michael@0: 3 | |4,5| | | michael@0: -------------- -------- | michael@0: | | | | | michael@0: | | | | | michael@0: | ----------- michael@0: | 1,3| | | | michael@0: V | 2| | | michael@0: +---+ ACCT +---+-- | ----->+---+ michael@0: | |---------->| W | 4,5 -------->| F | michael@0: +---+ +---+------------->+---+ michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 57] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: Finally, we present a generalized diagram that could be used to model michael@0: the command and reply interchange: michael@0: michael@0: michael@0: ------------------------------------ michael@0: | | michael@0: Begin | | michael@0: | V | michael@0: | +---+ cmd +---+ 2 +---+ | michael@0: -->| |------->| |---------->| | | michael@0: | | | W | | S |-----| michael@0: -->| | -->| |----- | | | michael@0: | +---+ | +---+ 4,5 | +---+ | michael@0: | | | | | | | michael@0: | | | 1| |3 | +---+ | michael@0: | | | | | | | | | michael@0: | | ---- | ---->| F |----- michael@0: | | | | | michael@0: | | | +---+ michael@0: ------------------- michael@0: | michael@0: | michael@0: V michael@0: End michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 58] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: 7. TYPICAL FTP SCENARIO michael@0: michael@0: User at host U wanting to transfer files to/from host S: michael@0: michael@0: In general, the user will communicate to the server via a mediating michael@0: user-FTP process. The following may be a typical scenario. The michael@0: user-FTP prompts are shown in parentheses, '---->' represents michael@0: commands from host U to host S, and '<----' represents replies from michael@0: host S to host U. michael@0: michael@0: LOCAL COMMANDS BY USER ACTION INVOLVED michael@0: michael@0: ftp (host) multics Connect to host S, port L, michael@0: establishing control connections. michael@0: <---- 220 Service ready . michael@0: username Doe USER Doe----> michael@0: <---- 331 User name ok, michael@0: need password. michael@0: password mumble PASS mumble----> michael@0: <---- 230 User logged in. michael@0: retrieve (local type) ASCII michael@0: (local pathname) test 1 User-FTP opens local file in ASCII. michael@0: (for. pathname) test.pl1 RETR test.pl1 ----> michael@0: <---- 150 File status okay; michael@0: about to open data michael@0: connection. michael@0: Server makes data connection michael@0: to port U. michael@0: michael@0: <---- 226 Closing data connection, michael@0: file transfer successful. michael@0: type Image TYPE I ----> michael@0: <---- 200 Command OK michael@0: store (local type) image michael@0: (local pathname) file dump User-FTP opens local file in Image. michael@0: (for.pathname) >udd>cn>fd STOR >udd>cn>fd ----> michael@0: <---- 550 Access denied michael@0: terminate QUIT ----> michael@0: Server closes all michael@0: connections. michael@0: michael@0: 8. CONNECTION ESTABLISHMENT michael@0: michael@0: The FTP control connection is established via TCP between the user michael@0: process port U and the server process port L. This protocol is michael@0: assigned the service port 21 (25 octal), that is L=21. michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 59] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: APPENDIX I - PAGE STRUCTURE michael@0: michael@0: The need for FTP to support page structure derives principally from michael@0: the need to support efficient transmission of files between TOPS-20 michael@0: systems, particularly the files used by NLS. michael@0: michael@0: The file system of TOPS-20 is based on the concept of pages. The michael@0: operating system is most efficient at manipulating files as pages. michael@0: The operating system provides an interface to the file system so that michael@0: many applications view files as sequential streams of characters. michael@0: However, a few applications use the underlying page structures michael@0: directly, and some of these create holey files. michael@0: michael@0: A TOPS-20 disk file consists of four things: a pathname, a page michael@0: table, a (possibly empty) set of pages, and a set of attributes. michael@0: michael@0: The pathname is specified in the RETR or STOR command. It includes michael@0: the directory name, file name, file name extension, and generation michael@0: number. michael@0: michael@0: The page table contains up to 2**18 entries. Each entry may be michael@0: EMPTY, or may point to a page. If it is not empty, there are also michael@0: some page-specific access bits; not all pages of a file need have the michael@0: same access protection. michael@0: michael@0: A page is a contiguous set of 512 words of 36 bits each. michael@0: michael@0: The attributes of the file, in the File Descriptor Block (FDB), michael@0: contain such things as creation time, write time, read time, writer's michael@0: byte-size, end-of-file pointer, count of reads and writes, backup michael@0: system tape numbers, etc. michael@0: michael@0: Note that there is NO requirement that entries in the page table be michael@0: contiguous. There may be empty page table slots between occupied michael@0: ones. Also, the end of file pointer is simply a number. There is no michael@0: requirement that it in fact point at the "last" datum in the file. michael@0: Ordinary sequential I/O calls in TOPS-20 will cause the end of file michael@0: pointer to be left after the last datum written, but other operations michael@0: may cause it not to be so, if a particular programming system so michael@0: requires. michael@0: michael@0: In fact, in both of these special cases, "holey" files and michael@0: end-of-file pointers NOT at the end of the file, occur with NLS data michael@0: files. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 60] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: The TOPS-20 paged files can be sent with the FTP transfer parameters: michael@0: TYPE L 36, STRU P, and MODE S (in fact, any mode could be used). michael@0: michael@0: Each page of information has a header. Each header field, which is a michael@0: logical byte, is a TOPS-20 word, since the TYPE is L 36. michael@0: michael@0: The header fields are: michael@0: michael@0: Word 0: Header Length. michael@0: michael@0: The header length is 5. michael@0: michael@0: Word 1: Page Index. michael@0: michael@0: If the data is a disk file page, this is the number of that michael@0: page in the file's page map. Empty pages (holes) in the file michael@0: are simply not sent. Note that a hole is NOT the same as a michael@0: page of zeros. michael@0: michael@0: Word 2: Data Length. michael@0: michael@0: The number of data words in this page, following the header. michael@0: Thus, the total length of the transmission unit is the Header michael@0: Length plus the Data Length. michael@0: michael@0: Word 3: Page Type. michael@0: michael@0: A code for what type of chunk this is. A data page is type 3, michael@0: the FDB page is type 2. michael@0: michael@0: Word 4: Page Access Control. michael@0: michael@0: The access bits associated with the page in the file's page michael@0: map. (This full word quantity is put into AC2 of an SPACS by michael@0: the program reading from net to disk.) michael@0: michael@0: After the header are Data Length data words. Data Length is michael@0: currently either 512 for a data page or 31 for an FDB. Trailing michael@0: zeros in a disk file page may be discarded, making Data Length less michael@0: than 512 in that case. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 61] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: APPENDIX II - DIRECTORY COMMANDS michael@0: michael@0: Since UNIX has a tree-like directory structure in which directories michael@0: are as easy to manipulate as ordinary files, it is useful to expand michael@0: the FTP servers on these machines to include commands which deal with michael@0: the creation of directories. Since there are other hosts on the michael@0: ARPA-Internet which have tree-like directories (including TOPS-20 and michael@0: Multics), these commands are as general as possible. michael@0: michael@0: Four directory commands have been added to FTP: michael@0: michael@0: MKD pathname michael@0: michael@0: Make a directory with the name "pathname". michael@0: michael@0: RMD pathname michael@0: michael@0: Remove the directory with the name "pathname". michael@0: michael@0: PWD michael@0: michael@0: Print the current working directory name. michael@0: michael@0: CDUP michael@0: michael@0: Change to the parent of the current working directory. michael@0: michael@0: The "pathname" argument should be created (removed) as a michael@0: subdirectory of the current working directory, unless the "pathname" michael@0: string contains sufficient information to specify otherwise to the michael@0: server, e.g., "pathname" is an absolute pathname (in UNIX and michael@0: Multics), or pathname is something like "" to michael@0: TOPS-20. michael@0: michael@0: REPLY CODES michael@0: michael@0: The CDUP command is a special case of CWD, and is included to michael@0: simplify the implementation of programs for transferring directory michael@0: trees between operating systems having different syntaxes for michael@0: naming the parent directory. The reply codes for CDUP be michael@0: identical to the reply codes of CWD. michael@0: michael@0: The reply codes for RMD be identical to the reply codes for its michael@0: file analogue, DELE. michael@0: michael@0: The reply codes for MKD, however, are a bit more complicated. A michael@0: freshly created directory will probably be the object of a future michael@0: michael@0: michael@0: Postel & Reynolds [Page 62] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: CWD command. Unfortunately, the argument to MKD may not always be michael@0: a suitable argument for CWD. This is the case, for example, when michael@0: a TOPS-20 subdirectory is created by giving just the subdirectory michael@0: name. That is, with a TOPS-20 server FTP, the command sequence michael@0: michael@0: MKD MYDIR michael@0: CWD MYDIR michael@0: michael@0: will fail. The new directory may only be referred to by its michael@0: "absolute" name; e.g., if the MKD command above were issued while michael@0: connected to the directory , the new subdirectory michael@0: could only be referred to by the name . michael@0: michael@0: Even on UNIX and Multics, however, the argument given to MKD may michael@0: not be suitable. If it is a "relative" pathname (i.e., a pathname michael@0: which is interpreted relative to the current directory), the user michael@0: would need to be in the same current directory in order to reach michael@0: the subdirectory. Depending on the application, this may be michael@0: inconvenient. It is not very robust in any case. michael@0: michael@0: To solve these problems, upon successful completion of an MKD michael@0: command, the server should return a line of the form: michael@0: michael@0: 257"" michael@0: michael@0: That is, the server will tell the user what string to use when michael@0: referring to the created directory. The directory name can michael@0: contain any character; embedded double-quotes should be escaped by michael@0: double-quotes (the "quote-doubling" convention). michael@0: michael@0: For example, a user connects to the directory /usr/dm, and creates michael@0: a subdirectory, named pathname: michael@0: michael@0: CWD /usr/dm michael@0: 200 directory changed to /usr/dm michael@0: MKD pathname michael@0: 257 "/usr/dm/pathname" directory created michael@0: michael@0: An example with an embedded double quote: michael@0: michael@0: MKD foo"bar michael@0: 257 "/usr/dm/foo""bar" directory created michael@0: CWD /usr/dm/foo"bar michael@0: 200 directory changed to /usr/dm/foo"bar michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 63] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: The prior existence of a subdirectory with the same name is an michael@0: error, and the server must return an "access denied" error reply michael@0: in that case. michael@0: michael@0: CWD /usr/dm michael@0: 200 directory changed to /usr/dm michael@0: MKD pathname michael@0: 521-"/usr/dm/pathname" directory already exists; michael@0: 521 taking no action. michael@0: michael@0: The failure replies for MKD are analogous to its file creating michael@0: cousin, STOR. Also, an "access denied" return is given if a file michael@0: name with the same name as the subdirectory will conflict with the michael@0: creation of the subdirectory (this is a problem on UNIX, but michael@0: shouldn't be one on TOPS-20). michael@0: michael@0: Essentially because the PWD command returns the same type of michael@0: information as the successful MKD command, the successful PWD michael@0: command uses the 257 reply code as well. michael@0: michael@0: SUBTLETIES michael@0: michael@0: Because these commands will be most useful in transferring michael@0: subtrees from one machine to another, carefully observe that the michael@0: argument to MKD is to be interpreted as a sub-directory of the michael@0: current working directory, unless it contains enough information michael@0: for the destination host to tell otherwise. A hypothetical michael@0: example of its use in the TOPS-20 world: michael@0: michael@0: CWD michael@0: 200 Working directory changed michael@0: MKD overrainbow michael@0: 257 "" directory created michael@0: CWD overrainbow michael@0: 431 No such directory michael@0: CWD michael@0: 200 Working directory changed michael@0: michael@0: CWD michael@0: 200 Working directory changed to michael@0: MKD michael@0: 257 "" directory created michael@0: CWD michael@0: michael@0: Note that the first example results in a subdirectory of the michael@0: connected directory. In contrast, the argument in the second michael@0: example contains enough information for TOPS-20 to tell that the michael@0: michael@0: michael@0: Postel & Reynolds [Page 64] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: directory is a top-level directory. Note also that michael@0: in the first example the user "violated" the protocol by michael@0: attempting to access the freshly created directory with a name michael@0: other than the one returned by TOPS-20. Problems could have michael@0: resulted in this case had there been an directory; michael@0: this is an ambiguity inherent in some TOPS-20 implementations. michael@0: Similar considerations apply to the RMD command. The point is michael@0: this: except where to do so would violate a host's conventions for michael@0: denoting relative versus absolute pathnames, the host should treat michael@0: the operands of the MKD and RMD commands as subdirectories. The michael@0: 257 reply to the MKD command must always contain the absolute michael@0: pathname of the created directory. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 65] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: APPENDIX III - RFCs on FTP michael@0: michael@0: Bhushan, Abhay, "A File Transfer Protocol", RFC 114 (NIC 5823), michael@0: MIT-Project MAC, 16 April 1971. michael@0: michael@0: Harslem, Eric, and John Heafner, "Comments on RFC 114 (A File michael@0: Transfer Protocol)", RFC 141 (NIC 6726), RAND, 29 April 1971. michael@0: michael@0: Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172 michael@0: (NIC 6794), MIT-Project MAC, 23 June 1971. michael@0: michael@0: Braden, Bob, "Comments on DTP and FTP Proposals", RFC 238 (NIC 7663), michael@0: UCLA/CCN, 29 September 1971. michael@0: michael@0: Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 265 michael@0: (NIC 7813), MIT-Project MAC, 17 November 1971. michael@0: michael@0: McKenzie, Alex, "A Suggested Addition to File Transfer Protocol", michael@0: RFC 281 (NIC 8163), BBN, 8 December 1971. michael@0: michael@0: Bhushan, Abhay, "The Use of "Set Data Type" Transaction in File michael@0: Transfer Protocol", RFC 294 (NIC 8304), MIT-Project MAC, michael@0: 25 January 1972. michael@0: michael@0: Bhushan, Abhay, "The File Transfer Protocol", RFC 354 (NIC 10596), michael@0: MIT-Project MAC, 8 July 1972. michael@0: michael@0: Bhushan, Abhay, "Comments on the File Transfer Protocol (RFC 354)", michael@0: RFC 385 (NIC 11357), MIT-Project MAC, 18 August 1972. michael@0: michael@0: Hicks, Greg, "User FTP Documentation", RFC 412 (NIC 12404), Utah, michael@0: 27 November 1972. michael@0: michael@0: Bhushan, Abhay, "File Transfer Protocol (FTP) Status and Further michael@0: Comments", RFC 414 (NIC 12406), MIT-Project MAC, 20 November 1972. michael@0: michael@0: Braden, Bob, "Comments on File Transfer Protocol", RFC 430 michael@0: (NIC 13299), UCLA/CCN, 7 February 1973. michael@0: michael@0: Thomas, Bob, and Bob Clements, "FTP Server-Server Interaction", michael@0: RFC 438 (NIC 13770), BBN, 15 January 1973. michael@0: michael@0: Braden, Bob, "Print Files in FTP", RFC 448 (NIC 13299), UCLA/CCN, michael@0: 27 February 1973. michael@0: michael@0: McKenzie, Alex, "File Transfer Protocol", RFC 454 (NIC 14333), BBN, michael@0: 16 February 1973. michael@0: michael@0: michael@0: Postel & Reynolds [Page 66] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: Bressler, Bob, and Bob Thomas, "Mail Retrieval via FTP", RFC 458 michael@0: (NIC 14378), BBN-NET and BBN-TENEX, 20 February 1973. michael@0: michael@0: Neigus, Nancy, "File Transfer Protocol", RFC 542 (NIC 17759), BBN, michael@0: 12 July 1973. michael@0: michael@0: Krilanovich, Mark, and George Gregg, "Comments on the File Transfer michael@0: Protocol", RFC 607 (NIC 21255), UCSB, 7 January 1974. michael@0: michael@0: Pogran, Ken, and Nancy Neigus, "Response to RFC 607 - Comments on the michael@0: File Transfer Protocol", RFC 614 (NIC 21530), BBN, 28 January 1974. michael@0: michael@0: Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White, michael@0: "Comments on the File Transfer Protocol", RFC 624 (NIC 22054), UCSB, michael@0: Ames Research Center, SRI-ARC, 28 February 1974. michael@0: michael@0: Bhushan, Abhay, "FTP Comments and Response to RFC 430", RFC 463 michael@0: (NIC 14573), MIT-DMCG, 21 February 1973. michael@0: michael@0: Braden, Bob, "FTP Data Compression", RFC 468 (NIC 14742), UCLA/CCN, michael@0: 8 March 1973. michael@0: michael@0: Bhushan, Abhay, "FTP and Network Mail System", RFC 475 (NIC 14919), michael@0: MIT-DMCG, 6 March 1973. michael@0: michael@0: Bressler, Bob, and Bob Thomas "FTP Server-Server Interaction - II", michael@0: RFC 478 (NIC 14947), BBN-NET and BBN-TENEX, 26 March 1973. michael@0: michael@0: White, Jim, "Use of FTP by the NIC Journal", RFC 479 (NIC 14948), michael@0: SRI-ARC, 8 March 1973. michael@0: michael@0: White, Jim, "Host-Dependent FTP Parameters", RFC 480 (NIC 14949), michael@0: SRI-ARC, 8 March 1973. michael@0: michael@0: Padlipsky, Mike, "An FTP Command-Naming Problem", RFC 506 michael@0: (NIC 16157), MIT-Multics, 26 June 1973. michael@0: michael@0: Day, John, "Memo to FTP Group (Proposal for File Access Protocol)", michael@0: RFC 520 (NIC 16819), Illinois, 25 June 1973. michael@0: michael@0: Merryman, Robert, "The UCSD-CC Server-FTP Facility", RFC 532 michael@0: (NIC 17451), UCSD-CC, 22 June 1973. michael@0: michael@0: Braden, Bob, "TENEX FTP Problem", RFC 571 (NIC 18974), UCLA/CCN, michael@0: 15 November 1973. michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 67] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: McKenzie, Alex, and Jon Postel, "Telnet and FTP Implementation - michael@0: Schedule Change", RFC 593 (NIC 20615), BBN and MITRE, michael@0: 29 November 1973. michael@0: michael@0: Sussman, Julie, "FTP Error Code Usage for More Reliable Mail michael@0: Service", RFC 630 (NIC 30237), BBN, 10 April 1974. michael@0: michael@0: Postel, Jon, "Revised FTP Reply Codes", RFC 640 (NIC 30843), michael@0: UCLA/NMC, 5 June 1974. michael@0: michael@0: Harvey, Brian, "Leaving Well Enough Alone", RFC 686 (NIC 32481), michael@0: SU-AI, 10 May 1975. michael@0: michael@0: Harvey, Brian, "One More Try on the FTP", RFC 691 (NIC 32700), SU-AI, michael@0: 28 May 1975. michael@0: michael@0: Lieb, J., "CWD Command of FTP", RFC 697 (NIC 32963), 14 July 1975. michael@0: michael@0: Harrenstien, Ken, "FTP Extension: XSEN", RFC 737 (NIC 42217), SRI-KL, michael@0: 31 October 1977. michael@0: michael@0: Harrenstien, Ken, "FTP Extension: XRSQ/XRCP", RFC 743 (NIC 42758), michael@0: SRI-KL, 30 December 1977. michael@0: michael@0: Lebling, P. David, "Survey of FTP Mail and MLFL", RFC 751, MIT, michael@0: 10 December 1978. michael@0: michael@0: Postel, Jon, "File Transfer Protocol Specification", RFC 765, ISI, michael@0: June 1980. michael@0: michael@0: Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP michael@0: Commands", RFC 776, BBN, December 1980. michael@0: michael@0: Padlipsky, Michael, "FTP Unique-Named Store Command", RFC 949, MITRE, michael@0: July 1985. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 68] michael@0: michael@0: michael@0: michael@0: RFC 959 October 1985 michael@0: File Transfer Protocol michael@0: michael@0: michael@0: REFERENCES michael@0: michael@0: [1] Feinler, Elizabeth, "Internet Protocol Transition Workbook", michael@0: Network Information Center, SRI International, March 1982. michael@0: michael@0: [2] Postel, Jon, "Transmission Control Protocol - DARPA Internet michael@0: Program Protocol Specification", RFC 793, DARPA, September 1981. michael@0: michael@0: [3] Postel, Jon, and Joyce Reynolds, "Telnet Protocol michael@0: Specification", RFC 854, ISI, May 1983. michael@0: michael@0: [4] Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC 943, michael@0: ISI, April 1985. michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: michael@0: Postel & Reynolds [Page 69] michael@0: