RFC 430 (rfc430) - Page 1 of 8
Comments on File Transfer Protocol
Alternative Format: Original Text Document
Network Working Group R. Braden
Request for Comments: 430 CCN/UCLA
NIC: 13299 7 February 1973
COMMENTS ON FILE TRANSFER PROTOCOL
On January 23, 1973, Jon Postel (NMC), Eric Harslem (RAND), Stephen
Wolfe (CCN), and Robert Braden (CCN), held and informal meeting at
UCLA on FTP. This RFC generally reports the consensus of that
meeting on the following issues: server-server transfers (ref. RFC
438 by Thomas and Clements); site-dependent information; and
miscellaneous questions/disagreements with RFC 354, 385, and 414.
There was also a discussion of the print file muddle, but that
subject is addressed in a separate RFC, No. 448.
Miscellaneous Comments on FTP
1. RFC 385, P. 1 (3)
The question of print files will be discussed at length in another
RFC. However, we did feel that the word "still" on the second
line from the bottom of Page 1 is gratuitous.
2. RFC 385, P. 2 (5.)
RFC 385, P. 3 (8.)
RFC 414, P. 4 (11.i)
To the extent that we understand these items, they seem to be
unnecessary and probably undesirable concessions to particular bad
implementations ("hacks"). In reference to the second item, No. 8
in RFC 385, one should note that in an asynchronous multi-process
system like the ARPA Network, the phrase "immediately after" has
little meaning. An implementation which depends upon "immediately
after" is erroneous and should be fixed. If the protocol as
defined has an intrinsic race condition, of course, the protocol
should be fixed, but we don't believe such a problem exists. It
would help if definitions of command-response sequences in the FTP
document were tightened up considerably. As for the last item, we
don't understand why Wayne Hathaway is so strongly opposed to
"implied eor".
3. RFC 354, P. 13, Format Definitions for Block Mode
(a) The definition of the header length presumably is meant to be
the "smallest integral number of bytes whose length is greater
or equal to 24 bits".
Braden
