doc: Add RFC documents

1 files changed, 171 insertions, 0 deletions

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 <SP> 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 <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.
+
+
+
+
+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]
+