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