in Index   Prev   Next

RFC 0959

File Transfer Protocol

Pages: 69
Internet Standard: 9
Obsoletes:  0765
Updated by:  222826402773365957977151
Part 3 of 3 – Pages 43 to 69
First   Prev   None

ToP   noToC   RFC0959 - Page 43   prevText


      In order to make FTP workable without needless error messages, the
      following minimum implementation is required for all servers:

         TYPE - ASCII Non-print
         MODE - Stream
         STRUCTURE - File, Record
                    TYPE, MODE, STRU,
                      for the default values
                    RETR, STOR,

      The default values for transfer parameters are:

         TYPE - ASCII Non-print
         MODE - Stream
         STRU - File

      All hosts must accept the above as the standard defaults.
ToP   noToC   RFC0959 - Page 44

      The server protocol interpreter shall "listen" on Port L.  The
      user or user protocol interpreter shall initiate the full-duplex
      control connection.  Server- and user- processes should follow the
      conventions of the Telnet protocol as specified in the
      ARPA-Internet Protocol Handbook [1].  Servers are under no
      obligation to provide for editing of command lines and may require
      that it be done in the user host.  The control connection shall be
      closed by the server at the user's request after all transfers and
      replies are completed.

      The user-DTP must "listen" on the specified data port; this may be
      the default user port (U) or a port specified in the PORT command.
      The server shall initiate the data connection from his own default
      data port (L-1) using the specified user data port.  The direction
      of the transfer and the port used will be determined by the FTP
      service command.

      Note that all FTP implementation must support data transfer using
      the default port, and that only the USER-PI may initiate the use
      of non-default ports.

      When data is to be transferred between two servers, A and B (refer
      to Figure 2), the user-PI, C, sets up control connections with
      both server-PI's.  One of the servers, say A, is then sent a PASV
      command telling him to "listen" on his data port rather than
      initiate a connection when he receives a transfer service command.
      When the user-PI receives an acknowledgment to the PASV command,
      which includes the identity of the host and port being listened
      on, the user-PI then sends A's port, a, to B in a PORT command; a
      reply is returned.  The user-PI may then send the corresponding
      service commands to A and B.  Server B initiates the connection
      and the transfer proceeds.  The command-reply sequence is listed
      below where the messages are vertically synchronous but
      horizontally asynchronous:
ToP   noToC   RFC0959 - Page 45
         User-PI - Server A                User-PI - Server B
         ------------------                ------------------
         C->A : Connect                    C->B : Connect
         C->A : PASV
         A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2
                                           C->B : PORT A1,A2,A3,A4,a1,a2
                                           B->C : 200 Okay
         C->A : STOR                       C->B : RETR
                    B->A : Connect to HOST-A, PORT-a

                                Figure 3

      The data connection shall be closed by the server under the
      conditions described in the Section on Establishing Data
      Connections.  If the data connection is to be closed following a
      data transfer where closing the connection is not required to
      indicate the end-of-file, the server must do so immediately.
      Waiting until after a new transfer command is not permitted
      because the user-process will have already tested the data
      connection to see if it needs to do a "listen"; (remember that the
      user must "listen" on a closed data port BEFORE sending the
      transfer request).  To prevent a race condition here, the server
      sends a reply (226) after closing the data connection (or if the
      connection is left open, a "file transfer completed" reply (250)
      and the user-PI should wait for one of these replies before
      issuing a new transfer command).

      Any time either the user or server see that the connection is
      being closed by the other side, it should promptly read any
      remaining data queued on the connection and issue the close on its
      own side.

   5.3.  COMMANDS

      The commands are Telnet character strings transmitted over the
      control connections as described in the Section on FTP Commands.
      The command functions and semantics are described in the Section
      on Access Control Commands, Transfer Parameter Commands, FTP
      Service Commands, and Miscellaneous Commands.  The command syntax
      is specified here.

      The commands begin with a command code followed by an argument
      field.  The command codes are four or fewer alphabetic characters.
      Upper and lower case alphabetic characters are to be treated
      identically.  Thus, any of the following may represent the
      retrieve command:
ToP   noToC   RFC0959 - Page 46
                  RETR    Retr    retr    ReTr    rETr

      This also applies to any symbols representing parameter values,
      such as A or a for ASCII TYPE.  The command codes and the argument
      fields are separated by one or more spaces.

      The argument field consists of a variable length character string
      ending with the character sequence <CRLF> (Carriage Return, Line
      Feed) for NVT-ASCII representation; for other negotiated languages
      a different end of line character might be used.  It should be
      noted that the server is to take no action until the end of line
      code is received.

      The syntax is specified below in NVT-ASCII.  All characters in the
      argument field are ASCII characters including any ASCII
      represented decimal integers.  Square brackets denote an optional
      argument field.  If the option is not taken, the appropriate
      default is implied.
ToP   noToC   RFC0959 - Page 47
      5.3.1.  FTP COMMANDS

         The following are the FTP commands:

            USER <SP> <username> <CRLF>
            PASS <SP> <password> <CRLF>
            ACCT <SP> <account-information> <CRLF>
            CWD  <SP> <pathname> <CRLF>
            CDUP <CRLF>
            SMNT <SP> <pathname> <CRLF>
            QUIT <CRLF>
            REIN <CRLF>
            PORT <SP> <host-port> <CRLF>
            PASV <CRLF>
            TYPE <SP> <type-code> <CRLF>
            STRU <SP> <structure-code> <CRLF>
            MODE <SP> <mode-code> <CRLF>
            RETR <SP> <pathname> <CRLF>
            STOR <SP> <pathname> <CRLF>
            STOU <CRLF>
            APPE <SP> <pathname> <CRLF>
            ALLO <SP> <decimal-integer>
                [<SP> R <SP> <decimal-integer>] <CRLF>
            REST <SP> <marker> <CRLF>
            RNFR <SP> <pathname> <CRLF>
            RNTO <SP> <pathname> <CRLF>
            ABOR <CRLF>
            DELE <SP> <pathname> <CRLF>
            RMD  <SP> <pathname> <CRLF>
            MKD  <SP> <pathname> <CRLF>
            PWD  <CRLF>
            LIST [<SP> <pathname>] <CRLF>
            NLST [<SP> <pathname>] <CRLF>
            SITE <SP> <string> <CRLF>
            SYST <CRLF>
            STAT [<SP> <pathname>] <CRLF>
            HELP [<SP> <string>] <CRLF>
            NOOP <CRLF>
ToP   noToC   RFC0959 - Page 48

         The syntax of the above argument fields (using BNF notation
         where applicable) is:

            <username> ::= <string>
            <password> ::= <string>
            <account-information> ::= <string>
            <string> ::= <char> | <char><string>
            <char> ::= any of the 128 ASCII characters except <CR> and
            <marker> ::= <pr-string>
            <pr-string> ::= <pr-char> | <pr-char><pr-string>
            <pr-char> ::= printable characters, any
                          ASCII code 33 through 126
            <byte-size> ::= <number>
            <host-port> ::= <host-number>,<port-number>
            <host-number> ::= <number>,<number>,<number>,<number>
            <port-number> ::= <number>,<number>
            <number> ::= any decimal integer 1 through 255
            <form-code> ::= N | T | C
            <type-code> ::= A [<sp> <form-code>]
                          | E [<sp> <form-code>]
                          | I
                          | L <sp> <byte-size>
            <structure-code> ::= F | R | P
            <mode-code> ::= S | B | C
            <pathname> ::= <string>
            <decimal-integer> ::= any decimal integer
ToP   noToC   RFC0959 - Page 49

      The communication between the user and server is intended to be an
      alternating dialogue.  As such, the user issues an FTP command and
      the server responds with a prompt primary reply.  The user should
      wait for this initial primary success or failure response before
      sending further commands.

      Certain commands require a second reply for which the user should
      also wait.  These replies may, for example, report on the progress
      or completion of file transfer or the closing of the data
      connection.  They are secondary replies to file transfer commands.

      One important group of informational replies is the connection
      greetings.  Under normal circumstances, a server will send a 220
      reply, "awaiting input", when the connection is completed.  The
      user should wait for this greeting message before sending any
      commands.  If the server is unable to accept input right away, a
      120 "expected delay" reply should be sent immediately and a 220
      reply when ready.  The user will then know not to hang up if there
      is a delay.

      Spontaneous Replies

         Sometimes "the system" spontaneously has a message to be sent
         to a user (usually all users).  For example, "System going down
         in 15 minutes".  There is no provision in FTP for such
         spontaneous information to be sent from the server to the user.
         It is recommended that such information be queued in the
         server-PI and delivered to the user-PI in the next reply
         (possibly making it a multi-line reply).

      The table below lists alternative success and failure replies for
      each command.  These must be strictly adhered to; a server may
      substitute text in the replies, but the meaning and action implied
      by the code numbers and by the specific command reply sequence
      cannot be altered.

      Command-Reply Sequences

         In this section, the command-reply sequence is presented.  Each
         command is listed with its possible replies; command groups are
         listed together.  Preliminary replies are listed first (with
         their succeeding replies indented and under them), then
         positive and negative completion, and finally intermediary
ToP   noToC   RFC0959 - Page 50
         replies with the remaining commands from the sequence
         following.  This listing forms the basis for the state
         diagrams, which will be presented separately.

            Connection Establishment
                  500, 501, 421
                  331, 332
                  500, 501, 503, 421
                  500, 501, 503, 421
                  500, 501, 502, 421, 530, 550
                  500, 501, 502, 421, 530, 550
                  202, 250
                  500, 501, 502, 421, 530, 550
                  500, 502
ToP   noToC   RFC0959 - Page 51
            Transfer parameters
                  500, 501, 421, 530
                  500, 501, 502, 421, 530
                  500, 501, 504, 421, 530
                  500, 501, 504, 421, 530
                  500, 501, 504, 421, 530
            File action commands
                  500, 501, 504, 421, 530
                  500, 501, 502, 421, 530
                  125, 150
                     226, 250
                     425, 426, 451, 551, 552
                  532, 450, 452, 553
                  500, 501, 421, 530
                  125, 150
                     226, 250
                     425, 426, 451, 551, 552
                  532, 450, 452, 553
                  500, 501, 421, 530
                  125, 150
                     226, 250
                     425, 426, 451
                  450, 550
                  500, 501, 421, 530
ToP   noToC   RFC0959 - Page 52
                  125, 150
                     226, 250
                     425, 426, 451
                  500, 501, 502, 421, 530
                  125, 150
                     226, 250
                     425, 426, 451
                  500, 501, 502, 421, 530
                  125, 150
                     226, 250
                     425, 426, 451, 551, 552
                  532, 450, 550, 452, 553
                  500, 501, 502, 421, 530
                  450, 550
                  500, 501, 502, 421, 530
                  532, 553
                  500, 501, 502, 503, 421, 530
                  450, 550
                  500, 501, 502, 421, 530
                  500, 501, 502, 421, 530, 550
                  500, 501, 502, 421, 530, 550
                  500, 501, 502, 421, 550
                  225, 226
                  500, 501, 502, 421
ToP   noToC   RFC0959 - Page 53
            Informational commands
                  500, 501, 502, 421
                  211, 212, 213
                  500, 501, 502, 421, 530
                  211, 214
                  500, 501, 502, 421
            Miscellaneous commands
                  500, 501, 530
                  500 421
ToP   noToC   RFC0959 - Page 54

   Here we present state diagrams for a very simple minded FTP
   implementation.  Only the first digit of the reply codes is used.
   There is one state diagram for each group of FTP commands or command

   The command groupings were determined by constructing a model for
   each command then collecting together the commands with structurally
   identical models.

   For each command or command sequence there are three possible
   outcomes: success (S), failure (F), and error (E).  In the state
   diagrams below we use the symbol B for "begin", and the symbol W for
   "wait for reply".

   We first present the diagram that represents the largest group of FTP

                               1,3    +---+
                          ----------->| E |
                         |            +---+
      +---+    cmd    +---+    2      +---+
      | B |---------->| W |---------->| S |
      +---+           +---+           +---+
                         |     4,5    +---+
                          ----------->| F |

      This diagram models the commands:

ToP   noToC   RFC0959 - Page 55
   The other large group of commands is represented by a very similar

                               3      +---+
                          ----------->| E |
                         |            +---+
      +---+    cmd    +---+    2      +---+
      | B |---------->| W |---------->| S |
      +---+       --->+---+           +---+
                 |     | |
                 |     | |     4,5    +---+
                 |  1  |  ----------->| F |
                  -----               +---+

      This diagram models the commands:


   Note that this second model could also be used to represent the first
   group of commands, the only difference being that in the first group
   the 100 series replies are unexpected and therefore treated as error,
   while the second group expects (some may require) 100 series replies.
   Remember that at most, one 100 series reply is allowed per command.

   The remaining diagrams model command sequences, perhaps the simplest
   of these is the rename sequence:

      +---+   RNFR    +---+    1,2    +---+
      | B |---------->| W |---------->| E |
      +---+           +---+        -->+---+
                       | |        |
                3      | | 4,5    |
         --------------  ------   |
        |                      |  |   +---+
        |               ------------->| S |
        |              |   1,3 |  |   +---+
        |             2|  --------
        |              | |     |
        V              | |     |
      +---+   RNTO    +---+ 4,5 ----->+---+
      |   |---------->| W |---------->| F |
      +---+           +---+           +---+
ToP   noToC   RFC0959 - Page 56
   The next diagram is a simple model of the Restart command:

      +---+   REST    +---+    1,2    +---+
      | B |---------->| W |---------->| E |
      +---+           +---+        -->+---+
                       | |        |
                3      | | 4,5    |
         --------------  ------   |
        |                      |  |   +---+
        |               ------------->| S |
        |              |   3   |  |   +---+
        |             2|  --------
        |              | |     |
        V              | |     |
      +---+   cmd     +---+ 4,5 ----->+---+
      |   |---------->| W |---------->| F |
      +---+        -->+---+           +---+
                  |      |
                  |  1   |

         Where "cmd" is APPE, STOR, or RETR.

   We note that the above three models are similar.  The Restart differs
   from the Rename two only in the treatment of 100 series replies at
   the second stage, while the second group expects (some may require)
   100 series replies.  Remember that at most, one 100 series reply is
   allowed per command.
ToP   noToC   RFC0959 - Page 57
   The most complicated diagram is for the Login sequence:

      +---+   USER    +---+------------->+---+
      | B |---------->| W | 2       ---->| E |
      +---+           +---+------  |  -->+---+
                       | |       | | |
                     3 | | 4,5   | | |
         --------------   -----  | | |
        |                      | | | |
        |                      | | | |
        |                 ---------  |
        |               1|     | |   |
        V                |     | |   |
      +---+   PASS    +---+ 2  |  ------>+---+
      |   |---------->| W |------------->| S |
      +---+           +---+   ---------->+---+
                       | |   | |     |
                     3 | |4,5| |     |
         --------------   --------   |
        |                    | |  |  |
        |                    | |  |  |
        |                 -----------
        |             1,3|   | |  |
        V                |  2| |  |
      +---+   ACCT    +---+--  |   ----->+---+
      |   |---------->| W | 4,5 -------->| F |
      +---+           +---+------------->+---+
ToP   noToC   RFC0959 - Page 58
   Finally, we present a generalized diagram that could be used to model
   the command and reply interchange:

              |                                    |
      Begin   |                                    |
        |     V                                    |
        |   +---+  cmd   +---+ 2         +---+     |
         -->|   |------->|   |---------->|   |     |
            |   |        | W |           | S |-----|
         -->|   |     -->|   |-----      |   |     |
        |   +---+    |   +---+ 4,5 |     +---+     |
        |     |      |    | |      |               |
        |     |      |   1| |3     |     +---+     |
        |     |      |    | |      |     |   |     |
        |     |       ----  |       ---->| F |-----
        |     |             |            |   |
        |     |             |            +---+
ToP   noToC   RFC0959 - Page 59

   User at host U wanting to transfer files to/from host S:

   In general, the user will communicate to the server via a mediating
   user-FTP process.  The following may be a typical scenario.  The
   user-FTP prompts are shown in parentheses, '---->' represents
   commands from host U to host S, and '<----' represents replies from
   host S to host U.


      ftp (host) multics<CR>         Connect to host S, port L,
                                     establishing control connections.
                                     <---- 220 Service ready <CRLF>.
      username Doe <CR>              USER Doe<CRLF>---->
                                     <---- 331 User name ok,
                                               need password<CRLF>.
      password mumble <CR>           PASS mumble<CRLF>---->
                                     <---- 230 User logged in<CRLF>.
      retrieve (local type) ASCII<CR>
      (local pathname) test 1 <CR>   User-FTP opens local file in ASCII.
      (for. pathname) test.pl1<CR>   RETR test.pl1<CRLF> ---->
                                     <---- 150 File status okay;
                                           about to open data
                                     Server makes data connection
                                     to port U.
                                     <---- 226 Closing data connection,
                                         file transfer successful<CRLF>.
      type Image<CR>                 TYPE I<CRLF> ---->
                                     <---- 200 Command OK<CRLF>
      store (local type) image<CR>
      (local pathname) file dump<CR> User-FTP opens local file in Image.
      (for.pathname) >udd>cn>fd<CR>  STOR >udd>cn>fd<CRLF> ---->
                                     <---- 550 Access denied<CRLF>
      terminate                      QUIT <CRLF> ---->
                                     Server closes all


   The FTP control connection is established via TCP between the user
   process port U and the server process port L.  This protocol is
   assigned the service port 21 (25 octal), that is L=21.
ToP   noToC   RFC0959 - Page 60

   The need for FTP to support page structure derives principally from
   the  need to support efficient transmission of files between TOPS-20
   systems, particularly the files used by NLS.

   The file system of TOPS-20 is based on the concept of pages.  The
   operating system is most efficient at manipulating files as pages.
   The operating system provides an interface to the file system so that
   many applications view files as sequential streams of characters.
   However, a few applications use the underlying page structures
   directly, and some of these create holey files.

   A TOPS-20 disk file consists of four things: a pathname, a page
   table, a (possibly empty) set of pages, and a set of attributes.

   The pathname is specified in the RETR or STOR command.  It includes
   the directory name, file name, file name extension, and generation

   The page table contains up to 2**18 entries.  Each entry may be
   EMPTY, or may point to a page.  If it is not empty, there are also
   some page-specific access bits; not all pages of a file need have the
   same access protection.

      A page is a contiguous set of 512 words of 36 bits each.

   The attributes of the file, in the File Descriptor Block (FDB),
   contain such things as creation time, write time, read time, writer's
   byte-size, end-of-file pointer, count of reads and writes, backup
   system tape numbers, etc.

   Note that there is NO requirement that entries in the page table be
   contiguous.  There may be empty page table slots between occupied
   ones.  Also, the end of file pointer is simply a number.  There is no
   requirement that it in fact point at the "last" datum in the file.
   Ordinary sequential I/O calls in TOPS-20 will cause the end of file
   pointer to be left after the last datum written, but other operations
   may cause it not to be so, if a particular programming system so

   In fact, in both of these special cases, "holey" files and
   end-of-file pointers NOT at the end of the file, occur with NLS data
ToP   noToC   RFC0959 - Page 61
   The TOPS-20 paged files can be sent with the FTP transfer parameters:
   TYPE L 36, STRU P, and MODE S (in fact, any mode could be used).

   Each page of information has a header.  Each header field, which is a
   logical byte, is a TOPS-20 word, since the TYPE is L 36.

   The header fields are:

      Word 0: Header Length.

         The header length is 5.

      Word 1: Page Index.

         If the data is a disk file page, this is the number of that
         page in the file's page map.  Empty pages (holes) in the file
         are simply not sent.  Note that a hole is NOT the same as a
         page of zeros.

      Word 2: Data Length.

         The number of data words in this page, following the header.
         Thus, the total length of the transmission unit is the Header
         Length plus the Data Length.

      Word 3: Page Type.

         A code for what type of chunk this is.  A data page is type 3,
         the FDB page is type 2.

      Word 4: Page Access Control.

         The access bits associated with the page in the file's page
         map.  (This full word quantity is put into AC2 of an SPACS by
         the program reading from net to disk.)

   After the header are Data Length data words.  Data Length is
   currently either 512 for a data page or 31 for an FDB.  Trailing
   zeros in a disk file page may be discarded, making Data Length less
   than 512 in that case.
ToP   noToC   RFC0959 - Page 62

   Since UNIX has a tree-like directory structure in which directories
   are as easy to manipulate as ordinary files, it is useful to expand
   the FTP servers on these machines to include commands which deal with
   the creation of directories.  Since there are other hosts on the
   ARPA-Internet which have tree-like directories (including TOPS-20 and
   Multics), these commands are as general as possible.

      Four directory commands have been added to FTP:

         MKD pathname

            Make a directory with the name "pathname".

         RMD pathname

            Remove the directory with the name "pathname".


            Print the current working directory name.


            Change to the parent of the current working directory.

   The  "pathname"  argument should be created (removed) as a
   subdirectory of the current working directory, unless the "pathname"
   string contains sufficient information to specify otherwise to the
   server, e.g., "pathname" is an absolute pathname (in UNIX and
   Multics), or pathname is something like "<abso.lute.path>" to


      The CDUP command is a special case of CWD, and is included to
      simplify the implementation of programs for transferring directory
      trees between operating systems having different syntaxes for
      naming the parent directory.  The reply codes for CDUP be
      identical to the reply codes of CWD.

      The reply codes for RMD be identical to the reply codes for its
      file analogue, DELE.

      The reply codes for MKD, however, are a bit more complicated.  A
      freshly created directory will probably be the object of a future
ToP   noToC   RFC0959 - Page 63
      CWD command.  Unfortunately, the argument to MKD may not always be
      a suitable argument for CWD.  This is the case, for example, when
      a TOPS-20 subdirectory is created by giving just the subdirectory
      name.  That is, with a TOPS-20 server FTP, the command sequence

         MKD MYDIR
         CWD MYDIR

      will fail.  The new directory may only be referred to by its
      "absolute" name; e.g., if the MKD command above were issued while
      connected to the directory <DFRANKLIN>, the new subdirectory
      could only be referred to by the name <DFRANKLIN.MYDIR>.

      Even on UNIX and Multics, however, the argument given to MKD may
      not be suitable.  If it is a "relative" pathname (i.e., a pathname
      which is interpreted relative to the current directory), the user
      would need to be in the same current directory in order to reach
      the subdirectory.  Depending on the application, this may be
      inconvenient.  It is not very robust in any case.

      To solve these problems, upon successful completion of an MKD
      command, the server should return a line of the form:


      That is, the server will tell the user what string to use when
      referring to the created  directory.  The directory name can
      contain any character; embedded double-quotes should be escaped by
      double-quotes (the "quote-doubling" convention).

      For example, a user connects to the directory /usr/dm, and creates
      a subdirectory, named pathname:

         CWD /usr/dm
         200 directory changed to /usr/dm
         MKD pathname
         257 "/usr/dm/pathname" directory created

      An example with an embedded double quote:

         MKD foo"bar
         257 "/usr/dm/foo""bar" directory created
         CWD /usr/dm/foo"bar
         200 directory changed to /usr/dm/foo"bar
ToP   noToC   RFC0959 - Page 64
      The prior existence of a subdirectory with the same name is an
      error, and the server must return an "access denied" error reply
      in that case.

         CWD /usr/dm
         200 directory changed to /usr/dm
         MKD pathname
         521-"/usr/dm/pathname" directory already exists;
         521 taking no action.

      The failure replies for MKD are analogous to its file  creating
      cousin, STOR.  Also, an "access denied" return is given if a file
      name with the same name as the subdirectory will conflict with the
      creation of the subdirectory (this is a problem on UNIX, but
      shouldn't be one on TOPS-20).

      Essentially because the PWD command returns the same type of
      information as the successful MKD command, the successful PWD
      command uses the 257 reply code as well.


      Because these commands will be most useful in transferring
      subtrees from one machine to another, carefully observe that the
      argument to MKD is to be interpreted as a sub-directory of  the
      current working directory, unless it contains enough information
      for the destination host to tell otherwise.  A hypothetical
      example of its use in the TOPS-20 world:

         CWD <some.where>
         200 Working directory changed
         MKD overrainbow
         257 "<some.where.overrainbow>" directory created
         CWD overrainbow
         431 No such directory
         CWD <some.where.overrainbow>
         200 Working directory changed

         CWD <some.where>
         200 Working directory changed to <some.where>
         MKD <unambiguous>
         257 "<unambiguous>" directory created
         CWD <unambiguous>

      Note that the first example results in a subdirectory of the
      connected directory.  In contrast, the argument in the second
      example contains enough information for TOPS-20 to tell that  the
ToP   noToC   RFC0959 - Page 65
      <unambiguous> directory is a top-level directory.  Note also that
      in the first example the user "violated" the protocol by
      attempting to access the freshly created directory with a name
      other than the one returned by TOPS-20.  Problems could have
      resulted in this case had there been an <overrainbow> directory;
      this is an ambiguity inherent in some TOPS-20 implementations.
      Similar considerations apply to the RMD command.  The point is
      this: except where to do so would violate a host's conventions for
      denoting relative versus absolute pathnames, the host should treat
      the operands of the MKD and RMD commands as subdirectories.  The
      257 reply to the MKD command must always contain the absolute
      pathname of the created directory.
ToP   noToC   RFC0959 - Page 66

   Bhushan, Abhay, "A File Transfer Protocol", RFC 114 (NIC 5823),
   MIT-Project MAC, 16 April 1971.

   Harslem, Eric, and John Heafner, "Comments on RFC 114 (A File
   Transfer Protocol)", RFC 141 (NIC 6726), RAND, 29 April 1971.

   Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172
   (NIC 6794), MIT-Project MAC, 23 June 1971.

   Braden, Bob, "Comments on DTP and FTP Proposals", RFC 238 (NIC 7663),
   UCLA/CCN, 29 September 1971.

   Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 265
   (NIC 7813), MIT-Project MAC, 17 November 1971.

   McKenzie, Alex, "A Suggested Addition to File Transfer Protocol",
   RFC 281 (NIC 8163), BBN, 8 December 1971.

   Bhushan, Abhay, "The Use of "Set Data Type" Transaction in File
   Transfer Protocol", RFC 294 (NIC 8304), MIT-Project MAC,
   25 January 1972.

   Bhushan, Abhay, "The File Transfer Protocol", RFC 354 (NIC 10596),
   MIT-Project MAC, 8 July 1972.

   Bhushan, Abhay, "Comments on the File Transfer Protocol (RFC 354)",
   RFC 385 (NIC 11357), MIT-Project MAC, 18 August 1972.

   Hicks, Greg, "User FTP Documentation", RFC 412 (NIC 12404), Utah,
   27 November 1972.

   Bhushan, Abhay, "File Transfer Protocol (FTP) Status and Further
   Comments", RFC 414 (NIC 12406), MIT-Project MAC, 20 November 1972.

   Braden, Bob, "Comments on File Transfer Protocol", RFC 430
   (NIC 13299), UCLA/CCN, 7 February 1973.

   Thomas, Bob, and Bob Clements, "FTP Server-Server Interaction",
   RFC 438 (NIC 13770), BBN, 15 January 1973.

   Braden, Bob, "Print Files in FTP", RFC 448 (NIC 13299), UCLA/CCN,
   27 February 1973.

   McKenzie, Alex, "File Transfer Protocol", RFC 454 (NIC 14333), BBN,
   16 February 1973.
ToP   noToC   RFC0959 - Page 67
   Bressler, Bob, and Bob Thomas, "Mail Retrieval via FTP", RFC 458
   (NIC 14378), BBN-NET and BBN-TENEX, 20 February 1973.

   Neigus, Nancy, "File Transfer Protocol", RFC 542 (NIC 17759), BBN,
   12 July 1973.

   Krilanovich, Mark, and George Gregg, "Comments on the File Transfer
   Protocol", RFC 607 (NIC 21255), UCSB, 7 January 1974.

   Pogran, Ken, and Nancy Neigus, "Response to RFC 607 - Comments on the
   File Transfer Protocol", RFC 614 (NIC 21530), BBN, 28 January 1974.

   Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White,
   "Comments on the File Transfer Protocol", RFC 624 (NIC 22054), UCSB,
   Ames Research Center, SRI-ARC, 28 February 1974.

   Bhushan, Abhay, "FTP Comments and Response to RFC 430", RFC 463
   (NIC 14573), MIT-DMCG, 21 February 1973.

   Braden, Bob, "FTP Data Compression", RFC 468 (NIC 14742), UCLA/CCN,
   8 March 1973.

   Bhushan, Abhay, "FTP and Network Mail System", RFC 475 (NIC 14919),
   MIT-DMCG, 6 March 1973.

   Bressler, Bob, and Bob Thomas "FTP Server-Server Interaction - II",
   RFC 478 (NIC 14947), BBN-NET and BBN-TENEX, 26 March 1973.

   White, Jim, "Use of FTP by the NIC Journal", RFC 479 (NIC 14948),
   SRI-ARC, 8 March 1973.

   White, Jim, "Host-Dependent FTP Parameters", RFC 480 (NIC 14949),
   SRI-ARC, 8 March 1973.

   Padlipsky, Mike, "An FTP Command-Naming Problem", RFC 506
   (NIC 16157), MIT-Multics, 26 June 1973.

   Day, John, "Memo to FTP Group (Proposal for File Access Protocol)",
   RFC 520 (NIC 16819), Illinois, 25 June 1973.

   Merryman, Robert, "The UCSD-CC Server-FTP Facility", RFC 532
   (NIC 17451), UCSD-CC, 22 June 1973.

   Braden, Bob, "TENEX FTP Problem", RFC 571 (NIC 18974), UCLA/CCN,
   15 November 1973.
ToP   noToC   RFC0959 - Page 68
   McKenzie, Alex, and Jon Postel, "Telnet and FTP Implementation -
   Schedule Change", RFC 593 (NIC 20615), BBN and MITRE,
   29 November 1973.

   Sussman, Julie, "FTP Error Code Usage for More Reliable Mail
   Service", RFC 630 (NIC 30237), BBN, 10 April 1974.

   Postel, Jon, "Revised FTP Reply Codes", RFC 640 (NIC 30843),
   UCLA/NMC, 5 June 1974.

   Harvey, Brian, "Leaving Well Enough Alone", RFC 686 (NIC 32481),
   SU-AI, 10 May 1975.

   Harvey, Brian, "One More Try on the FTP", RFC 691 (NIC 32700), SU-AI,
   28 May 1975.

   Lieb, J., "CWD Command of FTP", RFC 697 (NIC 32963), 14 July 1975.

   Harrenstien, Ken, "FTP Extension: XSEN", RFC 737 (NIC 42217), SRI-KL,
   31 October 1977.

   Harrenstien, Ken, "FTP Extension: XRSQ/XRCP", RFC 743 (NIC 42758),
   SRI-KL, 30 December 1977.

   Lebling, P. David, "Survey of FTP Mail and MLFL", RFC 751, MIT,
   10 December 1978.

   Postel, Jon, "File Transfer Protocol Specification", RFC 765, ISI,
   June 1980.

   Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP
   Commands", RFC 776, BBN, December 1980.

   Padlipsky, Michael, "FTP Unique-Named Store Command", RFC 949, MITRE,
   July 1985.
ToP   noToC   RFC0959 - Page 69

   [1]  Feinler, Elizabeth, "Internet Protocol Transition Workbook",
        Network Information Center, SRI International, March 1982.

   [2]  Postel, Jon, "Transmission Control Protocol - DARPA Internet
        Program Protocol Specification", RFC 793, DARPA, September 1981.

   [3]  Postel, Jon, and Joyce Reynolds, "Telnet Protocol
        Specification", RFC 854, ISI, May 1983.

   [4]  Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC 943,
        ISI, April 1985.