Internet name domains
RFC 799

Document Type RFC - Unknown (September 1981; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 799 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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

     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,
(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
Show full document text