rfc757.txt

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

something  about  who issued it.  A simple system for determining
the address for any ID can be maintained by  having  the  issuing
network  keep  a  pointer  for  each  ID  it  issues.  One double
indirection would yield the desired address, even if the ID  were
not issued on the local nets.  A message originating on the local
nets  with  an ID which is unknown to its database can be handled
by determining the birthplace of the  ID.    An  inquiry  to  the
birthplace  database  would return a list of one or more networks
on which the ID is registered.  An inquiry to any of those  would
get  the requisite information.  All that is necessary to support
this is for the birthplace record (small enough!)   to  be  kept,
and  for  the act of registration at a given net to automatically
cause that net to notify  the  birthplace  of  the  registration.
(Conversely, a de-registration would cause a similar notification
of the birthplace.)


5.1.1 ID resolution

  The  handling  of ID resolution when the ID is not known to the
local net does not seem to have a solution simpler than  querying
foreign nets until some success is achieved.


5.1.2 Hosts in an internet environment

  The  substitution  of internet host names for simple host names
should not cause any difficulty.




RFC 757                                            September 1979
Implications of an internetwork message environment       Page 14


5.1.3 Orphans

  Should a birthplace cease to exist (usually because its network
is  dismantled), it would be necessary for a second birthplace to
"adopt" the first birthplace's records.    Notification  of  this
change could be propagated throughout the internet environment in
much  the  same  way as the addition of a new birthplace would be
treated.














































RFC 757                                            September 1979
Conclusions                                               Page 15


6. Conclusions

  While  ARPAnet  message systems have been amazingly successful,
there is much room for improvement in the quality and quantity of
the  services  offered.    Current  protocols  are  limiting  the
development  of  new message systems.  This paper has discussed a
means of providing the underlying support necessary for  building
a   new  generation  of  message  systems  which  can  be  better
human-engineered in  addition  to  providing  more  services  and
greater reliability.

  Critics may argue that the proposal is too radical, too much of
a  departure  from  current practice.  After all, today's message
service is extremely straightforward in design, and therefore has
comparatively few failure modes.    The  protocols  in  use  have
descended,  with  relatively  few  changes,  from  the first file
transfer and message format protocols implemented on the ARPAnet.
This makes them well understood; people are aware of  both  their
shortcomings  and  usage.  Finally, there are people who will not
feel comfortable about requiring a network database,  distrusting
the  reliability  and  questioning  the  possible  cost of such a
scheme.

  On the other hand, it is undeniably true that very little  more
can  be  done  to  improve  message services while staying within
today's practices.  New message systems which  will  be  able  to
transmit  facsimile,  voice,  and  other  media  along  with text
require us to rethink message formats and do away  with  delivery
protocols  which are predicated upon the characteristics of ASCII
text.  The inception of internetwork message delivery  causes  us
to  re-evaluate  how  we  handle  messages locally.  Finally, the
USERNAME@HOST naming scheme has proved to  be  inadequate,  while
the  divorce of recipients' identities from their locations seems
a promising possibility as a replacement.

  The  ARPAnet  will  soon  have  a  distributed   database   for
supporting  TIP  Login.    Only small, incremental costs would be
associated with building and maintaining a  netmail  database  at
the same time.  It can be argued that TIP Login requires at least
the  level  of reliability required by a message delivery system.
If the TIP Login database is successful, a netmail  database  can
work, too.

  It  is  clear that we will be implementing a new set of message
format and delivery protocols in the near  future,  in  order  to
allow for multi-media messages, internetwork message traffic, and
the  like.   New message composition and delivery systems will be
built to meet those specifications  and  take  advantage  of  the
avenues  of development which they will open.  If there will ever
be an advantageous time to re-evaluate and re-design how messages
are addressed and delivered, it is now,  when  we  are  about  to
enter  upon  an  entirely  new  cycle  of message composition and


RFC 757                                            September 1979
Conclusions                                               Page 16


delivery program implementation.





















































RFC 757                                            September 1979
References                                                Page 17


                           REFERENCES

[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 and
      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 i


                        Table of Contents

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 ii


                      List of Figures

Figure 4-1:  The Internet Environment                          10



















































RFC 757                                            September 1979