From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc805.txt | 348 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 348 insertions(+) create mode 100644 doc/rfc/rfc805.txt (limited to 'doc/rfc/rfc805.txt') diff --git a/doc/rfc/rfc805.txt b/doc/rfc/rfc805.txt new file mode 100644 index 0000000..d47a3a5 --- /dev/null +++ b/doc/rfc/rfc805.txt @@ -0,0 +1,348 @@ + + +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 + + +Postel [Page 1] + + + +Computer Mail Meeting Notes 8 February 1982 + + + 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. + + + + +Postel [Page 2] + + + +Computer Mail Meeting Notes 8 February 1982 + + + 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., + + + +Postel [Page 3] + + + +Computer Mail Meeting Notes 8 February 1982 + + + 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 + + + + +Postel [Page 4] + + + +Computer Mail Meeting Notes 8 February 1982 + + + 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 + + + + + + + +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@UWisc + Ed Taft Xerox Parc Taft@Parc-Maxc (415) 494-4419 + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 6] + -- cgit v1.2.3