rfc686.txt

RFC 相关的技术文档

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