Movatterモバイル変換

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  1974Comments on the File Transfer ProtocolThis document replacesRFC 607, which was inadvertently releasedwhile still in rough draft form. It would be appreciated ifRFC 607were disregarded, and this document considered the accurate statementof the authors' opinions.There are several aspects of the File Transfer Protocol of RFC542 that constitute serious drawbacks. Some of these are quite basicin nature, and imply substantial design changes; these will bediscussed in a later RFC. Others could be remedied with very littleeffort, 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 noconvenient way for the user to make him "active" again. The"REIN" command accomplishes this, but affects more than just thedesired active/passive state. SOLUTION: define a new command,with a command verb of "ACTV", to mean that the server is to issuea CONNECT rather than a LISTEN on the data socket. If the serveris already "active", the command is a no op. "ACTV" is to havethe same reply codes as "PASV".2. Design of an FTP server or user would be simpler if allcommand verbs were the same length. While it is certainlypossible to handle varying length verbs, fixed length stringmanipulation is in general easier to write and faster to run thanvarying length string manipulation, and it would seem that nothingis to be gained in this application by allowing varying lengthstrings. SOLUTION: replace the only three-letter verb, "BYE",with a four-letter one, such as "QUIT", and constrain futurecommand verbs to be four letters long.3. The order of the handshaking elements following a file transfercommand is left unspecified. After sending a STOR command, forexample, a user process has no way of knowing which to wait forfirst, the "250 FILE TRANSFER STARTED" reply, or establishment ofthe data connection. SOLUTION: specify that the server is tosend a "250" reply before attempting to establish the dataconnection. 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 thefile, these checks must be made before any reply is sent. Thetext of the "250" reply would perhaps be more appropriate as "250OPENING DATA CONNECTION", since it comes before actual datatransfer begins. If the server wishes to send an error reply inthe event that the data connection cannot be opened, it is to besent in lieu of the "252 TRANSFER COMPLETE" reply.                                 -1-

4. Some hosts currently send an error reply on receipt of acommand that is unimplemented because it is hot needed (e.g.,"ACCT" or "ALLO"). Even though the text of the reply indicatesthat the command has been ignored, it is obviously impossible fora user process to know that there is no real "error". SOLUTION:require that any server that does not support a particular commandbecause it is not needed in that system must return the successreply for that command.5. There is no specified maximum length of a TELNET command line,TELNET reply line, user name, password, account, or pathname. Itis true that every system implementing an FTP server likely hasdifferent maxima for its own parameters, but it is inconvenient,at least in some systems, for the writer of an FTP user (whichmust converse with many FTP servers) to construct an indefinitelength buffer. Similar difficulties confront the writer of aserver FTP. SOLUTION: specify a maximum length for TELNETcommand lines, TELNET replies, user names, passwords, accountnumbers, and pathnames. This is to be done after conducting aPoll of serving sites concerning their individual maxima. IfNetwork mail is to be included in FTP, the mail text, if sent overthe TELNET connection, is to be subject to the same line lengthmaximum.6. The notion of allowing continuation lines to start witharbitrary text solves a minor problem for a few server FTPimplementors at the expense of creating a major problem for alluser FTP implementors. The logic needed to decode a multi-linereply is unnecessarily complex, and made an order of magnitudemore so by the fact that multi-line replies arc allowed to benested. SOLUTION: assign a unique (numeric) reply code, such as"009", to be used on all lines of a multi-line reply after thefirst. The reply code used for this purpose must begin with "0"(it cannot be three blanks, for example), so that it will appearas extraneous to a user process by virtue of the already existingrules concerning reply code groupings.7. If it is the case that the above solution to (6) is notaccepted, the fact that the maximum allowed level of nesting isleft unspecified creates a hardship for implementors of user FTPs.This hardship is somewhat easily solved on a machine that hashardware stacks, but not so for other machines. SOLUTION: eitherdisallow nested replies (preferred), or specify a maximum level ofnesting of multi-line replies.8. The prose descriptions of the meanings of the various replycodes are in several cases unclear or ambiguous. For example, thecode "020" is explained only as "announcing FTP". It is given asa reply that can be issued when a server cannot accept inputimmediately after an ICP, but its exact meaning is not obvious.Also. the code "331" is said to mean "ENTER ACCOUNT (if requiredas part of login sequence)", but is listed as a possible successreply for most of the commands. The explanation indicates that itis only valid in the login sequence, but the command-reply                                 -2-

correspondence table implies that it also means, "I can't do thatwithout an account". SOLUTION: an expanded effort should be madeby those who originated the reply codes to define them morecompletely.A major complaint about the protocol concerns the fact that thewriter of an FTP user process must handle a considerable number ofspecial cases merely to determine Whether or not the last commandsent was successful. It is admitted that the protocol iswell-defined in all the following areas, but it is important torealize that the characteristic "well-defined" is necessary, but hotsufficient; for many reasons, it is very desirable to employ thesimplest mechanism that satisfies all the needs. Following is a listof those drawbacks that unduly complicate the flow chart of an FTPuser process:9. Different commands have different success reply codes. Asuccessful "USER" command, for example, returns a "230", whereas asuccessful "BYTE" command returns a "200". The stated conceptthat the first digit would carry this information does not apply,as "100" means success for "STAT", and "200" means success for"SOCK". SOLUTION: specify that any command must return a replycode beginning with some unique digit, such as "2", if successful,and anything other than that digit if not successful. Forexample 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 berequired to keep a list of reply codes for each command, all ofwhich mean "command accepted, continue". Again, the statedconcept concerning the first digit fails, as "230" and "330" arein truth both acknowledgments to a successful "USER" command.SOLUTION: same as for (9) above. The desire to communicate morespecific information than simply "yes" or "no", such as thedifficulty that some servers do not need all the login parameters,may be solved by having, for example, "230" mean "PASSWORDACCEPTED, YOU ARE NOW LOGGED IN", and "237" mean "PASSWORDACCEPTED, ACCOUNT NOW NEEDED". Given the solution to (4) above, auser process becomes much less interested in the differencebetween "YOU ARE NOW LOGGED IN" and "ACCOUNT NOW NEEDED". Theimportant point is that the idea of "command accepted" is conveyedby the initial "2, and that finer gradations of meaning can bededuced by the user process, if desired.11. The meanings of the various connection greeting reply codesare somewhat inconsistent. "300 connection greeting, awaitinginput", if intended as a positive acknowledgments to the ICP,should be a 200-series reply, or if intended to be purelyinformative, a 000-series reply. If the former, then clearly "020expected delay" is the corresponding negative acknowledgments, andshould be a 400-series reply. It is however unlikely thatnotification of an expected delay would be of importance to a userProcess without knowledge of the length of the delay. SOLUTION.:change "300 connection greeting" to a 000-series reply, perhaps                                 -3-

"011" (preferred), or change "300 connection greeting" to a200-series reply, perhaps "211", and "020 expected delay" to a400-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 thecommand-reply correspondence table. It Would seem that this wouldbe a more-information-needed (success) reply for all thosecommands which require the user to be logged in. It should alsobe stressed that the "332" code is to be used for this purpose, asmany servers currently use other codes, such as "451" and "504",to mean "LOGIN PLEASE".                                   -4-