rfc773.txt

RFC 相关的技术文档

                                                                        
Network Working Group                                            V. Cerf
Request for Comments: 773                                          DARPA
                                                            October 1980

          COMMENTS ON NCP/TCP MAIL SERVICE TRANSITION STRATEGY


INTRODUCTION

   This memo reviews and expands on the mail service transition plan
   [20].

   The principal aim of the plan is to provide for the orderly support
   of the most commonly used network service (mail) during the period of
   transition from ARPANET to Internet Protocol-based operation.

   The goal of the transition is, at the end, to provide in the internet
   environment service which is equivalent to or better than what has
   been available in the ARPANET environment.  During the interim
   period, when both internet and the older ARPANET-based protocols are
   in use, the goal of the transition is to minimize user impact and, to
   the extent possible, to minimize software development or modification
   required to deal with transitional problems.

   It is assumed that the reader is familiar with both the ARPANET and
   internet protocol hierarchies [1-17].  The internet hierarchy is
   designed to interface to many different packet networks (e.g., packet
   satellite, packet radio, Ethernet, LCS Ring net, X.25 public
   nets, ...), while the ARPANET hierarchy is limited to ARPANET IMPs
   (This is less true of the levels above NCP, but NCP itself is closely
   bound to ARPANET services).

   The objective of the transition plan is to specify means by which the
   ARPANET electronic mail services may be supported across the boundary
   between the purely ARPANET environment and the more general internet
   environment during the period of transition by ARPANET hosts to the
   richer internet world.

ELECTRONIC MESSAGE SERVICES

   DARPA is beginning a new phase of research into automatic electronic
   message handling systems.  Ultimately, it is intended that electronic
   messages incorporate multiple media such as text, facsimile,
   compressed digitized voice, graphics and so on.  Success in this new
   research will require substantial progress in developing multimode
   user interfaces to computer-based services (voice input/output,
   graphics, tablet/light pen, facsimile input/output, video/bit mapped
   displays, ...).

   At the same time, progress must be made towards an environment based
   on internet protocols so as to avoid confining the results of the



                                   1


                                                                        
October 1980                                                     RFC 773
Comments on NCP/TCP Mail Service Transition Strategy                    



   multimedia effort to any one network.  As a result, DARPA is planning
   to make several transitions over the next few years, from the
   existing, text-based ARPANET electronic message system to an
   internet-based, multimedia electronic message system.

   This paper addresses only the first of the transitions from NCP-based
   text mail to TCP-based multimedia mail.  The transition to the new
   multimedia mail system [7,19] lies ahead, but need not be planned in
   detail until we have some experience with the basic concepts.  This
   first step only provides for the transition to TCP-based text mail.

   The basic ground rules for transition from ARPANET-based electronic
   mail to internet electronic mail are the following:

      1.  ARPANET mailbox names must continue to work correctly.

      2.  No change required to mail editors which parse message headers
          to compose replies and the like.

      3.  Accommodation of non-ARPANET mailbox designators without
          change to the header parsing and checking mechanisms of mail
          composition programs.

      4.  Automatic forwarding of messages between NCP and TCP
          environments without user intervention.

      5.  During the transition, old style mail mechanisms must still
          work.

ELECTRONIC MESSAGE MECHANISMS

   In order to make progress at all, it has been necessary to postulate
   fairly sophisticated changes to the "mailer" function which accepts
   as input an electronic text message and causes it to be delivered to
   the destination (or to an intermediate forwarder).

   We also posit the existence of special, well-known mail forwarding
   hosts on the ARPANET which are responsible for accepting messages
   from NCP (TCP)-based message senders and forwarding them to
   TCP (NCP)-based message receivers.

   In the ARPANET, electronic messages are transported via special
   procedures of the File Transfer Protocol:  MAIL and MLFL.  The former
   method sends electronic messages via the FTP Telnet command channel





                                   2


                                                                        
RFC 773                                                     October 1980
                    Comments on NCP/TCP Mail Service Transition Strategy



   while the latter achieves this by actual file transfer.  In both
   cases, it is generally assumed that the receiving FTP server is
   colocated with the destination mailbox.

   Thus, the sending procedure identifies to the receiver the
   destination mailbox identifier, but not the destination host (or
   network) identifier.  For example, messages sent from Postel at
   USC-ISIF to Adams at USC-ISIA would arrive at ISIA with an indicator
   "Adams" but no indication of "ISIA".  This creates some problems when
   messages must be staged at an intermediate host for further
   processing, as is the case when moving from an NCP-based sender to a
   TCP-based receiver, or vice-versa.  Similar considerations arise when
   dealing with compatible, but different, message systems requiring
   re-formatting of messages at intermediate points.

   In the following paragraphs, a mechanism is proposed for dealing with
   the naming, addressing and routing [18] of messages between systems.

   At the source, it is assumed that the user has prepared the text of
   the message (including "To:" and "CC:" fields) in the conventional
   way [12].  The mailbox identifiers will continue to exhibit the
   format:

      User@Host

   but "host" may in fact be a compound name (which is not necessarily
   parsed), such as:

      USC-ISIA
      ARPANET-ISIA
      SATNET-NDRE
      PPSN-RSRE
      HOST1.SRINET
      LCSNET/MAILROOM

   or even the name of an organization, such as:

      BBN
      ARPA
      MIT
      SRI

   The only restriction is that the "@" not appear in either "user" or
   "host" strings in the mailbox identifier.

   During message composition, the "user" or "host" portions of the



                                   3


                                                                        
October 1980                                                     RFC 773
Comments on NCP/TCP Mail Service Transition Strategy                    



   mailbox identifier may be verified for correctness (or at least for
   validity).  The "user" string may incorporate parenthetical
   information such as

      RAK(Richard A. Karp)@SU-AI

   as is currently allowed.

   After composition, messages are either sent immediately or left as
   "unsent mail" files to be sent later by mailer demons.  The actual
   sending process uses the "host" string to determine where and how to
   send the message.

NEW MAIL MECHANISMS

   At this point, we encounter the first critical new requirement to
   support the transition plan.  A new table is needed within the mailer
   or in the host supporting the mailer or accessible to the mailer via
   the internet name server (for instance).  This table must provide for
   mapping of the "host" string into an internet destination address
   (i.e., 32 bits: 8 bits of net, 24 bits of host), and must also
   indicate whether the destination is NCP or TCP capable.

   In the event that the source and destination hosts do not have a
   compatible host level protocol (e.g. source is NCP only, destination
   is TCP only) then the message must be passed to a "forwarder" which
   can stage the transport by accepting via one protocol and forwarding
   by another.

   This leads to a problem for the forwarding host since the basic FTP
   mail mechanism sends only the "user" portion of the mailbox
   identifier ("user@host") because the assumption is that the "host" is
   the destination.  In the case of forwarding, the "host" is not the
   forwarder.  Even if we cleverly arrange for "host" to translate into
   the internet address of a forwarder, we will have two problems.
   First, the forwarder may need the "host" information to figure where
   now to forward the message and second, depending on which network the
   source is in, "host" may need to translate into different forwarder
   addresses.  The latter observation raises the spectre of many
   different mappings of a given "host" string which would require
   different tables for different mail sources.  This would lead to
   considerable complexity in the maintenance and distribution of tables
   of forwarder addresses.  Furthermore, a single-entry table mapping
   "host" to forwarder would limit reliability since only one forwarder
   would be bound to serve a giver "host".




                                   4


                                                                        
RFC 773                                                     October 1980
                    Comments on NCP/TCP Mail Service Transition Strategy



   For the NCP/TCP transition, it may be sufficient to declare some set
   of well-known hosts to be NCP/TCP forwarders.  Each mailer, when it
   discovers an incompatible destination, can send the message to any
   forwarder which is available.  In addition, however, the mailer must
   provide full mailbox identifier information "user@host" to the
   forwarding host.

   In the present mailers, only the "user" portion of the mailbox
   identifier is sent, so all mailers must change to send "user@host"
   when sending to a forwarder.  The mailers all have to learn how to do
   table look-up a new way, also, to map "host" into internet addresses
   and to interpret the NCP or TCP capability information.

   For purposes of this discussion, we postulate three different cases
   of electronic mail service implementation which must be made to
   interoperate during the transition:

      1.  Unchanged OLD NCP (RFC733) mail

      2.  NCP mail with new internet tables

      3.  TCP mail with new internet tables.

   The second case assumes that the host has adopted a new host-string
   to address table (including NCP/TCP capability bits) and new mailer -
   mail server programs, but continues to use the old NCP host level
   protocol, modified to send "user@host" when sending to a forwarder.
   For such hosts, the only table entries which result in direct
   source-destination mail delivery are those showing NCP capability.
   If the destination is TCP capable only then the source host selects a
   forwarder address from another table and sends the message to it for
   further processing.

   In the third case, the source host has fully transitioned to TCP,
   uses the new internet address tables to translate host-strings into
   internet addresses, and uses the new mailer - mail server.
   Destinations which are NCP-compatible only are reached via NCP/TCP
   forwarders.

   Mail composition programs (e.g. SNDMSG, MSG, Hermes, MH,...) which
   today use ARPANET string-to-address tables to verify the legality of
   host names in mailbox entries can continue to use these "old" tables
   as long as these are updated to include internet host names as well
   as ARPANET host names.

   Indeed, expanding the old tables is essential to handle the hardest



                                   5


                                                                        
October 1980                                                     RFC 773
Comments on NCP/TCP Mail Service Transition Strategy                    



   transition case:  OLD NCP to new TCP mail.  The three types of hosts
   lead to a 3 by 3 matrix of cases of mail transfer.  In all but one
   case, mail is either handled directly or explicitly by forwarder.
   The only case needing further explanation is OLD NCP to NEW TCP which
   uses an "implicit forwarder."

IMPLICIT FORWARDING VS EXPLICIT FORWARDING

   If the source host has adopted the new internet tables, it can tell
   whether the destination host has a compatible mail acceptance
   protocol.  Incompatibility is explicitly resolved by selection of an
   intermediate forwarder.

   If, however, the source host is still using pure NCP tables, it will
   not be able to tell that a particular destination host is only
   TCP-capable.  To provide service for this case, it is proposed to
   expand the conventional NCP host table to include internet host
   names, but to map them into the addresses of implicit mail forwarders
   (i.e. Aliases).

   Since we are postulating a case in which the NCP host has made no
   change (except for extending the host table). we also assume that the