1 files changed, 175 insertions, 0 deletions
diff --git a/doc/rfc/rfc607.txt b/doc/rfc/rfc607.txt
new file mode 100644
index 0000000..18e9c5b
--- /dev/null
+++ b/doc/rfc/rfc607.txt
@@ -0,0 +1,175 @@
+Request for Comments: 607                                 Mark Krilanovich
+NIC # 21255                                                   George Gregg
+references: RFC #542 UCSB                                       Jan  1974
+                                                      
+
+                 Comments on the File Transfer Protocol
+
+
+There are several aspects of the File Transfer Protocol that constitute
+serious drawbacks. Some of these are quite basic in nature, and imply
+substantial design changes; these will be discussed in a later RFC.
+Others could be remedied with very little 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 told to be "passive" with regard to establishment
+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", to
+mean that the server is to issue a CONNECT rather than a LISTEN on the data
+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 the
+same length, and design of an FTP user would be simpler if either all
+command verbs were the same length, or if multiple blanks were allowed
+following the verb. SOLUTION: replace the only three-letter verb, "BYE",
+with a four-letter one, such as "QUIT", and constrain future command verbs
+to be four letters long.
+
+3. The order of the handshaking elements following a file transfer command
+is left unspecified. After sending a STOR command, for example, a user
+process has no way of knowing which to wait for first, the "250 FILE
+TRANSFER STARTED" reply, or establishment of the data connection. SOLUTION:
+specify that the server is to send a "250" reply before attempting to
+establish the data 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
+the file, these checks must be made before any reply is sent. The text of
+the "250" reply would perhaps be more appropriate as "250 OPENING DATA
+CONNECTION", since it comes before actual data transfer begins. If the
+server wishes to send an error reply in the event that the data connection
+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 command
+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 been
+ignored, it is obviously impossible for a user process to know that there
+is no real "error". SOLUTION: require that any server that does not support
+a particular command because it is not needed in that system must return a
+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 implementing
+an FTP server likely has different maxima for its own parameters, but it is
+nearly impossible for the writer of an FTP user (which must converse with
+many FTP servers) to construct an indefinite length buffer. Typically some
+
+                                     -1-
+arbitrary maximum must be chosen. SOLUTION: specify a maximum length for
+TELNET lines, user names, passwords, account numbers, and pathnames. This
+is to be done after conducting a poll of serving sites concerning their
+individual maxima.
+
+6. The notion of allowing continuation lines to start with arbitrary text
+solves a minor problem for a few server FTP implementers at the expense of
+creating a major problem for all user FTP implementers. The logic needed to
+decode a multi-line reply is unnecessarily complex, and made an order of
+magnitude more so by the fact that multi-line replies are allowed to be
+nested. SOLUTION: assign a unique (numeric) reply code, such as "009", to
+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 that
+the maximum allowed level of nesting is left unspecified creates a hardship
+for implementers of user FTPs. This hardship is somewhat easily solved on a
+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 markers
+(EOR) are explicit, including the final one." This prohibits sending data
+between the final end of record and the end of file, but does not specify
+what the receiver of data is to do if this rule is broken. That is, should
+the intervening data be discarded or treated as a new (final) record?
+SOLUTION: specify that if an end-of-file marker is not immediately preceded
+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 of
+an FTP user process must handle a considerable number of special cases
+merely to determine whether or not the last command sent was successful. It
+is admitted that the protocol is well-defined in all the following areas,
+but it is important to realize that the characteristic "well-defined" is
+necessary, but not sufficient; for many reasons, it is very desirable to
+employ the simplest mechanism that satisfies all the needs. Following is a
+list of those drawbacks that unduly complicate the flow chart of an FTP
+user process:
+
+9. Different commands have different success reply codes. A successful
+"USER" command, for example, returns a "230" whereas a successful "BYTE"
+command returns a "200". The concept that success replies should have an
+even first digit and failure replies an odd first digit does not apply, as
+"100, means success for "STAT", and "402" means failure for "BYTE".
+SOLUTION: specify that any command must return a reply code beginning with
+some unique digit, such as "2", if successful, and anything other than that
+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 keep
+a list of reply codes for each command, all of which mean "command
+accepted, continue".  SOLUTION: same as for (9.) above. The desire to
+communicate more specific information than simply "yes" or "no", such as
+the difficulty in the login procedure that some sites do not need all the
+parameters, may be solved by having, for example, "238" mean "PASSWORD
+ACCEPTED, YOU ARE NOW LOGGED IN", and "237" mean "PASSWORD ACCEPTED,
+ACCOUNT NOW NEEDED" The important point is that the idea of "command
+accepted" is conveyed by the initial "2", and that finer gradations of
+meaning can be deduced by the user process, if desired.
+
+                                      -2-
+                                      
+11. There are several types of replies that are extraneous from the point
+of view of a user FTP process, and their reply codes have no characteristic
+that makes them easily distinguishable.  For example, "010 message from
+operator" and "050 FTP commentary" are superfluous to a user process, and
+"000 announcing FTP" (in place of "300" greeting) is not. SOLUTION: specify
+that any reply that has meaning only to a human user and not to a user
+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 this
+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 be
+accepted right away is another instance of multiple reply codes having the
+same meaning to a user process.  SOLUTION: require that the server send a
+reply with a "020" reply code in the situation cited. If it is desired to
+communicate more detailed information, the text of the reply may used for
+this purpose.
+
+In addition to the above mentioned weaknesses in the protocol, the
+following is believed to be a typographical error:
+
+13. Reply code "331" is cited as a possible success reply code for the
+commands "BYTE", "SOCK", "PASV", "TYPE", "STRU", "MODE", "ALLO", "REST",
+"SITE", AND "STAT". This reply code means "ENTER ACCOUNT" (if required as
+part of login sequence), and perhaps should be "332 LOGIN FIRST, PLEASE".
+This is especially indicated by the fact that "332" is not listed anywhere
+in the command-reply correspondence table.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                      
+
+
+
+
+
+
+
+
+
+
+
+                                       -3-
+\ No newline at end of file