As per Relevance of the word delivery, we have this rfc below:
RFC 757
A Suggested Solution to the Naming, Addressing, and
Problem for ARPAnet Message
Debra P.
10 September 1979
Bolt Beranek and
50 Moulton
Cambridge, Massachusetts 02138
(617) 491-1850
Preface Page 1
Unlike many RFCs, this is not a specification of
soon-to-be-implemented protocol. Instead this is a true
for comments on the concepts and suggestions found within
document, written with the hope that its content, and
discussion which it spurs, will contribute towards the design
the next generation of computer-based message creation
delivery systems
A number of people have made contributions to the form
content of this document. In particular, I would like to
Jerry Burchfiel for his general and technical advice
encouragement, Bob Thomas for his wisdom about the TIP
database and design of a netmail database, Ted Myer for
devil's advocate, and Charlotte Mooers for her
editorial assistance
Debbie
RFC 757 September 1979
Introduction Page 2
1.
The current ARPAnet message handling scheme has evolved
rather informal, decentralized beginnings. Early developers
advantage of pre-existing tools -- TECO, FTP -- in order
implement their first systems. Later, protocols were
to codify the conventions already in use. While
conventions have been able to support an amazing variety
amount of service, they have a number of shortcomings
One difficulty is the naming/addressing problem, which
with the need both to identify the recipient and to
correctly a delivery point for the message. The current
is deficient in that it lacks a sharp distinction between
recipient's name and the recipient's address, which is
delivery point on the net
The naming/addressing scheme does not allow users to
their messages using human names, but instead forces them
employ designations better designed for machine parsing
human identification
Another source of limitations lies in the delivery system
which is simply an extension of the File Transfer Protocol.
delivery system is fairly limited in its operation, handling
simple transactions involving the transfer of a single message
a single user on the destination host. The ability to
messages and the ability to fan-out messages at the foreign
would improve the efficiency and usefulness of the system
An additional drawback to the delivery system is caused,
some extent, by the addressing scheme. A change in address,
incorrect address usually causes the delivery system to
the message incorrectly. While some hosts support some
of a mail forwarding database (MFDB), this solution is at
inadequate and spotty for providing reliable service to
network as a whole. Because the same username may belong
different people at different hosts, ambiguities which may
up when messages are incorrectly addressed keep even the
MFDBs from always being able to do their job
This proposal envisions a system in which the identity
address of the recipient are treated as two separate items.
network database supports a directory service which
correct address information for all recipients. Additionally
the scheme allows mail delivery to be restricted to
users of the network, should that be a desirable feature
RFC 757 September 1979
Names and Addresses Page 3
2. Names and
Today's ARPAnet naming and addressing scheme (as specified
RFC 733[3]) does not discriminate between the identity of a
1
and his address . Both are expressed the same way
USERNAME@HOST. While this should always result in a
handle for that user, it has proved to be inadequate in practice
Users who change the location of their mailboxes, because
either a change in affiliation or a simple shift in host usage
also get their names changed. If their old host employs an
the problem is not too bad. Mail is simply forwarded on to
new address, slightly delayed. Other less fortunate users
cannot rely upon an MFDB must notify all their correspondents
the change in address/name. Any mail addressed to the
address becomes undeliverable. (An excellent discussion of
differences between naming, addressing, and routing is found in
paper by John Shoch [1].)
The desire to use "real" names in the address fields
messages is also thwarted by the current system. An
system for using human-compatible vs. machine-
2
information has been evolved for use in message headers .
most recent developments indicate that many users would
happiest if the real human name could appear
machine-interpretable information should not intrude too
into the writer's work- and thought-space
The solution proposed here calls for a total break between
way a recipient is named or identified and the way in which
location is specified. Since the ARPAnet is a
environment, a unique (and not necessarily human-readable)
could be assigned to each authorized recipient of network mail
This ID would stay with the user throughout his lifetime on
network, through changes in address and affiliation
A network database (which could be derived from the
database that has been proposed to support TIP login)
associate each ID with one or more addresses indicating where
mail for that ID may be delivered. If more than one address
_______________
1
See, for example, RFC 733's discussion of the semantics
address fields, in which it is specified that the To:
"contains the identity of the primary recipients of the message".
2
See the "Syntax of General Addressee Items" section of
733.
RFC 757 September 1979
Names and Addresses Page 4
associated with an ID, that would indicate an ordered
in delivery points. The delivery system would attempt
to the first addressee, and, if that failed, try the second,
3
so on . Most IDs would probably have only one address.
associated with each ID would be some information about the ID'
owner: name, postal address, affiliation, phone number, etc
Rather than being forced to type some awkward character
in order to name his correspondent, the writer would have
supply only enough information to allow some process to
the unique identity of the recipient. This information might
the recipient's name or anything else found in the database
The access to this data would also free the writer from
need to know the location of the recipient. Once the unique
were known, the correct location for delivery would be only
look-up away
2.1 A distributed database
It is clear that if the network database had only
instantiation there would be a tremendous contention problem
All message traffic would be forced to query that one database
This is extremely undesirable, both in terms of reliability
speed. It is also clear that requiring each host to maintain
complete local copy of the entire network database is
undesirable and unnecessary burden on the hosts
A better approach would be to build some sophistication
the local delivery system, and use local mini-databases which
based upon the contents of a distributed network database. (
may be redundant and/or partitioned, etc., but is probably
resident on the local host.) When a local host queries
network database about an ID (or, in a more costly operation
asked to supply an ID given enough identification such as name
etc.) the database may be asked to return all its information
that ID. At this point the local host can enter all or some
that information into a locally maintained database of its own
It will always refer to that database first when looking for
name or address, only calling the network database if it
find a local entry. Depending upon the desired level
sophistication of the local message handling programs,
information may be added to that database, including,
_______________
3
Multiple addresses might also be used to indicate
multiple deliveries are desired
RFC 757 September 1979
Names and Addresses Page 5
example, nicknames
The database might be shared by a cluster of hosts (such
exist at BBN or ISI), or it might be used by only one.
which originate small amounts of message traffic might rely
the network database entirely
The structure and maintenance of the local databases is
solely to the local hosts. They may or may not store addresses
It may be desirable either to garbage collect them, or to
them grow. The local databases might be linked to smaller,
specialized databases which are owned by individual users
groups. These individual databases would be the equivalent
address books in which users might note special things
individuals: interests, last time seen, names of associates
etc. The existence and scope of these databases are not
by this scheme, but it does allow for them
The same individual databases may be used by message
programs in order to determine the recipient's ID
user-supplied input. For example, a user may address a
to someone named Nick. The message creation program
associate "Nick" with an ID, and hand that ID off to the
system, totally removing the matter of address or formal ID
the user's world
2.2
The delivery operation consists of three parts
1. Determining the address to which the message must
sent
2. Sending the message
3. Processing by foreign host
The first step usually means looking up, in either a local
the network database, the correct address(es) for
delivery, given the recipient's ID. Should the ID not be
at the time the message is submitted for delivery, any
necessary to determine that ID (such as a call to either
local or network database) is also performed as part of
step
The second step is not too different from what happens today
The local host establishes a connection to the foreign host.
is then able to send one or messages to one or more people.
options are
- Bulk mail. Several recipients all get the same message
RFC 757 September 1979
Names and Addresses Page 6
- Bundled mail. Several messages get sent to the
recipient
- A combination of the
- One recipient gets one message
The foreign host should be able to accept mail for each ID
The rejection of mail for a given ID by the foreign host
usually indicate an inconsistency between the sender's
database and the network database. In this case, the local
updates its local database from the network database,
attempts delivery at the "new" host. (This is mail forwarding.)
If a host taken from the network database is found to
incorrect, there is a problem in the network database,
appropriate authorities are notified. Thus, address
propagate out from the network database only as the out-of-
information is referenced. This reduces the magnitude of
local database update problem
Once the foreign host recognizes the ID(s), the message(s)
be transmitted to the foreign host. Upon
transmission, the job of the local host is done
The third step requires the foreign host to process
message(s). This is analogous to what may occur in a mail room
A foreign host may have to sort the bundled or bulk mail
receives. In addition, the foreign host might perform
or external fan-out functions or other special functions, at
option of the ID owner
The implemention and design of possible functions which may
performed in the mail rooms are neither mandated nor
by this delivery scheme. Since they are too numerous to
even a small portion of them to be described here, only a
examples will be mentioned
Fan-out functions might include placing messages in
files, sending copies to one or more other users,
rebroadcasting the messages onto the network. (In that
case, the foreign host might evaluate an ID list, in much
same way that the ITS mail repeater broadcasts messages
to certain mailboxes.) Special functions might include
hard-copy creation or reply generation, processing by
daemons, or any other service found desirable by the host's
population and administration. The implementation of fan-
functions is up to the local host, as are any
functions which the user population might wish of its local "
room". Whatever services are available, the mail room
distribute the mail to the correct location for each ID
RFC 757 September 1979
Names and Addresses Page 7
2.2.1 Additional delivery
It may be desirable to allow mail rooms to accept a username
place of an ID. Use of a username is a less reliable method
addressing than use of an ID
- A username may not be sufficiently unambiguous
getting an ID and host from the network database
- Since a recipient's username may change from time
time, there is a chance that the username supplied
4
the sender will be incorrect , or that the host may
recognize it
Because a recipient's ID does not change with time
errors such as those caused by username changes
occur if IDs are used. Similarities or ambiguities
be discovered before delivery occurs, and the sender
be prompted for additional identifying information
his intended recipient
- In an even worse case, a correct username can
result in an incorrect delivery when it is paired
an incorrect host or acted upon by a mail
5
database .
Because unique IDs are unambiguous, the possibility
such a situation is eliminated by the use of unique IDs
_______________
4
A particularly insidious source of addressing errors
from the inconsistent use of (human) names and initials
generate usernames. The sender can easily guess
recipient's username incorrectly by using, or failing to
a combination of initials and last name. (For example,
user wishing to address Jim Miller at BBNA and using
address "Miller@BBNA" will have his message
delivered to Duncan Miller at the same site.)
5
The author has observed a mail forwarding
redirect messages correctly addressed to one JWalker
different JWalker at another host
RFC 757 September 1979
Names and Addresses Page 8
2.2.2
The case in which the network database is found to be
has already been discussed. It may make sense to mark the
as "possibly in error" and to notify both the network
6
and the ID owner when such a situation occurs. In this case
delivery to the ID's owner will not occur, but this is not
bad, considering that that is what happens today when a host
not recognize a username
One additional failure mode, the loss of the network
from the net, must be considered, even though a well-
distributed network database should be robust enough to
rule out this possibility
If such a failure should occur, the local databases should
able to handle most of the traffic. What would be lost is
ability to add new IDs to the network database, the ability
change hosts for an ID, the ability to update local databases
and the ability to query the network database. In essence,
would be a regression to the state we are in today
A well-administered network database should be backed
frequently. Should a catastrophic series of hardware
remove one or more of the network database's hosts from the net
the database could be moved elsewhere. Such a change
entail notification of all hosts on which mail originates
Software which queries the database should be designed to be
to easily handle such a move
_______________
6
Such notification would presumably be by hardcopy mail
telephone
RFC 757 September 1979
Relationship to TIP Login database Page 9
3. Relationship to TIP Login
A number of references to the TIP Login problem and a
which has been proposed as part of its solution have been made
this note. A series of working papers [5] written by Bob Thomas
Paul Santos, and Jack Haverty describe an approach to TIP Login
In brief, the method is to build and maintain a distributed
Login database, containing information necessary to allow a
entity called a "login-host" to decide whether or not to grant
user access to a given TIP, and whether or not to allow the
to make various modifications to the database itself
The TIP login database is derived from a "network user
base", which contains information above and beyond that
to support TIP login. This comprehensive database is designed
support applications other than TIP Login, either directly or
means of databases derived from it
Contained in the TIP Login database are each user's
string, a list of TIPs the user is authorized to access,
user's unique ID, his password, and any other "permissions" (
addition to which TIPs may be accessed). These permissions
indicate that the user may create, delete, or modify entries
the database, to assume other user's roles, and to what extent
may do so. The notion of permissions as developed by
Warshall is discussed in an NSW memo [2].
It seems entirely reasonable to derive a netmail database
the same comprehensive database that is designed to support
Login. The concept of a unique ID is supported by that database
Much of the required information for a netmail database
already included, and the maintenance tools necessary to
it seem well-suited for the purpose. The concept of
extends well to the needs of netmail. Permissions specific
network mail might include, for example, the ability to
the delivery host list associated with a given user
The mechanisms necessary for the maintenance of
comprehensive network database and its derived databases give
a netmail database very inexpensively. This proposal
advantage of that situation
RFC 757 September 1979
Relationship to RFC 753 Page 10
4. Relationship to RFC 753
RFC 753 [4] describes an internetwork message delivery system
Very briefly, the approach is to locate one or more "
processing modules" (or MPMs) on each network. These MPMs
messages across network boundaries, and are also capable
making deliveries to users on the local network. The
also details a proposed message format, along the envelope
letter paradigm. An external "envelope", read by the
system, allows the (unread) message to be correctly routed
delivered to the proper recipient. Groups of messages
between a pair of MPMs are sent together in a "mail bag".
This proposal differs from RFC 753 in that it is
intended to operate within a network or a concatenation
networks using a common host-host protocol, e.g. TCP. Where
753 addresses the problems of internetwork
(differing message formats, complex routing, and
identification of the proper recipient), this note
primarily on what can be done within a single protocol. The
are not incompatible. While a general internetwork protocol
provide general methods which can be compatible with
host-host protocols in different networks, a proposal such
this one can capitalize on the capabilities, resources,
policies of a given catenet (catenated network) such as
ARPAnet/PRnet/SATNET etc
4.1
The delivery system described in RFC 753 is compatible with
system outlined here. Let's examine this for each of the
basic delivery options performed by the MPM. (In the
that follows, "local networks" means a concatenation of
using a common host-host protocol, e.g. TCP. "Foreign network
means some network which uses a different host-host protocol
e.g. X.25. (See Figure 4-1.)
4.1.1 Outgoing
4.1.1.1 RFC 753
The sender's process hands a message to the local network MPM
The message may be destined to an address on the local network
on a foreign network. In the former case, the MPM performs
local delivery function (see "Incoming message"). In the
case, the MPM passes the message along to another MPM which
"closer" to the end user
RFC 757 September 1979
Relationship to RFC 753 Page 11
+---------+ +----------+
| | | |
| RCC-NET | | WIDEBAND | .......
| | | NET | . .
+---------+ | | . MPM .
* * +----------+ .......
+---------+ * * * * ....... |
| | +---------+ . . +---------+
| BBN-NET |***| |__. MPM . ..... | |
| | | ARPANET | ....... . .xxxx| TELENET |
+---------+***| |***********. G . | |
+---------+*** ..... +---------+
* * * * ** .......
+--------+ +-------+ ***..... +-------------+ . .
| | | | . . | |--. MPM .
| SATNET | | PRNET | . G .oooo| DIAL-UP NET | .......
| | | | ..... | |
+--------+ +-------+ +-------------+
"Local Nets", TCP based | "Foreign Nets",
(direct addressing using IP) | host-host
*** = TCP xxx = X.25 ooo = other communications
G =
Figure 4-1: The Internet
4.1.1.2 This
The sender's process determines the proper host for
given the recipient's unique ID. If the message is destined
the local network, delivery takes place as described earlier
this proposal. If the recipient is not local, the message may
passed to an MPM for foreign delivery. (A discussion of
delivery which does not presuppose RFC 753 implementation
found later in this note.)
The environment in which the MPM operates does not assume
knowledge on the part of the local networks about addressees
foreign networks. Thus there are two possibilities which arise
RFC 757 September 1979
Relationship to RFC 753 Page 12
- The recipient has an ID known to the local networks
In this case, the local networks supply the RFC 753
"address". This can take place in the local networks
MPM or the user's sending or mail creation process
- The recipient is unknown to the local networks
Here the sender must supply "mailbox"
himself, either explicitly or with help of his
host's database
Thus, outgoing mail as described in this memo is
with RFC 753, with the benefit of reducing the burden on the
by handling mail deliveries that are local to local networks
4.1.2 Messages in
Traffic between two MPMs is not affected by this proposal
4.1.3 Incoming
The MPM on the networks local to the recipient will have
to the netmail database, allowing it to translate "mailboxes"
"addresses". It can determine the unique ID of the recipient (
not known), and initiate delivery to that recipient. Here
753 and this proposal complement each other very well
RFC 757 September 1979
Implications of an internetwork message environment Page 13
5. Implications of an internetwork message
The scheme described above is based upon the assumption that
unique identifier can be assigned to each registered recipient
mail. Whether or not this uniqueness can be guaranteed in
fairly unregulated internetwork environment is questionable.
is technically feasible, certainly. The difficulties are
political, because it is necessary to gain the cooperation of
administrators and user populations of foreign networks. Let'
assume cooperation, however, and see what might happen in
internet environment
5.1
Each set of local networks would have its own database,
ease in access. It does not seem practical to register each
in every database, however. That would be unnecessary, and
create access and storage problems at the network databases
Here the concept of a "birthplace", or ID origin, may be of use
While an ID does not imply where the user is now, it can
something about who issued it. A simple system for
the address for any ID can be maintained by having the
network keep a pointer for each ID it issues. One
indirection would yield the desired address, even if the ID
not issued on the local nets. A message originating on the
nets with an ID which is unknown to its database can be
by determining the birthplace of the ID. An inquiry to
birthplace database would return a list of one or more
on which the ID is registered. An inquiry to any of those
get the requisite information. All that is necessary to
this is for the birthplace record (small enough!) to be kept
and for the act of registration at a given net to
cause that net to notify the birthplace of the registration
(Conversely, a de-registration would cause a similar
of the birthplace.)
5.1.1 ID
The handling of ID resolution when the ID is not known to
local net does not seem to have a solution simpler than
foreign nets until some success is achieved
5.1.2 Hosts in an internet
The substitution of internet host names for simple host
should not cause any difficulty
RFC 757 September 1979
Implications of an internetwork message environment Page 14
5.1.3
Should a birthplace cease to exist (usually because its
is dismantled), it would be necessary for a second birthplace
"adopt" the first birthplace's records. Notification of
change could be propagated throughout the internet environment
much the same way as the addition of a new birthplace would
treated
RFC 757 September 1979
Conclusions Page 15
6.
While ARPAnet message systems have been amazingly successful
there is much room for improvement in the quality and quantity
the services offered. Current protocols are limiting
development of new message systems. This paper has discussed
means of providing the underlying support necessary for
a new generation of message systems which can be
human-engineered in addition to providing more services
greater reliability
Critics may argue that the proposal is too radical, too much
a departure from current practice. After all, today's
service is extremely straightforward in design, and therefore
comparatively few failure modes. The protocols in use
descended, with relatively few changes, from the first
transfer and message format protocols implemented on the ARPAnet
This makes them well understood; people are aware of both
shortcomings and usage. Finally, there are people who will
feel comfortable about requiring a network database,
the reliability and questioning the possible cost of such
scheme
On the other hand, it is undeniably true that very little
can be done to improve message services while staying
today's practices. New message systems which will be able
transmit facsimile, voice, and other media along with
require us to rethink message formats and do away with
protocols which are predicated upon the characteristics of
text. The inception of internetwork message delivery causes
to re-evaluate how we handle messages locally. Finally,
USERNAME@HOST naming scheme has proved to be inadequate,
the divorce of recipients' identities from their locations
a promising possibility as a replacement
The ARPAnet will soon have a distributed database
supporting TIP Login. Only small, incremental costs would
associated with building and maintaining a netmail database
the same time. It can be argued that TIP Login requires at
the level of reliability required by a message delivery system
If the TIP Login database is successful, a netmail database
work, too
It is clear that we will be implementing a new set of
format and delivery protocols in the near future, in order
allow for multi-media messages, internetwork message traffic,
the like. New message composition and delivery systems will
built to meet those specifications and take advantage of
avenues of development which they will open. If there will
be an advantageous time to re-evaluate and re-design how
are addressed and delivered, it is now, when we are about
enter upon an entirely new cycle of message composition
RFC 757 September 1979
Conclusions Page 16
delivery program implementation
RFC 757 September 1979
References Page 17
[1] John F. Shoch
Inter-Network Naming, Addressing, and Routing
In Proceedings, COMPCON. IEEE Computer Society, Fall, 1979.
[2] Stephen Warshall
On Names and Permissions
Mass. Computer Associates. 1979.
[3] David H. Crocker, John J. Vittal, Kenneth T. Pogran
D. Austin Henderson, Jr
STANDARD FOR THE FORMAT OF ARPA NETWORK TEXT MESSAGES
RFC 733, The Rand Corporation, Bolt Beranek and Newman Inc
Massachussets Institute of Technology, Bolt Beranek
Newman Inc., November, 1977.
[4] Jonathan B. Postel
INTERNET MESSAGE PROTOCOL
RFC 753, Information Sciences Institute, March, 1979.
[5] Robert H. Thomas, Paul J. Santos, and John F. Haverty
TIP Login Notes
Bolt Beranek and Newman. 1979.
RFC 757 September 1979
Table of Contents Page
Table of
1. Introduction 2
2. Names and Addresses 3
2.1 A distributed database approach 4
2.2 Delivery 5
2.2.1 Additional delivery options 7
2.2.2 Failures 8
3. Relationship to TIP Login database 9
4. Relationship to RFC 753 10
4.1 Compatibility 10
4.1.1 Outgoing message 10
4.1.1.1 RFC 753 10
4.1.1.2 This proposal 11
4.1.2 Messages in transit 12
4.1.3 Incoming mail 12
5. Implications of an internetwork message environment 13
5.1 Birthplaces 13
5.1.1 ID resolution 13
5.1.2 Hosts in an internet environment 13
5.1.3 Orphans 14
6. Conclusions 15
RFC 757 September 1979
List of Figures Page
List of
Figure 4-1: The Internet Environment 10
RFC 757 September 1979
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
