Comments on the File Transfer Protocol
RFC 624

Document Type RFC - Unknown (February 1974; No errata)
Obsoletes RFC 607
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 624 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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" reply.

                                 -1-


4. Some hosts currently send an error reply on receipt of a
command that is unimplemented because it is hot 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 the success
reply for that command.

5. There is no specified maximum length of a TELNET command line,
TELNET reply 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 inconvenient,
at least in some systems, for the writer of an FTP user (which
must converse with many FTP servers) to construct an indefinite
length buffer. Similar difficulties confront the writer of a
server FTP. SOLUTION: specify a maximum length for TELNET
command lines, TELNET replies, user names, passwords, account
numbers, and pathnames. This is to be done after conducting a
Poll of serving sites concerning their individual maxima. If
Network mail is to be included in FTP, the mail text, if sent over
the TELNET connection, is to be subject to the same line length
maximum.

6. The notion of allowing continuation lines to start with
arbitrary text solves a minor problem for a few server FTP
implementors at the expense of creating a major problem for all
user FTP implementors. The logic needed to decode a multi-line
reply is unnecessarily complex, and made an order of magnitude
more so by the fact that multi-line replies arc allowed to be
nested. SOLUTION: assign a unique (numeric) reply code, such as
"009", to be used on all lines of a multi-line reply after the
first. The reply code used for this purpose must begin with "0"
Show full document text