doc: Add RFC documents

1 files changed, 2299 insertions, 0 deletions

diff --git a/doc/rfc/rfc1835.txt b/doc/rfc/rfc1835.txt
new file mode 100644
index 0000000..e7e68b6
--- /dev/null
+++ b/doc/rfc/rfc1835.txt
@@ -0,0 +1,2299 @@
+
+
+
+
+
+
+Network Working Group                                         P. Deutsch
+Request for Comments: 1835              BUNYIP INFORMATION SYSTEMS, Inc.
+Category: Standards Track                                    R. Schoultz
+                                                                  KTHNOC
+                                                            P. Faltstrom
+                                        BUNYIP INFORMATION SYSTEMS, Inc.
+                                                               C. Weider
+                                        BUNYIP INFORMATION SYSTEMS, Inc.
+                                                             August 1995
+
+
+                  Architecture of the WHOIS++ service
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document describes WHOIS++, an extension to the trivial WHOIS
+   service described in RFC 954 to permit WHOIS-like servers to make
+   available more structured information to the Internet.  We describe
+   an extension to the simple WHOIS data model and query protocol and a
+   companion extensible, distributed indexing service.  A number of
+   options have also been added such as the use of multiple languages
+   and character sets, more advanced search expressions, structured data
+   and a number of other useful features.  An optional authentication
+   mechanism for protecting all or part of the associated WHOIS++
+   information database from unauthorized access is also described.
+
+Table of Contents
+
+   Part I - WHOIS++ Overview .................................  3
+   1.1.  Purpose and Motivation ..............................  3
+   1.2.  Basic Information Model .............................  4
+   1.2.1.  Changes to the current WHOIS Model ................  5
+   1.2.2.  Registering WHOIS++ servers .......................  5
+   1.2.3.  The WHOIS++ Search Selection Mechanism ............  7
+   1.2.4.  The WHOIS++ Architecture ..........................  7
+   1.3.  Indexing in WHOIS++ .................................  8
+   1.4.  Getting Help ........................................  9
+   1.4.1.  Minimum HELP Required .............................  9
+   1.5.  Options and Constraints ............................. 10
+   1.6.  Formatting Responses ................................ 10
+
+
+
+Deutsch, et al              Standards Track                     [Page 1]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+   1.7.  Reporting Warnings and Errors ....................... 11
+   1.8.  Privacy and Security Issues ......................... 11
+   Part II - WHOIS++ Implementation .......................... 12
+   2.1.  The WHOIS++ interaction model ....................... 12
+   2.2.  The WHOIS++ Command set ............................. 12
+   2.2.1.  System Commands ................................... 13
+   2.2.1.1.  The COMMANDS command ............................ 14
+   2.2.1.2.  The CONSTRAINTS command ......................... 15
+   2.2.1.3.  The DESCRIBE command ............................ 15
+   2.2.1.4.  The HELP command ................................ 15
+   2.2.1.5.  The LIST command ................................ 15
+   2.2.1.6.  The POLLED-BY command ........................... 15
+   2.2.1.7.  The POLLED-FOR command .......................... 16
+   2.2.1.8.  The SHOW command ................................ 16
+   2.2.1.9.  The VERSION command ............................. 16
+   2.2.2.  The Search Command ................................ 16
+   2.2.2.1.  Format of a Search Term ......................... 17
+   2.2.2.2.  Format of a Search String ....................... 18
+   2.3.  WHOIS++ Constraints ................................. 19
+   2.3.1.  Required Constraints .............................. 20
+   2.3.2.  Optional CONSTRAINTS .............................. 21
+   2.3.2.1.  The SEARCH Constraint ........................... 22
+   2.3.2.2.  The FORMAT Constraint ........................... 22
+   2.3.2.3.  The MAXFULL Constraint .......................... 22
+   2.3.2.4.  The MAXHITS Constraint .......................... 23
+   2.3.2.5.  The CASE Constraint ............................. 23
+   2.3.2.6.  The AUTHENTICATE Constraint ..................... 23
+   2.3.2.7.  The NAME Constraint ............................. 23
+   2.3.2.8.  The PASSWORD Constraint ......................... 23
+   2.3.2.9.  The LANGUAGE Constraint ......................... 23
+   2.3.2.10.  The INCHARSET Constraint ....................... 24
+   2.3.2.11.  The IGNORE Constraint .......................... 24
+   2.3.2.12.  The INCLUDE Constraint ......................... 24
+   2.4.  Server Response Modes ............................... 24
+   2.4.1.  Default Responses ................................. 25
+   2.4.2.  Format of Responses ............................... 25
+   2.4.3.  Syntax of a Formatted Response .................... 26
+   2.4.3.1.  A FULL format response .......................... 26
+   2.4.3.2.  ABRIDGED Format Response ........................ 27
+   2.4.3.3.  HANDLE Format Response .......................... 27
+   2.4.3.4.  SUMMARY Format Response ......................... 27
+   2.4.3.5.  SERVERS-TO-ASK Response ......................... 28
+   2.4.4.  System Generated Messages ......................... 28
+   2.5.  Compatibility with Older WHOIS Servers .............. 29
+   3.  Miscellaneous ......................................... 29
+   3.1.  Acknowledgements .................................... 29
+   3.2.  References .......................................... 29
+   3.3.  Authors' Addresses .................................. 30
+
+
+
+Deutsch, et al              Standards Track                     [Page 2]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+   Appendix A - Some Sample Queries .......................... 31
+   Appendix B - Some sample responses ........................ 31
+   Appendix C - Sample responses to system commands .......... 33
+   Appendix D - Sample whois++ session ....................... 35
+   Appendix E - System messages .............................. 36
+   Appendix F - The WHOIS++ BNF Grammar ...................... 38
+   Appendix G - Description of Regular expressions ........... 40
+
+1.  Part I - WHOIS++ Overview
+
+1.1.  Purpose and Motivation
+
+   The current NIC WHOIS service [HARR85] is used to provide a very
+   limited directory service, serving information about a small number
+   of Internet users registered with the DDN NIC. Over time the basic
+   service has been expanded to serve additional information and similar
+   services have also been set up on other hosts.  Unfortunately, these
+   additions and extensions have been done in an ad hoc and
+   uncoordinated manner.
+
+   The basic WHOIS information model represents each individual record
+   as a Rolodex-like collection of text. Each record has a unique
+   identifier (or handle), but otherwise is assumed to have little
+   structure. The current service allows users to issue searches for
+   individual strings within individual records, as well as searches for
+   individual record handles using a very simple query-response
+   protocol.
+
+   Despite its utility, the current NIC WHOIS service cannot function as
+   a general White Pages service for the entire Internet. Given the
+   inability of a single server to offer guaranteed response or
+   reliability, the huge volume of traffic that a full scale directory
+   service will generate and the potentially huge number of users of
+   such a service, such a trivial architecture is obviously unsuitable
+   for the current Internet's needs for information services.
+
+   This document describes the architecture and protocol for WHOIS++, a
+   simple, distributed and extensible information lookup service based
+   upon a small set of extensions to the original WHOIS information
+   model.  These extensions allow the new service to address the
+   community's needs for a simple directory service, yet the extensible
+   architecture is expected to also allow it to find application in a
+   number of other information service areas.
+
+   Added features include an extension to the trivial WHOIS data model
+   and query protocol and a companion extensible, distributed indexing
+   service. A number of other options have also been added, like boolean
+   operators, more powerful search constraints and search methods, and
+
+
+
+Deutsch, et al              Standards Track                     [Page 3]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+   most specificly structured the data to make both the client and the
+   server part of the dialogue more stringent and parseable. An optional
+   authentication mechanism for protecting all or parts of the
+   associated WHOIS++ information database from unauthorized access is
+   also briefly described.
+
+   The basic architecture of WHOIS++ allows distributed maintenance of
+   the directory contents and the use of the WHOIS++ indexing service
+   for locating additional WHOIS++ servers. Although a general overview
+   of this service is included for completeness, the indexing extensions
+   are described in a separate paper.
+
+1.2.  Basic Information Model
+
+   The WHOIS++ service is centered in a recommendation to structure user
+   information around a series of standardized information templates.
+   Such templates consist of ordered sets of data elements (or
+   attribute-value pairs).
+
+   It is intended that adding such structured templates to a server and
+   subsequently identifying and searching them be simple tasks.  The
+   creation and use of customized templates should also be possible with
+   little effort, although their use should be discouraged where
+   appropriate standardized templates exist.
+
+   We also offer methods to allow the user to constrain searches to
+   desired attributes or template types, in addition to the existing
+   commands for specifying handles or simple strings.
+
+   It is expected that the minimalist approach we have taken will find
+   application where the high cost of configuring and operating
+   traditional White Pages services can not currently be justified.
+
+   Also note that the architecture makes no assumptions about the search
+   and retrieval mechanisms used within individual servers.  Operators
+   are free to use dedicated database formats, fast indexing software or
+   even provide gateways to other directory services to store and
+   retrieve information, if desired.
+
+   The WHOIS++ server simply functions as a known front end, offering a
+   simple data model and communicating through a well known port and
+   query protocol. The format of both queries and replies has been
+   structured to allow the use of client software for generating
+   searches and displaying the results. At the same time, some effort
+   has been made to keep responses at least to some degree readible by
+   humans, to ensure low entry cost and to ease debugging.
+
+
+
+
+
+Deutsch, et al              Standards Track                     [Page 4]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+   The actual implemention details of an individual WHOIS++ search
+   engine are left to the imagination of the implementor and it is hoped
+   that the simple, extensible approach taken will encourage
+   experimentation and the development of improved search engines.
+
+1.2.1.  Changes to the current WHOIS Model
+
+   The current WHOIS service is based upon an extremely simple data
+   model.  The NIC WHOIS database consists of a series of individual
+   records, each of which is identified by a single unique identifer
+   (the "handle"). Each record contains one or more lines of
+   information. Currently, there is no structure or implicit ordering of
+   this information, although by implication each record is concerned
+   with information about a single user or service.
+
+   We have implemented two basic changes to this model. First, we have
+   structured the information within the database as collections of data
+   elements, or simple attribute/value pairs. Each individual record
+   contains a specified ordered set of these data elements.
+
+   Secondly, we have introduced typing of the database records. In
+   effect, each record is based upon one of a specified set of
+   templates, each containing a finite and specified number of data
+   elements. This allow users to easily limit searches to specific
+   collections of information, such as information about users,
+   services, abstracts of papers, descriptions of software, and so on.
+
+   As a final extension, we require that each individual WHOIS++
+   database on the Internet be assigned a unique handle, analogous to
+   the handle associated with each database record.
+
+   The WHOIS++ database structure is shown in Fig. 1.
+
+1.2.2.  Registering WHOIS++ servers
+
+   We propose that individual database handles be registered through the
+   Internet Assigned Numbers Authority (the IANA), ensuring their
+   uniqueness. This will allow us to specify each WHOIS++ entry on the
+   Internet as a unique pair consisting of a server handle and a record
+   handle.
+
+   A unique registered handle is preferable to using the host's IP
+   address, since it is conceivable that the WHOIS++ server for a
+   particular domain may move over time.  If we preserve the unique
+   WHOIS++ handle in such cases we have the option of using it for
+   resource discovery and networked information retrieval (see [IIIR]
+   for a discussion of resource and discovery and support issues).
+
+
+
+
+Deutsch, et al              Standards Track                     [Page 5]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+   There are many ways of guaranteeing uniqueness of server handles; we
+   will discuss them in a separate paper.
+
+   We believe that organizing information around a series of such
+   templates will make it easier for administrators to gather and
+   maintain this information and thus encourage them to make such
+   information available.  At the same time, as users become more
+   familiar with the data elements available within specific templates
+   they will be better able to specify their searches, leading to a more
+   useful service.
+
+ ______________________________________________________________________
+|                                                                      |
+|   +  Single unique WHOIS++ database handle                           |
+|                                                                      |
+|              _______                 _______                _______  |
+|    handle3  |..  .. |      handle6  |..  .. |     handle9  |..  .. | |
+|            _______  |              _______  |             _______  | |
+|  handle2  |..  .. |      handle5  |..  .. |     handle8  |..  .. |   |
+|           _______ |               _______ |              _______ |   |
+| handle1  |..  .. |      handle4  |..  .. |     handle7  |..  .. |    |
+|          |..  .. |               |..  .. |              |..  .. |    |
+|           -------                 -------                -------     |
+|      Template                   Template               Template      |
+|       Type 1                     Type 2                 Type 3       |
+|                                                                      |
+|                                                                      |
+|                                                                      |
+|                                                                      |
+|               Fig.1 - Structure of a WHOIS++ database.               |
+|                                                                      |
+| Notes: - Entire database is identified by a single unique WHOIS      |
+|          handle.                                                     |
+|        - Each record has a single unique handle and a specific set   |
+|          of attributes, determined by the template type used.        |
+|        - Each value associated with an attribute can be any ASCII    |
+|          string up to a specified length.                            |
+|______________________________________________________________________|
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deutsch, et al              Standards Track                     [Page 6]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+1.2.3.  The WHOIS++ Search Selection Mechanism
+
+   The WHOIS++ search mechanism is intended to be extremely simple. A
+   search command consists of one or more search terms, with an optional
+   set of global constraints (specifiers that modify or control a
+   search).
+
+   Search terms allow the user to specify template type, attribute,
+   value or handle that any record returns must satisfy. Each search
+   term can have an optional set of local constraints that apply to only
+   that term.
+
+   A WHOIS++ database may be seen as a single rolodex-like collection of
+   typed records.  Each term specifies a further constraint that the
+   selected set of output records must satisfy. Each term may thus be
+   thought of as performing a subtractive selection, in the sense that
+   any record that does not fulfil the term is discarded from the result
+   set.  Boolean searches are possible by the use of AND, OR, NOT and
+   parenthesis.
+
+1.2.4.  The WHOIS++ Architecture
+
+   The WHOIS++ directory service has an architecture which is separated
+   into two components; the base level server, which is described in
+   this paper, and a indexing server. A single physical server can act
+   as both a base level server and an indexing server.
+
+   A base level server is one which contains only filled templates. An
+   indexing server is one which contains forward knowledge (q.v.) and
+   pointers to other indexing servers or base level servers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deutsch, et al              Standards Track                     [Page 7]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+1.3.  Indexing in WHOIS++
+
+   Indexing in WHOIS++ is used to tie together many base level servers
+   and index servers into a unified directory service.
+
+   Each base level server and index server which wishes to participate
+   in the unified directory service must generate "forward knowledge"
+   for the entries it contains. One type of forward knowledge is the
+   "centroid".
+
+   An example of a centroid is as follows: if a whois++ server contained
+   exactly three records, as follows:
+
+        Record 1                        Record 2
+        Template: Person                Template: Person
+        First-Name: John                First-Name: Joe
+        Last-Name: Smith                Last-Name: Smith
+        Favourite-Drink: Labatt Beer    Favourite-Drink: Molson Beer
+
+        Record 3
+        Template: Domain
+        Domain-Name: foo.edu
+        Contact-Name: Mike Foobar
+
+        the centroid for this server would be
+
+        Template:       Person
+        First-Name:     Joe
+                        John
+        Last-Name:      Smith
+        Favourite-Drink:Beer
+                        Labatt
+                        Molson
+
+        Template:       Domain
+        Domain-Name:    foo.edu
+        Contact-Name:   Mike
+                        Foobar
+
+   An index server would then collect this centroid for this server as
+   forward knowledge.
+
+   Index servers can collect forward knowledge for any servers it
+   wishes.  In effect, all of the servers that the index server knows
+   about can be searched with a single query to the index server; the
+   index server holds the forward knowledge along with pointers to the
+   servers it indexes, and can refer the query to servers which might
+   hold information which satisfies the query.
+
+
+
+Deutsch, et al              Standards Track                     [Page 8]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+   Implementors of this protocol are strongly encouraged to incorporate
+   centroid generation abilities into their servers.
+
+-------------------------------------------------------------------
+
+                              ____             ____
+top level                    |    |           |    |
+whois index                  |    |           |    |
+servers                       ----             ----
+
+
+                        ____                ____
+first level            |    |              |    |
+whois index            |    |              |    |
+servers                 ----                ----
+
+
+                    ____                ____                ____
+individual         |    |              |    |              |    |
+whois servers      |    |              |    |              |    |
+                    ----                ----                ----
+
+
+                 Fig. 2 - Indexing system architecture.
+
+-------------------------------------------------------------------
+
+1.4.  Getting Help
+
+   Another extension to the basic WHOIS service is the requirement that
+   all servers support at least a minimal set of help commands, allowing
+   users to find out information about both the individual server and
+   the entire WHOIS++ service itself. This is done in the context of the
+   new extended information model by defining two specific template
+   formats and requiring each server to offer at least one example of
+   each record using these formats. The operator of each WHOIS service
+   is therefor expected to have, as a minimum, a single example of
+   SERVICES and HELP records, which can be accessed through appropriate
+   commands.
+
+1.4.1.  Minimum HELP Required
+
+     Executing the command:
+
+             DESCRIBE
+
+     gives a brief information about the WHOIS++ server.
+
+
+
+
+Deutsch, et al              Standards Track                     [Page 9]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+     Executing the command:
+
+             HELP
+
+     gives a brief description of the WHOIS++ service itself.
+
+     The text of both required helped records should contain pointers to
+     additional help subjects that are available.
+
+
+     Executing the command:
+
+             HELP <searchstring>
+
+     may give information on any topic.
+
+1.5.  Options and Constraints
+
+   The WHOIS++ service is based upon a minimal core set of commands and
+   controlling constraints. A small set of additional optional commands
+   and constraints can be supported. These would allow users to perform
+   such tasks as provide security options, modify the information
+   contents of a server or add multilingual support. The required set of
+   WHOIS++ commands are summarized in section 2.2.  WHOIS++ constraints
+   are described in section 2.3. Optional constraints are described in
+   section 2.3.2.
+
+1.6.  Formatting Responses
+
+   The output returned by a WHOIS++ server is structured to allow
+   machine parsing and automated handling. Of particular interest in the
+   ability to return summary information about a search (without having
+   to return the entire results).
+
+   All output of searches will be returned in one of five output
+   formats, which will be one of FULL, ABRIDGED, HANDLE, SUMMARY or
+   SERVER-TO-ASK.  Note that a conforming server is only required to
+   support the first four formats.
+
+   When available, SERVER-TO-ASK format is used to indicate that a
+   search cannot be completed but that one or more alternative WHOIS++
+   servers may be able to perform the search.
+
+   Details of each output format are specified in section 2.4.
+
+
+
+
+
+
+
+Deutsch, et al              Standards Track                    [Page 10]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+1.7.  Reporting Warnings and Errors
+
+   The formatted response of WHOIS++ commands allows the encoding of
+   warning or error messages to simplify parsing and machine handling.
+   The syntax of output formats are described in detail in section 2.4,
+   and details of WHOIS++ warnings and error conditions are given in
+   Appendix E.
+
+   All system messages are numerical, but can be tagged with text. It is
+   the clients decision if the text is presented to the user.
+
+1.8.  Privacy and Security Issues
+
+   The basic WHOIS++ service was conceived as a simple, unauthenticated
+   information lookup service, but there are occasions when
+   authentication mechanisms are required. To handle such cases, an
+   optional mechanism is provided for authenticating each WHOIS++
+   transaction.
+
+   The current identified authentication mechanism is PASSWORD, which
+   uses simple password authentication. Any other scheme name used must
+   begin with the characters "X-" and should thus be regarded as
+   experimental and non-standard.
+
+   Note that the WHOIS++ authentication mechanism does not dictate the
+   actual authentication scheme used, it merely provides a framework for
+   indicating that a particular transaction is to be authenticated, and
+   the appropriate mechanisms to use. This mechanism is extensible and
+   individual implementors are free to add additional mechanisms.
+
+   This document includes a very simple authentication scheme where a
+   combination of username and password is sent together with the search
+   string so the server can verify that the user have access to the
+   information. Note that this is NOT by any means a method recommended
+   to secure the data itself because both password and information are
+   tranferred unencrypted over the network.
+
+   Given the unauthenticated nature that default services like white
+   pages services are, it is easy to either forget the implications of
+   this and just show all data to the public Internet, or think that
+   Internet is so dangerous that information is hidden from the Internet
+   so the whole idea of a global white pages service is lost.  Therefore
+   the type of authentication scheme selected and the public nature of
+   the Internet environment must still be taken into consideration when
+   assessing the security and authentication of the information served.
+
+   A more detailed exposition on security is outside the scope of this
+   document.
+
+
+
+Deutsch, et al              Standards Track                    [Page 11]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+2.  Part II - WHOIS++ Implementation
+
+2.1.  The WHOIS++ interaction model
+
+   A WHOIS++ server will normally listen for a TCP connections on the
+   allocated WHOIS++ port (although a WHOIS++ server can be accessed
+   over any TCP connection). Once a connection is established, the
+   server issues a banner message, and listens for input. The command
+   specified in this input is processed and the results returned
+   including an ending system message. If the optional HOLD constraint
+   has not been specified the connection is then terminated.
+
+   If the server supports the optional HOLD constraint, and this
+   constraint is specified as part of any command, the server continues
+   to listen on the connection for another line of input.  This cycle
+   continues as long as the sender continues to append the required HOLD
+   constraint to each subsequent command.
+
+   At the same time, each server is permitted to set an optional timeout
+   value (which should be indicated in the response to the CONSTRAINTS
+   command). If set, the server is free to terminate an idle connection
+   at any time after this delay has passed with no input from the
+   client. If the server terminates the connection due to timeout, it
+   will be indicated by the system message. The timeout value is not
+   changeable by the client.
+
+2.2.  The WHOIS++ Command set
+
+   There are two types of WHOIS++ commands - system commands and the
+   WHOIS++ search command.
+
+   The WHOIS++ command set consists of a core set of required systems
+   commands, a single required search command and an set of optional
+   system commands which support features that are not required by all
+   servers. The set of required WHOIS++ system commands are listed in
+   Table I. Details of the allowable search terms for the search command
+   are included in Table II.
+
+   Each WHOIS++ command also allows the use of one or more controlling
+   constraints, when selected can be used to override defaults or
+   otherwise modify server behavior. There is a core set of constraints
+   that must be supported by all conforming servers. These include
+   SEARCH (which controls the type of search performed), FORMAT (which
+   determines the output format used) and MAXHITS (which determines the
+   maximum number of matches that a search can return).
+
+   These required constraints are summarized in Table III.
+
+
+
+
+Deutsch, et al              Standards Track                    [Page 12]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+   An additional set of optional constraints are used to provide support
+   for different character sets, indicate the need and type of
+   authentication to perform on a transaction, and permit multiple
+   transactions during a single communications session. These optional
+   constraints are listed in Table IV.
+
+   It is possible, using the required COMMANDS and CONSTRAINTS system
+   commands, to query any WHOIS++ server for its list of supported
+   commands and constraints.
+
+2.2.1.  System Commands
+
+   System commands are commands to the server for information or to
+   control its operation. These include commands to list the template
+   types available from individual servers, to obtain a single blank
+   template of any available type, and commands to obtain the list of
+   valid commands and constraints supported on a server.
+
+   There are also commands to obtain the current version of the WHOIS++
+   protocol supported, to access a simple help subsystem, to obtain a
+   brief description of the service (which is intended, among other
+   things, to support the automated registration of the service by
+   yellow pages directory services). All of these commands are required
+   from a conforming WHOIS++ server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deutsch, et al              Standards Track                    [Page 13]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+------------------------------------------------------------------------
+
+Short  Long Form                               Functionality
+-----  ---------                               -------------
+       COMMANDS        [ ':' HOLD ]          list valid WHOIS++ commands
+                                             supported by this server
+
+       CONSTRAINTS     [ ':' HOLD ]          List valid constraints
+                                             supported by this server
+
+       DESCRIBE        [ ':' HOLD ]          Describe this server,
+                                             formating the response
+                                             using a standard
+                                             "Services" template
+
+ '?'   HELP [<string>  [':' <cnstrnts>]]     System help, using a "Help"
+                                             template
+
+       LIST            [':' <cnstrnts>]      List templates supported
+                                             by this system
+
+       POLLED-BY       [ ':' HOLD ]          List indexing servers
+                                             that are know to track
+                                             this server
+
+       POLLED-FOR      [ ':' HOLD ]          List information about
+                                             what this server is
+                                             tracking for
+
+       SHOW <string>   [':' <cnstrnts>]      Show contents of templates
+                                             specified
+
+       VERSION         [ ':' HOLD ]          return current version of
+                                             the protocol supported.
+
+              Table I - Required WHOIS++ SYSTEM commands.
+
+------------------------------------------------------------------------
+
+   Below follows a descriptions for each command. Examples of responses
+   to each command is in Appendix C.
+
+2.2.1.1.  The COMMANDS command
+
+   The COMMANDS command returns a list of commands that the server
+   supports. The response is formatted as a FULL response.
+
+
+
+
+
+Deutsch, et al              Standards Track                    [Page 14]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+2.2.1.2.  The CONSTRAINTS command
+
+   The CONSTRAINTS command returns a list of constraints and the values
+   of those that the server supports. The response is formatted as a
+   FULL response, where every constraint is represented as a separate
+   record. The template name for these records is CONSTRAINT.  No
+   attention is paid to handles. Each record has, as a minimum, the
+   following two fields:
+
+     - "Constraint", which contains the attribute name described -
+       "Default", which shows the default value for this constraint.
+
+   If the client is permitted to change the value of the constraint,
+   there is also:
+
+     - "Range" field, which contains a list of values that this
+       server supports, as a comma separated list; Or, if the range
+       is numerical, as a pair of numbers separated with a hyphen.
+
+2.2.1.3.  The DESCRIBE command
+
+   The DESCRIBE command gives a brief description about the server in a
+   "Services" template. The result is formatted as a FULL response.
+
+2.2.1.4.  The HELP command
+
+   The HELP command takes an optional argument as subject to get help
+   for.
+
+2.2.1.5.  The LIST command
+
+   The LIST command returns the name of the templates available on the
+   server. The answer is formatted FULL format response.
+
+2.2.1.6.  The POLLED-BY command
+
+   The POLLED-BY command returns a list of servers and the templates and
+   attribute names that those server polled as centroids from this
+   server. The format is in FULL format with two attributes, Template
+   and Field. Each of these is a list of names of the templates or
+   fields polled.  An empty result means either that the server is not
+   polled by anyone, or that it doesn't support indexing.
+
+
+
+
+
+
+
+
+
+Deutsch, et al              Standards Track                    [Page 15]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+2.2.1.7.  The POLLED-FOR command
+
+   The POLLED-FOR command returns a list of servers that this server has
+   polled, and the template and attribute names for each of those.  The
+   answer is in FULL format with two attributes, Template and Field.  An
+   empty result means either that the server is not polling anyone, or
+   that it doesn't support indexing.
+
+2.2.1.8.  The SHOW command
+
+   The SHOW command takes a template name as argument and returns
+   information about a specific template, formatted as a FULL response.
+   The answer is formatted as a blank template with the requested name.
+
+2.2.1.9.  The VERSION command
+
+   The output format is a FULL response containg a record with template
+   name VERSION. The record must have attribute name "Version", which
+   value is "1.0" for this version of the protocol.  The record may also
+   have the additional fields "Program-Name" and "Program-Version" which
+   gives information about the server implementation if the server so
+   desires.
+
+2.2.2.  The Search Command
+
+   A search command consists of one or more search terms, which might
+   each have local constraints, followed by an optional colon with a set
+   of global search constraints.
+
+   Each attribute value in the WHOIS++ database is divided into one or
+   more words separated by whitespace. Each search term operates on
+   every word in the attribute value.
+
+   Two or more search terms may be combined with boolean operators AND,
+   OR or NOT (other than the implied AND between terms). The operator
+   AND has higher precedence than the operator OR, but this can be
+   changed by the use of parentheses.
+
+   Search constraints that apply to every search term are specified as
+   global constraints. Local constraints override global constraints for
+   the search term they are bound to. The search terms and the global
+   constraints are separated with a colon (':'). Additional global
+   constraints are appended to the end of the search command delimited
+   with a semicolon ';'.
+
+   If different search constraints can not be fulfilled, or the
+   combination of different search constraints is uncombinable, the
+   server may choose to ignore some constraints, but still do the search
+
+
+
+Deutsch, et al              Standards Track                    [Page 16]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+   and return some records.
+
+   The set of required constraints are summarized in Table III. The set
+   of optional constraints are summarized in Table IV.
+
+   As an option, the server may accept specifications for attributes for
+   either inclusion or exclusion from a reply. Thus, users could specify
+   -only- those attributes to return, or specific attributes to filter
+   out, thus creating custom views.
+
+2.2.2.1.  Format of a Search Term
+
+   Each search term consists of one of the following:
+
+     1) A search string, followed by an optional semicolon and set of
+        semicolon-separated local constraints.
+
+     2) A search term specifier (as listed in Table II), followed by a
+        '=', followed by a search string, an optional semicolon and a
+        set of semicolon-separate local constraints.
+
+     3) An abbreviated search term specifier, followed by a search
+        string, followed by an optional semicolon and set of
+        semicolon-separated local constraints.
+
+     4) A combination of attribute name, followed by '=', followed by
+        a search string, followed by an optional semicolon and set of
+        semicolon-separate local constraints.
+
+   If no term identifier is provided, then the search will be applied to
+   attribute values only. This corresponds to an identifier of VALUE.
+
+   If a SEARCH-ALL specifier is used then the search will be applied to
+   all template names, handles, attribute names and attribute values.
+
+   When the user specifies the search term using the form:
+
+             "<attribute_name> = <value>"
+
+   this is considered to be an ATTRIBUTE-VALUE search.
+
+   For discussion of the system reply format, and selecting the
+   appropriate reply format, see section 2.4.
+
+
+
+
+
+
+
+
+Deutsch, et al              Standards Track                    [Page 17]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+     -------------------------------------------------------------------
+
+     Valid specifiers:
+     -----------------
+
+      Name                                  Functionality
+      ----                                  -------------
+
+      ATTRIBUTE-VALUE [ ';' <constrnt>]*    allows combining
+                                            attribute and value
+                                            specifiers in one term.
+      HANDLE          [ ';' <constrnt>]*    Confine search to handles.
+      SEARCH-ALL      [ ';' <constrnt>]*    Search everything.
+      TEMPLATE        [ ';' <constrnt>]*    Confine search to
+                                            template names.
+      VALUE           [ ';' <constrnt>]*    Confine search to attribute
+                                            values. This is the default.
+
+     (Note: The name HANDLE can be replaced with the shortname '!')
+
+     Acceptable forms of a search specifier:
+     ---------------------------------------
+
+     1) <searchstring>  [';' <constraint>]*
+
+     2) <specifier> = <searchstring> [';' <constraint>]*
+
+     3) <shortspecifier> <searchstring>  [';' <constraint>]*
+
+     4) <attribute_name> = <searchstring>  [';' <constraint>]*
+
+     (Note: A <constraint> is a name of a valid local constraint.)
+
+            Table II - Valid search command term specifiers.
+
+     -------------------------------------------------------------------
+
+2.2.2.2.  Format of a Search String
+
+   Special characters that need to be quoted are preceeded by a
+   backslash, '\'.
+
+   Special characters are space ' ', tab, equal sign '=', comma ',',
+   colon ':', backslash '\', semicolon ';', asterisk '*', period '.',
+   parenthesis '()', square brackets '[]', dollar sign '$' and
+   circumflex '^'.
+
+
+
+
+
+Deutsch, et al              Standards Track                    [Page 18]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+   If the search term is given in some other character set than ISO-
+   8859-1, it must be specified by the constraint INCHARSET.
+
+2.3.  WHOIS++ Constraints
+
+   Constraints are intended to be hints or recommendations to the server
+   about how to process a command. They may also be used to override
+   default behaviour, such as requesting that a server not drop the
+   connection after performing a command.
+
+   Thus, a user might specify a search constraint as "SEARCH=exact",
+   which means that the search engine is to perform an exact match
+   search. It might also specify "LANGUAGE=Fr", which implies that the
+   server should use French in fuzzy matches. It might also be able to
+   issue system messages in French.
+
+   In general, contraints take the form "<constraintname>=<value>", with
+   <value> being one of a specified set of valid values. The notable
+   exception is "HOLD", which takes no argument.
+
+   All constraints can be used as a global constraint, but only a few
+   can be used as local. See tables IV and V for information of which
+   constraints can be local.
+
+   The CONSTRAINTS system command is used to list the search constraints
+   supported by an individual server.
+
+   If a server cannot satisfy the specified constraint there will be a
+   mechanism for informing the user in the reply, using system messages.
+   In such cases, the search is still performed, with the the server
+   ignoring unsupported constraints.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deutsch, et al              Standards Track                    [Page 19]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+2.3.1.  Required Constraints
+
+   The following CONSTRAINTS must be supported in all conforming WHOIS++
+   servers.
+
+     ------------------------------------------------------------------
+
+      Format                                           LOCAL/GLOBAL
+      ------                                           -------------
+
+     SEARCH=   {exact | lstring }                      LOCAL/GLOBAL
+
+     FORMAT=   {full | abridged | handle | summary }   GLOBAL
+
+     MAXHITS=  { 1-<max-allowed> }                     GLOBAL
+
+     Table III - Required WHOIS++ constraints.
+
+     ------------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deutsch, et al              Standards Track                    [Page 20]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+2.3.2.  Optional CONSTRAINTS
+
+   The following CONSTRAINTS and constraint values are not required of a
+   conforming WHOIS++ server, but may be supported. If supported, their
+   names and supported values must be returned in the response to the
+   CONSTRAINTS command.
+
+  ---------------------------------------------------------------------
+
+   Format                                                  LOCAL/GLOBAL
+   ------                                                  -------------
+
+  SEARCH=       { regex | fuzzy | substring | <X-format> } LOCAL/GLOBAL
+
+  CASE=         { ignore | consider }                      LOCAL/GLOBAL
+
+  FORMAT=       { server-to-ask | <X-format> }             GLOBAL
+
+  MAXFULL=      { 1-<max-allowed> }                        GLOBAL
+
+  AUTHENTICATE= password                                   GLOBAL
+
+  NAME=         <string>                                   GLOBAL
+
+  PASSWORD=     <string>                                   GLOBAL
+
+  INCHARSET=    { us-ascii | iso-8859-* }                  GLOBAL
+
+  LANGUAGE=     <As defined in ISO 639:1988>               GLOBAL
+
+  HOLD                                                     GLOBAL
+
+  IGNORE=       {attributelist}                            GLOBAL
+
+  INCLUDE=      {attributelist}                            GLOBAL
+
+                Table IV - Optional WHOIS++ constraints.
+
+  ----------------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+Deutsch, et al              Standards Track                    [Page 21]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+2.3.2.1.  The SEARCH Constraint
+
+   The SEARCH constraint is used for specifying the method that is to be
+   used for the search. The default method is "exact". Following is a
+   definition of each search method.
+
+
+   exact           The search will succeed for a word that exactly
+                   matches the search string.
+
+   substring       The search will succeed for a word that matches
+                   a part of a word.
+
+   regex           The search will succeed for a word when a regular
+                   expression matches the searched data. Regular
+                   expression is built up by using constructions of
+                   '*', '.', '^', '$', and '[]'. For use of
+                   regular expressions see Appendix G.
+
+   fuzzy           The search will succeed for words that matches the
+                   search string by using an algorithm designed to catch
+                   closely related names with different spelling, e.g.
+                   names with the same pronounciation.  The server
+                   chooses which algorithm to use, but it may vary
+                   depending on template name, attribute name and
+                   language used (see Constraint Language above).
+
+   lstring         The search will succed for words that begins
+                   with the search string.
+
+2.3.2.2.  The FORMAT Constraint
+
+   The FORMAT constraint describes what format the result will be in.
+   Default format is FULL. For a description of each format, see Server
+   Response Modes below.
+
+2.3.2.3.  The MAXFULL Constraint
+
+   The MAXFULL constraint sets the limit of the number of matching
+   records the server allows before it enforces SUMMARY responses.  The
+   client may attempt to override this value by specifying another value
+   to that constraint. Example: If, for privacy reasons, the server will
+   return the response in SUMMARY format if the number of hits exceeds
+   2, the MAXFULL constraint is set to 2 by the server.
+
+   Regardless of what format the client did or did not ask for, the
+   server will change the response format to SUMMARY when the number of
+   matching records equals or exceeds this value.
+
+
+
+Deutsch, et al              Standards Track                    [Page 22]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+2.3.2.4.  The MAXHITS Constraint
+
+   The MAXHITS constraint sets the maximum number of records the client
+   can get in a search respone.
+
+2.3.2.5.  The CASE Constraint
+
+   The CASE constraint defines if the search should be done case
+   sensistive or not. Default value is to have case ignored.
+
+2.3.2.6.  The AUTHENTICATE Constraint
+
+   The AUTHENTICATE constraint describes which authentication method to
+   use when executing the search. By using a specific authentication
+   method, some other constraints might be needed which is specified by
+   the authentication method.
+
+   The only authentication method described in this document is
+   "password", if used, also the two other constraints "name" and
+   "password" need to be set.
+
+2.3.2.7.  The NAME Constraint
+
+   The NAME constraint is only used together with some authentication
+   method named by the constraint "authenticate". The only use described
+   in this document is by sending a username as a string of characters
+   which together with the string given as an argument to the "password"
+   constraint is sent to the server. The server can use that pair of
+   strings to do a simple authentication check, similar to the UNIX
+   login program.
+
+2.3.2.8.  The PASSWORD Constraint
+
+   The PASSWORD constraint is only used together with some
+   authentication method named by the constraint "authenticate". The
+   only use described in this document is by sending a password as a
+   string of characters which together with the string given as an
+   argument to the "name" constraint is sent to the server. The server
+   can use that pair of strings to do a simple authentication check,
+   similar tothe UNIX login program.
+
+2.3.2.9.  The LANGUAGE Constraint
+
+   The LANGUAGE constraints can be used as an extra information to the
+   fuzzy matching search method, and it might also be used to tell the
+   server to give the system responses in another language, although
+   this ability should be handled by the client. The language code
+   defined in RFC 1766 [ALVE95] can be used as a value for the language
+
+
+
+Deutsch, et al              Standards Track                    [Page 23]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+   constraint.  In these, the case of the letters are insignigicant.
+
+2.3.2.10.  The INCHARSET Constraint
+
+   The INCHARSET constraint tells the server in which character set the
+   search string itself is given in. The default character set is ISO-
+   8859-1.
+
+2.3.2.11.  The IGNORE Constraint
+
+   The IGNORE constraint specifies which attributes to NOT include in
+   the result. All other attributes will be included (as if named
+   explicitly by the "include" constraint).
+
+   If an attribute is named both with the "include" and "ignore"
+   constraint, the attribute is to be included in the result, but the
+   system message must be "% 205 Requested constraint not fulfilled".
+
+2.3.2.12.  The INCLUDE Constraint
+
+   The INCLUDE constraint specifies which attributes to include in the
+   result. All other attributes will be excluded (as if named explicitly
+   by the "ignore" constraint).
+
+   If an attribute is named both with the "include" and "ignore"
+   constraint, the attribute is to be included in the result, but the
+   system message must be "% 205 Requested constraint not fulfilled".
+
+2.4.  Server Response Modes
+
+   There are currently a total of five different response modes possible
+   for WHOIS++ servers. These are FULL, ABRIDGED, HANDLE, SUMMARY and
+   SERVER-TO-ASK. The syntax of each output format is specified in more
+   detail in the following section.
+
+     1) A FULL format response provides the complete contents of a
+        template matching the specified query, including the template
+        type, the server handle and an optional record handle.
+
+     2) An ABRIDGED format response provides a brief summary, including
+        (as a minimum) the server handle, the corresponding record handle
+        and relevant information for that template.
+
+     3) A HANDLE format response returns a line with information about
+        the server handle and record handle for a record that matched
+        the specified query.
+
+
+
+
+
+Deutsch, et al              Standards Track                    [Page 24]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+     4) A SUMMARY response provides only a brief summary of information
+        the number of matches and the list of template types in which the
+        matches occured.
+
+     5) A SERVER-TO-ASK response only returns pointers to other index
+        servers which might possibly be able to answer the specified
+        query.
+
+   The server may respond with a null answer and may also respond with a
+   null answer together with a correct system message to indicate that
+   the query was too complex.
+
+2.4.1.  Default Responses
+
+   By default, a WHOIS++ server will provide FULL responses. This may be
+   changed by the client with the use of the global constraint "format".
+
+   The server is allowed to provide response in SUMMARY format if the
+   number of hits exceeds the value of the global constraint "maxfull".
+
+   The server will not respond with more matches than the value
+   specified with the global constraint "maxhits"; Not in any response
+   format. If the number of matches exceeds this value, the server will
+   issues the system message 110 (maxhits value exceeded), but will
+   still show the responses, up to the number of the "maxhits"
+   constraint value.  This mechanism will allow the server to hide the
+   number of possible matches to a search command.
+
+   The server response modes are summarized in Table V.
+
+2.4.2.  Format of Responses
+
+   Each response consists of a numerical system generated message, which
+   can be tagged with text, followed by an optional formatted response
+   message, followed by a second system generated messages.
+
+   That is:
+
+        '%' <system messages> <nl>
+
+        [ <formatted response> ]
+
+        '%' <system messages> <nl>
+
+
+   If there are no matches to a query, the system is not required to
+   generate any output as a formatted response, although it must still
+   generate system messages.
+
+
+
+Deutsch, et al              Standards Track                    [Page 25]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+   For information about the format for system messages, see Appendix E.
+
+2.4.3.  Syntax of a Formatted Response
+
+   All formatted responses except for the HANDLE response, consists of a
+   response-specific START line, followed by an optional response-
+   specific data section, followed by a TERMINATION line.  The HANDLE
+   response is different in that it only consists of a START line.  It
+   is permissible to insert any number of lines consisting solely of
+   newlines within a formatted response to improve readibility.
+
+   Each line shall be limited to no more than 81 characters, including
+   the terminating newline.  If a line (including the required leading
+   single space) would exceed 81 characters, it is to be broken into
+   lines of no more than 81 characters, with each continuation line
+   beginning with a "+" character in the first column instead of the
+   leading character.
+
+   If an attribute value in a data section includes a line break, the
+   line break must be replaced by a CR/LF pair and the following line
+   begin with a "-" character in the first column, instead of the
+   leading character. The attribute name is not repeated on consecutive
+   lines.
+
+   A TERMINATION line consists of a line with a '#' in the first column,
+   followed by one white space character (SPACE or TAB), followed by the
+   keyword END, followed by zero or more characters, followed by a
+   newline.
+
+   A response-specific section will be one of the following:
+
+       1) FULL Format Response
+       2) ABRIDGED Format Response
+       3) HANDLE Format Response
+       4) SUMMARY Format Response
+       5) SERVER-TO-ASK Format Response
+
+        The details of each are specified in the following sections:
+
+2.4.3.1.  A FULL format response
+
+   A FULL format response consists of a series of responses, each
+   consisting of a START line, followed by the complete template
+   information for the matching record and a TERMINATION line.
+
+   Each START line consists of a '#' in the first column, followed by
+   one white space character, the word "FULL", a white space character,
+   the name of the corresponding template type, one white space
+
+
+
+Deutsch, et al              Standards Track                    [Page 26]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+   character, the server handle, a white space character, an optional
+   handle for the record, and a terminating newline.
+
+   The template information for the record will be returned as a series
+   of lines consisting of a single space, followed by the corresponding
+   line of the record.
+
+   The line of the record shall consist of a single space and the
+   attribute name followed by a ':', a single space, the value of that
+   attribute, and a newline.
+
+2.4.3.2.  ABRIDGED Format Response
+
+   Each ABRIDGED format response consists of a START line, a single line
+   excerpt of the template information from each matching record and a
+   TERMINATION line. The excerpt information shall include information
+   that is relevant to the template type.
+
+   The START line consists of a '#' in the first column, followed by one
+   white space character, the word "ABRIDGED", a white space character,
+   the name of the corresponding template type, a white space character,
+   the server handle, a white space character, the handle for the
+   record, and a terminating newline.
+
+   The abridged template information will be returned as a line,
+   consisting of a single space, followed by the abridged line of the
+   record and a newline pair.
+
+2.4.3.3.  HANDLE Format Response
+
+   A HANDLE response consists of a single START line, which shall start
+   with a '#' in the first column, followed by one white space
+   character, the word "HANDLE", a white space character, the name of
+   the corresponding template, a white space character, the handle for
+   the server, a white space character, the handle for that record, and
+   a terminating newline.
+
+2.4.3.4.  SUMMARY Format Response
+
+   A SUMMARY format response consists of a single set of responses,
+   consisting of a line listing the number of matches to the specified
+   query, followed by a list of all template types which satisfied the
+   query at least once.
+
+   The START line shall begin with a '#' in the first column, be
+   followed by one white space character, the word "SUMMARY", a white
+   space character, the handle for the server, and a terminating
+   newline.
+
+
+
+Deutsch, et al              Standards Track                    [Page 27]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+   All following lines until the TERMINATION line starts with a leading
+   space.  The first line shall begin with the string "matches: ", be
+   followed by a space and the number of responses to the query and
+   terminated by a newline.  The second line shall begin with the string
+   "templates: ", be followed by a newline separated list of the name of
+   the template types which matched the query.  Each line following the
+   first which include the text "templates:" must begin with a '-'
+   instead of a space.
+
+2.4.3.5.  SERVER-TO-ASK Response
+
+   A SERVER-TO-ASK response consists of information to the client about
+   a server to contact next to resolve a query.  If the server has
+   pointers to more than one server, it will present additional SERVER-
+   TO-ASK responses.
+
+   The SERVER-TO-ASK response will consist of a START line and a number
+   of lines with attribute-value pairs, separated by CRLF. Each line is
+   indented with one space. The end of a SERVER-TO-ASK response is
+   indicated with a TERMINATION line.
+
+   Each START line consists of a '#' in the first column, followed by
+   one white space character, the word "SERVER-TO-ASK", a white space
+   character, the handle of the server and a terminating newline.
+
+   1. "Server-Handle" - The server handle of the server pointed at.
+      (req.)
+   2. "Host-Name" - A cached host named for the server pointed at. (opt.)
+   3. "Host-Port" - A cached port number for the server pointed at.
+      (opt.)
+
+   Other attributes may be present, depending on the index server.
+
+2.4.4.  System Generated Messages
+
+   All system generated messages must begin with a '%' as the first
+   character, a space as the second one, followed by a three digit
+   number, a space and an optional text message. The total length of the
+   line must be no more than 81 characters long, including the
+   terminating CR LF pair. There is no limit to the number of system
+   messages that may be generated.
+
+   The format for multiline replies requires that every line, except the
+   last, begin with "%", followed by space, the reply code, a hyphen,
+   and an optional text.  The last line will begin with "%", followed by
+   space, the reply code, a space and some optional text.
+
+
+
+
+
+Deutsch, et al              Standards Track                    [Page 28]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+   System generated messages displayed before or after the formatted
+   response section are expected to refer to operation of the system or
+   refer to the entire query. System generated messages within the
+   output of an individual record during a FULL reponse are expected to
+   refer to that record only, and could (for example) be used to
+   indicate problems with that record of the response. See Appendix E
+   for a description of system messages.
+
+2.5.  Compatibility with Older WHOIS Servers
+
+   Note that this format, although potentially more verbose, is still in
+   a human readible form. Responses from older systems that do not
+   follow this format are still conformant, since their responses would
+   be interpreted as being equivalent to optional text messages, without
+   a formatted response.  Clients written to this specification would
+   display the responses as a advisory text message, where it would
+   still be readible by the user.
+
+3.  Miscellaneous
+
+3.1.  Acknowledgements
+
+   The WHOIS++ effort began as an intensive brainstorming session at the
+   24th IETF, in Boston Massachusetts.  Present at the birth, and
+   contributing ideas through this early phase, were (alphabetically)
+   Peter Deutsch, Alan Emtage, Jim Fullton, Joan Gargano, Brad
+   Passwaters, Simon Spero, and Chris Weider. Others who have since
+   helped shape this document with feedback and suggestions include
+   Roxana Bradescu, Patrik Faltstrom, Kevin Gamiel, Dan Kegel, Michael
+   Mealling, Mark Prior and Rickard Schoultz.
+
+3.2  References
+
+   [ALVE95]        Alvestrand H., "Tags for the Identification of
+                   Languages", RFC 1766, UNINETT, March 1995.
+
+   [HARR85]        Harrenstein K., Stahl M., and E. Feinler,
+                   "NICNAME/WHOIS", RFC 954, SRI, October 1985.
+
+   [IIIR]          Weider C., and P. Deutsch, "A Vision of an
+                   Integrated Internet Information Service", RFC 1727
+                   Bunyip Information Systems, Inc., December 1994.
+
+   [POST82]        Postel J., "Simple Mail Transfer Protocol", STD 10,
+                   RFC 821, USC/Information Sciences Institute,
+                   August 1982.
+
+
+
+
+
+Deutsch, et al              Standards Track                    [Page 29]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+3.3.  Authors' Addresses
+
+   Peter Deutsch
+   BUNYIP INFORMATION SYSTEMS, Inc.
+   310 St-Catherine St West,
+   Suite 202,
+   Montreal, Quebec H2X 2A1
+   CANADA
+
+   EMail: peterd@bunyip.com
+
+
+   Rickard Schoultz
+   KTHNOC, SUNET/NORDUnet/Ebone Operations Centre
+   100 44 STOCKHOLM
+   SWEDEN
+
+   EMail: schoultz@sunet.se
+
+
+   Patrik Faltstrom
+   BUNYIP INFORMATION SYSTEMS, Inc.
+   310 St-Catherine St West,
+   Suite 202,
+   Montreal, Quebec H2X 2A1
+   CANADA
+
+   EMail: paf@bunyip.com
+
+
+   Chris Weider
+   BUNYIP INFORMATION SYSTEMS, Inc.
+   2001 S. Huron Parkway, #12
+   Ann Arbor, MI 48104
+   USA
+
+   EMail: clw@bunyip.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deutsch, et al              Standards Track                    [Page 30]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+Appendix A - Some Sample Queries
+
+       author=chris and template=user
+
+   The result will consist of all records where attribute "author"
+   matches "chris" with case ignored. Only USER templates will be
+   searched. An example of a matching record is "Author=Chris Weider".
+   This is the typical case of search.
+
+       schoultz and rick;search=lstring
+
+   The result will consist of all records which have one attribute value
+   matching "schoultz" exactly and one having "rick" as leading
+   substring, both with case ignored. One example is "Name=Rickard
+   choultz".
+
+       value=phone;search=substring
+
+   The result will consist of all records which have attribute values
+   matching *phone*, for example the record "Name=Acme telephone inc.",
+   but will not match the attribute name "phone". (Since "value" term
+   specifier is the default, the search term could be "phone" as well as
+   "value=phone".)
+
+       search-all=Peter ; search=substring;case=consider
+
+   The result will consist of all records which have attribute names,
+   template names or attribute values matching "Peter" with respect to
+   case. One example is "Friend-Of-Peter: Yes".
+
+      ucdavis;search=substring and (gargano or joan):include=name,email
+
+   This search command will find records which have records containing
+   the words "gargano" or "joan" somewhere in the record, and has the
+   word "ucdavis" somewhere in a word. The result will only show the
+   "name" and "email" fields.
+
+Appendix B - Some sample responses
+
+      1) FULL format responses:
+
+      # FULL USER SERVERHANDLE1 PD45
+       Name: Peter Deutsch
+       email: peterd@bunyip.com
+      # END
+      # FULL USER SERVERHANDLE1 AE1
+       Name: Alan Emtage
+       email: bajan@bunyip.com
+
+
+
+Deutsch, et al              Standards Track                    [Page 31]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+      # END
+      # FULL USER SERVERHANDLE1 NW1
+       Name: Nick West
+       Favourite-Bicycle-Forward-Wheel-Brand: New Bicy
+      +cles Acme Inc.
+       email: nick@bicycle.acme.com
+       My-favourite-song: Happy birthday to you!
+      -Happy birthday to you!
+      -Happy birthday dear Nick!
+      -Happy birthday to you.
+      # END
+      # FULL SERVICES SERVERHANDLE1 WWW1
+       Type: World Wide Web
+       Location: the world
+      # END
+
+                          --------------------
+
+
+      2) An ABRIDGED format response:
+
+      # ABRIDGED USER SERVERHANDLE1 PD45
+       Peter Deutsch             peterd@bunyip.com
+      # END
+      # ABRIDGED USER SERVERHANDLE1 AE1
+       Alan Emtage               bajan@bunyip.com
+      # END
+      # ABRIDGED USER SERVERHANDLE1 WWW1
+       World Wide Web            the world
+      # END
+
+
+                          --------------------
+
+
+      3) HANDLE format responses:
+
+
+      # HANDLE USER SERVERHANDLE1 PD45
+      # HANDLE USER SERVERHANDLE1 AE1
+      # HANDLE SERVICES SERVERHANDLE1 WWW1
+
+
+                          --------------------
+
+
+
+
+
+
+
+Deutsch, et al              Standards Track                    [Page 32]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+      4) A SUMMARY HANDLE format response:
+
+      # SUMMARY SERVERHANDLE1
+
+        Matches:      175
+        Templates:    User
+      -               Services
+      -               Abstracts
+      # END
+
+Appendix C - Sample responses to system commands
+
+   C.1 Response to the LIST command
+
+      # FULL LIST SERVERHANDLE1
+       Templates: USER
+      -SERVICES
+      -HELP
+      # END
+
+
+   C.2 Response to the SHOW command
+
+      This example shows the result after issuing "show user":
+
+      # FULL USER SERVERHANDLE1
+        Name:
+        Email:
+        Work-Phone:
+        Organization-Name:
+        City:
+        Country:
+      # END
+
+   C.3 Response to the POLLED-BY command
+
+      # FULL POLLED-BY SERVERHANDLE1
+       Server-handle: serverhandle2
+       Cached-Host-Name: sunic.sunet.se
+       Cached-Host-Port: 7070
+       Template: USER
+       Field: ALL
+      # END
+      # FULL POLLED-BY SERVERHANDLE1
+       Server-handle: serverhandle3
+       Cached-Host-Name: kth.se
+       Cached-Host-Port: 7070
+       Template: ALL
+
+
+
+Deutsch, et al              Standards Track                    [Page 33]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+       Field: Name,Email
+      # END
+
+
+   C.4 Response to the POLLED-FOR command
+
+      # FULL POLLED-FOR SERVERHANDLE1
+       Server-Handle: serverhandle5
+       Template: ALL
+       Field: Name,Address,Job-Title,Organization-Name,
+      +Organization-Address,Organization-Name
+      # END
+      # FULL POLLED-FOR SERVERHANDLE1
+       Server-Handle: serverhandle4
+       Template: USER
+       Field: ALL
+      # END
+
+
+   C.5 Response to the VERSION command
+
+      # FULL VERSION BUNYIP.COM
+       Version: 1.0
+       Program-Name: kth-whoisd
+       Program-Version: 2.0
+      # END
+
+
+   C.6 Response to the CONSTRAINTS command
+
+      # FULL CONSTRAINT COMEDIA.SE
+       Constraint: format
+       Default: full
+       Range: full,abridged,summary,handle
+      # END
+      # FULL CONSTRAINT COMEDIA.SE
+       Constraint: maxhits
+       Default: 200
+       Range: 1-1000
+      # END
+      # FULL CONSTRAINT COMEDIA.SE
+       Constraint: search
+       Default: exact
+       Range: exact,substring,lstring
+      # END
+      # FULL CONSTRAINT COMEDIA.SE
+       Constraint: maxfull
+       Default: 20
+
+
+
+Deutsch, et al              Standards Track                    [Page 34]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+      # END
+
+   C.3 Response to the COMMANDS command
+
+      # FULL COMMANDS SERVERHANDLE1
+       Commands: commands
+      -constraints
+      -describe
+      -help
+      -list
+      -polled-by
+      -polled-for
+      -show
+      -version
+      # END
+
+Appendix D - Sample whois++ session
+
+   Below is an example of a session between a client and a server. The
+   angle brackets to the left is not part of the communication, but is
+   just put there to denonte the direction of the communication between
+   the server or the client. Text appended to '>' means messages from
+   the server and '<' from the client.
+
+     Client connects to the server
+
+     >% 220-Welcome to
+     >% 220-the whois++ server
+     >% 220 at ACME inc.
+     <name=Nick:hold
+     >% 200 Command okay
+     >
+     ># FULL USER ACME.COM NW1
+     > name: Nick West
+     > email: nick@acme.com
+     ># END
+     ># SERVER-TO-ASK ACME.COM
+     > Server-Handle: SUNETSE01
+     > Host-Name: whois.sunet.se
+     > Host-Port: 7070
+     ># END
+     ># SERVER-TO-ASK ACME.COM
+     > Server-Handle: KTHSE01
+     ># END
+     >% 226 Tranfer complete
+     <version
+     >% 200 Command okay
+     ># FULL VERSION ACME.COM
+
+
+
+Deutsch, et al              Standards Track                    [Page 35]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+     > Version: 1.0
+     ># END
+     >% 226 Tranfer complete
+     >% 203 Bye
+     Server closes the connection
+
+   In the example above, the client connected to a whois++ server and
+   queried for all records where the attribute "name" equals "Nick", and
+   asked the server not to close the connection after the response by
+   using the global constraint "HOLD".
+
+   The server responds with one record and a pointer to two other
+   servers that either holds records or pointers to other servers.
+
+   The client continues with asking for the servers version number
+   without using the HOLD constraint.  After responding with protocol
+   version, the server closes the connection.
+
+   Note that each response from the server begins system message 200
+   (Command OK), and ends with system message 226 (Transfer Complete).
+
+Appendix E - System messages
+
+   A system message begins with a '%', followed by a space and a three
+   digit number, a space, and an optional text message. The line message
+   must be no more than 81 characters long, including the terminating CR
+   LF pair. There is no limit to the number of system messages that may
+   be generated.
+
+   A multiline system message have a hyphen instead of a space in column
+   6, immediately after the numeric response code in all lines, except
+   the last one, where the space is used.
+
+     Example 1
+
+     % 200 Command okay
+
+     Example 2
+
+     % 220-Welcome to
+     % 220-the whois++ server
+     % 220 at ACME inc.
+
+   The client is not expected to parse the text part of the response
+   message except when receiving reply 600, in which case the text part
+   is the name of a character set that will be used by the server in the
+   rest of the response. The valid values for characters sets is
+   specified in the "characterset" list in the BNF listing in Appendix
+
+
+
+Deutsch, et al              Standards Track                    [Page 36]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+   F.
+
+   The theory of reply codes is described in Appendix E in STD 10, RFC
+   821 [POST82].
+
+------------------------------------------------------------------------
+
+List of system response codes
+------------------------------
+
+110 Too many hits                         The number of matches exceeded
+                                          the value specified by the
+                                          maxhits constraint. Server
+                                          will still reply with as many
+                                          records as "maxhits" allows.
+
+111 Requested constraint not supported    One or more constraints in
+                                          query is not implemented, but
+                                          the search is still done.
+
+112 Requested constraint not fullfilled   One or more constraints in
+                                          query has unacceptable value
+                                          and was therefore not used,
+                                          but the search is still done.
+
+200 Command Ok                            Command accepted and executed.
+                                          The client must wait for a
+                                          transaction end system message.
+
+201 Command Completed successfully        Command accepted and executed.
+
+203 Bye                                   Server is closing connection
+
+220 Service Ready                         Greeting message. Server is
+                                          accepting commands.
+
+226 Transaction complete                  End of data. All responses to
+                                          query are sent.
+
+430 Authentication needed                 Client requested information
+                                          that needs authentication.
+
+500 Syntax error
+
+502 Search expression too complicated     This message is sent when the
+                                          server is not able to resolve
+                                          a query (i.e. when a client
+                                          sent a regular expression that
+
+
+
+Deutsch, et al              Standards Track                    [Page 37]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+                                          is too deeply nested).
+
+530 Authentication failed                 The authentication phase
+                                          failed.
+
+600 <token>                               Subsequent attribute values
+                                          are encoded in the charater
+                                          set specified by <token>.
+
+                    Table V - System response codes
+
+------------------------------------------------------------------------
+
+Appendix F - The WHOIS++ BNF Grammar
+
+
+
+   whois-command   =   ( system-command [":" "hold"]
+                       / terms [":" globalcnstrnts] ) NL
+
+   system-command  =   "constraints"
+                       / "describe"
+                       / "commands"
+                       / "polled-by"
+                       / "polled-for"
+                       / "version"
+                       / "list"
+                       / "show" [1*SP string]
+                       / "help" [1*SP string]
+                       / "?" [string]
+
+   terms           =   and-expr *("or" and-expr)
+
+   and-expr        =   not-expr *("and" not-expr)
+
+   not-expr        =   ["not"] (term / ( "(" terms ")" ))
+
+   term            =   generalterm / specificterm
+                       / shorthandle / combinedterm
+
+   generalterm     =   string *(";" localcnstrnt)
+
+   specificterm    =   specificname "=" string
+                       *(";" localcnstrnt)
+
+   specificname    =   "handle" / "value"
+
+   shorthandle     =   "!" string *(";" localcnstrnt)
+
+
+
+Deutsch, et al              Standards Track                    [Page 38]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+   combinedterm    =   string "=" string *(";" localcnstrnt)
+
+   globalcnstrnts  =   globalcnstrnt *(";" globalcnstrnt)
+
+   globalcnstrnt   =   localcnstrnt
+                       / "format" "=" format
+                       / "maxfull" "=" 1*digit
+                       / "maxhits" "=" 1*digit
+                       / opt-globalcnst
+
+   opt-globalcnst  =   "hold"
+                       / "authenticate" "=" auth-method
+                       / "name" "=" string
+                       / "password" "=" string
+                       / "language" "=" language
+                       / "incharset" "=" characterset
+                       / "ignore" "=" string
+                       / "include" "=" string
+
+   format          =   "full" / "abridged" / "handle" / "summary"
+                       / "server-to-ask"
+
+   language        = <The language code defined in RFC1766 [ALVE95]>
+
+   characterset    =   "us-ascii" / "iso-8859-1" / "iso-8859-2" /
+                       "iso-8859-3" / "iso-8859-4" / "iso-8859-5" /
+                       "iso-8859-6" / "iso-8859-7" / "iso-8859-8" /
+                       "iso-8859-9" / "iso-8859-10" / "utf-8" /
+                       charset-value
+
+   charset-value   =   1*char
+
+   localcnstrnt    =   "search" "=" searchvalue /
+                       "case" "=" casevalue
+
+   searchvalue     =   "exact" / "substring" / "regex" / "fuzzy"
+                       / "lstring"
+
+   casevalue       =   "ignore" / "consider"
+
+   auth-method     =   "password"
+
+   string          =   0*char
+
+   char            =   "\" specialchar
+                       / <Characters 0-255 (decimal) except specialchar>
+
+
+
+
+
+Deutsch, et al              Standards Track                    [Page 39]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+   specialchar     =   " " / <tab> / "=" / "," / ":" / ";" / "\" /
+                       "*" / "." / "(" / ")" / "[" / "]" / "^" /
+                       "$" / "!" / "?"
+
+   digit           =   "0" / "1" / "2" / "3" / "4" /
+                       "5" / "6" / "7" / "8" / "9"
+
+   NL              =   <CR LF (decimal 13 10)>
+
+
+   NOTE: Significant blanks must be escaped.  The following
+   characters, when significant to the query, may be preceded
+   and/or followed by a single blank:
+
+     : ; , ( ) = !
+
+Appendix G - Description of Regular expressions
+
+   The regular expressions described in this section is the same as used
+   in many other applications and operating systems. It is though very
+   simple and does not include logical operators AND and OR.
+
+   Searches using regular expressions are always using substring
+   matching except when the regular expression contains the characters
+   '^' or '$'.
+
+       Character                                Function
+       ---------                                --------
+
+        <any except those listed in this table> Matches itself
+
+        .                                       Matches any character
+
+        a*                                      Matches zero or more 'a'
+
+        [ab]                                    Matches 'a' or 'b'
+
+        [a-c]                                   Matches 'a', 'b' or 'c'
+
+        ^                                       Matches beginning of
+                                                a token
+
+        $                                       Matches end of a token
+
+
+
+
+
+
+
+
+Deutsch, et al              Standards Track                    [Page 40]
+
+RFC 1835          Architecture of the WHOIS++ service        August 1995
+
+
+          Examples
+          ---------
+
+            String         Matches       Matches not
+            -------        -------       -----------
+             hello          xhelloy         heello
+             h.llo          hello           helio
+             h.*o           hello           helloa
+             h[a-f]llo      hello           hgllo
+             ^he.*          hello           ehello
+             .*lo$          hello           helloo
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deutsch, et al              Standards Track                    [Page 41]
+