Browse Prior Art Database

Comments on the File Transfer Protocol (RFC0607)

IP.com Disclosure Number: IPCOM000003679D
Original Publication Date: 1974-Jan-07
Included in the Prior Art Database: 2000-Sep-13
Document File: 3 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. Krilanovich: AUTHOR [+2]

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

Request for Comments: 607 Mark Krilanovich

NIC # 21255 George Gregg

references: RFC #542 UCSB Jan 1974

Comments on the File Transfer Protocol

There are several aspects of the File Transfer Protocol that constitute

serious drawbacks. Some of these are quite basic in nature, and imply

substantial design changes; these will be discussed in a later RFC.

Others could be remedied with very little effort, and this should be done

as soon as possible.

Following is a list of those problems that can be easily solved, together

with their proposed solutions:

1. Once a server has been told to be "passive" with regard to establishment

of data connections, there is no way for the user to make him "active"

again. SOLUTION: define a new command, with a command verb of "ACTV", to

mean that the server is to issue a CONNECT rather than a LISTEN on the data

socket. If the server is already "active", the command is a no op. "ACTV"

is to have the same reply codes as "PASV".

2. Design of an FTP server would be simpler if all command verbs were the

same length, and design of an FTP user would be simpler if either all

command verbs were the same length, or if multiple blanks were allowed

following the verb. SOLUTION: replace the only three-letter verb, "BYE",

with a four-letter one, such as "QUIT", and constrain future command verbs

to be four letters long.

3. The order of the handshaking elements following a file transfer command

is left unspecified. After sending a STOR command, for example, a user

process has no way of knowing which to wait for first, the "250 FILE

TRANSFER STARTED" reply, or establishment of the data connection. SOLUTION:

specify that the server is to send a "250" reply before attempting to

establish the data connection. If it is desired to check if the user is

logged in, if the file exists, or if the user is to be allowed access to

the file, these checks must be made before any reply is sent. The text of

the "250" reply would perhaps be more appropriate as "250 OPENING DATA

CONNECTION", since it comes before actual data transfer begins. If the

server wishes to send an error reply in the event that the data connection

cannot be opened, it is to be sent in lieu of the "252 TRANSFER COMPLETE"

reply.

4. Some hosts currently send an error reply on receipt of a command

that is unimplemented because it is not needed (e.g., "ACCT" or "ALLO").

Even though the text of the reply indicates that the command has been

ignored, it is obviously impossible for a user process to know that there

is no real "error". SOLUTION: require that any server that does not support

a particular command because it is not needed in that system must return a

success reply.

5. There is no specified maximum length of a TELNET line, user name,

password, account, or pathname. It is true that every system implementing

an FTP server likely has different maxima for its own parameters, but it is

nearl...