RFC 624

Comments on the File Transfer Protocol 🎀

Okay bestie, this one is a hit list for FTP 💅. It was written in February 1974 by Mark Krilanovich (UCSB), George Gregg (UCSB), Wayne Hathaway (AMES-67), and Jim White (SRI-ARC) 🌸. The NIC number is #22054, it references RFC 542 (the FTP spec they're critiquing), and it obsoletes RFC 607 😭. RFC 607 got released by accident while it was still a rough draft, so the authors want everyone to ignore it and treat this doc as their real opinions 💖. The header doesn't state a category, so I'm not inventing one 🙈.

This document replaces RFC 607, which got inadvertently released while still in rough draft form. Please disregard RFC 607 and consider this one the accurate statement of the authors' opinions ✨.

There are several aspects of the File Transfer Protocol of RFC 542 that are seriously problematic 💀. Some are basic and would need big design changes, and those will get covered in a later RFC 🔥. Others could be fixed with very little effort, and they should be fixed ASAP 🫶.

Here's the list of the easy-fix problems, plus their proposed solutions 🦋.

1. Once a server has been set to "passive" for data connections, there's no convenient way for the user to make it "active" again 😤. The REIN command does this, but it changes way more than just the active/passive state. SOLUTION: define a new command with the verb ACTV, meaning the server should issue a CONNECT instead of a LISTEN on the data socket. If the server is already "active", the command is a no op. ACTV should have the same reply codes as PASV ✨.
2. Designing an FTP server or user would be simpler if every command verb was the same length 🧚. Varying lengths are possible to handle, but fixed-length string manipulation is generally easier to write and faster to run, and nothing seems to be gained by allowing varying lengths here 💅. SOLUTION: replace the only three-letter verb, BYE, with a four-letter one such as QUIT, and constrain future command verbs to be four letters long 🍓.
3. The order of the handshaking elements after a file transfer command is unspecified 😵‍💫. After sending STOR, for example, a user process has no way of knowing whether to wait for the 250 FILE TRANSFER STARTED reply or for the data connection to be established 🙃. SOLUTION: specify that the server sends a 250 reply before attempting to establish the data connection. If it's desired to check whether the user is logged in, whether the file exists, or whether the user is allowed access to the file, those checks must be made before any reply is sent 🔐. The text of the 250 reply would perhaps be more appropriate as 250 OPENING DATA CONNECTION, since it comes before the actual data transfer begins 🎀. If the server wants to send an error reply in the event that the data connection can't be opened, it's to be sent in lieu of the 252 TRANSFER COMPLETE reply 🚫.

page 1

4. Some hosts send an error reply when they get a command they haven't implemented because it's not needed, like ACCT or ALLO 😭. Even though the reply text says the command was ignored, a user process obviously can't tell that there's no real "error" 🙈. SOLUTION: require that any server that doesn't support a particular command because it isn't needed on that system must return the success reply for that command 💖.
5. There's no specified maximum length for a TELNET command line, a TELNET reply line, a user name, a password, an account, or a pathname 🌈. Every FTP server surely has different maxima for its own parameters, but for the writer of an FTP user (who has to talk to lots of FTP servers), building an indefinite-length buffer is inconvenient, at least on some systems 😩. Server FTP writers have similar trouble 🫠. SOLUTION: specify a maximum length for TELNET command lines, TELNET replies, user names, passwords, account numbers, and pathnames. This should be done after conducting a Poll of serving sites about their individual maxima 📊. If Network mail is to be included in FTP, the mail text, if sent over the TELNET connection, is subject to the same line length maximum 💌.
6. Letting continuation lines start with arbitrary text solves a minor problem for a few server FTP implementors and creates a major problem for all user FTP implementors 💀. Decoding a multi-line reply is unnecessarily complex, and it gets an order of magnitude worse because multi-line replies are allowed to be nested 🌀. SOLUTION: assign a unique (numeric) reply code, such as 009, to be used on all lines of a multi-line reply after the first 🎯. The reply code used for this must begin with 0 (it can't be three blanks, for example), so that it appears extraneous to a user process because of the existing rules about reply code groupings 🧠.
7. If the solution to (6) above isn't accepted, the fact that the maximum allowed level of nesting is unspecified creates a hardship for user FTP implementors 😖. This hardship is somewhat easy to solve on a machine with hardware stacks, but not on other machines 🖥️. SOLUTION: either disallow nested replies (preferred), or specify a maximum level of nesting of multi-line replies 🫶.
8. The prose descriptions of the various reply codes are unclear or ambiguous in several cases 🤔. For example, the code 020 is explained only as "announcing FTP". It's given as a reply that can be issued when a server can't accept input immediately after an ICP, but its exact meaning isn't obvious 😵. Also, the code 331 is said to mean "ENTER ACCOUNT (if required as part of login sequence)", but it's listed as a possible success reply for most of the commands 🙃. The explanation says it's only valid in the login sequence, but the command-reply correspondence table implies it also means "I can't do that without an account" 🎭. SOLUTION: those who originated the reply codes should put in an expanded effort to define them more completely 📚.

A major complaint about the protocol is that the writer of an FTP user process has to handle a ton of special cases just to figure out whether the last command was successful 😩. It's admitted that the protocol is well-defined in all the areas below, but "well-defined" is necessary, not sufficient, and for many reasons it's very desirable to use the simplest mechanism that meets all the needs 💅. Here's the list of drawbacks that overcomplicate the flow chart of an FTP user process 🧜‍♀️.

9. Different commands have different success reply codes 🙄. A successful USER command returns a 230, whereas a successful BYTE command returns a 200. The stated idea that the first digit carries this information doesn't hold, since 100 means success for STAT and 200 means success for SOCK 💀. SOLUTION: any command must return a reply code beginning with some unique digit, such as 2, if successful, and anything other than that digit if not. For example, this includes changing the success reply for STAT, perhaps to 200 ✨.
10. Some commands have multiple possible success reply codes, like USER and REIN 🌸. It's annoying for an FTP user to have to keep a list of reply codes for each command, all of which mean "command accepted, continue" 😤. Again, the first-digit idea fails, since 230 and 330 are both acknowledgments of a successful USER command 💔. SOLUTION: same as for (9) above 🫶. The wish to communicate more specific information than just "yes" or "no" (for example, some servers don't need all the login parameters) can be solved by having 230 mean PASSWORD ACCEPTED, YOU ARE NOW LOGGED IN, and 237 mean PASSWORD ACCEPTED, ACCOUNT NOW NEEDED 🔑. Given the solution to (4) above, a user process becomes much less interested in the difference between "YOU ARE NOW LOGGED IN" and "ACCOUNT NOW NEEDED" 🙌. The important part is that "command accepted" is conveyed by the initial 2, and finer gradations of meaning can be deduced by the user process if it wants them 🧠.
11. The meanings of the connection greeting reply codes are kind of inconsistent 😬. 300 connection greeting, awaiting input, if it's meant as a positive acknowledgment to the ICP, should be a 200-series reply. If it's meant to be purely informative, it should be a 000-series reply. If it's the former, then 020 expected delay is the matching negative acknowledgment and should be a 400-series reply 🧩. It's unlikely that a notification of an expected delay would matter to a user process without knowing how long the delay is 🕰️. SOLUTION: change 300 connection greeting to a 000-series reply, perhaps 011 (preferred), or change 300 connection greeting to a 200-series reply, perhaps 211, and 020 expected delay to a 400-series reply, perhaps 411 🌈.

page 2

In addition to the weaknesses above, the following is believed to be a typographical error 📝.

12. Reply code 332 LOGIN PLEASE isn't listed anywhere in the command-reply correspondence table 🙈. It would seem this should be a more-information-needed (success) reply for all the commands that require the user to be logged in 🔐. It should also be stressed that the 332 code is to be used for this purpose, since many servers currently use other codes, like 451 and 504, to mean LOGIN PLEASE 😭🫶.

page 3