As per Relevance of the word establish, we have this rfc below:
Request for Comments: 607 Mark
NIC # 21255 George
references: RFC #542 UCSB Jan 1974
Comments on the File Transfer
There are several aspects of the File Transfer Protocol that
serious drawbacks. Some of these are quite basic in nature, and
substantial design changes; these will be discussed in a later RFC
Others could be remedied with very little effort, and this should be
as soon as possible
Following is a list of those problems that can be easily solved,
with their proposed solutions
1. Once a server has been told to be "passive" with regard to
of data connections, there is no way for the user to make him "active
again. SOLUTION: define a new command, with a command verb of "ACTV",
mean that the server is to issue a CONNECT rather than a LISTEN on the
socket. If the server is already "active", the command is a no op. "ACTV
is to have the same reply codes as "PASV".
2. Design of an FTP server would be simpler if all command verbs were
same length, and design of an FTP user would be simpler if either
command verbs were the same length, or if multiple blanks were
following the verb. SOLUTION: replace the only three-letter verb, "BYE",
with a four-letter one, such as "QUIT", and constrain future command
to be four letters long
3. The order of the handshaking elements following a file transfer
is left unspecified. After sending a STOR command, for example, a
process has no way of knowing which to wait for first, the "250
TRANSFER STARTED" reply, or establishment of the data connection. SOLUTION
specify that the server is to send a "250" reply before attempting
establish the data connection. If it is desired to check if the user
logged in, if the file exists, or if the user is to be allowed access
the file, these checks must be made before any reply is sent. The text
the "250" reply would perhaps be more appropriate as "250 OPENING
CONNECTION", since it comes before actual data transfer begins. If
server wishes to send an error reply in the event that the data
cannot be opened, it is to be sent in lieu of the "252 TRANSFER COMPLETE
reply.
4. Some hosts currently send an error reply on receipt of a
that is unimplemented because it is not needed (e.g., "ACCT" or "ALLO").
Even though the text of the reply indicates that the command has
ignored, it is obviously impossible for a user process to know that
is no real "error". SOLUTION: require that any server that does not
a particular command because it is not needed in that system must return
success reply
5. There is no specified maximum length of a TELNET line, user name
password, account, or pathname. It is true that every system
an FTP server likely has different maxima for its own parameters, but it
nearly impossible for the writer of an FTP user (which must converse
many FTP servers) to construct an indefinite length buffer. Typically
-1-
arbitrary maximum must be chosen. SOLUTION: specify a maximum length
TELNET lines, user names, passwords, account numbers, and pathnames.
is to be done after conducting a poll of serving sites concerning
individual maxima
6. The notion of allowing continuation lines to start with arbitrary
solves a minor problem for a few server FTP implementers at the expense
creating a major problem for all user FTP implementers. The logic needed
decode a multi-line reply is unnecessarily complex, and made an order
magnitude more so by the fact that multi-line replies are allowed to
nested. SOLUTION: assign a unique (numeric) reply code, such as "009",
be used on all lines of a multi-line reply after the first
7. Given that multi-line replies are allowed to be nested, the fact
the maximum allowed level of nesting is left unspecified creates a
for implementers of user FTPs. This hardship is somewhat easily solved on
machine that has hardware stacks, but not so for other machines. SOLUTION
specify a maximum level of nesting of multi-line replies
8. In blocked mode, the protocol states that "all end-of-record
(EOR) are explicit, including the final one." This prohibits sending
between the final end of record and the end of file, but does not
what the receiver of data is to do if this rule is broken. That is,
the intervening data be discarded or treated as a new (final) record
SOLUTION: specify that if an end-of-file marker is not immediately
by an end-of-record marker, the intervening data is to be discarded
A major complaint about the protocol concerns the fact that the writer
an FTP user process must handle a considerable number of special
merely to determine whether or not the last command sent was successful.
is admitted that the protocol is well-defined in all the following areas
but it is important to realize that the characteristic "well-defined"
necessary, but not sufficient; for many reasons, it is very desirable
employ the simplest mechanism that satisfies all the needs. Following is
list of those drawbacks that unduly complicate the flow chart of an
user process
9. Different commands have different success reply codes. A
"USER" command, for example, returns a "230" whereas a successful "BYTE
command returns a "200". The concept that success replies should have
even first digit and failure replies an odd first digit does not apply,
"100, means success for "STAT", and "402" means failure for "BYTE".
SOLUTION: specify that any command must return a reply code beginning
some unique digit, such as "2", if successful, and anything other than
digit if not successful
10. Some commands have multiple possible success reply codes, e.g., "USER",
"REIN", and "BYE". It is undesirable for an FTP user to be required to
a list of reply codes for each command, all of which mean "
accepted, continue". SOLUTION: same as for (9.) above. The desire
communicate more specific information than simply "yes" or "no", such
the difficulty in the login procedure that some sites do not need all
parameters, may be solved by having, for example, "238" mean "
ACCEPTED, YOU ARE NOW LOGGED IN", and "237" mean "PASSWORD ACCEPTED
ACCOUNT NOW NEEDED" The important point is that the idea of "
accepted" is conveyed by the initial "2", and that finer gradations
meaning can be deduced by the user process, if desired
-2-
11. There are several types of replies that are extraneous from the
of view of a user FTP process, and their reply codes have no
that makes them easily distinguishable. For example, "010 message
operator" and "050 FTP commentary" are superfluous to a user process,
"000 announcing FTP" (in place of "300" greeting) is not. SOLUTION:
that any reply that has meaning only to a human user and not to a
process must have a reply code beginning with a unique digit, such as "0".
The continuation line reply code proposed in (8.) above falls into
category, and therefore must start with the same unique digit
12. The notion of a server sending a "000 announcing FTP" or a "020
expected delay" immediately after completion of the ICP if input cannot
accepted right away is another instance of multiple reply codes having
same meaning to a user process. SOLUTION: require that the server send
reply with a "020" reply code in the situation cited. If it is desired
communicate more detailed information, the text of the reply may used
this purpose
In addition to the above mentioned weaknesses in the protocol,
following is believed to be a typographical error
13. Reply code "331" is cited as a possible success reply code for
commands "BYTE", "SOCK", "PASV", "TYPE", "STRU", "MODE", "ALLO", "REST",
"SITE", AND "STAT". This reply code means "ENTER ACCOUNT" (if required
part of login sequence), and perhaps should be "332 LOGIN FIRST, PLEASE".
This is especially indicated by the fact that "332" is not listed
in the command-reply correspondence table
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
