Response to RFC 607: "Comments on the File Transfer Protocol" (RFC0614)
Original Publication Date: 1974-Jan-01
Included in the Prior Art Database: 2019-Feb-12
Internet Society Requests For Comment (RFCs)
K.T. Pogran: AUTHOR [+1]
See also RFCs 624, 542 and 640.
Network Working Group K. Pogran (MIT-Multics) Request for Comments: 614 N. Neigus (BBN-NET) NIC #21530 Jan 1974 References: RFC #607, RFC #542
Response to RFC 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 agree with all of their proposed protocol modifications, we do feel that each of the points they have raised should be given some thought by everyone concerned about FTP. Each numbered paragraph in the discussion below is a comment on the identically-numbered paragraph in RFC 607.
1. Instructions to the Server to be "passive" are defined to apply only to the next single file transfer operation, after which the Server reverts to active mode. RFC 607 does, however, point out a drawback in the present specification, in that there is no way for a user to "change his mind": once he has told a server to be "passive", he has to initiate some file transfer operation. The suggested solution is a welcome one. We suggest that the text of the "successful reply" to the ACTV command indicate whether the server had previously been in "active" or "passive" mode, viz:
200 MODE CHANGED TO ACTIVE
200 MODE IS ALREADY ACTIVE
It is important to note that once some servers "listen" on a connection in response to a PASV command, they no longer can examine the Telnet control connection for the possible arrival of an ACTV command. User-FTP programs should precede the ACTV command with a SYNC sequence to ensure that 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 Telnet connections on a line-at-a-time basis, we can see how a variable command length might be harder for a character-at-a-time system to handle, especially for a server implemented in assembly language. Quite a bit is gained, and nothing seems to be lost, by requiring that FTP commands be four characters, so we agree with the suggestion in RFC 607.
3. While the FTP document may be somewhat ambiguous in its specification of the order of the handshaking which takes place following a file transfer command, such an order does exist as far as is possible for the two asynchronous processes described in "The FTP Model" (section II. B of RFC 542) -- the Telnet Control process (Protocol Interpreter) and the Data Transfer process. The user is required to "listen" on the data connection before sending the transfer command. Upon receipt of the command the server should first check that the status of the file specified by the argument to the file transfer command is okay, and, if so, attempt to open the data connection. If there are file system problems, no attempt should be made to open the connection. In this way,
the primary response to the command gives an accurate picture of the transfer status -- i. e., connection opened and transfer started (250), or...