doc: Add RFC documents

1 files changed, 293 insertions, 0 deletions

diff --git a/doc/rfc/rfc799.txt b/doc/rfc/rfc799.txt
new file mode 100644
index 0000000..b554b7f
--- /dev/null
+++ b/doc/rfc/rfc799.txt
@@ -0,0 +1,293 @@
+Network Working Group                                     D. L. Mills
+Request for Comments:  799                        COMSAT Laboratories
+                                                       September 1981
+
+
+	                   Internet Name Domains
+
+
+1.  Introduction
+
+     In the long run, it will not be practicable for every internet
+host to include all internet hosts in its name-address tables.  Even
+now, with over four hundred names and nicknames in the combined
+ARPANET-DCNET tables, this has become awkward.  Some sort of
+hierarchical name-space partitioning can easily be devised to deal
+with this problem; however, it has been wickedly difficult to find one
+compatible with the known mail systems throughout the community.  The
+one proposed here is the product of several discussions and meetings
+and is believed both compatible with existing systems and extensible
+for future systems involving thousands of hosts.
+
+2.  General Topology
+
+     We first observe that every internet host is uniquely identified
+by one or more 32-bit internet addresses and that the entire system is
+fully connected.  For the moment, the issue of protocol compatibility
+will be ignored, so that all hosts can be assumed MTP-competent.  We
+next impose a topological covering on the space of all internet
+addresses with a set of so-called name domains.  In the natural model,
+name domains would correspond to institutions such as ARPA, UCL and
+COMSAT, and would not be necessarily disjoint or complete.  While in
+principle name domains could be hierarchically structured, we will
+assume in the following only a single-level structure.
+
+     Every name domain is associated with one or more internet
+processes called mail forwarders and the name of that domain is the
+name for any of these processes.  Each forwarder process for a
+particular domain is expected to maintain duplicate name-address
+tables containing the names of all hosts in its domain and, in
+addition, the name of at least one forwarder process for every other
+domain.  Forwarder processes may be replicated in the interests of
+robustness; however, the resulting complexities in addressing and
+routing will not be discussed further here.  A particular internet
+host may support a number of forwarder processes and their collective
+names represent nicknames for that host, in addition to any other
+names that host may have.  In the following an internet host
+supporting one or more forwarder proceses will be called simply a
+forwarder.
+
+     Every host is expected to maintain name-address tables including
+the names of at least one forwarder for every
+
+
+Internet Name Domains                               PAGE   2
+
+
+
+domain together with additional hosts as convenient.  A host may
+belong to several domains, but it is not necessary that all hosts in
+any domain, be included in its tables.  Following current practice,
+several nicknames may be associated with the principal name of a host
+in any domain and these names need not be unique relative to any other
+domain.  Furthermore, hosts can be multi-homed, that is, respond to
+more than one address.  For the purpose of mail forwarding and
+delivery, we will assume that any of these addresses can be used
+without prejudice.  The use of multi-homing to facilitate source
+routing is a topic for future study.
+
+3.  Naming Conventions
+
+     In its most general form, a standard internet mailbox name has
+the syntax
+
+                  <user>.<host>@<domain> ,
+
+where <user> is the name of a user known at the host <host> in the
+name domain <domain>.  This syntax is intended to suggest a
+three-level hierarchically structured name (reading from the right)
+which is unique throughout the internet system.  However, hosts within
+a single domain may agree to adopt another structure, as long as it
+does not conflict with the above syntax and as long as the forwarders
+for that domain are prepared to make the requisite transformations.
+For instance, let the name of a domain including DCNET be COMSAT and
+the name of one of its hosts be COMSAT-DLM with Mills a user known to
+that host.  From within the COMSAT domain the name Mills@COMSAT-DLM
+uniquely identifies that mailbox as could, for example, the name
+Mills.COMSAT-DLM@COMSAT from anywhere in the internet system.
+However, Mills@COMSAT-DLM is not necessarily meaningful anywhere
+outside the COMSAT domain (but it could be).
+
+     A typical set of name domains covering the current internet
+system might include ARPA (ARPANET), COMSAT (DCNET), DCA (EDNET,
+WBNET), UCL (UCLNET, RSRENET, SRCNET), MIT (CHAOSNET), INTELPOST
+(INTELPOSTNET) and the various public data networks.  The ARPA
+forwarder would use a name-address table constructed from the latest
+version of the HOSTS.TXT table in the NIC data base.  The other
+forwarders would construct their own, but be expected to deposit a
+copy in the NIC data base.
+
+4.  Mail Transport Principles
+
+     In the interests of economy and simplicity, it is expected that
+the bulk of all mail transport in the internet system will take place
+directly from originator to recipient
+
+
+Internet Name Domains                               PAGE   3
+
+
+
+host and without intermediate relay.  A technique of caching will
+probably be necessary for many hosts in order to reduce the traffic
+with forwarders merely to learn the internet address associated with a
+correspondent host.  This naturally encourages naming strategies
+designed to minimize duplicate names in the various domains; however,
+such duplicates are not forbidden.
+
+     There are several reasons why some messages will have to be
+staged at an intermediate relay, among them the following:
+
+1.  It may not be possible or convenient for the  originator
+    and recipient hosts to be up on the internet system at
+    the same time for the duration of the transfer.
+
+2.  The originator  host  may  not  have  the  resources  to
+    perform all name-address translations required.
+
+3.  A direct-connection path may  not  be  feasible  due  to
+    regulatory economic or security constraints.
+
+4.  The originator and recipient hosts may not recognize the
+    same lower-level transport protocol (e.g.  TCP and NCP).
+
+     A mail relay is an internet process equipped to store an MTP
+message for subsequent transmission.  A mail forwarder is a mail
+relay, but not all relays are forwarders, since they might not include
+the full name-address capability required of forwarders.  In addition,
+relays may not be competent in all domains.  For instance, a MTP/TCP
+relay may not understand NCP.  In other words, the forwarders must be
+fully connected, but the relays may not.
+
+     The particular sequence of relays traversed by a message is
+determined by the sender by means of the source route specification in
+the MRCP command.  There are several implications to this:
+
+1.  Advisory messages returned to the originator by a relay
+    or recipient host are expected to traverse the route in
+    reverse order.
+
+2.  Relay host names follow the same  naming  convention  as
+    all  host  names relative to their domain.  Since it may
+    not be possible (see below) to use internet addresses to
+    dis-ambiguate the domain, the complete standard internet
+    name .<host>@<domain> is required everywhere.
+
+3.  There is no current  provision  for  strict/loose  route
+    specifications.    If,  in  fact,  the  "ordinary"  host
+    specification @<host> were used, each relay or forwarder
+
+Internet Name Domains                               PAGE   4
+
+
+
+    would  use  the  rules  outlined in the next section for
+    routing.  This may result in additional relay hops.
+
+5.  Forwarder Operations
+
+     This section describes a likely scenario involving hosts, relays
+and forwarders and typical internet routes.  When a forwarder receives
+a message for <user>.<host>@<domain>, it transforms <host> if
+necessary and forwards the message to its address found in the
+name-address table for <domain>.  Note that a single host can be a
+forwarder for several independent domains in this model and that these
+domains can intersect.  Thus, the names Mills@USC-ISIE,
+Mills.USC-ISIE@ARPA and Mills.USC-ISIE@COMSAT can all refer to the
+same mailbox and the names USC-ISIE, ARPA and COMSAT can, conceivably,
+all be known in the same domain.  Such use would be permissable only
+in case the name USC-ISIE did not conflict with other names in this
+domain.
+
+     In order for this scheme to work efficiently, it is desireable
+that messages transiting forwarders always contain standard internet
+mailbox names.  When this is not feasible, as in the current ARPANET
+mail system, the forwarder must be able to determine which domain the
+message came from and edit the names accordingly.  This would be
+necessary in order to compose a reply to the message in any case.
+
+     In the RFC-780 model a message arriving at a forwarder is
+processed by the MTP server there.  The server extracts the first
+entry in the recipient-route field of an MRCP command.  There are two
+cases, depending on whether this entry specifies a domain name or a
+host name.  If a domain name, as determined by a search of a universal
+table, it refers to one of the domains the server represents.  If not,
+it must a name or nickname of the server's host relative to ooe of the
+domains to which the sender belongs.  This allows a distinction to be
+made between the domains COMSAT and INTELPOST on one hand and the
+COMSAT host COMSAT-PLA on the other, all of which might be represented
+by the same internet address, and implies that domain names must be
+unique in all domains.
+
+     The server next extracts the second entry in the recipient-route
+field of the MRCP command and resolves its address relative to the
+domain established by the first entry.  If the second entry specifies
+an explicit domain, then that overrides the first entry.  If not and
+the first entry specifies a domain, then that domain is effective.
+However, if the first entry specifies the server's host, it may not be
+apparent which domain is intended.  For instance, consider the
+following two MRCP commands:
+
+Internet Name Domains                               PAGE   5
+
+
+
+MRCP to:<@COMSAT,Mills@HOST> and 
+MRCP to:<@INTELPOST,Mills@HOST> ,
+
+where Mills.HOST@COMSAT and Mills.HOST@INTELPOST are distinct
+mailboxes on different hosts.  A receiving host supporting forwarders
+for both COMSAT and INTELPOST can then preserve this distinction and
+forward correctly using the above rules.
+
+     Now let the forwarder host have the name FORWARDER in both the
+COMSAT and INTELPOST domains and consider its options when receiving
+the command
+
+MRCP to:<@FORWARDER,Mills@HOST> .
+
+The forwarder is being asked simply to relay within the domain of the
+sender; however, it belongs to more than one domain! The obvious way
+to resolve this issue would be to forbid the use of implicit domains,
+as represented by Mills@HOST, and require the full internet mailbox
+names Mills.HOST@COMSAT or Mills.HOST@INTELPOST.  It is also possible
+to dis-ambiguate the domain by inspecting the first entry of the
+sender-route field of the MAIL command (see below).
+
+6.  Source and Return Routing
+
+     In the RFC-780 model, routes can be specified in the
+recipient-route field of the MRCP command and in the sender-route
+field of the MAIL command.  In point of fact, neither the
+recipient-route or sender-route is necessary if the originator
+specifies standard internet mailbox names.  So long as the routes,
+when used, consist only of domain names, there is no conflict with the
+current RFC-780 specification.  If for some reason forwarding must be
+done via other hosts, then the use of a complete and unambigous syntax
+like .<host>@<domain> is required in order to avoid problems like that
+described above.
+
+     The present RFC-780 specification requires the receiver to
+construct a name for the sender and insert this at the beginning of
+the sender-route.  Presumably, the only information it has to
+construct this name is the internet address of the sender.  Consider
+the case, as in the example above, where multiple domains are
+supported by a single server on a particular host.  If hosts receiving
+a message relayed via that server were to map its address into a name,
+there would be no way to determine which domain was intended.  We
+conclude that the sending host must update the sender-route as well as
+the recipient-route.  It does this simply by copying the first entry
+in the recipient-route as received as the new first entry in the
+sender-route.
+
+Internet Name Domains                               PAGE   6
+
+
+
+7.  Editing the RFC-733 Header
+
+     Every effort should be made to avoid editing the RFC-733 header,
+since this is an invasive procedure requiring extensive analysis.  It
+is expected that newly developed mail systems will be aware of the
+standard internet mailbox syntax and ensure its use everywhere in the
+RFC-733 and RFC-780 fields.  On the occasions where this is not
+possible, such as in many current ARPANET hosts, the necessary editing
+should be performed upon first entry to the internet mail system from
+the local mail system.  This avoids the problems mentioned above and
+simplifies reply functions.
+
+     In the case of ARPANET hosts, the editing operations assume that
+all names in the form <anything>@<domain>, where <domain> is the name
+of a domain, are unchanged.  Names in the form <anything>@<host>,
+where <host> is the name of a host in the ARPA domain, are transformed
+to the form <anything>.<host>@ARPA.  Anything else is an error.
+Before handing off to an ARPANET NCP mailer, an ARPA MTP forwarder
+might optionally transform <anything>.<host>@ARPA to <anything>@<host>
+in order to reduce the forwarder traffic when local mail systems are
+available.  Similar situations might exist elsewhere.
+
+8.  Concluding Remarks
+
+     This memorandum is intended to stimulate discussion, not simulate
+it. 
+-------