diff options
Diffstat (limited to 'doc/rfc/rfc354.txt')
| -rw-r--r-- | doc/rfc/rfc354.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc354.txt b/doc/rfc/rfc354.txt new file mode 100644 index 0000000..6aa4098 --- /dev/null +++ b/doc/rfc/rfc354.txt @@ -0,0 +1,1403 @@ + + + + + + +Network Working Group Abhay Bhushan +Request for Comments: 354 MIT-MAC +NIC: 10596 July 8, 1972 +Categories D.4, D.5, D.7 +Obsoletes: RFC 264 and 265 + + + THE FILE TRANSFER PROTOCOL + + +I. INTRODUCTION + + The File Transfer Protocol (FTP) is a protocol for file +transfer betweet HOSTs (including terminal IMPs), on the ARPA +Computer Network (ARPANET). The primary function of FTP is to +transfer files efficiently and reliably among HOSTs and to allow +the convenient use of remote file storage capabilities. + + The objectives of FTP are 1) to promote sharing of files +(computer programs and/or data), 2) fo encourage indirect or +implicit (via programs) use of remote computers, 3) to shield a +user from variations in file storage systems among HOSTs, and +4) to transfer data reliably and efficiently. FTP, though usable +directly by user at a terminal, is designed mainly for use by +programs. + + The attempt in this specification is to satisfy the diverse +needs of users of maxi-HOSTs, mini-HOSTs, TIPs, and the +Datacomputer, with a simple, elegant, and easily implemented +protocol design. + + This paper assumes knowledge of the following protocols: + + 1) The HOST-HOST Protocol (NIC #8246) + + 2) The initial Connection Protocol (NIC #7101) + + 3) The TELNET Protocol (NWG/RFC #318, NIC #9348) + +II. DISCUSSION + + In this section, the terminology and the FTP model are +discussed. The terms defined in this section are only those that +have special significance in FTP. + + + + + + + + [Page 1] + +The File Transfer Protocol July 8, 1972 + + +11.A. Terminology + +ASCII The USASCII character set as defined in NIC + #7104. In FTP, ASCII characters are defined + to be the lower half of an eight bit code set + (i.e., the most significant bit es zero). + +access controls Access controls define users' access + privileges to the use of a system, and to the + files in that system. Access controls are + necessary to prevent unauthorized or + accidental use of files. It is the + prerogative of a user-FTP process to provide + access controls. + +byte size The byte size specified for the transfer of + data. The data connection is opened with + this byte size. Data connection byte size is + not necessarily the byte size in which data + is to be stored in a system, and may not be + related to the structure of data. + +data connection A simplex connection over which data is + transferred, in a specified byte size, mode + and type. The data transferred may be a part + of a file, an entire file or a number of + files. The data connection may be in either + direction (server-to-user or user-to server). + +data socket The socket on which a User-FTP process + "listens" for a data connection. + +EOF The end-of-file conidition that defines the + end of a file being transferred. + +EOR The end-of-record condition that defines the + end of a record being transferred. + +error recovery A procedure that allows a user to recover + form certain errors such as failure of either + Host system or transfer process In FTP, + error recovery may involve restarting a file + transfer at a given checkpoint + +FTP commands A set of commands that comprise the control + information flowing from the user-FTP to the + server-FTP process. + + + + + [Page 2] + +The File Transfer Protocol July 8, 1972 + + +file An ordered set of computer data (including + programs) of arbitrary length uniquely + identified by a pathname. + +mode The mode in which data is to be transferred + via the data connection. The mode defines + the data format including EOR and EOF. The + transfer modes defined in FTP are described + in Section III.A. + +NVT The Network Virtual Terminal as defined in + the ARPANET TELNET Protocol. + +NVFS The Network Virtual File System. A concept + which defines a standard network file system + with standard commands and pathname + conventions. FTP only partially embraces the + NFS concept at this time. + +pathname Pathname is defined to be the character + string which must be input to a file system + by a user in order to identify a file. + Pathname normally contains device and/or + directory names, and file name specification. + FTP does not yet specify a standard pathname + convention. Each user must follow the file + naming conventions of hte file systems he + wishes to use. + +record A sequential file may be structured as a + number of contiguous parts called records. + Record structures are supported by FTP but + are not mandatory. + +reply A reply is an acknowledgment (positive or + negative) sent from server to user via the + telnet connections in response to FTP + commands. The general form of a reply is a + completion code (including error codes) + followed by an ASCII text string. The codes + are for use by programs and the text is for + human users. + +server-FTP process A process or set of processes which perform + the function of file transfer in cooperation + with a user-FTP process. The server-FTP + process must interpret and respond to user + commands and initiate the data connection. + + + + [Page 3] + +The File Transfer Protocol July 8, 1972 + + +server site A HOST site wich has a server-FTP process. + +server-TELNET A TELNET process which listens on a specified + socket for an ICP initiated by a user-TELNET, + and perform in accordance with the ARPANET + TELNET Protocol. + +TELNET connections The full-duplex communication path between a + user-TELNET and a server-TELNET. The TELNET + connections are established via the standard + ARPANET initial Connection Protocol (ICP). + +type The data representation type used for data + transfer and storage. Type implies certain + transformations between the time of data + storage and data transfer. The + representation types defined in FTP are + described in Section III.B. + +user A process on behalf of a human being or a + human being wishing to obtain file transfer + service. + +user site A HOST site satisfying any of the following + conditions: 1) The site where a user is + located, 2) a site where a user-FTP process + is located, 3) a site to which a data + connection is made by a server. In the + normal case, the sites defined by 1, 2, and 3 + are the same site, but nothing in FTP + requires that this be so. + +user-FTP process A process or set of precesses which perform + the function of file transfer in cooperation + with a server-FTP process. The user-FTP + process 1) initiates the ICP (via a + user-TELNET, 2) initiates FTP commands and + 3) "listens" on the data socket for the data + connection. In some obvious cases (use from + TIPs and other mini-HOSTs) a user-FTP process + will be subsumed under the term "user". + +user-TELNET A TELNET process which initiates an ICP to a + specified server-TELNET socket, and performs + in accordance with the ARPANET TELNET + protocol. + + + + + + [Page 4] + +The File Transfer Protocol July 8, 1972 + + +II.B. The FTP Model + + With the above definitions in mind, the following model +(shown in Figure 1) may be diagrammed for an FTP service. + + + TELNET + connections +File Server Server<------------ User User File +Systems<-> FTP <->TELNET FTP Commands TELNET<->FTP <->System + Process ------------> Process + + Data + <------------------------------>Socket + Data Connection(s) | + | + USER + + + + +Notes: 1. The data connection may be in either direction. + + 2. The data connection need not exist all of the time. + + 3. The distinctions between user-FTP and user-TELNET, + and between server-FTP and server-TELNET may not + be as clear-cut as shown above. For example, a user- + TELNET may be directly driven by the user. + + + + FIGURE 1 Model for FTP Use + + + In the model described in Figure 1, the user-TELNET +initiates the TELNET connection. Standard FTP commands are then +generated by the user and transmitted to the server site via the TELNET +connections. FTP commands are in ASCII, in accordance with NVT +conventions and the TELNET protocol. Note that commands may be initiated +by the user directly through the user-TELNET or via a user-FTP process. +Standard replies are sent from the server to the user in response to the +commands over the TELNET connections. + + The FTP commands specify the parameters for teh data +connection (data socket, byte size, transfer mode, and representation +type), and the nature of file system operation (store, retrieve, append, +delete, etc.). The user-FTP process or its designate should "listen" on + + + + [Page 5] + +The File Transfer Protocol July 8, 1972 + + +the specified data socket, and it is the server's responsibility to +initiate the data connection and data transfer in accordance with the +specified data connection parameters. It should be noted that the data +socket need not be in the same HOST that initiates the FTP commands via +the TELNET connection, but the user or his user-FTP process must ensure +a "listen" on the specified data socket. A practical example of such +file transfer to third HOSTs is a maxi-HOST user (who may actually be a +TIP user) whishing to transmit a file to or from an I/O device attached +to a TIP. It should also be noted that two data connections, one for +send and the other for receive, may exist simultaneously. + + The protocol requires that the TELNET connections be open +while data transfer is in progress. It is the responsibility of the user +to close the TELNET connections when finished using the FTP service. The +server may abort data transfer if the TELNET connections are closed. + +III. DATA TRANSFER FUNCTIONS + + Data and files are transferred only via the data connection. +The data transfer of data is governed by FTP data transfer commands +received on the TELNET connections. The data transfer functions include +establishing the data connection to the specified data socket in the +specified HOST (using the specified byte size), transmitting and +receiving data in the specified representation type and transfer mode, +handling EOR and EOF conditions and error recovery (where applicable). + +III.A Establishing Data Connection + + The user site shall "listen" on the specified data socket. +The FTP request command determines the direction of data transfer, and +the socket number (odd or even) which is to be used in establishing the +data connection. The server on receiving the appropriate store or +retrieve request shall initiate the data connection to the specified +user data socket in the specified byte size (default byte size is 8 +bits) and send a reply indicating that file transfer may proceed. Prior +to this the server should send a reply indicating the server socket for +the data connection. The user may use this server socket information to +ensure the security of his data transfer. The server may send this reply +either before of after initiating the data connection. + + The byte size for the data connection is specified by the +TYPE (ASCII is 8 bits), or TYPE and BYTE commands. It is not required by +the protocol that servers accept all possible byte size. The user of +various byte size is for efficiency in data transfer and servers may +implement only those byte size for which their data transfer is +efficient. It is however recommended that servers implement at least the +byte size of 8 bits. + + + + + [Page 6] + +The File Transfer Protocol July 8, 1972 + + + After the data transfer is completed, it is the server's +responsibility to close the data connection except when the user is +sender of data. The data connection shall be closed under any of the +following conditions: + + 1) server receives an abort command form user. + + 2) EOF in stream mode indicated by closing data connection. + + 3) the socket or byte size specification is changed. + + 4) any of the TELNET connections are closed. + + 5) an irrecoverable error condition. + + It should be noted that two simultaneous data connections +(for send and receive) may exist. It is a server option, however, to +close the data connection after each instance of file transfer. + +III.B Data Representation and Storage + + Data is transferred from a storage device in sending HOST to +a storage device in receiving HOST. Often it is necessary to perform +certain transformations on the data because data storage representations +in the two systems are different. For example, NVT-ASCII has different +data storage representations in different systems. PDP-10's generally +store NVT-ASCII as five 7-bit ASCII characters, left justified in a 36 +bit word. 360's store NVT-ASCII as 8-bit EBCDIC codes. Multics stores +NVT-ASCII as four 9-bit characters in a 36-bit word. It may desirable to +convert characters into the standard NVT-ASCII representation when +transmitting text between disimilar systems. The sending and receiving +site would have to perform the necessary transformations between the +standard representation and their internal representations. + + A different problem in representation arises when +transmitting binary data (not character codes) between HOST systems with +different word length. it is not always clear how the sender should send +data, and the receiver store it. For example, when transmitting 32-bit +bytes from a 32-bit word-length system to a 36-bit word-length system, +it may be desirable (for reasons of efficiency and usefulness) o store +the 32-bit bytes right justified in a 36-bit word in the latter system. +In any case, the user should have the option of specifying data +representation and transformation functions. It should be noted that FTP +provides for very limited data types reprentations. Transformations +desired beyond this limited capability should be performed by the user +directly or via the use of the Data Reconfiguration Service (DRS, RFC +#138, NIC #6715). Additional representation types may be defined later +if there is a demonstrable need. + + + + [Page 7] + +The File Transfer Protocol July 8, 1972 + + + Data representations are handled in FTP by a user specifying +a representation type. The type may also specify a fixed transfer byte +size. For example in ASCII and Print File representations, the transfer +byte size must be 8 bits. Only in the Image and Local Byte +representations the byte size specified by the BYTE command is to be +used. The following data representation types are currently defined in +FTP: + +1. ASCII The sender converts data form its internal + character representation to the standard + ARPANET ASCII form. The receiver converts + the data from the standard form to its own + internal form. The data is transferred in + the standard form. The transfer byte size + must be 8 bits. This type would be used for + transfer of text files. This is be default + type, and it is recommended that this type be + implemented by all. + +2. Image The sender transforms data from contiguous + bits to bytes for transfer. The receiver + transforms the bytes into bits, storing them + contiguously independent of the byte size + chosen for data transfer. Typical uses for + the Image type are transfer of executable + programs between like machines, and transfer + of binary (non-text) data. It is recommended + that this type be implemented by all for some + byte size preferably including the 8 bit byte + size. + +3. Local Byte This representation allows for efficient + storage, use, and retrieval of data. The + mann in which data is to be transformed + depends on the byte size for data transfer, + and the particular HOST being used. The + transformation scheme for different byte size + is to be well publicized b all server sites. + This transformation shall be invertible + (i.e., if a file is stored using a certain + transfer byte size, an identical file must be + retrievable using the same byte size and + representation type). It is the user's + responsibility to keep track of the + representation type and byte size used for + his transfer. Typical uses of the Local Byte + type are in efficient storage and retrieval + of files, and transfer of structured binary + + + + [Page 8] + +The File Transfer Protocol July 8, 1972 + + + data. This type may be identical to the + image type for byte size which are integral + multiples of or factors of the computer word + length- + +4. Print File- The server site will transform the ASCII + ASCII file in a form suitable for printing at the + server site. The byte size must be 8 bits. + The transformation may not be invertible. + This type is different from ASCII in that + TABs, FFs and other ASCII format effector + characters may be replaced by SPs, LFs, and + other substitute characters. The print file + conversions are to be well publicized by all + server sites. This type would be used when + the file is destined for an ASCII printer. + This type in some systems may be identical to + the ASCII type. It is recommended that this + type be implemented by all. + +5. EBCDIC Print The server site will transform the EBCDIC + File file into a form suitable for printing at the + server site. The byte size must be 8 bits. + the transformation may not be invertible. + This type would be used when the file is + destined for an EBCDIC printer. Only systems + which use EBCDIC for their internal character + representation need accept this type. + + It should be noted that a serving HOST need not accept all +representation types and/or byte size, but it must inform the user of +the fact by sending an appropriate reply. + +III.C File Structure and Transfer Modes + + The only file structures supported directly in FTP at the +present time are record structures. However, the use of record +structures is not mandatory. A user with no record structure in his file +should be able to store and retrieve his file at any HOST. A user +wishing to transmit a record structured file must send the appropriate +FTP 'STRU' command (the default assumption is no record structure). A +serving HOST need not accept record structures, but it must inform the +user of this fact by sending an appropriate reply. Any record structure +information in the data stream may subsequently be discarded by the +receiver. + + + + + + + [Page 9] + +The File Transfer Protocol July 8, 1972 + + + All data transfer must end with an EOF. The EOF is defined +by the data transfer mode. For files that have record structures, an EOR +is also defined by the transfer mode. Only the transfer modes and +representation type combinations that have EOR defined may be used for +transfer or files with record structures. Records may be of zero length +but they must be contained in file boundaries. The relationship between +files and records is heirarchical and an EOF implies an EOR. + + The following data transfer modes are defined in FTP: + +1. Stream The file is transmitted as a stream of bytes of the + specified byte size. The EOF is signalled by + closing the data connection. Any representation + type and byte size may be used in the stream mode + but record structures are possible only with the + ASCII representation type. The convention is that + the ASCII character CR (Carriage Return, Code 13.) + followed by LF (Line Feed, Code 10.) Indicates an + EOR in stream mode and ASCII representation type. + This is the default mode, and it is recommended + that this mode be implemented by all. + +2. Text The file is ASCII text transmitted as sequence of + 8-bit bytes in the ASCII representation type. + Record structures are allowed in this mode. The + EOR and EOF are defined by the presence of special + "TELNET-control" codes (most significant bit set + of one) in the data stream. The EOR code is 192 + (octal 300, hex C0). The EOF code os 193 (octal + 301, hex C1). The byte size for transfer is 8 + bits. + +3. Block The file is transmitted as a series of data blocks + preceded by one or more header bytes. The header + bytes contain a count field and descriptor code. + The count field indicates the total length of the + data block in bytes, thus marking the beginning of + the next data block (there are no filler bits). + The descriptor code defines last file block (EOF), + last record block (EOR), restart marker (see + section III.D), or suspect data (i.e. the data + being transferred is suspected of errors and is + not reliable). Record structures are allowed in + this mode, and any representation type or byte + size may be used. The header consists of integral + number of bytes whose length is greater than or + equal to 24 bits. Only the least significant 24 + bits (right-jusified) of header shall have + + + + [Page 10] + +The File Transfer Protocol July 8, 1972 + + + information, other must significant bits must be + zero. Of the 24 bits of header information, the + 16 low order bits shall represent byte count, and + the 8 high order bits shall represent descriptor + codes as shown below. + + Integral data bytes > 24 + + + | Must be Zero | Descriptor | Byte Count | + | 0 to 231 bits | 8 bits | 16 bits | + + The following descriptor codes are assigned: + + Code Meaning + 0 An ordinary block of data. + 1 End of data block is EOR. + 2 End of data block is EOF. + 3 Suspected errors in data block. + 4 Data block is a restart marker. + + The restart marker is imbedded in the data stream + as integral number of 8-bit bytes (representing + printable ASCII characters) right-justified in + integral number of data bytes greater than 8 bits. + For example if the byte size is 7 bits, the + restart marker byte would be one byte + right-justified per two 7-bit bytes as shown + below: + + Two 7-bit bytes + + | | Marker Char| + | | 8 bits | + + For byte size of 16 bits or more, two more + marker bytes shall be packed right-justified. The + end of the marker may be delimited by the + character SP (code 32.). If marker characters do + no exactly fit an integral byte, the unused + character slots should contain the ASCII character + SP (code 32.). For example, to transmit a six + character marker in a 36-bit byte size, the + following three 36.bit bytes would be sent: + + | Zero | Descriptor | | + | 12 bits | code=4 | Byte count=2 | + + + + + [Page 11] + +The File Transfer Protocol July 8, 1972 + + + | | Marker | Marker | Marker | Marker | + | | 8 bits | 8 bits | 8 bits | 8 bits | + + + | | Marker | Marker | SP | SP | + | | 8 bits | 8 bits | 8 bits | 8 bits | + +4 Hasp The file is transmitted as a sequence of 8-bit bytes + in the standard Hasp-compressed data format + (document to be issued by Bob Braden, UCLA). This + mode achieves considerable compression of data for + print files. Record structures are allowed in the + Hasp mode. + +III.D Error Recovery and Restart + + There is no provision for detecting bits lost or scrambled +in data transfer. This issue is perhaps handled best at the NCP level +where it benefits most users. However, a restart procedure is provided +to protect user from system failures (such as failure of either HOST, +FTP-process, or the IMP subnet). + + The restart procedure is defined only for the block mode of +data transfer. It requires the sender of data to insert a special marker +code in teh data stream with some marker information. The marker +information has meaning only to the sender, but must consist of +printable ASCII characters. The printable ASCII characters are defined +to be codes 33. through 126. (i.e., not including codes 0. through 31. +and the characters SP and DEL). The marker could represent a bit-count,a +record-count, or any other information by wich a system may identify a +data checkpoint. The receiver of data, if it implements the restart +procedure, would then mark the corresponding position of this marker in +the receiving system, and return this information to the user. + + In the event of a system failure, the user can restart the +data transfer by identifying the marker point with the FTP restart +procedure. The following examples Illustrate the use of the restart +procedure. + + 1. When server is the sender of data, the server-FTP process +inserts an appropriate marker block in the data stream at a convenient +data point. The user-FTP process receiving the data, marks the +coressponding data point in its file system and conveys the last known +sender and receiver marker information to the user. In the event of +system failure, the user or user-FTP process restarts the server at the + + + + + + + [Page 12] + +The File Transfer Protocol July 8, 1972 + + +last server marker by sending a restart command with the server's marker +code at its argument. The restart command is transmitted over the +TELNET connection and is immediately followed by the command (such as +store or retrieve) which was being executed when the system failure +occured. + + 2. When user is the sender of data, the user-FTP process +inserts the appropriate marker block in the data stream. The server-FTP +process receiving the data, marks the corresponding data point in its +file system. The server does not store this marker but conveys the last +known sender and receiver marker information to the user over the TELNET +connections by appropriate reply codes. The user or the user-FTP process +then restarts transfer in a manner identical to that described in the +first example. + +IV. FILE TRANSFER FUNCTIONS + + The TELNET connections on which FTP commands and replies are +transmitted, are initiated by the user-FTP process via an ICP to a +standard server socket. FTP commands are then transmitted from user to +server, and replies are transmitted from server to user. The user file +transfer functions invoive sending the FTP commands, interpreting the +replies received and transferring data over the data connection in the +specified manner. The server file transfer functions involve accepting +and interpreting FTP commands, sending replies, setting up the data +connection, and transferring data. + +IV.A FTP Commands + + FTP commands are ASCII terminated by the ASCII +character sequence CRLF (Carriage Return follow by Line Feed). The +command codes themselves are ASCII alpabetic characters terminated by +the ASCII character 'space' (code = 32.). For convenience, the command +codes are defined to be four (or less) ASCII alphanumeric characters +(including both upper and lower case alphabetic characters). The command +codes and the semantics of commands are described in this section, but +the detailed syntax of commands is specified in Section V.b, the reply +sequence are discussed in Section V.C, and scenarios illustrating the +use of commands are provided in Section V.D. + + FTP commands may be partitioned as those specifying +access-control identifiers, data transfer parameters, or FTP service +requests. + + + + + + + + + [Page 13] + +The File Transfer Protocol July 8, 1972 + + +IV.A.1 Access Control Commands + +The following commands specify access control identifiers + (command codes are shown in parentheses). + + User name (USER) - The argument field is an ASCII string + identifying the user. The user identification is that wich is + required by the server for access to its file system. This + command will normally be the first command transmitted by the + user after the TELNET connections are made (some servers may + require this). Additional identification information in the form + of pasword command may also be required by some servers. + + Password (PASS) - The argument field is an ASCII string + identifying the user's password. This command must be immediately + preceded by the user name command, and together it completes the + user's identifecation for access control. + +IV.A.2 Data Transfer Commands + + All data transfer parameters have default values, and the + commands specifying data transfer parameters are required only if + the default parameter values are to be changed. The default + value is teh last specified value, or if no value has been + specified, the standard default value specified here. This + implies that the server must "remember" the applicable default + values. The commands may be in any order except that they must + precede the FTP service request. The following commands specify + data transfer parameters. + + Byte size (BYTE) - The argument is an ASCII-represented decimal + integer (1 through 255), specifying the byte size for the data + connection for local byte and image representation types. The + default byte size is 8 bits. The byte size is always 8 bits in + the ASCII and Print file representation types. A server may + reject specific byte size/type combinations by sending an + appropriate reply. + + Data socket (SOCK) - The argument is a HOST-socket specification + for the data socket to be used in data connection. There may be + two data sockets, one from server to user and the other for user + to server data transfer. An odd socket number defines a send + socket and an even socket number defines a receive socket. The + default HOST is the user HOST to which TELNET connections are + made. The default data sockets are (U+4) and (U+5) where U is the + socket number used in the TELNET ICP and the TELNET connections + are on sockets (U+2) and (U+3). + + + + + [Page 14] + +The File Transfer Protocol July 8, 1972 + + + Representation Type (TYPE) - The argument is a single ASCII + character code specifying the representation types described in + section III.B. The following codes are assigned for type: + + A - ASCII + I - Image + L - Local Byte + P - Print file in ASCII + E - EBCDIC print file + + The default representation type is ASCII + + File Structure (STRU) - The argument is a single ASCII character + code specifying file structure described in section III.C. The + following codes are assigned for structure: + + F - File (no record structure) + R - Record structure + + The default structure is File (i.e., no records). + + Transfer Mode (MODE) - The argument is a single ASCII character + code specifying the data transfer modes described in Section + III.C. The following codes are assigned for transfer modes: + + S - Stream (bytes, close is EOF) + B - Block (Header with descriptor and count) + T - Text (TELNET control mode for EOR, EOF) + H - Hasp (specially formatted compressed data) + + The default transfer mode is Stream. + +IV.A.3 FTP Service Commands. + + The FTP service commands define the file transfer or the file + system function requested by the user. The argument of an FTP + service command will normally be a pathname. the syntax of + pathnames must conform to server site conventions (with standard + defaults applicable), except that ASCII characters must be used + (in conformance with the TELNET Protool). The suggested default + handling is to use the last specified device directory or file + name, or the standard default defined for local users. The + commands may be in any order except that a "rename from" command, + must be followed by a "rename to" command, and some servers may + require an "allocate" command before a "store" command. The data + when transferred in response to FTP service commands shall always + be over the data connection. The following commands specify FTP + service requests: + + + + [Page 15] + +The File Transfer Protocol July 8, 1972 + + + Retrieve (RETR) - This command achieves the transfer of a copy of + file specified in pathname, from server to user site. The status + and contents of a file at server site shall be unaffected. + + Store (STOR) - This command achieves the transfer of a copy of + file from user to server site. If file specified in pathname + exists at the server site, then its contents shall be replaced by + the contents of the file being transferred. A new file is created + at the server site if the file specified in pathname does not + already exist. + + Append (with create) (APPE) - This command achieves the transfer + of data from using to serving site. If file specified in pathname + exists at the server site, then the data transferred shall be + appended to that file, otherwise the file specified in pathname + shall be created at the server site. + + Rename from (RNFR) - This command specifies the file which is to + be renamed. This command must be immediately followed by a + "rename to" command specifying the new file pathname. + + Delete (DELE) - This command causes teh file specified in + pathname to be deleted at the server site. If an extra level of + protection is desired (such as the query, "Do you really wish to + delete?"), it should be provided by the user-FTP process. + + List (LIST) - This command causes a list to be sent from server + to user site. If pathname specifies a directory, the server + should transfer a list of files in the specified directory. If + pathname specifies a file then server should send current + information on the file. This command may be used to obtain the + contents of a file directory (the response should be sent in + ASCII type) or test the existence of a file and its current + status. + + Allocate (ALLO) - This command my be required by some servers to + reserve sufficient storage to accomodate the new file to be + transferred. The command field shall be a decimal integer + representing the number of bytes (of size specified by the byte + size command) of storage to be reserved for the file. This + command shall be followed by a store or append command. The ALLO + command should be treated as a NO-OP (no operation) by thuse + servers which do not require that the maximum size of the file be + declared beforehand. + + Restart (REST) - The argument field represents the server marker + at which file transfer is to be restarted. This command does not + cause file transfer but "spaces" over the file to the specified + + + + [Page 16] + +The File Transfer Protocol July 8, 1972 + + + data checkpoint. This command shall be immediately followed by + the appropriate FTP service command which shall cause file + transfer to resume. + + Status (STAT) - This command shall cause a status response to be + sent over the TELNET connection in form of a reply. The command + may have an argument field such as a pathname. if the argument + is a pathname, the command is analogous to the "list" command + except that data shall be transferred in ASCII on the TELNET + connection. If no argument is specified, the server should return + general status information about the server FTP process. This may + include service availability, the current settings for the + relevant FTP parameters (including default settings), and the + status of command execution and connections. + + Abort (ABOR) - This command indicates to the server to abort the + previous FTP service command and any associated transfer of data. + The abort command should be preceded by the TELNET SYNCH + condition (indicated by the combination of the DATA MARK and the + INS). No action is to be taken if the previous command has been + completed (including data transfer). The TELNET connections is + not to be closed by the server, but the data connection may be + closed. An appropriate reply should be sent by the server. + + Logout (BYE) - This command terminates a USER and if file + transfer is not in progress, closes the TELNET connection. If + file transfer is in progress, the connection will remain open for + result response and will then close. During the interim a new + USER command (and no other command) is acceptable. + + An unexpected close on TELNET connection will cause the server to + take the effective action of an abort (ABOR) and a logout (BYE). + +IV.B FTP Replies + + The server sends FTP replies to user over the TELNET +connections in response to FTP commands. The FTP replies constitute the +acknowledgement or completion code (including errors). The FTP-server +replies are formatted for human or program interpretation. The replies +consist of a leading three digit numeric code followed by a space +followed by a text explanation of the code. The numeric codes are +assigned by groups and for ease of interpretation by programs in a +manner consistent with other protocols such as the RJE protocol. The +three digits of the code are to be interpredet as follows: + + + + + + + + [Page 17] + +The File Transfer Protocol July 8, 1972 + + +a) The first digit specifies type of response as indicated below: + + 000 These replies are purely informative and constitute + neither a positive nor a negative acknowledgement. + + 1xx informative replies to status inrequiries. These constitute + a positive acknowledgment to the status command. + + 2xx Positive acknowledgment of previous command or other + successful action. + + 3xx Incomplete information. Activity cannot proceed without + further specification and input. + + 4xx Unsuccessful reply. The request is correctly specified + but the server is unsuccessful in corretly fulfilling + it. + + 5xx Incorrect or illegal command. The command or its + parameters were invalid or incomplete from a syntactic + viewpoint, or the command its inconsistent with a previous + command. The command in question has been completely + ignored. + + 6xx - 9xx Reserved for future expansion. + +b) The second digit specifies the general category to which + the response refers: + + x00-x29 General purpose replies, not assignable to other + categories. + + x30 Primary access. Informative replies to the "log-on" + attempt. + + x40 Secondary access. The primary server is commenting on its + ability to access a secondary service. + + x5x FTP results. + + x6x RJE resutls. + + x7x-x9x Reserved for future expansion. + + + + + + + + + [Page 18] + +The File Transfer Protocol July 8, 1972 + + +c) the final digit specifies a particular message type. Since the code +is designed for an automaton process to interpret, it is not necessary +for every variation of a reply to have a unique number. Only the basic +meaning of replies need have unique numbers. The text of a reply can +explain the specific reason for that reply to a human user. + + Each TELNET line (ended by CRLF) from the server is intended +to be a complete reply message. if it is necessary to continue the text +of a reply onto following lines, then those continuation replies contain +the special reply code of three spaces. It should be noted that text of +replies are intended for a human user. Only the reply codes and in some +instances the first line of text are intended for programs. + + The assigned reply codes relating to FTP are: + +000 General information message (site, time of day, etc.) +030 Server availibility information. +050 FTP commentary or user information. +100 System status reply. +150 File status reply. +151 Directory listing reply. +200 Last command received correctly. +201 An ABORT has terminated activity, as requested. +202 Abort request ignored, no activity in progress. +230 User is "logged in". may proceed. +231 User is "logged out". Service terminated. +232 Logout command noted, will complete when transfer done. +250 FTP file transfer started correctly. +251 FTP Restart-marker reply + Text is: MARK yyyy = mmmm + where yyyy is user's data stream marker (yours) + and mmmm is server's equivalent marker (mine) + (Note the spaces between the markers and '='). +252 FTP transfer completed correctly. +253 Rename completed. +254 Delete completed. +255 FTP server data socket reply + Text is: SOCK nnnn + where nnnn is decimal integer representing + the server socket for data connection. +300 Connection greeting message, awaiting input. +301 Current command incomplete (no CRLF for long time). +330 Enter password (may be sent with hide-your-input). +400 This service not implemented. +401 This service not accepting users now, goodbye. +430 Log-on time or tries exceeded, goodbye. +431 Log-on unsuccessful. User and/or password invalid. +432 User not valid for this service. + + + + [Page 19] + +The File Transfer Protocol July 8, 1972 + + +434 Log-out forced by operator action. Phone site. +435 Log-out forced by system problem. +436 Service shutting down, goodbye. +450 FTP: File not found. +451 FTP: File access denied to you. +452 FTP: File transfer incomplete, data connection closed. +453 FTP: File transfer incomplete, insufficient storage space. +500 Last command line completely unrecognized. +501 Syntax of last command in incorrect. +502 Last command incomplete, parameters missing. +503 Last command invalid (ignored), illegal parameter combination. +504 Last command invalid, action not possible at this time. +505 Last command conflicts illegally with previous command(s). +506 Requested action not implemented by the server. + +V. DECLARATIVE SPECIFICATIONS + +V.A. Connections + + The server-FTP process at the server site shall "listen" on +Socket 3, via its server-TELNET. The user or user-FTP process at the +user site shall initiate the full-duplex TELNET connections via its +user-TELNET performing the ARPANET standard initial connection protocol +(ICP) to server socket 3. The TELNET connections shall be closed by the +user site upon completion of use. + + The user site shall "listen" on the specified data socket or +sockets (a send and/or a receive socket). The server site shall initiate +the data connection using the specified data socket and byte size. The +direction of data connection and the data socket used shall be +determined by the FTP service command. The server shall send a reply to +the user indicating the server data socket so that the user may ensure +the security of data transfer. This can be done at any time prior to the +first transfer of data over a data connection. + + The data connection shall be closed by the server site under +the conditions described is Section III.A. The server should in general +send a reply before closing the data connection to avoid problems at the +user end. + +V.B. Commands + + The commands are ASCII character strings transmitted over +the TELNET connections as described in section IV.A. The command +functions and semantics are described in sections IV.A.1, IV.A.2, +IV.A,3, and IV.A.4. The command syntax is specified here. + + + + + + [Page 20] + +The File Transfer Protocol July 8, 1972 + + + The commands begin with a command code followed by an +argument field. The command codes are four of less ASCII alphabetic +characters. Upper and lower case alphabetic characters are to be treated +identically. Thus any of the following may represent the retrieve +command: + + RETR Retr retr ReTr rETr + +The command codes and the argument fields are separated by one or more +spaces. + + The argument field consists of a variable length ASCII +character string ending with the character sequence CRLF (Carriage +Return immediately followed by Line Feed). In the following section on +syntax it should be stressed that all characters in the argument field +are ASCII characters. Thus a decimal integer shall mean an ASCII +represented decimal integer. + + The following are all the currently defined FTP commands: + + USER <user name> CRLF + PASS <password> CRLF + BYTE <byte size> CRLF + SOCK <HOST-socket> CRLF + TYPE <type code> CRLF + STRU <structure code> CRLF + MODE <mode code> CRLF + RETR <pathname> CRLF + STOR <pathname> CRLF + APPE <pathname> CRLF + RNFR <pathname> CRLF + RNTO <pathname> CRLF + DELE <pathname> CRLF + LIST <pathname> CRLF + ALLO <decimal integer> CRLF + REST <marker> CRLF + STAT <pathname> CRLF + ABOR <empty> CRLF + Bye <empty> CRLF + + The syntax of the above argument fields (using BNF notation +where aplicable) is: + + <username> ::= <string> + <password> ::= <string> + <string> ::= <empty> | <char> | <char><string> + <char> ::= any of the 128 ASCII characters except CR and LF. + <marker> ::= <pr string> + + + + [Page 21] + +The File Transfer Protocol July 8, 1972 + + + <pr string> ::= <empty> | <pr char> | <pr char><pr string> + <pr char> ::= any ASCII code 33 through 126. + <byte size> ::= any decimal integer 1 through 255. + <HOST-socket> ::= <socket> | <HOST number>,<socket> + <HOST number> ::= a decimal integer specifying an ARPANET HOST. + <socket> ::= decimal integer between o and (2**32)-1 + <type code> ::= A|I|L|P|E + <structure code> ::= F|R + <mode code> ::= S|B|T|H + <pathname> ::= <string> + <decimal integer> ::= <digit> | <digit><decimal integer> + <digit> ::= 0|1|2|3|4|5|6|7|8|9| + <empty> ::= the null string (specifies use of default). + +V.C Sequencing of Commands and Replies + + The communication between the user and server is intended to +be an alternating dialogue. As such, the user issues an FTP +command and the server responds with a prompt primary reply. The +user should wait for this initial primary success of failure +response before sending further commands. + + A second type of reply is sent asynchronously with respect +to user commands. These replies may for example report on the +progress or completion of file transfer and as such are secondary +replies to file transfer commands. + + The third class of replies are informational and spontaneous +replies which may arrive at any time. These replies are listed +below as spontaneous. + + COMMAND-REPLY CORRESPONDENCE TABLE + +COMMAND SUCCESS FAIL + +USER 230,330 430-432,500-505 +PASS 230 430-432,500-505 +BYE 231,232 430-432,500-505 +BYTE 200 500-506 +SOCK 200 500-506 +TYPE 200 500-506 +MODE 200 500-506 +RETR 250 450,451,500-506 + Secondary Reply 252 452 +STOR 250 451,451,500-506 + Secondary Reply 252 452,453 +APPE 250 451,451,500-506 + Secondary Reply 252 452,453 + + + + [Page 22] + +The File Transfer Protocol July 8, 1972 + + +RNFR 200 450,451,500-506 +RNTO 253 450,451,500-505 +DELE 254 450,451,500-506 +LIST 250 450,453,500-506 + Secondary Reply 252 452 +ALLO 200 500-506 +STAT 100,150,151 450,451,500-506 +REST 200 500-506 +ABOR 201,202 500-505 + +Spontaneous 0xx,300,301 400,401,434-436 +Replies 251,255 + +V.D. Tyical FTP Scenarious + +1. TIP User wanting o transfer file from FOST X to local printer: + + a) TIP user opens TELNET connections by ICP to HOST X, socket 3. + + b) The following commands and replies are exchanged: + TIP HOST X + + USER username CRLF --------> + <------- 330 Enter Password CRLF + + PASS password CRLF --------> + <------- 230 User logged in CRLF + + SOCK 65538 CRLF --------> + <------- 200 Command received OK CRLF + + RETR this.file CRLF --------> + <------- 255 SOCK 5533 CRLF + + (HOST X initiates data connection to + TIP socket 65538, i.e., PORT 1 receive) + + <------- 250 File transfer started + + BYE CRLF ------_-> + <------- 252 File transfer completed + + c) HOST X closes the TELNET and data connections. + + Note: The TIP user should be in line mode and can thus use + local TIP editing such as character delete. + + + + + + [Page 23] + +The File Transfer Protocol July 8, 1972 + + +2. User at Host U wanting to transfer files to/from HOST S: + + In general the user would communicate to the server via a + mediating user-FTP process. The following may be a typical + scenario. The user-FTP prompts are shown in parenthesis, + '---->' represents commands from HOST U to HOST S, and + '<----' represents replies from HOST S to HOST U. + +Local Commands by User Action Involved + +ftp (host) multics CR ICP to HOST S, socket 3, + establishing TELNET connections. +username Doe CR USER DoeCRLF ----> + <---- 330 passwordCRLF +password mumble CR PASS mumbleCRLF ----> + <---- 230 Doe logged in.CRLF +retrieve (local type ASCIICR +(local pathname) test 1 CR USER-FTP open local file in ASCII. +(for. pathname) test.pl1CR RETR test.pl1 CRLF ----> + <---- 255 SOCK 1233CRLF + Server makes data connection to (U+4). + <---- 250 File transfer startsCRLF + <---- 252 File transfer completeCRLF +type imageCR TYPE |CRLF ----> + <---- 200 Command OKCRLF +byte 36CR BYTE 36CRLF ----> + <---- 200 Command OKCRLF +store (local type) ImageCR +(local pathname) file dumpCR User-FTP opens local file in Image. +(for. pathname) >udd>cn>fdCR STOR >udd>cn>fdCRLF ----> + <---- 451 Access deniedCRLF +terminate BYECRLF + <---- 231 Doe logged outCRLF + Server closes all connections. + + + + + + + + + + + + + + + + + + [Page 24] + +The File Transfer Protocol July 8, 1972 + + +ACKNOWLEDGEMENTS + + The work on file transfer protocol has involved many people. +This document reports the work of a group rather than the author +alone. The author gratefully acknowledges the conributions of +the following: + + Bob Braden UCLA-CCCN + Arvola Chan MIT-MAC + Bill Crowther BBN-TIP + Eric Harslem RAND + John Heafner RAND + Chuck Holland UCSD + Alex McKenzie BBN (NET) + Bob Metcalfe XPARC + Jon Postel UCLA + Neal Ryan MIT-MAC + Bob Sundberg HARVARD + Ray Tomlinson BBN (TENEX) + Dick Watson SRI-ARC + Jim White SRI-ARC + Richard Winter CCA + + + [ This RFC was put into machine readable form for entry ] + [ into the online RFC archives by Gottfried Janik 9/97 ] + + + + + + + + + + + + + + + + + + + + + + + + + + [Page 25] + |