Revised FTP reply codes
RFC 640

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

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.