Browse Prior Art Database

Comments on File Transfer Protocol (RFC0430) Disclosure Number: IPCOM000004920D
Original Publication Date: 1973-Feb-01
Included in the Prior Art Database: 2019-Feb-12
Document File: 8 page(s) / 12K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R.T. Braden: AUTHOR

Related Documents

10.17487/RFC0430: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 19% of the total text.

Network Working Group R. Braden Request for Comments: 430 CCN/UCLA NIC: 13299 7 February 1973


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 [Page 1]


(b) The same definitional problem occurs for restart markers.

(c) Why does the restart marker have to be greater than 8 bits?

(d) Note that changing the Descriptor coding to bit flags would abolish the implied eor as well as the problem of RFC 385, P. 2, #6.

4. RFC 414, P. 5 (11.iii)

Note that text mode is not possible for any EBCDIC coded file. Since EBCDIC is an 8-bit code, Telnet control characters (128-255) cannot be used to distinguish either eor or eof. Stream and block modes will work, however. We have found the diagram on the last page to be useful for keeping track of the three-dimensional space of FTP parameters.

5. RFC 354, P. 17, PASS Command

There is no mechanism within FTP for changing a password. A user shouldn’t have to use a different protocol (e.g., log into a time sharing system) to merely change his password.

6. RFC 385, P. 3 (9.), TYPE Before BYTE

This admonition (to send TYPE before BYTE) should be clearly labeled as a recommended procedure for user FTP, not a restriction...