Re: Pointers to whois++ documents

Peter Deutsch <peterd@bunyip.com> Tue, 16 November 1993 17:38 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08596; 16 Nov 93 12:38 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08590; 16 Nov 93 12:38 EST
Received: from ucdavis.ucdavis.edu by CNRI.Reston.VA.US id aa14065; 16 Nov 93 12:38 EST
Received: by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA14251; Tue, 16 Nov 93 08:54:40 PST
X-Orig-Sender: ietf-wnils-request@ucdavis.edu
Received: from mocha.bunyip.com by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA12354; Tue, 16 Nov 93 08:31:38 PST
Received: from expresso.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06879 (mail destined for ietf-wnils@ucdavis.edu) on Tue, 16 Nov 93 11:33:34 -0500
Received: by expresso.bunyip.com (NX5.67c/NeXT-1.0) id AA23912; Tue, 16 Nov 93 11:25:12 -0500
Message-Id: <9311161625.AA23912@expresso.bunyip.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Peter Deutsch <peterd@bunyip.com>
Date: Tue, 16 Nov 1993 11:25:07 -0500
In-Reply-To: "Chris Weider"'s message as of Nov 16, 10:38
X-Mailer: Mail User's Shell (7.2.4 2/2/92)
To: Chris Weider <clw@merit.edu>, ietf-wnils@ucdavis.edu
Subject: Re: Pointers to whois++ documents
Cc: jcgargano@ucdavis.edu

[ You wrote: ]

> Hi gang:
>   Sorry for the delay on these... these are pointers to the whois++ specification
> documents.
.  .  .
> The basic query protocol and basic server description is not yet available as
> an Internet Draft. There is a spec floating around, but it needs two additions
> before it will be submitted as an Internet Draft. (The addition of
> MIME content types in the output format, and the addition of a query term
> to ask for mesh information). .  .  

Mea culpa on this one. I've had the last few paragraphs
kicking around in my head for months but I've been on the
road more than home.

Also, at the Houston IETF Chris and Simon mentioned that
they need a new command to support the mess, but haven't
sent along the syntax yet. Can one of you post it here for
discussion? Thanks.

Simon Spero said he would be sending me some suggested
text for the MIME stuff and hopefully I'll be able to get
to the doc this week. You'll hear it here first.

> .  .  .   However, people have been implementing
> off of the current draft. If Peter is willing, perhaps we can put it up for
> anonymous FTP at the wnils archive site. (This would also involve Joan's
> permission :^) ). .  .  .

I just checked and an earlier version in on
ftp.ucdavis.edu in the directory "/archive/wnils.archive"
as the file "Architecture.Overview". I'll include the most
recent version (as posted before Amsterdam) here and if
JOan would be so kind as to update the archive, we'll try
to get a more recent version out in the next few days
(right...)


					- peterd


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

[* Draft as posted July 3, 1993....  *]


From: Peter Deutsch <peterd@bunyip.com>
Date: Thu, 8 Jul 1993 19:30:05 -0400
In-Reply-To: jcgargano@ucdavis.edu's message as of Jul  3, 11:01
X-Mailer: Mail User's Shell (7.2.4 2/2/92)
To: ietf-wnils@aggie.ucdavis.edu
Subject: WHOIS++ Architecture Doc - Most Recent Draft
Cc: 

g'day all,

Here's the most recent draft of the WHOIS++ architecture doc for next
week. It incorporates all changes and suggestions since the last IETF
meeting and in particular includes a lot of useful feedback from Mark
Prior of Adelaide that he came up as we both worked on individual
implementations after the last IETF.


A note on implementations

Mark Prior won line honours for first released server, a WHOIS++ -> X.500
gateway. He posted details here. For those who missed it, his email
address is "mrp@itd.adelaide.edu.au" (hope this is right, it's what was
used in a piece of mail I have from him).

Although we have not released our server, the Bunyip gang now have
available an initial draft of a library for building and parsing WHOIS++
queries, a working frontend and a modified WAIS search engine capable of
doing field indexing, thus allowing us to do attribute and value searches.
all we have left to do is put in the code to make it a stand-alone server,
but life keeps getting in the way. We're happy to make available what we
have so far for your own experimenting and still plan to finish this any
moment now.

People who are still waiting for a pilot release are free to pound on any
Bunyip person you can find while in Amsterdam (look for the cool T-Shirts,
although we'll have more to distribute so check first that you're not
pounding on one of our customers... :-)

I understand that Chris Weider and the CNIDR gang are also working on
seperate implementations of servers and/or clients and expect an update
from them next week on their progress.



Now, some comments on changes to this draft since the last IETF:

	- I've added a contents pages and cleaned up the layout. Part I
	  now "WHOIS++ Overview", part II is now "WHOIS++ Implementation".

Part I:
	- Added a blurb on proposed search selection model, to (hopefully) 
	  make clear what our goal is when specifying a search.

	- Modified the description of the HELP and HELP HELP commands to
	  something hopefully a bit more sensible. There is now a
	  DESCRIBE and HELP commands. DESCRIBE gives an IAFA
	  "Services" template for the server. HELP with no arguments
	  gives a general overview of WHOIS. HELP <topic> gives help
	  of <topic>.

	- There are now COMMANDS and CONSTRAINTS commands to 
	  get the list of supported commands and constraints.
	  There's still more needed to specify the appropriate output
	  format for these so they can be machine parsed.

	- Missing is more stuff on the indexing side of things. I
	  point at Chris' doc, but think we should have a bit more
	  here, too.

	- Added some more stuff on Privacy and Security.

Part II:
	- Spell out details of the interaction model, including
	  optional HOLD constraint and a corresponding TIMEOUT value.

	- We now have tables for required and optional commands,
	  details of the search command, required and optional
	  constraints and the supported output formats (allows fast
	  location of needed info, without full details of the
	  required semantics). The tables themselves need work, but
	  at least are all in place.


Misc:
	- Started References and Acknowlegements sections.
	- Moved sample output to an appendix.



Open Questions and Misc Business for this IETF:

	- Should we specify the use of Dave Crocker's STIF proposal for
	  data element encoding?

	- How do we handle white space in a term?

	- This implies a quoting mechanism. How will this work?

	- I put forth a proposal for user-controlled views (that is,
	  IGNORE and RETURN constraints to allow user to select only a
	  subset of selected data elements). I'm folding this in for
	  now (as options) but we need to examine this in more detail.

	- We need to look again at VIEWS, to allow user to get details
	  of available views, etc. This can wait....

	- No one's brought it up here, but someone asked me about
	  command line editing (!!!). I assume this is out =8-0

	- I'm assuming that we're case insensitive for all but
	  case-sensitive search terms (ie: "ATTRIBUTE=fred" and
	  "attribute=fred" are identical and "ATTRIBUTE=fred" and
	  "ATTRIBUTE=FRED" are identical unless the search type is
	  case-sensitive ).

	- We might or might not want to specify a complete set of
	  default values, unless overridden by local configuration.

	- We need to chart legal response codes.

	- Need to check BNF closely (I've still not hammered enough
	  on this)


Okay, see you all next week.

				- peterd


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


Network Working Group				Peter Deutsch,
NOT QUITE AN INTERNET DRAFT			Bunyip Information Systems.

				(others?? I'm not sure who all to put here)



               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. Internet Drafts may be updated, replaced or obsoleted
by other documents at any time.  It is not appropriate to use
Internet Drafts as reference material or to cite them other
than as a ``working draft'' or ``work in progress.''

Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.dn.mil,
nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au
to learn the current status of any Internet Draft.


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 that enable such features as the adding
or updating of information records, the use of multiple languages and
character sets, multiple views onto a single set of data and a number
of other useful features. An optional authentication mechanism for
protecting all or part of the associated WHOIS++ information database
from unauthorized access is also described.

[Gargano92] describes the use of WHOIS++ for a general information
lookup service. The additional architectural issues and commands added
to support the distributed indexing service are described in
[Weider92]. This present document should be read in conjunction with
these additional references.




		Contents Page

1. WHOIS++ Overview

   1.1   Purpose and Motivation
   1.2   Basic Information Model
   1.3   The WHOIS++ Architecture
   1.4   Indexing in WHOIS++
   1.5   Getting Help
   1.6   Options and Constraints
   1.7   Formatting Responses
   1.8   Privacy and Security Issues

2. WHOIS++ Implementation

   2.1   Introduction
   2.2   The WHOIS++ Command Set
   2.3   The SEARCH Command
   2.4   WHOIS++ Constraints
   2.5   Identifying and Using Options
   2.5   Server Response Modes
   2.6   MIME-compliant output
   2.7   WHOIS++ Warnings and Error Conditions

3. Miscellaneous

   3.1   Acknowledgements
   3.2   COntact Information

   Appendix I:   Sample output formats
   Appendix II:  WHOIS++ BNF Grammar








		Summary of Illustrations and Tables
		------------------------------------





	Fig. 1 ..................... Structure of a WHOIS++ database.
	Fig. 2 ..................... Indexing system architecture.


	Table I .................... Required System Commands
	Table II ................... Search Command Terms
	Table III .................. Optional System Commands
	Table IV ................... Required Constraints
	Table V .................... Optional Constraints
	Table VI ................... Summary of Response Formats



		Part I - WHOIS++ Overview
		--------------------------


1.1  Purpose and Motivation
----------------------------

The current NIC WHOIS service [RFC954] is used to provide a very
limited directory service, serving information about a small number of
Internet users registered with the DDN NIC. Over time the basic
service has been expanded to serve additional information and similar
services have also been set up on other hosts. Unfortunately, these
additions and extensions have been done in an ad hoc and uncoordinated
manner.

The basic WHOIS information model represents each individual record as
a Rolodex-like collection of text. Each record has a unique identifier
(or handle), but otherwise is assumed to have little structure. The
current service allows users to issue searches for individual strings
within individual records, as well as searches for individual record
handles using a very simple query-response protocol.

Despite its utility, the current NIC WHOIS service obviously cannot
function as a general White Pages service for the entire Internet.
Given the inability of a single server to offer guaranteed response or
reliability, the huge volume of traffic that a full scale directory
service will generate and the potentially huge number of users of such
a service, such a trivial architecture is obviously unsuitable for the
current Internet's needs for information services.

This document describes the architecture and protocol for WHOIS++, a
simple, distributed and extensible information lookup service based
upon a small set of extensions to the original WHOIS information model.
These extensions allow the new service to address the community's
needs for a simple directory service, yet the extensible architecture
is expected to also allow it to find application in a number of
other information service areas.

Added features include an extension to the trivial WHOIS data model
and query protocol and a companion extensible, distributed indexing
service. A number of options have also been added that enable adding
or updating information records, the use of multiple languages and
character sets, multiple views onto a single set of data and a number
of other useful features. An optional authentication mechanism for
protecting all or part of the associated WHOIS++ information database
from unauthorized access is also described.

An outline of the use of WHOIS++ for a general information lookup
service is in [Gargano92]. The additional architectural issues and
commands added to support an optional distributed indexing service are
described in [Weider92]. This present document should be read in
conjunction with these additional references.

The basic architecture of WHOIS++ allows distributed maintenance of the
directory contents and the use of the WHOIS++ indexing service for
locating additional WHOIS servers. Although a general overview of this
service is included for completeness, the reader is referred to
[Weider92] for full details of the indexing extensions.



1.2  Basic Information Model
-----------------------------

Our extensions to the existing WHOIS service are centred upon a
recommendation to structure user information around a series of
standardized 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 on standardizing their format and content [IAFA], [NIR].

It is intended that adding such structured templates to a server and
subsequently identifying and searching them be simple tasks.  The creation
and use of customized templates should also be possible with little
effort, although their use should be discouraged where appropriate
standardized templates exist.

We also offer a set of extensions to the trivial protocol described in
RFC954 to allow the user to constrain searches to desired attributes
or template types, in addition to the existing commands for specifying
handles or simple strings.

It is expected that the minimalist approach we have taken will find
application where the high cost of configuring and operating
traditional White Pages services can not currently be justified.

Also note that the new architecture makes no assumptions about the
search and retrieval mechanisms used within individual servers.
Operators are free to use dedicated database formats, fast indexing
software or even provide gateways to other directory services to store
and retrieve information, if desired.

The WHOIS++ server simply functions as a known front end, offering a
simple data model and communicating through a well known port and query
protocol. The format of both queries and replies has been structured
to allow the use of client software for generating searches and
displaying the results. At the same time, some effort has been made to
keep responses at least to some degree readible by humans, to ensure
low entry cost and to ease debugging.

The actual implemention details of of an individual WHOIS search
engine are left to the imagination of the implementor and it is hoped
that the simple, extensible approach taken will encourage
experimentation and the development of improved search engines.


Changes to the current WHOIS Model
------------------------------------


The current WHOIS service is based upon an extremely simple data model.
The NIC WHOIS database consists of a series of individual records, each of
which is identified by a single unique identifer (the "handle"). Each
record contains one or more lines of information. Currently, there is no
structure or implicit ordering of this information, although by
implication each record is concerned with information about a single user
or service.

We have implemented two basic changes to this model. First, we have
structured the information within the database as collections of data
elements, or simple attribute/value pairs. Each individual record
contains a specified ordered set of these data elements.

Secondly, we have introduced typing of the database records. In effect,
each record is based upon one of a specified set of templates, each
containing a finite and specified number of data elements. This allow
users to easily limit searches to specific collections of information,
such as information about users, services, abstracts of papers,
descriptions of software, and so on.

As a final extension, we require that each individual WHOIS++ database
on the Internet be assigned a unique handle, analogous to the handle
associated with each database record. 

The WHOIS++ database structure is shown in Fig. 1.


Registering WHOIS++ servers
----------------------------

We propose that individual database handles be registered through the
Internet Assigned Numbers Authority (the IANA), ensuring their
uniqueness. This will allow us to specify each WHOIS++ entry on the
Internet as a unique record handle/WHOIS handle pair.

A unique registered handle is preferable to using the host's IP
address, since it is conceivable that the WHOIS++ server for a
particular domain may move over time.  If we preserve the unique
WHOIS++ handle in such cases we have the option of using it for
resource discovery and networked information retrieval (see
[IIIR] for a discussion of resource and discovery and support
issues).

We believe that organizing information around a series of such
templates will make it easier for administrators to gather and
maintain this information and thus encourage them to make such
information available. At the same time, as users become more familiar
with the data elements available within specific templates they will
be better able to specify their searches, leading to a more useful
service.



______________________________________________________________________________
|                                                                             |
|   +  Single unique WHOIS++ database handle                                  |
|                                                                             |
|              _______                   _______                   _______    |
|    handle3  |..  .. |        handle6  |..  .. |        handle9  |..  .. |   |
|            _______  |                _______  |                _______  |   |
|  handle2  |..  .. |        handle5  |..  .. |        handle8  |..  .. |     |
|           _______ |                 _______ |                 _______ |     |
| handle1  |..  .. |        handle4  |..  .. |        handle7  |..  .. |      |
|          |..  .. |                 |..  .. |                 |..  .. |      |
|           -------                   -------                   -------       |
|      Template                     Template                  Template        |
|       Type 1                       Type 2                    Type 3         |
|                                                                             |
|                                                                             |
|                                                                             |
|                                                                             |
|      Fig.1 - Structure of a WHOIS++ database.                               |
|                                                                             |
| Notes: - Entire database is identified by a single unique WHOIS handle.     |
|        - Each record has a single unique handle and a specific set          |
|          of attributes, determined by the template type used.               |
|        - Each value associated with an attribute can be any ASCII string    |
|          up to a specified length.                                          |
|                                                                             |
------------------------------------------------------------------------------


The WHOIS++ Search Selection Mechanism
---------------------------------------

The WHOIS++ search mechanism is intended to be extremely simple. A
search command consists of one or more search terms, with an optional
set of global constraints (specifiers that modify or control a search).

Search terms allow the user to specify template type, attribute, value
or handle that any record returns must satisfy. Each search term can
have an optional set of local constraints that apply to only that term
and which would override any defaults or global constraints. Thus, a
user might specify substring matching for the entire search, but exact
match for a single 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.
There is currently no provision for Boolean searches (other than an
implied AND between search terms) or other more elaborate search
mechanisms in WHOIS++.

[* note, as we currently interpret the spec, there is an implied
   OR between VALUE terms, with an open question about binding
   of VALUE and ATTRIBUTE terms. This needs work...  *]

The simple, subtractive nature of WHOIS++ queries, and the lack of
Boolean search operations, could lead to possible ambiguities if
certain combinations of search terms were allowed. For example, if the
user were to specify more than one template type for a given search
either no matches could occur (since it is implicit that no record can
have more than one template type associated with it) or a logical OR
operation would have to be inferred.

To handle such cases, the second and all subsequent conflicting terms
are to be discarded and a suitable warning returned along with the
results of the search. This occurs when either multiple template
types, or multiple handles are specified in a search.

[* we still need to decide what we're going to do about precedence
   rules, to allow specifying multiple value terms... *]



1.3  The WHOIS++ Architecture
------------------------------

A flooding algorithm is used to propagate information from individual
records across a distributed database combining information from a number
of WHOIS servers. This mechanism is used to address concerns about scaling
and redundancy.

[* more overview on this component might be included here... *]



1.4 Indexing in WHOIS++
------------------------

[* Some details on this component might be included here... *]




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

                              ____             ____
top level                    |    |           |    |
whois index                  |    |           |    |
servers                       ----             ----


                        ____                ____ 
first level            |    |              |    |
whois index            |    |              |    |
servers                 ----                ----


                    ____                ____                  ____
individual         |    |              |    |                |    |
whois servers      |    |              |    |                |    |
                    ----                ----                  ----


Fig. 2 - Indexing system architecture.

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



1.5  Getting Help
------------------

Another extension to the basic WHOIS service is the requirement that
all servers support at least a minimal set of help commands, allowing
users to find out information about both the individual server and the
entire WHOIS++ service itself. This is done in the context of the new
extended information model by defining two specific template formats
and requiring each server to offer at least one example of each record
using these formats. The operator of each WHOIS service is therefor
expected to have, as a minimum, a single example of SERVICES and
HELP records, which can be accessed through appropriate commands.

Full details of these required templates are included in [Gargano92].


Minimum HELP Required
-----------------------
 

Executing the command:

	DESCRIBE

is equivalent to issuing the search command with the terms
"TEMPLATE=services" and "SUBJECT=describe" and will result in the
display of the corresponding SERVICES template with an attribute of
"subject" and value of "describe". This template is expected to contain
brief information about the specific WHOIS++ server on which it
resides.


Executing the command:

	HELP

(with no arguments) is equivalent to issuing the search command with
the terms "TEMPLATE=help" and "SUBJECT=help" and will result in the
display of the corresponding HELP template with subject "help".
This template is expected to contain 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>

is equivalent to issuing the search command with the terms
"TEMPLATE=help" and "SUBJECT=<searchstring>" and will result in the
display of the corresponding HELP template with the subject of
"<searchstring>". These templates may contain brief information on any
topic.

Users may also use the general search command, specifying the template
type "HELP" and desired subject directly to access individual records.

[* Feeping Creaturism: Should we also add some kind "APROPROS" command?? *]



1.6  Options and Constraints 
-----------------------------

The WHOIS++ service is based upon a minimal core set of commands and
controlling constraints. A small set of additional optional commands
and constraints can be supported. These would allow users to perform
such tasks as provide security options, modify the information
contents of a server or add multilingual support. The required set of
WHOIS++ commands are summarized in section 2.2. WHOIS++ constraints
are described in section 2.4.  Optional commands and constraints are
described in section 2.5. 


1.7 Formatting Responses
--------------------------

The output returned by a WHOIS++ server is structured to allow machine
parsing and automated handling. Of particular interest in the ability
to return summary information about a search (without having to return
the entire results) and the ability to encode graphics and other
information, using the MIME message encoding format.

All output of searches will be returned in one of six output formats,
which will be one of FULL, ABRIDGED, HANDLE, SUMMARY, POINTER or MIME.
Note that a conforming server is only required to support the first
four formats. 

When available, POINTER format is used to indicate that a search
cannot be completed but that one or more alternative WHOIS++ servers
may be able to perform the search. It may return either a Fully
Qualified Domain Name (FQDN) or a valid IP address in "dotted-quad
decimal" format. FQDN is recommended.

When available, MIME format is used to encode output in MIME format
[MIME]. This allows the responses to use the full power of MIME to
encode additional information representation.

Details of each output format are specified in section 2.5.


Output Format Model
--------------------

[* we need a brief explanation of the general approach taken for
   creating output formats.... *]



Reporting Warnings and Errors
------------------------------

The formatted response of WHOIS++ commands allows the encoding of
warning or error messages to simplify parsing and machine handling. The
syntax of output formats are described in detail in section 2.5, and
details of WHOIS++ warnings and error conditions are given in section
2.7.


1.8 Privacy and Security Issues
---------------------------------

The basic WHOIS++ service was conceived as a simple, unauthenticated
information lookup service, but there are occasions when
authentication mechanisms are required. To handle such cases, an
optional mechanism is provided for authenticating each WHOIS++
transaction.

The currently identified authentication mechanisms are PASSWORD (which
uses simple password authentication) KERBEROS (which uses kerberos
authentication) and TICKET (which is based upon a simple private key
encryption scheme). Any other scheme name used must begin with the
characters "X-" and should thus be regarded as experimental and
non-standard.

[* We should probably spin off a companion document on how to
   implement each type of authentication and merely point this doc
   at it. Isn't this one getting long enough already??   :-)  *]


Note that the WHOIS++ authentication mechanism does not dictate the
actual authentication scheme used, it merely provides a framework for
indicating that a particular transaction is to be authenticated, and
the appropriate mechanisms to use. A core set of authentication schemes
has been enumerated, but this mechanism is extensible and individual
implementors are free to add additional mechanisms.
 
Given the unauthenticated nature of the default service users are
cautioned against putting too much faith in the information served.
This is especially true when not using an optional authentication
mechanism but even when using authentication, the type of
authentication scheme selected and the public nature of the Internet
environment must still be taken into consideration when assessing the
security and authentication of the information served.

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




		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 to be backwards compatible with existing servers, in the
sense that a new server receiving any of the older commands specified
in RFC 954 will behave in the same manner as the original NIC WHOIS
server.

Obviously, it is not possible to ensure desired behaviour if one of the
extended commands is sent to an older WHOIS server, since the requested
functionality is simply not there. Still, it would be possible to query
whether the WHOIS++ command set is supported as an attribute for each
WHOIS server in an appropraite 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 sent to an older WHOIS
server would simply be treated as a search term, and thus no harm
should result.

The small number of older servers, and the probability that at least
some of the older servers will be converted to WHOIS++ as
implementations become available, means that backwards compatibility
is not expected to be a problem in practice.


The WHOIS++ interaction model
------------------------------

A WHOIS++ server will normally listen for a TCP connections on the
allocated WHOIS port (port 43) (although a WHOIS++ server can be
accessed over any TCP connection). Once a connection is established,
the server may issue an optional banner message, then listens for a
single line of input. The command specified in this input is processed
and the results returned. If the optional HOLD constraint has not been
specified the connection is then terminated.

If the server supports the optional HOLD constraint, and this
constraint is specified as part of any command, the server continues
to listen on the connection for another line of input. This cycle
continues as long as the sender continues to append the required HOLD
constraint to each subsequent command.

At the same time, each server is permitted to set an optional timeout
value (which should be indicated in the response to the CONSTRAINTS
command). If set, the server is free to terminate an idle connection
at any time after this delay has passed with no input from the client.


[* question - do we require a corresponding error message before
   termination? I'd prefer it but things could get messy here... *]



2.2  The WHOIS++ Command set
-----------------------------

There are two types of WHOIS++ commands - system commands and the
WHOIS++ search command. Each command has a longform, and one or more
corresponding shortform identifiers which can be used to specify the
command desired.

The WHOIS++ command set consists of a core set of required systems
commands, a single required search command and an set of optional
system commands which support features that are not required by all
servers. The set of required WHOIS++ system commands are listed in
Table I. Details of the allowable search terms for the search command
are included in Table II. The set of optional commands is summarized
in Table III.

Each WHOIS++ command also allows the use of one or more controlling
constraints, which select can be used to override defaults or
otherwise modify server behavior. There is a core set of constraints
that must be supported by all conforming servers. These include SEARCH
(which controls the type of search performed), CASE (which determines
if a search is case sensitive), FORMAT (which determines the output
format used) and MAXHITS (which determines the maximum number of
matches that a a search can return). These required constraints are
summarized in Table IV.

An additional set of optional constraints are used to provide
multilingual support, 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 V.

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


System Commands
----------------

System commands are commands to the server for information or to
control its operation. These include commands to list the template
types available from individual servers, to obtain a single blank
template of any available type, and commands to obtain the list of
valid commands and constraints supported on a server.

There are also commands to obtain the current version of the WHOIS++
protocol supported, to access a simple help subsystem, to obtain a
brief description of the service (which is intended, among other
things, to support the automated registration of the service by yellow
pages directory services). All of these commands are required from a
conforming WHOIS++ server.

Details of the optional commands this are included in section 2.5.



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

Short Form    Long Form				Functionality
--------------------------------------------------------------------

  	COMMANDS	[ ':' HOLD ]		list valid WHOIS++ commands
						supported by this server

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

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

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

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


[* Question on the next two - should we make this optional, and not
   require all servers to support indexing, or do we make it a requirement?  *]

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

  	POLLED-FOR	  [ ':' HOLD ]		List information about
						what this server is
						tracking for

[* question - shouldn't such requests be sent to the appropriate indexer?? *]

  	SHOW <string> [':' <constraints>]	Show contents of templates
						specified

  	VERSION		  [ ':' HOLD ]		return current version of
						the protocol supported 
						[* is this really needed? *]


[* Comment - More thought has to go into which constraints can or
   should be supported for each system command.  *]


Table I - Required WHOIS++ SYSTEM commands.


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



2.3 The Search Command
-----------------------

A search command consists of one or more search terms, which act as
specifiers for the selection of records from the WHOIS++ database. Such
specifiers are cumulative, that is, each search term is an additional
specification that a record must satisfy before it will be returned to the
user as a valid response to the query.

It is currently an open question whether attributes and values can or
should be paired, or whether precedence rules are needed. There is
certainly a current ambiguity over how to handle multiple VALUE terms. 
This can be avoided (for now) by using combination ATTRIBUTE-VALUE
search terms.

There is currently no plans for Boolean AND, OR or NOT (other than the
implied AND between terms), although this capability could be added if
there is sufficient demand. There has been a proposal that users be
allowed to specify individual data elements for either inclusion or
exclusion from a reply. Thus, users could specify _only_ those
attributes to return, or specific attributes to filter out, thus
creating custom views.

A search command consists of one or more search terms, followed by an
optional set of global search constraints.  

Search constraints that apply to every search term are specified as global
constraints. In addition, the format of server responses may be changed
from the specified default behaviour by setting the corresponding global
constraint.

The set of required constraints are summarized in Table IV. The set of
optional constraints are summarized in Table V.


Format of a Search Term
------------------------

Each search term consists of one of the following:

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

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

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

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

[*  Currently, it seems to make sense to allow only SEARCH and CASE as
    local constraints... *]


In addition to the historical search specifiers to specify a search on
content, handle or mailbox provided in RFC 954, there are also identifiers
to select on template type or attribute name. In keeping with the spirit
of RFC 954, all identifiers have an associated single character prefix
that may be used in place of the "<identifier>=" format of the same
identifier.

If no term identifier is provided, then the search will be applied to all
template names, handles, attribute names and attribute values.  This
corresponds to an identifier of SEARCH-ALL.

When the user specifies the search term using the form:

	"<attribute_name> = <value>"

This is considered to be an ATTRIBUTE-VALUE search, and is treated as
being equivalent to the combined terms:

	"ATTRIBUTE = <attribute_name>; VALUE = <value>"

Note that in this case, "<attribute_name>" can not be one of the
specifiers "ATTRIBUTE", "VALUE", "HANDLE" or "TEMPLATE".


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



Some Sample Queries
--------------------


[* We need to include many examples and explanation of valid search
   terms. This will take some text, so perhaps should be in either its
   own section, in an Appendix, or confined to Joan's overview doc?  *]



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

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

Short 	Long Form		Functionality
--------------------------------------------------------------------

  .  ATTRIBUTE	[ ',' <constrnt>]*	Confine search to attribute fields.
  #  VALUE	[ ',' <constrnt>]*	Confine search to attribute values.
  !  HANDLE	[ ',' <constrnt>]*	Confine search to handles.
  ^  TEMPLATE	[ ',' <constrnt>]*	Confine search to template names.
  *  SEARCH-ALL	[ ',' <constrnt>]*	Search everything.
   ATTRIBUTE-VALUE [ ',' <constrnt>]*	allows combining attribute and
					value specifiers in one term.


A search term takes one of the following forms:

1) 	<searchstring>  [',' <constrnt>]*

2)	<specifier> = <searchstring> [',' <constrnt>]*

3)	<shortspecifier> <searchstring>  [',' <constrnt>]*

4)	<attribute_name> = <searchstring>  [',' <constrnt>]*

   Which is equivalent to the compound terms:

	ATTRIBUTE = <attribute_name>; VALUE = <value>, <constrnt>


A <constrnt> is a comma-separated list of valid constraints.


Table II - Valid search command term specifiers.

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


Format of a Search String
--------------------------

[* This part is still a placeholder. Here are issues to discuss:

   We need to specify a quoting mechanism to allow white space. *]
   
   Also, the actual format of a search string is not yet specified, as
   there is a discussion to be had concerning the use of non-ASCII
   (esp. but not limited to other European languages) in search strings
   and even attribute names, etc. We must allow for this, but I'm
   still merely flagging this need for now.

   Finally, we need lots more examples throughout the text.  *]



Optional Commands
------------------

This section provides a summary of the optional commands that may be
supported by a conforming WHOIS++ server. Note that a conforming
WHOIS++ server is not required to support any of the specified
optional commands or constraints, however if any are supported they
must have the behavior specified here.


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

Short Form    Long Form				Functionality
--------------------------------------------------------------------


/* One possibility for providing support for the Write Option */
/* this is yucky, but put out for discussion...               */

CREATE TEMPLATE=<template-name>:  <template>	/* add specified template.   */
						/* type. <template-name>     */
						/* must not already exist    */

DESTROY TEMPLATE=<template-name>:  <template>	/* delete all occurances.    */
						/* of specified template     */

ADD VIEW=<viewname>:				/* add specified view.       */
	 TEMPLATE=<template-name>: <template>	/* for type. neither         */
						/* <view-name nor            */
						/*  <template-name>          */
						/* may already exist         */

REMOVE VIEW=<viewname>:	 			/* remove specified view     */
		TEMPLATE=<template-name>	/* for <template-type>.      */

WRITE TEMPLATE=<template-name>: <template>	/* write specified contents. */
						/* <template-name> must      */
						/* already exist. A new      */
						/* handle is generated       */
						/* for this record           */

UPDATE HANDLE=<handle-value>: <template>	/* update existing template  */

/* Support for multiple views onto a template */

VIEWS			/* returns list of valid views         */
			/* may be used in conjunction with     */
			/* optional authentication constraint  */
			/* we need corresponding mechanism for */
			/* dumping contents of view (show,     */
			/* with view specifier?                */


Table III - Optional WHOIS++ SYSTEM commands.


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


2.4 WHOIS++ Constraints
------------------------

Constraints are intended to be hints or recommendations to the server
about how to process a command. They may also be used to override
default behaviour, such as requesting that a server not drop the
connection after performing a command.

Thus, a user might specify a search constraint as "SEARCH=exact",
which means that the search engine is to perform an exact match
search. It might also specify "LANGUAGE=francais", which implies that
the server should lssue all system messages in French. Although open
to debate, it might also be used to toggle representation of attribute
strings (since different users might wish the attributes in their own
language).

In general, contraints take the form "<constraintname>=<value>", with
<value> being one of a specified set of valid values. The notable
exception is "HOLD", which takes no argument.

The CONSTRAINTS system command is used to list the search constraints
supported by an individual server.

If a server cannot satisfy the specified constraint there will be a
mechanism for informing the user in the reply, using system messages.
In such cases, the search is still performed, with the the server
ignoring unsupported constraints.

[* is this sensible? I think so, but experience from users and other
   developers is needed... *]


Required Constraints
---------------------

The following CONSTRAINTS must be supported in all conforming WHOIS++
servers. In each case, individual options preceeded by a '*' are
themselves optional (thus, support for the SEARCH constraint is
required, but support for the "regex" or "fuzzy" options are not).


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

Short Form    Long Form				Functionality
--------------------------------------------------------------------


/* Search control, defaults would be exact, case sensitive??? */

*SEARCH=	{exact |substring | *regex |	/* type of search. */
		*fuzzy | <X-format> }

*CASE=		{ ignore | consider }		/* Ignore case */


/* Output format specifier.  */

FORMAT=		{full | abridged | handle |	/*select output format. */
		 summary | *pointer | *mime |
		 <X-format> }


/* general constraints */

MAXHITS=	{ 1-<max-allowed> }		/* maximum hits returned     */
						/* by server. Default value  */
						/* is returned by            */
						/* CONSTRAINTS command       */




Table IV - Required WHOIS++ constraints.

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





Optional CONSTRAINTS
---------------------

The following CONSTRAINTS are not required of a conforming 
WHOIS++ servers, but may be supported. If supported, their
names must be returned in the response to the CONSTRAINTS command.

In each case, those individual items preceeded by a '*'
are themselves optional. Thus, for example, a server performing
authentication is not required to perform any specific
authentication scheme (although support for a CONSTRAINT
implies support for at least one of the specified options).


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

Short Form    Long Form				Functionality

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


/* Authentication support options */

AUTHENTICATE=	{*password | *ticket |  *kerberos | *<X-format> }
ID=		<string>
NAME=		<string>
PASSWORD=	<string>
<some more stuff for authentication schemes here>


/* language support options */

INCHARSET=	{TBD, see MIME}
OUTCHARSET=	{TBD, see MIME}
LANGUAGE=	{TBD, see MIME}


/* general constraints */

HOLD

/* Support for user-configurable VIEWS  */

IGNORE=		{attributelist}	   /* list of attributes to filter out    */
INCLUDE=	{attributelist}	   /* list of attributes to include in    */
				   /* response. Note, implies all others  */
				   /* ignored.                            */


Table V - Optional WHOIS++ constraints.


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






Server Response Modes
----------------------

[* we can easily support additional response modes here. *]

There are currently a total of six different response modes possible
for WHOIS++ servers. These are FULL, ABRIDGED, HANDLE, SUMMARY. POINTER
and MIME. The syntax of each output format is specified in more detail
in the following section.

   1) A FULL format response provides the complete contents of each
      template matching the specified query, including the template type
      and handle for each record. 

   2) An ABRIDGED format response provides a brief summary, including (as a
      minimum) the record handle and the specific information in the
      corresponding record that matched the query.  [* this needs work *]

   3) A HANDLE format response returns only a list of handles that matched
      the specified query.

   4) A SUMMARY response provides only a brief summary of information
      about the number of matches and the list of template types in which
      the matches occured.

   5) A POINTER response returns only a pointer to another WHOIS++
      server, which might possibly be able to answer the specified
      query. Pointer is either a FQDN, or IP address, with optional
      port number.

   6) A MIME response indicates that the body of the response has
      been encoded in MIME message format.


Default Responses
------------------

By default, a WHOIS++ server will provide a FULL response when there is a
single record matching the specified query, an ABRIDGED response when
there between two and ten records matching the query and a SUMMARY
response when there is more than ten records matching the specified query.
The user may override these defaults by specifying the appropriate
keywords as global constraints to a search command (see below).

[* These numbers were chosen psuedo-randomly and are obviously open to
debate... *]

The server response modes are summarized in Table VI.


Format of Responses
--------------------

Each response consists of an optional free form introductory text message,
followed by any optional system generated messages, followed by a
formatted response message, followed by any optional system generated
messages, followed by an optional free form closing text message.

That is:

	[<text message> <nl>]*

	['%' <system messages> <nl>]*

	<formatted response>

	['%' <system messages> <nl>]*

	[<text message> <nl>]*

There is no limit on the total length or format of either the introductory
or closing text message, although each line should consist of no more
than 81 characters, including the terminating newline character. 

If there are no matches to a query, the system is not required to generate
any output as a formatted response, although it may still generate system
messages and/or a closing text message.

All optional system generated messages must begin with a '%' as the first
character and must be no more than 81 characters long, including the
terminating newline character. There is no limit to the number of system
messages that may be generated. 


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 is
permissible to insert any number of lines consisting solely of newlines
within a formatted response to improve readibility.

A START line consists of a line beginning with a '#' in the first column,
followed by zero or more white space characters (SPACE or TAB), followed by
one of the following keywords FULL, ABRIDGED, HANDLE or SUMMARY. Where the
keyword is FULL, ABRIDGED or HANDLE, this is then followed by one or more
white space characters, followed by a count of the number of matches found
for that query, followed by zero or more white space characters, followed
by a newline. 

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


A TERMINATION line consists of a line beginning with a '#' in the first
column, followed by zero or more white space characters (SPACE or TAB),
followed by the keyword END, followed by zero or more white space
characters, followed by a newline.

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



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

   1) FULL Format Response
   2) ABRIDGED Format Response
   3) HANDLE Format Response
   4) SUMMARY Format Response
   5) POINTER Format Response
   6) MIME format Response

The details of each are specified in the following sections:


A FULL format response
------------------------

A FULL format response consists of a series of responses, each consisting
of a FORMAT specifier line, followed by the complete template information
for the matching record.

Each FORMAT specifier line consists of a '#' in the first column, followed
by zero or more white space characters, followed by the name of the
corresponding template type, followed by one or more white space
characters, followed by the handle for that record, followed by zero or
more white space characters, followed by a newline. 

A FORMAT specifier must contain no more than 81 characters, including the
terminating newline character.

 [* Note this implicitly puts a limit on the length of a template name. We
    will need to set limits for this, and probably want to allow lines
    longer than 80 characters. I've put the 81 char limit in as a
    placeholder.  *]

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

The line of the record shall consist of the attribute name, followed by a
':', followed by at least one space, followed by the value of that
attribute, followed by 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 is to be broken into lines of no
more than 81 characters, with each continuation line beginning with a "+"
character.


ABRIDGED Format Response
------------------------

An ABRIDGED format response consists of a single set of responses,
consisting of a single line excerpt of the template information from each
matching record. The excerpt information shall include, as a minimum, the
template type and handle of the record, as well as the portion of the
information that caused the match.

The abridged template information for each record will be returned as a
series of lines, each of which must consist of a single space, followed by
the abridged line of the record.

Each line shall be limited to no more than 81 characters, including the
terminating newline. If a 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 remainder following on the subsequent line, with the
space replaced by a "+" character.


HANDLE Format Response
-----------------------

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

Each line shall start with at least one space, followed by the handle,
followed by at least one space, followed by the template type, followed by
zero or more white space characters 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 into multiple lines,
with each continuation line beginning with a '+' instead of a space.

SUMMARY Format Response
-----------------------

A SUMMARY format response consists of a single set of responses, consisting
of a line listing the number of matches to the specified query, followed
by a list of all template types which satisfied the query at least once.

The first line shall begin with the string "matches: ", be followed by the
number of responses to the query and terminated by a newline.  The second
line shall begin with the string "templates: ", be followed by the name of
the first template type which matched the query, followed by a newline.
Each succeeding line shall include the name of the next template type
matching the query, terminated by a newline.



System Generated Messages
--------------------------

Any line beginning with a '%' in the first column is to be treated as a
System generated message. System generated messages may occur immediately before,
within or immediately after the formatted response section of the response.

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.

Compatibility with Older WHOIS Servers
---------------------------------------

Note that this format, although potentially more verbose, is still in a
human readible form. Responses from older systems that do not follow this
format are still conformant, since their responses would be interpreted as
being equivalent to optional text messages, without a formatted response.
Clients written to this specification would display the responses as a
advisory text message, where it would still be readible by the user.


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

Format			Functionality
-----------------------------------------------------

FULL			Returns complete template information for each
			record that matches the specified query. Each
			such record is separated by a line that specifies
			the template type and handle for that record.
			

ABRIDGED		Returns a one line abridged response for each
			record that matches the specified query.

HANDLE			Returns a list of handles and corresponding
			template types for each record that matches the
			specified query.

SUMMARY			Returns only a brief summary of number of matches
			and the corresponding template types which
			matched the specified query.

POINTER			Returns a pointer to another WHOIS++ server.

MIME			Message is encoded in MIME format.


Note:	- Default is a FULL response for a single match, an ABRIDGED
	  response when there is between two and ten matches and a SUMMARY
	  response when there are more than ten matches. These may be
	  overridden by specifying the response format desired as a global
	  contraint.

	- Pointer and MIME formats are optional.

Table III - Summary of WHOIS++ Response Formats.

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

3. Miscellaneous
--------------------
Acknowledgements:

The WHOIS++ effort began as an intensive brainstorming session at the
24th IETF, in Boston Massachusetts. Present at the birth, and
contributing ideas through this early phase, were (alphabetically)
Peter Deutsch, Alan Emtage, Jim Fullton, Joan Gargano, Brad
Passwaters, Simon Spero and Chris Weider. Others who have since helped
shape this document with feedback and suggestions include Mark Prior,
and Dan Kegel. Apologies in advance to those I've left off.  Please
let me know and I'll fix things in future drafts.


Contacts:

Peter Deutsch,
Bunyip Information Systems,
310 St-Catherine St West,
suite 202,
Montreal, Quebec H2X 2A1
CANADA.
<peterd@bunyip.com>



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


Appendix A - Some sample responses.



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

1) A FULL format response:

# FULL 3

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

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

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

# END

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


2) An ABRIDGED format response:

# ABRIDGED 3

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

# END

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


3) A HANDLE format response:

# HANDLE 3

 PD45	User
 AE1	User
 WWW1	Services

# END

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


4) A SUMMARY HANDLE format response:

# SUMMARY

  Matches:	175
  Templates:	User
		Services
		Abstracts
# END




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



[* This grammer is still broken.... *]


Appendix B - The WHOIS++ BNF Grammar
---------------------------------------


WARNING!! WARNING!! I still haven't hacked the grammar!!

IT IS WRONG!!

IT IS ONLY INCLUDED HERE SO I CAN WORK ON IT LATER WITHOUT HAVING TO
FIND IT AGAIN!!!

There, you've been warned...


WHOIScommand	::=	<SYScommand>  |  <WHOISquery>


SYScommand	::=	<syscmdname1> [<searchstring> [',' <constraints>]]
			| "show" <searchstring> [',' <constraints>]
			| "constraints"
			| "version"


syscmdname1	::=	"help" | "?" | "list" 


WHOISquery	::=	<term> [';' <term>]* [':' <globalcnstrnts>] <nl>


term		::=	<generalterm> | <specificterm> | <shortterm>
			| <combinedterm>

generalterm	::=	<searchstring> [ ',' <constraints> ]

specificterm	::=	<specificname> '=' <searchstring>
			[ ',' <constraints> ]

specificname	::=	"template" | "handle" | "attribute" | "value"

shortterm	::=	<shortname> <searchstring>  [ ',' <constraints> ]

shortname	::=	'^'  | '!' | '.'  | ''  | '#' | '*'

globalcnstrnts	::=	[ <aconstraint> ]*  |  [ <responses> ]0-1

responses	::=	"full" | "abridged" | "handle" | "summary"

aconstraint	::=	(a set of specifiers for constraints. Expect
			 these to be a list of valid search methods... )

searchstring	::=	TBD (some string that does not include <shortname>
			or '?' but does include extended characters)


To come: 	- BNF for response formats.
		- more details on searchstring
		- more details on what a constraint



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



			References
			-----------


[*  These obviously need beefing up and a lot more detail...  *]


[IAFA1]		Emtage, Alan and Deutsch, Peter. IAFA RFC 
		(not yet issued, pending some editing...)

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

[RFC954]	Harrenstein et. al.

[Gargano92]	Gargano, Joan, et. al.

[Weider92]	Weider, Chris et. al.

[IIIR]		Weider, Chris and Deutsch Peter

[NIR]		Network Information Retrieval Working Group.



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

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

"The Internet destroys the Greek tragedy of time and space..."

                            - Daniel Pimienta <pimienta!daniel@redid.org.do>
-----------------------------------------------------------------------------