RFC 607

RFC 607: Comments on the File Transfer Protocol 🎀

Request for Comments: 607 💖

Authors: Mark Krilanovich and George Gregg 👑

NIC # 21255 🌸

References: RFC #542 UCSB 🦋

Date: January 1974 🍓

Obsoletes or updates: none listed. Category or status: not stated in the original. ✨

Comments on the File Transfer Protocol ✨

okay so the File Transfer Protocol has some seriously big drawbacks 😭 Some of them are basic enough that they'd need major design changes, and those get their own RFC later, bestie. Others could be fixed with almost no effort, and we should do those asap 💅

Here's the list of the easy-to-fix problems, with their proposed solutions:

Quick Fixes 🧚

1. 😤 Once a server has been told to go "passive" for data connections, the user has no way to make it "active" again. The fix is a new command with the verb ACTV 🦋. It tells the server to issue a CONNECT instead of a LISTEN on the data socket. If the server is already "active", ACTV is a no op. ACTV gets the same reply codes as PASV.
2. 📏 Servers would be simpler to build if every command verb had the same length. Users would be simpler to build if either that were true or if multiple blanks were allowed after the verb. The fix: swap the only three-letter verb, BYE, for a four-letter one like QUIT, and make future command verbs four letters long ✨
3. 🤔 The order of the handshaking bits after a file transfer command is never specified. After STOR, a user process has no clue whether to wait for the 250 FILE TRANSFER STARTED reply first or for the data connection to be established. The fix: the server sends a 250 reply before it tries to establish the data connection. If it wants 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 250 text might be more appropriate as 250 OPENING DATA CONNECTION, since it shows up before the actual data transfer begins. And if the server wants to send an error reply because the data connection couldn't be opened, that error goes in lieu of the 252 TRANSFER COMPLETE reply 🫶
4. 🙃 Some hosts send an error reply when they get a command that's unimplemented because they don't need it, like ACCT or ALLO. Even though the reply text says the command was ignored, a user process can't possibly know that there's no real "error". The fix: any server that doesn't support a particular command because it isn't needed on that system must return a success reply 💖
5. 📐 There's no specified maximum length for a TELNET line, user name, password, account, or pathname. Sure, every FTP server probably has its own limits, but it's nearly impossible for the writer of an FTP user (who has to talk to lots of FTP servers) to build an indefinite length buffer 😩 Some arbitrary maximum has to be picked. The fix: specify a maximum length for TELNET lines, user names, passwords, account numbers, and pathnames. This should happen after polling serving sites about their individual maxima 🌈
6. 🧵 Letting continuation lines start with arbitrary text fixes a minor problem for a few server implementers, but creates a major problem for every user FTP implementer. The logic to decode a multi-line reply is unnecessarily complex, and it gets an order of magnitude worse because multi-line replies can be nested. The fix: assign a unique numeric reply code, such as 009, to be used on all lines of a multi-line reply after the first 💅
7. 🪜 Since multi-line replies can be nested, leaving the maximum nesting level unspecified makes life hard for user FTP implementers. It's kinda easy to handle on a machine with hardware stacks, but not so much on other machines. The fix: specify a maximum level of nesting for multi-line replies 🔥
8. 🕳️ In blocked mode, the protocol says "all end-of-record markers (EOR) are explicit, including the final one." That bans sending data between the final end of record and the end of file, but it doesn't say what the receiver should do if someone breaks that rule. Should the stray data get discarded, or treated as a new (final) record? The fix: if an end-of-file marker isn't immediately preceded by an end-of-record marker, the intervening data is to be discarded 👀

A major complaint 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 following areas, but "well-defined" is necessary, not sufficient. For lots of reasons, it's very desirable to use the simplest mechanism that meets all the needs. Here are the drawbacks that unnecessarily complicate the flow chart of an FTP user process:

The Reply Code Mess 🌸

9. 🎭 Different commands have different success reply codes. A successful USER returns a 230, but a successful BYTE returns a 200. The idea that success replies start with an even digit and failures with an odd digit doesn't hold up, since 100, means success for STAT, and 402 means failure for BYTE. The fix: 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 successful 💅
10. 📋 Some commands have several possible success reply codes, like USER, REIN, and BYE. It's a pain for a user to keep a list of reply codes for each command that all mean "command accepted, continue" 🙄 The fix is the same as for 9 above. If you want to say more than just "yes" or "no", like how some sites don't need all the login parameters, you can have, for example, 238 mean PASSWORD ACCEPTED, YOU ARE NOW LOGGED IN, and 237 mean PASSWORD ACCEPTED, ACCOUNT NOW NEEDED. The big point is that "command accepted" is conveyed by the initial 2, and the user process can figure out the finer shades of meaning if it wants ✨
11. 🙈 Some replies are basically extraneous from the point of view of a user FTP process, and their codes don't have anything that makes them easy to spot. For example, 010 message from operator and 050 FTP commentary are superfluous to a user process, and 000 announcing FTP (in place of the 300 greeting) is not. The fix: any reply that only means something to a human user and not to a user process must have a reply code beginning with a unique digit, such as 0. The continuation line reply code proposed in (8.) above falls into this category, so it must start with that same unique digit 🫶
12. 🔁 Having a server send 000 announcing FTP or 020 expected delay right after the ICP completes, if input can't be accepted right away, is another case of multiple reply codes meaning the same thing to a user process. The fix: require that the server send a reply with the 020 reply code in the situation cited. If you want to communicate more detailed info, the reply text may used for this purpose 🦋

In addition to the weaknesses above, the following is believed to be a typo:

The Typo 👀

13. 🐛 Reply code 331 is cited as a possible success reply code for the commands BYTE, SOCK, PASV, TYPE, STRU, MODE, ALLO, REST, SITE, AND STAT. This reply code means ENTER ACCOUNT (if required as part of the login sequence), and perhaps should be 332 LOGIN FIRST, PLEASE. This is especially obvious because 332 isn't listed anywhere in the command-reply correspondence table 🌈