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 .@ is required everywhere.

3.  There is no current  provision  for  strict/loose  route
    specifications.    If,  in  fact,  the  "ordinary"  host
    specification @ 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 .@, it transforms  if
necessary and forwards the message to its address found in the
name-address table for .  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.