rfc454.txt

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

      transfer to resume.

      Rename from - (RNFR) - This command specifies the file which is to
      be renamed.  This command must be immediately followed by a
      "rename to" command specifying the new file pathname.

      Rename to (RNTO) - This command specifies the new pathname of the
      file specified in the immediately preceding "rename from" command.
      Together the two commands cause a file to be renamed.

      Abort (ABOR) - This command indicates to the server to abort the
      previous FTP service command and any associated transfer of data.
      The abort command should be preceded by the TELNET SYNCH condition
      (indicated by the combination of the DATA MARK and the INS).  No
      action is to be taken if the previous command has been completed
      (including data transfer).  The TELNET connections are not to be
      closed by the server, but the data connection may be closed.  An
      appropriate reply should be sent by the server.

      Delete (DELE) - This command causes the file specified in the
      pathname to be deleted at the server site.  If an extra level of
      protection is desired (such as the query, "Do you really wish to
      delete?"), it should be provided by the user-FTP process.

      List (LIST) - This command causes a list to be sent from server to
      user site.  If the pathname specifies a directory, the server
      should transfer a list of files in the specified directory.  If
      the pathname specifies a file then server should send current
      information on the file.  A null argument implies the user's
      current working or default directory.  The data transfer is over
      the data connection in type ASCII or type EBCDIC.  (It is the user
      's responsibility to ensure the correct parameters.)

      NList (NLST) - This command causes a directory listing to be sent
      from server to user site.  The pathname should specify a directory
      and the server will return a stream of names of files and no other
      information.  The data will be transferred in ASCII or EBCDIC type
      over the data connection as valid pathname strings separated by



McKenzie                                                       [Page 22]

RFC 454                  File Transfer Protocol                July 1972


      CRLF.  This command will allow automatic copying of an entire
      directory when used with the appropriate transfer commands.

      Status (STAT) - This command shall cause a status response to be
      sent over the TELNET connection in form of a reply.  The command
      may be sent during a file transfer (preceded by a TELNET SYNC) in
      which case the server will respond with the status of the opera-
      tion in progress, or it may be sent between file transfers.  In
      the latter case the command may have an argument field such as a
      pathname.  If the argument is a pathname, the command is analogous
      to the "list" command except that data shall be transferred in
      ASCII on the TELNET connection.  If a partial pathname is given,
      the server may respond with a list of file names or attributes
      associated with that specification.  If no argument is given, the
      server should return general status information about the server
      FTP process.  This should include current values of all transfer
      parameters and the status of connections.

      Help (HELP) - This command shall cause the server to send helpful
      information regarding its implementation status over the TELNET
      connection to the user.  The command may take an argument (e.g.
      any command name) and return more specific information as a
      response.  The reply is type 100, general system status.  It is
      suggested that HELP be allowed before entering a USER command.

      Mail File (MLFL) - The intent of this command is to enable a user
      site to mail data (in form of a file) to another user at the
      server site.  It should be noted that the files to be mailed are
      transmitted via the data connection in ASCII or EBCDIC type. (It
      is the user's responsibility to ensure that the type is correct.)
      These files should be appended to the destination user's mail by
      the server in accordance with serving HOST mail conventions.  The
      mail may be marked as sent from the particular using HOST and the
      user specified by the 'USER' command.  The argument field may con-
      tain one or more system or NIC idents (it is recommended that mul-
      tiple ident be allowed so the same mail can easily be sent to
      several users), or it may be empty.  If the argument field is
      empty or blank (one or more spaces), then the mail is destined for
      a printer or other designated place for site mail.  A NIC ident
      refers to the standard identification described in the NIC Direc-
      tory of Network Participants.  A serving host may keep a table
      mapping NIC indents into system idents, although NIC idents are
      not required in the implementation.  A system ident is the user's
      normal identification at the serving host.  The use of system
      idents would allow a network user to send mail to other users who
      do not have NIC identification but whose system ident is known.





McKenzie                                                       [Page 23]

RFC 454                  File Transfer Protocol                July 1972


      Mail (MAIL) - This command allows a user to send mail that is not
      in a file over the TELNET connection.  The argument field may con-
      tain one or more system or NIC idents, or it may be empty.  The
      idents are defined as above for the MLFL command.  After the
      'MAIL' command is received, the server is to treat the following
      lines as text of the mail sent by the user.  The mail text is to
      be terminated by a line containing only a single period, that is,
      the character sequence ".CRLF" in a new line.  It is suggested
      that a modest volume of mail service should be free; i.e., it may
      be entered before a USER command.

IV.A.4 Miscellaneous Commands

      NoOP (NOOP) - This command does not affect any parameters or pre-
      viously entered command.  The server simply sends a no-op reply.

      Quote (QUOT) - This command allows the user to talk directly to
      the FTP-server.  After parsing this command, the user-FTP process
      will pass without examination all succeeding liners until the NQUO
      command is received.  Between these two commands the server will
      respond appropriately to his implementation and the user's
      requests.

      NoQuote (NQUO) - This command returns the user and server
      processes to normal interactive mode.  Both QUOT and NQUO have
      reply codes to be sent by th server process to the user process to
      ensure agreement on the current mode.

   The quote commands provide a convenient method of testing server-
   implemented experimental commands.  The names of the latter should
   begin with an X, and can be listed in the system HELP reply.  It
   should be noted that the official command set is expandable; sugges-
   tions should go first to Alexander A. McKenzie (BBN).

IV.B  FTP Replies

   The server sends FTP replies over the TELNET connection in response
   to user FTP commands.  The FTP replies constitute the acknowledgment
   or completion code (including errors).  The FTP-server replies are
   formatted for human or program interpretation.  Single line replies
   consist of a leading three-digit numeric code followed by a space,
   followed by a one-line text explanation of the code.  For replies
   that contain several lines of text, the first line will have a lead-
   ing three-digit numeric code followed immediately by the ASCII char-
   acter "-" (Hyphen, Code 55 (octal)) and possibly some text.  All
   succeeding continuation lines except the last are constrained not to
   begin with three digits; the last line must repeat the numeric code
   of the first line and be followed immediately by a space.



McKenzie                                                       [Page 24]

RFC 454                  File Transfer Protocol                July 1972


   For example:

           100-First Line
           Continuation Line
           Another Line
           100 Last Line

   The numeric codes are assigned by groups and for ease of interpreta-
   tion by programs in a manner consistent with other protocols such as
   the RJE protocol.  The three digits of the code are to be interpreted
   as follows:

   a) The first digit specifies type of response as indicated below:

       000 These replies are purely informative and constitute neither a
           positive nor a negative acknowledgment.

       1xx Informative replies to status inquiries.  These constitute a
           positive acknowledgment to the status command.

       2xx Positive acknowledgment of previous command or other success-
           ful action.

       3xx Incomplete information.  Activity cannot proceed without
           further specification and input.

       4xx Unsuccessful reply.  The request is correctly specified but
           the server is unsuccessful in correctly fulfilling it.

       5xx Incorrect or illegal command.  The command or its parameters
           were invalid or incomplete from a syntactic viewpoint, or the
           command is inconsistent with a previous command.  The command
           in question has been completely ignored.

       6xx-9xx Reserved for future expansion.
















McKenzie                                                       [Page 25]

RFC 454                  File Transfer Protocol                July 1972


   b) The second digit specifies the general category to which the
       response refers:

       x00-x29 General purpose replies, not assignable to other
       categories.

       x30 Primary access.  Informative replies to the "log-on" attempt.

       x40 Secondary access.  The primary server is commenting on its
       ability to access a secondary service.

       x5x FTP results

       x6x RJE results.

       x7x-x9x Reserved for future expansion.

   c) The final digit specifies a particular message type.  Since the
       code is designed for an automation process to interpret, it is
       not necessary for every variation of a reply to have a unique
       number.  Only the basic meaning of replies need have unique
       numbers.  The text of a reply can explain the specific reason for
       that reply to a human user.

       Each TELNET line delimited by a numeric code and CRLF (or group
       of text lines bounded by coded lines) that is sent by the server
       is intended to be a complete reply message.  It should be noted
       that the text of replies is intended for a human user.  Only the
       reply codes and in some instances the first line of text are
       intended for programs.

The assigned reply codes relating to FTP are:

000 General information message (site, time of day, etc.).
010 Message from system operator.
030 Server availability information.
050 FTP commentary or user information.
100 System status reply.
110 System busy doing...
150 File status reply
151 Directory listing reply.
200 Last command received correctly.
201 An ABORT has terminated activity, as requested.
202 Abort request ignored, no activity in progress.
230 User is "logged in". May proceed.
231 User is "logged out". Service terminated.
232 Logout command noted, will complete when transfer done.
233 User is "logged out". Parameters reinitialized.



McKenzie                                                       [Page 26]

RFC 454                  File Transfer Protocol                July 1972


250 FTP file transfer started correctly.
251 FTP Restart-marker reply.

        Text is : MARK yyyy = mmmm
        where yyyy is user's data stream marker (yours)
        and mmmm is server's equivalent marker (mine)
        (Note the spaces between the markers and '=')

252 FTP transfer completed correctly.
253 Rename completed.
254 Delete completed.
255 FTP server data socket reply

        Text is: SOCK nnnn
        where nnnn is a decimal integer representing
        the server socket for data connection

256 Mail completed.
300 Connection greeting message, awaiting input.
301 Current command incompleted (no CRLF for long time).
330 Enter password
331 Enter account (if account required as part of login
    sequence).
350 Enter mail, terminate by a line with only a '.'
400 This service not implemented.
401 This service not acceptin