From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc607.txt | 175 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 175 insertions(+) create mode 100644 doc/rfc/rfc607.txt (limited to 'doc/rfc/rfc607.txt') 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 -- cgit v1.2.3