Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Response to RFC 607: "Comments on the File Transfer Protocol" (RFC0614)

IP.com Disclosure Number: IPCOM000003687D
Original Publication Date: 1974-Jan-28
Included in the Prior Art Database: 2000-Sep-13
Document File: 4 page(s) / 11K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

K.T. Pogran: AUTHOR [+2]

Abstract

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 24% of the total text.

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

or

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

com...