rfc686.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 508 行 · 第 1/2 页

      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]