Purge docs/rfc from the repository.

These are of no use to 99% of users and anyone who actually wants
to read them should be capable of using Google to find them.

1 files changed, 0 insertions, 451 deletions

diff --git a/docs/rfc/rfc1413.txt b/docs/rfc/rfc1413.txt
deleted file mode 100644
index 17ede58a2..000000000
--- a/docs/rfc/rfc1413.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       M. St. Johns
-Request for Comments: 1413                      US Department of Defense
-Obsoletes: 931                                             February 1993
-
-
-                        Identification Protocol
-
-Status of this Memo
-
-   This RFC specifies an IAB standards track protocol for the Internet
-   community, and requests discussion and suggestions for improvements.
-   Please refer to the current edition of the "IAB Official Protocol
-   Standards" for the standardization state and status of this protocol.
-   Distribution of this memo is unlimited.
-
-1.  INTRODUCTION
-
-   The Identification Protocol (a.k.a., "ident", a.k.a., "the Ident
-   Protocol") provides a means to determine the identity of a user of a
-   particular TCP connection.  Given a TCP port number pair, it returns
-   a character string which identifies the owner of that connection on
-   the server's system.
-
-   The Identification Protocol was formerly called the Authentication
-   Server Protocol.  It has been renamed to better reflect its function.
-   This document is a product of the TCP Client Identity Protocol
-   Working Group of the Internet Engineering Task Force (IETF).
-
-2.  OVERVIEW
-
-   This is a connection based application on TCP.  A server listens for
-   TCP connections on TCP port 113 (decimal).  Once a connection is
-   established, the server reads a line of data which specifies the
-   connection of interest.  If it exists, the system dependent user
-   identifier of the connection of interest is sent as the reply.  The
-   server may then either shut the connection down or it may continue to
-   read/respond to multiple queries.
-
-   The server should close the connection down after a configurable
-   amount of time with no queries - a 60-180 second idle timeout is
-   recommended.  The client may close the connection down at any time;
-   however to allow for network delays the client should wait at least
-   30 seconds (or longer) after a query before abandoning the query and
-   closing the connection.
-
-
-
-
-
-
-
-St. Johns                                                       [Page 1]
-
-RFC 1413                Identification Protocol            February 1993
-
-
-3.  RESTRICTIONS
-
-   Queries are permitted only for fully specified connections.  The
-   query contains the local/foreign port pair -- the local/foreign
-   address pair used to fully specify the connection is taken from the
-   local and foreign address of query connection.  This means a user on
-   address A may only query the server on address B about connections
-   between A and B.
-
-4.  QUERY/RESPONSE FORMAT
-
-   The server accepts simple text query requests of the form:
-
-            <port-on-server> , <port-on-client>
-
-   where <port-on-server> is the TCP port (decimal) on the target (where
-   the "ident" server is running) system, and <port-on-client> is the
-   TCP port (decimal) on the source (client) system.
-
-   N.B - If a client on host A wants to ask a server on host B about a
-   connection specified locally (on the client's machine) as 23, 6191
-   (an inbound TELNET connection), the client must actually ask about
-   6191, 23 - which is how the connection would be specified on host B.
-
-      For example:
-
-                 6191, 23
-
-   The response is of the form
-
-   <port-on-server> , <port-on-client> : <resp-type> : <add-info>
-
-   where <port-on-server>,<port-on-client> are the same pair as the
-   query, <resp-type> is a keyword identifying the type of response, and
-   <add-info> is context dependent.
-
-   The information returned is that associated with the fully specified
-   TCP connection identified by <server-address>, <client-address>,
-   <port-on-server>, <port-on-client>, where <server-address> and
-   <client-address> are the local and foreign IP addresses of the
-   querying connection -- i.e., the TCP connection to the Identification
-   Protocol Server.  (<port-on-server> and <port-on-client> are taken
-   from the query.)
-
-      For example:
-
-         6193, 23 : USERID : UNIX : stjohns
-         6195, 23 : ERROR : NO-USER
-
-
-
-St. Johns                                                       [Page 2]
-
-RFC 1413                Identification Protocol            February 1993
-
-
-5.  RESPONSE TYPES
-
-A response can be one of two types:
-
-USERID
-
-     In this case, <add-info> is a string consisting of an
-     operating system name (with an optional character set
-     identifier), followed by ":", followed by an
-     identification string.
-
-     The character set (if present) is separated from the
-     operating system name by ",".  The character set
-     identifier is used to indicate the character set of the
-     identification string.  The character set identifier,
-     if omitted, defaults to "US-ASCII" (see below).
-
-     Permitted operating system names and character set
-     names are specified in RFC 1340, "Assigned Numbers" or
-     its successors.
-
-     In addition to those operating system and character set
-     names specified in "Assigned Numbers" there is one
-     special case operating system identifier - "OTHER".
-
-     Unless "OTHER" is specified as the operating system
-     type, the server is expected to return the "normal"
-     user identification of the owner of this connection.
-     "Normal" in this context may be taken to mean a string
-     of characters which uniquely identifies the connection
-     owner such as a user identifier assigned by the system
-     administrator and used by such user as a mail
-     identifier, or as the "user" part of a user/password
-     pair used to gain access to system resources.  When an
-     operating system is specified (e.g., anything but
-     "OTHER"), the user identifier is expected to be in a
-     more or less immediately useful form - e.g., something
-     that could be used as an argument to "finger" or as a
-     mail address.
-
-     "OTHER" indicates the identifier is an unformatted
-     character string consisting of printable characters in
-     the specified character set.  "OTHER" should be
-     specified if the user identifier does not meet the
-     constraints of the previous paragraph.  Sending an
-     encrypted audit token, or returning other non-userid
-     information about a user (such as the real name and
-     phone number of a user from a UNIX passwd file) are
-
-
-
-St. Johns                                                       [Page 3]
-
-RFC 1413                Identification Protocol            February 1993
-
-
-     both examples of when "OTHER" should be used.
-
-     Returned user identifiers are expected to be printable
-     in the character set indicated.
-
-     The identifier is an unformatted octet string - - all
-     octets are permissible EXCEPT octal 000 (NUL), 012 (LF)
-     and 015 (CR).  N.B. - space characters (040) following the
-     colon separator ARE part of the identifier string and
-     may not be ignored. A response string is still
-     terminated normally by a CR/LF.  N.B. A string may be
-     printable, but is not *necessarily* printable.
-
-ERROR
-
-   For some reason the port owner could not be determined, <add-info>
-   tells why.  The following are the permitted values of <add-info> and
-   their meanings:
-
-          INVALID-PORT
-
-          Either the local or foreign port was improperly
-          specified.  This should be returned if either or
-          both of the port ids were out of range (TCP port
-          numbers are from 1-65535), negative integers, reals or
-          in any fashion not recognized as a non-negative
-          integer.
-
-          NO-USER
-
-          The connection specified by the port pair is not
-          currently in use or currently not owned by an
-          identifiable entity.
-
-          HIDDEN-USER
-
-          The server was able to identify the user of this
-          port, but the information was not returned at the
-          request of the user.
-
-          UNKNOWN-ERROR
-
-          Can't determine connection owner; reason unknown.
-          Any error not covered above should return this
-          error code value.  Optionally, this code MAY be
-          returned in lieu of any other specific error code
-          if, for example, the server desires to hide
-          information implied by the return of that error
-
-
-
-St. Johns                                                       [Page 4]
-
-RFC 1413                Identification Protocol            February 1993
-
-
-          code, or for any other reason.  If a server
-          implements such a feature, it MUST be configurable
-          and it MUST default to returning the proper error
-          message.
-
-   Other values may eventually be specified and defined in future
-   revisions to this document.  If an implementer has a need to specify
-   a non-standard error code, that code must begin with "X".
-
-   In addition, the server is allowed to drop the query connection
-   without responding.  Any premature close (i.e., one where the client
-   does not receive the EOL, whether graceful or an abort should be
-   considered to have the same meaning as "ERROR : UNKNOWN-ERROR".
-
-FORMAL SYNTAX
-
-   <request> ::= <port-pair> <EOL>
-
-   <port-pair> ::= <integer> "," <integer>
-
-   <reply> ::= <reply-text> <EOL>
-
-   <EOL> ::= "015 012"  ; CR-LF End of Line Indicator
-
-   <reply-text> ::= <error-reply> | <ident-reply>
-
-   <error-reply> ::= <port-pair> ":" "ERROR" ":" <error-type>
-
-   <ident-reply> ::= <port-pair> ":" "USERID" ":" <opsys-field>
-                     ":" <user-id>
-
-   <error-type> ::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR"
-                    | "HIDDEN-USER" |  <error-token>
-
-   <opsys-field> ::= <opsys> [ "," <charset>]
-
-   <opsys> ::= "OTHER" | "UNIX" | <token> ...etc.
-               ;  (See "Assigned Numbers")
-
-   <charset> ::= "US-ASCII" | ...etc.
-                 ;  (See "Assigned Numbers")
-
-   <user-id> ::= <octet-string>
-
-   <token> ::= 1*64<token-characters> ; 1-64 characters
-
-   <error-token> ::= "X"1*63<token-characters>
-                     ; 2-64 chars beginning w/X
-
-
-
-St. Johns                                                       [Page 5]
-
-RFC 1413                Identification Protocol            February 1993
-
-
-   <integer> ::= 1*5<digit> ; 1-5 digits.
-
-   <digit> ::= "0" | "1" ... "8" | "9" ; 0-9
-
-   <token-characters> ::=
-                  <Any of these ASCII characters: a-z, A-Z,
-                   - (dash), .!@#$%^&*()_=+.,<>/?"'~`{}[]; >
-                               ; upper and lowercase a-z plus
-                               ; printables minus the colon ":"
-                               ; character.
-
-   <octet-string> ::= 1*512<octet-characters>
-
-   <octet-characters> ::=
-                  <any octet from  00 to 377 (octal) except for
-                   ASCII NUL (000), CR (015) and LF (012)>
-
-Notes on Syntax:
-
-   1)   To promote interoperability among variant
-        implementations, with respect to white space the above
-        syntax is understood to embody the "be conservative in
-        what you send and be liberal in what you accept"
-        philosophy.  Clients and servers should not generate
-        unnecessary white space (space and tab characters) but
-        should accept white space anywhere except within a
-        token.  In parsing responses, white space may occur
-        anywhere, except within a token.  Specifically, any
-        amount of white space is permitted at the beginning or
-        end of a line both for queries and responses.  This
-        does not apply for responses that contain a user ID
-        because everything after the colon after the operating
-        system type until the terminating CR/LF is taken as
-        part of the user ID.  The terminating CR/LF is NOT
-        considered part of the user ID.
-
-   2)   The above notwithstanding, servers should restrict the
-        amount of inter-token white space they send to the
-        smallest amount reasonable or useful.  Clients should
-        feel free to abort a connection if they receive 1000
-        characters without receiving an <EOL>.
-
-   3)   The 512 character limit on user IDs and the 64
-        character limit on tokens should be understood to mean
-        as follows: a) No new token (i.e., OPSYS or ERROR-TYPE)
-        token will be defined that has a length greater than 64
-        and b) a server SHOULD NOT send more than 512 octets of
-        user ID and a client MUST accept at least 512 octets of
-
-
-
-St. Johns                                                       [Page 6]
-
-RFC 1413                Identification Protocol            February 1993
-
-
-        user ID.  Because of this limitation, a server MUST
-        return the most significant portion of the user ID in
-        the first 512 octets.
-
-   4)   The character sets and character set identifiers should
-        map directly to those defined in or referenced by RFC 1340,
-        "Assigned Numbers" or its successors.  Character set
-        identifiers only apply to the user identification field
-        - all other fields will be defined in and must be sent
-        as US-ASCII.
-
-   5)   Although <user-id> is defined as an <octet-string>
-        above, it must follow the format and character set
-        constraints implied by the <opsys-field>; see the
-        discussion above.
-
-   6)   The character set provides context for the client to
-        print or store the returned user identification string.
-        If the client does not recognize or implement the
-        returned character set, it should handle the returned
-        identification string as OCTET, but should in addition
-        store or report the character set.  An OCTET string
-        should be printed, stored or handled in hex notation
-        (0-9a-f) in addition to any other representation the
-        client implements - this provides a standard
-        representation among differing implementations.
-
-6.  Security Considerations
-
-   The information returned by this protocol is at most as trustworthy
-   as the host providing it OR the organization operating the host.  For
-   example, a PC in an open lab has few if any controls on it to prevent
-   a user from having this protocol return any identifier the user
-   wants.  Likewise, if the host has been compromised the information
-   returned may be completely erroneous and misleading.
-
-   The Identification Protocol is not intended as an authorization or
-   access control protocol.  At best, it provides some additional
-   auditing information with respect to TCP connections.  At worst, it
-   can provide misleading, incorrect, or maliciously incorrect
-   information.
-
-   The use of the information returned by this protocol for other than
-   auditing is strongly discouraged.  Specifically, using Identification
-   Protocol information to make access control decisions - either as the
-   primary method (i.e., no other checks) or as an adjunct to other
-   methods may result in a weakening of normal host security.
-
-
-
-
-St. Johns                                                       [Page 7]
-
-RFC 1413                Identification Protocol            February 1993
-
-
-   An Identification server may reveal information about users,
-   entities, objects or processes which might normally be considered
-   private.  An Identification server provides service which is a rough
-   analog of the CallerID services provided by some phone companies and
-   many of the same privacy considerations and arguments that apply to
-   the CallerID service apply to Identification.  If you wouldn't run a
-   "finger" server due to privacy considerations you may not want to run
-   this protocol.
-
-7.  ACKNOWLEDGEMENTS
-
-   Acknowledgement is given to Dan Bernstein who is primarily
-   responsible for renewing interest in this protocol and for pointing
-   out some annoying errors in RFC 931.
-
-References
-
-   [1] St. Johns, M., "Authentication Server", RFC 931, TPSC, January
-       1985.
-
-   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
-       USC/Information Sciences Institute, July 1992.
-
-Author's Address
-
-       Michael C. St. Johns
-       DARPA/CSTO
-       3701 N. Fairfax Dr
-       Arlington, VA 22203
-
-       Phone: (703) 696-2271
-       EMail: stjohns@DARPA.MIL
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-St. Johns                                                       [Page 8]
-
\ No newline at end of file