Response to RFC 607: "Comments on the File Transfer Protocol" (RFC0614)
Original Publication Date: 1974-Jan-28
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
K.T. Pogran: AUTHOR [+2]
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.
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"
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 t...