doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

diff --git a/doc/rfc/rfc479.txt b/doc/rfc/rfc479.txt
new file mode 100644
index 0000000..c42a550
--- /dev/null
+++ b/doc/rfc/rfc479.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                               James E. White (JEW)
+Request for Comments:  479                                       SRI-ARC
+NIC: 14948                                                 March 8, 1973
+
+
+                     Use of FTP by the NIC Journal
+
+   At the Network Mail Meeting (see -- 14317,) the NIC outlined it's
+   requirements for implementing FTP Journal delivery and submission.
+
+   It had always been our thinking that those two services should rely
+   upon the File Transfer Protocol's MLFL command for their
+   implementation.
+
+   Prior to the meeting, we had envisioned that, in the case of
+   submission, for example, the user would embed what parameters the NIC
+   required (e.g., an indication that this piece of mail was to be
+   journalized, a list of NIC idents, etc.) in the USERNAME field of the
+   MLFL command, in a way that was transparent to his FTP user process,
+   and that SRI-ARC's FTP server process would parse the 'user name' for
+   the parameters and internally invoke the Journal System with them and
+   the text of the mail as arguments.
+
+      Our goal (which this scheme would have satisfied) was to provide
+      the desired services while confining software changes to our own
+      system and, in particular, to avoid requiring that user FTP
+      processes or the File Transfer Protocol itself be modified.
+
+   It was, however, the consensus of those present at the meeting that
+   it was preferable to modify FTP in such a way that all required
+   parameters could be explicitly declared, rather than require that
+   they be hidden within what purported to be simply a user name.
+
+   The intent of this RFC is to list what we (the NIC) believe were the
+   new FTP commands it was agreed should be defined in support of mail
+   submission and delivery. Actually, we've done some massaging after
+   thinking about the issues for awhile, and so this is really a
+   description of what we'd like to see included in the File Transfer
+   Protocol (following the lines of thought which developed at the
+   meeting), along with a short description of how the NIC would use
+   them.
+
+   Some of the commands currently make sense only if issued TO the NIC's
+   FTP server process (as opposed to anybody else's) and others only if
+   issued BY the NIC's FTP user process (as opposed to anybody else's).
+   This is true because currently only the NIC plans to offer mail
+
+
+
+
+
+White                                                           [Page 1]
+
+RFC 479              Use of FTP by the NIC Journal            March 1973
+
+
+   forwarding and recording (i.e., the Journal System) as a service.
+   However, other hosts may in the future desire to implement a similar
+   service, at which time these special commands will have wider use.
+
+   Conceptually, all of these commands are sub-commands of a new MAIL
+   command, but the intent for the moment is not to define their
+   position within the FTP dialogue nor their syntax, but simply to
+   describe them conceptually.  Details of syntax and use are left to
+   the FTP Interest Group which meets 16-MAR-73 in Boston (see --
+   14333,).
+
+   The new sub-commands are described below.  Bracketed fields are
+   optional; slash denotes a choice of two or more alternatives.
+
+      (1)  TITLE title
+
+         Where 'title' is a character string describing for the human
+         reader the contents of the mail.
+
+      (2)  USER-READABLE-AUTHOR author
+
+         Where 'author' identifies the author of the mail to the human
+         reader.  This may be a nickname, or any other identifier with
+         which the human sender chooses to sign his mail.
+
+      (3)  PROCESS-READABLE-AUTHOR last, first initial (ident)
+
+         Where the author's name (and ident if known) is made available
+         to the server in a form it can hope to parse (if need be).
+
+         This sub-command is important to the NIC, providing a basis for
+         locating the author in the NIC's Ident files.
+
+      (4)  FOR-ACKNOWLEDGMENT-AUTHOR username hostname
+
+         Where 'username' and 'hostname' define the sender in a way
+         useful in acknowledging delivery (of forwarded mail).
+
+            The acknowledgment will itself be a piece of mail sent from
+            the NIC to 'username' at 'hostname'.
+
+         It's important, conceptually, to note the NIC's unique role
+         here.  Normally, acceptance of the mail by the server would
+         constitute acknowledgment of delivery.  But, in the case of
+         Journal submission, the NIC acts only as a forwarding agent,
+         and hence delivery of mail by the sender to SRI-ARC isn't
+
+
+
+
+
+White                                                           [Page 2]
+
+RFC 479              Use of FTP by the NIC Journal            March 1973
+
+
+         really delivery at all -- only submission.  Final delivery
+         occurs when the NIC transmits a copy of the mail to each of its
+         addressees; hence the need for this special kind of
+         acknowledgment.
+
+         Note that this sub-command and the previous two constitute
+         different renderings of the sender's name.
+
+      (5)  ACKNOWLEDGMENT-DETAILS
+             DEFAULT / (COMPLETION / FAILURE / PERIODIC interval
+                        GIVEUP time
+                        TERSE / VERBOSE)
+
+         The value of the first parameter (ignoring 'DEFAULT' for the
+         moment) determines the conditions under which acknowledgment
+         will be made to the sender:
+
+            -- upon completion, whether delivery was successful or timed
+            out for one or more addressees,
+
+            -- only if delivery failed for one or more addressees, or
+
+            -- periodically until delivery is complete.
+
+         The value of the second parameter determines the time after
+         which delivery attempts will be discontinued.
+
+         The value of the third parameter determines how detailed -- in
+         some as yet unspecified sense -- an acknowledgment will be
+         returned.
+
+            A verbose acknowledgment might, in the case of delivery
+            failure, include a copy of the text of the message, or, for
+            mail sent by citation (see item 10 below), a pointer to it.
+
+         If DEFAULT is specified (in which case, FOR-ACKNOWLEDGMENT-
+         AUTHOR should not be specified, and 'DEFAULT' applies to it,
+         too), the NIC will extract a set of default values from its
+         Ident files, provided that a PROCESS-READABLE-AUTHOR subcommand
+         is present and the sender's NIC Ident can be inferred from it;
+         otherwise, the NIC will apply a set of (as yet unspecified)
+         system defaults.
+
+            The NIC's Ident files will be modified to contain, for each
+            user known to it, the kind of acknowledgment the user
+            usually wants (i.e., his default) and the username and
+            hostname that define the destination for such
+            acknowledgments.  These last two pieces of information will
+
+
+
+White                                                           [Page 3]
+
+RFC 479              Use of FTP by the NIC Journal            March 1973
+
+
+            also be used in delivering mail to the user if he has
+            requested Network delivery (as opposed to Online (at the
+            NIC) or hardcopy).
+
+      (6)  ADDRESSEES-ARE name1, name2, ...
+
+         This sub-command identifies the recipient(s) of the mail.  In
+         general, 'namei' will be the name by which the recipient is
+         known locally in the server's system.
+
+         The NIC's server FTP process will permit 'namei' to be any of
+         the following:
+
+            -- a NIC Ident (designating either an individual or a
+            group),
+
+            -- username hostname, where 'username' is the name by which
+            the addressee is known at host 'hostname', or
+
+            -- lastname, firstname initial , which the NIC will attempt
+            to parse and then locate in its Ident files.
+
+         Note that now the possibility of multiple addressees is
+         explicitly admitted by the Protocol, but the meaning of 'useri'
+         (to the server) is left server-dependent.
+
+      (7)  MAIL-CLASS
+             BULK/POSTCARD
+             SPECIAL-DELIVERY/FIRST-CLASS
+
+         The first parameter makes a statement about the size of the
+         mail, and the server may choose to use it to decide how and
+         where to store he mail for the addressee.
+
+         The second parameter makes a statement about the importance of
+         the mail, and the server may choose to expedite delivery (e.g.,
+         interrupt the user if he's logged in) for SPECIAL-DELIVERY
+         mail.
+
+      (8)  RECORD [identifier] [miscellaneous]
+
+         This is the command to the server to record the mail.
+         'Identifier' allows the sender the option of specifying a pre-
+         assigned identifier if he has one; if this field is not
+         present, the server assigns one.
+
+         'Miscellaneous' includes any server-dependent parameters which
+         the server may require or allow.
+
+
+
+White                                                           [Page 4]
+
+RFC 479              Use of FTP by the NIC Journal            March 1973
+
+
+         When this command is issued to the NIC, it will be taken as a
+         command to Journalize the mail, and 'identifier' may be:
+
+            NIC number [RFC number]
+
+         The NIC may allow 'miscellaneous' to contain such information
+         as comments, keywords, etc.
+
+      (9)  PRESERVED-AT hostname AS identifier
+
+         This is not a command but a statement of fact which the FTP
+         server will presumably relay to the user as it does the
+         information contained in (for example) the TITLE command.
+
+         The implication is that a copy of this piece of mail has been
+         preserved at 'hostname' and is retrievable -- on a long-term
+         basis -- with 'identifier'.  'Identifier' might, in general, be
+         a pathname.
+
+         When the NIC delivers Journal articles through the Net, it will
+         include this sub-command, and 'identifier' will be a NIC
+         number, and 'hostname' of course 'SRI-ARC' or 'NIC'.
+
+      (10) TEXT text
+           FILE pathname hostname
+
+         One of these two sub-commands is used to actually transmit the
+         mail:  the first transmits the text of the mail, the second a
+         pointer to it (leaving open to the FTP server (or his user) the
+         option of retrieving the text of the mail from the specified
+         host).
+
+         The NIC will transmit mail created within NLS with 'Submit
+         File' using the FILE command, and mail created with 'Submit
+         Message' using the TEXT command.   For mail entering the SRI-
+         ARC system via its FTP server process, the NIC will employ the
+         same command in delivery as was used in submission.
+
+
+
+
+
+       [ This RFC was put into machine readable form for entry ]
+      [ into the online RFC archives by Hannes Faestermann 12/97 ]
+
+
+
+
+
+
+
+White                                                           [Page 5]
+