Dismiss
InnovationQ/InnovationQ Plus content will be updated on Sunday, June 25, 10am ET, with new patent and non-patent literature collections. Click here to learn more.
Browse Prior Art Database

Comments on the File Transfer Protocol (RFC0624)

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

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. Krilanovich: AUTHOR [+4]

Abstract

There are several aspects of the File Transfer Protocol of RFC 542 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.

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

Network Working Group Mark Krilanovich (UCSB)

Request for Comments: 624 George Gregg (UCSB)

NIC #22054 Wayne Hathaway (AMES-67)

references: RFC 542 Jim White (SRI-ARC)

obsoletes: RFC 607 Feb 1974

Comments on the File Transfer Protocol

This document replaces RFC 607, which was inadvertently released

while still in rough draft form. It would be appreciated if RFC 607

were disregarded, and this document considered the accurate statement

of the authors' opinions.

There are several aspects of the File Transfer Protocol of RFC

542 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 set to the state where he is "passive"

with regard to establishment of data connections, there is no

convenient way for the user to make him "active" again. The

"REIN" command accomplishes this, but affects more than just the

desired active/passive state. 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 or user would be simpler if all

command verbs were the same length. While it is certainly

possible to handle varying length verbs, fixed length string

manipulation is in general easier to write and faster to run than

varying length string manipulation, and it would seem that nothing

is to be gained in this application by allowing varying length

strings. 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" re...