rfc773.txt

RFC 相关的技术文档

   source host cannot send the "user@host" information via FTP to the
   intermediate forwarder.

   This leaves the intermediate forwarder with the problem of figuring
   out where to forward a message identified by "user" only.  In this
   case, we postulate that internet TCP-only mailboxes are registered at
   implicit forwarders so that incoming mail from conventional NCP
   sources can be forwarded successfully to the destination.

   In the reverse direction, the source can use explicit forwarding
   because it is assumed that all TCP hosts use the new internet tables.

   The use of registered names in the implicit forwarder raises two
   problems:

      1.  How can we deal with ambiguous mailbox names?  (e.g. USERX@BBN
          and USERX@ISI look the same if only the string "USERX" is
          presented to the intermediate forwarder)

      2.  How can we collect, update and distribute changes to the
          registries at implicit forwarders?

   In the first case, we propose to duck the problem by insisting on




                                   6


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



   unambiguous mailbox names everywhere.  This may force some internet
   mail users to change their mailbox names, but we believe this will be
   rare.

   The second problem can be solved by collecting information on a
   regular basis from all network mail users and cataloging this data in
   a database which can be accessed automatically (e.g. by mailer
   programs).

   One possible mechanism is to make the data available through an
   internet mailbox name server analogous to the internet host name
   server [6].  This data might be collectible as a natural part of the
   TIP LOGIN database which is under development to permit expanded
   access to the ARPANET TIPs by legitimate ARPANET users.

   In any case, internet mail users need supply their mailbox
   information to a single collection site which would disseminate it to
   all implicit forwarders on ARPANET.  Note that such forwarders are
   only needed on ARPANET since all other systems are starting with the
   TCP-base.  It is the internet mailbox users who must register,
   however, since they are the ones who cannot otherwise be reached via
   NCP.

FORWARDER CHARACTERISTICS

   By their definition, NCP/TCP forwarders must be both NCP and TCP
   capable. Consequently, all NCP/TCP forwarders must be ARPANET hosts.

   Implicit forwarders must accept conventional NCP/FTP mail [11] and be
   equipped with tables of valid internet user mailbox names which can
   be associated with the proper destination host.  To allow implicit
   forwarders to also accept ordinary mail for users with mailboxes on
   the implicit forwarder, the forwarder should check first whether
   incoming mail is for a local user.

   Explicit mail forwarders must be able to accept both conventional
   NCP-FTP mail commands (for local user mail) and both NCP-based and
   TCP-based mail server commands (whose arguments include the full
   destination mailbox strings "user@host").

   To prevent potentially anomalous behavior, the NCP-based and
   TCP-based mail servers will offer service on socket/port 57 (71
   octal).  To summarize the communication patterns:

      (a)  TCP sends/receives mail via well known port 57.




                                   7


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



      (b)  implicit forwarder receives conventional NCP/FTP mail on
           well-known socket 3, and sends TCP mail to port 57.

      c)  explicit forwarder receives NCP mail on well-known socket 57,
           but sends NCP mail via NCP/FTP on socket 3.  TCP mail is
           sent/received via port 57.

USER HOST CHARACTERISTICS

   NCP hosts must at minimum, update host name tables to include aliases
   for internet hosts (i.e. map to NCP implicit forwarder host
   addresses).

   The next most useful step is to update NCP hosts to include internet
   address tables and NCP/TCP capability bits so as to make use of
   explicit forwarders.  This requires implementation of the mail server
   and modification of the mailer programs for sending mail to explicit
   forwarders.  This also requires addition of explicit forwarder
   address tables.

   Finally, a host can implement full TCP mail services, incorporating
   internet name tables and explicit forwarder address tables as well.

DANGLING PARTICIPLES

   1.  Error message handling needs to be worked out in detail to assure
       reasonable reporting of problems with the use of forwarders.

   2.  Designation of forwarding hosts.

   3.  Collection of internet mailbox names for implicit forwarders.

   4.  Format and distribution of internet name table and NCP/TCP
       capability information.

   5.  Dealing with mail systems not compatible with NCP, TCP or RFC733.
       (e.g. Telemail, On-Tyme, Phonenet, TWX, TELEX,...)












                                   8


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



PLANS

   To encourage this transition, the following schedule is proposed:

      1.  January 1, l981 - implicit and explicit NCP/TCP forwarders
          made available on various service hosts (e.g. TOPS-20).

      2.  January 1, l982 - implicit NCP/TCP forwarder service removed;
          explicit forwarding service continues.

      3.  January 1, l983 - explicit NCP/TCP forwarding service
          terminated, transition to TCP complete.

ACKNOWLEDGEMENTS

   A number of people have reviewed and commented on this contribution.
   Particular comments by J. Pickens, J. Postel, J. Haverty, D. Farber
   and D. Adams are gratefully acknowledged.































                                   9


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



                               REFERENCES

   1.  DoD Standard Internet Protocol, IEN 128, RFC 760, NTIS
       ADA 079730, Jan 1980.

   2.  DoD Standard Transmission Control Protocol, IEN 129, RFC 761,
       NTIS ADA 082609, Jan 1980.

   3.  Postel, J., Telnet Protocol Specification, IEN 148, RFC 764,
       Jun 1980.

   4.  Postel, J., File Transfer Protocol, IEN 149, RFC 765, Jun 1980.

   5.  Postel, J., User Datagram Protocol, RFC 768, Aug 1980.

   6.  Postel, J., Internet Name Server, IEN 116, Aug 1979.

   7.  Postel, J., Internet Message Protocol, IEN 113, RFC 759, Aug
       1980.

   8.  Postel, Sunshine, Cohen, The ARPA Internet Protocol, in
       preparation.

   9.  NCP:  ARPANET Protocol Handbook, NIC 7104, Jan 1978.

   10.  Telnet:  ARPANET Protocol Handbook, NIC 7104, Jan 1978.

   11.  FTP:  ARPANET Protocol Handbook, NIC 7104, Jan 1978.

   12.  D. Crocker, J. Vittal, K. Pogran, A. Henderson, Standard for the
        Format of ARPA Network Text Messages, RFC 733, Nov 1977.

   13.  Crocker, et.al., Function-Oriented Protocols for the ARPA
        Computer Network, SJCC, May, 1972.

   14.  Carr, Crocker, Cerf, Host-Host Communication Protocol in the
        ARPA Network, SJCC, May, 1970.

   15.  Cerf, V., The Catenet Model for Internetworking, IEN 48,
        DARPA/IPTO, Jul 1978.

   16.  BBN 1822:  Specifications for the Interconnection of a Host and
        an IMP, BBN Report No. 1822.

   17.  Heart, et.al., The Interface Message Processor for the ARPA
        Computer Network, SJCC, May, 1970.



                                   10


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



   18.  Shoch, J., Inter-Network Naming, Addressing, and Routing,
        COMPCOM, Fall 1978.

   19.  Postel, J., A Structured Format for Transmission of Multi-Media
        Documents, RFC 767, Aug 1980.

   20.  Cerf, V. and, J. Postel, Mail Transition Plan, RFC 771,
        Sep 1980.

   21.  Sluizer, S. and, J. Postel, Mail Transfer Protocol, RFC 772,
        Sep 1980.






































                                   11