As per Relevance of the word february, we have this rfc below:
Network Working Group J.
Request for Comments: 805
8 February 1982
Computer Mail Meeting
A meeting was held on the 11th of January 1982 at USC
Sciences Institute to discuss addressing issues in computer mail
The attendees are listed at the end of this memo. The
conclusion reached at the meeting is to extend
"username@hostname" mailbox format to "username@host.domain",
the domain itself can be further structured
The meeting opened with a brief discussion of the objectives of
meeting and a review of the agenda
The meeting was called to discuss a few specific issues in
mail systems for the ARPA Internet. In particular, issues
addressing are of major concern as we develop an internet in
mail relaying is a common occurance. We need to
alternatives in the design of the mail system to provide
utility at reasonable cost. One scheme suggested is to
"mail domains" which are another level of addressing. The ad
scheme of source routing, while effective for some cases, is
to lead to some problems. A key test of addressing schemes is
procedure for sending copies of a reply to a message to the
who received copies of the original message. The key
documents for the meeting were RFCs 788, 799, and 801.
Jon Postel gave a brief review of the NCP-to-TCP transition plan (
801). The emphasis was on mail, the internet host table, and
role of a Host Name Server
The major part of the meeting was devoted to a wide
discussion of the general mailbox identification problem.
particular, the notion of a hierarchial structure of name domains
discussed, and the issues associated with name servers were
including the types of information name servers should provide
Name
One of the interesting ideas that emerged from this discussion
that the "user@host" model of a mailbox identifier should,
Postel [Page 1]
Computer Mail Meeting Notes 8 February 1982
principle, be replaced by a "unique-id@location-id" model, where
unique-id would be a globally unique id for this mailbox (
of location) and the location-id would be advice about where to
the mailbox. However, it was recognized that the "user@host"
was well established and that so many different elaborations of
"user" field were already in use that there was no point in
this "unique-id" idea at this time
Several alternatives for the structuring and ordering of
extensions to the "host" field to make it into a
"location-id" were discussed
These basically involved adding more hierarchical name
either to the right or the left of the @, with the "higher order
portion rightmost or leftmost. It was clear that the
content of all these syntactic alternatives was the same, so
the one causing least difficulty for existing systems should
chosen. Hence it was decided to add all new information on
right of the @ sign, leaving the "user" field to the
completely to each system to determine (in particular to avoid
problem that some systems already use dot (.) internally as
of user names).
The conclusion in this area was that the current "user@host"
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"
and the structure would read (left to right) from the
specific to the most general
For example: "Postel@F.ISI.IN" might be the mailbox of
Postel on host F in the ISI complex of the Internet domain
Formally, in RFC733, the host-indicator definition rule
become
host indicator = ( "at" / "@" )
domains = node / node "."
Note only one "at" or "@" is allowed, and that the
form a hierarchy with the most general in scope last
And note that the choice of domain names must
administratively controlled and the highest level
names must be globally unique
Postel [Page 2]
Computer Mail Meeting Notes 8 February 1982
The hierarchial domain type naming differs from source routing
that the former gives absolute addressing while the latter
relative adressing
Name
The discussion of name servers identified three separate name
functions: "white pages", "unique-id to location-id",
"location-id to address".
The "white pages" service is a way of looking up a user by
and other properties using pattern matching and may return
data base "hits". Each hit must have an associated unique-id
The "unique-id to location-id" service returns the
string location-id where the unique-id is currently found
The "location-id to address" service returns a network
(numeric) corresponding to the location-id
If the location-id is the name of a host in the current
it is clear that the address returned will be the address
send the mail to, but if the location-id is that of some
domain then the address returned may be either the address
send the mail to, or the address of a name server for
domain, and these two cases must be distinguished
The conclusion of this discussion was that a location-id to
name service must be defined soon. The other types of name
were not further discussed, and are not required in
implemenation
Another aspect of the name server is returning additional
besides the address. In particular, for mail it is important to
which mail procedures the destination implements (NCP/FTP, TCP/SMTP
etc.). Two approaches were discussed: one is coding the
as service names (e.g., NCP/SMTP), and the other is by reference
protocol and port numbers (e.g., PROTOCOL=6, PORT=25).
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
information was suggested that instead of (or in addition to)
this information in the name server, one should get this data
the host itself via some sort of query or "who are you" protocol
Also discussed was the initial provision for name service. It
useful to start with a text file that can be accessed via FTP, and
have both "Telnet-Like" (i.e., based on TCP) and "Datagram" (i.e.,
Postel [Page 3]
Computer Mail Meeting Notes 8 February 1982
based on UDP) access to a query server. This might be possible as
extension of the IEN-116 name server
Another issue was the central vs. distributed implementation of
name look up service. It is recognized that separate servers
each domain has administrative and maintenance advantages, but that
central server may be a useful first step. It is also
that each distinct database should be replicated a few times and
avialiable from distinct servers for robust and reliable service
An Example
Suppose that the new mailbox specification is of the
USER@HOST.ORG.DOMAIN
e.g., Postel@F.ISI.
A source host sending mail to this address first queries a
server for the domain IN (giving the whole location "F.ISI.IN").
The result of the query is either (1) the final address of
destination host (F.ISI), or (2) the address of a name server
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
2, the source host queries the ISI name server and ... (
call to this paragraph).
Action Items
RFC 733
To include the hierarchial host and domain naming procedure,
to delete the features decommitted at the Computer Mail meeting
10-JAN-79.
By: Dave
Due: 15-Feb-82
Host Name Server
To specify a way to get name to address conversions and to
out about services offered. Also how to get info on domain names
By: Jon
Due: 15-Feb-82
Postel [Page 4]
Computer Mail Meeting Notes 8 February 1982
Transition Plan
To include new host and domain names
By: Jon
Due: 15-Feb-82
SMTP
To include new host and domain names
By: Jon
Due:
Mail System Description
How to do mail systems, including use of SMTP and Host
Server
By: Jon
Due:
Conversion of User Programs and Mailer Programs
Programs have to handle dots in the "host" field. Many
on many hosts will have to be modified to a greater or
extent. In many cases the modifications should be quite simple
By: A Cast of
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
dots throughout the ARPANET and Internet world without
recipients complaining
By: DARPA (Duane Adams
Due: 1-Mar-82
Postel [Page 5]
Computer Mail Meeting Notes 8 February 1982
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@
Ed Taft Xerox Parc Taft@Parc-Maxc (415) 494-4419
Postel [Page 6]
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
