Comments on File Transfer Protocol
RFC 430
|
Document |
Type |
|
RFC - Unknown
(February 1973; No errata)
|
|
Authors |
|
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 430 (Unknown)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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 [Page 1]
RFC 430 COMMENTS ON FILE TRANSFER PROTOCOL FEBRUARY 1973
(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
on a server FTP.
7. RFC 385, P. 2-3 (7) Order of 255 Reply
Some of the participants felt (strongly) that the timing problem
dealt with in this item is the result of bad NCP implementations
and ought not be dignified in the protocol. The issue here is the
old, familiar, and touchy one of queueing RFC's or not. (My own
view is that the protocol asymmetry forced by NCP's which can't
queue RFC's is at least unaesthetic, and makes some elegant
solutions impossible. For examples, see RFC 414 and the comments
below on server-server interaction, and RFC 438 on Reconnection
Protocol).
8. RFC 354, P. 15, Restart
Following a RESTart command, APPend and STORe presumably have
identical meanings.
Braden [Page 2]
RFC 430 COMMENTS ON FILE TRANSFER PROTOCOL FEBRUARY 1973
B. FTP Parameter Encoding
RFC 448, which discusses print files, points out that the print file
attribute is logically independent of the character code attribute
(ASCII vs. EBCDIC) in the type dimension; the set of allowable types
in FTP is the outer product of the individual attributes. Thus FTP
has (at least) four character types, summarized by the following two
x two matrix:
| ASCII | EBCDIC
---------------+---------+------------
Not Print File | |
Show full document text