as follows:
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 acknowledgment.
1xx Informative replies to status inquiries. These constitute a
positive acknowledgment to the status command.
2xx Positive acknowledgment of previous command or other success-
ful 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 correctly fulfilling it.
5xx Incorrect or illegal command. The command or its parameters
were invalid or incomplete from a syntactic viewpoint, or the
command is 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 results.
x7x-x9x Reserved for future expansion.
c) The final digit specifies a particular message type. Since the
code is designed for an automation 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 delimited by a numeric code and CRLF (or group
of text lines bounded by coded lines) that is sent by the server
is intended to be a complete reply message. It should be noted
that the text of replies is 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.).
010 Message from system operator.
030 Server availability information.
050 FTP commentary or user information.
100 System status reply.
110 System busy doing...
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.
233 User is "logged out". Parameters reinitialized.
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 a decimal integer representing
the server socket for data connection
256 Mail completed.
300 Connection greeting message, awaiting input.
301 Current command incompleted (no CRLF for long time).
330 Enter password
331 Enter account (if account required as part of login
sequence).
350 Enter mail, terminate by a line with only a '.'
400 This service not implemented.
401 This service not accepting user now, goodbye.
430 Log-on time or tries exceeded, goodbye.
431 Log-on unsuccessful. Usre and/or password invalid.
432 User not valid for this service.
433 Cannot transfer files without valid account. Enter account.
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.
454 FTP: Cannot connect to your data socket.
455 FTP: File system error not covered by other reply codes.
456 FTP: Name duplication rename failed.
457 FTP: Transfer parameters in error.
500 Last command line completely unrecognized.
501 Syntax of last command is incorrect.
502 Last command incomplete, parameters missing.
123456789012345678901234567890123456789012345678901234567890123456789012
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.
507 Catchall error reply.
550 Bad pathname specification (e.g., syntax error).
V. DECLARATIVE SPECIFICATIONS
In order to make FTP workable without needless error messages, the
following minimum implementation is required for servers:
TYPE -- ASCII (with 8-bit bytes)
MODE -- Stream
STRUCTURE -- File
Record (with ASCII type and CRLF for EOR)
FORM -- Unformatted
COMMANDS -- USER, BYE, SOCK
TYPE, BYTE, MODE, STRU, FORM
for the default values
RETR, STOR
NOOP
The initial default values for transfer parameters are:
TYPE -- ASCII
BYTE -- 8
MODE -- Stream
STRU -- File
FORM -- Unformatted
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. Servers may specify that interaction over the TEL-
NET connections be line-at-a-time with local echo. The server is not
obliged to provide remote echo and may ignore TELNET control charac-
ters; he should not, however, return error response to the latter.
All editing of command lines similarly must be local. The TELNET
connections shall be closed by the user site upon completion of use
and receipt of the last server reply.
The user site must "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
ensue the security of data transfer. This can be done at any time
prior to the first transfer of data over a data connection. It
should be emphasized that the user-FTP should not wait for a 255
(server data socket) reply before doing the "listen", since there is
no guarantee that the reply will arrive before the user site receives
the initiating RFC. The security check can be done when the reply
arrives and the data connection closed if it was made to a socket
other than the one specified.
The data connection shall be closed by the server site under the con-
ditions described in Section III.A. If the server wishes to close
the connection in modes where that is not required, it is recommended
that the close be sent immediately after the file transfer is com-
pleted rather than after a new transfer command is received, because
the user or server may have to test the state of the socket before
doing a "listen" or "init". The server should in general send a
reply before closing the data connection to avoid problems at the
user end, though, for reasons stated above, the user-FTP should not
wait for the reply before doing his close.
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.
The commands begin with a command code followed by an argument field.
The command codes are four or less ASCII alphabetic characters.
Upper and lower case alphabetic characters are to be treated identi-
cally. Thus any of the following may represent the retrieve command:
RETR Retr retr ReTr rETr
This also applies to any symbols representing parameters 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 ASCII character
string ending with the character sequence CRLF (Carriage Return
immediately followed by Line Feed). In the following section on syn-
tax 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 <username> CRLF
PASS <password> CRLF
ACCT <acctno> CRLF
REIN CRLF
BYE CRLF
BYTE <byte size> CRLF
SOCK <HOST-socket> CRLF
LSTN <direction> CRLF
TYPE <type code> CRLF
FORM <form code> CRLF
STRU <structure code> CRLF
MODE <mode code> CRLF
RETR <pathname> CRLF
STOR <pathname> CRLF
APPE <pathname> CRLF
ALLO <decimal integer> CRLF
REST <marker> CRLF
RNFR <pathname> CRLF
RNTO <pathname> CRLF
ABOR CRLF
DELE <pathname> CRLF
LIST <pathname> CRLF
NLST <pathname> CRLF
STAT <pathname> CRLF
HELP <string> CRLF
MLFL <users> CRLF
MAIL <users> CRLF
NOOP CRLF
QUOT CRLF
NQUO CRLF
The syntax of the above argument fields (using BNF notation where
applicable) is:
<username> ::= <string>
<password> ::= <string>
<acctno> ::= <string>
<string> ::= <empty>/<char>/<char><string>
<char> ::= any of the 128 ASCII characters except CR and LF.
<marker> ::= <pr string>
<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 0 and (2**32)-1
<direction> ::= S/R
<form code> ::= U/P
<type code> ::= A/E/I/L
<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 the default).
<users> ::= <user>|<user,<users>
<user> ::= <empty>|<NIC ident>|<sys ident>
<NIC ident> ::= <string>
<sys ident> ::= <string>
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 or 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,507
PASS 230,331 430-432,500-507
ACCT 230 430-432,500-507
REIN 232,233 401,436,500-507
Secondary Reply 300
BYE 231,232 430-432,500-505,507
BYTE 200,331 500-507
SOCK 200,331 500-505,507
LSTN 255,331 500-507
TYPE 200,331 500-507
FORM 200,331 500-507
STRU 200,331 500-507
MODE 200,331 500-507
RETR 250,331 433,450,451,454,455,500-505,507,550
Secondary Reply 252 452
STOR 250,331 433,451,454,455,457,500-505,507,550
Secondary Reply 252 452,453
APPE 250,331 433,451,454,455,457,500-507,550
Secondary Reply 252 452,453
ALLO 200,331 500-507
REST 200,331 500-507
RNFR 200,331 433,450,451,455,500-507,550
RNTO 253,331 433,450,451,455,456,500-505,507,550
ABOR 201,202,331 500-507
DELE 254,331 433,450,451,455,500-507,550
LIST 250,331 433,450,451,454,455,457,500-507,550
Secondary Reply 252 452
NLST 250,331 433,450,451,454,455,457,500-507
Secondary Reply 252 452
STAT 100,110,150, 450,451,454,455,500-507,550
151,331
HELP 000,030,050, 500-507
331
MLFL 250,331 433,450,451,454,455,457,500-507
Secondary Reply 252 452,453
MAIL 331,350 433,450,451,455,500-507
Secondary Reply 256
NOOP 200 500-505,507
QUOT 200,331 500-507
NQUO 200 500-505,507
Spontaneous 0xx,300,301 400,401,434-436
Replies 251,255
V.D Typical FTP Scenarios
1. TIP User wanting to transfer file from HOST 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.
2. User at HOST U wanting to transfer files to/from HOST S:
In general the user would communicate to the server via a mediat-
ing 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.
Local Commands by User Action Involved
---------------------- ---------------
ftp (host) multics CR ICP to HOST S, socket 3,
establishing TELNET connections.
username Doe CR USER Doe CRLF ---->
<---- 330 password CRLF
password mumble CR PASS mumble CRLF ---->
<---- 230 Doe logged in. CRLF
retrieve (local type) ASCII CR
(local pathname) test 1 CR User-FTP opens local file in ASCII.
(for.pathname) test.p11 CR RETR test.p11 CRLF
<---- 255 SOCK 1233 CRLF
Server makes data connection to (U+4).
<---- 250 File transfer starts CRLF
<---- 252 File transfer complete CRLF
type ImageCR TYPE I CRLF ---->
<---- 200 Command OK CRLF
byte 36CR BYTE 36 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 ---->
<---- 451 Access denied CRLF
terminate <---- 231 Doe logged out CRLF
Server closes all connections.
[ This RFCwas put into machine readable form for entry ]
[ into the online RFCarchives by Via Genie 03/00 ]