doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

diff --git a/doc/rfc/rfc953.txt b/doc/rfc/rfc953.txt
new file mode 100644
index 0000000..a083409
--- /dev/null
+++ b/doc/rfc/rfc953.txt
@@ -0,0 +1,283 @@
+Network Working Group                               K. Harrenstien (SRI)
+Request for Comments: 953                                 M. Stahl (SRI)
+Obsoletes:  RFC 811                                     E. Feinler (SRI)
+                                                            October 1985
+
+                            HOSTNAME SERVER
+
+
+STATUS OF THIS MEMO
+
+   This RFC is the official specification of the Hostname Server
+   Protocol.  This edition of the specification includes minor revisions
+   to RFC 811 which brings it up to date.  Distribution of this memo is
+   unlimited.
+
+INTRODUCTION
+
+   The NIC Internet Hostname Server is a TCP-based host information
+   program and protocol running on the SRI-NIC machine.  It is one of a
+   series of internet name services maintained by the DDN Network
+   Information Center (NIC) at SRI International on behalf of the
+   Defense Communications Agency (DCA).  The function of this particular
+   server is to deliver machine-readable name/address information
+   describing networks, gateways, hosts, and eventually domains, within
+   the internet environment.  As currently implemented, the server
+   provides the information outlined in the DoD Internet Host Table
+   Specification [See RFC-952].  For a discussion of future developments
+   see also RFC-921 concerning the Domain Name System.
+
+PROTOCOL
+
+   To access this server from a program, establish a TCP connection to
+   port 101 (decimal) at the service host, SRI-NIC.ARPA (26.0.0.73 or
+   10.0.0.51).  Send the information request (a single line), and read
+   the resulting response.  The connection is closed by the server upon
+   completion of the response, so only one request can be made for each
+   connection.
+
+QUERY/RESPONSE FORMAT
+
+   The name server accepts simple text query requests of the form
+
+      <command key> <argument(s)> [<options>]
+
+   where square brackets ("[]") indicate an optional field.  The command
+   key is a keyword indicating the nature of the request.  The defined
+   keys are explained below.
+
+   The response, on the other hand, is of the form
+
+      <response key> : <rest of response>
+
+
+Harrenstien & Stahl & Feinler                                   [Page 1]
+
+
+
+RFC 953                                                     October 1985
+Hostname Server
+
+
+   where <response key> is a keyword indicating the nature of the
+   response, and the rest of the response is interpreted in the context
+   of the key.
+
+   NOTE:  Care should be taken to interpret the nature of the reply
+   (e.g, single record or multiple record), so that no confusion about
+   the state of the reply results.  An "ALL" request will likely return
+   several hundred or more records of all types, whereas "HNAME" or
+   "HADDR" will usually return one HOST record.
+
+COMMAND/RESPONSE KEYS
+
+   The currently defined command keywords are listed below.  NOTE:
+   Because the server and the features available will evolve with time,
+   the HELP command should be used to obtain the most recent summary of
+   implemented features, changes, or new commands.
+
+      Keyword   Response
+
+      HELP      This information.
+
+      VERSION   "VERSION: <string>" where <string> will be different for
+                each version of the host table.
+
+      HNAME <hostname>
+                One or more matching host table entries.
+
+      HADDR <hostaddr>
+                One or more matching host table entries.
+
+      ALL       The entire host table.
+
+      ALL-OLD   The entire host table without domain style names.
+
+      DOMAINS   The entire top-level domain table (domains only).
+
+      ALL-DOM   Both the entire domain table and the host table.
+
+      ALL-INGWAY
+                All known gateways in TENEX/TOPS-20 INTERNET.GATEWAYS
+                format.
+
+   Remember that the server accepts only a single command line and
+   returns only a single response before closing the connection.  HNAME
+   and HADDR are useful for looking up a specific host by name or
+   address; VERSION can be used by automated processes to see whether a
+   "new" version of the host table exists without having to transfer the
+
+
+Harrenstien & Stahl & Feinler                                   [Page 2]
+
+
+
+RFC 953                                                     October 1985
+Hostname Server
+
+
+   whole table.  Note, however, that the returned version string is only
+   guaranteed to be unique to each version, and nothing should currently
+   be assumed about its format.
+
+   Response Keys:
+
+      ERR       entry not found, nature of error follows
+      NET       entry found, rest of entry follows
+      GATEWAY   entry found, rest of entry follows
+      HOST      entry found, rest of entry follows
+      DOMAIN    entry found, rest of entry follows
+      BEGIN     followed by multiple entries
+      END       done with BEGIN block of entries
+
+   More keywords will be added as new needs are recognized.  A more
+   detailed description of the allowed requests/responses follows.
+
+QUERY/RESPONSE EXAMPLES
+
+   1. HNAME Query - Given a name, find the entry or entries that match
+   the name.  For example:
+
+      HNAME SRI-NIC.ARPA <CRLF>
+
+         where <CRLF> is a carriage return/ linefeed, and 'SRI-NIC.ARPA'
+         is a host name
+
+      The likely response is:
+
+      HOST : 26.0.0.73, 10.0.0.51 : SRI-NIC.ARPA,SRI-NIC,NIC :
+             DEC-2060 : TOPS20 : TCP/TELNET,TCP/SMTP,TCP/TIME,TCP/FTP,
+             TCP/ECHO,ICMP :
+
+      A response may stretch across more than one line.  Continuation
+      lines always begin with at least one space.
+
+   2. HADDR Query - Given an internet address (as specified in RFC 796)
+   find the entry or entries that match that address. For example:
+
+      HADDR 26.0.0.73 <CRLF>
+
+         where <CRLF> is a carriage return/ linefeed, and '26.0.0.73' is
+         a host address.
+
+      The likely response is the same as for the previous HNAME request.
+
+
+
+
+Harrenstien & Stahl & Feinler                                   [Page 3]
+
+
+
+RFC 953                                                     October 1985
+Hostname Server
+
+
+   3. ALL Query - Deliver the entire internet host table in a
+   machine-readable form.  For example:
+
+      ALL <CRLF>   ;where <CRLF> is a carriage return/linefeed
+
+      The likely response is the keyword 'BEGIN' followed by a colon
+      ':', followed by the entire internet host table in the format
+      specified in RFC-952, followed by 'END:'.
+
+ERROR HANDLING
+
+   ERR Reply - may occur on any query, and should be permitted in any
+   access program using the name server.  Errors are of the form
+
+      ERR : <code> : <string> :
+        as in
+      ERR : NAMNFD : Name not found :
+
+   The error code is a unique descriptor, limited to 8 characters in
+   length for any given error.  It may be used by the access program to
+   identify the error and, in some cases, to handle it automatically.
+   The string is an accompanying message for a given error for that case
+   where the access program simply logs the error message.  Current
+   codes and their associated interpretations are
+
+      NAMNFD    Name not found; name not in table
+      ADRNFD    Address not found; address not in table
+      ILLCOM    Illegal command; command key not recognized
+      TMPSYS    Temporary system failure, try again later
+
+REFERENCES
+
+   1. Harrenstien, K., Stahl, M., and Feinler, E., "Official DoD
+      Internet Host Table Specification," RFC-952, DDN Network
+      Information Center, SRI International, October 1985.
+
+   2. Pickens, J., Feinler, E., and Mathis, J., "The NIC Name Server," A
+      Datagram-based Information Utility, RFC-756, Network Information
+      Center, SRI International, July 1979.
+
+   3. Postel, J., "Address Mappings," RFC-796, Information Sciences
+      Institute, University of Southern California, Marina del Rey,
+      September 1981.
+
+   4. Postel, J., "Domain Name System Implementation Schedule", RFC-921,
+      Information Sciences Institute, University of Southern California,
+      Marina del Rey, October 1984.
+
+
+Harrenstien & Stahl & Feinler                                   [Page 4]
+
+
+
+RFC 953                                                     October 1985
+Hostname Server
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrenstien & Stahl & Feinler                                   [Page 5]
+