doc: Add RFC documents

1 files changed, 638 insertions, 0 deletions

diff --git a/doc/rfc/rfc773.txt b/doc/rfc/rfc773.txt
new file mode 100644
index 0000000..45ee2bc
--- /dev/null
+++ b/doc/rfc/rfc773.txt
@@ -0,0 +1,638 @@
+
+                                                                        
+Network Working Group                                            V. Cerf
+Request for Comments: 773                                          DARPA
+                                                            October 1980
+
+          COMMENTS ON NCP/TCP MAIL SERVICE TRANSITION STRATEGY
+
+
+INTRODUCTION
+
+   This memo reviews and expands on the mail service transition plan
+   [20].
+
+   The principal aim of the plan is to provide for the orderly support
+   of the most commonly used network service (mail) during the period of
+   transition from ARPANET to Internet Protocol-based operation.
+
+   The goal of the transition is, at the end, to provide in the internet
+   environment service which is equivalent to or better than what has
+   been available in the ARPANET environment.  During the interim
+   period, when both internet and the older ARPANET-based protocols are
+   in use, the goal of the transition is to minimize user impact and, to
+   the extent possible, to minimize software development or modification
+   required to deal with transitional problems.
+
+   It is assumed that the reader is familiar with both the ARPANET and
+   internet protocol hierarchies [1-17].  The internet hierarchy is
+   designed to interface to many different packet networks (e.g., packet
+   satellite, packet radio, Ethernet, LCS Ring net, X.25 public
+   nets, ...), while the ARPANET hierarchy is limited to ARPANET IMPs
+   (This is less true of the levels above NCP, but NCP itself is closely
+   bound to ARPANET services).
+
+   The objective of the transition plan is to specify means by which the
+   ARPANET electronic mail services may be supported across the boundary
+   between the purely ARPANET environment and the more general internet
+   environment during the period of transition by ARPANET hosts to the
+   richer internet world.
+
+ELECTRONIC MESSAGE SERVICES
+
+   DARPA is beginning a new phase of research into automatic electronic
+   message handling systems.  Ultimately, it is intended that electronic
+   messages incorporate multiple media such as text, facsimile,
+   compressed digitized voice, graphics and so on.  Success in this new
+   research will require substantial progress in developing multimode
+   user interfaces to computer-based services (voice input/output,
+   graphics, tablet/light pen, facsimile input/output, video/bit mapped
+   displays, ...).
+
+   At the same time, progress must be made towards an environment based
+   on internet protocols so as to avoid confining the results of the
+
+
+
+                                   1
+
+
+                                                                        
+October 1980                                                     RFC 773
+Comments on NCP/TCP Mail Service Transition Strategy                    
+
+
+
+   multimedia effort to any one network.  As a result, DARPA is planning
+   to make several transitions over the next few years, from the
+   existing, text-based ARPANET electronic message system to an
+   internet-based, multimedia electronic message system.
+
+   This paper addresses only the first of the transitions from NCP-based
+   text mail to TCP-based multimedia mail.  The transition to the new
+   multimedia mail system [7,19] lies ahead, but need not be planned in
+   detail until we have some experience with the basic concepts.  This
+   first step only provides for the transition to TCP-based text mail.
+
+   The basic ground rules for transition from ARPANET-based electronic
+   mail to internet electronic mail are the following:
+
+      1.  ARPANET mailbox names must continue to work correctly.
+
+      2.  No change required to mail editors which parse message headers
+          to compose replies and the like.
+
+      3.  Accommodation of non-ARPANET mailbox designators without
+          change to the header parsing and checking mechanisms of mail
+          composition programs.
+
+      4.  Automatic forwarding of messages between NCP and TCP
+          environments without user intervention.
+
+      5.  During the transition, old style mail mechanisms must still
+          work.
+
+ELECTRONIC MESSAGE MECHANISMS
+
+   In order to make progress at all, it has been necessary to postulate
+   fairly sophisticated changes to the "mailer" function which accepts
+   as input an electronic text message and causes it to be delivered to
+   the destination (or to an intermediate forwarder).
+
+   We also posit the existence of special, well-known mail forwarding
+   hosts on the ARPANET which are responsible for accepting messages
+   from NCP (TCP)-based message senders and forwarding them to
+   TCP (NCP)-based message receivers.
+
+   In the ARPANET, electronic messages are transported via special
+   procedures of the File Transfer Protocol:  MAIL and MLFL.  The former
+   method sends electronic messages via the FTP Telnet command channel
+
+
+
+
+
+                                   2
+
+
+                                                                        
+RFC 773                                                     October 1980
+                    Comments on NCP/TCP Mail Service Transition Strategy
+
+
+
+   while the latter achieves this by actual file transfer.  In both
+   cases, it is generally assumed that the receiving FTP server is
+   colocated with the destination mailbox.
+
+   Thus, the sending procedure identifies to the receiver the
+   destination mailbox identifier, but not the destination host (or
+   network) identifier.  For example, messages sent from Postel at
+   USC-ISIF to Adams at USC-ISIA would arrive at ISIA with an indicator
+   "Adams" but no indication of "ISIA".  This creates some problems when
+   messages must be staged at an intermediate host for further
+   processing, as is the case when moving from an NCP-based sender to a
+   TCP-based receiver, or vice-versa.  Similar considerations arise when
+   dealing with compatible, but different, message systems requiring
+   re-formatting of messages at intermediate points.
+
+   In the following paragraphs, a mechanism is proposed for dealing with
+   the naming, addressing and routing [18] of messages between systems.
+
+   At the source, it is assumed that the user has prepared the text of
+   the message (including "To:" and "CC:" fields) in the conventional
+   way [12].  The mailbox identifiers will continue to exhibit the
+   format:
+
+      User@Host
+
+   but "host" may in fact be a compound name (which is not necessarily
+   parsed), such as:
+
+      USC-ISIA
+      ARPANET-ISIA
+      SATNET-NDRE
+      PPSN-RSRE
+      HOST1.SRINET
+      LCSNET/MAILROOM
+
+   or even the name of an organization, such as:
+
+      BBN
+      ARPA
+      MIT
+      SRI
+
+   The only restriction is that the "@" not appear in either "user" or
+   "host" strings in the mailbox identifier.
+
+   During message composition, the "user" or "host" portions of the
+
+
+
+                                   3
+
+
+                                                                        
+October 1980                                                     RFC 773
+Comments on NCP/TCP Mail Service Transition Strategy                    
+
+
+
+   mailbox identifier may be verified for correctness (or at least for
+   validity).  The "user" string may incorporate parenthetical
+   information such as
+
+      RAK(Richard A. Karp)@SU-AI
+
+   as is currently allowed.
+
+   After composition, messages are either sent immediately or left as
+   "unsent mail" files to be sent later by mailer demons.  The actual
+   sending process uses the "host" string to determine where and how to
+   send the message.
+
+NEW MAIL MECHANISMS
+
+   At this point, we encounter the first critical new requirement to
+   support the transition plan.  A new table is needed within the mailer
+   or in the host supporting the mailer or accessible to the mailer via
+   the internet name server (for instance).  This table must provide for
+   mapping of the "host" string into an internet destination address
+   (i.e., 32 bits: 8 bits of net, 24 bits of host), and must also
+   indicate whether the destination is NCP or TCP capable.
+
+   In the event that the source and destination hosts do not have a
+   compatible host level protocol (e.g. source is NCP only, destination
+   is TCP only) then the message must be passed to a "forwarder" which
+   can stage the transport by accepting via one protocol and forwarding
+   by another.
+
+   This leads to a problem for the forwarding host since the basic FTP
+   mail mechanism sends only the "user" portion of the mailbox
+   identifier ("user@host") because the assumption is that the "host" is
+   the destination.  In the case of forwarding, the "host" is not the
+   forwarder.  Even if we cleverly arrange for "host" to translate into
+   the internet address of a forwarder, we will have two problems.
+   First, the forwarder may need the "host" information to figure where
+   now to forward the message and second, depending on which network the
+   source is in, "host" may need to translate into different forwarder
+   addresses.  The latter observation raises the spectre of many
+   different mappings of a given "host" string which would require
+   different tables for different mail sources.  This would lead to
+   considerable complexity in the maintenance and distribution of tables
+   of forwarder addresses.  Furthermore, a single-entry table mapping
+   "host" to forwarder would limit reliability since only one forwarder
+   would be bound to serve a giver "host".
+
+
+
+
+                                   4
+
+
+                                                                        
+RFC 773                                                     October 1980
+                    Comments on NCP/TCP Mail Service Transition Strategy
+
+
+
+   For the NCP/TCP transition, it may be sufficient to declare some set
+   of well-known hosts to be NCP/TCP forwarders.  Each mailer, when it
+   discovers an incompatible destination, can send the message to any
+   forwarder which is available.  In addition, however, the mailer must
+   provide full mailbox identifier information "user@host" to the
+   forwarding host.
+
+   In the present mailers, only the "user" portion of the mailbox
+   identifier is sent, so all mailers must change to send "user@host"
+   when sending to a forwarder.  The mailers all have to learn how to do
+   table look-up a new way, also, to map "host" into internet addresses
+   and to interpret the NCP or TCP capability information.
+
+   For purposes of this discussion, we postulate three different cases
+   of electronic mail service implementation which must be made to
+   interoperate during the transition:
+
+      1.  Unchanged OLD NCP (RFC733) mail
+
+      2.  NCP mail with new internet tables
+
+      3.  TCP mail with new internet tables.
+
+   The second case assumes that the host has adopted a new host-string
+   to address table (including NCP/TCP capability bits) and new mailer -
+   mail server programs, but continues to use the old NCP host level
+   protocol, modified to send "user@host" when sending to a forwarder.
+   For such hosts, the only table entries which result in direct
+   source-destination mail delivery are those showing NCP capability.
+   If the destination is TCP capable only then the source host selects a
+   forwarder address from another table and sends the message to it for
+   further processing.
+
+   In the third case, the source host has fully transitioned to TCP,
+   uses the new internet address tables to translate host-strings into
+   internet addresses, and uses the new mailer - mail server.
+   Destinations which are NCP-compatible only are reached via NCP/TCP
+   forwarders.
+
+   Mail composition programs (e.g. SNDMSG, MSG, Hermes, MH,...) which
+   today use ARPANET string-to-address tables to verify the legality of
+   host names in mailbox entries can continue to use these "old" tables
+   as long as these are updated to include internet host names as well
+   as ARPANET host names.
+
+   Indeed, expanding the old tables is essential to handle the hardest
+
+
+
+                                   5
+
+
+                                                                        
+October 1980                                                     RFC 773
+Comments on NCP/TCP Mail Service Transition Strategy                    
+
+
+
+   transition case:  OLD NCP to new TCP mail.  The three types of hosts
+   lead to a 3 by 3 matrix of cases of mail transfer.  In all but one
+   case, mail is either handled directly or explicitly by forwarder.
+   The only case needing further explanation is OLD NCP to NEW TCP which
+   uses an "implicit forwarder."
+
+IMPLICIT FORWARDING VS EXPLICIT FORWARDING
+
+   If the source host has adopted the new internet tables, it can tell
+   whether the destination host has a compatible mail acceptance
+   protocol.  Incompatibility is explicitly resolved by selection of an
+   intermediate forwarder.
+
+   If, however, the source host is still using pure NCP tables, it will
+   not be able to tell that a particular destination host is only
+   TCP-capable.  To provide service for this case, it is proposed to
+   expand the conventional NCP host table to include internet host
+   names, but to map them into the addresses of implicit mail forwarders
+   (i.e. Aliases).
+
+   Since we are postulating a case in which the NCP host has made no
+   change (except for extending the host table). we also assume that the
+   source host cannot send the "user@host" information via FTP to the
+   intermediate forwarder.
+
+   This leaves the intermediate forwarder with the problem of figuring
+   out where to forward a message identified by "user" only.  In this
+   case, we postulate that internet TCP-only mailboxes are registered at
+   implicit forwarders so that incoming mail from conventional NCP
+   sources can be forwarded successfully to the destination.
+
+   In the reverse direction, the source can use explicit forwarding
+   because it is assumed that all TCP hosts use the new internet tables.
+
+   The use of registered names in the implicit forwarder raises two
+   problems:
+
+      1.  How can we deal with ambiguous mailbox names?  (e.g. USERX@BBN
+          and USERX@ISI look the same if only the string "USERX" is
+          presented to the intermediate forwarder)
+
+      2.  How can we collect, update and distribute changes to the
+          registries at implicit forwarders?
+
+   In the first case, we propose to duck the problem by insisting on
+
+
+
+
+                                   6
+
+
+                                                                        
+RFC 773                                                     October 1980
+                    Comments on NCP/TCP Mail Service Transition Strategy
+
+
+
+   unambiguous mailbox names everywhere.  This may force some internet
+   mail users to change their mailbox names, but we believe this will be
+   rare.
+
+   The second problem can be solved by collecting information on a
+   regular basis from all network mail users and cataloging this data in
+   a database which can be accessed automatically (e.g. by mailer
+   programs).
+
+   One possible mechanism is to make the data available through an
+   internet mailbox name server analogous to the internet host name
+   server [6].  This data might be collectible as a natural part of the
+   TIP LOGIN database which is under development to permit expanded
+   access to the ARPANET TIPs by legitimate ARPANET users.
+
+   In any case, internet mail users need supply their mailbox
+   information to a single collection site which would disseminate it to
+   all implicit forwarders on ARPANET.  Note that such forwarders are
+   only needed on ARPANET since all other systems are starting with the
+   TCP-base.  It is the internet mailbox users who must register,
+   however, since they are the ones who cannot otherwise be reached via
+   NCP.
+
+FORWARDER CHARACTERISTICS
+
+   By their definition, NCP/TCP forwarders must be both NCP and TCP
+   capable. Consequently, all NCP/TCP forwarders must be ARPANET hosts.
+
+   Implicit forwarders must accept conventional NCP/FTP mail [11] and be
+   equipped with tables of valid internet user mailbox names which can
+   be associated with the proper destination host.  To allow implicit
+   forwarders to also accept ordinary mail for users with mailboxes on
+   the implicit forwarder, the forwarder should check first whether
+   incoming mail is for a local user.
+
+   Explicit mail forwarders must be able to accept both conventional
+   NCP-FTP mail commands (for local user mail) and both NCP-based and
+   TCP-based mail server commands (whose arguments include the full
+   destination mailbox strings "user@host").
+
+   To prevent potentially anomalous behavior, the NCP-based and
+   TCP-based mail servers will offer service on socket/port 57 (71
+   octal).  To summarize the communication patterns:
+
+      (a)  TCP sends/receives mail via well known port 57.
+
+
+
+
+                                   7
+
+
+                                                                        
+October 1980                                                     RFC 773
+Comments on NCP/TCP Mail Service Transition Strategy                    
+
+
+
+      (b)  implicit forwarder receives conventional NCP/FTP mail on
+           well-known socket 3, and sends TCP mail to port 57.
+
+      c)  explicit forwarder receives NCP mail on well-known socket 57,
+           but sends NCP mail via NCP/FTP on socket 3.  TCP mail is
+           sent/received via port 57.
+
+USER HOST CHARACTERISTICS
+
+   NCP hosts must at minimum, update host name tables to include aliases
+   for internet hosts (i.e. map to NCP implicit forwarder host
+   addresses).
+
+   The next most useful step is to update NCP hosts to include internet
+   address tables and NCP/TCP capability bits so as to make use of
+   explicit forwarders.  This requires implementation of the mail server
+   and modification of the mailer programs for sending mail to explicit
+   forwarders.  This also requires addition of explicit forwarder
+   address tables.
+
+   Finally, a host can implement full TCP mail services, incorporating
+   internet name tables and explicit forwarder address tables as well.
+
+DANGLING PARTICIPLES
+
+   1.  Error message handling needs to be worked out in detail to assure
+       reasonable reporting of problems with the use of forwarders.
+
+   2.  Designation of forwarding hosts.
+
+   3.  Collection of internet mailbox names for implicit forwarders.
+
+   4.  Format and distribution of internet name table and NCP/TCP
+       capability information.
+
+   5.  Dealing with mail systems not compatible with NCP, TCP or RFC733.
+       (e.g. Telemail, On-Tyme, Phonenet, TWX, TELEX,...)
+
+
+
+
+
+
+
+
+
+
+
+
+                                   8
+
+
+                                                                        
+RFC 773                                                     October 1980
+                    Comments on NCP/TCP Mail Service Transition Strategy
+
+
+
+PLANS
+
+   To encourage this transition, the following schedule is proposed:
+
+      1.  January 1, l981 - implicit and explicit NCP/TCP forwarders
+          made available on various service hosts (e.g. TOPS-20).
+
+      2.  January 1, l982 - implicit NCP/TCP forwarder service removed;
+          explicit forwarding service continues.
+
+      3.  January 1, l983 - explicit NCP/TCP forwarding service
+          terminated, transition to TCP complete.
+
+ACKNOWLEDGEMENTS
+
+   A number of people have reviewed and commented on this contribution.
+   Particular comments by J. Pickens, J. Postel, J. Haverty, D. Farber
+   and D. Adams are gratefully acknowledged.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                   9
+
+
+                                                                        
+October 1980                                                     RFC 773
+Comments on NCP/TCP Mail Service Transition Strategy                    
+
+
+
+                               REFERENCES
+
+   1.  DoD Standard Internet Protocol, IEN 128, RFC 760, NTIS
+       ADA 079730, Jan 1980.
+
+   2.  DoD Standard Transmission Control Protocol, IEN 129, RFC 761,
+       NTIS ADA 082609, Jan 1980.
+
+   3.  Postel, J., Telnet Protocol Specification, IEN 148, RFC 764,
+       Jun 1980.
+
+   4.  Postel, J., File Transfer Protocol, IEN 149, RFC 765, Jun 1980.
+
+   5.  Postel, J., User Datagram Protocol, RFC 768, Aug 1980.
+
+   6.  Postel, J., Internet Name Server, IEN 116, Aug 1979.
+
+   7.  Postel, J., Internet Message Protocol, IEN 113, RFC 759, Aug
+       1980.
+
+   8.  Postel, Sunshine, Cohen, The ARPA Internet Protocol, in
+       preparation.
+
+   9.  NCP:  ARPANET Protocol Handbook, NIC 7104, Jan 1978.
+
+   10.  Telnet:  ARPANET Protocol Handbook, NIC 7104, Jan 1978.
+
+   11.  FTP:  ARPANET Protocol Handbook, NIC 7104, Jan 1978.
+
+   12.  D. Crocker, J. Vittal, K. Pogran, A. Henderson, Standard for the
+        Format of ARPA Network Text Messages, RFC 733, Nov 1977.
+
+   13.  Crocker, et.al., Function-Oriented Protocols for the ARPA
+        Computer Network, SJCC, May, 1972.
+
+   14.  Carr, Crocker, Cerf, Host-Host Communication Protocol in the
+        ARPA Network, SJCC, May, 1970.
+
+   15.  Cerf, V., The Catenet Model for Internetworking, IEN 48,
+        DARPA/IPTO, Jul 1978.
+
+   16.  BBN 1822:  Specifications for the Interconnection of a Host and
+        an IMP, BBN Report No. 1822.
+
+   17.  Heart, et.al., The Interface Message Processor for the ARPA
+        Computer Network, SJCC, May, 1970.
+
+
+
+                                   10
+
+
+                                                                        
+RFC 773                                                     October 1980
+                    Comments on NCP/TCP Mail Service Transition Strategy
+
+
+
+   18.  Shoch, J., Inter-Network Naming, Addressing, and Routing,
+        COMPCOM, Fall 1978.
+
+   19.  Postel, J., A Structured Format for Transmission of Multi-Media
+        Documents, RFC 767, Aug 1980.
+
+   20.  Cerf, V. and, J. Postel, Mail Transition Plan, RFC 771,
+        Sep 1980.
+
+   21.  Sluizer, S. and, J. Postel, Mail Transfer Protocol, RFC 772,
+        Sep 1980.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                   11
+
\ No newline at end of file