rfc691.txt

RFC 相关的技术文档

   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.                                     5j

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





                                   5

NWG/RFC# 691                                    BH 6-JUN-75 23:15  32700
One More Try on the FTP



   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.)                               5k

   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.                                                    5l

   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.                                                         5m

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
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:    6

   1.  It is almost true that an FTP user program can understand
   reply codes by the following simple algorithm:                     6a

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





                                   6

NWG/RFC# 691                                    BH 6-JUN-75 23:15  32700
One More Try on the FTP



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

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

      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.)                                   6a4

   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
   procedure for handling the STAT command:                           6b

      151 information
      151 information
      151 ...
      151 information
      200 END OF STATUS                                              6b1

   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 RFC 354 it ought to
   be                                                                 6c

      151-information
      information
      ...
      151 information                                                6c1

   instead.  RFC 414, which approves of the 200 reply for STAT, also
   gives 200 for HELP.  (It seems to me, by the way, that 050 and
   030 aren't good enough as responses to HELP since they
   "constitute neither a positive nor a negative acknowledgement" of





                                   7

NWG/RFC# 691                                    BH 6-JUN-75 23:15  32700
One More Try on the FTP



   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 RFC 354, 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.                           6d

   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.    6e

   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 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 is
   proposed below.                                                    6f

   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






                                   8

NWG/RFC# 691                                    BH 6-JUN-75 23:15  32700
One More Try on the FTP



   all convincing.  Let me try to pick out the virtues of 640 and
   indicate how they might be achieved in FTP-1.                      6g

      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 existing 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.              6g1

      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                                     6g2

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