Skip to main content

File Transfer Protocol
RFC 354

Document Type RFC - Unknown (July 1972)
Obsoleted by RFC 542
Updated by RFC 385, RFC 454, RFC 683
Obsoletes RFC 264, RFC 265
Authors
Last updated 2013-03-02
RFC stream Legacy stream
Formats
IESG Responsible AD (None)
Send notices to (None)
RFC 354
|    | Marker  | Marker | Marker | Marker |
                    |    | 8 bits  | 8 bits | 8 bits | 8 bits |

                    |    | Marker  | Marker | SP     | SP     |
                    |    | 8 bits  | 8 bits | 8 bits | 8 bits |

4 Hasp              The file is transmitted as a sequence of 8-bit bytes
                    in the standard Hasp-compressed data format
                    (document to be issued by Bob Braden, UCLA). This
                    mode achieves considerable compression of data for
                    print files. Record structures are allowed in the
                    Hasp mode.

III.D Error Recovery and Restart

    There is no provision for detecting bits lost or scrambled
in data transfer. This issue is perhaps handled best at the NCP level
where it benefits most users. However, a restart procedure is provided
to protect user from system failures (such as failure of either HOST,
FTP-process, or the IMP subnet).

    The restart procedure is defined only for the block mode of
data transfer. It requires the sender of data to insert a special marker
code in teh data stream with some marker information. The marker
information has meaning only to the sender, but must consist of
printable ASCII characters. The printable ASCII characters are defined
to be codes 33. through 126. (i.e., not including codes 0. through 31.
and the characters SP and DEL). The marker could represent a bit-count,a
record-count, or any other information by wich a system may identify a
data checkpoint. The receiver of data, if it implements the restart
procedure, would then mark the corresponding position of this marker in
the receiving system, and return this information to the user.

    In the event of a system failure, the user can restart the
data transfer by identifying the marker point with the FTP restart
procedure. The following examples Illustrate the use of the restart
procedure.

    1. When server is the sender of data, the server-FTP process
inserts an appropriate marker block in the data stream at a convenient
data point. The user-FTP process receiving the data, marks the
coressponding data point in its file system and conveys the last known
sender and receiver marker information to the user. In the event of
system failure, the user or user-FTP process restarts the server at the

                                                               [Page 12]
The File Transfer Protocol                                  July 8, 1972

last server marker by sending a restart command with the server's marker
code at its argument.  The restart command is transmitted over the
TELNET connection and is immediately followed by the command (such as
store or retrieve) which was being executed when the system failure
occured.

    2. When user is the sender of data, the user-FTP process
inserts the appropriate marker block in the data stream. The server-FTP
process receiving the data, marks the corresponding data point in its
file system. The server does not store this marker but conveys the last
known sender and receiver marker information to the user over the TELNET
connections by appropriate reply codes. The user or the user-FTP process
then restarts transfer in a manner identical to that described in the
first example.

IV. FILE TRANSFER FUNCTIONS

    The TELNET connections on which FTP commands and replies are
transmitted, are initiated by the user-FTP process via an ICP to a
standard server socket. FTP commands are then transmitted from user to
server, and replies are transmitted from server to user.  The user file
transfer functions invoive sending the FTP commands, interpreting the
replies received and transferring data over the data connection in the
specified manner. The server file transfer functions involve accepting
and interpreting FTP commands, sending replies, setting up the data
connection, and transferring data.

IV.A FTP Commands

    FTP commands are ASCII terminated by the ASCII
character sequence CRLF (Carriage Return follow by Line Feed).  The
command codes themselves are ASCII alpabetic characters terminated by
the ASCII character 'space' (code = 32.). For convenience, the command
codes are defined to be four (or less) ASCII alphanumeric characters
(including both upper and lower case alphabetic characters). The command
codes and the semantics of commands are described in this section, but
the detailed syntax of commands is specified in Section V.b, the reply
sequence are discussed in Section V.C, and scenarios illustrating the
use of commands are provided in Section V.D.

    FTP commands may be partitioned as those specifying
access-control identifiers, data transfer parameters, or FTP service
requests.

                                                               [Page 13]
The File Transfer Protocol                                  July 8, 1972

IV.A.1 Access Control Commands

The following commands specify access control identifiers
       (command codes are shown in parentheses).

       User name (USER) - The argument field is an ASCII string
       identifying the user. The user identification is that wich is
       required by the server for access to its file system. This
       command will normally be the first command transmitted by the
       user after the TELNET connections are made (some servers may
       require this). Additional identification information in the form
       of pasword command may also be required by some servers.

       Password (PASS) - The argument field is an ASCII string
       identifying the user's password. This command must be immediately
       preceded by the user name command, and together it completes the
       user's identifecation for access control.

IV.A.2 Data Transfer Commands

       All data transfer parameters have default values, and the
       commands specifying data transfer parameters are required only if
       the default parameter values are to be changed.  The default
       value is teh last specified value, or if no value has been
       specified, the standard default value specified here. This
       implies that the server must "remember" the applicable default
       values. The commands may be in any order except that they must
       precede the FTP service request. The following commands specify
       data transfer parameters.

       Byte size (BYTE) - The argument is an ASCII-represented decimal
       integer (1 through 255), specifying the byte size for the data
       connection for local byte and image representation types. The
       default byte size is 8 bits.  The byte size is always 8 bits in
       the ASCII and Print file representation types. A server may
       reject specific byte size/type combinations by sending an
       appropriate reply.

       Data socket (SOCK) - The argument is a HOST-socket specification
       for the data socket to be used in data connection. There may be
       two data sockets, one from server to user and the other for user
       to server data transfer. An odd socket number defines a send
       socket and an even socket number defines a receive socket. The
       default HOST is the user HOST to which TELNET connections are
       made. The default data sockets are (U+4) and (U+5) where U is the
       socket number used in the TELNET ICP and the TELNET connections
       are on sockets (U+2) and (U+3).

                                                               [Page 14]
The File Transfer Protocol                                  July 8, 1972

       Representation Type (TYPE) - The argument is a single ASCII
       character code specifying the representation types described in
       section III.B. The following codes are assigned for type:

          A - ASCII
          I - Image
          L - Local Byte
          P - Print file in ASCII
          E - EBCDIC print file

       The default representation type is ASCII

       File Structure (STRU) - The argument is a single ASCII character
       code specifying file structure described in section III.C. The
       following codes are assigned for structure:

          F - File (no record structure)
          R - Record structure

       The default structure is File (i.e., no records).

       Transfer Mode (MODE) - The argument is a single ASCII character
       code specifying the data transfer modes described in Section
       III.C. The following codes are assigned for transfer modes:

          S - Stream (bytes, close is EOF)
          B - Block (Header with descriptor and count)
          T - Text (TELNET control mode for EOR, EOF)
          H - Hasp (specially formatted compressed data)

       The default transfer mode is Stream.

IV.A.3 FTP Service Commands.

       The FTP service commands define the file transfer or the file
       system function requested by the user. The argument of an FTP
       service command will normally be a pathname.  the syntax of
       pathnames must conform to server site conventions (with standard
       defaults applicable), except that ASCII characters must be used
       (in conformance with the TELNET Protool). The suggested default
       handling is to use the last specified device directory or file
       name, or the standard default defined for local users. The
       commands may be in any order except that a "rename from" command,
       must be followed by a "rename to" command, and some servers may
       require an "allocate" command before a "store" command. The data
       when transferred in response to FTP service commands shall always
       be over the data connection. The following commands specify FTP
       service requests:

                                                               [Page 15]
The File Transfer Protocol                                  July 8, 1972

       Retrieve (RETR) - This command achieves the transfer of a copy of
       file specified in pathname, from server to user site. The status
       and contents of a file at server site shall be unaffected.

       Store (STOR) - This command achieves the transfer of a copy of
       file from user to server site. If file specified in pathname
       exists at the server site, then its contents shall be replaced by
       the contents of the file being transferred. A new file is created
       at the server site if the file specified in pathname does not
       already exist.

       Append (with create) (APPE) - This command achieves the transfer
       of data from using to serving site. If file specified in pathname
       exists at the server site, then the data transferred shall be
       appended to that file, otherwise the file specified in pathname
       shall be created at the server site.

       Rename from (RNFR) - This command specifies the file which is to
       be renamed. This command must be immediately followed by a
       "rename to" command specifying the new file pathname.

       Delete (DELE) - This command causes teh file specified in
       pathname to be deleted at the server site. If an extra level of
       protection is desired (such as the query, "Do you really wish to
       delete?"), it should be provided by the user-FTP process.

       List (LIST) - This command causes a list to be sent from server
       to user site. If pathname specifies a directory, the server
       should transfer a list of files in the specified directory. If
       pathname specifies a file then server should send current
       information on the file. This command may be used to obtain the
       contents of a file directory (the response should be sent in
       ASCII type) or test the existence of a file and its current
       status.

       Allocate (ALLO) - This command my be required by some servers to
       reserve sufficient storage to accomodate the new file to be
       transferred. The command field shall be a decimal integer
       representing the number of bytes (of size specified by the byte
       size command) of storage to be reserved for the file. This
       command shall be followed by a store or append command. The ALLO
       command should be treated as a NO-OP (no operation) by thuse
       servers which do not require that the maximum size of the file be
       declared beforehand.

       Restart (REST) - The argument field represents the server marker
       at which file transfer is to be restarted. This command does not
       cause file transfer but "spaces" over the file to the specified

                                                               [Page 16]
The File Transfer Protocol                                  July 8, 1972

       data checkpoint. This command shall be immediately followed by
       the appropriate FTP service command which shall cause file
       transfer to resume.

       Status (STAT) - This command shall cause a status response to be
       sent over the TELNET connection in form of a reply.  The command
       may have an argument field such as a pathname.  if the argument
       is a pathname, the command is analogous to the "list" command
       except that data shall be transferred in ASCII on the TELNET
       connection. If no argument is specified, the server should return
       general status information about the server FTP process. This may
       include service availability, the current settings for the
       relevant FTP parameters (including default settings), and the
       status of command execution and connections.

       Abort (ABOR) - This command indicates to the server to abort the
       previous FTP service command and any associated transfer of data.
       The abort command should be preceded by the TELNET SYNCH
       condition (indicated by the combination of the DATA MARK and the
       INS). No action is to be taken if the previous command has been
       completed (including data transfer). The TELNET connections is
       not to be closed by the server, but the data connection may be
       closed. An appropriate reply should be sent by the server.

       Logout (BYE) - This command terminates a USER and if file
       transfer is not in progress, closes the TELNET connection.  If
       file transfer is in progress, the connection will remain open for
       result response and will then close.  During the interim a new
       USER command (and no other command) is acceptable.

       An unexpected close on TELNET connection will cause the server to
       take the effective action of an abort (ABOR) and a logout (BYE).

IV.B FTP Replies

    The server sends FTP replies to user over the TELNET
connections in response to FTP commands. The FTP replies constitute the
acknowledgement or completion code (including errors). The FTP-server
replies are formatted for human or program interpretation. The replies
consist of a leading three digit numeric code followed by a space
followed by a text explanation of the code. The numeric codes are
assigned by groups and for ease of interpretation by programs in a
manner consistent with other protocols such as the RJE protocol. The
three digits of the code are to be interpredet as follows:

                                                               [Page 17]
The File Transfer Protocol                                  July 8, 1972

a) The first digit specifies type of response as indicated below:

   000 These replies are purely informative and constitute
       neither a positive nor a negative acknowledgement.

   1xx informative replies to status inrequiries. These constitute
       a positive acknowledgment to the status command.

   2xx Positive acknowledgment of previous command or other
       successful action.

   3xx Incomplete information. Activity cannot proceed without
       further specification and input.

   4xx Unsuccessful reply. The request is correctly specified
       but the server is unsuccessful in corretly fulfilling
       it.

   5xx Incorrect or illegal command. The command or its
       parameters were invalid or incomplete from a syntactic
       viewpoint, or the command its inconsistent with a previous
       command. The command in question has been completely
       ignored.

   6xx - 9xx Reserved for future expansion.

b) The second digit specifies the general category to which
   the response refers:

   x00-x29 General purpose replies, not assignable to other
       categories.

   x30 Primary access. Informative replies to the "log-on"
       attempt.

   x40 Secondary access. The primary server is commenting on its
       ability to access a secondary service.

   x5x FTP results.

   x6x RJE resutls.

   x7x-x9x Reserved for future expansion.

                                                               [Page 18]
The File Transfer Protocol                                  July 8, 1972

c) the final digit specifies a particular message type. Since the code
is designed for an automaton process to interpret, it is not necessary
for every variation of a reply to have a unique number. Only the basic
meaning of replies need have unique numbers. The text of a reply can
explain the specific reason for that reply to a human user.

    Each TELNET line (ended by CRLF) from the server is intended
to be a complete reply message. if it is necessary to continue the text
of a reply onto following lines, then those continuation replies contain
the special reply code of three spaces. It should be noted that text of
replies are intended for a human user. Only the reply codes and in some
instances the first line of text are intended for programs.

    The assigned reply codes relating to FTP are:

000 General information message (site, time of day, etc.)
030 Server availibility information.
050 FTP commentary or user information.
100 System status reply.
150 File status reply.
151 Directory listing reply.
200 Last command received correctly.
201 An ABORT has terminated activity, as requested.
202 Abort request ignored, no activity in progress.
230 User is "logged in". may proceed.
231 User is "logged out". Service terminated.
232 Logout command noted, will complete when transfer done.
250 FTP file transfer started correctly.
251 FTP Restart-marker reply
          Text is: MARK yyyy  =  mmmm
          where yyyy is user's data stream marker (yours)
          and mmmm is server's equivalent marker (mine)
          (Note the spaces between the markers and '=').
252 FTP transfer completed correctly.
253 Rename completed.
254 Delete completed.
255 FTP server data socket reply
          Text is: SOCK nnnn
          where nnnn is decimal integer representing
          the server socket for data connection.
300 Connection greeting message, awaiting input.
301 Current command incomplete (no CRLF for long time).
330 Enter password (may be sent with hide-your-input).
400 This service not implemented.
401 This service not accepting users now, goodbye.
430 Log-on time or tries exceeded, goodbye.
431 Log-on unsuccessful. User and/or password invalid.
432 User not valid for this service.

                                                               [Page 19]
The File Transfer Protocol                                  July 8, 1972

434 Log-out forced by operator action. Phone site.
435 Log-out forced by system problem.
436 Service shutting down, goodbye.
450 FTP: File not found.
451 FTP: File access denied to you.
452 FTP: File transfer incomplete, data connection closed.
453 FTP: File transfer incomplete, insufficient storage space.
500 Last command line completely unrecognized.
501 Syntax of last command in incorrect.
502 Last command incomplete, parameters missing.
503 Last command invalid (ignored), illegal parameter combination.
504 Last command invalid, action not possible at this time.
505 Last command conflicts illegally with previous command(s).
506 Requested action not implemented by the server.

V. DECLARATIVE SPECIFICATIONS

V.A. Connections

    The server-FTP process at the server site shall "listen" on
Socket 3, via its server-TELNET. The user or user-FTP process at the
user site shall initiate the full-duplex TELNET connections via its
user-TELNET performing the ARPANET standard initial connection protocol
(ICP) to server socket 3. The TELNET connections shall be closed by the
user site upon completion of use.

    The user site shall "listen" on the specified data socket or
sockets (a send and/or a receive socket). The server site shall initiate
the data connection using the specified data socket and byte size. The
direction of data connection and the data socket used shall be
determined by the FTP service command. The server shall send a reply to
the user indicating the server data socket so that the user may ensure
the security of data transfer. This can be done at any time prior to the
first transfer of data over a data connection.

    The data connection shall be closed by the server site under
the conditions described is Section III.A. The server should in general
send a reply before closing the data connection to avoid problems at the
user end.

V.B. Commands

    The commands are ASCII character strings transmitted over
the TELNET connections as described in section IV.A. The command
functions and semantics are described in sections IV.A.1, IV.A.2,
IV.A,3, and IV.A.4. The command syntax is specified here.

                                                               [Page 20]
The File Transfer Protocol                                  July 8, 1972

    The commands begin with a command code followed by an
argument field. The command codes are four of less ASCII alphabetic
characters. Upper and lower case alphabetic characters are to be treated
identically. Thus any of the following may represent the retrieve
command:

    RETR Retr retr ReTr rETr

The command codes and the argument fields are separated by one or more
spaces.

    The argument field consists of a variable length ASCII
character string ending with the character sequence CRLF (Carriage
Return immediately followed by Line Feed). In the following section on
syntax it should be stressed that all characters in the argument field
are ASCII characters. Thus a decimal integer shall mean an ASCII
represented decimal integer.

    The following are all the currently defined FTP commands:

         USER <user name> CRLF
         PASS <password> CRLF
         BYTE <byte size> CRLF
         SOCK <HOST-socket> CRLF
         TYPE <type code> CRLF
         STRU <structure code> CRLF
         MODE <mode code> CRLF
         RETR <pathname> CRLF
         STOR <pathname> CRLF
         APPE <pathname> CRLF
         RNFR <pathname> CRLF
         RNTO <pathname> CRLF
         DELE <pathname> CRLF
         LIST <pathname> CRLF
         ALLO <decimal integer> CRLF
         REST <marker> CRLF
         STAT <pathname> CRLF
         ABOR <empty> CRLF
          Bye <empty> CRLF

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

     <username> ::= <string>
     <password> ::= <string>
     <string> ::= <empty> | <char> | <char><string>
     <char> ::= any of the 128 ASCII characters except CR and LF.
     <marker> ::= <pr string>

                                                               [Page 21]
The File Transfer Protocol                                  July 8, 1972

     <pr string> ::= <empty> | <pr char> | <pr char><pr string>
     <pr char> ::= any ASCII code 33 through 126.
     <byte size> ::= any decimal integer 1 through 255.
     <HOST-socket> ::= <socket> | <HOST number>,<socket>
     <HOST number> ::= a decimal integer specifying an ARPANET HOST.
     <socket> ::= decimal integer between o and (2**32)-1
     <type code> ::= A|I|L|P|E
     <structure code> ::= F|R
     <mode code> ::= S|B|T|H
     <pathname> ::= <string>
     <decimal integer> ::= <digit> | <digit><decimal integer>
     <digit> ::= 0|1|2|3|4|5|6|7|8|9|
     <empty> ::= the null string (specifies use of default).

V.C Sequencing of Commands and Replies

    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 of failure
response before sending further commands.

    A second type of reply is sent asynchronously with respect
to user commands. These replies may for example report on the
progress or completion of file transfer and as such are secondary
replies to file transfer commands.

    The third class of replies are informational and spontaneous
replies which may arrive at any time. These replies are listed
below as spontaneous.

               COMMAND-REPLY CORRESPONDENCE TABLE

COMMAND             SUCCESS              FAIL

USER                230,330              430-432,500-505
PASS                230                  430-432,500-505
BYE                 231,232              430-432,500-505
BYTE                200                  500-506
SOCK                200                  500-506
TYPE                200                  500-506
MODE                200                  500-506
RETR                250                  450,451,500-506
  Secondary Reply   252                  452
STOR                250                  451,451,500-506
  Secondary Reply   252                  452,453
APPE                250                  451,451,500-506
  Secondary Reply   252                  452,453

                                                               [Page 22]
The File Transfer Protocol                                  July 8, 1972

RNFR                200                  450,451,500-506
RNTO                253                  450,451,500-505
DELE                254                  450,451,500-506
LIST                250                  450,453,500-506
  Secondary Reply   252                  452
ALLO                200                  500-506
STAT                100,150,151          450,451,500-506
REST                200                  500-506
ABOR                201,202              500-505

Spontaneous         0xx,300,301          400,401,434-436
Replies             251,255

V.D. Tyical FTP Scenarious

1. TIP User wanting o transfer file from FOST X to local printer:

   a) TIP user opens TELNET connections by ICP to HOST X, socket 3.

   b) The following commands and replies are exchanged:
          TIP                           HOST X

          USER username CRLF  -------->
          <-------  330 Enter Password CRLF

          PASS password CRLF  -------->
          <-------  230 User logged in CRLF

          SOCK 65538 CRLF     -------->
          <-------  200 Command received OK CRLF

          RETR this.file CRLF -------->
          <-------  255 SOCK 5533 CRLF

          (HOST X initiates data connection to
           TIP socket 65538, i.e., PORT 1 receive)

          <------- 250 File transfer started

          BYE CRLF           ------_->
          <------- 252 File transfer completed

   c) HOST X closes the TELNET and data connections.

   Note: The TIP user should be in line mode and can thus use
         local TIP editing such as character delete.

                                                               [Page 23]
The File Transfer Protocol                                  July 8, 1972

2. User at Host U wanting to transfer files to/from HOST S:

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

Local Commands by User                  Action Involved

ftp (host) multics CR         ICP to HOST S, socket 3,
                              establishing TELNET connections.
username Doe CR               USER DoeCRLF ---->
                              <---- 330 passwordCRLF
password mumble CR            PASS mumbleCRLF ---->
                              <---- 230 Doe logged in.CRLF
retrieve (local type ASCIICR
(local pathname) test 1 CR    USER-FTP open local file in ASCII.
(for. pathname) test.pl1CR    RETR test.pl1 CRLF ---->
                              <---- 255 SOCK 1233CRLF
                              Server makes data connection to (U+4).
                              <---- 250 File transfer startsCRLF
                              <---- 252 File transfer completeCRLF
type imageCR                  TYPE |CRLF ---->
                              <---- 200 Command OKCRLF
byte 36CR                     BYTE 36CRLF ---->
                              <---- 200 Command OKCRLF
store (local type) ImageCR
(local pathname) file dumpCR  User-FTP opens local file in Image.
(for. pathname) >udd>cn>fdCR  STOR >udd>cn>fdCRLF ---->
                              <---- 451 Access deniedCRLF
terminate                     BYECRLF
                              <---- 231 Doe logged outCRLF
                              Server closes all connections.

                                                               [Page 24]
The File Transfer Protocol                                  July 8, 1972

ACKNOWLEDGEMENTS

    The work on file transfer protocol has involved many people.
This document reports the work of a group rather than the author
alone. The author gratefully acknowledges the conributions of
the following:

          Bob Braden         UCLA-CCCN
          Arvola Chan        MIT-MAC
          Bill Crowther      BBN-TIP
          Eric Harslem       RAND
          John Heafner       RAND
          Chuck Holland      UCSD
          Alex McKenzie      BBN (NET)
          Bob Metcalfe       XPARC
          Jon Postel         UCLA
          Neal Ryan          MIT-MAC
          Bob Sundberg       HARVARD
          Ray Tomlinson      BBN (TENEX)
          Dick Watson        SRI-ARC
          Jim White          SRI-ARC
          Richard Winter     CCA

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Gottfried Janik 9/97  ]

                                                               [Page 25]