From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc686.txt | 507 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc686.txt (limited to 'doc/rfc/rfc686.txt') diff --git a/doc/rfc/rfc686.txt b/doc/rfc/rfc686.txt new file mode 100644 index 0000000..9c983da --- /dev/null +++ b/doc/rfc/rfc686.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group Brian Harvey +Request for Comments: 686 SU-AI +NIC 32481 10 May 1975 +References: 354, 385, 630, 542, 640. + + + Leaving Well Enough Alone + + I recently decided it was time for an overhaul of our FTP user and + server programs. This was my first venture into the world of network + protocols, and I soon discovered that there was a lot we were doing + wrong -- and a few things that everyone seemed to be doing + differently from each other. When I enquired about this, the + response from some quarters was "Oh, you're running version 1!" + + Since, as far as I can tell, all but one network host are running + version 1, and basically transferring files OK, it seems to me that + the existence on paper of an unused protocol should not stand in the + way of maintaining the current one unless there is a good reason to + believe that the new one is either imminent or strongly superior or + both. (I understand, by the way, that FTP-2 represents a lot of + thought and effort by several people who are greater network experts + than I, and that it isn't nice of me to propose junking all that + work, and I hereby apologize for it.) Let me list what strike me as + the main differences in FTP-2 and examine their potential impact on + the world. + + 1. FTP-2 uses TELNET-2. The main advantage of the new Telnet + protocol is that it allows flexible negotiation about things like + echoing. But the communicators in the case of FTP are computer + programs, not people, and don't want any echoing anyway. The + argument that new hosts might not know about old Telnet seems an + unlikely one 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. This is more of a + mess on paper than in practice, I think. Although the protocol + document is confusing on the subject, I think it is 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. That is, 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). As a non-Fortran-user + I may be missing something here but I don't think so; it is just + like the well-understood TYPE E in which the data is sent in + EBCDIC and the recipient can format it for local use as desired. + + + +Harvey [Page 1] + +RFC 686 Leaving Well Enough Alone May 1975 + + + 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 indeed maybe that's all it's good + for and nobody's user program will implement TYPE P RETR. In any + event, 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 is any straightening out of + FTP-2, it could only be in the handling of these files once the + negotiation is settled, not in the negotiation process. + + 3. FTP-2 approves of the Network Virtual File System concept even + though it doesn't actually implement it. It seems to me that the + NVFS notion is full of pitfalls, the least of which is the problem + of incompatibilities in filename syntax. (For example, one would + like to be able to do random access over the network, which + requires that different systems find a way to accommodate each + other's rules about record sizes and so on.) In any case, FTP-2 + doesn't really use NVFS and I mention it here only 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 I see as the + real reply code problems. The increased specificity of reply + codes doesn't seem to be much of a virtue; if, say, 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. + + 5. 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. + + 6. 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 that 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 + + + +Harvey [Page 2] + +RFC 686 Leaving Well Enough Alone May 1975 + + + 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 wierd. 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.) + + 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 me for help in getting + FTP up. + + 8. 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 STR 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 + + + +Harvey [Page 3] + +RFC 686 Leaving Well Enough Alone May 1975 + + + FTP-2 at the same time. The main thing about FTP-2, as I said at the + beginning, is that its existence is an excuse for not solving + problems in FTP-1. Some such problems are quite trivial except for + the fact that people are reluctant to go against anything in the + protocol document, as if the latter were the Holy writ. A few + actually require some coordinated effort. Here is my problem list: + + 1. It is almost true that an FTP user program can understand + reply codes by the following 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, aside from bugs in a few servers + whose maintainers tell me they're working on it, is the HELP + command, which is not in the original protocol and which returns + 0xx, 1xx, or 2xx depending on the server. (Sometimes more than one + message is returned.) The word from one network protocol expert + at BBN is that (a) 050 or 030 is the correct response to HELP, and + (b) there is a perfectly good mechanism in the protocol for + multi-line responses. Unfortunately this does not 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 + + which fits right in with the above algorithm. This is despite the + fact that 1xx is supposed to constitute a positive response to a + command like STAT, so that according to the protocol it ought to + be + + + + + +Harvey [Page 4] + +RFC 686 Leaving Well Enough Alone May 1975 + + + 151-information + information + ... + 151 information + + instead. (It seems to me, by the way, that 050 and 030 aren't + good enough as response to HELP since they "constitute neither a + positive nor a negative acknowledgment" of the HELP command and + thus don't tell the user program when it ought to ask the human + user what to do next.) I suggest that despite the protocol, a 200 + response be given by all servers at the end of whatever other HELP + it gives as of, let's say, June 1. The alternatives are either to + let the current rather chaotic situation continue forever while + waiting for FTP-2, or to try to standardize everyone 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. Unfortunately there + is 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 not in the protocol. This 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 all should have been 0xx messages. I + propose that all such messages be given codes in the 000-599 + range, chosen to fit the scheme given above for interpreting reply + codes. x9x or xx9 could be used to indicate experiments. + + 3. One more on reply: 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, and I + think it could easily be adapted for FTP-1 use in a way which + would allow people to ignore the change and still win. At + present, I believe that the only program which attempts to + distinguish between temporary and permanent errors is the TENEX + mailer. For other programs, no distinction is currently 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 codes is + proposed below. + + + + + +Harvey [Page 5] + +RFC 686 Leaving Well Enough Alone May 1975 + + + 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 enable exiting user programs to work while + some servers continue as now and others adopt the suggestions I + make below.) However, although this 3xx idea is logically + pleasing, it is not 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 this would only + be a real improvement for the user program if there were also a + 2xx code which might be returned after RNFR, which is not the + case. 640 also abolishes the 300 initial connection message + with 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 which 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 + + + +Harvey [Page 6] + +RFC 686 Leaving Well Enough Alone May 1975 + + + 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 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 which 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 which 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 + + + +Harvey [Page 7] + +RFC 686 Leaving Well Enough Alone May 1975 + + + 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. + + 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 + + + +Harvey [Page 8] + +RFC 686 Leaving Well Enough Alone May 1975 + + + 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 ] + + + + + + + + + + + + + + + + + + + + +Harvey [Page 9] + -- cgit v1.2.3