RFC 463 FTP Comments and Response to RFC 430 February 1973 Item A8 - Yes. Item B - There are at least two ways to solve the FTP parameter encoding problem presented by Bob Braden. One is to allow multiple letter in the TYPE command as suggested by Bob and the other is to have a new command such as FORM (which could be P or U). Other solutions are equally acceptable to me. Item C - Our emphasis should be on working protocol as well as elegance. I like the proposed GSOC command over the listen. In fact GSOC can be used for all data connection security checking. The 255 reply should be sent with GSOC only, and the server should use only those sockets for data connection. Item D - We need more discussion on the issue of site dependent FTP parameters. I will put it on the agenda for the forthcoming FTP meeting. FURTHER COMMENTS 1. The command-reply sequence needs to be tightened in both specification and implementations to allow convenient use of FTP by programs or "automatons". 2. A 300 reply greeting upon first connecting to the FTP server should be required and not optional. This avoids the programs having to wait an arbitrary time for such a greeting before issuing commands. Commands may only be sent after the 300 reply is received from the server. 3. RFC 454 needs a discussion of transfer between two FTP servers arranged by the user via the LSTN or GSOC commands. 4. Perhaps we should allow specification of data transfer parameters in a single command line (for reasons of efficiency). A suggested format is to have separate the parameters bunched together in a single line (requiring only a single reply). Consider the following sequences: STRU F TYPE I BYTE 36 MODE S reply - 200 OK 5. Further discussion of MAIL and MAIL.file commands seems necessary. Perhaps we will get some useful input from the MAIL meeting at SRI on February 23, The following issues seem particularly relevant to me: a) Allowing mail to multiple users. It should be required that FTP servers allow this. Bhushan