RFC 414

RFC 414 🎀 The Title Block

okay bestie, this one is giving vintage 🧚 It's a Request for Comments numbered 414, and it was put together in the Network Working Group 💖

The author is A. Bhushan from MIT-MAC ✨ The date is 29 November 1972 🍓

This doc updates RFC 354 and RFC 385 🦋 so if you're reading those, you'll want this one next to them. The header doesn't say anything about category, status, or what it obsoletes, so I'm not going to make that up 💅

The rest of the doc comes in part 2 🌈

NIC: 12406

File Transfer Protocol (FTP) Status and Further Comments 🎀

okay so a bunch of HOSTs have working server and user FTPs now 🥹 here's the status of FTP implementations, to the best of my knowledge:

• BBN(A and B), SRI-ARC, UTAH, CASE, USC-ISI, CCA, MIT-AI MIT-Mathlab, MIT-DMCG, CMU, AMES-67, and SU-AI have fully functioning server and user FTPs 💅

MIT-Multics has user and server FTPs, but the server does not listen on socket 3 (you can start it with normal login and the command ftp_server) 🙈 and UCSB will soon have user and server FTPs ✨

the servers at all the TENEX systems are more or less identical (developed by Bob Clements at BBN) 💖 the servers at MIT-AI and MIT-ML are also identical (developed by Pitts Jarvis of MAC) 🧚 others currently involved with FTP include Arvola Chan (AC@MIT-DMCG), Ken Pogran (Multics), Greg Hicks (HICKS@UTAH), Wayne Hathaway (AMES-67), Ralph Gorin (SU-AI), Rick Werme (CMU), and Ron Stoughton (UCSB) 🫶

---

the User-FTP, or the user interface to FTP, is where the desirable and interesting features can go 🦋 a good example is the BBN (and other TENEX) SNDMSG USER@HOST feature, which lets a local user send messages (or mail) to other network users. if the remote host is not up, the message gets stored as --UNSENT-MAIL-- USERHOST in the user's directory, and a background job keeps checking for those files so it can send them later. MIT-AI and MIT-ML have a TRANS command for convenient file transfers 🍓 and at MIT-DMCG, under the "CALICO" subsystem, they built generalized commands that let local users send mail, copy files efficiently, and list users and directories over the network in a way that feels similar to local usage. that means no having to explicitly connect, login, and send commands to a remote HOST 😭 they also let TELNET, FTP, and RJS users automatically "login" and run other command sequences from an "initial" file 👑

it should be noted that file transfer between PDP-10's in "Image 36" is an order of magnitude faster (and more efficient) than in "ASCII 8" 🔥 it's also useful to provide a "Quote" or "talk" mode in user-FTP, so a user can type commands straight to the FTP server (commands that aren't implemented in user-FTP) 💅 and it's desirable that user and server FTP features and useful modes of usage get documented and reported through the RFC mechanism 📜

the following suggestions and additions pertain to the File Transfer Protocol as stated in NWG/RFC 354 and NWG/RFC 385 🌸 once comments on this RFC come in, I'll have the three RFCs combined into a single document and issued as the ARPANET Official File Transfer Protocol, very soon ⭐ but FTP is an open-ended protocol with room for experimentation. new commands, reply codes, data representation types, and file structures may be defined in the future. if two sites agree, they can define their own experimental set of commands, data types, file structures, and/or transfer modes. any additions like that should be well documented and clearly specified, so other sites can use them too 🫶

1) FTP assumes line-at-a-time interaction with local echo. the server is not obliged to provide remote echo, and it may ignore TELNET control characters. a server, however, should not give an error or bad response when it receives TELNET control characters 🙈

the server doesn't explicitly provide any editing capability, like character delete or line kill characters. all editing is assumed to be local 💅 TIP users should use FTP in line mode and send both <CR> and <LF> (using the TIP commands @T O L and @I L). in that mode, a TIP user can flush the current input line with the flush command (@F) ✨

the server should respond to the TELNET "SYNCH" by flushing the current command line and waiting for user input, such as an "ABOR" command. other commands, like "BYE" or "STAT", may also be an acceptable input 🦋

2) commands like "STAT" that produce more than one line of output over the TELNET connection need some way of positively indicating the end of the status information 😤 it's proposed that a "200 status complete" reply give that positive indication. the reply to STAT should begin with a line starting with 1xx (where x=digit), the following lines should not have a digit as their first character, and the status ends with the 200 reply. (note that the requirement of three spaces is dropped in favour of the less restrictive requirement that the first character is not a digit 🎀) this change would make things so much easier for both user and server FTPs 🥹

3) a reminder that BYE<CR><LF> is legal 💖 a space after a command name is not required if there is a null argument ✨

4) the following responses are proposed for the "STAT" and "LIST" commands 🧚 (this wasn't clearly specified, especially for the null argument case). responses to "STAT" and "LIST" shall always be sent over the TELNET and Data connections, respectively. the "LIST" command with a null argument should produce a list of files in the user's current working or default directory. the "STAT" command with a null argument should (as suggested by Wayne Hathaway) produce the status of all file transfer parameters (user, byte, size, data type, transfer mode, and file structure) if it's used between file transfers, meaning no transfer is in progress 🌈 if STAT is sent during a file transfer operation (accompanied by TELNET synch), the server should respond with the status of the operation in progress. and if the argument of the "LIST" and "STAT" commands is a pathname, a list associated with that pathname should be sent 💅

5) two new commands are proposed 👑 first is a "HELP" command, which should send the user helpful hints about using the server and its implementation status (news). the information gets sent over the TELNET connection, starting with a type 100 reply and ending with a type 200 reply (completion). it's suggested that this command, plus the "MAIL" and "BYE" commands, be allowed without the user having to "login" (i.e., supplying a valid user, password, and account) 🔥

the other command, suggested by Bob Clements, is a new directory listing command called "NLST" 🍓 it sends only the names of files (as valid pathname strings separated by CRLF) and none of the other useful but confusing information. that way you can copy a whole directory automatically using this command and the store and retrieve commands 🙌 the syntax and format of this command are identical to the "LIST" command (for some HOSTs they may be identical commands) 🫶

6) the minimum implementation doesn't require the TYPE, BYTE, MODE, and STRU commands 🥺 but it's suggested that even minimum implementations accept these commands with their default values. that would avoid some of the "ugly" error responses to input like TYPE A and STRU F, even though those are perfectly acceptable to the server 💅

7) when using the "MLFL" and "LIST" commands, it's the user's (or user-FTP's) responsibility to make sure the TYPE is ASCII (8-bit bytes) 🙈 if the TYPE is something other than ASCII, the server may send an error response and refuse the command. so the user (or user-FTP) should send the server the TYPE A command, if the type is other than ASCII, before sending the "MLFL" or "LIST" commands 🧚

8) a useful suggestion is to allow multiple user names in the "MAIL" and "MLFL" commands 💖 people often want to send the same mail to a bunch of users at one particular site, and it'd be so convenient to do that in a single transfer and command 🥹 it's strongly urged that server sites implement this option 🔥

9) another suggestion that's been made is to standardize pathname syntax in FTP 🗺️ it looks like subdirectories will soon be introduced in the TENEX system, and that might have some bearing on the standard pathname syntax. any pathname standard should allow convenient use of local pathname conventions, and it shouldn't conflict with them ✨ a reasonable proposal seems to be a standard pathname that starts with a special character such as ">" (as in Multics), and uses that character to separate the elements of a pathname 🦋 if the special character happens to be a valid part of a pathname element, use the literal quote convention of '> (a single quote preceding the special character) 💅 examples of pathnames under this convention:

>udd>CNet>Doe>foo_bar                       (for Multics)
>DSK>JFD>foo bar                            (for ITS)
>DOE>foo.bar1    (for TENEX)

10) the TENEX requirement for account numbers has caused some problems for automatons using FTP, under the present reply code sequences 😤 so two new reply codes are defined to handle the account requirement 🎀 the reply code 331 Enter Account is to be used if an account is required as part of the user "login" sequence. the reply code 433 Cannot store files without valid account. Enter account. is to be used if an account is required only for a particular operation, such as store 🌸

11) the following suggestions from Wayne Hathaway (RFC forthcoming) seem reasonable and should be included in the Protocol 🫶

• i) the End-of-Record condition should be explicit on the last record, and not implied by an End-of-File. this change would simplify server implementation and improve reliability (better error control) 🔥
• ii) implementors of user-FTPs should note that it's trivial for them to implement record structures in ASCII type and Stream mode (the default CRLF convention for end-of-record). all user-FTPs should allow store or retrieve of record structured files with ASCII type and Stream mode 💖
• iii) it's possible to send record structured "print-file" types (in addition to ASCII type) in either stream or text modes. (RFC 354 wasn't clear on this issue) 🧚
• iv) the TELNET synch mechanism should be extended to other commands, such as BYE and STAT, in addition to ABOR 🦋
• v) comments are invited on the desirability of NOOP, CLSE, and SRVR commands 🤔 in Wayne's opinion, a STAT command with a null argument serves the purpose of NOOP (to see if the server is still alive), and BYE serves the purpose of CLSE (the USER command should be used to change user name). SRVR is a useful command 🌈

12) Bob Clements raised the old issue of error detection and control again 😭 to handle this, we can define two new descriptor codes in Block mode: one that signals the start of a block check, and another that indicates the end of a block check (and includes the block check bytes). these codes may be ignored by any site not wishing to implement the error detection scheme 💅 comments on the error check scheme, and on whether it's desirable to include it in FTP, are solicited 🙏✨

[This RFC was put into machine readable form for entry] [into the online RFC archives by Helene Morin, Via Genie, 12/99]