From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc463.txt | 171 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 doc/rfc/rfc463.txt (limited to 'doc/rfc/rfc463.txt') diff --git a/doc/rfc/rfc463.txt b/doc/rfc/rfc463.txt new file mode 100644 index 0000000..5a105ba --- /dev/null +++ b/doc/rfc/rfc463.txt @@ -0,0 +1,171 @@ + + + + + + +Network Working Group Abhay K. Bhushan +RFC # 463 MIT-DMCG +NIC # 14573 February 21, 1973 + + + FTP Comments and Response to RFC 430 + + + Most of the comments in RFC 430 by Bob Braden are useful suggestions +which should be included in the forthcoming official FTP specification. +This RFC represents my response to Braden's comments and 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?). + +SPECIFIC RESPONSES TO RFC 430. + + Item A1 - I will let Bob Braden handle the "print file" issues (the + "still" should be removed). + + Item A2 - I agree that 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. 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. This is 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 NCP's should be fixed. A 255 (socket + number) reply should be required at a specific time, and NCP's + should be able to provide it (this also permits the proposed GSOC + command). Let us find out at next meeting if there is anyone who + cannot live with this new requirement. + + + + +Bhushan [Page 1] + +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 [Page 2] + +RFC 463 FTP Comments and Response to RFC 430 February 1973 + + + 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 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 + 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 user's directory and notify him of the same. The user does + not see all the junk on his console but can print the file on a + printer and read that class of mail at his leisure. + + + + + + + + + + + [ 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 ] + + + + + + + + + + + + + + + + + + + + + + + + + +Bhushan [Page 3] + -- cgit v1.2.3