Network Working Group 23 June 1971 Request for Comments #172 Abhay Bhushan, MIT NIC 6794 Bob Braden, UCLA Categories: D.4, D.5, and D.7 Will Crowther, BBN Updates: 114 Eric Harslem, Rand Obsolete: None John Heafner, Rand
THE FILE TRANSFER PROTOCOL
[Page 1]
The file transfer protocol (FTP) is a user-level protocol for file
The objectives of FTP are to promote sharing of files (computer
A file is considered here to be an ordered set of arbitrary
A file may or may not have access controls associated with it.
FTP does not restrict the nature of information in the file. For
[Page 2]
FTP is readily extensible, in that additional commands and data
For transferring data, FTP uses the data transfer protocol
It should be noted, that FTP specifications do not require
The use of data transfer aborts (type B6) is neither required, nor
FTP uses the data transfer protocol described in RFC 171, for transferring data and/or control transaction. Both data and control transactions are communicated over the same connection.
[Page 3]
Data transactions represent the data contained in a file. There is no data type or byte size information contained in data transactions. The structure of data is instead communicated via control transactions. A file may be transferred as one or more data transactions. The protocol neither specifies nor imposes any limitations on the structure (record, group, etc) or length of file. Such limitations may however be imposed by a serving host. The end of a file may be indicated either by a file separator (as defined in data transfer protocol), or by closing connection (in type B0). In particular a serving or using host should not send the ETX, or other end of file character, unless such a character is part of the data in file (i.e., not provided by system).
The control transactions may be typified as requests, identifiers, and terminates. A request fulfillment sequence begins with a request and ends with receipt of data (followed by End-of-File) or a terminate.
Control transactions are distinguished by their first byte referred
as op code. A standard set of opcodes is defined below.
Implementation of a workable[4] subset of opcodes is specifically
permitted. Additional standard opcodes may be assigned later. Opcodes
hex 5A (octal 100) through hex FF (octal 377) are for experimental
use.
[Page 4]
Op Code Operation Hex Octal 00 000 Change data type identifier 01 001 Retrieve Request 02 002 Store request (replaced if file already exists) 03 003 Delete request 04 004 Rename_from request 05 005 Rename_to request 06 006 List_file_directory request 07 007 Username identifier 08 010 Password identifier 09 011 Error or unsuccessful terminate 04 012 Acknowledge or successful terminate 0B 013 Append request (add to existing file) 0C 014 through through Reserved for standard assignment 4F 077 5A 100 through through Reserved for experimental use FF 377
[Page 5]
The 'change data type' control transactions identifies the structure of data (data type and byte size) in succeeding data transactions. This transaction shall contain two more bytes in addition to the opcode byte. The first of these bytes shall convey a data type or code information and the second byte may convey the data byte size, where applicable. This information may be used to define the manner in which data is to be parsed, interpreted, reconfigured or stored. Change data type need be sent only when structure of data is changed from the preceding.
Although, a number of data types are defined, specific
implementations may handle only limited data types or completely
ignore the data type and byte size descriptors. Even if a host
process does not "recognize" a data type, it must accept data (i.e.,
there is no such thing as a data type error.) These descriptors are
provided only for convenience, and it is not essential that they be
used. The standard default is to assume nothing about the information
and treat it as a bit stream (binary data, byte size 1)[5] whose
interpretation is left to a higher level process, or the user.
_________________________
* It is, however, possible that this bit stream is treated like ASCII characters in specific instances such as transmitting a file to a line printer.
[Page 6]
Hex Octal 00 000 1 Bit stream (standard default) 01 001 none Binary data bytes 02 002 8 Network ASCII characters 03 003 8 EBCDIC characters 04 004 36 DEC-packed ASCII (five 7-bit characters, 36th bit 1 or 0) 05 005 8 Decimal numbers, net. ASCII 06 006 8 Octal numbers, net. ASCII 07 007 8 Hexadecimal numbers, net. ASCII 08 010 through through Reserved for standard assignment 4F 077 5A 100 through through Reserved for experimental use FF 377
Retrieve, delete, name_from, rename_t, and append requests contain a pathname, following the op code, in the information field. A pathname may also follow the opcode in list_file_directory request.
A pathname must uniquely identify a file in the serving host. The syntax of pathnames and identifying information shall conform to serving host conventions, except that standard network ASCII (as defined in the TELNET protocol) shall be used.
[Page 7]
Retrieve request achieves the transfer of a copy of file specified in pathname, from serving to using host. The status and contents of file in serving host should be unaffected.
Store request achieves the transfer of a copy of file specified in pathname, from using to serving host. If file specified in pathname exists on serving hosts, then its contents shall be replaced by the contents of the file being transferred. A new file is created at the serving host, if the file specified in pathname does not exist.
Append request achieves the transfer of data from using to serving host. The transferred data is appended to file specified in pathname, at serving host.
Rename-from and rename-to requests cause the name of the file specified in pathname of rename_from to be changed to the name specified in pathname of rename_to. A rename_from must always be followed by a rename_to request.
Delete request causes file specified in pathname to be deleted from the serving host. If an extra level of protection is desired such as the query "Do you really wish to delete this file?", it is to be a local implementation in the using system. Such queries should not be transmitted over network connections.
Username and password identifiers contain the respective identifying information. Normally, the information will be supplied by the user of the file transfer service. These identifiers are normally sent at the start of connection.
The error transactions may have an error code indicated by the second descriptor byte. Transmission of an error message in text is also permitted. The following error codes are defined.
[Page 8]
Error Code (2nd descriptor byte) Meaning Hex Octal 00 000 Error condition indicated by computer system (external to protocol) 01 001 Name syntax error 02 003 Access control violation 03 003 Abort 04 004 Allocate size too big 05 005 Allocate size overflow 06 006 Improper order for transactions 07 007 Opcode not implemented 08 010 File search failed 09 011 Error described in text message (ASCII characters follow code)
[Page 9]
Read / List_file_directory request
-------------------------------------> User <File -- data> Server <------------------------------------- End of file indication <-------------------------------------
Store and append requests cause the transfer of file from user to server. After a complete file has been transferred, the user should send an end-of-file indication. The receipt of the file must be acknowledged by the server, as shown below.
User Store / Append request Server -------------------------------------> <File -- data> -------------------------------------> End of file indication -------------------------------------> Acknowledge <-------------------------------------
Rename_from request must be followed by a rename_to request. The request must be acknowledged as shown below.
User Rename_from request Server -------------------------------------> Rename_to request -------------------------------------> Acknowledge <-------------------------------------
The delete request requires the server to acknowledge it, as shown below.
User Delete Server -------------------------------------> Acknowledge <-------------------------------------
Error transactions may be sent by either host at any time, and these terminate the current request fulfillment sequence.
[Page 10]
CLS may also be used by either user or server, to abort a transaction in the middle. If CLS is received in the middle of transaction, the current request fulfillment sequence will be aborted. The using host will then reopen connection.
[Page 11]
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Glenn Forbes Fleming Larratt 5/97 ]
[Page 12]