RFC 414 (rfc414) - Page 2 of 5

File Transfer Protocol (FTP) status and further comments

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  and  (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
      having a digit as their first character, and the status ending
      with the 200 reply.  (Note that the requirement of three spaces is
      dropped in favour of the less restrictive requirement of the first
      character not being a digit.)  This change would make operations
      much easier for both user and server FTPs.

   3) A reminder that BYE is legal.  A space after a command
      name is not required if there is a null argument.




Bhushan