RFC 691

One More Try on the FTP ✨

Brian Harvey 💖 wrote this one from SU-AI, and it's dated May 28, 1975 📅

Re: File Transfer Protocol 🎀

Ref: RFC 354, 385, 414, 448, 454, 630, 542, 640 🧚

Okay bestie, this is a slight revision of RFC 686 💅 The big difference is how it talks about print files. Brian read a bunch of RFCs he (sigh) had never heard of before writing 686, and that made him realize he was right all along, just for the wrong reasons 🙈 He also tidied up the list of reply codes so it matches the four lists in RFCs 354, 454, 542, and 640 more completely. 🦋

Then he drops a little wishlist. If nobody objects before June 1, everyone should treat these as official: HELP should return 200, SRVR should be used the way he describes below, and "permanent" 4xx errors should become 5xx. ✨ Big thanks to Jon Postel, who spent a whole evening helping him sort this out 🫶 (page 2a)

---

Aside from a cry of anguish from the site dealing with the security hassle described below 😭, Brian only got one comment, and it was unfavorable but, alas, unspecific. So he wants to be super clear: he is not trying to step on toes for fun 🙅‍♀️ and he doesn't think the positive FTP-1 changes here are necessarily the best possible thing. What they are, he thinks, is easily doable 💜 The great-FTP-in-the-sky isn't showing any signs of universal acceptability, and it shouldn't block us from fixing immediate problems. 🌈 (page 2b)

Leaving Well Enough Alone 3

Okay so Brian recently decided his FTP user and server programs needed a full glow-up ✨ This was his first venture into network protocols, and he quickly found a lot they were doing wrong. There were also a few things everyone seemed to be doing differently from each other 💀 When he asked about it, some people basically said, "Oh, you're running Version 1!" 🙄 4

Here's the tea 🍵 as far as he can tell, all but one network host are running version 1, and they're basically transferring files just fine. So the fact that an unused protocol exists on paper shouldn't stop us from keeping the current one, unless there's a good reason to believe the new one is imminent, strongly superior, or both 🎀 (page 1)

Brian also knows that FTP-2 took a lot of thought and effort from several people who are way bigger network experts than him 🥺 He says it isn't nice to propose junking all that work, and he apologizes for it. Still, let me list what strike me as

...okay so the main differences in FTP-2 and how much they could actually shake up the world 🌍✨ bestie, let's go 💅

1. FTP-2 uses TELNET-2 🦋 The main glow-up of the new Telnet is that it allows flexible negotiation about stuff like echoing. But the communicators in the case of FTP 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 to come 🙄 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 🖨️✨ There are two separate questions here: what command you give to establish a print file transfer, and which end does what sort of conversion. For the second one, even though all of the FTP-1 documents are confusing on the subject, I think it's perfectly obvious what to do: if the user specifies, and the server accepts, an ASCII or EBCDIC print file transfer parameter sequence, then the data sent over the network should contain Fortran control characters. So the source file should contain Fortran controls, and should be sent over the net as is, and reformatted if necessary not by the SERVER as the protocol says but by the RECIPIENT (server for STOR, user for RETR). (The "Telnet print file" non-issue will be debunked below.)

As a non-Fortran-user I may be missing something, but I don'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 as desired. One never reformats a file from ASCII to EBCDIC at the sending end. Perhaps the confusion happened because the protocol authors had in mind using these types to send files directly to a line printer at the server end, and honestly maybe that's all it's good for, and nobody's user program will implement TYPE P RETR 💀

As for the specific commands used to negotiate such a transfer, there may currently be some confusion because the most recent FTP-1 document on the subject (RFC 454) invents a new command, FORM, which is not in general use as far as I know. (Most of my experiments have been on PDP-10s, so maybe other systems have adopted this command 🤷‍♀️) FTP-2 puts the format argument in the TYPE command as a second argument. 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. FTP-2 also introduces the notion of Telnet formatted vs. non-print files. These types are used when a Telnet format oriented system is sending a file to an ASA oriented one, and the recipient needs to know, not what is coming over the net, but how to solve a local file storage problem. It is unnecessary and unfair for hosts to have to negotiate something which does not actually affect what gets sent over the net. It is unnecessary because the sending user process (there is no problem if the user process is receiving) need not understand what the issue is. It only needs to make the server understand by transmitting a message from the human user to the server process. Any TYPE parameter must be understood by both processes, even if the user treats it just like some other type 🫶

To take a specific example, if I want to send an ASCII file to a 360, my FTP user program needs to have built into it the knowledge that there are two TYPEs which are really the same, AN and AT in the FTP-2 notation. If tomorrow someone needs to know the ultimate use of a binary file (for instance, the old PDP-6 DECtape format stores dump files differently from ordinary data files), I will have to add another piece of information to my FTP user and server (maybe they try to read such a file from me) 😭 Instead, information which affects only the RECIPIENT of a file, and not the format AS SENT OVER THE NET, should be specified in some form which the sending process can ignore. This is what the SRVR command should be used for 🎀

If a user at a 360 wants to retrieve a "Telnet print file" from another system, he might tell his FTP user process something like this:

TYPE A
DISP PRINT
RETR FOO etc.

(or whatever syntax they use in their FTP). If a user at a 10 wants to send such a file to a 360, he would say:

TYPE A
SRVR PRINT
STOR FOO etc.

His FTP user program would send on the SRVR command without comment. Suppose that the transformation is one which might be used in either direction between the same two hosts. (This is not the case for the Telnet print file thing, because two 360s would be using ASA format.) Then the user process could accept the equivalent of DISP PRINT from the user, and if the transfer turned out to be a STOR, it would decide to send SRVR PRINT first. In this way the FTP user program can be written so that the human user types the same command regardless of the direction of transfer 🍓

Thus, FTP servers which care about the distinction between Telnet print and non-print could implement SRVR N and SRVR T. Ideally the SRVR parameters should be registered with Jon Postel to avoid conflicts, although it is not a disaster if two sites use the same parameter for different things. I suggest that parameters be allowed to be more than one letter, and that an initial letter X be used for really local idiosyncrasies 🌸 The following should be considered as registered:

• T - Telnet print file
• N - Normal.
  • Means to turn off any previous SRVR in effect. (This makes "non-print" the default case, rather than making "Telnet print" and "non-print" equal. It is probably a good idea if a user program can count on being able to turn off an earlier SRVR without having to know a specific inverse for it. Servers which do not implement any other SRVR parameters need not implement SRVR N either. User processes shouldn't send SRVR N just for the hell of it 💅)

3. FTP-2 reshuffles reply codes somewhat 🔁 There have been four attempts altogether, that I know of, at specifying a list of reply codes: RFCs 354 and 454 for FTP-1, and RFCs 542 and 640 for FTP-2. There is not much to choose from among the first three of these, which are basically the same, except for a slight increase in specificity each time through, e.g., the introduction of reply code 456 for a rename which fails because a file of the same (new) name already exists. This increased specificity doesn't seem much of a virtue. If a rename operation fails, it is the human user, not the FTP user program, who needs to know that it was because of a name conflict rather than some other file system error. I am all for putting such information in the text part of FTP replies 🙌 Some real problems are actually addressed in the reply code revision of RFC 640, in which the basic scheme for assigning reply code numbers is more rational than either the FTP-1 scheme or the original FTP-2 scheme. However, I think that most of the benefits of RFC 640 can be obtained in a way which does not require cataclysmic reprogramming. More on this below.
4. FTP-2 was established by a duly constituted ARPAnet committee, and we are duty-bound to implement it 🙃 I don't suppose anyone would actually put it that baldly, but I've heard things which amounted to that. It's silly.
5. FTP-2 specifies default sockets for the data connection 🔌 Most places use the default sockets already anyway, and it is easy enough to ignore the 255 message if you want to. This is a security issue, of course, and I'm afraid I can't work up much excitement about helping the CIA keep track of what anti-war demonstrations I attended in 1968, and which Vietnamese hamlets to bomb for the greatest strategic effect, even if they do pay my salary indirectly. I could rave about this subject for pages, and probably will if I ever get around to writing an argument against MAIL-2. But for now let me just get one anecdote off my chest 🫠 I have access to an account at an ARPAnet host because I am responsible at my own site for local maintenance of a program which was written by, and is maintained by, someone at the other site. However, the other site doesn't really trust us outsiders (the account is shared by people in my 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 us all by network mail. Well, on my system and at least one of the others, that mail isn't read protected. I delete my mail when I read it, but since it is hard enough remembering HRHPUK without them changing it every week, I naturally write it in a file on our system. That file could in principle be read protected, but it isn't, since sometimes I'm in someone else's office when I want to use it, and the other passwords in it are for open guest accounts which are widely known.

Moral #1: Security freaks are pretty weird. 🙈 Moral #2: If you have a secret, don't keep it on the ARPAnet. 🔐

(In the past week I have heard about two newly discovered holes in TENEX security. 💀)

6. 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 me for help in getting FTP up 🧚‍♀️
7. FTP-2 has some changes to the strange MODEs and STRUs. This is another thing I can't get too excited about 🥱 We support only MODE S and STRU F, and that will probably still be true even if we are forced into FTP-2. If the relatively few people who do very large file transfers need to improve the restart capability, they can do so within FTP-1 without impacting the rest of us. The recent implementation of paged file transfers by TENEX shows that problems of individual systems can be solved within the FTP-1 framework. If the IBM people have some problem about record structure in FTP-1, for example, let them solve it in FTP-1, and whatever the solution is, nobody who isn't affected has to reprogram 👑

Well, to sum up, I am pretty happy with the success I've had transferring files around the network the way things are ☺️ When I do run into trouble, it's generally because some particular host hasn't implemented some particular feature of FTP-1, and there's no reason to suppose 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 I said at

okay so, like I said at the start, FTP-2 is kinda an excuse for not fixing problems in FTP-1 💅 Some of these are super trivial, except people are weirdly scared to touch anything in the protocol doc, like it's Holy Writ 🙈 A few actually need coordinated effort. Here's my problem list ✨

1. It is almost true that an FTP user program can understand reply codes with 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 need not distinguish which 300 message it got, merely whether or not it is expecting one right now.)

The only real problem with this is HELP, aside from a few buggy servers whose maintainers tell me they're on it 🙏 HELP isn't even in the original protocol, and it returns 0xx, 1xx, or 2xx depending on the server. Sometimes more than one message comes back too 😭 One network protocol expert at BBN says that (a) 050 or 030 is the correct response to HELP, and (b) the protocol already has a perfectly good mechanism for multi-line responses. Unfortunately, that doesn't do much good in dealing with reality 💀

There seems to be a uniform procedure for handling the STAT command 📋:

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

which fits right in with the above algorithm, honestly iconic ✨ The thing is, 1xx is supposed to be a positive response to a command like STAT, so according to RFC 354 it ought to look like this instead:

151-information
information
...
151 information

RFC 414 approves of the 200 reply for STAT, but it also gives 200 for HELP. (And ngl, 050 and 030 aren't good enough for HELP either, since they "constitute neither a positive nor a negative acknowledgement" of the HELP command. So the user program has no idea when it should ask the human what to do next 🙈)

Here's my plan: despite RFC 354, every server should send a 200 response at the end of whatever other HELP text it gives, as of, let's say, June 1 🎀 The other options are letting this chaotic situation go on forever while we wait for FTP-2, or getting everyone to use a multi-line 1xx for both HELP and STAT. I'm against changing STAT, because it works perfectly for everyone as far as I can tell, and it should be obvious 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. This includes the BBN mail-forwarding message and one other that I know of. RFC 385 sanctions this procedure, but it's a bad idea imo 💀 For one thing, the user program has no way of knowing whether the reply is positive, negative, or irrelevant. Every example I've been burned by should have been a 0xx message 😤 So I propose that all such messages get 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 reply codes 🍓: 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 handles this for FTP-2 by changing the meaning of 4xx and 5xx, so the former are for temporary errors and the latter are for permanent errors. I'm obsessed with this idea, and I think it could easily be adapted for FTP-1 in a way that lets people ignore the change and still win 👑 Right now, I believe the only program that tries to tell temporary and permanent errors apart is the TENEX mailer. Every other program makes no distinction between 4xx and 5xx responses. Both just mean failure, and any retries 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, now 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 pick out the virtues of 640 and show 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 stay as they are and others adopt the suggestions I make below.) Honestly, 3xx is logically pleasing, but it isn't really necessary for a simple-minded user program 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 come back after RNFR, which there isn't. 640 also gets rid of the 300 initial connection message in favor of 220, but again, there's clearly no conflict there 🫶
• b. The use of 1xx gets 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 isn't really true 😬 Think about the file transfer commands. The state diagram on page 13 of RFC 640 is slightly misleading. It looks like the user program simply ignores 1xx replies. 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, that would be a bug in the server, not a successful transfer. The real state diagram is more like this:

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 love this idea, although those temporary errors virtually never happen in real life 🥺 This could be done 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 doesn't cause any catastrophes if some server is slow in converting. It just leads to unnecessary retries, and a few CPU cycles get wasted in the month following the official switch 🤷‍♀️ So this feature is very different from (a) and (b), which could lead to catastrophic failures if they aren't all implemented at once. (Yes, I know FTP-2 is supposed to run on a different ICP socket. I'm not discussing FTP-2, I'm asking whether its virtues can transfer 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 isn't totally clean. For example, why is 150 ("file status okay; about to open data connection") considered more about the file system than about the data connection? 🤔) This can easily be done, since the second digit isn't currently important to any user process. The TENEX mailer is already due for modification in this plan because of (c), so that's not a problem. Since this is mostly an aesthetic point, I'm hesitant to do it if it would be difficult for anyone. In particular, I'd 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. So 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 💖

Okay bestie, so here's the glow-up list 💅 The main changes to FTP-1 I want to see are mostly documentation fixes to match what actually happens out there in the wild 🫶 7

1. HELP should return 200. All commands should return 2xx if they succeed, and I'm pretty sure they all do except HELP 🙈 7a
2. The definition of 1xx messages should change to say: "Informative replies to status inquiries. These constitute neither a positive nor a negative acknowledgment." 🌸 7b
3. Experimental reply codes should look like x9x or xx9, where the first digit shows how significant the reply is 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 figure out the significance from the first digit instead of needing a specific reply code, when that's possible ✨ 7c
4. The STAT command with no argument counts as a request for a directory listing of the current working directory. The exception is when it's sent along with TELNET SYNCH during a transfer, and then it asks for the status of that transfer 💜 Everyone does the first part, and I'm not sure anyone actually does the second. This just gets the protocol to agree with reality 😭 The reply to a STAT command should be zero or more 1xx messages followed by a 200. 7d
5. TYPEs P and F mean the source file has ASA control characters, and the recipient program should reformat it if needed 🎀 Servers that care about Telnet-print vs. non-print should implement SRVR T and SRVR N. All user processes should give the human user a way to specify an arbitrary SRVR command 🔥 7e
6. This one just tidies up a loose end in the docs 💀 Nested reply codes are not allowed. Honestly they never happen and couldn't work anyway, and FTP user programs shouldn't have to worry about them 🦋 7f

Here's the list of 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 aren't as important 🍓 As explained above, it won't be catastrophic even if some hosts don't meet the requirement 🫶 The list also has one new possible reply, adapted from RFC 640 ✨ Replies invented in RFC 454 are marked as such. Some of them are for commands mostly not implemented, like REIN, so they might be irrelevant anyway 🙃 7g

   OLD   NEW   TEXT
                                                                     7g1
   0x0   0x0   (These messages are not very well defined nor very





                                   11

                  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.)
   110   111   System busy doing...  (This RFC 454 message could
                  easily be considered an example of the one above,
                  but since the 454 authors want to distinguish it,
                  here it is in another number.)
   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.                                           7g2
   202   252   ABOR ignored, no transfer in progress.
   new   206   Command ignored, superfluous here.
   230   230   Login complete.
   231   231   Logout complete.  (RFC 454: Closing connection.)
   232   232   Logout command will be processed when transfer is
                  complete.                                          7g3
   233   233   Logout complete, parameters reinitialized.  (RFC
   454               for REIN)                                    7g4
   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                                     7g5
   331   331   Enter account (RFC 454)
   350   350   Enter mail.                                        7g6
   400   huh?  "This service not implemented."  I don't
   understand
                  this; how does it differ from 506?  If it means no





                                   12

   FTP
                  at all, who gave the message?  Flush.              7g7
   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.
   433   533   Need account to write files.
   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.            7g8
   453   423   Transfer incomplete, insufficient storage space.
   454   454   Can't connect to your socket.
   455   425   Random file system error (RFC 454)                 7g9
   456   526   Name duplication, rename failed (RFC 454)
   457   557   Bad transfer parameters (TYPE, BYTE, etc) (RFC
   454)
   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.
   507   507   Some other problem.  (RFC 454)
   550   520   Bad syntax in pathname.  (RFC454)                 7g10




















                                   13