rfc1835.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,693 行 · 第 1/5 页
TXT
1,693 行
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]
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?