Suggested solution to the naming, addressing, and delivery problem for ARPANET message systems
RFC 757

Document Type RFC - Unknown (September 1979; 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 757 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
RFC 757

  A Suggested Solution to the Naming, Addressing, and Delivery
               Problem for ARPAnet Message Systems

                        Debra P. Deutsch

                        10 September 1979

                     Bolt Beranek and Newman

                        50 Moulton Street

                 Cambridge, Massachusetts 02138

                         (617) 491-1850

Preface                                                    Page 1


  Unlike   many   RFCs,   this   is  not  a  specification  of  a
soon-to-be-implemented protocol.  Instead this is a true  request
for  comments  on  the concepts and suggestions found within this
document, written  with  the  hope  that  its  content,  and  any
discussion  which it spurs, will contribute towards the design of
the  next  generation  of  computer-based  message  creation  and
delivery systems.

  A  number  of  people  have  made contributions to the form and
content of this document.  In particular, I would like  to  thank
Jerry   Burchfiel  for  his  general  and  technical  advice  and
encouragement, Bob Thomas for his  wisdom  about  the  TIP  Login
database  and  design of a netmail database, Ted Myer for playing
devil's  advocate,  and  Charlotte  Mooers  for   her   excellent
editorial assistance.

                                                   Debbie Deutsch

RFC 757                                            September 1979

Introduction                                               Page 2

1. Introduction

  The  current  ARPAnet  message handling scheme has evolved from
rather informal, decentralized beginnings.  Early developers took
advantage of pre-existing tools --  TECO,  FTP  --  in  order  to
implement  their  first systems.  Later, protocols were developed
to  codify  the  conventions  already  in  use.     While   these
conventions  have  been  able  to  support an amazing variety and
amount of service, they have a number of shortcomings.

  One difficulty is the naming/addressing  problem,  which  deals
with  the  need  both  to  identify the recipient and to indicate
correctly a delivery point for the message.  The current paradigm
is deficient in that it lacks a  sharp  distinction  between  the
recipient's  name  and  the  recipient's  address,  which  is the
delivery point on the net.

  The naming/addressing scheme does not allow  users  to  address
their  messages  using  human  names,  but instead forces them to
employ designations better  designed  for  machine  parsing  than
human identification.

  Another  source  of  limitations  lies  in the delivery system,
which is simply an extension of the File Transfer Protocol.   The
delivery system is fairly limited in its operation, handling only
simple transactions involving the transfer of a single message to
a  single  user  on  the destination host.  The ability to bundle
messages and the ability to fan-out messages at the foreign  host
would improve the efficiency and usefulness of the system.

  An  additional  drawback  to  the delivery system is caused, to
some extent, by the addressing scheme.  A change in  address,  or
incorrect  address  usually  causes the delivery system to handle
the message incorrectly.  While some hosts support  some  variety
of  a  mail  forwarding database (MFDB), this solution is at best
inadequate and spotty  for  providing  reliable  service  to  the
network  as  a  whole.    Because the same username may belong to
different people at different hosts, ambiguities which  may  crop
up  when  messages  are  incorrectly addressed keep even the best
MFDBs from always being able to do their job.

  This proposal envisions a system  in  which  the  identity  and
address  of  the  recipient are treated as two separate items.  A
network database supports  a  directory  service  which  supplies
correct  address  information  for all recipients.  Additionally,
the scheme allows mail delivery to be  restricted  to  authorized
users of the network, should that be a desirable feature.

RFC 757                                            September 1979

Names and Addresses                                        Page 3

2. Names and Addresses

  Today's  ARPAnet  naming and addressing scheme (as specified in
RFC 733[3]) does not discriminate between the identity of a  user
and   his   address .      Both   are  expressed  the  same  way:
USERNAME@HOST.  While this  should  always  result  in  a  unique
handle for that user, it has proved to be inadequate in practice.
Users  who  change  the  location  of their mailboxes, because of
either a change in affiliation or a simple shift in  host  usage,
also  get their names changed.  If their old host employs an MFDB
the problem is not too bad.  Mail is simply forwarded on  to  the
new  address,  slightly  delayed.  Other less fortunate users who
cannot rely upon an MFDB must notify all their correspondents  of
Show full document text