As per Relevance of the word requested, we have this rfc below:
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843
Revised FTP Reply
Jon
19 JUN 75
Revised FTP Reply Codes 1
This document describes a revised set of reply codes for the
Transfer Protocol. 2
The aim of this revision is to satisfy the goal of using
codes to enable the command issuing process to easily
the outcome of each command. The user protocol interpreter
be able to determine the success or failure of a command
examining the first digit of the reply code. 3
An important change in the sequencing of commands and
which may not be obvious in the following documents concerns
establishment of the data connection. 4
In the previous FTP specifications when an actual
command (STOR, RETR, APPE, LIST, NLIST, MLFL) was issued
preliminary reply was sent after the data connection
established. This presented a problem for some user
interpreters which had difficulty monitoring two
asynchronously. 4
The current specification is that the preliminary reply to
actual transfer commands indicates that the file can
transferred and either the connection was
established or an attempt is about to be made to establish
data connection. 4
This reply code revision is a modification of the protocol
described in RFC 542, that is to say that the
implementation associated with socket number 21 (decimal) is
protocol specified by the combination of RFC 542 and this RFC. 5
A note of thanks to those who contributed to this work:
Pogran, Mark Krilanovich, Wayne Hathway, and especially
Neigus. 6
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843
Nancy
Ken
Jon
19 JUN 75
A New Schema for FTP Reply Codes 7
Replies to File Transfer Protocol commands were devised to
the synchronization of requests and actions in the process
file transfer, and to guarantee that the user process
knows the state of the Server. Every command must generate
least one reply, although there may be more than one; in
latter case, the multiple replies must be easily distinguished
In addition, some commands occur in sequential groups, such
USER, PASS and ACCT, or RNFR and RNTO. The replies show
existence of an intermediate state if all preceding commands
been successful. A failure at any point in the
necessitates the repetition of the entire sequence from
beginning. 8
Details of the command-reply sequence will be made explicit
a state diagram. 8
An FTP reply consists of a three digit number (transmitted
three alphanumeric characters) followed by some text. The
is intended for use by automata to determine what state to
next; the text is intended for the human user. It is
that the three digits contain enough encoded information that
user-process (the User-PI described in RFC 542) will not need
examine the text and may either discard it or pass it on to
user, as appropriate. In particular, the text may
server-dependent, so there are likely to be varying texts
each reply code. 9
Formally, a reply is defined to contain the 3-digit code
followed by Space , followed by one line of text (where
maximum line length has been specified), and terminated by
TELNET end-of-line code. There will be cases, however, where
text is longer than a single line. In these cases the
text must be bracketed so the User-process knows when it may
reading the reply (i.e. stop processing input on the
connection) and go do other things. This requires a
format on the first line to indicate that more than one line
coming, and another on the last line to designate it as the last
At least one of these must contain the appropriate reply code to
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843
Neigus FTP Reply Codes [3]
indicate the state of the transaction. To satisfy all
it was decided that both the first and last line codes should
the same. 10
Thus the format for multi-line replies is that the first
will begin with the exact required reply code,
immediately by a Hyphen, "-" (also known as Minus),
by text. The last line will begin with the same code
followed immediately by Space , optionally some text,
TELNET . 10
For example
123-First
Second
234 A line beginning with
123 The last line 10a
The user-process then simply needs to search for the
occurrence of the same reply code, followed by (Space),
at the beginning of a line, and ignore all intermediary lines
If an intermediary line begins with a 3-digit number,
Server must pad the front to avoid confusion. 10
This scheme allows standard system routines to be used
reply information (such as for the STAT reply),
"artificial" first and last lines tacked on. In the
cases where these routines are able to generate
digits and a Space at the beginning of any line,
beginning of each text line should be offset by
neutral text, like Space. 10b
This scheme assumes that multi-line replies may not be nested
We have found that, in general, nesting of replies will
occur, except for random system messages (called
replies in the previous FTP incarnations) which may
another reply. Spontaneous replies are no longer defined
system messages (i.e. those not processed by the FTP server
will NOT carry reply codes and may occur anywhere in
command-reply sequence. They may be ignored by
User-process as they are only information for the human user. 10
The three digits of the reply each have a special significance
This is intended to allow a range of very simple to
sophisticated response by the user-process. The first
denotes whether the response is good, bad or incomplete
(Referring to the state diagram) an unsophisticated user-
will be able to determine its next action (proceed as planned
redo, retrench, etc.) by simply examining this first digit.
user-process that wants to know approximately what kind of error
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843
Neigus FTP Reply Codes [4]
occurred (e.g. file system error, command syntax error)
examine the second digit, reserving the third digit for
finest gradation of information (e.g. RNTO command without
preceding RNFR.) 11
There are four values for the first digit of the reply code: 11
1yz Positive Preliminary reply 11
The requested action is being initiated; expect
reply before proceeding with a new command. (
user-process sending another command before the
reply would be in violation of protocol; but server-
processes should queue any commands that arrive while
preceeding command is in progress.) This type of reply
be used to indicate that the command was accepted and
user-process may now pay attention to the data connections
for implementations where simultaneous monitoring
difficult. 11b
2yz Positive Completion reply 11
The requested action has been successfully completed.
new request may be initiated. 11c
3yz Positive Intermediate reply 11
The command has been accepted, but the requested action
being held in abeyance, pending receipt of
information. The user should send another
specifying this information. This reply is used in
sequence groups. 11d
4yz Transient Negative Completion reply 11
The command was not accepted and the requested action
not take place, but the error condition is temporary
the action may be requested again. The user should
to the beginning of the command sequence, if any. It
difficult to assign a meaning to "transient",
when two distinct sites (Server and User-processes) have
agree on the interpretation. Each reply in the 4
category might have a slightly different time value,
the intent is that the user-process is encouraged to
again. A rule of thumb in determining if a reply fits
the 4yz or the 5yz (Permanent Negative) category is
replies are 4yz if the commands can be repeated without
change in command form or in properties of the User
Server (e.g. the command is spelled the same with the same
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843
Neigus FTP Reply Codes [5]
arguments used; the user does not change his file access
user name; the server does not put up a
implementation.) 11e
5yz Permanent Negative Completion reply 11
The command was not accepted and the requested action
not take place. The User-process is discouraged
repeating the exact request (in the same sequence).
some "permanent" error conditions can be corrected, so
human user may want to direct his User-process
reinitiate the command sequence by direct action at
point in the future (e.g. after the spelling has
changed, or the user has altered his directory status.) 11f
The following function groupings are encoded in the
digit: 11
x0z Syntax - These replies refer to syntax errors
syntactically correct commands that don't fit
functional category, unimplemented or
commands. 11g
x1z Information - These are replies to requests
information, such as status or help. 11g
x2z Connections - Replies referring to the TELNET
data connections. 11g
x3z Authentication and accounting - Replies for the
process and accounting procedures. 11g
x4z Unspecified as yet 11g
x5z File system - These replies indicate the status
the Server file system vis-a-vis the
transfer or other file system action. 11g
The third digit gives a finer gradation of meaning in each
the function categories, specified by the second digit.
list of replies below will illustrate this. Note that
text associated with each reply is suggestive, rather
mandatory, and may even change according to the command
which it is associated. The reply codes, on the other hand
should strictly follow the specifications in the last section
that is, Server implementations should not invent new
for situations that are only slightly different from the
described here, but rather should adapt codes already defined.
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843
Neigus FTP Reply Codes [6]
If additional codes are found to be necessary, the
should be submitted to the FTP committee, through Jon Postel. 11
A command such as TYPE or ALLO whose successful
does not offer the user-process any new information
cause a 200 reply to be returned. If the command is
implemented by a particular Server-FTP process because
has no relevance to that computer system, for example
at a TENEX site, a Positive Completion reply is
desired so that the simple User-process knows it
proceed with its course of action. A 202 reply is used
this case with, for example, the reply text: "No
allocation necessary." If, on the other hand, the
requests a non-site-specific action and is unimplemented
the response is 502. A refinement of that is the 504
for a command that IS implemented, but that requests
unimplemented parameter. 11h
11
200 Command okay 11i
500 Syntax error, command
[This may include errors such as command line
long.] 11i
501 Syntax error in parameters or arguments 11i
202 Command not imlemented, superfluous at this site. 11i
502 Command not implemented 11i
503 Bad sequence of commands 11i
504 Command not implemented for that parameter 11i
11
110 Restart marker reply
In this case the text is exact and not left to
particular implementation; it must read
MARK yyyy =
where yyyy is User-process data stream marker,
mmmm is Server's equivalent marker. (note
spaces between the markers and "=".) 11j
211 System status, or system help reply 11j
212 Directory status 11j
213 File status 11j
214 Help message (on how to use the server or the
of a particular non-standard command. This
is useful only to the human user.) 11j
11
120 Service ready in nnn minutes 11k
220 Service ready for new user 11k
221 Service closing TELNET connection (logged off
appropriate) 11k
421 Service not available, closing TELNET connection
[This may be a reply to any command if the
knows it must shut down.] 11k4
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843
Neigus FTP Reply Codes [7]
125 Data connection already open; transfer starting 11k
225 Data connection open; no transfer in progress 11k
425 Can't open data connection 11k
226 Closing data connection; requested file
successful (for example, file transfer or
abort.) 11k
426 Connection trouble, closed; transfer aborted. 11k
227 Entering [passive, active] mode 11k10
11
230 User logged on, proceed 11l
530 Not logged in 11l
331 User name okay, need password 11l
332 Need account for login 11l
532 Need account for storing files 11l
11
150 File status okay; about to open data connection. 11m
250 Requested file action okay, completed. 11m
350 Requested file action pending further information 11m
450 Requested file action not taken: file
(e.g. file not found, no access) 11m
550 Requested action not taken: file unavailable (e.g
file busy) 11m
451 Requested action aborted: local error in processing 11m
452 Requested action not taken: insufficient
space in system 11m
552 Requested file action aborted: exceeded
allocation (for current directory or dataset) 11m
553 Requested action not taken: file name not allowed 11m
354 Start mail input; end with . 11m10
Command-Reply Sequences 12
In this section, the command-reply sequence is presented.
command is listed with its possible replies; command groups
listed together. Preliminary replies are listed first (
their succeeding replies under them), then positive and
completion, and finally intermediary replies with the
commands from the sequence following. This listing forms
basis for the state diagrams, which will be presented separately. 13
ICP 13
120 13a
220 13a1
220 13a
421 13a3
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843
Neigus FTP Reply Codes [8]
Logon 13
USER 13b
230 13b1
530 13b1
500, 501, 421 13b1
331, 332 13b1
PASS 13b
230 13b2
202 13b2
530 13b2
500, 501, 503, 421 13b2
332 13b2
ACCT 13b
230 13b3
202 13b3
530 13b3
500, 501, 503, 421 13b3
Logoff 13
QUIT 13c
221 13c1
500 13c1
REIN 13c
120 13c2
220 13c2a
220 13c2
421 13c2
500, 502 13c2
Transfer parameters 13
SOCK 13d
200 13d1
500, 501, 421, 530 13d1
PASV 13d
227 13d2
500, 501, 502, 421, 530 13d2
ACTV 13d
227 13d3
202 13d3
500, 501, 421, 530 13d3
BYTE, MODE, TYPE, STRU 13d
200 13d4
500, 501, 504, 421, 530 13d4b
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843
Neigus FTP Reply Codes [9]
File action commands 13
ALLO 13e
200 13e1
202 13e1
500, 501, 504, 421, 530 13e1
REST 13e
500, 501, 502, 421, 530 13e2
350 13e2
STOR 13e
125, 150 13e3
(110) 13e3a
226, 250 13e3a
425, 426, 451, 552 13e3a
532, 450, 452, 553 13e3
500, 501, 421, 530 13e3
RETR 13e
125, 150 13e4
(110) 13e4a
226, 250 13e4a
425, 426, 451 13e4a
450, 550 13e4
500, 501, 421, 530 13e4
LIST, NLST 13e
125, 150 13e5
226, 250 13e5a
425, 426, 451 13e5a
450 13e5
500, 501, 502, 421, 530 13e5
APPE 13e
125, 150 13e6
(110) 13e6a
226, 250 13e6a
425, 426, 451, 552 13e6a
532, 450, 550, 452, 553 13e6
500, 501, 502, 421, 530 13e6
MLFL 13e
125, 150 13e7
226, 250 13e7a
425, 426, 451, 552 13e7a
532, 450, 550, 452, 553 13e7
500, 501, 502, 421, 530 13e7
RNFR 13e
450, 550 13e8
500, 501, 502, 421, 530 13e8
350 13e8
RNTO 13e
250 13e9
532, 553 13e9b
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843
Neigus FTP Reply Codes [10]
500, 501, 502, 503, 421, 530 13e9
DELE 13e10
250 13e10
450, 550 13e10
500, 501, 502, 421, 530 13e10
ABOR 13e11
225, 226 13e11
500, 501, 502, 421 13e11
MAIL 13e12
354 13e12
250 13e12a
451, 552 13e12a
450, 550, 452, 553 13e12
500, 501, 502, 421, 530 13e12
Informational commands 13
STAT 13f
211, 212, 213 13f1
450 13f1
500, 501, 502, 421, 530 13f1
HELP 13f
211, 214 13f2
500, 501, 502, 421 13f2
Miscellaneous commands 13
SITE 13g
200 13g1
202 13g1
500, 501, 530 13g1
NOOP 13g
200 13g2
500 13g2b
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843
Jon
19 JUN 75
FTP State Diagrams 14
Here we present state diagrams for a very simple minded
implementation. Only the first digit of the reply codes is used
There is one state diagram for each group of FTP commands
command sequences. 15
The command groupings were determined by constructing a model
each command then collecting together the commands
structurally identical models. 16
For each command or command sequence there are three
outcomes: success (S), failure (F), and error (E). In the
diagrams below we use the symbol B for "begin", and the symbol
for "wait for reply". 17
We first present the diagram that represents the largest group
FTP commands: 18
1,3 +---+
----------->! E !
! +---+
!
+---+ cmd +---+ 2 +---+
! B !---------->! W !---------->! S !
+---+ +---+ +---+
!
! 4,5 +---+
----------->! F !
+---+
18
This diagram models the commands: 18
ABOR, ACTV, ALLO, BYTE, DELE, HELP, MODE, NOOP, PASV, QUIT
SITE, SOCK, STAT, STRU, TYPE. 18b1
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843
Postel FTP State Diagrams [12]
The other large group of commands is represented by a
similar diagram: 19
3 +---+
----------->! E !
! +---+
!
+---+ cmd +---+ 2 +---+
! B !---------->! W !---------->! S !
+---+ --->+---+ +---+
! ! !
! ! ! 4,5 +---+
! 1 ! ----------->! F !
----- +---+
19
This diagram models the commands: 19
APPE, (ICP), LIST, MLFL, NLST, REIN, RETR, STOR. 19b
Note that this second model could also be used to represent
first group of commands, the only difference being that in
first group the 100 series replies are unexpected and
treated as error, while the second group expects (some
require) 100 series replies. 20
The remaining diagrams model command sequences, perhaps
simplest of these is the rename sequence: 21
+---+ RNFR +---+ 1,2 +---+
! B !---------->! W !---------->! E !
+---+ +---+ -->+---+
! ! !
3 ! ! 4,5 !
-------------- ------ !
! ! ! +---+
! ------------->! S !
! ! 1,3 ! ! +---+
! 2! --------
! ! ! !
V ! ! !
+---+ RNTO +---+ 4,5 ----->+---+
! !---------->! W !---------->! F !
+---+ +---+ +---+
21a
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843
Postel FTP State Diagrams [13]
A very similar diagram models the Mail command: 22
+---+ MAIL +---+ 1,2 +---+
! B !---------->! W !---------->! E !
+---+ +---+ -->+---+
! ! !
3 ! ! 4,5 !
-------------- ------ !
! ! ! +---+
! ------------->! S !
! ! 1,3 ! ! +---+
! 2! --------
! ! ! !
V ! ! !
+---+ text +---+ 4,5 ----->+---+
! !---------->! W !---------->! F !
+---+ +---+ +---+
22
Note that the "text" here is a series of lines sent from
user to the server with no response expected until the
line is sent, recall that the last line must consist only of
single period. 22b
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843
Postel FTP State Diagrams [14]
The next diagram is a simple model of the Restart command: 23
+---+ REST +---+ 1,2 +---+
! B !---------->! W !---------->! E !
+---+ +---+ -->+---+
! ! !
3 ! ! 4,5 !
-------------- ------ !
! ! ! +---+
! ------------->! S !
! ! 3 ! ! +---+
! 2! --------
! ! ! !
V ! ! !
+---+ cmd +---+ 4,5 ----->+---+
! !---------->! W !---------->! F !
+---+ -->+---+ +---+
! !
! 1 !
------
23
Where "cmd" is APPE, STOR, RETR, or MLFL. 23a
We note that the above three models are similar, in fact the
diagram and the Rename diagram are structurally identical.
Restart differs from the other two only in the treatment of 100
series replies at the second stage. 24
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843
Postel FTP State Diagrams [15]
The most complicated diagram is for the Logon sequence: 25
1
+---+ 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 !
+---+ +---+------------->+---+
25a
NWG/RFC# 640 JBP NJN 5-JUN-74 16:07 30843
Postel FTP State Diagrams [16]
Finally we present a generalized diagram that could be used
model the command and reply interchange: 26
------------------------------------
! !
Begin ! !
! V !
! +---+ cmd +---+ 2 +---+ !
-->! !------->! !---------->! ! !
! ! ! W ! ! S !-----!
-->! ! -->! !----- ! ! !
! +---+ ! +---+ 4,5 ! +---+ !
! ! ! ! ! ! !
! ! ! 1! !3 ! +---+ !
! ! ! ! ! ! ! ! !
! ! ---- ! ---->! F !-----
! ! ! ! !
! ! ! +---+
-------------------
!
!
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
