    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.
    -------