RFC 463

RFC 463 💖 FTP Comments and Response to RFC 430

okay bestie, title block tea ☕ This one is by Abhay K. Bhushan of MIT-DMCG, NIC # 14573, dated February 21, 1973, from the Network Working Group. The original doesn't state a category, and it doesn't list anything it obsoletes or updates, so there's nothing more to report there 🦋

Most of the comments in RFC 430 by Bob Braden are useful suggestions that should be included in the forthcoming official FTP specification ✨ So this RFC is my response to Braden's comments and some other views 💅 These comments should be useful for the FTP meeting on March 16 at BBN (announcement warning AAM NIC #14417). The results of the FTP subgroup meeting held at BBN on January 25 will be published in RFC 4541 (are published?) 🙈 the original literally has a question mark on this one lol.

SPECIFIC RESPONSES TO RFC 430. 🎀

• Item A1 - Bob Braden can handle the "print file" issues 💖 The "still" should be removed.
• Item A2 - Concessions are undesirable and should be removed, unless people cannot "live" without them 🙅‍♀️
• Item A3 - I strongly support "bit flag coding" for descriptors 🔥 Other definition improvement suggestions are ok too.
• Item A4 - The diagram was useful 🦋 An alternate one is given on page 17 of RFC 454, and I prefer the latter.
• Item A5 - The FTP may not be privileged enough to alter passwords in many Host systems (e.g. Multics) 🥺 I know that CCN allows changing passwords on-line. We can define a format for changing passwords in the pass command, but I don't think we can require that all servers allow password changing. It's a minor problem that can be easily solved ✨
• Item A6 - Yes, the comment that TYPE should be before BYTE was for bad implementations 💀 The server should reject data transfer parameters only when the data transfer command is received. The order of the parameter-change commands is not important.
• Item A7 - I do agree that NCPs should be fixed 👑 A 255 (socket number) reply should be required at a specific time, and NCPs should be able to provide it (this also permits the proposed GSOC command). Let's find out at the next meeting if anyone cannot live with this new requirement.
• 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 letters in the TYPE command, as suggested by Bob. 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 a 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, so that FTP can be used conveniently by programs or "automatons" 🤖✨
2. A 300 reply greeting upon first connecting to the FTP server should be required and not optional 💖 This avoids 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 <SP> separate the parameters bunched together in a single line, which requires only a single reply. Consider the following sequence:

STRU F TYPE I BYTE 36 MODE S <CR><LF>
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. 👯‍♀️
   • b) Using NIC idents. FTP servers should accept some standard form of user name. This could be NIC idents, or last name with optional use of initials 🪪
   • c) Uniform conventions for who the mail is from, day, time, etc., and how the mail is delivered to the user. The mail usually gets tagged twice, or sometimes not tagged at all 😵‍💫 Perhaps we need a different mechanism for indicating who the mail is from than the one provided by the USER command.
   • d) Handling bulk or junk mail, particularly the NIC documents that may be sent on-line by the NIC 🗑️ Perhaps mail.file should put a file in the user's directory and notify them of the same. The user does not see all the junk on their console, but can print the file on a printer and read that class of mail at their leisure 🧋

Final note from the original, kept exactly as-is 🌈

[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with    ]
[ support from GTE, formerly BBN Corp.             9/99 ]