Comments on the File Transfer Protocol
RFC 607
Document | Type |
RFC - Unknown
(January 1974; No errata)
Obsoleted by RFC 624
Updated by RFC 614
|
|
---|---|---|---|
Authors | |||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 607 (Unknown) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 casesShow full document text