rfc757.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,156 行 · 第 1/3 页

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

                         [phone]
Preface                                                    Page 1


                             Preface

  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
                   1
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
the  change  in  address/name.    Any  mail  addressed to the old
address becomes undeliverable.  (An excellent discussion  of  the
differences between naming, addressing, and routing is found in a
paper by John Shoch [1].)

  The  desire  to  use  "real"  names  in  the  address fields of
messages is also thwarted by the current system.    An  elaborate
system  for  using  human-compatible  vs.   machine-interpretable
                                                        2
information has been evolved for use in message  headers .    The
most  recent  developments  indicate  that  many users would feel
happiest   if    the    real    human    name    could    appear;
machine-interpretable  information should not intrude too heavily
into the writer's work- and thought-space.

  The solution proposed here calls for a total break between  the
way  a  recipient is named or identified and the way in which his
location  is  specified.    Since  the  ARPAnet  is  a  regulated
environment,  a  unique  (and  not necessarily human-readable) ID
could be assigned to each authorized recipient of  network  mail.
This  ID  would stay with the user throughout his lifetime on the
network, through changes in address and affiliation.

  A network database  (which  could  be  derived  from  the  same
database  that  has  been  proposed  to  support TIP login) would
associate each ID with one or more addresses indicating where the
mail for that ID may be delivered.  If more than one address were

_______________
  1
   See, for example, RFC 733's discussion  of  the  semantics  of
address  fields,  in  which  it  is  specified that the To: field
"contains the identity of the primary recipients of the message".
  2
   See the "Syntax of General Addressee  Items"  section  of  RFC
733.




RFC 757                                            September 1979
Names and Addresses                                        Page 4


associated  with an ID, that would indicate an ordered preference
in delivery points.  The delivery system would  attempt  delivery
to  the first addressee, and, if that failed, try the second, and
     3
so on .  Most IDs would probably have only  one  address.    Also
associated  with each ID would be some information about the ID's
owner:  name, postal address, affiliation, phone number, etc.

  Rather than being forced to type some awkward character  string
in  order  to  name  his  correspondent, the writer would have to
supply only enough information to allow some process to determine
the unique identity of the recipient.  This information might  be
the recipient's name or anything else found in the database.

  The  access  to  this  data would also free the writer from any
need to know the location of the recipient.  Once the  unique  ID
were  known,  the  correct  location for delivery would be only a
look-up away.


2.1 A distributed database approach

  It  is  clear  that  if  the  network  database  had  only  one
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 and
speed.  It is also clear that requiring each host to  maintain  a
complete  local  copy  of  the  entire  network  database  is  an
undesirable and unnecessary burden on the hosts.

  A better approach would be to build  some  sophistication  into
the local delivery system, and use local mini-databases which are
based  upon  the contents of a distributed network database.  (It
may be redundant and/or partitioned, etc., but  is  probably  not
resident  on  the  local  host.)    When a local host queries the
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 on
that ID.  At this point the local host can enter all or  some  of
that  information  into a locally maintained database of its own.
It will always refer to that database first when  looking  for  a
name  or  address, only calling the network database if it cannot
find  a  local  entry.  Depending  upon  the  desired  level   of
sophistication of the local message handling programs, additional
information  may  be  added  to  that  database,  including,  for

_______________
  3
   Multiple  addresses  might  also  be  used  to  indicate  that
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 as
exist at BBN or ISI), or it might be used by  only  one.    Hosts
which  originate small amounts of message traffic might rely upon
the network database entirely.

  The structure and maintenance of the local  databases  is  left
solely  to the local hosts.  They may or may not store addresses.
It may be desirable either to garbage collect  them,  or  to  let
them  grow.  The local databases might be linked to smaller, more
specialized databases which are  owned  by  individual  users  or
groups.    These  individual databases would be the equivalent of
address books in which users  might  note  special  things  about
individuals:    interests,  last  time seen, names of associates,
etc.  The existence and scope of these databases are not mandated
by this scheme, but it does allow for them.

  The same individual databases may be used by  message  creation
programs   in   order   to  determine  the  recipient's  ID  from
user-supplied input.  For example, a user may address  a  message
to  someone  named  Nick.    The  message  creation  program  may
associate "Nick" with an ID, and hand that ID off to the delivery
system, totally removing the matter of address or formal ID  from
the user's world.


2.2 Delivery

  The delivery operation consists of three parts:

  1.  Determining  the  address  to which the message must be
      sent,

  2.  Sending the message,

  3.  Processing by foreign host.

  The first step usually means looking up, in either a  local  or
the   network  database,  the  correct  address(es)  for  message
delivery, given the recipient's ID.  Should the ID not  be  known
at  the time the message is submitted for delivery, any operation
necessary to determine that ID (such as  a  call  to  either  the
local  or  network  database)  is  also performed as part of this
step.

  The second step is not too different from what  happens  today.
The  local host establishes a connection to the foreign host.  It
is then able to send one or messages to one or more people.   The
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 same
     recipient.

   - A combination of the above

   - 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  would
usually  indicate  an  inconsistency  between  the sender's local
database and the network database.  In this case, the local  host
updates  its  local  database  from  the  network  database,  and
attempts delivery at the "new" host.  (This is mail  forwarding.)
If  a  host  taken  from  the  network  database  is  found to be
incorrect, there is  a  problem  in  the  network  database,  and
appropriate  authorities  are  notified.    Thus, address changes
propagate out from the network database only as  the  out-of-date
information  is  referenced.    This reduces the magnitude of the
local database update problem.

  Once the foreign host recognizes the ID(s), the message(s)  may
be   transmitted   to   the   foreign   host.    Upon  successful
transmission, the job of the local host is done.

  The third  step  requires  the  foreign  host  to  process  the
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  it
receives.    In addition, the foreign host might perform internal
or external fan-out functions or other special functions, at  the
option of the ID owner.

  The  implemention and design of possible functions which may be
performed in the mail rooms are neither mandated  nor  restricted
by  this  delivery  scheme.  Since they are too numerous to allow
even a small portion of them to be described  here,  only  a  few
examples will be mentioned.

  Fan-out  functions  might  include placing messages in multiple
files,  sending  copies  to  one  or   more   other   users,   or
rebroadcasting  the  messages  onto  the  network.  (In that last
case, the foreign host might evaluate an ID  list,  in  much  the