rfc640.txt

RFC 的详细文档！


    NWG/RFC# 640                               JBP NJN 5-JUN-74 16:07  30843
    Revised FTP Reply Codes



                                                           Jon Postel
                                                            19 JUN 75


                          Revised FTP Reply Codes                          1




    This document describes a revised set of reply codes for the File
    Transfer Protocol.                                                     2

    The aim of this revision is to satisfy the goal of using reply
    codes to enable the command issuing process to easily determine
    the outcome of each command. The user protocol interpreter should
    be able to determine the success or failure of a command by
    examining the first digit of the reply code.                           3

    An important change in the sequencing of commands and replies
    which may not be obvious in the following documents concerns the
    establishment of the data connection.                                  4

       In the previous FTP specifications when an actual transfer
       command (STOR, RETR, APPE, LIST, NLIST, MLFL) was issued the
       preliminary reply was sent after the data connection was
       established. This presented a problem for some user protocol
       interpreters which had difficulty monitoring two connections
       asynchronously.                                                    4a

       The current specification is that the preliminary reply to the
       actual transfer commands indicates that the file can be
       transferred and either the connection was previously
       established or an attempt is about to be made to establish the
       data connection.                                                   4b

    This reply code revision is a modification of the protocol in
    described in RFC 542, that is to say that the protocol
    implementation associated with socket number 21 (decimal) is the
    protocol specified by the combination of RFC 542 and this RFC.         5

    A note of thanks to those who contributed to this work: Ken
    Pogran, Mark Krilanovich, Wayne Hathway, and especially Nancy
    Neigus.                                                                6

    NWG/RFC# 640                               JBP NJN 5-JUN-74 16:07  30843
    
                                                         Nancy Neigus
                                                           Ken Pogran
                                                           Jon Postel
                                                            19 JUN 75



                     A New Schema for FTP Reply Codes                      7






    Replies to File Transfer Protocol commands were devised to ensure
    the synchronization of requests and actions in the process of
    file transfer, and to guarantee that the user process always
    knows the state of the Server. Every command must generate at
    least one reply, although there may be more than one; in the
    latter case, the multiple replies must be easily distinguished.
    In addition, some commands occur in sequential groups, such as
    USER, PASS and ACCT, or RNFR and RNTO.  The replies show the
    existence of an intermediate state if all preceding commands have
    been successful.  A failure at any point in the sequence
    necessitates the repetition of the entire sequence from the
    beginning.                                                             8

       Details of the command-reply sequence will be made explicit in
       a state diagram.                                                   8a

    An FTP reply consists of a three digit number (transmitted as
    three alphanumeric characters) followed by some text.  The number
    is intended for use by automata to determine what state to enter
    next; the text is intended for the human user.  It is intended
    that the three digits contain enough encoded information that the
    user-process (the User-PI described in RFC 542) will not need to
    examine the text and may either discard it or pass it on to the
    user, as appropriate.  In particular, the text may be
    server-dependent, so there are likely to be varying texts for
    each reply code.                                                       9

    Formally, a reply is defined to contain the 3-digit code,
    followed by Space <SP>, followed by one line of text (where some
    maximum line length has been specified), and terminated by the
    TELNET end-of-line code.  There will be cases, however, where the
    text is longer than a single line.  In these cases the complete
    text must be bracketed so the User-process knows when it may stop
    reading the reply (i.e. stop processing input on the TELNET
    connection) and go do other things.  This requires a special
    format on the first line to indicate that more than one line is
    coming, and another on the last line to designate it as the last.
    At least one of these must contain the appropriate reply code to

    NWG/RFC# 640                               JBP NJN 5-JUN-74 16:07  30843
    Neigus                                       FTP Reply Codes  [3]



    indicate the state of the transaction.  To satisfy all factions
    it was decided that both the first and last line codes should be
    the same.                                                             10

       Thus the format for multi-line replies is that the first line
       will begin with the exact required reply code, followed
       immediately by a Hyphen, "-" (also known as Minus), followed
       by text.  The last line will begin with the same code,
       followed immediately by Space <SP>, optionally some text, and
       TELNET <eol>.                                                     10a

          For example:
                               123-First line
                               Second line
                                 234 A line beginning with numbers
                               123 The last line                        10a1

       The user-process then simply needs to search for the second
       occurrence of the same reply code, followed by <SP> (Space),
       at the beginning of a line, and ignore all intermediary lines.
       If an intermediary line begins with a 3-digit number, the
       Server must pad the front to avoid confusion.                     10b

          This scheme allows standard system routines to be used for
          reply information (such as for the STAT reply), with
          "artificial" first and last lines tacked on.  In the rare
          cases where these routines are able to generate three
          digits and a Space at the beginning of any line, the
          beginning of each text line should be offset by some
          neutral text, like Space.                                     10b1

       This scheme assumes that multi-line replies may not be nested.
       We  have found that, in general, nesting of replies will not
       occur, except for random system messages (called spontaneous
       replies in the previous FTP incarnations) which may interrupt
       another reply.  Spontaneous replies are no longer defined;
       system messages (i.e. those not processed by the FTP server)
       will NOT carry reply codes and may occur anywhere in the
       command-reply sequence.  They may be ignored by the
       User-process as they are only information for the human user.     10c

    The three digits of the reply each have a special significance.
    This is intended to allow a range of very simple to very
    sophisticated response by the user-process.  The first digit
    denotes whether the response is good, bad or incomplete.
    (Referring to the state diagram) an unsophisticated user-process
    will be able to determine its next action (proceed as planned,
    redo, retrench, etc.) by simply examining this first digit.  A
    user-process that wants to know approximately what kind of error

    NWG/RFC# 640                               JBP NJN 5-JUN-74 16:07  30843
    Neigus                                       FTP Reply Codes  [4]



    occurred (e.g. file system error, command syntax error) may
    examine the second digit, reserving the third digit for the
    finest gradation of information (e.g. RNTO command without a
    preceding RNFR.)                                                      11

       There are four values for the first digit of the reply code:      11a

       1yz   Positive Preliminary reply                                  11b

          The requested action is being initiated; expect another
          reply before proceeding with a new command.  (The
          user-process sending another command before the  completion
          reply would be in violation of protocol; but server-FTP
          processes should queue any commands that arrive while a
          preceeding command is in progress.)  This type of reply can
          be used to indicate that the command was accepted and the
          user-process may now pay attention to the data connections,
          for implementations where simultaneous monitoring is
          difficult.                                                    11b1

       2yz   Positive Completion reply                                   11c

          The requested action has been successfully completed.  A
          new request may be initiated.                                 11c1

       3yz   Positive Intermediate reply                                 11d

          The command has been accepted, but the requested action is
          being held in abeyance, pending receipt of further
          information.  The user should send another command
          specifying this information.  This reply is used in command
          sequence groups.                                              11d1

       4yz   Transient Negative Completion reply                         11e

          The command was not accepted and the requested action did
          not take place, but the error condition is temporary and
          the action may be requested again.  The user should return
          to the beginning of the command sequence, if any.  It is
          difficult to assign a meaning to "transient", particularly
          when two distinct sites (Server and User-processes) have to
          agree on the interpretation.  Each reply in the 4yz
          category might have a slightly different time value, but
          the intent is that the user-process is encouraged to try
          again.  A rule of thumb in determining if a reply fits into
          the 4yz or the 5yz (Permanent Negative) category is that
          replies are 4yz if the commands can be repeated without any
          change in command form or in properties of the User or
          Server (e.g. the command is spelled the same with the same

    NWG/RFC# 640                               JBP NJN 5-JUN-74 16:07  30843
    Neigus                                       FTP Reply Codes  [5]



          arguments used; the user does not change his file access or
          user name; the server does not put up a new
          implementation.)                                              11e1

       5yz   Permanent Negative Completion reply                         11f

          The command was not accepted and the requested action did
          not take place.  The User-process is discouraged from
          repeating the exact request (in the same sequence).  Even
          some "permanent" error conditions can be corrected, so the
          human user may want to direct his User-process to
          reinitiate the command sequence by direct action at some
          point in the future (e.g. after the spelling has been
          changed, or the user has altered his directory status.)       11f1

       The following function groupings are encoded in the second
       digit:                                                            11g

          x0z   Syntax - These replies refer to syntax errors,
                  syntactically correct  commands that don't fit any
                  functional category, unimplemented or superfluous
                  commands.                                             11g1

          x1z   Information -  These are replies to requests for
                  information, such as status or help.                  11g2

          x2z   Connections - Replies referring to the TELNET and
                  data connections.                                     11g3

          x3z   Authentication and accounting - Replies for the logon
                  process and accounting procedures.                    11g4

          x4z   Unspecified as yet                                      11g5