As per Relevance of the word destination, we have this rfc below:
Network Working Group V.
Request for Comments: 773
October 1980
COMMENTS ON NCP/TCP MAIL SERVICE TRANSITION
This memo reviews and expands on the mail service transition
[20].
The principal aim of the plan is to provide for the orderly
of the most commonly used network service (mail) during the period
transition from ARPANET to Internet Protocol-based operation
The goal of the transition is, at the end, to provide in the
environment service which is equivalent to or better than what
been available in the ARPANET environment. During the
period, when both internet and the older ARPANET-based protocols
in use, the goal of the transition is to minimize user impact and,
the extent possible, to minimize software development or
required to deal with transitional problems
It is assumed that the reader is familiar with both the ARPANET
internet protocol hierarchies [1-17]. The internet hierarchy
designed to interface to many different packet networks (e.g.,
satellite, packet radio, Ethernet, LCS Ring net, X.25
nets, ...), while the ARPANET hierarchy is limited to ARPANET
(This is less true of the levels above NCP, but NCP itself is
bound to ARPANET services).
The objective of the transition plan is to specify means by which
ARPANET electronic mail services may be supported across the
between the purely ARPANET environment and the more general
environment during the period of transition by ARPANET hosts to
richer internet world
ELECTRONIC MESSAGE
DARPA is beginning a new phase of research into automatic
message handling systems. Ultimately, it is intended that
messages incorporate multiple media such as text, facsimile
compressed digitized voice, graphics and so on. Success in this
research will require substantial progress in developing
user interfaces to computer-based services (voice input/output
graphics, tablet/light pen, facsimile input/output, video/bit
displays, ...).
At the same time, progress must be made towards an environment
on internet protocols so as to avoid confining the results of
1
October 1980 RFC 773
Comments on NCP/TCP Mail Service Transition Strategy
multimedia effort to any one network. As a result, DARPA is
to make several transitions over the next few years, from
existing, text-based ARPANET electronic message system to
internet-based, multimedia electronic message system
This paper addresses only the first of the transitions from NCP-
text mail to TCP-based multimedia mail. The transition to the
multimedia mail system [7,19] lies ahead, but need not be planned
detail until we have some experience with the basic concepts.
first step only provides for the transition to TCP-based text mail
The basic ground rules for transition from ARPANET-based
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
to compose replies and the like
3. Accommodation of non-ARPANET mailbox designators
change to the header parsing and checking mechanisms of
composition programs
4. Automatic forwarding of messages between NCP and
environments without user intervention
5. During the transition, old style mail mechanisms must
work
ELECTRONIC MESSAGE
In order to make progress at all, it has been necessary to
fairly sophisticated changes to the "mailer" function which
as input an electronic text message and causes it to be delivered
the destination (or to an intermediate forwarder).
We also posit the existence of special, well-known mail
hosts on the ARPANET which are responsible for accepting
from NCP (TCP)-based message senders and forwarding them
TCP (NCP)-based message receivers
In the ARPANET, electronic messages are transported via
procedures of the File Transfer Protocol: MAIL and MLFL. The
method sends electronic messages via the FTP Telnet command
2
RFC 773 October 1980
Comments on NCP/TCP Mail Service Transition
while the latter achieves this by actual file transfer. In
cases, it is generally assumed that the receiving FTP server
colocated with the destination mailbox
Thus, the sending procedure identifies to the receiver
destination mailbox identifier, but not the destination host (
network) identifier. For example, messages sent from Postel
USC-ISIF to Adams at USC-ISIA would arrive at ISIA with an
"Adams" but no indication of "ISIA". This creates some problems
messages must be staged at an intermediate host for
processing, as is the case when moving from an NCP-based sender to
TCP-based receiver, or vice-versa. Similar considerations arise
dealing with compatible, but different, message systems
re-formatting of messages at intermediate points
In the following paragraphs, a mechanism is proposed for dealing
the naming, addressing and routing [18] of messages between systems
At the source, it is assumed that the user has prepared the text
the message (including "To:" and "CC:" fields) in the
way [12]. The mailbox identifiers will continue to exhibit
format
User@
but "host" may in fact be a compound name (which is not
parsed), such as
USC-
ARPANET-
SATNET-
PPSN-
HOST1.
LCSNET/
or even the name of an organization, such as
The only restriction is that the "@" not appear in either "user"
"host" strings in the mailbox identifier
During message composition, the "user" or "host" portions of
3
October 1980 RFC 773
Comments on NCP/TCP Mail Service Transition Strategy
mailbox identifier may be verified for correctness (or at least
validity). The "user" string may incorporate
information such
RAK(Richard A. Karp)@SU-
as is currently allowed
After composition, messages are either sent immediately or left
"unsent mail" files to be sent later by mailer demons. The
sending process uses the "host" string to determine where and how
send the message
NEW MAIL
At this point, we encounter the first critical new requirement
support the transition plan. A new table is needed within the
or in the host supporting the mailer or accessible to the mailer
the internet name server (for instance). This table must provide
mapping of the "host" string into an internet destination
(i.e., 32 bits: 8 bits of net, 24 bits of host), and must
indicate whether the destination is NCP or TCP capable
In the event that the source and destination hosts do not have
compatible host level protocol (e.g. source is NCP only,
is TCP only) then the message must be passed to a "forwarder"
can stage the transport by accepting via one protocol and
by another
This leads to a problem for the forwarding host since the basic
mail mechanism sends only the "user" portion of the
identifier ("user@host") because the assumption is that the "host"
the destination. In the case of forwarding, the "host" is not
forwarder. Even if we cleverly arrange for "host" to translate
the internet address of a forwarder, we will have two problems
First, the forwarder may need the "host" information to figure
now to forward the message and second, depending on which network
source is in, "host" may need to translate into different
addresses. The latter observation raises the spectre of
different mappings of a given "host" string which would
different tables for different mail sources. This would lead
considerable complexity in the maintenance and distribution of
of forwarder addresses. Furthermore, a single-entry table
"host" to forwarder would limit reliability since only one
would be bound to serve a giver "host".
4
RFC 773 October 1980
Comments on NCP/TCP Mail Service Transition
For the NCP/TCP transition, it may be sufficient to declare some
of well-known hosts to be NCP/TCP forwarders. Each mailer, when
discovers an incompatible destination, can send the message to
forwarder which is available. In addition, however, the mailer
provide full mailbox identifier information "user@host" to
forwarding host
In the present mailers, only the "user" portion of the
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
table look-up a new way, also, to map "host" into internet
and to interpret the NCP or TCP capability information
For purposes of this discussion, we postulate three different
of electronic mail service implementation which must be made
interoperate during the transition
1. Unchanged OLD NCP (RFC733)
2. NCP mail with new internet
3. TCP mail with new internet tables
The second case assumes that the host has adopted a new host-
to address table (including NCP/TCP capability bits) and new mailer -
mail server programs, but continues to use the old NCP host
protocol, modified to send "user@host" when sending to a forwarder
For such hosts, the only table entries which result in
source-destination mail delivery are those showing NCP capability
If the destination is TCP capable only then the source host selects
forwarder address from another table and sends the message to it
further processing
In the third case, the source host has fully transitioned to TCP
uses the new internet address tables to translate host-strings
internet addresses, and uses the new mailer - mail server
Destinations which are NCP-compatible only are reached via NCP/
forwarders
Mail composition programs (e.g. SNDMSG, MSG, Hermes, MH,...)
today use ARPANET string-to-address tables to verify the legality
host names in mailbox entries can continue to use these "old"
as long as these are updated to include internet host names as
as ARPANET host names
Indeed, expanding the old tables is essential to handle the
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
lead to a 3 by 3 matrix of cases of mail transfer. In all but
case, mail is either handled directly or explicitly by forwarder
The only case needing further explanation is OLD NCP to NEW TCP
uses an "implicit forwarder."
IMPLICIT FORWARDING VS EXPLICIT
If the source host has adopted the new internet tables, it can
whether the destination host has a compatible mail
protocol. Incompatibility is explicitly resolved by selection of
intermediate forwarder
If, however, the source host is still using pure NCP tables, it
not be able to tell that a particular destination host is
TCP-capable. To provide service for this case, it is proposed
expand the conventional NCP host table to include internet
names, but to map them into the addresses of implicit mail
(i.e. Aliases).
Since we are postulating a case in which the NCP host has made
change (except for extending the host table). we also assume that
source host cannot send the "user@host" information via FTP to
intermediate forwarder
This leaves the intermediate forwarder with the problem of
out where to forward a message identified by "user" only. In
case, we postulate that internet TCP-only mailboxes are registered
implicit forwarders so that incoming mail from conventional
sources can be forwarded successfully to the destination
In the reverse direction, the source can use explicit
because it is assumed that all TCP hosts use the new internet tables
The use of registered names in the implicit forwarder raises
problems
1. How can we deal with ambiguous mailbox names? (e.g. USERX@
and USERX@ISI look the same if only the string "USERX"
presented to the intermediate forwarder
2. How can we collect, update and distribute changes to
registries at implicit forwarders
In the first case, we propose to duck the problem by insisting
6
RFC 773 October 1980
Comments on NCP/TCP Mail Service Transition
unambiguous mailbox names everywhere. This may force some
mail users to change their mailbox names, but we believe this will
rare
The second problem can be solved by collecting information on
regular basis from all network mail users and cataloging this data
a database which can be accessed automatically (e.g. by
programs).
One possible mechanism is to make the data available through
internet mailbox name server analogous to the internet host
server [6]. This data might be collectible as a natural part of
TIP LOGIN database which is under development to permit
access to the ARPANET TIPs by legitimate ARPANET users
In any case, internet mail users need supply their
information to a single collection site which would disseminate it
all implicit forwarders on ARPANET. Note that such forwarders
only needed on ARPANET since all other systems are starting with
TCP-base. It is the internet mailbox users who must register
however, since they are the ones who cannot otherwise be reached
NCP
FORWARDER
By their definition, NCP/TCP forwarders must be both NCP and
capable. Consequently, all NCP/TCP forwarders must be ARPANET hosts
Implicit forwarders must accept conventional NCP/FTP mail [11] and
equipped with tables of valid internet user mailbox names which
be associated with the proper destination host. To allow
forwarders to also accept ordinary mail for users with mailboxes
the implicit forwarder, the forwarder should check first
incoming mail is for a local user
Explicit mail forwarders must be able to accept both
NCP-FTP mail commands (for local user mail) and both NCP-based
TCP-based mail server commands (whose arguments include the
destination mailbox strings "user@host").
To prevent potentially anomalous behavior, the NCP-based
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
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
sent/received via port 57.
USER HOST
NCP hosts must at minimum, update host name tables to include
for internet hosts (i.e. map to NCP implicit forwarder
addresses).
The next most useful step is to update NCP hosts to include
address tables and NCP/TCP capability bits so as to make use
explicit forwarders. This requires implementation of the mail
and modification of the mailer programs for sending mail to
forwarders. This also requires addition of explicit
address tables
Finally, a host can implement full TCP mail services,
internet name tables and explicit forwarder address tables as well
DANGLING
1. Error message handling needs to be worked out in detail to
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/
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
To encourage this transition, the following schedule is proposed
1. January 1, l981 - implicit and explicit NCP/TCP
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
terminated, transition to TCP complete
A number of people have reviewed and commented on this contribution
Particular comments by J. Pickens, J. Postel, J. Haverty, D.
and D. Adams are gratefully acknowledged
9
October 1980 RFC 773
Comments on NCP/TCP Mail Service Transition Strategy
1. DoD Standard Internet Protocol, IEN 128, RFC 760,
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,
1980.
8. Postel, Sunshine, Cohen, The ARPA Internet Protocol,
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
Format of ARPA Network Text Messages, RFC 733, Nov 1977.
13. Crocker, et.al., Function-Oriented Protocols for the
Computer Network, SJCC, May, 1972.
14. Carr, Crocker, Cerf, Host-Host Communication Protocol in
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
an IMP, BBN Report No. 1822.
17. Heart, et.al., The Interface Message Processor for the
Computer Network, SJCC, May, 1970.
10
RFC 773 October 1980
Comments on NCP/TCP Mail Service Transition
18. Shoch, J., Inter-Network Naming, Addressing, and Routing
COMPCOM, Fall 1978.
19. Postel, J., A Structured Format for Transmission of Multi-
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
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
