Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 0765

File Transfer Protocol specification

Pages: 70
Obsoletes:  0542
Obsoleted by:  0959
Part 3 of 3 – Pages 44 to 70
First   Prev   None

ToP   noToC   RFC0765 - Page 44   prevText
      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 <LF>
         <marker> ::= <pr string>
         <pr string> ::= <pr char> | <pr char><pr string>
         <pr char> ::= printable characters, any
                       ASCII code 33 through 126
         <byte size> ::= any decimal integer 1 through 255
         <Host-port> ::= <Host-number>,<Port-number>
         <Host-number> ::= <number>,<number>,<number>,<number>
         <Port-number> ::= <number>,<number>
         <number> ::= any decimal integer 0 through 255
         <ident> ::= <string>
         <scheme> ::= R | T | ?
         <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>
ToP   noToC   RFC0765 - Page 45

      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, he
      should send a 120 "expected delay" reply immediately and a 220
      reply when ready.  The user will then know not to hang up if there
      is a delay.

      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
         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
ToP   noToC   RFC0765 - Page 46
                  500, 501, 421
                  331, 332
                  500, 501, 503, 421
                  500, 501, 503, 421
                  500, 502
            Transfer parameters
                  500, 501, 421, 530
                  500, 501, 502, 421, 530
               MODE, TYPE, STRU
                  500, 501, 504, 421, 530
            File action commands
                  500, 501, 504, 421, 530
                  500, 501, 502, 421, 530
ToP   noToC   RFC0765 - Page 47
                  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
               LIST, NLST
                  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
                  125, 150, 151, 152
                     226, 250
                     425, 426, 451, 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
               DELE, CWD
                  450, 550
                  500, 501, 502, 421, 530
ToP   noToC   RFC0765 - Page 48
                  225, 226
                  500, 501, 502, 421
               MAIL, MSND
                  151, 152
                        451, 552
                     451, 552
                  450, 550, 452, 553
                  500, 501, 502, 421, 530
               MSOM, MSAM
                  119, 151, 152
                        451, 552
                     451, 552
                  450, 550, 452, 553
                  500, 501, 502, 421, 530
                  200, 215
                  500, 501, 502, 421, 530
                  151, 152
                  450, 550, 452, 553
                  500, 501, 502, 503, 421
            Informational commands
                  211, 212, 213
                  500, 501, 502, 421, 530
                  211, 214
                  500, 501, 502, 421
            Miscellaneous commands
                  500, 501, 530
ToP   noToC   RFC0765 - Page 49
                  500 421
ToP   noToC   RFC0765 - Page 50

   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   RFC0765 - Page 51
   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.

   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   RFC0765 - Page 52
   A very similar diagram models the Mail and Send commands:

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

         This diagram models the commands:

            MAIL, MSND, MSOM, MSAM.

      Note that the "text" here is a series of lines sent from the user
      to the server with no response expected until the last line is
      sent, recall that the last line must consist only of a single
ToP   noToC   RFC0765 - Page 53
   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, RETR, or MLFL.

   We note that the above three models are similar, in fact the Mail
   diagram and the Rename diagram are structurally identical. The
   Restart differs from the other two only in the treatment of 100
   series replies at the second stage.
ToP   noToC   RFC0765 - Page 54
   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   RFC0765 - Page 55
   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   RFC0765 - Page 56

   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 TELNET 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 connection
                                     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> ---->
                                     <---- 450 Access denied<CRLF>
      terminate                      QUIT <CRLF> ---->
                                     Server closes all
ToP   noToC   RFC0765 - Page 57

   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   RFC0765 - Page 58

   The basic commands transmitting mail are the MAIL and the MLFL
   commands.  These commands cause the transmitted data to be entered
   into the recipients mailbox.

      MAIL <SP> <recipient name> <CRLF>

         If accepted, returns 354 reply and considers all succeeding
         lines to be the message text, terminated by a line containing
         only a period, upon which a 250 completion reply is returned.
         Various errors are possible.

      MLFL <SP> <recipient name> <CRLF>

         If accepted, acts like a STOR command, except that the data is
         considered to be the message text.  Various errors are

   There are two possible preliminary replies that a server may use to
   indicate that it is accepting mail for a user whose mailbox is not at
   that server.

      151 User not local; Will forward to <user>@<host>.

         This reply indicates that the server knows the user's mailbox
         is on another host and will take responsibility for forwarding
         the mail to that host.  For example, at BBN (or ISI) there are
         several host which each have a list of many of the users on
         several of the host.  These hosts then can accept mail for any
         user on their list and forward it to the correct host.

      152 User Unknown; Mail will be forwarded by the operator.

         This reply indicates that the host does not recognize the user
         name, but that it will accept the mail and have the operator
         attempt to deliver it.  This is useful if the user name is
         misspelled, but may be a disservice if the mail is really

   Three FTP commands provide for "sending" a message to a logged-in
   user's terminal, as well as variants for mailing it normally whether
   the user is logged in or not.
ToP   noToC   RFC0765 - Page 59
      MSND -- SeND to terminal.

         Returns 450 failure reply if the addressee is refusing or not
         logged in.

      MSOM -- Send to terminal Or Mailbox.

         Returns 119 notification reply if terminal is not accessible.

      MSAM -- Send to terminal And Mailbox.

         Returns 119 notification reply if terminal is not accessible.

   Note that for MSOM and MSAM, it is the mailing which determines
   success, not the sending, although MSOM as implemented uses a 119
   reply (in addition to the normal success/failure code) to indicate
   that because the SEND failed, an attempt is being made to mail the
   message instead.  There are no corresponding variants for MLFL, since
   messages transmitted in this way are generally short.

   There are two FTP commands which allow one to mail the text of a
   message to several recipients simultaneously; such message
   transmission is far more efficient than the practice of sending the
   text again and again for each additional recipient at a site.

   There are two basic ways of sending a single text to several
   recipients.  In one, all recipients are specified first, and then the
   text is sent; in the other, the order is reversed and the text is
   sent first, followed by the recipients.  Both schemes are necessary
   because neither by itself is optimal for all systems, as will be
   explained later.  To select a particular scheme, the MRSQ command is
   used; to specify recipients after a scheme is chosen, MRCP commands
   are given; and to furnish text, the MAIL or MLFL commands are used.

   Scheme Selection: MRSQ

      MRSQ is the means by which a user program can test for
      implementation of MRSQ/MRCP, select a particular scheme, reset its
      state thereof, and even do some rudimentary negotiation.  Its
      format is like that of the TYPE command, as follows:
ToP   noToC   RFC0765 - Page 60
         MRSQ [<SP> <scheme>] <CRLF>

         <scheme> = a single character.  The following are defined:
            R  Recipients first.  If not implemented, T must be.
            T  Text first.  If this is not implemented, R must be.
            ?  Request for preference.  Must always be implemented.

            No argument means a "selection" of none of the schemes (the

            200 OK, we'll use specified scheme.
            215 <scheme> This is the scheme I prefer.
            501 I understand MRSQ but can't use that scheme.
            5xx Command unrecognized or unimplemented.

      Three aspects of MRSQ need to be pointed out here.  The first is
      that an MRSQ with no argument must always return a 200 reply and
      restore the default state of having no scheme selected.  Any other
      reply implies that MRSQ and hence MRCP are not understood or
      cannot be performed correctly.

      The second is that the use of "?" as a <scheme> asks the FTP
      server to return a 215 reply in which the server specifies a
      "preferred" scheme.  The format of this reply is simple:

         215 <SP> <scheme> [<SP> <arbitrary text>] <CRLF>

         Any other reply (e.g. 4xx or 5xx) implies that MRSQ and MRCP
         are not implemented, because "?" must always be implemented if
         MRSQ is.

      The third important thing about MRSQ is that it always has the
      side effect of resetting all schemes to their initial state.  This
      reset must be done no matter what the reply will be - 200, 215, or
      501.  The actions necessary for a reset will be explained when
      discussing how each scheme actually works.

   Message Text Specification: MAIL/MLFL

      Regardless of which scheme (if any) has been selected, a MAIL or
      MLFL with a non-null argument will behave exactly as before; the
      MRSQ/MRCP commands have no effect on them.  However, such normal
      MAIL/MLFL commands do have the same side effect as MRSQ; they
      "reset" the current scheme to its initial state.
ToP   noToC   RFC0765 - Page 61
      It is only when the argument is null (e.g. MAIL<CRLF> or
      MLFL<CRLF>) that the particular scheme being used is important,
      because rather than producing an error (as most servers currently
      do), the server will accept message text for this "null"
      specification; what it does with it depends on which scheme is in
      effect, and will be described in "Scheme Mechanics".

   Recipient specification: MRCP

      In order to specify recipient names  (i.e., idents) and receive
      some acknowledgment (or refusal) for each name, the following
      command is used:

         MRCP <SP> <ident> <CRLF>

         Reply for no scheme:
            503 No scheme specified yet; use MRSQ.
         Replies for scheme T are identical to those for MAIL/MLFL.
         Replies for scheme R (recipients first):
            200 OK, name stored.
            452 Recipient table full, this name not stored.
            553 Recipient name rejected.
            4xx Temporary error, try this name again later.
            5xx Permanent error, report to sender.

      Note that use of this command is an error if no scheme has been
      selected yet; an MRSQ <scheme> must have been given if MRCP is to
      be used.

   Scheme mechanics: MRSQ R (Recipients first)

      In the recipients-first scheme, MRCP is used to specify names
      which the FTP server stores in a list or table.  Normally the
      reply for each MRCP will be either a 200 for acceptance, or a
      4xx/5xx code for rejection; all 5xx codes are permanent rejections
      (e.g. user not known) which should be reported to the human
      sender, whereas 4xx codes in general connote some temporary error
      that may be rectified later.  None of the 4xx/5xx replies impinge
      on previous or succeeding MRCP commands, except for 452 which
      indicates that no further MRCP's will succeed unless a message is
      sent to the already stored recipients or a reset is done.

      Sending message text to stored recipients is done by giving a MAIL
      or MLFL command with no argument; that is, just MAIL<CRLF> or
      MLFL<CRLF>.  Transmission of the message text is exactly the same
      as for normal MAIL/MLFL; however, a positive acknowledgment at the
ToP   noToC   RFC0765 - Page 62
      end of transmission means that the message has been sent to ALL
      recipients that were remembered with MRCP, and a failure code
      means that it should be considered to have failed for ALL of these
      specified recipients.  This applies regardless of the actual error
      code; and whether the reply signifies success or failure, all
      stored recipient names are flushed and forgotten - in other words,
      things are reset to their initial state.  This purging of the
      recipient name list must also be done as the "reset" side effect
      of any use of MRSQ.

      A 452 reply to an MRCP can thus be handled by using a MAIL/MLFL to
      specify the message for currently stored recipients, and then
      sending more MRCP's and another MAIL/MLFL, as many times as
      necessary; for example, if a server only had room for 10 names
      this would result in a 50-recipient message being sent 5 times, to
      10 different recipients each time.

      If a user attempts to specify message text (MAIL/MLFL with no
      argument) before any successful MRCP's have been given, this
      should be treated exactly as a "normal" MAIL/MLFL with a null
      recipient would be; some servers will return an error of some
      type, such as "550 Null recipient".

      See Example 1 for an example using MRSQ R.

   Scheme mechanics: MRSQ T (Text first)

      In the text-first scheme, MAIL/MLFL with no argument is used to
      specify message text, which the server stores away.  Succeeding
      MRCP's are then treated as if they were MAIL/MLFL commands, except
      that none of the text transfer manipulations are done; the stored
      message text is sent to the specified recipient, and a reply code
      is returned identical to that which an actual MAIL/MLFL would
      invoke. (Note ANY 2xx code indicates success.)

      The stored message text is not forgotten until the next MAIL/MLFL
      or MRSQ, which will either replace it with new text or flush it
      entirely.  Any use of MRSQ will reset this scheme by flushing
      stored text, as will any use of MAIL/MLFL with a non-null

      If an MRCP is seen before any message text has been stored, the
      user in effect is trying to send a null message; some servers
      might allow this, others would return an error code.

      See Example 2 for an example using MRSQ T.
ToP   noToC   RFC0765 - Page 63
   Why two schemes anyway?

      Because neither by itself is optimal for all systems.  MRSQ R
      allows more of a "bulk" mailing, because everything is saved up
      and then mailed simultaneously; this is very useful for systems
      such as ITS where the FTP server does not itself write mail
      directly, but hands it on to a central mailer demon of great
      power; the more information (e.g. recipients) associated with a
      single "hand-off", the more efficiently mail can be delivered.

      By contrast, MRSQ T is geared to FTP servers which want to deliver
      mail directly, in one-by-one incremental fashion.  This way they
      can return an individual success/failure reply code for each
      recipient given which may depend on variable file system factors
      such as exceeding disk allocation, mailbox access conflicts, and
      so forth; if they tried to emulate MRSQ R's bulk mailing, they
      would have to ensure that a success reply to the MAIL/MLFL indeed
      meant that it had been delivered to ALL recipients specified - not
      just some.


      * Because these commands are not required in the minimum
        implementation of FTP, one must be prepared to deal with sites
        which don't recognize either MRSQ or MRCP.  "MRSQ" and "MRSQ ?"
        are explicitly designed as tests to see whether either scheme is
        implemented; MRCP is not, and a failure return of the
        "unimplemented" variety could be confused with "No scheme
        selected yet", or even with "Recipient unknown".  Be safe, be
        sure, use MRSQ!

      * There is no way to indicate in a positive response to "MRSQ ?"
        that the preferred "scheme" for a server is that of the default
        state; i.e. none of the multi-recipient schemes.  The rationale
        is that in this case, it would be pointless to implement
        MRSQ/MRCP at all, and the response would therefore be negative.

      * One reason that the use of MAIL/MLFL is restricted to null
        arguments with this multi-recipient extension is the ambiguity
        that would result if a non-null argument were allowed; for
        example, if MRSQ R was in effect and some MRCP's had been given,
        and a MAIL FOO<CRLF> was done, there would be no way to
        distinguish a failure reply for mailbox "FOO" from a global
        failure for all recipients specified.  A similar situation
        exists for MRSQ T; it would not be clear whether the text was
        stored and the mailbox failed, or vice versa, or both.
ToP   noToC   RFC0765 - Page 64
      * "Resets" are done by all MRSQ's and "normal" MAIL/MLFL's to
        avoid confusion and overly complicated implementation.  The MRSQ
        command implies a change or uncertainty of status, and the
        latter commands would otherwise have to use some independent
        mechanisms to avoid clobbering the data bases (e.g., message
        text storage area) used by the T/R schemes.  However, once a
        scheme is selected, it remains "in effect" just as a "TYPE A"
        remains selected.  The recommended way for doing a reset,
        without changing the current selection, is with "MRSQ ?".
        Remember that "MRSQ" alone reverts to the no-scheme state.

      * It is permissible to intersperse other FTP commands among the
        MRSQ/MRCP/MAIL sequences.
ToP   noToC   RFC0765 - Page 65
   Example 1

                  Example of MRSQ R (Recipients first)

      This is an example of how MRSQ R is used; first the user must
      establish that the server in fact implements MRSQ:

         U: MRSQ
         S: 200 OK, no scheme selected.

      An MRSQ with a null argument always returns a 200 if implemented,
      selecting the "scheme" of null, i.e. none of them.  If MRSQ were
      not implemented, a code of 4xx or 5xx would be returned.

         U: MRSQ R
         S: 200 OK, using that scheme

      All's well; now the recipients can be specified.

         U: MRCP Foo
         S: 200 OK

         U: MRCP Raboof
         S: 553 Who's that?  No such user here.

         U: MRCP bar
         S: 200 OK

      Well, two out of three ain't bad.  Note that the demise of
      "Raboof" has no effect on the storage of "Foo" or "bar".  Now to
      furnish the message text, by giving a MAIL or MLFL with no

         U: MAIL
         S: 354 Type mail, ended by <CRLF>.<CRLF>
         U: Blah blah blah blah....etc etc etc
         U: .
         S: 250 Mail sent.

      The text has now been sent to both "Foo" and "bar".
ToP   noToC   RFC0765 - Page 66
   Example 2

                     Example of MRSQ T (Text first)

      Using the same message as the previous example:

         U: MRSQ ?
         S: 215 T Text first, please.

      MRSQ is indeed implemented, and the server says that it prefers
      "T", but that needn't stop the user from trying something else:

         U: MRSQ R
         S: 501 Sorry, I really can't do that.

      It's possible that it could have understood "R" also, but in
      general it's best to use the "preferred" scheme, since the server
      knows which is most efficient for its particular site.  Anyway:

         U: MRSQ T
         S: 200 OK, using that scheme.

      Scheme "T" is now selected, and the text must be sent:

         U: MAIL
         S: 354 Type mail, ended by <CRLF>.<CRLF>
         U: Blah blah blah blah....etc etc etc
         U: .
         S: 250 Mail stored.

      Now recipients can be specified:

         U: MRCP Foo
         S: 250 Stored mail sent.

         U: MRCP Raboof
         S: 553 Who's that?  No such user here.

         U: MRCP bar
         S: 250 Stored mail sent.
ToP   noToC   RFC0765 - Page 67
      Again, the text has now been sent to both "Foo" and "bar", and
      still remains stored.  A new message can be sent with another
      MAIL/MRCP... sequence, but the fastidious or paranoid could chose
      to do:

         U: MRSQ ?
         S: 215 T Text first, please.

      Which resets things without altering the scheme in effect.
ToP   noToC   RFC0765 - Page 68

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

   The file system of TOPS20 is based on the concept of pages.  The
   system level is most efficient at manipulating files as pages.
   System level programs provide 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 TOPS20 file is just a bunch of words pointed to by a page table.
   If those words contain CRLF's, fine -- but that doesn't mean "record"
   to TOPS20.

   A TOPS20 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 version

   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 pages 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 TOPS20 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
ToP   noToC   RFC0765 - Page 69
   In fact both of these special cases, "holey" files and
   end-of-file pointers not at the end of the file, occur with NLS data

   The TOPS20 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 TOPS20 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 21 for an FDB.  Trailing
   zeros in a disk file page may be discarded, making Data Length less
   than 512 in that case.
ToP   noToC   RFC0765 - Page 70
   Data transfers are implemented like the layers of an onion: some
   characters are packaged into a line.  Some lines are packaged into a
   file.  The file is broken into other manageable units for
   transmission.  Those units have compression applied to them.  The
   units may be flagged by restart markers.  On the other end, the
   process is reversed.