Computer mail meeting notes
How the Internet settled on hierarchical domain-based email addresses
Postel, J., "Computer mail meeting notes", RFC 805, DOI 10.17487/RFC0805, February 1982, <https://www.rfc-editor.org/info/rfc805>.
@misc{rfc805,
series = {Request for Comments},
number = 805,
howpublished = {RFC 805},
publisher = {RFC Editor},
doi = {10.17487/RFC0805},
url = {https://www.rfc-editor.org/info/rfc805},
author = {J. Postel},
title = {{Computer mail meeting notes}},
pagetotal = 6,
year = 1982,
month = feb,
} RFC text
Contents
Network Working Group J. Postel
Request for Comments: 805 ISI
8 February 1982
Computer Mail Meeting Notes
Introduction
A meeting was held on the 11th of January 1982 at USC Information
Sciences Institute to discuss addressing issues in computer mail.
The attendees are listed at the end of this memo. The major
conclusion reached at the meeting is to extend the
"username@hostname" mailbox format to "username@host.domain", where
the domain itself can be further structured.
Overview
The meeting opened with a brief discussion of the objectives of the
meeting and a review of the agenda.
The meeting was called to discuss a few specific issues in text
mail systems for the ARPA Internet. In particular, issues of
addressing are of major concern as we develop an internet in which
mail relaying is a common occurance. We need to discuss
alternatives in the design of the mail system to provide high
utility at reasonable cost. One scheme suggested is to create
"mail domains" which are another level of addressing. The ad hoc
scheme of source routing, while effective for some cases, is seen
to lead to some problems. A key test of addressing schemes is the
procedure for sending copies of a reply to a message to the people
who received copies of the original message. The key reference
documents for the meeting were RFCs 788, 799, and 801.
Jon Postel gave a brief review of the NCP-to-TCP transition plan (RFC
801). The emphasis was on mail, the internet host table, and the
role of a Host Name Server.
The major part of the meeting was devoted to a wide ranging
discussion of the general mailbox identification problem. In
particular, the notion of a hierarchial structure of name domains was
discussed, and the issues associated with name servers were discussed
including the types of information name servers should provide.
Name Domains
One of the interesting ideas that emerged from this discussion was
that the "user@host" model of a mailbox identifier should, in
principle, be replaced by a "unique-id@location-id" model, where the
unique-id would be a globally unique id for this mailbox (independent
of location) and the location-id would be advice about where to find
the mailbox. However, it was recognized that the "user@host" model
was well established and that so many different elaborations of the
"user" field were already in use that there was no point in persuing
this "unique-id" idea at this time.
Several alternatives for the structuring and ordering of the
extensions to the "host" field to make it into a general
"location-id" were discussed.
These basically involved adding more hierarchical name information
either to the right or the left of the @, with the "higher order"
portion rightmost or leftmost. It was clear that the information
content of all these syntactic alternatives was the same, so that
the one causing least difficulty for existing systems should be
chosen. Hence it was decided to add all new information on the
right of the @ sign, leaving the "user" field to the left
completely to each system to determine (in particular to avoid the
problem that some systems already use dot (.) internally as part
of user names).
The conclusion in this area was that the current "user@host" mailbox
identifier should be extended to "user@host.domain" where "domain"
could be a hierarchy of domains.
In particular, the "host" field would become a "location" field
and the structure would read (left to right) from the most
specific to the most general.
For example: "Postel@F.ISI.IN" might be the mailbox of Jon
Postel on host F in the ISI complex of the Internet domain.
Formally, in RFC733, the host-indicator definition rule would
become:
host indicator = ( "at" / "@" ) domains
domains = node / node "." domains
Note only one "at" or "@" is allowed, and that the domains
form a hierarchy with the most general in scope last.
And note that the choice of domain names must be
administratively controlled and the highest level domain
names must be globally unique.
The hierarchial domain type naming differs from source routing in
that the former gives absolute addressing while the latter gives
relative adressing.
Name Servers
The discussion of name servers identified three separate name server
functions: "white pages", "unique-id to location-id", and
"location-id to address".
The "white pages" service is a way of looking up a user by name
and other properties using pattern matching and may return several
data base "hits". Each hit must have an associated unique-id.
The "unique-id to location-id" service returns the character
string location-id where the unique-id is currently found.
The "location-id to address" service returns a network address
(numeric) corresponding to the location-id.
If the location-id is the name of a host in the current domain
it is clear that the address returned will be the address to
send the mail to, but if the location-id is that of some other
domain then the address returned may be either the address to
send the mail to, or the address of a name server for that
domain, and these two cases must be distinguished.
The conclusion of this discussion was that a location-id to address
name service must be defined soon. The other types of name servers
were not further discussed, and are not required in the
implemenation.
Another aspect of the name server is returning additional information
besides the address. In particular, for mail it is important to know
which mail procedures the destination implements (NCP/FTP, TCP/SMTP,
etc.). Two approaches were discussed: one is coding the information
as service names (e.g., NCP/SMTP), and the other is by reference to
protocol and port numbers (e.g., PROTOCOL=6, PORT=25). Another
suggestion was that the request ought to be "location-id,service"
(e.g., "ISIF.IN,MAIL") and the response ought to be the location-id,
address, protocol, and port. A different way of getting this
information was suggested that instead of (or in addition to) having
this information in the name server, one should get this data from
the host itself via some sort of query or "who are you" protocol.
Also discussed was the initial provision for name service. It seems
useful to start with a text file that can be accessed via FTP, and to
have both "Telnet-Like" (i.e., based on TCP) and "Datagram" (i.e.,
based on UDP) access to a query server. This might be possible as an
extension of the IEN-116 name server.
Another issue was the central vs. distributed implementation of the
name look up service. It is recognized that separate servers for
each domain has administrative and maintenance advantages, but that a
central server may be a useful first step. It is also recognized
that each distinct database should be replicated a few times and be
avialiable from distinct servers for robust and reliable service.
An Example:
Suppose that the new mailbox specification is of the form
USER@HOST.ORG.DOMAIN.
e.g., Postel@F.ISI.IN
A source host sending mail to this address first queries a name
server for the domain IN (giving the whole location "F.ISI.IN").
The result of the query is either (1) the final address of the
destination host (F.ISI), or (2) the address of a name server for
ISI, or (3) the address of a forwarder for ISI. In cases 1 and 3,
the source host sends the mail to the address returned. In case
2, the source host queries the ISI name server and ... (recursive
call to this paragraph).
Action Items:
RFC 733 Revision
To include the hierarchial host and domain naming procedure, and
to delete the features decommitted at the Computer Mail meeting on
10-JAN-79.
By: Dave Crocker
Due: 15-Feb-82
Host Name Server Description
To specify a way to get name to address conversions and to find
out about services offered. Also how to get info on domain names.
By: Jon Postel
Due: 15-Feb-82
Transition Plan Revision
To include new host and domain names.
By: Jon Postel
Due: 15-Feb-82
SMTP Revision
To include new host and domain names.
By: Jon Postel
Due: Unspecified
Mail System Description Revision
How to do mail systems, including use of SMTP and Host Name
Server.
By: Jon Postel
Due: Unspecified
Conversion of User Programs and Mailer Programs.
Programs have to handle dots in the "host" field. Many programs
on many hosts will have to be modified to a greater or lesser
extent. In many cases the modifications should be quite simple.
By: A Cast of Thousands
Due: Unspecified (See the Following Item)
Set a date when it ok to send messages with dots in "host" field.
The must be a date after which it is ok to send host fields with
dots throughout the ARPANET and Internet world without the
recipients complaining.
By: DARPA (Duane Adams)
Due: 1-Mar-82
Attendees:
Duane A. Adams DARPA/IPTO Adams@ISI (202) 694-8096
Vint Cerf DARPA/IPTO Cerf@ISI (202) 694-3049
Harry Forsdick BBN Forsdick@BBN (617) 497-3638
Eric Schienbrood BBN shienbrood@bbn-unix (617) 497-3756
Bob Thomas BBN BThomas@BBND (617) 497-3483
Bob Fabry Berkeley Fabry@Berkeley (415) 642-2714
Bill Joy Berkeley unj@berkeley (415) 642-7780
Gene Ball CMU Ball@CMUA (412) 578-2569
Anil Agarwal COMSAT Agarwal@ISID (301) 863-6103
David L. Mills COMSAT Mills@ISID (202) 863-6092
Dave Crocker Univ. Del DCrocker@Udel (302) 738-8913
Ray McFarland DoD McFarland@ISIA (301) 796-6290
Dave Lebling MIT PDL@MIT-XX (617) 253-1440
Paul Mockapetris ISI Mockapetris@ISIF (213) 822-1511
Jon Postel ISI Postel@ISIF (213) 822-1511
Carl Sunshine ISI Sunshine@ISIF (213) 822-1511
Mark Crispin Stanford U. Admin.MRC@SCORE (415) 497-1407
Bob Braden UCL[A] braden@ISIA (uk) (01)387-7050
Steve Kille UCL UCL-Netwiz@ISIE (uk) (01)387-7050
Bill Tuck UCL UKSAT@ISIE (uk) (01)387-7050
Marv Solomon Univ. Wisc Solomon@UWisc
Ed Taft Xerox Parc Taft@Parc-Maxc (415) 494-4419
AI ELI5
On this page
§1The Meeting and Its Goals
On January 11, 1982, leaders from DARPA, BBN, UC Berkeley, CMU, COMSAT, MIT, and other research institutions met at USC Information Sciences Institute in Los Angeles to discuss addressing issues in computer mail. The meeting was called because the ARPA Internet was growing, mail relaying (forwarding mail through intermediate hosts) was becoming common, and the simple "user@hostname" format could not support the emerging structure.
The participants, including Jon Postel, Vint Cerf, and Paul Mockapetris (who would later design the Domain Name System), focused on several problems: how to organize addresses when messages must route through multiple mail servers, how to avoid the pitfalls of source routing (where the sender specifies the path), and how to ensure that reply messages reach the correct recipients.
Internet experts gathered to solve a problem: the old way of addressing email was running out of room as the network grew and mail had to pass through more computers.
§2The New Hierarchical Domain Structure
The meeting's major conclusion was to replace the simple "user@host" format with "user@host.domain", where the domain itself can be further structured hierarchically. This creates a location identifier that reads from left to right, most specific to most general.
For example, instead of just "Postel@hostname", the address might be "Postel@F.ISI.IN"—Jon Postel on host F in the ISI complex of the Internet domain. The dots in the hostname allow unlimited hierarchical nesting without changing mail software except to recognize the new syntax.
One alternative discussed was replacing "user@host" with a "unique-id@location-id" model, where each mailbox had a globally unique identifier independent of its location, and the location could change. However, the meeting recognized that the "user@host" model was too well established to change, and many systems already used dots in usernames in incompatible ways, so this idea was set aside.
The key decision was to extend only the right side of the @ symbol (the hostname part) to avoid breaking existing user naming conventions. The highest-level domain names would need to be globally unique and administratively controlled.
Instead of "user@computer", addresses would become "user@computer.organization.domain". This lets each organization have its own subdomains without needing one central master list.
§3Name Servers and Service Discovery
The meeting identified three separate functions a name server should provide. The "white pages" service allows users to look up a person by name and other properties, returning one or more matches, each with an associated unique user ID. The "unique-id to location-id" service translates a user ID to a current location (like a forward address). The "location-id to address" service converts a domain or host name into a numeric network address.
The group decided that the location-id to address service was the most urgent to define. They also discussed whether name servers should return information about which mail services a destination supports (for example, whether it accepts NCP/FTP mail, TCP/SMTP mail, or both). This information could be coded as service names or by protocol and port numbers, or it could be queried from the host itself.
For initial implementation, the meeting proposed starting with a simple text file accessible via FTP, with both connection-oriented (TCP-based) and connectionless (UDP-based) query access to a name server. This might extend the IEN-116 name server design. The group also recognized that while a central name server might be useful to start, a distributed system with servers per domain would offer better maintenance and reliability if the databases were replicated.
Computers would ask a name server where to find an address, what services it offers, and how to reach it. These servers could be centralized at first, then distributed across organizations later.
§4Action Items and Implementation Timeline
The meeting assigned specific follow-up tasks with deadlines. Dave Crocker was tasked with revising RFC 733 to include the hierarchical naming procedure by February 15, 1982. Jon Postel was assigned to specify the Host Name Server and update the NCP/TCP transition plan and SMTP specification to use the new naming convention, also by February 15. A Mail System Description was planned (deadline unspecified) to document how to use SMTP and name servers together.
The group recognized that many programs on many hosts would need modification to handle dots in the hostname field, a task assigned to "A Cast of Thousands." DARPA (Duane Adams) was given the responsibility to set a date—by March 1, 1982—after which it would be acceptable to send mail with dots in the host field across the ARPANET and Internet without complaint.
Different people were assigned to update the standards, programs had to be fixed, and a date was set for when everyone could start using the new format.