Network Working Group 17 November 1971 Request for Comments #265 Abbay Bhushan, MIT NIC 781 Bob Braden, UCLA Categories D.4, D.5, and D.7 Will Crowther, BBN
THE FILE TRANSFER PROTOCOL
This Paper is a revision of RF 172, Mic 6794. The changes
CHANGES TO RFC 172
The file transfer protocol (FTP) is a userlevel procotocol for
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 control associated with it The
FTP does not restrict the nature of information in files. For
FTP is readily extendable, 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
It is strongly recommended that default options be provided in
FTP uses the Data Transfer Protocol (described in RFC 264)
for transferring data and/or control transaction. Both data
and control transactions are communicated over the same
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 communicated via control transactions. A file may be transferred as one or more data transactions. The protocol neither specifies nor impose 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 by a file separator (as defined in data transfer protocol). In the special case of indefinite bit-stream transfer mode (Type B0), the end of file is indicated by closing connection. In particular, a serving or usin 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. The user side initiates the connections as well as the request. The server side "listens" and complies with the request.
The first information (i.e., not descriptor) byte or control
transactions indicates the control function. This byte is
referred to as "opcode". A standard set of opcodes are
defined below. The operations are discussed in Section 2B.2.
Op Code Operation Hex Octal 00 000 Set data type identifier 01 001 Retrieve Request 02 002 Create request (write file; error ir file already exits) 03 003 Store request (write file; replace if file already exists) 04 004 Append request (add to existing file; error if file does not exist) 05 005 Append_with_create request (add to file; create if file does not exist) 06 006 Delete request (delete file) 07 007 Rename_from request (change file name) 08 010 Rename_to request (the new file name) 09 011 List request (list information) 0A 012 Username identifier (for access control) 0B 013 Password identifier (for access control) 0C 014 Error of unsuccessful terminate 0D 015 Acknowledge or successful terminate 0E 016 through through Reserved for standard assignment 4F 077 5A 100 through through Assigned for experimental use FF 377
The 'set data type' control transactions indentifies the structure of data (data type and byte size) is succeeding data transactions. The 'set data type' 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. Set 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 data type error.) These descriptors are provided only for convenience, and it es 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)(*)whose interpretation is left to a higher level process, or the user.
The following data type codes are currently assigned. Where a byte size is not implicit in data type, it may be provided by the second byte.
Code Implicit Data Type Hex Octal Byte Size 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 assignemt 4f 077 5A 100 through through Assigned for experimental use FF 377
Retrieve, create, append, append_with_create, delete, rename_from, and rename_to requests must contain a pathname specifying a file, following the opcode in the information field. In the list request a pathname may or may not follow the opcode. If present, the pathname may specify either a file or a directory.
A file 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 (7-bit ASCII right justified in 8-bit) field with most signifcant bit as zero) shall be used.
The store request has a 4-byte (32 bits) 'allocate size' field followed by a pathname specifying a file. 'Allocate size' indicates the number of bits of storage to be allocated to the file. An allocate size of zero indicates that server should use his default.
Create request causes a file to be created at the serving host as specified in pathname, A copy of the file is transferred from the using to the serving host. If the file specified in pathname already exists at the serving host, an error terminate should be sent by the server.
Store request achieves the transfer of copy of file 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. If the specified file does not exist at serving host, an error terminate should be sent by the server.
Append with create request achieves the transfer of data from using to serving host. If file specified is pathname exists at serving host, then the transferred data is appended to that file, otherwise the file specified in pathname is created at the 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 request 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 option in the using system. Such queries should not be transmitted over network connections.
List request causes a list to be sent from the serving to using host. If there is no pathname of if pathname is a directory, the server should send a file directory list. If the pathname specifies a file then server should send current information on the file.
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 will normally be sent at the start of connetion for access control.
The error transactions may have an error code indicated by the second information byte. Transmission of an ASCII error message in subsequent bytes is permitted with all error codes, except that with Hex '0A' error code, ASCII text is required. The errors here relate to file transfer functions only. Data synchronization and related errors in data transfer are to be handled at the DTP level. The following error codes are currently defined:
Error Code (2nd descriptor byte) Meaning Hex Octal 00 000 Error condition indicated by computer system (external to protocol) 01 001 Name syntay error 02 002 Access control violation 03 003 Abort (by user) 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 Incorrect or missing identifier 0A 012 Error described in text message (ASCII characters follow code) 0B 013 File already exists (in create request)
At present, no completion codes are defined for acknowledge, It is assumed that acknowledge refers to the current request being fulfilled.
Retrieve / List requests
-----------------------------> User < File -- Data> Server <----------------------------- End of file indication <-----------------------------
Store, create, append, and append_with_create 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.
Create / Store / Append / Append_with_create requests
-----------------------------> User <File --- Data> Server -----------------------------> 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_ro request -----------------------------> Acknowledge <-----------------------------
The delete request requires the server to acknowledge it, as shown below.
User Delete Server -----------------------------> Acknowledge <-----------------------------
Error transactions my be sent by either host at any time, and these terminate the current request fulfillment sequence.
CLS may also be used by either user or server, to abort a transation 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.
--------------------------------- (*) Socket 1 has been assigned to logger, socket 3 seems a reasonable choice for File Transfer.
RFC 165, or any subsequent standard applicable in initial connection to loggers.
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Gottfried Janik 7/97 ]