RFC 354

File Transfer Protocol

📅 published July 1972, from ietf

THE FILE TRANSFER PROTOCOL 🎀

RFC 354 💖 (NIC 10596), from the Network Working Group, written by Abhay Bhushan of MIT-MAC on July 8, 1972. It's filed under Categories D.4, D.5, D.7, and it obsoletes RFC 264 and RFC 265 🦋. Think of it as the glow-up that replaces those two earlier drafts ✨.

I. INTRODUCTION ✨

okay so the File Transfer Protocol (FTP) is the protocol for moving files between HOSTs (including terminal IMPs) on the ARPA Computer Network (ARPANET) 🌸. Its main job is to transfer files efficiently and reliably between HOSTs, and to let you conveniently use remote file storage 💅.

The goals are slay and also very practical 👑:

promote sharing of files (computer programs and/or data)
encourage indirect or implicit use of remote computers (via programs)
shield a user from the differences between file storage systems on different HOSTs
transfer data reliably and efficiently

FTP can be used directly by a person at a terminal, but it was designed mainly for programs to use 🤖🧚.

The whole spec is trying to serve everyone: maxi-HOSTs, mini-HOSTs, TIPs, and the Datacomputer 🌈. The vibe is simple, elegant, and easy to implement, no cap 🫶.

This paper assumes you already know these protocols:

The HOST-HOST Protocol (NIC #8246)
The initial Connection Protocol (NIC #7101)
The TELNET Protocol (NWG/RFC #318, NIC #9348)

II. DISCUSSION 💜

In this section we go over the terminology and the FTP model. The terms defined here are only the ones that have special meaning in FTP, so don't stress if a word means something else in regular life 🙈.

II.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, meaning the most significant bit is zero.

access controls 🔐: these define users' access privileges to use a system and the files in it. They're needed 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 transferring data. The data connection is opened with this byte size. The data connection byte size is not necessarily the byte size the data gets stored in on a system, and it may not be related to how the data is structured.

data connection 🛣️: a simplex connection that data is transferred over, in a specified byte size, mode, and type. The data can be part of a file, a whole file, or a bunch of files. The data connection can go either direction (server-to-user or user-to-server).

data socket 🔌: the socket where a User-FTP process "listens" for a data connection.

EOF 🏁: the end-of-file condition that marks the end of a file being transferred.

EOR 📦: the end-of-record condition that marks the end of a record being transferred.

error recovery 🩹: a procedure that lets a user recover from certain errors, like a failure of either the host system or the transfer process. In FTP, error recovery may involve restarting a file transfer at a given checkpoint.

FTP commands 📨: a set of commands that make up the control information flowing from the user-FTP to the server-FTP process.

file 🗂️: an ordered set of computer data (including programs) of arbitrary length, uniquely identified by a pathname.

mode 🎛️: the mode the data gets transferred in over 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. It's a concept for a standard network file system with standard commands and pathname conventions. FTP only partially embraces the NVFS concept at this time.

pathname 🛤️: the character string a user has to type into a file system to identify a file. It normally contains device and/or directory names, plus a file name specification. FTP does not yet specify a standard pathname convention, so each user has to follow the file naming conventions of whichever file systems they want to use.

record 🧱: a sequential file can be structured as a number of contiguous parts called records. FTP supports record structures, but they aren't mandatory.

reply 💬: an acknowledgment (positive or negative) sent from the server to the user over the TELNET connections, in response to FTP commands. A reply is generally a completion code (including error codes) followed by an ASCII text string. The codes are for programs to use, and the text is for humans 🙋.

server-FTP process 🏠: a process or set of processes that does the file transfer work in cooperation with a user-FTP process. The server-FTP process must interpret and respond to user commands and initiate the data connection 👑.

server site 🖧: a HOST site that has a server-FTP process.

server-TELNET 📡: a TELNET process that listens on a specified socket for an ICP initiated by a user-TELNET, and performs in accordance with the ARPANET TELNET Protocol.

TELNET connections 🔗: the full-duplex communication path between a user-TELNET and a server-TELNET. They're set up through the standard ARPANET initial Connection Protocol (ICP).

type 🎨: the data representation type used for transferring and storing data. Type implies certain transformations between the time data is stored and the time it's transferred. The representation types defined in FTP are described in Section III.B.

user 🙋‍♀️: a process acting on behalf of a human being, or a human being who wants file transfer service.

user site 🏡: a HOST site that meets any of these 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.

Usually, sites 1, 2, and 3 are the same site, but nothing in FTP requires that 🤷‍♀️.

user-FTP process 💁: a process (or set of processes) that does the file transfer work 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 (like use from TIPs and other mini-HOSTs), a user-FTP process gets folded into the term "user" 🫶.

user-TELNET 📞: a TELNET process that initiates an ICP to a specified server-TELNET socket, and performs in accordance with the ARPANET TELNET Protocol.

II.B. The FTP Model 🧠

With those definitions in mind, the following model (shown in Figure 1) can be drawn 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:

The data connection may be in either direction.
The data connection need not exist all of the time.
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 in Figure 1, the user-TELNET starts the TELNET connection. Then the user generates standard FTP commands and sends them to the server site over the TELNET connections. FTP commands are in ASCII, following NVT conventions and the TELNET protocol. Commands can be started by the user directly through the user-TELNET, or through a user-FTP process. Standard replies come back from the server to the user over the TELNET connections, in response to each command 📬.

The FTP commands set the parameters for the data connection (data socket, byte size, transfer mode, and representation type), and they describe the file system operation (store, retrieve, append, delete, etc.). The user-FTP process or its designate should "listen" on the specified data socket. It's the server's job to initiate the data connection and the data transfer, following the specified data connection parameters 🚀.

Here's the tea 🍵: the data socket doesn't have to be on the same HOST that sends the FTP commands over the TELNET connection. But the user, or their user-FTP process, must make sure there's a "listen" on the specified data socket. A practical example of this kind of third-HOST file transfer is a maxi-HOST user (who might really be a TIP user) wanting to send a file to or from an I/O device attached to a TIP 🖨️. It's also worth knowing that two data connections, one for send and one for receive, may exist at the same time 🔁.

The protocol requires that the TELNET connections stay open while a data transfer is in progress. It's the user's responsibility to close the TELNET connections when they're done with the FTP service. The server may abort a data transfer if the TELNET connections get closed 🚪.

III. DATA TRANSFER FUNCTIONS 🚚

Data and files only move over the data connection 📦. The data transfer is governed by FTP data transfer commands received on the TELNET connections. The data transfer functions cover setting up the data connection to the specified data socket on the specified HOST (using the specified byte size), sending and receiving data in the specified representation type and transfer mode, handling EOR and EOF conditions, and error recovery where it applies 🩹💖.

III.A Establishing Data Connection 🦋

Okay bestie, so the user site SHALL "listen" on the specified data socket 🎧. The FTP request command decides which way the data is going and whether the socket number is odd or even. That socket is what gets used to set up the data connection ✨. When the server gets the right store or retrieve request, it SHALL initiate the data connection to the user's data socket in the specified byte size (the default byte size is 8 bits 💅) and send a reply saying the file transfer may proceed. Before that, the server SHOULD send a reply with its own server socket for the data connection 🫶. The user MAY use that server socket info to keep their data transfer secure 🔐. The server MAY send this reply either before or after it starts the data connection, so no stress there 😭.

The byte size for the data connection is set by the TYPE command (ASCII is 8 bits) or by the TYPE and BYTE commands together 🎀. It is NOT REQUIRED by the protocol that servers accept every possible byte size. Using different byte sizes is all about efficiency in data transfer, so servers MAY implement only the byte sizes where their data transfer is efficient 💖. It is however RECOMMENDED that servers implement at least the byte size of 8 bits 🌸.

After the data transfer is completed, it is the server's responsibility to close the data connection, except when the user is the sender of data 🚪. The data connection SHALL be closed under any of the following conditions:

The server receives an abort command from the user.
EOF in stream mode is indicated by closing the data connection.
The socket or byte size specification is changed.
Any of the TELNET connections are closed.
An irrecoverable error condition occurs.

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 the sending HOST to a storage device in the receiving HOST. Often you have to transform the data, because the storage representations in the two systems are different 🔄. For example, NVT-ASCII is stored differently from one system to the next. PDP-10s generally store NVT-ASCII as five 7-bit ASCII characters, left justified in a 36-bit word 🧚. 360s store NVT-ASCII as 8-bit EBCDIC codes 💜. Multics stores NVT-ASCII as four 9-bit characters in a 36-bit word ⭐. It may be desirable to convert characters into the standard NVT-ASCII representation when transmitting text between dissimilar systems. The sending and receiving sites would have to do the necessary transformations between the standard representation and their internal representations 🫶.

A different problem pops up when you transmit binary data (not character codes) between HOST systems with different word lengths 😵‍💫. It is not always clear how the sender should send the data, or how the receiver should store it. For example, when sending 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) to store the 32-bit bytes right justified in a 36-bit word on 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 type representations. Transformations desired beyond this limited capability SHOULD be performed by the user directly, or via the Data Reconfiguration Service (DRS, RFC #138, NIC #6715). Additional representation types MAY be defined later if there is a demonstrable need. 🚨

Data representations are handled in FTP by the 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 is the byte size specified by the BYTE command to be used. The following data representation types are currently defined in FTP 👑:

ASCII: The sender converts data from 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 the default type, and it is RECOMMENDED that this type be implemented by all. 📝
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. 🤖
Local Byte: This representation allows for efficient storage, use, and retrieval of data. The manner in which data is transformed depends on the byte size used for data transfer and on the particular HOST being used. The transformation scheme for different byte sizes is to be well publicized by 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 their transfer 🗂️. Typical uses of the Local Byte type are efficient storage and retrieval of files, and transfer of structured binary data. This type may be identical to the Image type for byte sizes that are integral multiples of, or factors of, the computer word length 🧩.
Print File-ASCII: The server site will transform the ASCII 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 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. In some systems this type may be identical to the ASCII type. It is RECOMMENDED that this type be implemented by all. 🖨️
EBCDIC Print File: The server site will transform the EBCDIC 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 sizes, 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 their file SHOULD be able to store and retrieve their 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 🗑️.

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 of files with record structures. Records MAY be of zero length, but they MUST be contained within file boundaries. And the relationship between

okay so files and records are hierarchical, bestie 🧚, and an EOF implies an EOR ✨

Here are the data transfer modes FTP defines 💅

Stream 🌊 The file is sent 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 stream mode, but record structures are only possible 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. 🫶
Text 📝 The file is ASCII text sent as a 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 to one) in the data stream. The EOR code is 192 (octal 300, hex C0). The EOF code is 193 (octal 301, hex C1). The byte size for transfer is 8 bits. 💖
Block 🧱 The file is sent as a series of data blocks, each preceded by one or more header bytes. The header bytes contain a count field and a descriptor code. The count field indicates the total length of the data block in bytes, which marks 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 an integral number of bytes whose length is greater than or equal to 24 bits. Only the least significant 24 bits (right-justified) of the header shall have information, and the other most 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, no cap 👑

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 embedded in the data stream as an integral number of 8-bit bytes (representing printable ASCII characters), right-justified in an 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 a 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 not 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  |
                    |    | Marker  | Marker | Marker | Marker |
                    |    | 8 bits  | 8 bits | 8 bits | 8 bits |


                    |    | Marker  | Marker | SP     | SP     |
                    |    | 8 bits  | 8 bits | 8 bits | 8 bits |

Hasp 🗜️ The file is sent 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 the 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 the data stream, along with some marker information. The marker information has meaning only to the sender, but it 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 which 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 ✨

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 corresponding data point in its file system and conveys the last known sender and receiver marker information to the user. In the event of a system failure, the user or user-FTP process restarts the server at the last server marker by sending a restart command with the server's marker code as 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 occurred. 💅
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 involve 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 followed by Line Feed). The command codes themselves are ASCII alphabetic 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 is 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. 🍓

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 which 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 a password 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 they complete the user's identification for access control. ✨

IV.A.2 Data Transfer Commands ✨

Okay bestie, data transfer parameters all come with default values, so you only send these commands if you want to change something 💅 They're REQUIRED only if you're changing a default. The default is whatever value was last specified, or the standard default if nothing has been specified yet. That means the server MUST "remember" these defaults 🧠 You can send the commands in any order, as long as they all come before the FTP service request. Here are the data transfer parameters:

Byte size (BYTE): The argument is an ASCII-represented decimal integer from 1 through 255, and it sets the byte size for the data connection when using the local byte and image representation types. The default is 8 bits. In the ASCII and Print file representation types, the byte size is always 8 bits 🎀 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 used in the data connection. There MAY be two data sockets, one for server to user transfers and one for user to server transfers. An odd socket number is a send socket and an even socket number is a receive socket. The default HOST is the user HOST that TELNET connections are made to. 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) 🦋

Representation Type (TYPE): The argument is a single ASCII character code that picks one of the representation types from section III.B. These are the codes 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 that picks the file structure from section III.C. These are the codes 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 that picks one of the data transfer modes from Section III.C. These are the codes 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. 🦋

These commands are the main event 🎬 They define the file transfer or the file system function the user is asking for. The argument of an FTP service command is normally a pathname. The syntax of pathnames MUST follow the server site's conventions (with the standard defaults applying), except that ASCII characters MUST be used (to match the TELNET Protocol). The suggested default is to use the last specified device directory or file name, or the standard default 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. Any data transferred in response to FTP service commands SHALL always go over the data connection. Here are the FTP service requests:

Retrieve (RETR): This command gets a copy of the file named in pathname and transfers it from the server to the user site. The status and contents of the file at the server site SHALL be unaffected 📥

Store (STOR): This command transfers a copy of a file from the user to the server site. If the file named in pathname already exists at the server site, its contents SHALL be replaced by the contents of the file being transferred. If the file named in pathname does not exist yet, a new file is created at the server site 📤

Append (with create) (APPE): This command transfers data from the user to the server site. If the file named in pathname exists at the server site, the transferred data SHALL be appended to that file. Otherwise, the file named in pathname SHALL be created at the server site ➕

Rename from (RNFR): This command names the file that is going to be renamed. It MUST be immediately followed by a "rename to" command that gives the new file pathname ✏️

Delete (DELE): This command deletes the file named in pathname at the server site. If you want an extra layer of protection, like a "Do you really wish to delete?" prompt, it SHOULD be provided by the user-FTP process 🗑️

List (LIST): This command sends a list from the server to the user site. If pathname names a directory, the server SHOULD transfer a list of the files in that directory. If pathname names a file, the server SHOULD send current information about that file. You can use this command to get the contents of a file directory (the response SHOULD be sent in ASCII type), or to check whether a file exists and what its current status is 🔍

Allocate (ALLO): Some servers MAY be REQUIRED to reserve enough storage for the new file before it's transferred, and this command is how you do that 💾 The command field is a decimal integer for the number of bytes (in the size set by the byte size command) to reserve 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 servers that don't need the maximum file size declared beforehand 🙌

Restart (REST): The argument field is the server marker where the file transfer should restart. This command doesn't start a transfer, it just "spaces" over the file up to the specified data checkpoint ⏩ This command SHALL be immediately followed by the appropriate FTP service command, which SHALL cause the file transfer to resume 🔁

Status (STAT): This command SHALL cause a status response to be sent over the TELNET connection as a reply 📊 The command MAY have an argument field, such as a pathname. If the argument is a pathname, the command works like the "list" command, except the data SHALL be transferred in ASCII on the TELNET connection. If no argument is given, the server SHOULD return general status information about the server FTP process. That MAY include service availability, the current settings for the relevant FTP parameters (including the default settings), and the status of command execution and connections 🧾

Abort (ABOR): This command tells the server to abort the previous FTP service command and any transfer of data linked to it 🛑 The abort command SHOULD be preceded by the TELNET SYNCH condition (shown by the combination of the DATA MARK and the INS). No action is taken if the previous command has already completed, including data transfer. The server does not close the TELNET connection, but the data connection MAY be closed. An appropriate reply SHOULD be sent by the server 🙅‍♀️

Logout (BYE): This command ends a USER session and, if no file transfer is in progress, closes the TELNET connection 👋 If a file transfer is in progress, the connection stays open so the result response can be sent, and then it closes. In the meantime, a new USER command (and no other command) is acceptable 🫶

An unexpected close of the TELNET connection makes the server act as if it received an abort (ABOR) and a logout (BYE) 😭

IV.B FTP Replies 💌

The server sends FTP replies to the user over the TELNET connections, in response to FTP commands. These replies are the acknowledgement or completion codes (including errors). They're formatted so that both humans and programs can read them 🤖 Each reply is a leading three-digit numeric code, then a space, then a text explanation. The numeric codes are grouped, and they're designed to be easy for programs to read, in a way that's consistent with other protocols like the RJE protocol. Here's how to read the three digits:

a) The first digit tells you the type of response:

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 tells you the general category the response is about:

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.

c) The final digit gives a specific message type. Since the code is designed for an automaton process to interpret, not every variation of a reply needs a unique number. Only the basic meaning of replies needs unique numbers. The text of a reply can explain the specific reason to a human user 🌈

Each TELNET line (ended by CRLF) from the server is meant to be a complete reply message. If a reply's text has to continue onto the following lines, those continuation replies use the special reply code of three spaces. The reply text is meant for human users. Only the reply codes, and in some cases the first line of text, are meant for programs 💖

These are the assigned reply codes for FTP:

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.

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 🔌

okay so the server-FTP process at the server site is the one that listens on Socket 3, through its server-TELNET 👂. the user (or user-FTP process) at the user site is the one that starts the full-duplex TELNET connections, using its user-TELNET and the ARPANET standard initial connection protocol (ICP) to reach server socket 3 💖. when the user is done, the user site is the one that closes those TELNET connections.

the user site also "listens" on the data socket or sockets it specified (a send socket, a receive socket, or both 🦋). the server site is the one that opens the data connection, using the data socket and byte size that were specified. which direction the data goes and which data socket gets used are both decided by the FTP service command 🧚. the server sends the user a reply saying which server data socket it's using, so the user can check the data transfer is the real deal 🔒. the server can do this any time before the first data transfer over a data connection.

the server site closes the data connection under the conditions described in Section III.A 🚪. in general the server should send a reply before it closes the data connection, so the user end doesn't get confused 💅.

V.B. Commands 💬

commands are ASCII character strings sent over the TELNET connections, like we covered in section IV.A 🌸. the command functions and semantics live in sections IV.A.1, IV.A.2, IV.A,3, and IV.A.4, and the syntax lives right here 🍓.

every command starts with a command code, followed by an argument field 🧁. command codes are four or fewer ASCII alphabetic characters. upper and lower case get treated exactly the same, so all of these can mean the retrieve command 🫶:

RETR Retr retr ReTr rETr

the command code and the argument field are separated by one or more spaces ✨.

the argument field is a variable length ASCII character string that ends with the CRLF sequence (Carriage Return immediately followed by Line Feed) 📏. in the syntax section, every character in an argument field is ASCII, so a decimal integer means an ASCII-represented decimal integer 🔢.

here are all the FTP commands that are defined right now 👑:

     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

here's the syntax for those argument fields, written in BNF notation where it applies 🧠:

     <username> ::= <string>
     <password> ::= <string>
     <string> ::= <empty> | <char> | <char><string>
     <char> ::= any of the 128 ASCII characters except CR and LF.
     <marker> ::= <pr string>
     <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 user and server are meant to have an alternating dialogue, kinda like a turn-based game 🎮. the user sends an FTP command, and the server answers with a primary reply that says success or failure. the user should wait for that first primary reply before sending any more commands 🫠.

the second type is a secondary reply, which shows up asynchronously, so it isn't tied to any particular user command 🌈. these can report on how a file transfer is going or whether it finished, which makes them secondary replies to file transfer commands 📦.

the third type is informational and spontaneous. these can show up at any time, and they're 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

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:

🌟 the TIP user opens TELNET connections using ICP to HOST X, socket 3.
💌 these commands and replies get swapped:

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

🔚 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. 💡

2. User at Host U wanting to transfer files to/from HOST S:

in general, the user talks to the server through a mediating user-FTP process 🤝. here's a typical scenario 🎬. the user-FTP prompts are in parentheses, ----> means commands from HOST U to HOST S, and <---- means 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.

ACKNOWLEDGEMENTS 🫶🌸

this work on the file transfer protocol took a whole crew of people 👯‍♀️. this document is the work of a group, not just the author 💜. the author is super grateful for the contributions from all of these legends 👑:

          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  ]

RFC>>>

📦 where this page comes from

ietf: rfc354 1972-07
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms