doc: Add RFC documents

1 files changed, 115 insertions, 0 deletions

diff --git a/doc/rfc/rfc486.txt b/doc/rfc/rfc486.txt
new file mode 100644
index 0000000..2bb7649
--- /dev/null
+++ b/doc/rfc/rfc486.txt
@@ -0,0 +1,115 @@
+
+
+
+
+
+
+Network Working Group                           Bob Bressler
+RFC #486                                        BBN
+NIC #15064                                      20 March 1973
+
+
+                        Data Transfer Revisited
+
+
+    A lot of work has recently gone into the development and refinement
+of both the RJE and FTP protocols.  Stepping back from the details and
+small issues, we can describe the two protocols as 1) a control
+connection over which commands are passed, and 2) a data connection over
+which uninterpreted (by the server process) data is passed.  Both
+protocols deal with the concept of identifying oneself to the server,
+setting up parameters, and transferring some data.
+
+    New ideas and concepts, such as the "hot card reader", have been
+introduced into one protocol or the other, but these concepts are
+generally applicable to both.  In addition, a great deal of effort was
+made to make the structures of the two protocols be as similar as
+possible.
+
+    This discussion is, of course, leading to the suggestion that we
+stop considering these as two separate protocols, and merge them into a
+single unit - perhaps resurrecting the name of "data transfer".
+
+    Several advantages besides simplicity are gained by this.  Sites
+need only build one server program - given that they can always respond
+with "command not implemented".  This will also prevent the RJE users
+and servers from having to start up a (possibly) separate FTP user and
+server - saving the resulting doubling of programs and Telnet
+connections.
+
+    The further advantage of insuring that new ideas and concepts will
+be shared by all users and servers will also be realized.  A RJE user
+will be able to transfer his deck of cards (file) to storage on another
+machine's file system using the "hot card reader" previously defined
+only in the RJE protocol.
+
+    The command set of the combined protocol would now consist of
+several sets of command types.  These sets include:
+
+    a.  general system commands (e.g., USER, HELP)
+
+    b.  parameter settings (e.g., TYPE, STRU)
+
+    c.  data control (e.g., ABORT, REIN)
+
+
+
+
+Bressler                                                        [Page 1]
+
+RFC 486                 Data Transfer Revisited               March 1973
+
+
+    d.  file operation (e.g., STOR, RETR, LIST)
+
+    e.  job execution (e.g., INPUT, OUTPUT, CHANGE)
+
+    I will not try to completely specify the syntax of each command
+since they are still being finalized (left as an exercise for the
+reader?).
+
+    An implementor who was only interested in file transfer would
+implement the general data transfer routines and the small set of file
+transfer commands.  Another site might also wish to implement the job
+execution commands.
+
+    Users at traditional RJE stations would be able to store their files
+on machines that do not support other RJE functions, by using the file
+transfer command package in their user machine.  At some later date,
+they can connect to a batch server elsewhere on the net and instruct it
+to accept its input from the site currently storing the files.  Thus
+card reader availability and access to a batch machine would not need to
+be concurrent.
+
+    In an effort to get a feel for the complexity of this suggestions,
+the latest FTP offering (RFC 454) was compared with the RJE document.
+The amount of change to the RJE document was in fact relatively small
+(and will perhaps constitute a subsequent RFC).  A possible course of
+action, then, would be to take the "official FTP" resulting from the 16
+March meeting at BBN and divide the commands into data transfer and file
+transfer components.  The RJE documents can then be revised or rewritten
+such that the "new" data transfer protocol will also have an RJE subset.
+This would be accomplished by recognizing and removing those parts of
+the RJE that dealt with data transfer, leaving a command subset dealing
+exclusively with job submission and execution.  This course of action is
+intended to cause minimal perturbation on current implementations.
+
+    The intention of this suggestion is not to try and pack everything
+into a single protocol but to make the large body of common code - the
+transfer of data - available to current and new protocols.  New ideas,
+be they mail or load sharing, could be developed more easily given the
+common availability of this data transfer mechanism.
+
+RB/jm
+
+
+
+       [ 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 ]
+
+
+
+
+Bressler                                                        [Page 2]
+