File Transfer Protocol (FTP) status and further comments
RFC 414

Document Type RFC - Unknown (December 1972; No errata)
Updates RFC 385
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 414 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         A. Bhushan
Request for Comments: 414                                        MIT-MAC
Updates: RFC 354, RFC 385                               29 November 1972
NIC: 12406

        FILE TRANSFER PROTOCOL (FTP) STATUS AND FURTHER COMMENTS

   A number of HOSTs have working server and user FTPs now.  The
   following reflects the status of FTP implementations to the best of
   my knowledge:

      BBN(A and B), SRI-ARC, UTAH, CASE, USC-ISI, CCA, MIT-AI MIT-
      Mathlab, MIT-DMCG, CMU, AMES-67, and SU-AI have fully functionning
      server and user FTPs.

      MIT-Multics has user and server FTPs but the server does not
      listen on socket 3 (it can be started by normal login and the
      command ftp_server).  UCSB will soon have user and server FTP's.

   The servers at all the TENEX systems are more or less identical
   (developed by Bob Clements at BBN).  The servers at MIT-AI and MIT-ML
   are also identical (developed by Pitts Jarvis of MAC).  Others
   currently involved with FTP include Arvola Chan (AC@MIT-DMCG), Ken
   Pogran (Multics), Greg Hicks (HICKS@UTAH), Wayne Hathaway (AMES-67),
   Ralph Gorin (SU-AI), Rick Werme (CMU), and Ron Stoughton (UCSB).

   The User-FTP or the user interface to FTP is where desirable and
   interesting features can be put in.  An example of such a features is
   the BBN (and other TENEXes) "SNDMSG USER@HOST" feature which allows a
   local user to send messages (or mail) to other network users.  If the
   remote host is not up, the message is stored as "--UNSENT-MAIL--
   USERHOST" in the user's directory and a background job periodically
   checks for such files to send mail.  MIT-AI and MIT-ML have a "TRANS"
   command which allows convenient transfer of files.  At MIT-DMCG we
   have developed under the "CALICO" subsystem, generalized commands
   which allow local users to send mail, copy files efficiently, and
   list users and directories over the network in a manner similar to
   local usage (that is without having to explicitly connect, login, and
   send commands to a remote HOST).  We also allow TELNET, FTP, and RJS
   users to automatically "login" and perform other command sequences
   from an "initial" file.

   It should be noted that file transfer between PDP-10's in "Image 36"
   is an order of magnitude faster (and more efficient) than in "ASCII
   8".  Note also that it is useful to provide a "Quote" or "talk" mode
   in user-FTP, to enable a user to input commands directly to the FTP
   server (i.e. commands not implemented in user-FTP).  It is desirable

Bhushan                                                         [Page 1]
RFC 414             FTP Status and Further Comments        November 1972

   that user and server FTP features and desirable modes of usage be
   documented and reported via the RFC mechanism.

   The following suggestions and additions pertain to the File Transfer
   Protocol as stated in NWG/RFC 354 and NWG/RFC 385.  After receiving
   comments to this RFC, I will have the three RFC's combined into a
   single document and have it issued as the ARPANET Official File
   Transfer Protocol, very soon.  It should however be noted that FTP is
   an open-ended protocol with room for experimentation.  New commands,
   reply codes, data representation types, and file structures may be
   defined in future.  If two sites agree, they can define their own
   experimental set of commands, data types, file structures, and/or
   transfer modes.  Such additions to the protocol should be well
   documented and clearly specified so that other sites can also make
   use of the same.

   1) The FTP assumes line-at-a-time interaction with local acho.  The
      server is not obliged to provide remote echo and may ignore TELNET
      control characters.  A server however should not give error or bad
      response on receiving TELNET control characters.

      The server does not explicitly provide any editing capability such
      as character delete or line kill characters.  All editing is
      assumed to be local.  TIP users should use FTP in line mode and
      send both <CR> and <LF> (by TIP commands @T O L and @I L).  In
      such a mode the TIP user can flush his current input line by the
      flush command (@F).

      The server should respond to the TELNET "SYNCH" by flushing the
      current command line and waiting for user input such as an "ABOR"
      command.  Other commands such as "BYE" or "STAT" may also
      constitute an acceptable input.

   2) Commands such as "STAT" which will produce more than one line of
      output over the TELNET connection, require some way of positively
      indicating the end of status information.  It is proposed that a
      "200 status complete" reply give a positive indication for end of
      status information.  The reply to STAT should begin with a line
      starting with 1xx (where x=digit), with the following lines not
Show full document text