RFC 430 (rfc430) - Page 2 of 8
Comments on File Transfer Protocol
Alternative Format: Original Text Document
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