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
