As per Relevance of the word successful, we have this rfc below:
Network Working Group Mark Krilanovich (UCSB
Request for Comments: 624 George Gregg (UCSB
NIC #22054 Wayne Hathaway (AMES-67)
references: RFC 542 Jim White (SRI-ARC
obsoletes: RFC 607 Feb 1974
Comments on the File Transfer
This document replaces RFC 607, which was inadvertently
while still in rough draft form. It would be appreciated if RFC 607
were disregarded, and this document considered the accurate
of the authors' opinions
There are several aspects of the File Transfer Protocol of
542 that constitute serious drawbacks. Some of these are quite
in nature, and imply substantial design changes; these will
discussed in a later RFC. Others could be remedied with very
effort, and this should be done as soon as possible
Following is a list of those problems that can be easily solved
together with their proposed solutions
1. Once a server has been set to the state where he is "passive
with regard to establishment of data connections, there is
convenient way for the user to make him "active" again.
"REIN" command accomplishes this, but affects more than just
desired active/passive state. SOLUTION: define a new command
with a command verb of "ACTV", to mean that the server is to
a CONNECT rather than a LISTEN on the data socket. If the
is already "active", the command is a no op. "ACTV" is to
the same reply codes as "PASV".
2. Design of an FTP server or user would be simpler if
command verbs were the same length. While it is
possible to handle varying length verbs, fixed length
manipulation is in general easier to write and faster to run
varying length string manipulation, and it would seem that
is to be gained in this application by allowing varying
strings. SOLUTION: replace the only three-letter verb, "BYE",
with a four-letter one, such as "QUIT", and constrain
command verbs to be four letters long
3. The order of the handshaking elements following a file
command is left unspecified. After sending a STOR command,
example, a user process has no way of knowing which to wait
first, the "250 FILE TRANSFER STARTED" reply, or establishment
the data connection. SOLUTION: specify that the server is
send a "250" reply before attempting to establish the
connection. If it is desired to check if the user is logged in
if the file exists, or if the user is to be allowed access to
file, these checks must be made before any reply is sent.
text of the "250" reply would perhaps be more appropriate as "250
OPENING DATA CONNECTION", since it comes before actual
transfer begins. If the server wishes to send an error reply
the event that the data connection cannot be opened, it is to
sent in lieu of the "252 TRANSFER COMPLETE" reply
-1-
4. Some hosts currently send an error reply on receipt of
command that is unimplemented because it is hot needed (e.g.,
"ACCT" or "ALLO"). Even though the text of the reply
that the command has been ignored, it is obviously impossible
a user process to know that there is no real "error". SOLUTION
require that any server that does not support a particular
because it is not needed in that system must return the
reply for that command
5. There is no specified maximum length of a TELNET command line
TELNET reply line, user name, password, account, or pathname.
is true that every system implementing an FTP server likely
different maxima for its own parameters, but it is inconvenient
at least in some systems, for the writer of an FTP user (
must converse with many FTP servers) to construct an
length buffer. Similar difficulties confront the writer of
server FTP. SOLUTION: specify a maximum length for
command lines, TELNET replies, user names, passwords,
numbers, and pathnames. This is to be done after conducting
Poll of serving sites concerning their individual maxima.
Network mail is to be included in FTP, the mail text, if sent
the TELNET connection, is to be subject to the same line
maximum
6. The notion of allowing continuation lines to start
arbitrary text solves a minor problem for a few server
implementors at the expense of creating a major problem for
user FTP implementors. The logic needed to decode a multi-
reply is unnecessarily complex, and made an order of
more so by the fact that multi-line replies arc allowed to
nested. SOLUTION: assign a unique (numeric) reply code, such
"009", to be used on all lines of a multi-line reply after
first. The reply code used for this purpose must begin with "0"
(it cannot be three blanks, for example), so that it will
as extraneous to a user process by virtue of the already
rules concerning reply code groupings
7. If it is the case that the above solution to (6) is
accepted, the fact that the maximum allowed level of nesting
left unspecified creates a hardship for implementors of user FTPs
This hardship is somewhat easily solved on a machine that
hardware stacks, but not so for other machines. SOLUTION:
disallow nested replies (preferred), or specify a maximum level
nesting of multi-line replies
8. The prose descriptions of the meanings of the various
codes are in several cases unclear or ambiguous. For example,
code "020" is explained only as "announcing FTP". It is given
a reply that can be issued when a server cannot accept
immediately after an ICP, but its exact meaning is not obvious
Also. the code "331" is said to mean "ENTER ACCOUNT (if
as part of login sequence)", but is listed as a possible
reply for most of the commands. The explanation indicates that
is only valid in the login sequence, but the command-
-2-
correspondence table implies that it also means, "I can't do
without an account". SOLUTION: an expanded effort should be
by those who originated the reply codes to define them
completely
A major complaint about the protocol concerns the fact that
writer of an FTP user process must handle a considerable number
special cases merely to determine Whether or not the last
sent was successful. It is admitted that the protocol
well-defined in all the following areas, but it is important
realize that the characteristic "well-defined" is necessary, but
sufficient; for many reasons, it is very desirable to employ
simplest mechanism that satisfies all the needs. Following is a
of those drawbacks that unduly complicate the flow chart of an
user process
9. Different commands have different success reply codes.
successful "USER" command, for example, returns a "230", whereas
successful "BYTE" command returns a "200". The stated
that the first digit would carry this information does not apply
as "100" means success for "STAT", and "200" means success
"SOCK". SOLUTION: specify that any command must return a
code beginning with some unique digit, such as "2", if successful
and anything other than that digit if not successful.
example this includes changing the success reply for STAT
Perhaps to "200".
10. Some commands have multiple possible success reply codes
e.g., "USER" and "REIN". It is undesirable for ah FTP user to
required to keep a list of reply codes for each command, all
which mean "command accepted, continue". Again, the
concept concerning the first digit fails, as "230" and "330"
in truth both acknowledgments to a successful "USER" command
SOLUTION: same as for (9) above. The desire to communicate
specific information than simply "yes" or "no", such as
difficulty that some servers do not need all the login parameters
may be solved by having, for example, "230" mean "
ACCEPTED, YOU ARE NOW LOGGED IN", and "237" mean "
ACCEPTED, ACCOUNT NOW NEEDED". Given the solution to (4) above,
user process becomes much less interested in the
between "YOU ARE NOW LOGGED IN" and "ACCOUNT NOW NEEDED".
important point is that the idea of "command accepted" is
by the initial "2, and that finer gradations of meaning can
deduced by the user process, if desired
11. The meanings of the various connection greeting reply
are somewhat inconsistent. "300 connection greeting,
input", if intended as a positive acknowledgments to the ICP
should be a 200-series reply, or if intended to be
informative, a 000-series reply. If the former, then clearly "020
expected delay" is the corresponding negative acknowledgments,
should be a 400-series reply. It is however unlikely
notification of an expected delay would be of importance to a
Process without knowledge of the length of the delay. SOLUTION.:
change "300 connection greeting" to a 000-series reply,
-3-
"011" (preferred), or change "300 connection greeting" to
200-series reply, perhaps "211", and "020 expected delay" to
400-series reply, perhaps "411".
In addition to the above mentioned weaknesses in the protocol
the following is believed to be a typographical error
12. Reply code "332 LOGIN PLEASE" is not listed anywhere in
command-reply correspondence table. It Would seem that this
be a more-information-needed (success) reply for all
commands which require the user to be logged in. It should
be stressed that the "332" code is to be used for this purpose,
many servers currently use other codes, such as "451" and "504",
to mean "LOGIN PLEASE".
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
