WDIFF

draft-ietf-wnils-whois-arch-01.txt --> draft-ietf-wnils-whois-arch-02.txt

Network Working Group Peter Deutsch
INTERNET-DRAFT BUNYIP INFORMATION SYSTEMS, inc
<draft-ietf-wnils-whois-arch-01.txt>
<draft-ietf-wnils-whois-arch-02.txt> Rickard Schoultz
Expires: 25 January July 95 KTHNOC
Patrik Faltstrom
KTH
BUNYIP INFORMATION SYSTEMS, inc
Chris Weider
BUNYIP INFORMATION SYSTEMS, inc

25 July 1994 January 1995

Architecture of the WHOIS++ service

STATUS OF THIS MEMO

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents docu-
ments at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as ``work in
progress.'' pro-
gress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ds.internic.net (US East Coast),
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
munnari.oz.au (Pacific Rim).

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 authenti-
cation mechanism for protecting all or part of the associated
WHOIS++ information database from unauthorized access is also
described.

The additional architectural issues and commands added to support
the distributed indexing service are described in [Weider94]. This
present document should be read in conjunction with the additional
reference.

Deutsch, et al [Page 1]
^L

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

1. January 1995

Table of contents

Part I - WHOIS++ Overview

1.1. Purpose and Motivation

The current NIC WHOIS service [HARR85] is used Motivation....................................... 2
1.2. Basic Information Model...................................... 3
1.2.1. Changes 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 current WHOIS Model......................... 3
1.2.2. Registering WHOIS++ servers................................ 4
1.2.3. The WHOIS++ Search Selection Mechanism..................... 5
1.2.4. The WHOIS++ Architecture................................... 6
1.3. Indexing in WHOIS++.......................................... 6
1.4. Getting Help................................................. 7
1.4.1. Minimum HELP Required...................................... 8
1.5. Options and simi-
lar services have also been set up on other hosts. Unfortunately,
these additions Constraints...................................... 8
1.6. Formatting Responses......................................... 8
1.7. Reporting Warnings and extensions have been done in an ad hoc Errors................................ 9
1.8. Privacy and
uncoordinated manner. Security Issues.................................. 9

Part II - WHOIS++ Implementation

2.1. Introduction................................................. 11
2.1.1. The basic WHOIS information model represents each individual record
as a Rolodex-like collection WHOIS++ interaction model.............................. 11
2.2. The WHOIS++ Command set...................................... 12
2.2.1. System Commands............................................ 12
2.2.1.1. The COMMANDS command..................................... 13
2.2.1.2. The CONSTRAINTS command.................................. 13
2.2.1.3. The DESCRIBE command..................................... 14
2.2.1.4. The HELP command......................................... 14
2.2.1.5. The LIST command......................................... 14
2.2.1.6. The POLLED-BY command.................................... 14
2.2.1.7. The POLLED-FOR command................................... 15
2.2.1.8. The SHOW command......................................... 15
2.2.1.9. The VERSION command...................................... 15
2.2.2. The Search Command......................................... 15
2.2.2.1. Format 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 relia-
bility, the huge volume Search Term.................................. 16
2.2.2.2. Format of traffic that a full scale directory ser-
vice will generate and the potentially huge number of users Search String................................ 17
2.3. WHOIS++ Constraints.......................................... 18
2.3.1. Required Constraints....................................... 18
2.3.2. Optional Constraints....................................... 19
2.3.2.1. The SEARCH Constraint.................................... 20
2.3.2.2. The FORMAT Constraint.................................... 21
2.3.2.3. The MAXFULL Constraint................................... 21
2.3.2.4. The MAXHITS Constraint................................... 21
2.3.2.5. The CASE Constraint...................................... 21
2.3.2.6. The AUTHENTICATE Constraint.............................. 21
2.3.2.7. The NAME Constraint...................................... 22
2.3.2.8. The PASSWORD Constraint.................................. 22
2.3.2.9. The LANGUAGE Constraint.................................. 22
2.3.2.10. The INCHARSET Constraint................................ 22
2.3.2.11. The IGNORE Constraint................................... 23
2.3.2.12. The INCLUDE Constraint.................................. 23

Deutsch, et al [Page 2]

Internet-Draft Architecture 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 WHOIS++ service
based upon a small set 25 January 1995

2.4. Server Response Modes........................................ 23
2.4.1. Default Responses.......................................... 24
2.4.2. Format of Responses........................................ 24
2.4.3. Syntax of extensions to the original WHOIS informa-
tion model. These extensions allow the new service to address the
community's needs for a simple directory service, yet the extensi-
ble 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 Formatted Response............................. 24
2.4.3.1. A FULL format response................................... 25
2.4.3.2. ABRIDGED Format Response................................. 26
2.4.3.3. HANDLE Format Response................................... 26
2.4.3.4. SUMMARY Format Response.................................. 27
2.4.3.5. SERVERS-TO-ASK Response.................................. 27
2.4.4. System Generated Messages.................................. 28
2.5. Compatibility with Older WHOIS data model
and query protocol and a companion extensible, distributed indexing
service. Servers....................... 28
3. Miscellaneous.................................................. 28
3.1. Acknowledgements............................................. 28
3.2. Contact information.......................................... 29

Appendix A number of other options have also been added, like
boolean operators, more powerful search constraints and search
methods and most specificly structured the data - Some Sample Queries................................... 30
Appendix B - Some sample responses................................. 31
Appendix C - Sample responses 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 unau-
thorized access is also briefly described. system commands................... 33
Appendix D - Sample whois++ session................................ 35
Appendix E - System messages....................................... 37
Appendix F - The additional architectural issues and commands added to support
an optional distributed indexing service are described in
[Weider93]. This present document should be read in conjunction
with the additional reference. WHOIS++ BNF Grammar............................... 39
Appendix G - Description of Regular expressions.................... 41

Deutsch, et al [Page 2]
^L 3]

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

The basic architecture of January 1995

1.
Part I - WHOIS++ allows distributed maintenance of
the directory contents Overview

1.1. Purpose and the use of the WHOIS++ indexing service
for locating additional Motivation

The current NIC WHOIS servers. Although a general overview
of this service [HARR85] is included for completeness, the reader is
referred used to [Weider94] for full details provide a very
limited directory service, serving information about a small number
of Internet users registered with the indexing extensions.

1.2. Basic Information Model

Our extensions to DDN NIC. Over time the existing WHOIS basic
service are centered upon a
recommendation has been expanded to structure user information around a series of
standardized serve additional information templates, such as to those described by
[IAFA1]. Such templates consist of ordered sets of data elements
(or attribute-value pairs) and a number of groups at the IETF are
now working simi-
lar services have also been set up on standardizing their format and content [IAFA],
[NIR].

It is intended that adding such structured templates to a server other hosts. Unfortunately,
these additions and subsequently identifying extensions have been done in an ad hoc and searching them be simple tasks.
uncoordinated manner.

The creation and use of customized templates should also be possi-
ble with little effort, although their use should be discouraged
where appropriate standardized templates exist.

We also offer basic WHOIS information model represents each individual record
as a set Rolodex-like collection of extensions to the trivial protocol described
in RFC954 [HARR85] text. Each record has a unique
identifier (or handle), but otherwise is assumed to allow the user have little
structure. The current service allows users to constrain issue searches to
desired attributes or template types, in addition to the existing
commands for specifying
individual strings within individual records, as well as searches
for individual record handles or simple strings.

It is expected that the minimalist approach we have taken will find
application where using a very simple query-response
protocol.

Despite its utility, the high cost of configuring and operating tradi-
tional current NIC WHOIS service cannot function
as a general White Pages services can not currently be justified.

Also note that service for the new architecture makes no assumptions about entire Internet. Given the
search and retrieval mechanisms used within individual servers.
Operators are free
inability of a single server to use dedicated database formats, fast indexing
software offer guaranteed response or even provide gateways to other relia-
bility, the huge volume of traffic that a full scale directory services to
store ser-
vice will generate and retrieve information, if desired.

The WHOIS++ server simply functions as the potentially huge number of users of such
a known front end, offering service, such a simple data model trivial architecture is obviously unsuitable for
the current Internet's needs for information services.

This document describes the architecture and communicating through protocol for WHOIS++,
a well known port simple, distributed and
query protocol. The format extensible information lookup service
based upon a small set of both queries and replies has been
structured extensions to the original WHOIS informa-
tion model. These extensions allow the use of client software for generating
searches and displaying new service to address the results. At
community's needs for a simple directory service, yet the same time, some effort
has been made extensi-
ble architecture is expected to keep responses at least also allow it to some degree readible by
humans, find application
in a number of other information service areas.

Added features include an extension to ensure low entry cost the trivial WHOIS data model
and to ease debugging.

The actual implemention details of query protocol and a companion extensible, distributed indexing
service. A number of an individual WHOIS other options have also been added, like
boolean operators, more powerful search
engine are left constraints and search
methods and most specificly structured the data to make both the imagination
client and the server part of the implementor dialogue more stringent and it
parseable. An optional authentication mechanism for protecting all
or parts of the associated WHOIS++ information database from unau-
thorized access is
hoped that also briefly described.

The basic architecture of WHOIS++ allows distributed maintenance of
the simple, extensible approach taken will encourage
experimentation directory contents and the development use of improved search engines. the WHOIS++ indexing service
for locating additional WHOIS servers. Although a general overview
of this service is included for completeness, the indexing exten-
sions are described in a separate paper.

Deutsch, et al [Page 3]
^L 4]

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

1.2.1. Changes January 1995

1.2. Basic Information Model

Our extensions to the current WHOIS Model

The current existing WHOIS service is based are centered upon an extremely simple data
model. The NIC WHOIS database consists of a
recommendation to structure user information around a series of individual
records, each of which is identified
standardized information templates, such as to those described by a single unique identifer
(the "handle"). Each record contains one or more lines
[IAFA1]. Such templates consist of informa-
tion. Currently, there is no structure or implicit ordering ordered sets of this
information, although by implication each record is concerned with
information about data elements
(or attribute-value pairs) and 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 number of groups at the database records. In
effect, each record IETF are
now working on standardizing their format and content [IAFA],
[NIR].

It is based upon one of intended that adding such structured templates to a specified set server
and subsequently identifying and searching them be simple tasks.
The creation and use of tem-
plates, each containing customized templates should also be possi-
ble with little effort, although their use should be discouraged
where appropriate standardized templates exist.

We also offer a finite and specified number set of data ele-
ments. This extensions to the trivial protocol described
in RFC954 [HARR85] to allow users the user to easily limit constrain searches to specific col-
lections 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++ data-
base on the Internet be assigned a unique handle, analogous
desired attributes or template types, in addition to the
handle associated with each database record.

The WHOIS++ database structure existing
commands for specifying handles or simple strings.

It is shown in Fig. 1.

1.2.2. Registering WHOIS++ servers

We propose expected that individual database handles be registered through the Internet Assigned Numbers Authority (the IANA), ensuring their
uniqueness. This minimalist approach we have taken will allow us to specify each WHOIS++ entry on find
application where the
Internet as a server handle and a unique record handle pair. This
pair is called the ``composed handle''.

A unique registered handle is preferable to using the host's IP
address, since it is conceivable high cost of configuring and operating tradi-
tional White Pages services can not currently be justified.

Also note that the WHOIS++ server for a par-
ticular domain may move over time. If we preserve the unique
WHOIS++ handle in such cases we have new architecture makes no assumptions about the option of using it for
resource discovery
search and networked information retrieval (see [IIIR]
for a discussion of resource and discovery and support issues).
There mechanisms used within individual servers.
Operators are many ways of guaranteeing uniqueness of 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 handles;
we will discuss them in simply functions as a separate paper.

We believe that organizing information around known front end, offering
a series of such tem-
plates will make it easier for administrators to gather simple data model and main-
tain this information communicating through a well known port and thus encourage them
query protocol. The format of both queries and replies has been
structured to make such informa-
tion available. allow the use of client software for generating
searches and displaying the results. At the same time, as users become more familiar
with the data elements available within specific templates they
will be better able some effort
has been made to specify their searches, leading keep responses at least to a more
useful service.

Deutsch, et al [Page 4]
^L

Internet-Draft Architecture some degree readible by
humans, to ensure low entry cost and to ease debugging.

The actual implemention details of of an individual WHOIS search
engine are left to the imagination of the WHOIS++ 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 25 July 1994

______________________________________________________________________
| |
| + Single unique WHOIS++ is based upon an extremely simple data
model. The NIC WHOIS database handle |
| |
| _______ _______ _______ |
| handle3 |.. .. | handle6 |.. .. | handle9 |.. .. | |
| _______ | _______ | _______ | |
| handle2 |.. .. | handle5 |.. .. | handle8 |.. .. | |
| _______ | _______ | _______ | |
| handle1 |.. .. | handle4 |.. .. | handle7 |.. .. | |
| |.. .. | |.. .. | |.. .. | |
| ------- ------- ------- |
| Template Template Template |
| Type 1 Type 2 Type 3 |
| |
| |
| |
| |
| Fig.1 - Structure consists of a WHOIS++ database. |
| |
| Notes: - Entire database series of individual
records, each of which is identified by a single unique WHOIS |
| handle. |
| - identifer
(the "handle"). Each record has a single unique handle and a specific set |
| contains one or more lines of attributes, determined informa-
tion. Currently, there is no structure or implicit ordering of this
information, although by the template type used. |
| - Each value associated with an attribute can be any ASCII |
| string up to a specified length. |
|______________________________________________________________________|

1.2.3. The WHOIS++ Search Selection Mechanism

The WHOIS++ search mechanism implication each record is intended to be extremely simple. A
search command consists of one or more search terms, concerned with an
optional nvset

Deutsch, et al [Page 5]

Internet-Draft Architecture of global constraints (specifiers that modify or
control a search).

Search terms allow the WHOIS++ service 25 January 1995

information about a single user to specify template type, attribute,
value or handle that any record returns must satisfy. Each search
term can service.

We have an optional set of local constraints that apply implemented two basic changes to
only that term.

A WHOIS++ this model. First, we have
structured the information within the database may be seen as a single rolodex-like collection collections of typed records.
data elements, or simple attribute/value pairs. Each term specifies individual
record contains a further constraint that
the selected specified ordered set of output records must satisfy. Each term may thus
be thought these data elements.

Secondly, we have introduced typing of as performing a subtractive selection, in the sense
that any database records. In
effect, each record that does not fulfill the term is discarded from
the result set. Boolean searches are possible by the use based upon one of AND,
OR, NOT a specified set of tem-
plates, each containing a finite and parenthesis.

Deutsch, et al [Page 5]
^L

Internet-Draft Architecture specified number of the WHOIS++ service 25 July 1994

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, which is described
in [Weider94]. A single physical server can act data ele-
ments. This allow users to easily limit searches to specific col-
lections of information, such as both a base
level server information about users, services,
abstracts of papers, descriptions of software, and an indexing server.

A so on.

As a final extension, we require that each individual WHOIS++ data-
base level server is one which contains only filled templates. An
indexing server is one which contains forward knowledge (q.v.) and
pointers on the Internet be assigned a unique handle, analogous to other indexing servers or base level servers.

1.3. Indexing in the
handle associated with each database record.

The WHOIS++

Indexing database structure is shown in Fig. 1.

1.2.2. Registering WHOIS++ is used to tie together many base level servers
and index servers into

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 unified directory service.

Each base level server handle and index server which wishes to participate
in a unique record handle pair. This
pair is called the unified directory service must generate "forward knowledge"
for ``composed handle''.

A unique registered handle is preferable to using the entries host's IP
address, since it contains. One type of forward knowledge is conceivable that the WHOIS++ server for a par-
ticular domain may move over time. If we preserve the
"centroid", discussed unique
WHOIS++ handle in [Weider94].

An example such cases we have the option of using it for
resource discovery and networked information retrieval (see [IIIR]
for a centroid is as follows: if a whois++ discussion of resource and discovery and support issues).
There are many ways of guaranteeing uniqueness of server con-
tained 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 handles;
we will discuss them in a separate paper.

We believe that organizing information around a series of such tem-
plates will make it easier for administrators to gather and main-
tain this server would information and thus encourage them to make such informa-
tion available. At the same time, as users become more familiar
with the data elements available within specific templates they
will 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 better able to specify their searches, leading to a more
useful service.

Deutsch, et al [Page 6]
^L

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

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.

Implementors of this protocol are strongly encouraged to incor-
porate centroid generation abilities into their servers, and to
read [Weider94] carefully.

-------------------------------------------------------------------

____ ____
top level January 1995

____ ____
first level handle3 |.. .. | handle6 |.. .. | handle9 |.. .. | |
whois index
| _______ | _______ | _______ | |
servers ---- ----

____ ____ ____
individual
| handle2 |.. .. | handle5 |.. .. | handle8 |.. .. | |
|
whois servers _______ | _______ | _______ | |
| handle1 |.. .. |
---- ---- ----

Fig. handle4 |.. .. | handle7 |.. .. | |
| |.. .. | |.. .. | |.. .. | |
| ------- ------- ------- |
| Template Template Template |
| Type 1 Type 2 Type 3 |
| |
| |
| |
| |
| Fig.1 - 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 Structure of help commands,
allowing users to find out information about both the individual
server and the entire a WHOIS++ service itself. This database. |
| |
| Notes: - Entire database is done in the
context of the new extended information model identified 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, single unique WHOIS |
| handle. |
| - Each record has a single example of SERVICES unique handle and HELP records, which can be accessed
through appropriate commands.

Deutsch, et al [Page 7]
^L

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

1.4.1. Minimum HELP Required

Executing the command:

DESCRIBE

gives a brief information about the WHOIS++ server.

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 specific set |
| of additional optional
commands and constraints attributes, determined by the template type used. |
| - Each value associated with an attribute can be supported. These would allow users any ASCII |
| string up to perform such tasks as provide security options, modify the
information contents of a server or add multilingual support. specified length. |
|______________________________________________________________________|

1.2.3. The
required set of WHOIS++ commands are summarized in section 2.2. WHOIS++ constraints are described in section 2.4. Optional commands
and constraints are described in section 2.5.

1.6. Formatting Responses Search Selection Mechanism

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) and the ability mechanism is intended to encode
graphics and other information, using the MIME message encoding
format.

All output of searches will be returned in one extremely simple. A
search command consists of six output for-
mats, which will be one of FULL, ABRIDGED, HANDLE, SUMMARY,
SERVERS-TO-ASK or MIME. Note more search terms, with an
optional nvset of global constraints (specifiers that modify or
control a conforming server is only
required to support search).

Search terms allow the first four formats.

When available, SERVERS-TO-ASK format is used user to indicate 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 fulfill the term is discarded from
the result set. Boolean searches are possible by the use of AND,
OR, NOT and parenthesis.

Deutsch, et al [Page 8]
^L 7]

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

search cannot be completed but that one or more alternative January 1995

1.2.4. The WHOIS++
servers may be able to perform Architecture

The WHOIS++ directory service has an architecture which is
separated into two components; the search.

When available, MIME format base level server, which is used to encode output
described in MIME format
[BORE93] this paper, and [MOOR93]. This allows the response 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 include attri-
bute values other indexing servers or base level servers.

1.3. Indexing in different character sets.

Details of each output format are specified WHOIS++

Indexing in section 2.5.

1.7. Reporting Warnings and Errors

The formatted response of WHOIS++ commands allows the encoding of
warning or error messages is used to simplify parsing and machine handling.
The syntax of output formats are described in detail in section
2.5, tie together many base level servers
and details of WHOIS++ warnings index servers into a unified directory service.

Each base level server and error conditions are given
in section appendix E.

All system messages are numerical, but can be tagged with text. It
is the clients decision if the text is presented index server which wishes to participate
in the user.

1.8. Privacy and Security Issues

The basic WHOIS++ unified directory service was conceived as a simple, unauthenti-
cated 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 generate "forward knowledge"
for the
actual authentication scheme used, entries it merely provides a framework
for indicating that a particular transaction contains. One type of forward knowledge is to be authenti-
cated, 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
"centroid".

An example of username and password a centroid is sent together with the
search string so the as follows: if a whois++ server can verify that the user have access to
the information. Note that this is NOT by any means a method recom-
mended to secure the data itself because both password and informa-
tion are tranferred unencrypted over the network.

Given the unauthenticated nature that default services like white
pages services are, it is easy to either forget con-
tained 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 implications of centroid for this and just show all data to the public Internet, or think that 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

Deutsch, et al [Page 9]
^L 8]

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

Internet is so dangerous that information is hidden from January 1995

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 Inter-
net so servers that the whole idea of index server knows
about can be searched with a global whitepages service is lost.
Therefore single query to the type of authentication scheme selected and index server; the public
nature of
index server holds the Internet environment must still be taken into con-
sideration when assessing forward knowledge along with pointers to the security
servers it indexes, and authentication of can refer the query to servers which might
hold information served.

A more detailed exposition on security is outside which satisfies the scope query.

Implementors of this
document.

Deutsch, et al [Page 10]
^L

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

2. Part II - WHOIS++ Implementation

2.1. Introduction

The WHOIS++ protocol specifies the interactions between a WHOIS
client and a WHOIS server supporting the WHOIS++ extensions. These
extensions are designed strongly encouraged to incor-
porate centroid generation abilities into their servers.

-------------------------------------------------------------------

Fig. 2 - Indexing system architecture.

-------------------------------------------------------------------

1.4. Getting Help

Another extension to be backwards compatible with existing
servers, in the sense basic WHOIS service is the requirement
that all servers support at least a new server receiving any minimal set of help commands,
allowing users to find out information about both the older
commands specified in RFC 954 [HARR85] will behave in the same
manner as individual
server and the original NIC WHOIS server.

Obviously, it entire WHOIS++ service itself. This is not possible to ensure desired behaviour if one done in the
context of the new extended commands is sent information model by defining two
specific template formats and requiring each server to an older offer at
least one example of each record using these formats. The operator
of each WHOIS server, since the
requested functionality service is simply not there. Still, it would be
possible therefor expected to query whether the WHOIS++ command set is supported have, as
an attribute for each WHOIS server in an appropriate services
registry (which itself could be set up using a WHOIS++ server).
Thus, in practice this should not be minimum, a problem. In addition, any
such command sent to an older WHOIS server would simply
single example of SERVICES and HELP records, which can be treated
as accessed
through appropriate commands.

Deutsch, et al [Page 9]

Internet-Draft Architecture of the WHOIS++ service 25 January 1995

1.4.1. Minimum HELP Required

Executing the command:

DESCRIBE

gives a search term, and thus no harm brief information about the WHOIS++ server.

Executing the command:

HELP

gives a brief description of the WHOIS++ service itself.

The text of both required helped records should result. 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 small number WHOIS++ service is based upon a minimal core set of older servers, commands
and the probability that at
least some controlling constraints. A small set of the older servers will additional optional
commands and constraints can be converted supported. These would allow users
to WHOIS++ perform such tasks as
implementations become available, means that backwards compatibil-
ity is not expected to be provide security options, modify the
information contents of a problem in practice.

2.1.1. server or add multilingual support. The
required set of WHOIS++ interaction model

A commands are summarized in section 2.2.
WHOIS++ server will normally listen for a TCP connections on the
allocated WHOIS port (port 43) (although constraints are described in section 2.4. Optional commands
and constraints are described in section 2.5.

1.6. Formatting Responses

The output returned by a WHOIS++ server can be
accessed over any TCP connection). Once a connection is esta-
blished, the server issues a banner message, then 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 con-
straint is specified as part of any command, the server continues structured to listen on the connection for another line of input. This cycle
continues as long as allow
machine parsing and automated handling. Of particular interest in
the sender continues ability to append the required
HOLD constraint return summary information about a search (without
having to each subsequent command.

At return the same time, each server is permitted to set an optional
timeout value (which should entire results).

All output of searches will be indicated returned in the response to the
CONSTRAINTS command). If set, the one of five output for-
mats, which will be one of FULL, ABRIDGED, HANDLE, SUMMARY or
SERVERS-TO-ASK. Note that a conforming server is free only required to terminate an
idle connection at any time after this delay has passed with no
input from the client. If the server terminates
support the connection due first four formats.

When available, SERVERS-TO-ASK format is used to timeout, it will indicate that a
search cannot be indicated by the system message. The timeout
value is not changeable by completed but that one or more alternative WHOIS++
servers may be able to perform the client. search.

Deutsch, et al [Page 11]
^L 10]

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

2.2. The WHOIS++ Command set

There are two types January 1995

Details 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 each output format are not required by all
servers. specified in section 2.5.

1.7. Reporting Warnings and Errors

The set formatted response of required WHOIS++ system commands are listed in
Table I. Details of the allowable search terms for the search com-
mand are included in Table II.

Each WHOIS++ command also allows the use encoding of one
warning or more controlling
constraints, which select can be used error messages to override defaults or oth-
erwise 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) simplify parsing and MAXHITS (which determines
the maximum number machine handling.
The syntax of matches that a a search can return). These
required constraints output formats are summarized described in Table III.

An additional set of optional constraints are used to provide sup-
port for different character sets, indicate the need detail in section
2.5, and type details of
authentication to perform on a transaction, WHOIS++ warnings and permit multiple
transactions during a single communications session. These optional
constraints error conditions are listed given
in Table IV. section appendix E.

All system messages are numerical, but can be tagged with text. It
is possible, using the required COMMANDS and CONSTRAINTS system
commands, clients decision if the text is presented to query any WHOIS++ server for its list of supported
commands the user.

1.8. Privacy and constraints.

2.2.1. System Commands

System commands Security Issues

The basic WHOIS++ service was conceived as a simple, unauthenti-
cated information lookup service, but there are commands to 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 server 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 information or to
control its operation. These include commands indicating that a particular transaction is to list be authenti-
cated, and the template
types available from appropriate mechanisms to use. This mechanism is
extensible and individual servers, implementors are free to obtain add additional
mechanisms.

This document includes a single blank
template very simple authentication scheme where a
combination of any available type, username and commands to obtain password is sent together with the list of
valid commands and constraints supported on a server.

There are also commands to obtain
search string so the current version of server can verify that the
WHOIS++ protocol supported, to user have access a simple help subsystem, to
obtain a brief description of
the service (which information. Note that this is intended, among
other things, NOT by any means a method recom-
mended to support secure the automated registration of data itself because both password and informa-
tion are tranferred unencrypted over the service
by yellow network.

Given the unauthenticated nature that default services like white
pages directory services). All of these commands are
required 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 Inter-
net so the whole idea of a conforming WHOIS++ server.

------------------------------------------------------------------------

Short Long Form Functionality
----- --------- -------------
COMMANDS [ ':' HOLD ] list valid global whitepages service is lost.
Therefore the type of authentication scheme selected and the public
nature of the Internet environment must still be taken into con-
sideration when assessing the security and authentication of the
information served.

Deutsch, et al [Page 11]

Internet-Draft Architecture of the WHOIS++ commands service 25 January 1995

A more detailed exposition on security is outside the scope of this
document.

Deutsch, et al [Page 12]
^L

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

supported by this server

CONSTRAINTS [ ':' HOLD ] List valid constraints
supported by this server

DESCRIBE [ ':' HOLD ] Describe this server,
formating January 1995

2. Part II - WHOIS++ Implementation

2.1. Introduction

The WHOIS++ protocol specifies the response using interactions between a WHOIS
client and a WHOIS server supporting the standard IAFA "Services"
template

'?' HELP [<string> [':' <cnstrnts>]] System help, using standard
IAFA "Help" template

LIST [<string> [':' <cnstrnts>]] List templates supported
by this system

POLLED-BY [ ':' HOLD ] List indexing servers
that WHOIS++ extensions. These
extensions are know designed to track
this server

POLLED-FOR [ ':' HOLD ] List information about
what this be backwards compatible with existing
servers, in the sense that a new server is
tracking for

SHOW <string> [':' <cnstrnts>] Show contents receiving any of templates the older
commands specified

VERSION [ ':' HOLD ] return current version of in RFC 954 [HARR85] will behave in the protocol supported.

Table I - Required WHOIS++ SYSTEM commands.

------------------------------------------------------------------------

Below follows a descriptions for each command. Examples of
responses to each command same
manner as the original NIC WHOIS server.

Obviously, it is in Appendix C.

2.2.1.1. The COMMANDS command

The COMMANDS command returns a list not possible to ensure desired behaviour if one of
the extended commands that is sent to an older WHOIS server, since the server
supports. The response
requested functionality is formatted simply not there. Still, it would be
possible to query whether the WHOIS++ command set is supported as
an ABRIDGED response.

2.2.1.2. The CONSTRAINTS command

The CONSTRAINTS attribute for each WHOIS server in an appropriate services
registry (which itself could be set up using a WHOIS++ server).
Thus, in practice this should not be a problem. In addition, any
such command returns sent to an older WHOIS server would simply be treated
as a list search term, and thus no harm should result.

The small number of constraints older servers, and the
values of those probability that at
least some of the server supports. The response is formatted older servers will be converted to WHOIS++ as a FULL response, where every constraint
implementations become available, means that backwards compatibil-
ity is represented as not expected to be a
separate record. problem in practice.

2.1.1. The template name WHOIS++ interaction model

A WHOIS++ server will normally listen for these records is CONSTRAINT.
No attention is paid to handles. Each record has, as a minimum, the

Deutsch, et al [Page 13]
^L

Internet-Draft Architecture of TCP connections on the
allocated WHOIS port (port 43) (although a WHOIS++ service 25 July 1994

following two fields:

- "Constraint", which contains the attribute name described -
"Default", which shows server can be
accessed over any TCP connection). Once a connection is esta-
blished, the default value server issues a banner message, then listens for
input. The command specified in this constraint. input is processed and the
results returned including an ending system message. If the client
optional HOLD constraint has not been specified the connection is permitted to change
then terminated.

If the value of server supports the optional HOLD constraint,
there is also:

- "Range" field, which contains a list of values that and this
server supports, as a comma separated list; Or, if the range con-
straint is numerical, specified as a pair part of numbers separated with a hyphen.

2.2.1.3. The DESCRIBE command

This is equivalent to issuing the search command on any command, the local server with only the terms "template=services" and
"subject=describe" and will result in continues
to listen on the display connection for another line of input. This cycle
continues as long as the
corresponding SERVICES template with an attribute of "subject" and
value of "describe", except that sender continues to append the DESCRIBE command only searches
local information and may not return pointers required
HOLD constraint to other servers.

2.2.1.4. The HELP command

The HELP command takes each subsequent command.

At the same time, each server is permitted to set an optional argument as subject to get help
for. This is equivalent
timeout value (which should be indicated in the response to issuing the search command on
CONSTRAINTS command). If set, the local server only with the terms "template=help and subject=<subject>"
(or "subject=help" if no argument specified) and will result in the
display of the corresponding HELP template is free to terminate an
idle connection at any time after this delay has passed with subject "help".
The HELP command differs no
input from the above search command in that the
HELP command only searches local information and may not return
pointers to other servers.

2.2.1.5. The LIST command

The LIST command returns the name of the templates available on the
server. The answer is in ABRIDGED format with client. If the template name as server terminates the first word on each line.

2.2.1.6. The POLLED-BY command

The POLLED-BY command returns a list of servers and connection due
to timeout, it will be indicated by the templates
and attribute names that those server polled as centroids from this
server. system message. The format is in FULL format with two attributes, Template
and Field. Each of these timeout
value is a list of names of not changeable by the templates or
fields polled. client.

Deutsch, et al [Page 14]
^L 13]

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

2.2.1.7. January 1995

2.2. The POLLED-FOR command WHOIS++ Command set

There are two types of WHOIS++ commands - system commands and the
WHOIS++ search command.

The POLLED-FOR WHOIS++ command returns set consists of a list core set of servers that this server
has polled, and the template required systems
commands, a single required search command and attribute names for each an set of those. optional
system commands which support features that are not required by all
servers. The answer is set of required WHOIS++ system commands are listed in FULL format with two attributes, Template and
Field.

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

This is equivalent to issuing
Table I. Details of the allowable search command on the local
server only with the terms "template=version" and will result in
the display of the VERSION template, except that for the VERSION search com-
mand only searches local information and may not return pointers to
other servers.

The output format is a FULL response containg a record with tem-
plate name VERSION. The handle for this record is unspecified. The
record must have attribute name "Version", which value is "1.0" for
this version of the protocol. The record may are included in Table II.

Each WHOIS++ command also have the addi-
tional fields "Program-Name" and "Program-Version" which gives
information about the server implementation if allows the server so
desires.

2.2.2. The Search Command

A search command consists use of one or more search terms, which might
each have local controlling
constraints, followed by an optional colon with which select can be used to override defaults or oth-
erwise modify server behavior. There is a core set of global search constraints.

Each attribute value in the WHOIS++ database is divided into one or
more words separated constraints
that must be supported by whitespace. Each search term operates on
every word in all conforming servers. These include
SEARCH (which controls the attribute value.

Two or more type of 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 performed), FORMAT (which
determines the search term they are bound to. The search terms output format used) and MAXHITS (which determines
the

Deutsch, et al [Page 15]
^L

Internet-Draft Architecture maximum number of the WHOIS++ service 25 July 1994

global constraints are separated with matches that 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 combi-
nation of different search constraints is uncombinable, the server
may choose to ignore some constraints, but still do the search and
return some records.

The set of return). These
required constraints are summarized in Table III. The

An additional set of optional constraints are summarized used to provide sup-
port 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.

As an option,

It is possible, using the required COMMANDS and CONSTRAINTS system
commands, to query any WHOIS++ server may accept specifications for attributes its list of supported
commands and constraints.

2.2.1. System Commands

System commands are commands to the server for either inclusion information or exclusion to
control its operation. These include commands to list the template
types available from individual servers, to obtain a reply. Thus, users could
specify _only_ those attributes single blank
template of any available type, and commands 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 obtain the following:

1) A search string, followed by an optional comma and set of
comma-separated local constraints.

2) A search term specifier (as listed in Table II), followed by '=',
followed by a search string, an optional comma and a set list of
comma-separate local constraints.

3) An abbreviated search term specifier, followed by a search
string, followed by an optional comma
valid commands and set of comma-separate
local constraints.

4) A combination of attribute name, followed by '=', followed by constraints supported on a
search string, followed by an optional comma and set of
comma-separate local constraints.

If no term identifier is provided, then the search will be applied
to attribute values only. This corresponds server.

There are also commands to an identifier of
VALUE.

If a HANDLE specifier is used then obtain the search term can specify
either a composed handle or a record handle. The server is respon-
sible for resolving current version of the composed handle
WHOIS++ protocol supported, to access a server handle and a
record handle.

If a SEARCH-ALL specifier is used then the search will be applied simple help subsystem, to all template names, handles, attribute names and attribute
values.

When the user specifies the search term using the form:

Deutsch, et al [Page 16]
^L

Internet-Draft Architecture
obtain a brief description of the WHOIS++ service 25 July 1994

"<attribute_name> = <value>"

this (which is considered intended, among
other things, to be an ATTRIBUTE-VALUE search.

For discussion support the automated registration of the system reply format, and selecting the
appropriate reply format, see section 2.5.

----------------------------------------------------------------------

Valid specifiers:
-----------------

Name service
by yellow pages directory services). All of these commands are
required from a conforming WHOIS++ server.

------------------------------------------------------------------------

Short Long Form 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
COMMANDS [ ',' <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 ':' HOLD ] list 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 circum-
flex '^'. WHOIS++ commands

Deutsch, et al [Page 17]
^L 14]

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

If the search term is given in some other character set than ISO-
8859-1, it must be specified January 1995

supported by the constraint INCHARSET.

2.3. WHOIS++ Constraints

Constraints are intended to be hints or recommendations to the this server about how to process a command. They may also be used to
override default behaviour, such as requesting

CONSTRAINTS [ ':' HOLD ] List valid constraints
supported by this server

DESCRIBE [ ':' HOLD ] Describe this server,
formating the response using
the standard IAFA "Services"
template

'?' HELP [<string> [':' <cnstrnts>]] System help, using standard
IAFA "Help" template

LIST [':' <cnstrnts>] List templates supported
by this system

POLLED-BY [ ':' HOLD ] List indexing servers
that a are know to track
this server not
drop

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 connection after performing protocol supported.

Table I - Required WHOIS++ SYSTEM commands.

------------------------------------------------------------------------

Below follows a descriptions for each command.

Thus, a user might specify Examples of
responses to each command is in Appendix C.

2.2.1.1. The COMMANDS command

The COMMANDS command returns a search constraint as "SEARCH=exact",
which means list of commands that the search engine server
supports. The response is to perform formatted as an exact match
search. It might also specify "LANGUAGE=Fr", which implies ABRIDGED response.

2.2.1.2. The CONSTRAINTS command

The CONSTRAINTS command returns a list of constraints and the
values of those 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. supports. The not-
able exception response is "HOLD", which takes no argument.

All constraints can be used formatted
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 con-
straints supported by an individual server.

If a server cannot satisfy the specified FULL response, where every constraint there will be is represented as a
mechanism
separate record. The template name for informing the user in the reply, using system mes-
sages. In such cases, the search these records is still performed, with the CONSTRAINT.
No attention is paid to handles. Each record has, as a minimum, the
server ignoring unsupported constraints.

2.3.1. Required Constraints

The following CONSTRAINTS must be supported in all conforming
WHOIS++ servers.

Deutsch, et al [Page 18]
^L 15]

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

------------------------------------------------------------------

Format LOCAL/GLOBAL
------ -------------

SEARCH= {exact | lstring } LOCAL/GLOBAL

FORMAT= {full | abridged | handle | summary } GLOBAL

MAXHITS= { 1-<max-allowed> } GLOBAL

Table III - Required WHOIS++ constraints.

------------------------------------------------------------------

2.3.2. Optional CONSTRAINTS

The January 1995

following CONSTRAINTS and constraint values are not required of
a conforming WHOIS++ server, but may be supported. two fields:

- "Constraint", which contains the attribute name described -
"Default", which shows the default value for this constraint.

If supported,
their names and supported values must be returned in the response client is permitted to change the CONSTRAINTS command.

Deutsch, et al [Page 19]
^L

Internet-Draft Architecture value of the WHOIS++ service 25 July 1994

---------------------------------------------------------------------

Format LOCAL/GLOBAL
------ -------------

SEARCH= { regex | fuzzy | substring | <X-format> } LOCAL/GLOBAL

CASE= { ignore | consider } LOCAL/GLOBAL

FORMAT= { servers-to-ask | mime | <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.

----------------------------------------------------------------------

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 constraint,
there is also:

- "Range" field, which contains a definition list of each search method.

exact The search will succeed for a word values that exactly
matches the search string.

substring The search will succeed for this
server supports, as a word that matches comma separated list; Or, if the range
is numerical, as a part pair of numbers separated with a word.

regex hyphen.

2.2.1.3. The search will succeed for a word when a regular
expression matches the searched data. Regular
expression DESCRIBE command

This is built up by using constructions of
'*', '.', '^', '$', and '[]'. For use of
regular expressions see Appendix G.

Deutsch, et al [Page 20]
^L

Internet-Draft Architecture of equivalent to issuing the WHOIS++ service 25 July 1994

fuzzy The search will succeed for words that matches command on the
search string by using an algorithm designed to catch
closely related names with different spelling, e.g.
names local
server with only the same pronounciation. The server
chooses which algorithm to use, but it may vary
depending on terms "template=services" and
"subject=describe" and will result in the display of the
corresponding SERVICES template name, with an attribute name of "subject" and
language used (see Constraint Language above).

lstring The search will succed for words
value of "describe", except that begins
with the search string.

2.3.2.2. DESCRIBE command only searches
local information and may not return pointers to other servers.

2.2.1.4. The FORMAT Constraint HELP command

The FORMAT constraint describes what format the result will be in.
Default format HELP command takes an optional argument as subject to get help
for. This 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 equivalent to issuing the number of matching
records search command on the local
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, only with the
server terms "template=help and subject=<subject>"
(or "subject=help" if no argument specified) and will return the response result in SUMMARY format if the number
display of
hits exceeds 2, the MAXFULL constraint is set to 2 by corresponding HELP template with subject "help".
The HELP command differs from the server.

Regardless of what format above search command in that the client did or did
HELP command only searches local information and may not ask for, the
server will change the response format return
pointers to SUMMARY when the number
of matching records equals or exceeds this value.

2.3.2.4. other servers.

2.2.1.5. The MAXHITS Constraint LIST command

The MAXHITS constraint sets LIST command returns the maximum number name of records the
client can get templates available on the
server. The answer is in a search respone.

2.3.2.5. ABRIDGED format with the template name as
the first word on each line.

2.2.1.6. The CASE Constraint POLLED-BY command

The CASE constraint defines if the search should be done case sen-
sistive or not. Default value is to have case ignored.

2.3.2.6. The AUTHENTICATE Constraint POLLED-BY command returns a list of servers and the templates
and attribute names that those server polled as centroids from this
server. The AUTHENTICATE constraint describes which authentication method 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.

Deutsch, et al [Page 21]
^L 16]

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

to use when executing the search. By using January 1995

2.2.1.7. The POLLED-FOR command

The POLLED-FOR command returns a specific authentica-
tion method, some other constraints might be needed which is speci-
fied by list of servers that this server
has polled, and the authentication method. template and attribute names for each of those.
The only authentication method described in this document answer is "pass-
word", if used, also the in FULL format with two other constraints "name" attributes, Template and "pass-
word" need to be set.

2.3.2.7.
Field.

2.2.1.8. The USER Constraint SHOW command

The USER constraint is only used together with some authentication
method named by the constraint "authenticate". SHOW command takes a template name as argument and returns
information about a specific template, formatted as a FULL
response. The only use
described in this document answer is by sending a username formatted as a string of
characters which together blank template with the string given as an argument to
the "password" constraint
requested name.

2.2.1.9. The VERSION command

This is sent equivalent to issuing the server. The search command on the local
server can use
that pair of strings to do a simple authentication check, like only with the
UNIX login program do.

2.3.2.8. The PASSWORD Constraint

The PASSWORD constraint is only used together with some authentica-
tion method named by terms "template=version" and will result in
the constraint "authenticate". The display of the VERSION template, except that the VERSION com-
mand only use
described in this document searches local information and may not return pointers to
other servers.

The output format is by sending a password as FULL response containg a string of
characters which together record with the string given as an argument to
the "user" constraint tem-
plate name VERSION. The handle for this record is sent to the server. unspecified. The server can use
that pair
record must have attribute name "Version", which value is "1.0" for
this version of strings to do a simple authentication check, like the
UNIX login program do.

2.3.2.9. The LANGUAGE Constraint protocol. The LANGUAGE constraints can be used as an extra information to record may also have the
fuzzy matching search method, addi-
tional fields "Program-Name" and it might also be used to tell "Program-Version" which gives
information about the server to give the system responses in another language, although
this ability should be handled by implementation if the client. server so
desires.

2.2.2. The two-letter
language code defined in ISO 639:1988 can be used as 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 for
the language constraint. In these, in the case of WHOIS++ database is divided into one or
more words separated by whitespace. Each search term operates on
every word in the letters are
insignigicant. Other language codes shall attribute value.

Two or more search terms may be interpreted according
to combined with boolean operators
AND, OR or NOT (other than the Internet standard for language codes in RFC 822/MIME mes-
sages, if and when such a standard is adopted.

2.3.2.10. The INCHARSET Constraint implied AND between terms). The INCHARSET constraint tells
operator AND has higher precedence than the server in which character set operator OR, but this
can be changed by the use of parentheses.

Search constraints that apply to every search string itself is given in. term are specified as
global constraints. Local constraints override global constraints
for the search term they are bound to. The default character set is
"ISO-8859-1". search terms and the

Deutsch, et al [Page 22]
^L 17]

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

2.3.2.11. The IGNORE Constraint

The IGNORE constraint specifies which attributes January 1995

global constraints are separated with a colon (':'). Additional
global constraints are appended to NOT include in the result. All other attributes will be included (as if named
explicitly by end of the "include" constraint).

If an attribute is named both search command
delimited with a semicolon ';'.

If different search constraints can not be fulfilled, or the "include" and "ignore" con-
straint, the attribute combi-
nation of different search constraints is to be included in uncombinable, the result, server
may choose to ignore some constraints, but still do the
system message must be "% 205 Requested constraint not fulfilled".

2.3.2.12. search and
return some records.

The INCLUDE Constraint set of required constraints are summarized in Table III. The INCLUDE constraint specifies which attributes to include
set of optional constraints are summarized in the
result. All other attributes will be excluded (as if named expli-
citly by the "ignore" constraint).

If Table IV.

As an attribute is named both with the "include" and "ignore" con-
straint, option, the attribute is server may accept specifications for attributes
for either inclusion or exclusion from a reply. Thus, users could
specify _only_ those attributes 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 return, or specific attributes
to filter out, thus creating custom views.

2.2.2.1. Format of a total Search Term

Each search term consists of six different response modes possi-
ble for WHOIS++ servers. These are FULL, ABRIDGED, HANDLE, SUMMARY,
SERVERS-TO-ASK and MIME. The syntax one of each output format is speci-
fied in more detail in the following section. following:

1) A FULL format response provides the complete contents of each
template matching the specified query, including the template
type search string, followed by an optional comma and the composed handle for each record. set of
comma-separated local constraints.

2) An ABRIDGED format response provides a brief summary, including A search term specifier (as listed in Table II), followed by '=',
followed by a minimum) the composed handle search string, an optional comma and relevant information for
that template. a set of
comma-separate local constraints.

3) A HANDLE format response returns only An abbreviated search term specifier, followed by a list search
string, followed by an optional comma and set of handles that
matched the specified query. comma-separate
local constraints.

4) A SUMMARY response provides only a brief summary of information
the number of matches and the list combination of template types in which attribute name, followed by '=', followed by a
search string, followed by an optional comma and set of
comma-separate local constraints.

If no term identifier is provided, then the
matches occured.

5) A SERVERS-TO-ASK response returns only search will be applied
to attribute values only. This corresponds to an identifier of
VALUE.

If a pointer HANDLE specifier is used then the search term can specify
either a composed handle or a record handle. The server is respon-
sible for resolving the composed handle to another
WHOIS++ server, which might possibly a server handle and a
record handle.

If a SEARCH-ALL specifier is used then the search will be able applied
to answer all template names, handles, attribute names and attribute
values.

When the
specified query.

6) A MIME response indicates that user specifies the body of search term using the response has been
encoded in MIME message format. form:

Deutsch, et al [Page 23]
^L 18]

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

The server may respond with a null answer and may also respond with
a null answer together with a correct system message January 1995

"<attribute_name> = <value>"

this is considered to indicate
that the query was too complex.

2.4.1. Default Responses

By default, a WHOIS++ server will provide a FULL response. This may be changed by the client with the use an ATTRIBUTE-VALUE search.

For discussion of the global constraint
"format".

The server is allowed to provide response in SUMMARY format if the
number of hits exceeds system reply format, and selecting the
appropriate reply format, see section 2.5.

----------------------------------------------------------------------

Valid specifiers:
-----------------

Name Functionality
---- -------------

ATTRIBUTE-VALUE [ ',' <constrnt>]* allows combining attribute and
value of the global constraint "max-
full".

The server will not respond with more matches than the value speci-
fied with the global constraint "maxhits"; Not specifiers in any response for-
mat. 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 one term.
HANDLE [ ',' <constrnt>]* Confine search to the number of the "maxhits" con-
straint value. handles.
SEARCH-ALL [ ',' <constrnt>]* Search everything.
TEMPLATE [ ',' <constrnt>]* Confine search to template names.
VALUE [ ',' <constrnt>]* Confine search to attribute
values. This mechanism will allow is the server to hide default.
(Note: The name HANDLE can be replaced with the
number shortname '!')

Acceptable forms of possible matches to a search command.

The server response modes are summarized in 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 V.

2.4.2. II - Valid search command term specifiers.

----------------------------------------------------------------------

2.2.2.2. Format of Responses

Each response consists of a numerical system generated message,
which can Search String

Special characters that need to be tagged with text, followed by an optional formatted
response message, followed quoted are preceeded by a second system generated messages.

That is:

'%' <system messages> <nl>

[ <formatted response> ]

'%' <system messages> <nl>

If there
backslash, '\'.

Special characters 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.

For information about the format for system messages, see Appendix
E. space ' ', tab, equal sign '=', comma ',',
colon ':', backslash '\', semicolon ';', asterisk '*', period '.',
parenthesis '()', square brackets '[]', dollar sign '$' and circum-
flex '^'.

Deutsch, et al [Page 24]
^L 19]

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

2.4.3. Syntax of a Formatted Response

All formatted responses consist of a START line, followed by a
response-specific section, followed by a TERMINATION line. It January 1995

If the search term is
permissible to insert any number of lines consisting solely of new-
lines within a formatted response to improve readibility.

A START line consists of a line beginning with a '#' given in the first
column, followed by one white space some other character (SPACE or TAB), fol-
lowed set than ISO-
8859-1, it must be specified by one of the following keywords FULL, ABRIDGED, HANDLE, SUM-
MARY, SERVERS-TO-ASK constraint INCHARSET.

2.3. WHOIS++ Constraints

Constraints are intended to be hints or MIME.

A START line must contain no more than 81 characters, including recommendations to the
terminating newline character.

A TERMINATION line consists of
server about how to process a line beginning with command. They may also be used to
override default behaviour, such as requesting that a '#' in the
first column, followed by one white space character (SPACE or TAB),
followed by server not
drop the keyword END, followed by zero or more characters,
followed by connection after performing a newline.

A TERMINATION line must contain no more than 81 characters, includ-
ing the terminating newline character.

A response-specific section will be one of command.

Thus, a user might specify a search constraint as "SEARCH=exact",
which means that the following:

1) FULL Format Response
2) ABRIDGED Format Response
3) HANDLE Format Response
4) SUMMARY Format Response
5) SERVERS-TO-ASK Format Response
6) MIME format Response

The details of each are specified 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 following sections:

2.4.3.1. A FULL format response

A FULL format response consists form "<constraintname>=<value>",
with <value> being one of a series of responses, each con-
sisting specified set of valid values. The not-
able exception is "HOLD", which takes no argument.

All constraints can be used as a FORMAT specifier line, followed by the complete tem-
plate information global constraint, but only a few
can be used as local. See tables IV and V for the matching record.

Each FORMAT specifier line consists information of a '#' in which
constraints can be local.

The CONSTRAINTS system command is used to list the first column,
followed search con-
straints supported by one white space character, the name of the correspond-
ing template type, one white space character, the serverhandle, an individual server.

If a
colon, server cannot satisfy the handle for that record, and a terminating newline.

The template information for each record specified constraint there will be returned as a
series of lines consisting of a single space, followed by
mechanism for informing the
corresponding line of user in the record.

Deutsch, et al [Page 25]
^L

Internet-Draft Architecture of reply, using system mes-
sages. In such cases, the WHOIS++ service 25 July 1994

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.

Each such 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 search is to
be broken into lines of no more than 81 characters, with each con-
tinuation line beginning still performed, with a "+" character in the first column,
instead of the leading space.

If the attribute value includes a line break, the line break
server ignoring unsupported constraints.

2.3.1. Required Constraints

The following CONSTRAINTS must be replaced by a CR/LF pair and the following line begin with a "-"
character supported in the first column, instead all conforming
WHOIS++ servers.

Deutsch, et al [Page 20]

Internet-Draft Architecture of the space character. WHOIS++ service 25 January 1995

------------------------------------------------------------------

Format LOCAL/GLOBAL
------ -------------

SEARCH= {exact | lstring } LOCAL/GLOBAL

FORMAT= {full | abridged | handle | summary } GLOBAL

MAXHITS= { 1-<max-allowed> } GLOBAL

Table III - Required WHOIS++ constraints.

------------------------------------------------------------------

2.3.2. Optional CONSTRAINTS

The
attribute name is following CONSTRAINTS and constraint values are not repeated on consecutive lines.

2.4.3.2. ABRIDGED Format Response

An ABRIDGED format response consists of a single set of responses,
consisting of a single line excerpt required of the template information
from each matching record. The excerpt information shall include,
as
a minimum, conforming WHOIS++ server, but may be supported. If supported,
their names and supported values must be returned in the composed handle of response
to the record, as well as other
information CONSTRAINTS command.

Deutsch, et al [Page 21]

Internet-Draft Architecture of the WHOIS++ service 25 January 1995

---------------------------------------------------------------------

Format LOCAL/GLOBAL
------ -------------

SEARCH= { regex | fuzzy | substring | <X-format> } LOCAL/GLOBAL

CASE= { ignore | consider } LOCAL/GLOBAL

FORMAT= { servers-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.

----------------------------------------------------------------------

2.3.2.1. The SEARCH Constraint

The SEARCH constraint is used for specifying the method that is relevant to
be used for the template type. search. The abridged template information for each record will be returned
as default method is "exact". Following is
a series definition of lines, each of which must consist of search method.

exact The search will succeed for a single space,
followed by the abridged line of the record, one or more space
characters, word that exactly
matches the composed handle, and search string.

substring The search will succeed for a CR/LF pair.

Each line shall be limited to no more than 81 characters, including
the terminating newline. If word that matches
a line (including the required single
space, would exceed 81 characters, it is to be broken into lines part of
no more than 81 characters, with the remainder following on the
subsequent line, with the space replaced by a "+" character in the
first column.

If the attribute value includes word.

regex The search will succeed for a line break, word when a regular
expression matches 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 space character. The
attribute name searched data. Regular
expression is not repeated on consecutive lines.

2.4.3.3. HANDLE Format Response

A HANDLE format response consists of a single set of responses,
consisting of a single line listing the composed handle and tem-
plate type for each matching record.

Each line shall start with one space, followed built up by the server han-
dle, a colon, the record handle, one or more whitespace characters,
the template type using constructions of
'*', '.', '^', '$', and terminated by a newline. '[]'. For use of
regular expressions see Appendix G.

Deutsch, et al [Page 26]
^L 22]

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

Each such line must contain no more than 81 characters, including
the terminating newline character. If a line (including January 1995

fuzzy The search will succeed for words that matches the
required first space) would exceed 81 characters, it shall be split
into multiple lines,
search string by using an algorithm designed to catch
closely related names with each continuation line beginning different spelling, e.g.
names with a
'+' instead of a space.

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 same pronounciation. The server
chooses which algorithm to the specified
query, followed by a list of all use, but it may vary
depending on template types which satisfied the
query at least once. name, attribute name and
language used (see Constraint Language above).

lstring The first line shall begin search will succed for words that begins
with the string "matches: ", search string.

2.3.2.2. The FORMAT Constraint

The FORMAT constraint describes what format the result will be followed
by in.
Default format is FULL. For a space and the number description of responses to the query and terminated
by a newline. each format, see
Server Response Modes below.

2.3.2.3. The second line shall begin with MAXFULL Constraint

The MAXFULL constraint sets the string "tem-
plates: ", be followed by a newline separated list limit of the name number of matching
records the template types which matched 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 query. Each line following
server will return the
first which include response in SUMMARY format if the text "templates:" must begin with a '-'
instead number of a space.

If
hits exceeds 2, the line MAXFULL constraint is longer than 81 characters including set to 2 by the terminating
CR/LF pair, it shall be split into multiple lines with each con-
tinuation line beginning with a '+' instead server.

Regardless of a space.

2.4.3.5. MIME Format Response

A MIME what format the client did or did not ask for, the
server will change the response consists of a MIME encoding of all
responses, each consisting of format to SUMMARY when the data number
of one matching record. records equals or exceeds this value.

2.3.2.4. The
result MAXHITS Constraint

The MAXHITS constraint sets the maximum number of records the
client can get in a search is contained in one MIME message. respone.

2.3.2.5. The MIME mes-
sage itself is indented with one space. Each record is embedded in
the message type text/iafa-template. If the result consists of more
than one record, CASE Constraint

The CASE constraint defines if the message type multipart/mixed search should be done case sen-
sistive or not. Default value is used to
separate the different records from each other.

See RFC-1521 [BORE93] and RFC-1522 [MOOR93] for more information
about the MIME format. have case ignored.

2.3.2.6. The format of the message type text/iafa-template follows the
specification of the FULL template, as described above. AUTHENTICATE Constraint

The MIME message itself must be indented with one space character.

2.4.3.6. SERVERS-TO-ASK Response

A SERVERS-TO-ASK response consists of information to the client
about AUTHENTICATE constraint describes which servers to contact next to resolve a query. authentication method

Deutsch, et al [Page 27]
^L 23]

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

The servers-to-ask response will consist of January 1995

to use when executing the search. By using a number of attribute-
value pairs, separated specific authentica-
tion method, some other constraints might be needed which is speci-
fied by CRLF. Each line the authentication method.

The only authentication method described in this document is indented with one
space.

Required attributes are "Version-number", which will be "1.0", "pass-
word", if used, also the two other constraints "name" and
"Next-Servers".

The "Next-Servers" field will "pass-
word" need to be returned 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 series string of lines,
each holding pointer information
characters which together with the string given as an argument to one server. Consecutive lines
shall have a hyphen "-" in
the first column. Each line will be
separated into five fields, separated with a semicolon. Those
fields are:

1. "password" constraint is sent to the server. The server handle can use
that pair of the server pointed at. (required)
2. A cached host named for the server pointed at. (optional)
3. A cached port number for the server pointed at. (optional)

Each such line shall be limited strings to no more than 81 characters,
including the terminating newline. If do a line (including simple authentication check, like the
required leading single space) would exceed 81 characters, it
UNIX login program do.

2.3.2.8. The PASSWORD Constraint

The PASSWORD constraint is to
be broken into lines of no more than 81 characters, with each con-
tinuation line beginning with a "+" character in the first column.

2.4.4. System Generated Messages

All system generated messages must begin only used together with a '%' as the first
character, a space as some authentica-
tion method named by the second one, followed constraint "authenticate". The only use
described in this document is by sending a three digit
number, password as a space and an optional text message. The total length string of
the line must be no more than 81
characters long, including which together with the
terminating CR LF pair. There string given as an argument to
the "name" constraint is no limit sent to the number of system
messages that may be generated. server. The format for multiline replies requires server can use
that every line, except
the last, begin with "%", followed by space, the reply code, pair of strings to do a
hyphen, and an optional text. simple authentication check, like the
UNIX login program do.

2.3.2.9. The last line will begin with "%",
followed by space, LANGUAGE Constraint

The LANGUAGE constraints can be used as an extra information to the reply code, a space
fuzzy matching search method, and some optional text.

System generated messages displayed before or after the formatted
response section are expected it might also be used to refer tell the
server to operation of give the system
or refer to responses in another language, although
this ability should be handled by the entire query. System generated messages within client. The two-letter
language code defined in ISO 639:1988 can be used as a value for
the
output language constraint. In these, the case of an individual record during a FULL reponse the letters are expected
to refer to that record only, and could (for example)
insignigicant. Other language codes shall be used interpreted according
to
indicate problems with that record of the response. See Appendix E Internet standard for language codes in RFC 822/MIME mes-
sages, if and when such a description of system messages.

2.5. Compatibility with Older WHOIS Servers

Note that this format, although potentially more verbose, standard is still adopted.

2.3.2.10. The INCHARSET Constraint

The INCHARSET constraint tells the server in a human readible form. Responses from older systems that do not
follow this format are still conformant, since their responses which character set
the search string itself is given in. The default character set is
"ISO-8859-1".

Deutsch, et al [Page 28]
^L 24]

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

would be interpreted as being equivalent to optional text messages,
without a formatted response. Clients written January 1995

2.3.2.11. The IGNORE Constraint

The IGNORE constraint specifies which attributes to this specifica-
tion would display NOT include in
the responses as a advisory text message, where
it would still result. All other attributes will be readible included (as if named
explicitly by the user.

3. Miscellaneous

3.1. Acknowledgements

The WHOIS++ effort began as "include" constraint).

If an intensive brainstorming session at attribute is named both with the 24th IETF, "include" and "ignore" con-
straint, the attribute is to be included 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 Passwa-
ters, Simon Spero, and Chris Weider. Others who have since helped
shape this document with feedback and suggestions include Patrik
Faltstrom, Dan Kegel, Mark Prior and Rickard Schoultz.

3.2. Contact information

Peter Deutsch,
BUNYIP INFORMATION SYSTEMS, inc
310 St-Catherine St West,
suite 202,
Montreal, Quebec H2X 2A1
CANADA
<peterd@bunyip.com>

Rickard Schoultz,
KTHNOC, SUNET/NORDUnet/Ebone Operations Centre
100 44 STOCKHOLM
SWEDEN
<schoultz@sunet.se>

Patrik Faltstrom
KTH/NADA
100 44 STOCKOLM
SWEDEN
<paf@nada.kth.se>

Chris Weider
BUNYIP INFORMATION SYSTEMS, inc
2001 S. Huron Parkway, #12
Ann Arbor, MI 48104
USA
<clw@bunyip.com>

Deutsch, et al [Page 29]
^L

Internet-Draft Architecture of result, but the WHOIS++ service 25 July 1994

Appendix A - Some Sample Queries

author=chris and template=user
system message must be "% 205 Requested constraint not fulfilled".

2.3.2.12. The result will consist of all records where attribute "author"
matches "chris" with case ignored. Only USER templates INCLUDE Constraint

The INCLUDE constraint specifies which attributes to include in the
result. All other attributes will be
searched. An example of a matching record is "Author=Chris Weider".
This excluded (as if named expli-
citly by the "ignore" constraint).

If an attribute is named both with the typical case of search.

schoultz "include" and rick;search=lstring

The result will consist of all records which have one "ignore" con-
straint, the attribute
value matching "schoultz" exactly and one having "rick" as leading
substring, both with case ignored. One example is "Name=Rickard
Schoultz".

value=phone;search=substring

The result will consist of all records which have attribute values
matching *phone*, for example to be included in the record "Name=Acme telephone
inc.", result, but will not match the attribute name "phone". (Since
"value" term specifier
system message must be "% 205 Requested constraint not fulfilled".

2.4. Server Response Modes

There are currently a total of five different response modes possi-
ble for WHOIS++ servers. These are FULL, ABRIDGED, HANDLE, SUMMARY
and SERVERS-TO-ASK. The syntax of each output format is specified
in more detail in the default, following section.

1) A FULL format response provides the search term could be
"phone" as well as "value=phone".)

search-all=Peter ; search=substring;case=consider

The result will consist complete contents of all records which have attribute names, each
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 specified query, including the record, template
type and has the
word "ucdavis" somewhere in composed handle for each record.

2) An ABRIDGED format response provides a word. The result will only show brief summary, including
(as a minimum) the
"name" composed handle and "email" fields.

Deutsch, et al [Page 30]
^L

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

Appendix B - Some sample responses.

1) relevant information for
that template.

3) A FULL HANDLE format response:

# FULL

# USER SERVHANDLE1:PD45
Name: Peter Deutsch
email: peterd@bunyip.com

# USER SERVHANDLE1:AE1
Name: Alan Emtage
email: bajan@bunyip.com

# USER SERVHANDLE1: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.

# SERVICES SERVHANDLE1:WWW1
Type: World Wide Web
Location: the world

# END

--------------------

2) An ABRIDGED format response:

# ABRIDGED

Peter Deutsch peterd@bunyip.com PD45
Alan Emtage bajan@bunyip.com AE1
World Wide Web the world WWW1

# END

--------------------

3) A HANDLE format response:

# HANDLE

SERVHANDLE1:PD45 User
SERVHANDLE1:AE1 User

Deutsch, et al [Page 31]
^L

Internet-Draft Architecture response returns only a list of handles that
matched the WHOIS++ service 25 July 1994

SERVHANDLE1:WWW1 Services

# END

-------------------- specified query.

4) A SUMMARY HANDLE format response:

# SUMMARY

Matches: 175
Templates: User
- Services
- Abstracts
# END 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 MIME format response:

# MIME
Mime-Version: 1.0
Content-Type: multipart/mixed;boundary=uniqueboundary

--uniqueboundary
Content-Type: text/iafa-template;charset=iso-8859-1;template=user;
handle=nadakthse01:paf01
Content-Transfer-Encoding: quoted-printable

Name: Patrik F=E4ltstr=F6m
Email: paf@nada.kth.se

--uniqueboundary
Content-Type: text/iafa-template;charset=us-ascii;template=user;
handle=sunetse01:risc01

Name: Rickard Schoultz
Email: schoultz@sunet.se

--uniqueboundary-
# END SERVERS-TO-ASK response returns only a pointer to another
WHOIS++ server, 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

Deutsch, et al [Page 32]
^L 25]

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

Appendix C - Sample responses to system commands

C.1 Response to the LIST command

# ABRIDGED
USER
SERVICES
HELP
# END

C.2 Response to the SHOW command

This example show the result after issuing "show help":

# FULL
# TEMPLATE serverhandle1:user-template
Template-Name: USER
Attribute-Names: Name,Organization-Name,Organization-Type,Work-Phone,
+Work-Fax,Work-Postal,Job-Title,Department,Email,Handle,Home-Phone,
+Home-Postal,Home-Fax
# TEMPLATE serverhandle1:help
Template-Name: HELP
Attribute-Names: Subject,Description,Handle
# END

C.3 Response to the POLLED-BY command

# FULL
# POLLED-BY xyz:serverhandle1
Server-handle: serverhandle1
Cached-Host-Name: sunic.sunet.se
Cached-Host-Port: 7070
Template: user
Field: ALL
# POLLED-BY xyz:serverhandle2
Server-handle: serverhandle2
Cached-Host-Name: kth.se
Cached-Host-Port: 7070
Template: ALL
Field: Name,Email
# END

C.4 Response to the POLLED-FOR command

# FULL
# POLLED-FOR xyz:serverhandle3
Server-Handle: serverhandle3
Template: ALL

Deutsch, et al [Page 33]
^L

Internet-Draft Architecture of January 1995

that the query was too complex.

2.4.1. Default Responses

By default, a WHOIS++ service 25 July 1994

Field: Name,Address,Job-Title,Organization-Name,Organization-Address,
+Organization-Name
# POLLED-FOR xyz:serverhandle4
Server-Handle: serverhandle4
Template: User
Field: ALL
# END

C.5 Response to the VERSION command

# FULL
# VERSION serverhandle:version
Version: 1.0
Program-Name: kth-whoisd
Program-Version: 2.0
# END

C.6 Response to the CONSTRAINTS command

# server will provide a FULL
# CONSTRAINT asdjkq
Constraint: format
Default: full
Range: full,abridged,summary,handle,mime
# CONSTRAINT ljkqwer
Constraint: maxhits
Default: 200
Range: 1-1000
# CONSTRAINT slkjewer
Constraint: search
Default: exact
Range: exact,substring,lstring
# CONSTRAINT qwewerq
Constraint: maxfull
Default: 20
# END

Deutsch, et al [Page 34]
^L

Internet-Draft Architecture of response. This may
be changed by the WHOIS++ service 25 July 1994

Appendix D - Sample whois++ session

Below is an example of a session between a client and a server. The
angle brackets to with the left is not part use of the communication, but global constraint
"format".

The server is
just put there allowed to denonte provide response in SUMMARY format if the direction
number of hits exceeds the communication
between value of the global constraint "max-
full".

The server or the client. Text appended to '>' means mes-
sages from the server and '<' from the client.

Client connects to will not respond with more matches than the server

>% 220-Welcome to
>% 220-the whois++ server
>% 220 at ACME inc.
<name=Nick:hold
>% 200 Command okay
>
># FULL
>
># USER serverhandle:nw1
> name: Nick West
> email: nick@acme.com
># END
># SERVERS-TO-ASK
> Version-number: 1.0
> Next-Servers: sunetse01;whois.sunet.se;7070
>- kthse01
>- anotherserverhandle01;whois.acme.com;7070
># END
>% 226 Tranfer complete
<version
>% 200 Command okay
># FULL
># VERSION ignoredserverhandle:version
> Version: 1.0
># END
>% 226 Tranfer complete
>% 203 Bye
Server closes value speci-
fied with the connection

In global constraint "maxhits"; Not in any response for-
mat. If the example above, number of matches exceeds this value, the client connected to a whois++ server and
queried for all records where will
issues the attribute "name" equals "Nick",
and asked system message 110 (maxhits value exceeded), but will
still show the server not responses, up to close the connection after number of the response
by using "maxhits" con-
straint value. This mechanism will allow the global constraint "HOLD".

The server responds with one record and a pointer to three other
servers that either holds records or pointers hide the
number of possible matches to other servers.
The first server was polled for "USER" templates and "name" and
"email" fields. a search command.

The client continues with asking for servers version number without
using the HOLD constraint. After responding with protocol version,
the server closes the connection.

Deutsch, et al [Page 35]
^L

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

Note that each response from the server begins modes are summarized in Table V.

2.4.2. Format of Responses

Each response consists of a numerical system message 200
(Command OK), and ends generated message,
which can be tagged with text, followed by an optional formatted
response message, followed by a second system message 226 (Transfer Complete). 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.

For information about the format for system messages, see Appendix
E.

2.4.3. Syntax of a Formatted Response

All formatted responses consist of a START line, followed by a

Deutsch, et al [Page 36]
^L 26]

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

Appendix E - System messages January 1995

response-specific section, followed by a TERMINATION line. It is
permissible to insert any number of lines consisting solely of new-
lines within a formatted response to improve readibility.

A system message begins START line consists of a line beginning with a '%', '#' in the first
column, followed by a one white space and a three
digit number, a space, and an optional text message. The character (SPACE or TAB), fol-
lowed by one of the following keywords FULL, ABRIDGED, HANDLE, SUM-
MARY or SERVERS-TO-ASK.

A START line mes-
sage must be contain no more than 81 characters long, characters, including the ter-
minating CR LF pair. There is no limit to the number of system mes-
sages that may be generated.
terminating newline character.

A multiline system message have a hyphen instead TERMINATION line consists of a space line beginning with a '#' in
column 6, immediately after the numeric response code in all lines,
except
first column, followed by one white space character (SPACE or TAB),
followed by the last one, where keyword END, followed by zero or more characters,
followed by a newline.

A TERMINATION line must contain no more than 81 characters, includ-
ing 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 terminating newline character.

A response-specific section will be one of the text part following:

1) FULL Format Response
2) ABRIDGED Format Response
3) HANDLE Format Response
4) SUMMARY Format Response
5) SERVERS-TO-ASK Format Response

The details of each are specified in the following sections:

2.4.3.1. A FULL format response
message except when receiving reply 600,

A FULL format response consists of a series of responses, each con-
sisting of a FORMAT specifier line, followed by the complete tem-
plate information for the matching record.

Each FORMAT specifier line consists of a '#' in which case the text
part is first column,
followed by one white space character, the name of the correspond-
ing template type, one white space character, the serverhandle, a character set
colon, the handle for that record, and a terminating newline.

The template information for each record will be used returned as a
series of lines consisting of a single space, followed by the server
in the rest
corresponding line of the response. record.

The valid values for characters sets
is specified in the "characterset" list in line of the BNF listing in
appendix F.

The theory record shall consist of reply codes is described in appendix E in RFC 821
[POST82].

------------------------------------------------------------------------

List of system response codes
------------------------------

110 Too many hits The number of matches exceeded a single space and the value specified
attribute name, followed by a ':', a single space, 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 of
that attribute, and was therefore not used,
but the search is still done. a newline.

Deutsch, et al [Page 37]
^L 27]

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

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 January 1995

Each such line shall be limited 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 no more than 81 characters,
including the
server terminating newline. If a line (including the
required leading single space) would exceed 81 characters, it is not able to resolve
a query (i.e. when a client
sent
be broken into lines of no more than 81 characters, with each con-
tinuation line beginning with a regular expression that
is too deeply nested).

530 Authentication failed The authentication phase
failed.

600 <token> Subsequent attribute values are
encoded "+" character in the charater set
specified by <token>.

Table V - System response codes

------------------------------------------------------------------------

Deutsch, et al [Page 38]
^L

Internet-Draft Architecture first column,
instead of the WHOIS++ service 25 July 1994

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" 1*SP [string]
/ "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)

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

Deutsch, et al [Page 39]
^L

Internet-Draft Architecture of leading space.

If the WHOIS++ service 25 July 1994

format = "full" / "abridged" / "handle" / "summary"
/ "servers-to-ask" / "mime"

language = <The two-letter language code defined in ISO 639-1988
can attribute value includes a line break, the line break must
be used as language constraint. In these replaced by a CR/LF pair and the case following line begin with a "-"
character in the first column, instead of the letters are insignificant.
Other language codes shall be interpreted
according to space character. The
attribute name is not repeated on consecutive lines.

2.4.3.2. ABRIDGED Format Response

An ABRIDGED format response consists of a single set of responses,
consisting of a single line excerpt of the Internet standard for
language codes in RFC 822/MIME messages, if
and when such template information
from each matching record. The excerpt information shall include,
as a standard minimum, the composed handle of the record, as well as other
information that is adopted>

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" / 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>

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 char-
acters, when significant relevant to the query, may template type.

The abridged template information for each record will be preceded and/or
followed by returned
as a series of lines, each of which must consist of a single blank:
: ; , ( ) = !

Deutsch, et al [Page 40]
^L

Internet-Draft Architecture of space,
followed by the WHOIS++ service 25 July 1994

Appendix G - Description abridged line 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.

Character Function
--------- --------

<any except those listed in this table> Matches itself

a* Matches zero record, one or more 'a'

[ab] Matches 'a' or 'b'

[a-c] Matches 'a', 'b' or 'c'

^ Matches beginning of space
characters, the composed handle, and a string

$ Matches end of CR/LF pair.

Each line shall be limited to no more than 81 characters, including
the terminating newline. If a string

Examples
---------

String Matches Matches not
------- ------- -----------
hello hello helloo
h.llo hello helio
h.*o hello helloa
h[a-f]llo hello hgllo
^he.* hello ehello
.*lo$ hello helloo

Deutsch, et al [Page 41]
^L

Internet-Draft Architecture line (including the required single
space, would exceed 81 characters, it is to be broken into lines of
no more than 81 characters, with the WHOIS++ service 25 July 1994

References

[BORE93] Borenstein N., and N. Freed, MIME (Multipurpose
Internet Mail Extensions): Mechanisms for Specifying remainder following on the
subsequent line, with the space replaced by a "+" character in the
first column.

If the attribute value includes a line break, the line break must
be replaced by a CR/LF pair and Describing the Format following line begin with a "-"
character in the first column, instead of Internet Message Bodies,
RFC 1521, Bellcore, Innosoft, September 1993.

[HARR85] Harrenstein K., Stahl M., Feinler E., NICNAME/WHOIS,
RFC954, SRI, October 1985

[IAFA] Internet Anonymous FTP Archives Working Group (now
closed).

[IAFA1] Emtage A., and Deutsch P.. IAFA (Internet Anonymous
FTP Archives)
(not yet issued, pending some editing...)

[IIIR] Weider C., and Deutsch P., the space character. The
attribute name is not repeated on consecutive lines.

2.4.3.3. HANDLE Format Response

A vision HANDLE format response consists of an integrated
internet information service, Internet Draft,
October, 1993. < URL:ftp://nic.merit.edu/documents/
internet-drafts/draft-ietf-iiir-vision-02.txt >

[MOOR93] Moore K., MIME (Multipurpose Internet Mail Extenssions)
Part Two: Message Header Extensions for Non-ASCII Text,
RFC 1522, University a single set of Tennessee, September 1993.

[NIR] Network Information Retrieval Working Group.

[POST82] Postel J., Simple Mail Transfer Protocol, RFC 821,
ISI, August 1982.

[Weider94] Weider C., Fullton J., Spero S., responses,
consisting of a single line listing the composed handle and tem-
plate type for each matching record.

Each line shall start with one space, followed by the server han-
dle, a colon, the record handle, one or more whitespace characters,
the template type and terminated by a newline.

Each such line must contain no more than 81 characters, including
the terminating newline character. If a line (including the
required first space) would exceed 81 characters, it shall be split

Deutsch, et al [Page 28]

Internet-Draft Architecture of the WHOIS++ Index Service: Internet Draft, March, 1994.
< URL:ftp://nic.merit.edu/documents/internet-drafts/
draft-ietf-wnils-whois-03.txt >

Expires: service 25 January 95

Part I - WHOIS++ Overview

1.1. Purpose and Motivation....................................... 2
1.2. Basic Information Model...................................... 3
1.2.1. Changes 1995

into multiple lines, with each continuation line beginning with a
'+' instead of a space.

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 current WHOIS Model......................... 4
1.2.2. Registering WHOIS++ servers................................ 4
1.2.3. specified
query, followed by a list of all template types which satisfied the
query at least once.

The WHOIS++ Search Selection Mechanism..................... 5
1.2.4. 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 WHOIS++ Architecture................................... 6
1.3. Indexing second line shall begin with the string "tem-
plates: ", 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.

If the line is longer than 81 characters including the terminating
CR/LF pair, it shall be split into multiple lines with each con-
tinuation line beginning with a '+' instead of a space.

2.4.3.5. SERVERS-TO-ASK Response

A SERVERS-TO-ASK response consists of information to the client
about which servers to contact next to resolve a query.

The servers-to-ask response will consist of a number of attribute-
value pairs, separated by CRLF. Each line is indented with one
space.

Required attributes are "Version-number", which will be "1.0", and
"Next-Servers".

The "Next-Servers" field will be returned as a series of lines,
each holding pointer information to one server. Consecutive lines
shall have a hyphen "-" in WHOIS++.......................................... 6 the first column. Each line will be
separated into five fields, separated with a semicolon. Those
fields are:

1. The server handle of the server pointed at. (required)
2. A cached host named for the server pointed at. (optional)
3. A cached port number for the server pointed at. (optional)

Each such 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 con-
tinuation line beginning with a "+" character in the first column.

Deutsch, et al [Page 29]

Internet-Draft Architecture of the WHOIS++ service 25 January 1995

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.

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 specifica-
tion 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 Passwa-
ters, 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 Meal-
ling, Mark Prior and Rickard Schoultz.

Deutsch, et al [Page 30]

Internet-Draft Architecture of the WHOIS++ service 25 January 1995

3.2. Contact information

Peter Deutsch,
BUNYIP INFORMATION SYSTEMS, inc
310 St-Catherine St West,
suite 202,
Montreal, Quebec H2X 2A1
CANADA
<peterd@bunyip.com>

Rickard Schoultz,
KTHNOC, SUNET/NORDUnet/Ebone Operations Centre
100 44 STOCKHOLM
SWEDEN
<schoultz@sunet.se>

Patrik Faltstrom
BUNYIP INFORMATION SYSTEMS, inc
310 St-Catherine St West,
suite 202,
Montreal, Quebec H2X 2A1
CANADA
<paf@bunyip.com>

Chris Weider
BUNYIP INFORMATION SYSTEMS, inc
2001 S. Huron Parkway, #12
Ann Arbor, MI 48104
USA
<clw@bunyip.com>

Deutsch, et al [Page 31]

Internet-Draft Architecture of the WHOIS++ service 25 January 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
Schoultz".

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.

Deutsch, et al [Page 32]

Internet-Draft Architecture of the WHOIS++ service 25 January 1995

Appendix B - Some sample responses.

1) A FULL format response:

# FULL

# USER SERVHANDLE1:PD45
Name: Peter Deutsch
email: peterd@bunyip.com

# USER SERVHANDLE1:AE1
Name: Alan Emtage
email: bajan@bunyip.com

# SERVICES SERVHANDLE1:WWW1
Type: World Wide Web
Location: the world

# END

--------------------

2) An ABRIDGED format response:

# ABRIDGED

Peter Deutsch peterd@bunyip.com PD45
Alan Emtage bajan@bunyip.com AE1
World Wide Web the world WWW1

# END

--------------------

3) A HANDLE format response:

# HANDLE

SERVHANDLE1:PD45 User
SERVHANDLE1:AE1 User

Deutsch, et al [Page 33]

Internet-Draft Architecture of the WHOIS++ service 25 January 1995

SERVHANDLE1:WWW1 Services

# END

--------------------

4) A SUMMARY HANDLE format response:

# SUMMARY

Matches: 175
Templates: User
- Services
- Abstracts
# END

Deutsch, et al [Page 34]

Internet-Draft Architecture of the WHOIS++ service 25 January 1995

Appendix C - Sample responses to system commands

C.1 Response to the LIST command

# ABRIDGED
USER
SERVICES
HELP
# END

C.2 Response to the SHOW command

This example show the result after issuing "show help":

C.3 Response to the POLLED-BY command

C.4 Response to the POLLED-FOR command

# FULL
# POLLED-FOR xyz:serverhandle3
Server-Handle: serverhandle3
Template: ALL

Deutsch, et al [Page 35]

Internet-Draft Architecture of the WHOIS++ service 25 January 1995

Field: Name,Address,Job-Title,Organization-Name,Organization-Address,
+Organization-Name
# POLLED-FOR xyz:serverhandle4
Server-Handle: serverhandle4
Template: User
Field: ALL
# END

C.5 Response to the VERSION command

# FULL
# VERSION serverhandle:version
Version: 1.0
Program-Name: kth-whoisd
Program-Version: 2.0
# END

C.6 Response to the CONSTRAINTS command

# FULL
# CONSTRAINT asdjkq
Constraint: format
Default: full
Range: full,abridged,summary,handle
# CONSTRAINT ljkqwer
Constraint: maxhits
Default: 200
Range: 1-1000
# CONSTRAINT slkjewer
Constraint: search
Default: exact
Range: exact,substring,lstring
# CONSTRAINT qwewerq
Constraint: maxfull
Default: 20
# END

Deutsch, et al [Page 36]

Internet-Draft Architecture of the WHOIS++ service 25 January 1995

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 mes-
sages from the server and '<' from the client.

Client connects to the server

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 three other
servers that either holds records or pointers to other servers.
The first server was polled for "USER" templates and "name" and
"email" fields.

The client continues with asking for servers version number without
using the HOLD constraint. After responding with protocol version,
the server closes the connection.

Deutsch, et al [Page 37]

Internet-Draft Architecture of the WHOIS++ service 25 January 1995

Note that each response from the server begins system message 200
(Command OK), and ends with system message 226 (Transfer Complete).

Deutsch, et al [Page 38]

Internet-Draft Architecture of the WHOIS++ service 25 January 1995

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 mes-
sage must be no more than 81 characters long, including the ter-
minating CR LF pair. There is no limit to the number of system mes-
sages 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 F.

The theory of reply codes is described in appendix E in 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.

Deutsch, et al [Page 39]

Internet-Draft Architecture of the WHOIS++ service 25 January 1995

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

------------------------------------------------------------------------

Deutsch, et al [Page 40]

Internet-Draft Architecture of the WHOIS++ service 25 January 1995

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)

combinedterm = string "=" string *(";" localcnstrnt)

globalcnstrnts = globalcnstrnt *(";" globalcnstrnt)

globalcnstrnt = localcnstrnt
/ "format" "=" format
/ "maxfull" "=" 1*digit
/ "maxhits" "=" 1*digit
/ opt-globalcnst

Deutsch, et al [Page 41]

Internet-Draft Architecture of the WHOIS++ service 25 January 1995

format = "full" / "abridged" / "handle" / "summary"
/ "servers-to-ask"

language = <The two-letter language code defined in
ISO 639-1988 can be used as language constraint.
In these the case of the letters are
insignificant. Other language codes shall be
interpreted according to the Internet standard
for language codes in RFC 822/MIME messages, if
and when such a standard is adopted>

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" / 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>

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 char-
acters, when significant to the query, may be preceded and/or
followed by a single blank:
: ; , ( ) = !

Deutsch, et al [Page 42]
^L

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

1.4. Getting Help................................................. 7
1.4.1. Minimum HELP Required...................................... 8
1.5. Options and Constraints...................................... 8
1.6. Formatting Responses......................................... 8
1.7. Reporting Warnings and Errors................................ 9
1.8. Privacy and Security Issues.................................. 9

Part II January 1995

Appendix G - WHOIS++ Implementation

2.1. Introduction................................................. 11
2.1.1. The WHOIS++ interaction model.............................. 11
2.2. The WHOIS++ Command set...................................... 12
2.2.1. System Commands............................................ 12
2.2.1.1. The COMMANDS command..................................... 13
2.2.1.2. The CONSTRAINTS command.................................. 13
2.2.1.3. The DESCRIBE command..................................... 14
2.2.1.4. The HELP command......................................... 14
2.2.1.5. The LIST command......................................... 14
2.2.1.6. The POLLED-BY command.................................... 14
2.2.1.7. The POLLED-FOR command................................... 15
2.2.1.8. The SHOW command......................................... 15
2.2.1.9. The VERSION command...................................... 15
2.2.2. The Search Command......................................... 15
2.2.2.1. Format of a Search Term.................................. 16
2.2.2.2. Format Description of a Search String................................ 17
2.3. WHOIS++ Constraints.......................................... 18
2.3.1. Required Constraints....................................... 18
2.3.2. Optional Constraints....................................... 19
2.3.2.1. The SEARCH Constraint.................................... 20
2.3.2.2. The FORMAT Constraint.................................... 21
2.3.2.3. The MAXFULL Constraint................................... 21
2.3.2.4. The MAXHITS Constraint................................... 21
2.3.2.5. The CASE Constraint...................................... 21
2.3.2.6. The AUTHENTICATE Constraint.............................. 21
2.3.2.7. The USER Constraint...................................... 22
2.3.2.8. The PASSWORD Constraint.................................. 22
2.3.2.9. The LANGUAGE Constraint.................................. 22
2.3.2.10. The INCHARSET Constraint................................ 22
2.3.2.11. The IGNORE Constraint................................... 23
2.3.2.12. Regular expressions

The INCLUDE Constraint.................................. 23
2.4. Server Response Modes........................................ 23
2.4.1. Default Responses.......................................... 24
2.4.2. Format 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 char-
acters '^' 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 Responses........................................ 24
2.4.3. Syntax a token

$ Matches end of a Formatted Response............................. 25
2.4.3.1. A FULL format response................................... 25
2.4.3.2. ABRIDGED Format Response................................. 26
2.4.3.3. HANDLE Format Response................................... 26
2.4.3.4. SUMMARY Format Response.................................. 27
2.4.3.5. MIME Format Response..................................... 27
2.4.3.6. SERVERS-TO-ASK Response.................................. 27
2.4.4. System Generated Messages.................................. 28
2.5. Compatibility with Older WHOIS Servers....................... 28
3. Miscellaneous.................................................. 29 token

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 [Page 43]
^L

Internet-Draft Architecture of the WHOIS++ service 25 July 1994

3.1. Acknowledgements............................................. 29
3.2. Contact information.......................................... 29

Appendix January 1995

References

[HARR85] Harrenstein K., Stahl M., Feinler E., NICNAME/WHOIS,
RFC954, SRI, October 1985

[IAFA] Internet Anonymous FTP Archives Working Group (now
closed).

[IAFA1] Emtage A., and Deutsch P.. IAFA (Internet Anonymous
FTP Archives)
(not yet issued, pending some editing...)

[IIIR] Weider C., and Deutsch P., A - Some Sample Queries................................... 30
Appendix B - Some sample responses................................. 31
Appendix C - Sample responses to system commands................... 33
Appendix D - Sample whois++ session................................ 35
Appendix E - System messages....................................... 37
Appendix F - The WHOIS++ BNF Grammar............................... 39
Appendix G - Description vision of Regular expressions.................... 41 an integrated
internet information service, Internet Draft,
October, 1993. < URL:ftp://nic.merit.edu/documents/
internet-drafts/draft-ietf-iiir-vision-02.txt >

[NIR] Network Information Retrieval Working Group.

[POST82] Postel J., Simple Mail Transfer Protocol, RFC 821,
ISI, August 1982.

Expires: 25 July 95

Deutsch, et al [Page 44]

----