rfc691.txt

RFC 相关的技术文档

      (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.                        6g3

      c.  Automatic programs which use FTP (like mailers) can decide





                                   9

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



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

      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 the 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.                          6g5

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

   1.  HELP should return 200.  All commands should return 2xx if
   successful, and I believe all do except HELP.                      7a

   2.  The definition of 1xx messages should be changed to read:
   "Informative replies to status inquiries.  These constitute
   neither a positive nor a negative acknowledgment."                 7b






                                   10

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



   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 programs are encouraged to determine the significance of the
   reply from the first digit, rather than requiring a specific
   reply code, when possible.                                         7c

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

   5.  TYPEs P and F mean that the source file contains ASA control
   characters and that the recipient program should reformat it if
   necessary.  Servers which care about Telnet-print vs. non-print
   should implement SRVR T and SRVR N.  All user processes should
   provide a way for the human user to specify an arbitrary SRVR
   command.                                                           7e

   6.  (This is just a resolution of a loose end in documentation.)
   Nested reply codes are not allowed.  I don't think this really
   needs more discussion; they never happen and can't possibly work,
   and FTP user programs shouldn't have to worry about them.          7f

   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.
   Replies invented in RFC 454 are so noted; since some of them are
   for commands largely not implemented like REIN, they may be
   irrelevant.                                                        7g

      OLD   NEW   TEXT
                                                                     7g1
      0x0   0x0   (These messages are not very well defined nor very





                                   11

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



                  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.)
      110   111   System busy doing...  (This RFC 454 message could
                  easily be considered an example of the one above,
                  but since the 454 authors want to distinguish it,
                  here it is in another number.)
      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.                                           7g2
      202   252   ABOR ignored, no transfer in progress.
      new   206   Command ignored, superfluous here.
      230   230   Login complete.
      231   231   Logout complete.  (RFC 454: Closing connection.)
      232   232   Logout command will be processed when transfer is
                  complete.                                          7g3
      233   233   Logout complete, parameters reinitialized.  (RFC
      454               for REIN)                                    7g4
      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
      256   256   Mail completed ok.
      300   300   Connection greeting
      301   301   Command incomplete (no crlf)
      330   330   Enter password                                     7g5
      331   331   Enter account (RFC 454)
      350   350   Enter mail.                                        7g6
      400   huh?  "This service not implemented."  I don't
      understand
                  this; how does it differ from 506?  If it means no





                                   12

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



      FTP
                  at all, who gave the message?  Flush.              7g7
      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.
      433   533   Need account to write files.
      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.            7g8
      453   423   Transfer incomplete, insufficient storage space.
      454   454   Can't connect to your socket.
      455   425   Random file system error (RFC 454)                 7g9
      456   526   Name duplication, rename failed (RFC 454)
      457   557   Bad transfer parameters (TYPE, BYTE, etc) (RFC
      454)
      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.
      507   507   Some other problem.  (RFC 454)
      550   520   Bad syntax in pathname.  (RFC454)                 7g10




















                                   13