RFC 265
The File Transfer Protocol
THE FILE TRANSFER PROTOCOL 🎀
Okay bestie, this RFC is from 17 November 1971 🍓 and it's the Network Working Group's Request for Comments #265, aka NIC 781. It's filed under Categories D.4, D.5, and D.7, and it's a revision of RFC 172 (Mic 6794), which means it obsoletes 172 🦋. The author squad is Abbay Bhushan (MIT), Bob Braden (UCLA), Will Crowther (BBN), Eric Narslem (Rand), John Heafner (Rand), Alex McKenzie (BBH), John Melvin (SRI), Bob Sundberg (Harvard), Dick Watson (SRI), and Jim White (UOSB) 👑 Nothing in the title block says it updates anything else.
CHANGES TO RFC 172 ✨
Here's what's new since RFC 172 💅
- Two new file transfer requests have been added. These are
- The op code assignments in control transactions have been changed to include the above requests.
- Two new error codes indicating 'incorrect or missing identifier' and 'file already exists' have been added. New error code assignments reflect this change.
- Editorial changes to clarify specifications.
The protocol is then restated below so you don't have to flip back to 172 🫶
I. INTRODUCTION 🦋
So the file transfer protocol (FTP) is a userlevel protocol for moving files between host computers (including terminal IMPs) on the ARPA computer network (ARPANET) 🌐 Its main job is to help you transfer files between hosts and let you use the storage and file handling stuff on remote hosts without it being a whole thing. FTP uses the Data Transfer Protocol from RFC 264 to actually move the data, and this paper assumes you already know RFC 264 🧚
The goals are pretty iconic honestly 💜 FTP wants to promote sharing of files (computer programs and/or data), encourage implicit use of computers (meaning without explicit login), and shield you from the differences between file and storage systems on different hosts. It gets there by specifying a standard file transfer socket and initial connection protocol for implicit use, plus standard conventions for file transfer and related operations. Main character energy 👑
II. DISCUSSION 💅
A file is treated here as an ordered set of arbitrary length, made of computer data (programs included) 📁 Files get uniquely identified in a system by their pathnames. Loosely speaking, a pathname is the data string a network user has to type into the file system to find a file, and it usually has device and/or directory names plus a file name 🌸 FTP gives standard file system commands but does not give a standard naming convention yet, so each user has to follow the naming convention of whatever file system they're trying to use. FTP might get standard pathname structures later, so stay tuned 🔥
Files may or may not have access control attached to them. Access controls say which users get which privileges, and without them files can't be protected from accidental or unauthorized use 🙈 Protection and selective access are up to the serving file system, since that's its prerogative. FTP does provide identifier and password mechanisms for swapping access control information. It should be noted though that for file sharing to work, a user has to be allowed (subject to access controls) to get at files they didn't create themselves. Sharing is caring 🫶
FTP doesn't restrict what kind of information lives in files. A file could hold ASCII text, binary data, a computer program, or any other information at all ✨ FTP has a way to indicate data structure (type and byte size) so that parsing, interpretation, and storage are easier 🎀
For implicit usage, a serving file transfer process may be a disowned "demon" process that "listens" on an agreed-upon socket and follows the standard initial connection protocol to set up a full-duplex connection 🧚 It should be noted that FTP may also be used directly by logging into a remote host and arranging for file transfer over specific sockets 💖
FTP is readily extendable, since extra commands and data types can be defined by anyone who agrees to implement them 🌈 Implementing only a subset of commands is specifically permitted, and an initial subset for implementation is recommended. (*) The protocol may also be extended to enable remote execution of programs, but no standard procedure is suggested for that 👀
For transferring data, FTP uses the data transfer protocol specified in RFC 264. The data transfer protocol doesn't say how FTP should use it, so implementations may differ from site to site 🍓 Hosts that don't want to separate data transfer and file transfer functions should take particular care to conform to the data transfer protocol specifications of RFC 264 🔥
Here's a lowkey important bit: FTP doesn't need you to know the transfer modes the data transfer protocol uses. BUT, since file transfer needs more than one control transaction over the same connection, hosts have to be able to send control transactions in either 'transparent block' (type B9) or 'descriptor and counts' (type BA) modes. The indefinite bit stream mode (type BS) isn't suitable, because it limits transfer to single transactions 😭
Using data transfer aborts (type B6) is neither required nor defined in FTP. Instead FTP has its own error terminate, which can be used to abort a file transfer request 💅 FTP also doesn't define the structure of files, and there are no conventions for using group, record, and unit separators. (*) A file separator, though, does indicate the end of a file 🦋
It's strongly recommended that implementations provide default options to make the file transfer service easier to use 🌸 For example, the main file directory on disk, a pool directory, the user directory, or the directory last accessed could all serve as standard pathname defaults. Defaults are convenient because you don't have to type the complete pathname every single time you use the service. FTP doesn't specify any standard default procedures, though 💜
(*) This initial subset covers the control functions needed for basic file transfer and "mail" operations, plus some elementary file manipulation operations. There's no attempt to provide data management or complete file management capability 🧚
(*) It's possible that we may, at a later date, assign meaning to these information separators within FTP 👑
III. SPECIFICATIONS 👑
1. Data Transfer
FTP uses the Data Transfer Protocol (described in RFC 264) for transferring data and/or control transactions. Both data and control transactions get communicated over the same connection 🌈
2. Data Transactions
Data transactions are the data contained in a file 📁 There's no data type or byte size information in data transactions. The structure of data is 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 a file. A serving host may still impose such limitations, though 💖 The end of a file may be indicated by a file separator (as defined in the data transfer protocol). In the special case of indefinite bit-stream transfer mode (Type B0), the end of file is indicated by closing the connection ✨
Here's the big warning, so pay attention 🙈 A serving or using host should not send the ETX, or any other end of file character, unless that character is part of the data in the file (i.e., not provided by the system).
3. Control Transactions
Control transactions can be typified as requests, identifiers, and terminates 🦋 A request fulfillment sequence starts with a request and ends with receipt of data (followed by end-of-File) or a terminate. The user side initiates the connection as well as the request. The server side "listens" and complies with the request 🧚
3A. Op Codes
The first information byte (i.e., not descriptor) of control transactions indicates the control function. This byte is called the "opcode". A standard set of opcodes is defined below, and the operations are discussed in Section 2B.2 🌸
Implementing a workable 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 🌈
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(*) A workable subset is any request, plus terminates. Identifiers may be required in addition for using "protected" file systems 💅
3B. Syntax and Semantics
3B.1 Data Types
The 'set data type' control transaction identifies the structure of data (data type and byte size) in the 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 needs to be sent only when the structure of data changes from the preceding transaction 🦋
Now, a number of data types are defined, but specific implementations may handle only limited data types or completely ignore the data type and byte size descriptors 🙈 Even if a host process doesn't "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) (*) 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 the data type, it may be provided by the second byte 🌈
(*) 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. Okay bestie, this table is the full menu of data types, so let's look at it together 🎀
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 3773B.2 Requests and Identifiers ✨
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 one is 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 significant 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. 💅
Retrieve request achieves the transfer of a copy of the file specified in pathname, from serving to using host. The status and contents of the file in the serving host SHOULD be unaffected. 🦋
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 a copy of a file from using to serving host. If the file specified in pathname exists on the serving host, 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 the file specified in pathname, at the serving host. If the specified file does not exist at the 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 the file specified in pathname exists at the 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 the 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 or if the pathname is a directory, the server SHOULD send a file directory list. If the pathname specifies a file, then the 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 the connection for access control. 🔑
3B.3 Error and Acknowledge Terminates 💥
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. 🫶
4. Order of transactions ✨
4A. A certain order of transactions MUST be maintained in fulfilling file transfer requests. The exact sequence in which transactions occur depends on the type of request, as described in 4B. The fulfillment of a request MAY be aborted anytime by either host, as explained in section 4C. 🎢
4B. Identifier transactions (set data type, username, and password) MAY be sent by the user at any time. The usual order would be a username transaction followed by a password transaction at the start of the connection. No acknowledge is REQUIRED, or permitted. The identifiers are to be used for default handling and access control. 🔐
Retrieve and list requests cause the transfer of a file from server to user. After a complete file has been transferred, the server SHOULD indicate end-of-file (by sending CLS or file separator) to complete the request fulfillment sequence, as shown below. 📤
Retrieve / List requests
----------------------------->
User < File -- Data> Server
<-----------------------------
End of file indication
<-----------------------------Store, create, append, and append_with_create requests cause the transfer of a 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
<-----------------------------A 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 MAY be sent by either host at any time, and these terminate the current request fulfillment sequence. 🚫
4C. Aborts. Either host MAY abort a request fulfillment sequence at any time by sending an error terminate, or by closing the connection (NCP to transmit a CCLS for the connection). CLS is a more drastic type of abort and SHALL be used when there is a catastrophic failure, or when an abort is desired in the middle of a long transaction. The abort indicates to the receiving host that the sender of the abort wishes to terminate the request fulfillment and is now ready to initiate or fulfill new requests. When CLS is used to abort, the using host will be responsible for reopening the connection. The file transfer abort described here is different from the data transfer abort, which is sent only by the sender of data. The use of the data transfer abort is not defined in this protocol. 🛑
5. Initial Connection, CLS, and Access Control ✨
5A. Socket 3 is the standard preassigned socket number on which the cooperating file transfer process at the serving host SHOULD "listen". () The connection establishment will be in accordance with the standard initial connection protocol, () establishing a full-duplex connection. 🔌
5B. The connection will be broken by trading a CLS between the NCP's for each of the two connections. Normally, the user will initiate CLS. 👋
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 a transaction, the current request fulfillment sequence will be aborted. The using host will then reopen the connection. 💫
5C. It is RECOMMENDED that identifier (user name and password) transactions be sent by user to server, at the start, as this would facilitate default handling and access control for the entire duration of the connection. Some service sites MAY require the identifier transactions. The identifier transactions do not require or permit an acknowledge, and the user can proceed directly with requests. If the identifier information is incorrect or not received, the server MAY send an error transaction indicating access control violation upon subsequent requests. 🎀
(*) 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 ] 🌈
📦 where this page comes from
- ietf: rfc265 1971-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms