doc: Add RFC documents

1 files changed, 627 insertions, 0 deletions

diff --git a/doc/rfc/rfc915.txt b/doc/rfc/rfc915.txt
new file mode 100644
index 0000000..2ea7102
--- /dev/null
+++ b/doc/rfc/rfc915.txt
@@ -0,0 +1,627 @@
+
+
+Network Working Group                                       Marc A. Elvy
+Request for Comments: 915                             Harvard University
+                                                             Rudy Nedved
+                                              Carnegie-Mellon University
+                                                           December 1984
+
+                       NETWORK MAIL PATH SERVICE
+
+
+STATUS OF THIS MEMO
+
+   This RFC proposes a new service for the ARPA-Internet community and
+   requests discussion and suggestions for improvements.  Distribution
+   of this memo is unlimited.
+
+INTRODUCTION
+
+   The network mail path service fills the current need of people to
+   determine mailbox addresses for hosts that are not part of the
+   ARPA-Internet but can be reached by one or more relay hosts that have
+   Unix To Unix Copy (UUCP) mail, CSNET mail, MAILNET mail, BITNET mail,
+   etc.
+
+   Anyone can use the service if they have TCP/TELNET to one of the
+   hosts with a mail path server.
+
+DISCUSSION
+
+   Currently many hosts that are not connected to the ARPA-Internet
+   network can send mail to and receive mail from the ARPA-Internet
+   community.  The ARPA-Internet community sends mail using mailbox
+   addresses of the form "user@host" or "local-part@domain" [1, 5].  In
+   an effort to provide service to hosts not connected directly to the
+   ARPA-Internet, mail maintainers have used the feature that the
+   "local-part" of the mailbox address is locally interpreted to imbed
+   specially encoded mail routing or relaying information.  These
+   encoded mailbox addresses have a variety of forms and have become
+   common practice. For example:
+
+      demco%ucb-ean.cdn%ubc.csnet@CSNET-RELAY.ARPA
+
+      "Rudy.Nedved%CMCCTE@CARNEGIE.MAILNET"@MIT-MULTICS.ARPA
+
+      ihnp4!cmucsg!ern@UT-SALLY.ARPA
+
+      mss.dartmouth@CSNET-RELAY.ARPA
+
+      nedved%CMCCTF.BITNET@WISCVM.ARPA
+
+   It is important that people be able to communicate, but it is clear
+   from the rampant confusion and frustration that something must be
+
+
+Elvy & Nedved                                                   [Page 1]
+
+
+
+RFC 915                                                       Month Year
+Network Mail Path Service
+
+
+   provided to make it easier for people to address mail to
+   non-ARPA-Internet hosts.  The result, for a variety of reasons, has
+   been the work and development of the Domain Name system and
+   facilities [2, 3, 7, 9], and it is expected to make mailbox addresses
+   be as simple as the current ARPA-Internet mailbox format (e.g.,
+   "user@domain").
+
+   How do people discover the special encoded addresses for
+   non-ARPA-Internet host mailboxes until the domain name system is
+   working and covering the majority of hosts in the mail world?  The
+   proposed solution to this problem is to provide a network service for
+   the ARPA-Internet and a mail service for the non-ARPA-Internet hosts
+   that, given a host and an optional addressing system or communication
+   protocol or some other piece of information, supplies the mailbox
+   address format for sending mail to that host.  For example,
+   "nedved@Carnegie.MAILNET" would be translated by the server to
+   "nedved%Carnegie.MAILNET@MIT-MULTICS.ARPA". This memo covers the
+   proposed network service.
+
+DOCUMENT CONVENTIONS
+
+   Unless otherwise noted, all numbers are in decimal.
+
+   The term "host", as used in this document, describes one computer
+   system which may have more than one name associated with it. It may
+   have a name for each network or mail connection it supports and may
+   have several nicknames or aliases for the computer and/or for each
+   set of network names that the computer has acquired.
+
+OVERVIEW
+
+   The network service is a connection based application on TCP [4].  A
+   server listens for TCP connections on the assigned port of 117 [8].
+   It responds to the connection with a coded greeting message and waits
+   for a command line. For each command line sent to the server, the
+   server will respond with a coded message.  The special command QUIT
+   causes the server to respond with a coded closing message and closes
+   the connection.
+
+
+
+
+
+
+
+
+
+
+
+Elvy & Nedved                                                   [Page 2]
+
+
+
+RFC 915                                                       Month Year
+Network Mail Path Service
+
+
+DESIGN GOALS
+
+   One of the goals is to provide the service to as many ARPA-Internet
+   hosts as possible. In the current ARPA-Internet, experience has shown
+   that software people first implement TELNET/TCP [6] before any other
+   network application or protocol. Therefore, it is a sub-goal that
+   people be able to access the service using available programs (with
+   minimal modifications) that implement TELNET/TCP.  Therefore,
+   TELNET/TCP on port 117 will work correctly.  The server understands
+   TELNET options but refuses all option negotiations that disagree with
+   the NVT characteristics defined by the TELNET protocol (see [6]),
+   does not echo, and expects command lines to end with <CRLF> (ASCII
+   code 13 (octal 15) followed by code 10 (octal 12)).  Character
+   echoing and line editing is expected to be handled by the user host
+   for the benefit of the user.
+
+   Mail systems and other programs are also expected to be able to
+   access and understand the service.  Each command reply can have
+   multiple line responses with text understandable by the novice user.
+   Each command is encoded so as to make it easy for a program to parse
+   the lines and extract interesting information, such as whether the
+   operation was successful.
+
+THE PROTOCOL
+
+   Given the developing nature of the protocol and its intent, the
+   command lines are composed of a command (case ignored) followed by
+   white space, the argument(s) and a <CRLF>. The white space is
+   required if any arguments are supplied but the arguments are
+   optional.  White space following the command and any optional
+   arguments are ignored.
+
+      <cmdline> := <cmd> [<WS> <args>] [<WS>] <CRLF>
+
+      <WS> := [<WS>] <WS> | <TAB> | <SPACE>
+
+   Coded response lines have the rigid format of a 3-digit decimal code
+   followed by a space or a dash followed by text composed of characters
+   within the ASCII range 32 to 126 (octal 40 to 176) with <CRLF> at the
+   end of the line.  The dash after the 3-digit code indicates at least
+   one more response line will be supplied while the space indicates the
+   current response line is the last one.
+
+      <rspline> := <digit><digit><digit><cont><rtext><CRLF>
+
+      <cont> := <SPACE> | "-"
+
+
+
+Elvy & Nedved                                                   [Page 3]
+
+
+
+RFC 915                                                       Month Year
+Network Mail Path Service
+
+
+      <rtext> := ASCII characters in the range 32 to 126.
+
+   Some of the successful response text to certain commands have rigid
+   formats so programs can extract path information. The commands that
+   have format restrictions are clearly noted and the response format is
+   documented with the command.
+
+   The response codes are in the range from 200 to 599 inclusively. The
+   following paragraphs provide the break down for each digit.
+
+   The first, most significant, digit is the success indicator. It
+   breaks down into the simple success and total failure responses but
+   includes the ability to communicate a temporary failure condition and
+   the need for further information that has worked so well for SMTP [5]
+   and other similiar protocols.  The codes are:
+
+      2xx  Positive reply.
+
+      3xx  Intermedate reply. Positive acknowlegement but more
+           information is neccessary.
+
+      4xx  Temporary error. Try again later.
+
+      5xx  Permanent error. Do not retry.
+
+   The second digit is used to classify the response to provide a flavor
+   for certain types of success. The flavor is apparent in providing the
+   response on whether a host name is known by a domain name server or
+   not. The codes are:
+
+      x0x  Command related response.
+
+      x1x  Connection related response.
+
+      x2x  Database related response.
+
+      x3x  Domain transition related response.
+
+      x4x  Data added response.
+
+      x5x  Data deleted response.
+
+      x6x  Data modified response.
+
+
+
+
+
+
+Elvy & Nedved                                                   [Page 4]
+
+
+
+RFC 915                                                       Month Year
+Network Mail Path Service
+
+
+BASIC IMPLEMENTATION
+
+   The minimum implementation is the support of three commands: HELP,
+   PATH and QUIT. The HELP command provides some level of documentation
+   and possibly lists the known addressing or communication protocols.
+   The PATH command takes as a required argument a user name or id
+   followed by a "@", followed by a domain style host name whose domain
+   components may be an addressing protocol, a communication
+   environment, or an unofficial or colloquial domain.
+
+      S: (server listens on port 117)
+      U: (user connects to port 117)
+      S: 210-Welcome to the CMU network mail path service.
+      S: 210 Type 'HELP' for help.
+      U: help
+      S: 200-The server currently knows about the following mail worlds:
+      S: 200-    BITNET,UUCP,CSNET,.AC.UK,EARNET,JANET,CDNNET
+      S: 200-Use the PATH command with "user@host.world" to get the
+      S: 200 ARPA-Internet mail address.
+      U: path root@inria.uucp
+      S: 220 philabs!mcvax!inria!root@SEISMO.ARPA
+      U: quit
+      S: 211 Bye bye.
+      S: (server closes connection)
+
+DETAILED PROTOCOL DESCRIPTION
+
+   The protocol is designed to provide a flexible but conservative
+   mechanism for providing responses and adding experimental or extended
+   commands.
+
+      <user connects to server>
+
+         The server responds with a message indicating the status of the
+         server and optional information.
+
+            210  Greeting message indicating the server is ready.
+
+            410  The server is down for some unknown reason for a short
+                 time.
+
+            510  The server is unavailable.
+
+      HELP [<arg>]
+
+         The server can respond with general help information about the
+         server, about the specific topic described by "arg", or it can
+
+
+Elvy & Nedved                                                   [Page 5]
+
+
+
+RFC 915                                                       Month Year
+Network Mail Path Service
+
+
+         indicate that something is temporarily wrong with the HELP
+         facility.  It is strongly recomended that the general HELP
+         command documentation be implemented and expanded.
+
+            200  General or specific documentation given.
+
+            220  Documentation given from a database.
+
+            421  Service temporarily unavailable.
+
+            501  Command not implemented or topic not known.
+
+      PATH <user>@<host>
+
+         The server normally responds with either the mail path that
+         will work for the given mailbox address or indicates the domain
+         style host name is unknown. If the database is in transition or
+         inconsistent, a temporary or permanent error can be supplied.
+
+            220  Rigid format route given.
+
+            230  Rigid format route given. Domain servers should be
+                 used.
+
+            420  Database problems. Try again later.
+
+            501  Invalid argument form or null argument given.
+
+            520  No such host found in database.
+
+            521  Host name is ambiguous.
+
+      When a route is supplied with the 2xx success responses. It has a
+      fixed format with a one-line response. The format is as follows:
+
+         <3-digit-code><SP><local-part>@<domain><CRLF>
+
+      The "local-part" and "domain" components are defined under the
+      SMTP protocol [5] and are intended to be used over SMTP
+      connections.
+
+      QUIT
+
+         Respond and close the server down.
+
+            211  Close the connection down.
+
+
+
+Elvy & Nedved                                                   [Page 6]
+
+
+
+RFC 915                                                       Month Year
+Network Mail Path Service
+
+
+   One special code is reserved and is used for a special case. The code
+   is 412 and is sent when the server has been waiting for a response
+   for more then 2 minutes and has decided to timeout the connection.
+   After the "412 <timeout msg>" is sent, the server may close or
+   possibly abort the connection.
+
+   Because of the somewhat experimental nature of the server, additional
+   commands are expected to be added as they become needed. No
+   restrictions are placed on the names of these experimental commands
+   other then the must not conflict with the basic commands and are not
+   allowed to be abbreviated (i.e., "SEAR" can not be used for
+   "SEARCH").
+
+PATH COMMAND ARGUMENTS
+
+   It is important to understand that the server is an aid to users that
+   may have minimal amount of information about the host. Therefore the
+   PATH command takes domain style host names that may be complete or
+   incomplete specifications for the host and may be common or
+   colloquial domain names. The servers look through the entire database
+   for anything that matches and try to find the best answer
+   disregarding any local domain information.  If several hosts have the
+   same nickname or alias and lack distinguishing domain components, the
+   server returns an error response containing all of the hosts found.
+   Some implementation may even break down the host name and indicate in
+   error messages that even though it did not find the host, it found
+   something else that might be what the user wanted.
+
+MAIL PATH SERVICE AND DOMAINS
+
+   As mentioned previously, the mail path service is not intended to be
+   a replacement or a parallel service to the domain name system.  It is
+   a stop gap measure and, when most of the domain name system is in
+   place, will probably be disabled on some or most of the hosts with
+   the service.
+
+   Mail systems should check the domain name servers for the specified
+   host before trying a mail path server. The mail path servers should
+   be modified when one or more domain servers are in place to check if
+   a host is part of the domain system and to generate an error or an
+   indication (but still include the path information) if a host is
+   found to be a part of the domain system.
+
+   The names used by the mail path servers have no official standing in
+   the ARPA-Internet community and have colloquial origins. The domain
+   name components are based on the adminstrative entities involved
+   whereas many of the current unofficial common domain style names for
+
+
+Elvy & Nedved                                                   [Page 7]
+
+
+
+RFC 915                                                       Month Year
+Network Mail Path Service
+
+
+   non-ARPA-Internet hosts are based on the protocol used, the relay
+   host used, or some acronym that someone dreamed up.  Only a few of
+   the current domain style names that are privately in use are expected
+   to be used by the ARPA-Internet community when the domain name
+   service is in use by the majority of the ARPA-Internet community.
+
+CAVEATS
+
+   The greatest problem with the new service, as implemented, is that it
+   reports paths from the service host rather than from the user's host.
+   This is due to the nature of software.  It would be more convenient
+   if it reported a correct path from the caller's host, but this would
+   require a different method of database management (a method which
+   could quickly compute the path from the caller's machine or a machine
+   which would be willing to keep updated databases for each host (which
+   is impractical)).
+
+   Two minor problems exist with the database used by the software. Many
+   relay hosts exist in several different protocol or addressing name
+   spaces but under different names. The current software cross
+   referencing for the multiple protocol relay hosts is done by hand,
+   but, given the seeming reliability of these relay hosts, the problem
+   does not appear to be significant.  The second problem is that the
+   data should be collected from the actual relay hosts to ensure
+   correctness, but in many cases this is impossible.
+
+EXAMPLES
+
+   Find a route to CMU-CC-TE in the CARNEGIE part of MAILNET for user id
+   EN0C:
+
+      S: (server listens on port 117)
+      U: (user connects to port 117)
+      S: 210-Welcome to the CMU network mail path service
+      S: 210 Type 'HELP' for help.
+      U: path EN0C@CMU-CC-TE.CARNEGIE.MAILNET
+      S: 220 EN0C%CMU-CC-TE%CARNEGIE.MAILNET@MIT-MULTICS.ARPA
+      U: quit
+      S: 211 Bye bye.
+      S: (server closes connection)
+
+
+
+
+
+
+
+
+
+Elvy & Nedved                                                   [Page 8]
+
+
+
+RFC 915                                                       Month Year
+Network Mail Path Service
+
+
+   Find a route to a host which has an unknown addressing system or
+   communication protocol and for which the name may be an alias:
+
+      S: (server listens on port 117)
+      U: (user connects to port 117)
+      S: 210-Welcome to the CMU network mail path service
+      S: 210 Type 'HELP' for help.
+      U: path mss@dartvax
+      S: 220 mss%dartmouth@CSNET-RELAY.ARPA
+      U: quit
+      S: 211 Bye bye.
+      S: (server closes connection)
+
+   Find a route to a host that is known by a very long domain style name
+   but is not in the current ARPA-Internet host tables:
+
+      S: (server listens on port 117)
+      U: (user connects to port 117)
+      S: 210-Welcome to the CMU network mail path service
+      S: 210 Type 'HELP' for help.
+      U: path rob@vax1.cent.lanc.ac.uk
+      S: 220 rob%vax1.cent.lanc@UCL-CS.ARPA
+      U: quit
+      S: 211 Bye bye.
+      S: (server closes connection)
+
+   Find a route to a host without any additional information and the
+   name is discovered to be ambiguous:
+
+      S: (server listens on port 117)
+      U: (user connects to port 117)
+      S: 210-Welcome to the CMU network mail path service
+      S: 210 Type 'HELP' for help.
+      U: path brad@pitt
+      S: 521-Several hosts found under the name of 'pitt', try one of:
+      S: 521-brad@pitt.UUCP
+      S: 521-brad@pitt.CSNET
+      U: path brad@pitt.CSNET
+      S: 220 brad%pitt@CSNET-RELAY.ARPA
+      U: quit
+      S: 211 Bye bye.
+      S: (server closes connection)
+
+
+
+
+
+
+
+Elvy & Nedved                                                   [Page 9]
+
+
+
+RFC 915                                                       Month Year
+Network Mail Path Service
+
+
+ACKNOWLEDGEMENTS
+
+   The original protocol was documented by Marc Elvy for a server that
+   he and Alan Langerman built.  The server used the pathalias software
+   created by Steve Bellovin, as modified by Peter Honeyman and Robert
+   T. Morris, to maintain the host to host connection database.  The
+   software provided a way for people to make sense out of the jungle of
+   UUCP hosts. The Info-Nets@MIT-MC mailing list, created and maintained
+   by Robert Krawitz, made the CMU and Harvard mail path projects aware
+   of each other and the people on the list provided many of the mail
+   relay databases that are in use by the mail path servers.  The
+   original server may be accessed through TCP port 117 on harvard.arpa
+   -- the "pathto" program that runs under 4.2BSD UNIX may be obtained
+   as a front end to the server from RFC915@HARVARD.ARPA.
+
+   The current protocol scope was changed by Rudy Nedved to cover
+   BITNET, CSNET, MAILNET and other "mail networks" and further refined
+   by Marc Elvy, Alan Langerman and others.
+
+   Comments should be sent to RFC-915@HARVARD.ARPA or mailed (via the
+   U.S.  Postal Service) to:
+
+      Marc A. Elvy
+      108 Aiken Computation Laboratory
+      33 Oxford Street
+      Harvard University
+      Cambridge, MA 02138
+
+      (617) 495-5849
+
+      Rudy Nedved
+      Department of Computer Science
+      Carnegie-Mellon University
+      Schenley Park
+      Pittsburgh, PA 15213
+
+      (412) 578-7685
+
+
+
+
+
+
+
+
+
+
+
+
+Elvy & Nedved                                                  [Page 10]
+
+
+
+RFC 915                                                       Month Year
+Network Mail Path Service
+
+
+REFERENCES
+
+   [1]   Crocker, D. "Standard for the Format of ARPA Internet Text
+         Messages". RFC 822, Department of Electrical Engineering,
+         University of Delaware, August, 1982.
+
+   [2]   Mockapetris, P. "Domain Names - Concepts and Facilities".
+         RFC 882, USC/Information Sciences Institute, Novemeber, 1983.
+
+   [3]   Mockapetris, P. "Domain Names - Implementation Specification".
+         RFC 883, USC/Information Sciences Institute, Novemeber, 1983.
+
+   [4]   Postel, J. "Transmission Control Protocol- DARPA Internet
+         Program Protocol Specification". RFC 793, USC/Information
+         Sciences Institute, September, 1981.
+
+   [5]   Postel, J. "Simple Mail Transfer Prootcol". RFC 821,
+         USC/Information Sciences Institute, August, 1982.
+
+   [6]   Postel, J., and J. Reynolds. "Telnet Protocol Specification".
+         RFC 854, USC/Information Sciences Institute, May, 1983.
+
+   [7]   Postel, J. "Domain Name System Implementation Schedule".
+         RFC 897, USC/Information Sciences Institute, Feburary, 1984.
+
+   [8]   Reynolds, J., and J. Postel. "Assigned Numbers". RFC 923,
+         USC/Information Sciences Institute, October, 1984.
+
+   [9]   Su, Z., and Postel, J. "The Domain Naming Convention for
+         Internet User Applications". RFC 819, SRI International,
+         August, 1982.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elvy & Nedved                                                  [Page 11]
+