RFC 686

Leaving Well Enough Alone 🎀

Okay so the title block first 💅 This is RFC 686, from the Network Working Group, written by Brian Harvey at SU-AI (NIC 32481) and dated 10 May 1975. It references RFCs 354, 385, 630, 542 and 640. The header doesn't list a category, and it doesn't say it obsoletes or updates anything. Now let's get into the tea ☕🫶

Brian recently decided it was time to overhaul the FTP user and server programs. This was his very first venture into network protocols 🦋 and he quickly found that there was a LOT his team was doing wrong, plus a few things that everyone was doing differently from each other 😭 When he asked about it, some people basically said "Oh, you're running version 1!" 🙄

Here's the vibe though: as far as he can tell, every network host except one is running version 1, and they're basically transferring files just fine ✨ So honestly, an unused protocol sitting on paper shouldn't stop us from keeping the current one, unless there's a good reason to believe the new one is either coming soon or strongly better, or both 💖 (Brian knows FTP-2 took a ton of thought and effort from people who are way bigger network experts than him, and he says it isn't nice to propose junking all that work. He apologizes for it 🥺🫶) Okay, so let's go through what he thinks are the main differences between FTP-2 and FTP-1, and how they'd actually impact the world 👑

1. FTP-2 uses TELNET-2. The big selling point of the new Telnet protocol is that it allows flexible negotiation about things like echoing. But for FTP, the communicators are computer programs, not people, and they don't want any echoing anyway 💀 The argument that new hosts might not know about old Telnet seems pretty unlikely for quite some time. And if TELNET-2 ever does really take over the world, FTP-1 could be implemented in it 🧚
2. FTP-2 straightens out the "print file" mess. Brian thinks this is more of a mess on paper than in practice 📄 The protocol document is confusing on the subject, but he thinks it's perfectly obvious what to do. If the user specifies, and the server accepts, TYPE P (ASCII print file) or TYPE F (EBCDIC print file), then the data sent over the network should contain Fortran control characters. So the source file should contain Fortran controls and be sent over the net as is. It should get reformatted if necessary, but not by the SERVER like the protocol says. It should be reformatted by the RECIPIENT (server for STOR, user for RETR) 🔥 As a non-Fortran-user, Brian admits he might be missing something, but he doesn't think so. It's just like the well-understood TYPE E, where the data is sent in EBCDIC and the recipient can format it for local use however they want 💅

Nobody reformats a file from ASCII to EBCDIC at the sending end 🙅‍♀️ Maybe the confusion happened because the protocol authors had in mind using these types to send files straight to a line printer at the server end. And honestly, maybe that's all they're good for, and nobody's user program will implement TYPE P RETR. Either way, using a two-dimensional scheme to specify the combinations of ASCII/EBCDIC and ASA/normal conveys no more information than the present A-P-E-F scheme. If there's any straightening out to do in FTP-2, it could only be in how these files are handled once the negotiation is settled, not in the negotiation process itself 🎀

3. FTP-2 approves of the Network Virtual File System concept even though it doesn't actually implement it. Brian thinks the NVFS notion is full of pitfalls, and the least of them is the problem of incompatible filename syntax 😬 For example, you'd want to be able to do random access over the network, which means different systems have to find a way to accommodate each other's rules about record sizes and so on. Anyway, FTP-2 doesn't really use NVFS. He only mentions it because RFC 542 does 🦋
4. FTP-2 reshuffles reply codes somewhat. The reply codes in the original FTP-2 document, RFC 542, don't address what Brian sees as the real reply code problems 🙄 The increased specificity doesn't seem like much of a virtue. If a rename operation fails, it's the human user, not the FTP user program, who needs to know it failed because of a name conflict rather than some other file system error. Brian is all for putting that kind of info in the text part of FTP replies ✨ Some real problems are addressed in the reply code revision of RFC 640, where the basic scheme for assigning reply code numbers is more rational than either the FTP-1 scheme or the original FTP-2 scheme. But Brian thinks most of the benefits of RFC 640 can be obtained without requiring cataclysmic reprogramming. More on this below 👑
5. FTP-2 was established by a duly constituted ARPAnet committee, and we are duty-bound to implement it. Brian doesn't suppose anyone would actually put it that baldly, but he's heard things that amounted to exactly that. It's silly 💀
6. FTP-2 specifies default sockets for the data connection. Most places already use the default sockets anyway, and it's easy enough to ignore the 255 message if you want to. This is a security issue, of course 🔒 Brian's afraid he can't work up much excitement about helping the CIA keep track of what anti-war demonstrations he attended in 1968, or which Vietnamese hamlets to bomb for the greatest strategic effect, even if they pay his salary indirectly 💀 He says he could rave about this for pages, and probably will if he ever gets around to writing an argument against MAIL-2. For now, though, he needs to get one anecdote off his chest 😭

Brian has access to an account at an ARPAnet host, because he's responsible at his own site for local maintenance of a program written and maintained by someone at the other site. But the other site doesn't really trust outsiders (the account is shared by people in Brian's position at several other hosts) to protect their vital system security. So every week they run a computer program to generate a new random password for the account (last week's was HRHPUK) and notify everyone by network mail 📬 Well, on Brian's system and at least one of the others, that mail isn't read protected. He deletes his mail when he reads it, but since it's hard enough remembering HRHPUK without them changing it every week, he naturally writes it in a file on their system. That file could in principle be read protected, but it isn't, because sometimes Brian is in someone else's office when he wants to use it. Plus the other passwords in it are for open guest accounts that are widely known 🙈

Moral #1: Security freaks are pretty wierd. 🙃 Moral #2: If you have a secret, don't keep it on the ARPAnet. (In the past week he's heard about two newly discovered holes in Tenex security.) 🫠

7. FTP-2 is available online and FTP-1 isn't, so new hosts can't find out how to do it. Aargh!!! What a reason for doing anything! 😤 Surely it would be less costly for someone to type it in again than for everyone to reprogram. Meanwhile, these new hosts can ask Jon or Geoff or Bobby or even Brian for help getting FTP up 🧚
8. FTP-2 has some changes to the strange MODEs and STRUs. Brian can't get too excited about this one either 🥱 His team only supports MODE S and STR F, and that will probably still be true even if they're forced into FTP-2. If the relatively few people doing very large file transfers need to improve the restart capability, they can do so within FTP-1 without impacting the rest of the crew. The recent implementation of paged file transfers by TENEX shows that problems of individual systems can be solved within the FTP-1 framework. And if the IBM people have a problem with record structure in FTP-1, for example, let them solve it in FTP-1. Whatever the solution is, nobody who isn't affected has to reprogram 🌈

---

Okay so to sum up 🫶 Brian is pretty happy with how well he's been transferring files around the network the way things are. When he does run into trouble, it's usually because some particular host hasn't implemented some particular feature of FTP-1, and there's no reason to think they'll do it any faster if they also have to convert to FTP-2 at the same time. The main thing about FTP-2, as he said at the beginning, is that its existence is an excuse for not solving problems in FTP-1 💅 Some of those problems are pretty trivial, except that people are reluctant to go against anything in the protocol document, as if it were the Holy writ 😇 A few actually require some coordinated effort. So here's Brian's problem list 📝

1. It's almost true that an FTP user program can understand reply codes using this simple algorithm:

a. Replies starting with 0 or 1 should be typed out and otherwise ignored.

b. Replies starting with 2 indicate success (of this step or of the whole operation, depending on the command).

c. Replies starting with 4 or 5 indicate failure of the command.

d. Replies starting with 3 are only recognized in three cases: the initial 300 message, the 330 password request, and the 350 MAIL response. (Note that the user program doesn't need to distinguish which 300 message it got, only whether or not it's expecting one right now.)

The only real problem with this, aside from bugs in a few servers whose maintainers say they're working on it, is the HELP command 🙃 HELP isn't in the original protocol, and it returns 0xx, 1xx, or 2xx depending on the server. (Sometimes more than one message comes back.) One network protocol expert at BBN says that (a) 050 or 030 is the correct response to HELP, and (b) there's a perfectly good mechanism in the protocol for multi-line responses. Unfortunately, that doesn't do much good in dealing with reality 😭 There seems to be a uniform, albeit contra-protocol, procedure for handling the STAT command:

151 information
151 information
151 ...
151 information
200 END OF STATUS

This fits right in with the algorithm above, which is so iconic 💖 The thing is, 1xx is supposed to count as a positive response to a command like STAT. So according to the protocol, it ought to look like this instead:

151-information
information
...
151 information

instead. (Ngl, 050 and 030 aren't good enough as a response to HELP, because they "constitute neither a positive nor a negative acknowledgment" of the HELP command. So they don't tell the user program when it ought to ask the human user what to do next. 🙈) I suggest that, despite the protocol, all servers give a 200 response at the end of whatever other HELP they give as of, let's say, June 1. 💅 The alternatives are either to let the current rather chaotic situation continue forever while we wait for FTP-2, or to try to get everyone standardized on a multi-line 1xx for both HELP and STAT. I'm against changing STAT, which works perfectly for everyone as far as I can tell. And it should be clear that I'm against waiting for FTP-2 😭 There's no real mechanism for "officially" adopting my plan, but I bet if TENEX does it on June 1, the rest of the world will come along. 🚀

2. Another reply code problem is the use of 9xx for "experimental" replies that aren't in the protocol. That includes the BBN mail-forwarding message and one other that I know of. This procedure is sanctioned by RFC 385, but it seems like a bad idea to me. 💀 For one thing, the user program has no way of knowing whether the reply is positive, negative, or irrelevant. The examples I've been burned by should all have been 0xx messages. ✨ I propose that all such messages be given codes in the 000-599 range, chosen to fit the scheme above for interpreting reply codes. x9x or xx9 could be used to indicate experiments. 🧚

3. One more on replies! RFC 630 (the one about the TENEX mod to the reply codes for MAIL and MLFL) raises the issue of "temporary" versus "permanent" failures within the 4xx category. RFC 640 deals with this question in the FTP-2 context by changing the meaning of 4xx and 5xx so that the former are for temporary errors and the latter are for permanent errors. I like this idea a lot 🦋, and I think it could easily be adapted for FTP-1 use in a way that would let people ignore the change and still win. Right now, I believe the only program that tries to distinguish between temporary and permanent errors is the TENEX mailer. For other programs, no distinction is made between 4xx and 5xx responses. Both indicate failure, and any retrials are done by the human user based on the text part of the message. A specific set of changes to the reply codes is proposed below. 🎀

Okay, so, perhaps I should make a few more points about RFC 640, since it's the best thing about FTP-2 and the only argument for it I find at all convincing. Let me try to pick out the virtues of 640 and indicate how they might be achieved in FTP-1. 👑

a. The 3xx category is used uniformly for "positive intermediate replies," where further negotiation in the Telnet connection is required, as for RNFR. I'm afraid this one can't be changed without affecting existing user programs. (One of my goals here is to let existing user programs keep working while some servers continue as they do now and others adopt the suggestions I make below. 🫶) However, although this 3xx idea is logically pleasing, it isn't really necessary for a simple-minded user program to be able to interpret replies. The only really new 3xx in RFC 640 is the 350 code for RNFR. But that would only be a real improvement for the user program if there were also a 2xx code that might be returned after RNFR, and that's not the case. 640 also abolishes the 300 initial connection message in favor of 220, but again, there is clearly no conflict here. 🌸

b. The use of 1xx is expanded to include what is now the 250 code for the beginning of a file transfer. The idea is that a 1xx message doesn't affect the state of the user process, but this is not really true. Consider the file transfer commands. The state diagram on page 13 of RFC 640 is slightly misleading. It appears as if 1xx replies are simply ignored by the user program. In reality, that little loop hides a lot of work: the file transfer itself! 😭 If the server replied to the file transfer command immediately with a 2xx message, it would be a bug in the server, not a successful transfer. The real state diagram is more like

B --> cmd --> W --> 1 --> W --> 2 --> S

(with branches out from the "W"s for bad replies). It should be clear from this diagram that the user program, if it trusts the server to know what it's doing, can expect a 2xx instead of the 1xx without getting confused, since it knows which of the W states it's in. In fact, the use of 1xx in file transfer is very different from its other uses, which are indeed more like the 0xx and 1xx replies in FTP-1. I'd call this particular point a bug in RFC 640. 🐛

c. Automatic programs that use FTP (like mailers) can decide whether to queue or abandon an unsuccessful transfer based on the distinction between 4xx and 5xx codes. I like this idea, although those temporary errors virtually never happen in real life. 🙈 This could be accomplished in FTP-1 by moving many of the 4xx replies to 5xx. Mailers would be modified to use the first digit to decide whether or not to retry. This scheme does not cause any catastrophes. If some server is slow in converting, it merely leads to unnecessary retries. A few CPU cycles would be wasted in the month following the official switch. ⏳ Thus, this feature is very different from (a) and (b), which could lead to catastrophic failures if not implemented all at once. (Yes, I know that FTP-2 is supposed to be done on a different ICP socket. I am not discussing FTP-2 but whether its virtues can be transferred to FTP-1.) The specific codes involved are listed below. 🍓

d. The use of the second digit to indicate the type of message. (The proposed division is not totally clean. For example, why is 150 ("file status okay; about to open data connection") considered to be more about the file system than about the data connection?) This can easily be done, since the second digit is not currently important to any user process. The TENEX mailer is, in this plan, already due for modification because of (c). Since this is mostly an aesthetic point, I'm hesitant to do it if it would be difficult for anyone. In particular, I would want to leave the 25x messages alone, in case some user programs distinguish these. This is especially likely for the ones that are entirely meant for the program: 251 and 255. Therefore I propose that if this idea is adopted in FTP-1, the meanings of x2x and x5x be interchanged. This proposal is reflected in the specific list below. 💜

4. The print file thing again! Let's get it made "official" that it is the recipient, not the server, who is responsible for any reformatting that is to be done on these files. After all, the recipient knows what his own print programs want. 🖨️✨

---

Let me summarize the specific changes to FTP-1 I'd like to see made, most of which are merely documentation changes to reflect reality:

1. HELP should return 200. All commands should return 2xx if successful, and I believe all do except HELP. 💖
2. The definition of 1xx messages should be changed to read: "Informative replies to status inquiries. These constitute neither a positive nor negative acknowledgment." 🌈
3. Experimental reply codes should be of the form x9x or xx9, where the first digit is chosen to reflect the significance of the reply to automated user programs. Reply codes greater than 599 are not permitted. The xx9 form should be used if the reply falls into one of the existing categories for the second digit. User programs are encouraged to determine the significance of the reply from the first digit, rather than requiring a specific reply code, when possible. 🦋
4. The STAT command with no argument is considered a request for a directory listing for the current working directory, except that it may be given along with TELNET SYNCH while a transfer is in progress, in which case it is a request for the status of that transfer. (Everyone seems to do the first part of this. I'm not sure if anyone actually implements the second. This is just getting the protocol to agree with reality. 🙃) The reply to a STAT command should be zero or more 1xx messages followed by a 200. 🌸
5. TYPEs P and F mean that the source file contains ASA control characters and that the recipient program should reformat it if necessary. 🎀

Here is a list of the current FTP-1 replies, and how they should be renumbered for the new scheme. The changes from 4xx to 5xx should be REQUIRED as of June 1. Changes in the second or third digit are not so important. (As explained above, it will not be catastrophic even if some hosts do not meet the requirement.) The list also contains one new possible reply adapted from RFC 640. 🧚‍♀️

okay so we're picking up right where the tea left off 🫖✨ this is the reply code table, and it's giving a whole vintage vibe 🧚 some of these are iconic, some are a little confusing, and a few are straight-up "who wrote this" 💀 the original is bold enough to say so itself, so I'm keeping every line exactly as it was, no edits, bestie 💅

   OLD    NEW     TEXT
   0x0    0x0     (These messages are not very well defined nor
       very important.  Servers should use their judgment.)
   100    110     System status reply.  (Since nobody does STAT
       as in the protocol, this may be a moot point.)
   150    150     "File status reply."  (If this were really that,
       it would be switched to 120, but I believe what is meant is
       the response to a bare STAT in mid-transfer, which is more
       a connection status reply than a file status reply.
   151    121     Directory listing reply.
   200    200     Last command ok.
   201    251     ABOR ok.
   202    252     ABOR ignored, no transfer in progress.
   new    206     Command ignored, superfluous here.
   230    230     Login complete.
   231    231     Logout complete.
   232    232     Logout command will be processed when
       transfer is complete.
   250    250     Transfer started correctly.
   251    251     MARK yyyy = mmmm
   252    252     Transfer completed ok.
   253    223     Rename ok.
   254    224     Delete ok.
   255    255     SOCK nnnn
   256    256     Mail completed ok.
   300    300     Connection greeting
   301    301     Command incomplete (no crlf)
   330    330     Enter password
   350    350     Enter mail.
   400    huh?    "This service not implemented." I don't
       understand this; how does it differ from 506?  If it means
       no FTP at all, who gave the message?  Flush.
   401    451     Service not accepting users now, goodbye.
   430    430     Foo, you are a password hacker!
   431    531     Invalid user or password.
   432    532     User invalid for this service.
   434    454     Logout by operator.
   435    455     Logout by system.
   436    456     Service shutting down.
   450    520     File not found.
   451    521     Access denied.
   452    452     Transfer incomplete, connection closed.
   453    423     Transfer incomplete, insufficient storage space.
   454    454     Can't connect to your socket.
   500    500     Command gibberish.
   501    501     Argument gibberish.
   502    502     Argument missing.
   503    503     Arguments conflict.
   504    504     You can't get there from here.
   505    505     Command conflicts with previous command.
   506    506     Action not implemented.


         [ This RFC was put into machine readable form for entry ]
            [ into the online RFC archives by Via Genie 3/00 ]

that's the whole table, and honestly the "you can't get there from here" line at 504 is my new favourite thing I've read all week 😭🎀

the note at the bottom is just the archive folks saying they converted the doc into machine readable form, so it's not a spec rule, but I'm keeping it because that's what the original says 🌸

---