Movatterモバイル変換

Network Working Group                                   K. Pogran (MIT-Multics)Request for Comments: 614                                   N. Neigus (BBN-NET)NIC #21530                                                             Jan 1974References: RFC #607, RFC #542    Response toRFC 607, "Comments on the File Transfer Protocol"Mark Krilanovich and George Gregg have pointed out a number of "sticky"issues in the current File Transfer Protocol. Although we don't agreewith all of their proposed protocol modifications, we do feel that eachof the points they have raised should be given some thought by everyoneconcerned about FTP. Each numbered paragraph in the discussion below is acomment on the identically-numbered paragraph inRFC 607.1. Instructions to the Server to be "passive" are defined to apply onlyto the next single file transfer operation, after which the Serverreverts to active mode.RFC 607 does, however, point out a drawback inthe present specification, in that there is no way for a user to "changehis mind": once he has told a server to be "passive", he has to initiatesome file transfer operation. The suggested solution is a welcome one. Wesuggest that the text of the "successful reply" to the ACTV commandindicate whether the server had previously been in "active" or "passive"mode, viz:200 MODE CHANGED TO ACTIVEor200 MODE IS ALREADY ACTIVEIt is important to note that once some servers "listen" on a connectionin response to a PASV command, they no longer can examine the Telnetcontrol connection for the possible arrival of an ACTV command. User-FTPprograms should precede the ACTV command with a SYNC sequence to ensurethat the server will see the ACTV command.2. While the length of an FTP command -- either three or four characters-- might often be irrelevant to a system which interacts over Telnetconnections on a line-at-a-time basis, we can see how a variable commandlength might be harder for a character-at-a-time system to handle,especially for a server implemented in assembly language. Quite a bit isgained, and nothing seems to be lost, by requiring that FTP commands befour characters, so we agree with the suggestion inRFC 607.3. While the FTP document may be somewhat ambiguous in its specificationof the order of the handshaking which takes place following a filetransfer command, such an order does exist as far as is possible for thetwo asynchronous processes described in "The FTP Model" (section II. B ofRFC 542) -- the Telnet Control process (Protocol Interpreter) and theData Transfer process. The user is required to "listen" on the dataconnection before sending the transfer command.  Upon receipt of thecommand the server should first check that the status of the filespecified by the argument to the file transfer command is okay, and, ifso, attempt to open the data connection. If there are file systemproblems, no attempt should be made to open the connection. In this way,                                    -1-

the primary response to the command gives an accurate picture of thetransfer status -- i. e., connection opened and transfer started (250),or connection not opened because of file problems (450, 451, 455, 457) orconnection problems (454). The secondary reply follows the conclusion ofthe transfer, and describes its success or failure.If a particular FTP implementation cannot monitor the data connection andthe Telnet control connection simultaneously, then it must establish atimeout waiting for the data connection RFC. In addition, a minimuminterval should be specified for which all servers must wait beforedeciding that the data connection cannot be opened. We suggest that thisinterval be no shorter than fifteen seconds.4. The protocol states that servers should return "success", replies tocommands such as ACCT and ALLO which were irrelevant to them. Werecommend that the protocol say "must" rather than "should".5. Specification of maximum lengths for lines, pathnames, etc.is a fineidea, as is the suggestion of a Server poll.  Typical values for thepresent Multics implementation (provided by Ken Pogran) are as follows:Telnet lines: 256User names: 32Passwords: 8Account Numbers: (na)Pathnames: 168 (yes, 168)6. We strongly disagree with Mark on this point. The algorithm a user-FTPshould use goes something like this:a. Examine the first four characters of the reply.b. If the fourth character is a space, the reply is not a multi-line reply.c. If the fourth character is a hyphen, the reply is a multi-line reply,and the text portion of this line and succeeding lines should be reportedto the user if this is desired.d. On each succeeding line, if the first four characters are not thethree digits of the original reply code followed by a space, the line isentirely a text line and should either be reported to the user ordiscarded.e. If the first four characters on the line are the three digits of thereply code followed by space, this line is the last line of the reply.This algorithm seems simple enough, if nesting of replies is not required(see comments on paragraph 7, below). This sort of continuation-lineconvention provides a number of benefits to the person coding a server.Consider the problem of providing a directory listing, in response to aSTAT command whose argument is the pathname of a directory. If the FTPTelnet control connection is treated as a pseudo-typewriter (as mostordinary Telnet connections are), the writer of an FTP Server may be ableto "borrow" the code from the system command which provides directorystatus (listing) information, as follows (in a pseudo-PL/l syntax):call write_out_line ("151- Directory listing follows") ;call list_directory_contents (directory_pathname);call write_out_line ("151 Directory listing complete");                                    -2-

The same can be done for the file status reply (code 150).  Otherwise, aprogram must be written which performs the function of thedirectory-listing command, but uses a special output format. If theimplementor of an FTP Server wants to be "nice" and list file attributes,as well as file names, in the directory listing (as manydirectory-listing commands do), this could be a fairly big job. Ifalready-written software can be borrowed and incorporated into the FTPServer, the implementor of the FTP Server can put more of his effort intodoing a better job of building the "guts" of the FTP Server.7. It is not obvious why multi-line replies are allowed to be nested toan arbitrary depth. Only truly spontaneous replies may nest inside otherreplies -- and it is easy to convince yourself that they will only nestto depth one. It was envisioned that some messages from "the system"might not allow the "exterior" multi-line message to finish; the scenariomight go something like this:.151- Directory listing follows:a1pha.p11alpharfc.runoffmailbox010- From Operator:010 Emergency shutdown in 5 mins. due to hardware probs.beta.fortranfoo.lisp151 Directory listing complete.It has been pointed out to us that:a. Messages from "the system" in general cannot be guaranteed to come atthe beginning of a line.b. It may be difficult to modify "the system" to preface such messageswith an appropriate FTP reply code.Therefore, we propose that, since user-FTP implementations must handlemulti-line replies, system messages "splattered" into the middle ofreplies need not be escorted by FTP reply codes. The user-FTP thus neednot detect and handle "nested" FTP replies.8.RFC 607 proposes that any data between the last end-of-record markerof a file and the end-of-file marker be discarded. We agree. The senderof the data has clearly violated the protocol, and the receiver cannotdivine the sender's original intent.9-11. The suggestion that reply codes beginning with the digit "2" betaken as successful, and all others be taken as failures, severelyrestricts use of the available "reply code space". We agree that thepresent scheme is disorganized and requires far too much "intelligence"on the part of a user-ftp automaton. With the present scheme, unless theautomaton's reply-interpretation is table-driven, it is extremely likelyto make a mistake. We feel that the whole reply code strategy should beredesigned; some of the ideas proposed inRFC 607 could fit in with sucha redesign, but we do not think that Mark's suggestion is the way to go.                                      -3-

12. 000 and 020 are used by the Server to indicate that it has heard andanswered the ICP to socket 3, but cannot accept file transfer commandsyet. 020 was intended to indicate how much of a time delay could beexpected, while 000 was ambiguous on this point. We suggest that the twobe merged to mean "I am here; please wait a specified or unspecifiedamount of time"; then, 300 would clearly mean "I am ready; you may nowsend me commands".13. There is no typographical error here. A TENEX representativesuggested that, rather than give a "fail" reply to a particular requestbecause the user is not logged in, a server might ask for his accountnumber (or ask him to log in) and then proceed with the previous request,which has been held in abeyance. While this may be convenient for aserver, it is not necessary, and certainly ambiguous to hold a command inabeyance while obtaining an account number.  Since any server may springthis on a user, all user-FTP implementations must be able to cope withthis twist, which adds a good deal of required complication to the"minimal" user-FTP implementation. We propose that the 331 reply beeliminated, and that the server forget the requested operation and returna 4XX reply if an account is needed.Jon Postel has remarked that "mail text should follow the same limit ascommands and long 'lines' of mail text have been trouble for some FTPServers." We agree. In fact, mail transmitted over the FTP Telnet controlconnection has other problems, too: Since FTP is (nominally, at least)supposed to be usable from TIPs, Multics implemented its standardcharacter erase and line kill conventions on the control connection forthe convenience of TIP users (it was actually easier to have thoseconventions in effect than to turn them off!). Of course, no erase/killprocessing was done on the data connection. The intent of the MAILrequest was to allow users at terminals to access an FTP Server directlyand transmit mail; it was presumed that mail-sending automata whichgathered the mail to be sent into a file would use the MLFL command andtransmit the mail over the data connection.  Presumably, long lines wouldnot be a problem, and, of course, no erase/kill conventions would be ineffect. Well, at least one major system (TENEX) has a mail-sendingautomaton which transmits mail over the Telnet control connection usingthe MAIL command - even though it has previously gathered the mail into afile!  Line-length considerations could be a severe problem here, and thefact that the Multics line-kill character is the at-sign (@) caused griefin reading mail from TENEX users who included their "return address" inTENEX's SNDMSG syntax, as USERNAME@HOST. We propose that mail-sendingautomata be required to use MLFL, rather than MAIL.                                  -4-