doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

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]
+