rfc1835.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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).