RFC 773

Comments on NCP/TCP mail service transition strategy

📅 published October 1980, from ietf

Comments on NCP/TCP Mail Service Transition Strategy 💌

  • RFC: 773
  • Working group: Network Working Group
  • Author: V. Cerf, DARPA
  • Date: October 1980
  • Category, obsoletes, updates: the header doesn't list any of these, so there's nothing to report 🫶

Introduction ✨

okay so this memo reviews and expands on the mail service transition plan [20] 📬

The main aim of the plan is to keep the most commonly used network service, mail, properly supported while we move from ARPANET to Internet Protocol-based operation 🦋

The end goal is for the internet environment to offer service that's equivalent to or better than what ARPANET had 🔥. During the in-between period, when both internet and the older ARPANET-based protocols are in use, the goal is to minimize user impact and, as much as possible, minimize software development or modification needed to deal with transitional problems 💅

We're assuming you already know the ARPANET and internet protocol hierarchies [1-17] 🧠. The internet hierarchy is built to interface with lots of 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 how ARPANET electronic mail services can be supported across the boundary between the purely ARPANET environment and the more general internet environment. This covers the period when ARPANET hosts are moving over to the richer internet world 🌈

Electronic Message Services 📨

DARPA is starting a new phase of research into automatic electronic message handling systems. The big dream is that electronic messages will eventually mix multiple media like text, facsimile, compressed digitized voice, graphics and so on 🎀. Making that work will take a lot of progress on 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, we have to build toward an environment based on internet protocols so the results of the multimedia effort aren't stuck on any one network 🧚. So DARPA plans to make several transitions over the next few years, going from the existing, text-based ARPANET electronic message system to an internet-based, multimedia electronic message system ⭐

This paper only covers the first of those transitions, from NCP-based text mail to TCP-based multimedia mail. The move to the new multimedia mail system [7,19] is coming, but it doesn't need detailed planning 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 moving from ARPANET-based electronic mail to internet electronic mail are these:

  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 🔮

Okay, so to make any progress at all, we had to assume some pretty sophisticated changes to the "mailer" function. The mailer takes an electronic text message as input and gets it delivered to the destination (or to an intermediate forwarder) 💅

We also assume there are special, well-known mail forwarding hosts on the ARPANET. Their job is to accept messages from NCP (TCP)-based message senders and forward them to TCP (NCP)-based message receivers 🫶

On the ARPANET, electronic messages travel through special File Transfer Protocol procedures: MAIL and MLFL. The former sends electronic messages through the FTP Telnet command channel, while the latter does it by actual file transfer. In both cases, it's generally assumed that the receiving FTP server is colocated with the destination mailbox 🌈

So the sending procedure tells 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 gets messy when messages have to be staged at an intermediate host for further processing, like when you're moving from an NCP-based sender to a TCP-based receiver, or the other way around. Similar issues come up with compatible, but different, message systems that need messages re-formatted at intermediate points 😭

Next, a mechanism is proposed for handling the naming, addressing and routing [18] of messages between systems 🧭

At the source, it's assumed that the user has prepared the message text (including "To:" and "CC:" fields) in the conventional way [12] ✍️. The mailbox identifiers will keep using this format:

User@Host

but "host" might actually be a compound name (which isn't 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 "@" can't appear in either the "user" or "host" strings in the mailbox identifier 🚫

During message composition, the "user" or "host" portions of the mailbox identifier may be checked for correctness (or at least for validity) 🔍. The "user" string may include parenthetical information like this:

RAK(Richard A. Karp)@SU-AI

since that's currently allowed 💖

After composition, messages are either sent right away or saved as "unsent mail" files to be sent later by mailer demons 📤. The actual sending process uses the "host" string to figure out where and how to send the message 🎯

New Mail Mechanisms 🚀

Now we hit the first critical new requirement for the transition plan 😤. A new table is needed within the mailer, or in the host supporting the mailer, or somewhere the mailer can reach through the internet name server (for instance). This table has to map the "host" string into an internet destination address (i.e., 32 bits: 8 bits of net, 24 bits of host), and it also has to indicate whether the destination is NCP or TCP capable 📋

If the source and destination hosts don't 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." The forwarder stages the transport by accepting the message through one protocol and forwarding it by another 🔀

This creates a problem for the forwarding host. The basic FTP mail mechanism only sends the "user" portion of the mailbox identifier ("user@host"), because the assumption is that "host" is the destination. But when forwarding, "host" isn't the forwarder 🥴. Even if we cleverly set things up so "host" translates into the internet address of a forwarder, two problems remain. First, the forwarder may need the "host" information to figure out where to forward the message next. Second, depending on which network the source is on, "host" may need to translate into different forwarder addresses. That second point brings up the specter of many different mappings for a given "host" string, which would need different tables for different mail sources. That would make maintaining and distributing the forwarder address tables a huge mess 😵‍💫. And a single-entry table mapping "host" to a forwarder would limit reliability, since only one forwarder would be bound to serve a giver "host" 💀

For the NCP/TCP transition, it may be enough to declare some set of well-known hosts to be NCP/TCP forwarders 🌟. Whenever a mailer finds an incompatible destination, it can send the message to any forwarder that's available. On top of that, the mailer must provide the full mailbox identifier information "user@host" to the forwarding host 📦

Right now, mailers only send the "user" portion of the mailbox identifier, so every mailer has to change to send "user@host" when it's talking to a forwarder 🛠️. Mailers also all have to learn a new way to look things up in tables, to map "host" into internet addresses and to interpret the NCP or TCP capability information 🧠

For discussion purposes, we're assuming three different cases of electronic mail service implementation that have 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 the host has adopted a new host-string to address table (including NCP/TCP capability bits) and a new mailer - mail server program, but still uses the old NCP host level protocol, modified to send "user@host" when sending to a forwarder. For these hosts, the only table entries that lead to direct source-destination mail delivery are the ones showing NCP capability. If the destination is TCP capable only, the source host picks a forwarder address from another table and sends the message to it for further processing 🔁

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

Mail composition programs (e.g. SNDMSG, MSG, Hermes, MH,...) that use ARPANET string-to-address tables today to verify host names in mailbox entries can keep using these "old" tables, as long as they're updated to include internet host names as well as ARPANET host names 📚

Expanding the old tables is actually essential for handling the hardest transition case: OLD NCP to new TCP mail 😩. The three types of hosts lead to a 3 by 3 matrix of mail transfer cases. In all but one case, mail is either handled directly or explicitly by a forwarder. The only case that needs more explanation is OLD NCP to NEW TCP, which uses an "implicit forwarder." 🕵️‍♀️✨

IMPLICIT FORWARDING VS EXPLICIT FORWARDING ✨

Okay so bestie, if the source host has adopted the new internet tables, it can tell whether the destination host has a compatible mail acceptance protocol 💅 If it's incompatible, that gets sorted out by picking an intermediate forwarder 🔥

If the source host is still on pure NCP tables, though, it won't be able to tell that a particular destination host is only TCP-capable 😭 To cover this case, it's proposed to expand the conventional NCP host table to include internet host names, but to map them to the addresses of implicit mail forwarders (aka Aliases) 🦋

Since we're postulating an NCP host that hasn't changed anything (except extending the host table), we also assume the source host can't send the "user@host" information via FTP to the intermediate forwarder 🙈

That leaves the intermediate forwarder with a problem: figuring out where to forward a message identified by "user" only. So we postulate that internet TCP-only mailboxes get registered at implicit forwarders, so incoming mail from conventional NCP sources can still be forwarded successfully to the destination ✨

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

Using registered names at 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?

For the first one, we propose to duck the problem by insisting on 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 it in a database that 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 to 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's the internet mailbox users who must register, though, since they're 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 let implicit forwarders also accept ordinary mail for users with mailboxes on the implicit forwarder itself, 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). Here's the summary of the communication patterns 👑

  • (a) TCP sends/receives mail via well known port 57.
  • (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.
Heads up: the mail servers only offer service on the ports listed above, so keep your socket numbers straight 🙈

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 they can make use of explicit forwarders. This requires implementing the mail server and modifying the mailer programs for sending mail to explicit forwarders. It also requires adding 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,...) 💀

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 🫶

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.
  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.
📦 where this page comes from