rfc1835.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,693 行 · 第 1/5 页

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