RFC 454
File Transfer Protocol - meeting announcement and a new proposed document
RFC 454: File Transfer Protocol 🎀
Bestie, the title block first! 💖 This is RFC 454, from the Network Working Group, written by A. McKenzie at BBN. The NIC number is 14333 and the date is 16 February 1973. The title is "File Transfer Protocol: Meeting Announcement and a New Proposed Document." 🦋 The document doesn't state a category, and it doesn't say it obsoletes anything. What it does say is that it's an extensive update to RFC 354 🌸
Meeting Announcement and a New Proposed Document 📣
Okay so this is a new proposal for a File Transfer Protocol 💅 It's a big update to RFC 354, and Alex thinks it fixes most of the complaints people had about RFC 354. ✨
Since everyone's been trying to agree on FTP for ages, Alex is calling a meeting at BBN on March 16 to talk about this proposal and some others. 🧚
This note isn't just for the old FTP committee, because not everyone who helped shape FTP is on that committee 🫶 The meeting is supposed to pick up from where things are now, not reteach everyone from scratch. So if you're coming, read at least these:
If you want to come, contact Alex McKenzie (NIC Ident aam) at BBN, 50 Moulton Street, Cambridge, Mass. 02138. His phone number is (617) 491-1850 ext.441 📞
Once there's a rough headcount, a room will get booked and attendees will get more details. 🍓
PROPOSED FILE TRANSFER PROTOCOL 🦋
This document came out of a meeting held 25 January 1973 in Cambridge, Massachusetts. The people there were:
- Abhay Bhushan (MIT - DMCG)
- Bob Bressler (BBN - NET)
- Bob Clements (BBN - TENEX)
- Alex McKenzie (BBN - NET)
- Nancy Neigus (BBN - NET)
- Ken Pogran (MIT - MULTICS)
- Marc Seriff (MIT - DMCG)
The base is RFC 354, with ideas taken from RFCs 385, 414, 418, and 438, plus conversations with people on the network. 💜
PROPOSED FILE TRANSFER PROTOCOL 🌈
INTRODUCTION ✨
The File Transfer Protocol (FTP) is how files get moved 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 make it easy to use remote file storage.
FTP has four goals: 1) help people share files (programs and/or data), 2) make it easier to use remote computers indirectly or implicitly (through programs), 3) hide the differences between file storage systems on different HOSTs from the user, and 4) move data reliably and efficiently. 🫶 A person at a terminal can use FTP directly, but it's mostly built for programs to use.
This spec is trying to serve lots of different users at once: maxi-HOSTs, mini-HOSTs, TIPs, and the Datacomputer. 💅 The goal is a protocol that's simple, elegant, and easy to implement. Iconic. 👑
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 🎀
This section covers the terminology and the FTP model. Only the terms that have a special meaning in FTP get defined here. 🧠
II.A. Terminology 📖
- ASCII: The USASCII character set, as defined in NIC #7104. In FTP, ASCII characters are the lower half of an eight-bit code set, which means the most significant bit is zero. 🔤
- access controls: These define what users are allowed to do with a system and its files. They're needed to stop unauthorized or accidental file use. A server-FTP process is the one that gets 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's byte size isn't necessarily the one the data gets stored in on the system, and it might not match the data's structure. 📦
- data connection: A simplex connection that moves data in a specified byte size, mode, and type. The data can be part of a file, a whole file, or several files. It can go in either direction (server-to-user or user-to-server). 🔁
- data socket: The socket a User-FTP process "listens" on for a data connection. 👂
- EOF: The end-of-file condition, which marks the end of a file being transferred. 🏁
- EOR: The end-of-record condition, which marks the end of a record being transferred. 📝
- error recovery: A procedure that lets a user recover from certain errors, like a HOST system or transfer process failing. In FTP, error recovery can mean restarting a transfer from a given checkpoint. ♻️
- FTP commands: The set of commands that carry the control information going from the user-FTP to the server-FTP process. 🎮
- file: An ordered set of computer data (programs included) of any length, uniquely identified by a pathname. 🗂️
- mode: The mode that data gets transferred in over the data connection. The mode defines the data format, including EOR and EOF. The transfer modes in FTP are described in Section III.C. 🚦
- 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 partly embraces NVFS right now. 🌐
- pathname: The character string a user has to type into a file system to identify a file. It usually includes device and/or directory names and a file name. FTP doesn't define a standard pathname convention yet, so each user has to follow the naming rules of whatever file systems they use. 🛣️
- record: A sequential file can be split into a number of contiguous parts called records. FTP supports record structures, but they aren't required. 🧩
- reply: An acknowledgement (positive or negative) that the server sends to the user over the TELNET connections, in response to FTP commands. A reply is a completion code (error codes included) followed by an ASCII text string. The codes are for programs, and the text is for humans. 💬
- server-FTP process: A process, or set of processes, that does the file transfer work together with a user-FTP process. It has to interpret and respond to user commands, and it starts 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 started by a user-TELNET, and works according to 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 when data is stored and when it's transferred. The representation types in FTP are described in Section III.B. 🎨
- user: A process acting for a human, or a human 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, or 3) a site a server makes a data connection to. Normally, 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 together with a server-FTP process. The user-FTP process 1) starts the ICP (through a user-TELNET), 2) starts 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), the user-FTP process just gets folded into the term "user". 🤝
- user-TELNET: A TELNET process that starts an ICP to a specified server-TELNET socket, and works according to the ARPANET TELNET protocol. 📞
That's the first part, bestie! 🌈💖 More is coming, so stay tuned!
II.B. The FTP Model ✨
okay so with those definitions locked in 🔐, here's the model (Figure 1 👇) for an FTP service, bestie 💖
in the Figure 1 setup, the user-TELNET is the one that starts the TELNET connections 🎀. Then the user generates standard FTP commands and sends them to the server site over those TELNET connections. FTP commands are ASCII, following NVT conventions and the TELNET protocol. Commands can come straight from the user through the user-TELNET, or through a user-FTP process 💅. Standard replies go back from the server to the user over the TELNET connections in response to those commands.
the FTP commands set the parameters for the data connection (data socket, byte size, transfer mode, representation type, and format) and the kind of file system operation (store, retrieve, append, delete, etc.) 🗂️. The user-FTP process or its designate SHOULD "listen" on the specified data socket, and it's the server's job to start the data connection and the data transfer using the specified data connection parameters 🧚. It should be noted that the data socket doesn't have to be on the same HOST that sends the FTP commands over the TELNET connections, but the user or their user-FTP process MUST ensure a "listen" on the specified data socket 🙈. A practical example of this kind of file transfer to a third HOST is a maxi-HOST user (who might actually be a TIP user) who wants to send 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 🦋.
TELNET
Connections
+-----+ +-------+ +------+ +------+ +-------+ +-----+
| File|<->|Server-|<->|Server|<----------|User |<->|User- |<->|File |
|Sys | |FTP | |TELNET| FTP Cmds |TELNET| |FTP | |Sys- |
| -tem| |Process| | |---------->| | |Process| | tem |
+-----+ | | +------+FTP Replies+------+ | | +-----+
| | | |
| |<------------------------------->|Data |
| | Data Connection(s) |Socket |
+-------+ +-------+
|
|
+------+
| |
| USER |
| |
+------+the figure's notes, in plain English 📝:
- The data connection MAY be in either direction. 🔄
- The data connection need not exist all of the time. ⏳
- The lines between user-FTP and user-TELNET, and between server-FTP and server-TELNET, may not be as clear-cut as the figure shows. For example, a user-TELNET may be directly driven by the user. 🤷♀️
FIGURE 1 Model for FTP Usethe protocol requires that the TELNET connections stay open while a data transfer is in progress 🔒. It's the user's job to close the TELNET connections when they're done using the FTP service 👋. The server MAY abort the data transfer if the TELNET connections get closed 💀.
III. DATA TRANSFER FUNCTIONS 🚚
data and files only move over the data connection, periodt 💜. The transfer is controlled by the FTP data transfer commands that come in over 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 applicable) ✨.
III.A. Establishing Data Connection 🔌
the user site SHALL "listen" on the specified data socket before it sends a transfer request command 🎧. The FTP request command decides which way the data goes, and which socket number (odd or even) gets used to set up the data connection 🧭. When the server gets the right store or retrieve request, it SHALL start the data connection to the specified user data socket using the specified byte size (the default byte size is 8 bits), and then send a reply saying that the file transfer may proceed 🚀. Before that reply, the server SHOULD send a reply that tells the user the 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.
the byte size for the data connection is set by the BYTE command 🔢. It is not required by the protocol that servers accept every possible byte size. Different byte sizes are there for efficiency in data transfer, so servers MAY implement only the byte sizes where their data transfer is efficient 🏎️. It is, however, REQUIRED that servers implement at least the byte size of 8 bits 💯.
once the data transfer is done, the server is responsible for closing the data connection, unless the user is the one sending the data 🧹. In stream mode the sender MUST close the data connection to signal EOF, which means the transfer is complete 🏁. Closing the connection is a server option, except in these situations:
- The server receives an abort command from the user. 🛑
- The socket or the byte size specification is changed by the user. 🔄
- The TELNET connections are closed. 📞
- An irrecoverable error condition occurs. 😭
It should be noted that if none of the above happen, it's possible to keep two data connections open at the same time, one for send and one for receive 🫶.
III.B Data Representation and Storage ✨
okay so bestie, data is always moving from a storage device on the sending HOST to a storage device on the receiving HOST 🚚💖 and the tricky part is that those storage devices often don't agree on how things are stored. so transformations are often needed to make the data make sense on the other side 🫶 For example, NVT-ASCII is stored totally differently depending on the system. 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. 🙈 So when you're sending text between systems that are totally different, it may be desirable to convert characters into the standard NVT-ASCII representation. The sending and receiving sites would then have to do the necessary transformations between the standard representation and their own internal representations. it's giving teamwork 👯♀️
Then there's a different representation problem, which is binary data (not character codes) going between HOSTs with different word lengths 🧩 It's 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 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 the data representation and transformation functions. ngl this is the user being in charge of their own data 👑 It should also be noted that FTP provides for very limited data type representations 💀 Any transformations beyond this limited capability should be performed by the user directly, or via the use of the Data Reconfiguration (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 imply a transfer byte size 🍓 For example, in ASCII representation, the transfer byte size should be 8 bits, and any other byte size specification will result in cancellation of the transfer request 😭 In Image and Local Byte representations, any byte size is possible. The following data representation types are currently defined in FTP:
- ASCII The sender converts data from its internal character representation to the standard NVT 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. It's giving main character energy for text files 📄💅
- EBCDIC The sender transfers data using the EBCDIC character code and an 8-bit transfer byte size. This type may be used for efficient transfer of EBCDIC files between systems which use EBCDIC for their internal character representation. ✨
- Image The sender transforms data from contiguous bits to bytes for transfer. The receiver transforms the bytes back into bits, storing them contiguously, independent of the byte size chosen for data transfer. With record structure and block mode, the server might need to pad each record for convenient storage. This padding is allowed at the end of a record, and should be remembered by the server so it will be stripped off when the file is retrieved by the user. The padding transformation should be well publicized by the server in case the user processes their file at the server site. 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 for data transfer, and on the particular HOST being used. The transformation scheme for each byte size 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 which are integral multiples of, or factors of, the computer word length. 🎀
Representation type may also be affected by another attribute, the format 🌸 For example, some printers can use ASA (Fortran) vertical format control procedures to transform printed data of type ASCII or EBCDIC. Currently, format may take one of two values.
- Unformatted The representation type, as specified, is unaffected by any format transformations. This is the default value. 🫧
- Printfile The server is to transform data of either ASCII or EBCDIC type in accordance with ASA (Fortran) vertical format control standards. The data is to be transferred in 8-bit bytes. 🖨️
A discussion of the ASA vertical format control appears in NWG/RFC 189, Appendix C, and in Communications of the ACM, Vol. 7, No. 10, p. 606, October 1964. According to the ASA vertical format control standards, the first character of a formatted record is not printed, but determines vertical spacing as follows: 📖
Character Vertical Spacing before printing
Blank One line
0 Two lines
1 To first line of the next page
+ No advanceIn addition to the above four, there are more characters (defined in Appendix C, RFC 189) which represent an IBM extension to the ASA standard. 🧚
It should be noted that a serving host need not accept all representation types and/or byte sizes, but it must inform the user requesting an unacceptable type or size of this fact by sending an appropriate reply. 💜
III.C. File Structure and Transfer Modes ✨
okay so the ONLY file structures FTP supports directly right now are record structures 📝 but using them is not mandatory 🌸. A user with no record structure in their file SHOULD be able to store and retrieve it at any HOST 🧚. A user who wants to send a record structured file MUST send the right FTP STRU command (the default assumption is no record structure) 💅. A serving HOST need not accept record structures, but it MUST tell the user about that by sending an appropriate reply 🫶. Any record structure info in the data stream MAY be thrown away by the receiver later 🗑️
every data transfer MUST end with an EOF 🔚. The EOF is defined by the data transfer mode. For files with record structures, the transfer mode also defines an EOR. Only the transfer modes and representation type combos that have EOR defined MAY be used for transferring files with record structures 📦. Records MAY be zero length, but they MUST sit inside file boundaries 🧸. The relationship between files and records is hierarchical, but an EOF does not imply an EOR 🌈
the following data transfer modes are defined in FTP:
- Stream 🌊 The file is sent as a stream of bytes of the specified byte size. The EOF is signaled by closing the data connection. Any representation type and byte size MAY be used in stream mode with file structure, but using record structure limits the type to ASCII or EBCDIC, with or without Printfile format. The convention is that the ASCII character CR (Carriage Return, Code 15 (octal)) followed by LF (Line Feed, Code 12 (octal)) indicates an EOR for ASCII representation type, and the EBCDIC character NL (New Line, Code 15 (hex)) indicates an EOR for EBCDIC type. This is the default mode, and it is RECOMMENDED that every implementation supports this mode 💖
- Text 📄 The file is ASCII text sent as a sequence of 8-bit bytes in the ASCII representation type, with optional Printfile format. Record structures are allowed in this mode. The EOR and EOF are defined by the presence of special "TELNET-control" codes (,ost significant bit set to one) in the data stream. The EOR code is 192 (octal 300, hex CO). The EOF code is 193 (octal 301, hex C1). The byte size for transfer is 8 bits 🎀
(for ASCII type, text and stream modes are almost identical 👯) but comparing the two, the perks of "stream" mode are:
- The receiver need not scan the incoming bytes 😌
- It is usable with all data types 🙌
and the downsides are:
- Closing the data connection under error conditions can be misconstrued as an EOF in stream mode, when in fact the data transfer was interrupted 😭 In text mode the EOF is sent explicitly ✅
- If record structure is specified in stream mode, then CRLF implies EOR, and for CRLF to be sent as valid data it MUST be transformed, e.g., into CR NUL LF or LF CR 🙈
- Block 🧱 The file is sent as a series of data blocks preceded by one or more header bytes. The header bytes contain a count field and a descriptor code. The count field gives the total length of the data block in bytes, which marks the start 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 is the smallest 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 carry information; the remaining most significant bits are "don't care" bits 🫧 Of the 24 bits of header info, the 16 low order bits SHALL represent the byte count, and the 8 high order bits SHALL represent descriptor codes, as shown below:
Integral data bytes >= 24
+---------------+---------------+--------------+
| Don't care | 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.in block mode it's possible for two or more conditions that need different descriptor codes (suspected errors and either end of record or end of file) to be true at the same time 🤯 Such a situation MAY be handled by sending a separate EOR or EOF block with a zero byte count. (This is allowed by the protocol.) 🙌
the restart marker is embedded in the data stream as an integral number of 8-bit bytes (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 byte size of 16 bits or more, two or 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 don't exactly fill 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:
+-------------+-------------+---------------+
| Don't care | 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 gets considerable compression for print files 🗜️ Record structures are allowed in Hasp mode 💜
the matrix below sums up the legal combos of file transfer parameters 📊 The decimal integers are the legal byte sizes for each STRU-MODE-TYPE-FORM grouping. No number means it's illegal 🚫 Note that HASP mode isn't in here, since it has never been defined 🫠
STRU F | R
+-------------------------------+-----+-----+------+
TYPE |\ MODE | | | |
| \ | | | |
| \ S T B | S | T | B |
| FORM +--------+-----+---------+-----+-----+------+
A | U | 8 | 8 | 8 | 8 | 8 | 8 |
| +--------+-----+---------+-----+-----+------+
| P | 8 | 8 | 8 | 8 | 8 | 8 |
----+------+--------+-----+---------+-----+-----+------+
E | U | 8 | | 8 | 8 | | 8 |
| +--------+-----+---------+-----+-----+------+
| P | 8 | | 8 | 8 | | 8 |
----+------+--------+-----+---------+-----+-----+------+
I | U | 1-255 | | 1-255 | | |1-255 |
----+------+--------+-----+---------+-----+-----+------+
L | U | 1-255 | | 1-255 | | |1-255 |
----+------+--------+-----+---------+-----+-----+------+III.D Error Recovery and Restart 🔥
Okay bestie, so there is literally no provision for detecting bits that get lost or scrambled during data transfer 😭 This is handled best at the NCP level, where it helps the most users. BUT there is a restart procedure to protect the user from system failures, like if a HOST, the FTP-process, or the IMP subnet goes down 🫶
The restart procedure is only defined for block mode of data transfer ✨ The sender of data has to insert a special marker code into the data stream, along with some marker information. Only the sender cares what that marker information means, but it has to be made of printable ASCII characters. Printable here means octal codes 41 through 176, so NOT codes 0 through 37, and NOT the characters SP and DEL 💅 The marker could be a bit-count, a record-count, or anything else a system can use to spot a data checkpoint 🧚 If the receiver implements the restart procedure, it marks the matching spot in its own system and sends that info back to the user.
In a system failure, the user can restart the data transfer by pointing at the marker point with the FTP restart procedure. Here are some examples, bestie 🎀
- When the server is the sender of data, the server-FTP process drops an appropriate marker block into the data stream at a convenient data point. The user-FTP process receives the data, marks the matching data point in its file system, and tells the user the last known sender and receiver marker information. If a system failure happens, 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 goes over the TELNET connection and is immediately followed by the command (such as store or retrieve) that was running when the failure happened 🦋
- When the user is the sender of data, the user-FTP process inserts the appropriate marker block into the data stream. The server-FTP process receives the data and marks the matching data point in its file system. The server doesn't store this marker, but it does tell the user the last known sender and receiver marker information over the TELNET connections, using appropriate reply codes. The user or user-FTP process then restarts the transfer in the exact same way as in the first example 💜
IV. FILE TRANSFER FUNCTIONS 🌈
The TELNET connections that carry FTP commands and replies get started by the user-FTP process, via an ICP to a standard server socket. FTP commands travel from user to server, and replies travel from server to user. The user side sends FTP commands, interprets the replies it gets back, and transfers data over the data connection in the specified manner. The server side accepts and interprets FTP commands, sends replies, sets up the data connection, and transfers data 👑
IV.A FTP Commands 💖
FTP commands are ASCII strings 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' (octal code 40). For convenience, command codes are defined to be four (or less) ASCII alphanumeric characters, including both upper and lower case alphabetic characters. This section covers the command codes and what commands mean, but the detailed syntax of commands is specified in Section V.B, the reply sequences are discussed in Section V.C, and scenarios showing commands in action are in Section V.D 🍓
FTP commands can be sorted into those that specify access-control identifiers, those that specify data transfer parameters, and those that make FTP service requests. Certain commands (such as ABOR, STAT, BYE) can be sent over the TELNET connections while a data transfer is in progress. Some servers may not be able to monitor the TELNET and data connections at the same time, in which case these commands should be preceded by a TELNET SYNC to wake the server up. (For other servers this may not be necessary, and the SYNC will be ignored.) 🙈
IV.A.1 Access Control Commands 🔐
The following commands specify access control identifiers (command codes are in parentheses).
- User name (
USER) - The argument field is an ASCII string identifying the user. The user identification is whatever the server requires for access to its file system. This command will normally be the first command the user sends after the TELNET connections are made (some servers may require this). Additional identification in the form of a password and/or an account command may also be required by some servers. Servers may allow a newUSERcommand to be entered at any point in order to change the accounting information. All parameters stay unchanged, and any file transfer in progress is completed under the old account 🎀 - 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, for some sites, it completes the user's identification for access control. Password information is super sensitive, so it's generally desirable to "mask" it or suppress the type-out. It appears that the server has no foolproof way to do this. So it's the responsibility of the user-FTP process to hide the sensitive password information 🔒 - Account (
ACCT) - The argument field is an ASCII string identifying the user's account. This command isn't necessarily related to theUSERcommand, since some sites may require an account for login and others only for specific access, such as storing files. In the latter case the command may arrive at any time. There are two reply codes that tell these cases apart for the automaton. When account information is required for login and the server receives another command which it buffers, the legal response is reply code 331. When an account is required for a specific transfer that was requested, reply code 433 is returned and the request command is flushed 💅 - Reinitialize (
REIN) - This command terminates aUSER, flushing all I/O and account information, except to allow any transfer in progress to be completed. All parameters are reset to their default settings, and the TELNET connection is left open. AUSERcommand is expected to follow ✨ - Logout (
BYE) - This command terminates aUSERand, if no file transfer is in progress, closes the TELNET connection. If a file transfer is in progress, the connection stays open for the result response and then closes. For "hot card-reader" mode, theREINcommand should be used instead 🌸
An unexpected close on the TELNET connection will make the server take the effective action of an abort (ABOR) and a logout (BYE) 😭
IV.A.2 Transfer Parameter Commands 🦋
All data transfer parameters have default values, and the commands that specify data transfer parameters are only required if the default values need to change. The default value is the last specified value, or, if no value has been specified, the standard default value stated here. This means the server must "remember" the applicable default values 🧠 The commands can come in any order, except that they must come before 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) that specifies the byte size for the data connection. The default byte size is 8 bits. The byte size is always 8 bits in the ASCII and EBCDIC representation types. A server may reject specific byte size/type combinations by sending an error reply code in response to a transfer request command 💖 - Data socket (
SOCK) - The argument is a HOST-socket specification for the data socket to be used in the 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) 🌈 - Listen (
LSTN) - The argument is a single ASCII character code that specifies the direction of the socket the server must allocate for use as a data connection. The server is to "listen" on the allocated socket when an appropriate transfer command is given. The following codes are assigned:
S - send
R - receive- 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
E - EBCDICThe default representation type is ASCII 🍓
- Format (
FORM) - The argument is a single ASCII character code specifying the formats described in Section III.B. The following codes are assigned for format:
U - Unformatted
P - PrintfileThe default format is Unformatted 💅
- File Structure (
STRU) - The argument is a single ASCII character code specifying the file structure described in Section III.C. The following codes are assigned for structure:
F - File (no ecord structure)
R - Record structureThe default structure is File (ie. 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 code for EOR, EOF)
H - Hasp (specially formatted compressed data)The default transfer mode is Stream 👑
IV.A.3 FTP Service Commands 💅
okay so these are the commands that actually tell the server what file system job the user wants done 🗂️ The argument is usually a pathname. Pathname syntax has to follow the server site's conventions (with standard defaults applying), except that ASCII characters MUST be used, matching the TELNET Protocol 🫶 The suggested default is to reuse the last device, directory, or file name, or the standard default for local users. Commands can come 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. Data sent in response to these commands SHALL always go over the data connection. Here's the lineup ✨
Retrieve (RETR) - This is the one that copies a file from server to user site. The status and contents of the file at the server site SHALL be unaffected, so the original stays exactly as it was 🦋
Store (STOR) - This copies a file from user to server site. If the file in the pathname already exists at the server, its contents SHALL be replaced by the contents of the file being transferred. If it doesn't exist yet, a new file gets created at the server site 🎀
Append (with create) (APPE) - This moves data from user to server site. If the file in the pathname exists at the server, the data SHALL be appended to that file. Otherwise, the file in the pathname SHALL be created at the server site 🌸
Allocate (ALLO) - This command MAY be REQUIRED by some servers so they can reserve enough storage for the new file. The argument field SHALL be a decimal integer showing how many 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 transfer should restart. This command doesn't start a transfer. It just "spaces" over the file up to the specified data checkpoint ⭐ It SHALL be immediately followed by the right FTP service command, which SHALL make the transfer resume 💖
Rename from (RNFR) - This names the file that's getting renamed. It MUST be immediately followed by a rename to command that gives the new file pathname 🍓
Rename to (RNTO) - This gives the new pathname for the file named in the rename from command right before it. Together, the two commands rename the file 🫶
Abort (ABOR) - This tells the server to abort the previous FTP service command and any data transfer tied to it. The abort command SHOULD be preceded by the TELNET SYNCH condition (shown by the combo of the DATA MARK and the INS) 🔥 If the previous command already finished (data transfer included), no action is taken. The server must not close the TELNET connections, but the data connection MAY be closed. An appropriate reply SHOULD be sent by the server 💅
Delete (DELE) - This deletes the file in the pathname at the server site. If you want an extra layer of protection, like asking "Do you really wish to delete?", that SHOULD be handled by the user-FTP process 💀
List (LIST) - This sends a list from server to user site. If the pathname is a directory, the server SHOULD send a list of the files in that directory. If the pathname is a file, the server SHOULD send current information about that file. A null argument means the user's current working or default directory. The data goes over the data connection in type ASCII or type EBCDIC. (It's the user's responsibility to make sure the parameters are right 🙈)
NList (NLST) - This sends a directory listing from server to user site. The pathname SHOULD point to a directory, and the server returns a stream of file names with nothing else attached. The data goes over the data connection in ASCII or EBCDIC type as valid pathname strings separated by CRLF. Paired with the right transfer commands, this lets you copy a whole directory automatically 🌈
Status (STAT) - This SHALL send a status response over the TELNET connection as a reply. It MAY be sent during a file transfer (preceded by a TELNET SYNC), and then the server responds with the status of the operation in progress. It MAY also be sent between transfers. In that case it MAY have an argument field, like a pathname. If the argument is a pathname, the command works like LIST, except the data SHALL be sent in ASCII over the TELNET connection. If you give a partial pathname, the server MAY respond with a list of file names or attributes that match it. With no argument, the server SHOULD return general status info about the server FTP process. That SHOULD include the current values of all transfer parameters and the status of connections 👑
Help (HELP) - This SHALL make the server send helpful info about its implementation status over the TELNET connection to the user. The command MAY take an argument (like any command name) and return more specific info. The reply is type 100, general system status. It's suggested that HELP be allowed before a USER command is entered 🌸
Mail File (MLFL) - The point of this one is letting a user site mail data (as a file) to another user at the server site ✉️ The files get sent over the data connection in ASCII or EBCDIC type. (It's the user's responsibility to make sure the type is correct.) The server SHOULD append these files to the destination user's mail, following the serving HOST mail conventions. The mail MAY be marked as sent from the particular using HOST and the user named in the 'USER' command. The argument field MAY contain one or more system or NIC idents (it is RECOMMENDED that multiple idents be allowed so the same mail can easily go to several users), or it MAY be empty. If the argument field is empty or blank (one or more spaces), the mail goes to a printer or another designated place for site mail 🖨️ A NIC ident refers to the standard identification in the NIC Directory of Network Participants. A serving host MAY keep a table that maps NIC idents to system idents, although NIC idents are NOT REQUIRED in the implementation. A system ident is the user's normal identification at the serving host. Using system idents lets a network user send mail to people who don't have a NIC identification but whose system ident is known 🧸
Mail (MAIL) - This lets a user send mail that isn't in a file, over the TELNET connection. The argument field MAY contain one or more system or NIC idents, or it MAY be empty. The idents work the same as they do for MLFL. After the MAIL command comes in, the server treats the following lines as the text of the mail. The mail text ends with a line containing only a single period, which is the character sequence .CRLF on a new line 📬 It's suggested that a modest volume of mail service should be free, so it MAY be entered before a USER command 💜
IV.A.4 Miscellaneous Commands 🦋
NoOP (NOOP) - This doesn't change any parameters or previously entered command. The server just sends a no-op reply 😴
Quote (QUOT) - This lets the user talk directly to the FTP-server 🗣️ After this command is parsed, the user-FTP process passes along all following lines without checking them, until the NQUO command shows up. In between, the server responds appropriately to its implementation and to the user's requests.
NoQuote (NQUO) - This sends the user and server processes back to normal interactive mode. QUOT and NQUO both have reply codes that the server process sends to the user process, so they agree on what mode they're in 🎀
The quote commands are a super handy way to test server-implemented experimental commands. Those names SHOULD begin with an X, and they can be listed in the system HELP reply ⭐ It should be noted that the official command set is expandable, and suggestions SHOULD go first to Alexander A. McKenzie (BBN) 🌈
IV.B FTP Replies 💌
okay so the server sends FTP replies back over the TELNET connection whenever a user sends an FTP command 📨. they're basically the server going "got it" ✅, "all done" 🎉, or "oops, that broke" 💀. they're formatted so both humans AND programs can read them 🤓
single line replies are a three-digit numeric code, a space, then a one-line text explanation. for multi-line replies, the first line has the code right next to a "-" (hyphen, Code 55 (octal)) and maybe some text. every continuation line except the last is constrained not to begin with three digits 🙈 and the last line MUST repeat the numeric code of the first line and be followed immediately by a space ✨
example, bestie 🎀
100-First Line
Continuation Line
Another Line
100 Last Linethe numeric codes are assigned in groups, and they're designed to be easy for programs to read, in a way that's consistent with other protocols like the RJE protocol 🧚 the three digits get read like this:
a) the first digit tells you the type of response 🔥
000 These replies are purely informative and constitute neither a
positive nor a negative acknowledgment.
1xx Informative replies to status inquiries. 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 correctly fulfilling it.
5xx Incorrect or illegal command. The command or its parameters
were invalid or incomplete from a syntactic viewpoint, or the
command is 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 refers to 💅
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 results.
x7x-x9x Reserved for future expansion.c) the final digit is the particular message type 🫶 since the code is built for an automation process to interpret, it's not necessary for every variation of a reply to have its own 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 that's ended by a numeric code and CRLF (or a group of text lines bounded by coded lines) and sent by the server is meant to be a complete reply message. it should be noted that the text of replies is meant for a human user. only the reply codes, and in some cases the first line of text, are meant for programs 🙈
the assigned reply codes for FTP are:
000 General information message (site, time of day, etc.).
010 Message from system operator.
030 Server availability information.
050 FTP commentary or user information.
100 System status reply.
110 System busy doing...
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.
233 User is "logged out". Parameters reinitialized.
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 a decimal integer representing
the server socket for data connection
256 Mail completed.
300 Connection greeting message, awaiting input.
301 Current command incompleted (no CRLF for long time).
330 Enter password
331 Enter account (if account required as part of login
sequence).
350 Enter mail, terminate by a line with only a '.'
400 This service not implemented.
401 This service not accepting user now, goodbye.
430 Log-on time or tries exceeded, goodbye.
431 Log-on unsuccessful. Usre and/or password invalid.
432 User not valid for this service.
433 Cannot transfer files without valid account. Enter account.
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.
454 FTP: Cannot connect to your data socket.
455 FTP: File system error not covered by other reply codes.
456 FTP: Name duplication rename failed.
457 FTP: Transfer parameters in error.
500 Last command line completely unrecognized.
501 Syntax of last command is incorrect.
502 Last command incomplete, parameters missing.
123456789012345678901234567890123456789012345678901234567890123456789012
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.
507 Catchall error reply.
550 Bad pathname specification (e.g., syntax error).V. DECLARATIVE SPECIFICATIONS 📜
so FTP can work without a pile of needless error messages, the following minimum implementation is REQUIRED for servers 🎀
TYPE -- ASCII (with 8-bit bytes)
MODE -- Stream
STRUCTURE -- File
Record (with ASCII type and CRLF for EOR)
FORM -- Unformatted
COMMANDS -- USER, BYE, SOCK
TYPE, BYTE, MODE, STRU, FORM
for the default values
RETR, STOR
NOOPthe initial default values for transfer parameters are:
TYPE -- ASCII
BYTE -- 8
MODE -- Stream
STRU -- File
FORM -- UnformattedV.A Connections 🦋
the server-FTP process at the server site SHALL "listen" on Socket 3, through its server-TELNET 🔌 the user (or user-FTP process) at the user site starts up the full-duplex TELNET connections through its user-TELNET by doing the ARPANET standard initial connection protocol (ICP) to server socket 3. Servers MAY specify that interaction over the TELNET connections is line-at-a-time with local echo. the server isn't on the hook to provide remote echo and MAY ignore TELNET control characters, but it SHOULD NOT send back an error response for those 🙈 all editing of command lines has to happen locally too. the user site SHALL close the TELNET connections once it's finished using them and has received the last server reply 💖
the user site MUST "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 the 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 the user MAY ensure the security of the data transfer 🔐 this can be done at any time before the first data transfer over a data connection. it SHOULD be emphasized that the user-FTP SHOULD NOT wait for a 255 (server data socket) reply before doing the "listen", since there's no guarantee that the reply arrives before the user site receives the initiating RFC 😭 the security check can happen when the reply arrives, and the data connection gets closed if it was made to a socket other than the one specified.
the data connection SHALL be closed by the server site under the conditions described in Section III.A. if the server wants to close the connection in modes where that is not REQUIRED, it is RECOMMENDED that the close be sent immediately after the file transfer is completed, rather than after a new transfer command is received, because the user or server MAY have to test the state of the socket before doing a "listen" or "init" 🧠 the server SHOULD in general send a reply before closing the data connection to avoid problems at the user end. though, for the reasons stated above, the user-FTP SHOULD NOT wait for that reply before doing its close 💅
V.B. Commands
okay so commands are just ASCII character strings sent over the TELNET connections, like we covered in section IV.A 💖. What each command actually does gets explained in sections IV.A.1, IV.A.2, IV.A.3, and IV.A.4 ✨. This section is where the syntax lives 🎀.
Every command starts with a command code and then an argument field. Command codes are four or fewer ASCII alphabetic characters, and upper and lower case get treated the exact same way. So all of these count as the retrieve command 🦋:
RETR Retr retr ReTr rETrSame vibe for parameter values, like A or a for ASCII TYPE 💅. The command code and the argument fields are separated by one or more spaces.
The argument field is a variable-length ASCII string that ends with the CRLF sequence (Carriage Return immediately followed by Line Feed) 🫶. In the syntax part, every character in the argument field is ASCII, so a decimal integer shall mean an ASCII represented decimal integer. The digits are written out as ASCII characters, bestie 🔥.
Here are all the FTP commands that are currently defined (every single one, no cap) 👑:
USER <username> CRLF
PASS <password> CRLF
ACCT <acctno> CRLF
REIN CRLF
BYE CRLF
BYTE <byte size> CRLF
SOCK <HOST-socket> CRLF
LSTN <direction> CRLF
TYPE <type code> CRLF
FORM <form code> CRLF
STRU <structure code> CRLF
MODE <mode code> CRLF
RETR <pathname> CRLF
STOR <pathname> CRLF
APPE <pathname> CRLF
ALLO <decimal integer> CRLF
REST <marker> CRLF
RNFR <pathname> CRLF
RNTO <pathname> CRLF
ABOR CRLF
DELE <pathname> CRLF
LIST <pathname> CRLF
NLST <pathname> CRLF
STAT <pathname> CRLF
HELP <string> CRLF
MLFL <users> CRLF
MAIL <users> CRLF
NOOP CRLF
QUOT CRLF
NQUO CRLFThe syntax of those argument fields is written in BNF notation where it applies 🧚. Here it is, exactly as the spec has it:
<username> ::= <string>
<password> ::= <string>
<acctno> ::= <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 0 and (2**32)-1
<direction> ::= S/R
<form code> ::= U/P
<type code> ::= A/E/I/L
<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 the default).
<users> ::= <user>|<user,<users>
<user> ::= <empty>|<NIC ident>|<sys ident>
<NIC ident> ::= <string>
<sys ident> ::= <string>V.C. Sequencing of Commands and Replies
Think of the user and the server as taking turns, like a little ping-pong match 🏓. The user sends an FTP command, and the server fires back a prompt primary reply. The user should wait for that first primary success or failure response before sending any more commands 🛑.
A second type of reply doesn't wait around for your command. It's sent asynchronously, so it can show up whenever. These replies can report on how a file transfer is going or whether it's finished, which makes them secondary replies to the file transfer commands 📦.
The third class is informational and spontaneous. These replies can arrive at any time, and they're listed below as spontaneous ✨.
Here's the command-reply correspondence table, copied exactly as written 📋:
COMMAND-REPLY CORRESPONDENCE TABLE
COMMAND SUCCESS FAIL
------- ------- ----
USER 230,330 430-432,500-505,507
PASS 230,331 430-432,500-507
ACCT 230 430-432,500-507
REIN 232,233 401,436,500-507
Secondary Reply 300
BYE 231,232 430-432,500-505,507
BYTE 200,331 500-507
SOCK 200,331 500-505,507
LSTN 255,331 500-507
TYPE 200,331 500-507
FORM 200,331 500-507
STRU 200,331 500-507
MODE 200,331 500-507
RETR 250,331 433,450,451,454,455,500-505,507,550
Secondary Reply 252 452
STOR 250,331 433,451,454,455,457,500-505,507,550
Secondary Reply 252 452,453
APPE 250,331 433,451,454,455,457,500-507,550
Secondary Reply 252 452,453
ALLO 200,331 500-507
REST 200,331 500-507
RNFR 200,331 433,450,451,455,500-507,550
RNTO 253,331 433,450,451,455,456,500-505,507,550
ABOR 201,202,331 500-507
DELE 254,331 433,450,451,455,500-507,550
LIST 250,331 433,450,451,454,455,457,500-507,550
Secondary Reply 252 452
NLST 250,331 433,450,451,454,455,457,500-507
Secondary Reply 252 452
STAT 100,110,150, 450,451,454,455,500-507,550
151,331
HELP 000,030,050, 500-507
331
MLFL 250,331 433,450,451,454,455,457,500-507
Secondary Reply 252 452,453
MAIL 331,350 433,450,451,455,500-507
Secondary Reply 256
NOOP 200 500-505,507
QUOT 200,331 500-507
NQUO 200 500-505,507
Spontaneous 0xx,300,301 400,401,434-436
Replies 251,255V.D. Typical FTP Scenarios
1. TIP user wants to transfer a file from HOST X to a local printer 🖨️
a) The TIP user opens TELNET connections by ICP to HOST X, socket 3 🔌.
b) These commands and replies get 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 completedc) HOST X closes the TELNET and data connections 👋.
Note: The TIP user should be in line mode. 🎀
2. User at HOST U wants to transfer files to/from HOST S 🗂️
Usually the user talks to the server through a mediating user-FTP process 🤝. The user-FTP prompts are shown in parentheses. '---->' means commands going from HOST U to HOST S, and '<----' means replies coming back from HOST S to HOST U. Here's a typical scenario, and it's giving very organised vibes 💅:
Local Commands by User Action Involved
---------------------- ---------------
ftp (host) multics CR ICP to HOST S, socket 3,
establishing TELNET connections.
username Doe CR USER Doe CRLF ---->
<---- 330 password CRLF
password mumble CR PASS mumble CRLF ---->
<---- 230 Doe logged in. CRLF
retrieve (local type) ASCII CR
(local pathname) test 1 CR User-FTP opens local file in ASCII.
(for.pathname) test.p11 CR RETR test.p11 CRLF
<---- 255 SOCK 1233 CRLF
Server makes data connection to (U+4).
<---- 250 File transfer starts CRLF
<---- 252 File transfer complete CRLF
type ImageCR TYPE I CRLF ---->
<---- 200 Command OK CRLF
byte 36CR BYTE 36 CRLF ---->
<---- 200 Command OK CRLF
store (local type) image CR
(local pathname) file dump CR User-FTP opens local file in Image.
(for.pathname) >udd>cn>fd CR STOR >udd>cn>fd CRLF ---->
<---- 451 Access denied CRLF
terminate <---- 231 Doe logged out CRLF
Server closes all connections. [ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Via Genie 03/00 ]📦 where this page comes from
- ietf: rfc454 1973-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms