Response to RFC 607: "Comments on the File Transfer Protocol"
RFC 614

Document Type RFC - Unknown (January 1974; No errata)
Updates RFC 607, RFC 542
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 614 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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:




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 connection not opened because of file problems (450, 451, 455, 457) or
connection problems (454). The secondary reply follows the conclusion of
the transfer, and describes its success or failure.

If a particular FTP implementation cannot monitor the data connection and
the Telnet control connection simultaneously, then it must establish a
timeout waiting for the data connection RFC. In addition, a minimum
interval should be specified for which all servers must wait before
deciding that the data connection cannot be opened. We suggest that this
interval be no shorter than fifteen seconds.

4. The protocol states that servers should return "success", replies to
commands such as ACCT and ALLO which were irrelevant to them. We
recommend that the protocol say "must" rather than "should".

5. Specification of maximum lengths for lines, pathnames, etc.  is a fine
idea, as is the suggestion of a Server poll.  Typical values for the
present Multics implementation (provided by Ken Pogran) are as follows:

Telnet lines: 256
User names: 32
Passwords: 8
Account Numbers: (na)
Pathnames: 168 (yes, 168)

6. We strongly disagree with Mark on this point. The algorithm a user-FTP
should 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 reported
to the user if this is desired.
d. On each succeeding line, if the first four characters are not the
three digits of the original reply code followed by a space, the line is
entirely a text line and should either be reported to the user or
e. If the first four characters on the line are the three digits of the
reply code followed by space, this line is the last line of the reply.
Show full document text