draft-wnils-service

[[e-mail]]

WNILS Working Group				     Joan Gargano
Internet Draft                                          Ken Weiss	
July 1, 1993			  University of California, Davis


             Whois and Network Information Lookup Service
                                Whois++


Status Of This Memo

This Internet Draft proposes changes to the NICNAME/WHOIS protocol 
described in RFC 954.  Distribution of this memo is unlimited.

   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.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or
   munnari.oz.au to learn the current status of any Internet Draft.

This Internet Draft expires December 31, 1993.

I.	Introduction

As currently defined, NICNAME/WHOIS service is a TCP transaction based 
query/response server, running on a few specific central machines, that 
provides netwide directory service to Internet users.  The Network 
Information Center (NIC) maintains the central NICNAME database and 
server, defined in RFC 954, providing online look-up of individuals,
network organizations, key host machines, and other information of
interest to users of the Internet.  The usefulness of this service has
lead to the development of other distributed directory information
servers and information retrieval tools and it is anticipated more will
be created.  Many sites now maintain local directory  servers with
information about individuals, departments and services at that specific
site. 

Typically these directory servers are network accessible.  Local
development of these services has resulted in wide variations in the
type of data stored, access methods, search  schemes, and user interfaces.
The purpose of the Whois and Network Information Lookup Service Working
Group  (WNILS) is to expand and define the standard for WHOIS types of
services, to resolve issues associated with the variations in access and
provide a consistent and predictable service across the network.  This
Internet Draft describes new features for WHOIS to meet these goals.


                                  1


WNILS Working Group      Whois++ Lookup Service   Gargano, Weiss


II.	Architecture

The WHOIS service should be provided in a client/server model.  There are 
no restrictions on the  design of the client, provided it is capable of
passing queries to the server in the proper format, and capturing the
server's response in some useful format.  Existing WHOIS specifications
call for clients to display responses in human-readable form.  This more
general proposal does not impose that restriction.

This paper acknowledges the existence of many distributed information 
servers, and anticipates the creation of many more. To help users locate 
WHOIS servers, each server should have a nameserver entry in the form 
"whois.domain", i.e. whois.internic.net.


III.	Client Design and Behavior

The client provides the user interface to the WHOIS system and a 
mechanism for query generation and display of the response.  The client
is responsible for providing support for paging of long output from the
server.  All clients must provide this service.  The server will not
include any special characters, or make any efforts to control output to
a screen.

Special search criteria may be specified by the use of keywords or
special characters, some of which are defined in RFC 954.  Clients
should be designed to make support for quoted strings unnecessary.


IV.	Server Design and Behavior

The server should return the same information in response to a given
query consistently, regardless of the client software or the hardware
used to originate the query. Queries should be evaluated on a
case-insensitive basis. Spaces should not be considered in searches.
A search for "La Russo" should return both "LaRusso" and "La Russo" as
matches.

There are three types of data records supported in this proposal:
records for people, hosts, and domains.

Individual records

Name			Name of the individual 		required
		
Organization 		Name of the organization 	required
		
Organization-type 	Type of organization 		optional
 			(university, commercial,
			research)
	
Work-telephone 		Work telephone number 		optional


                                 2

WNILS Working Group      Whois++ Lookup Service   Gargano, Weiss


		
Fax-telephone 		Fax telephone number 		optional
		
Work-address 		Work postal address 		optional
			
Title 			Working title or position 	optional
 			within an organization
	
Department 		Department 				optional
		
Email-address 		Email address in RFC 822  	optional
 			format for this individual
	
Handle 			A unique identifier for this  	required
 			record on the local server
	
Last-update 		Date this record was last  	required
			updated
		
Home-telephone 		Home telephone number 		optional
		
Home-address 		Home postal address 		optional


Host records
Domain records

Domain-name	Domain name registered with the 	required
		Network Information Center (NIC)
	
Network-address Network address associated with this 	required
		domain name
	
Admin-name 	Name of the Administrative Contact for 	required
		this domain
	
Admin-address 	Postal address of the Administrative 	required
		Contact for this domain
		
Admin-telephone Telephone number of the Administrative 	required
		Contact for this domain
	
Admin-email 	Electronic mail address in RFC 822 	required
		format for the Administrative Contact 
		for this domain

Tech-name 	Name of the Technical Contact for this 	required
 		domain
	
Tech-address 	Postal address of the Administrative 	required
		Contact for this domain
	
		
                                  3

WNILS Working Group      Whois++ Lookup Service   Gargano, Weiss


Tech-telephone 	Telephone number of the Technical 	required
		Contact for this domain
	
Tech-email 	Electronic mail address in RFC 822 	required
		format for the Administrative Contact 
		for this domain

Nameservers 	Primary domain nameservers for this 	optional
		domain
	
Last-update 	Last date this record was updated	required


Search Options

A unique handle must be provided for every record in the serve
database to target specific records for display.  For example, if
there are three individuals named, respectively, A. La  Russo,
B. LaRusso, and C. Larusso, then a search for "LA RUSSO" would return
all three as matches.  However, each record would have a unique handle,
i.e. LARUSSO1, LARUSSO2, and LARUSSO3. A search for any one of these
handles would return a single match for that particular individual.
This is consistent with the RFC 954 query, "whois !SMITH1"

Other search options which should be supported are:

whois smith 		exact match on last name
	
whois smith,j 		exact match on last name, first name 
whois "smith,j" 	begins with "J"
whois j. Smith	
whois "j. Smith"	
	
whois smith, john 	exact match on last and  first names
whois "smith, john"	
whois john Smith	
whois "john Smith"	
whois .john Smith	
	
whois "smith..." 	all last names beginning 
whois smith*		with Smith
whois begins smith	
	
whois smith?? 		all last names beginning with
			"Smith" and containing up to two
			letters after "Smith",  i.e. "Smith",
			"Smithy", "Smithey" and "Smithie"
	
whois ends smith 	all last names ending in "smith"
	
whois exact A Martinez 	exact match for "A Martinez"
	

                                4

WNILS Working Group      Whois++ Lookup Service   Gargano, Weiss


whois fuzzy paulson 	all last names that sound like or
			are spelled like "Paulson"
	
whois first Kazuko 	exact match on first name "Kazuko"
	
whois first begins Art	all first names beginning with "Art"
	
whois first fuzzy Kasuko 	all first names that sound like or
				are spelled like "Kasuko"
	
whois hamlet.ucdavis.edu 	IP address and other information
whois system hamlet.ucdavis.edu	on the computer called
				hamlet.ucdavis.edu.Could be served
				by a domain name service querytype
				(QTYPE) *
 	 
whois system hamlet 	IP address and other 
 			information on the computer called
			hamlet with the default domain
			appended.  Could be served by a
			domain name service  querytype
			(QTYPE) *
	
whois 128.120.2.9 		domain name and other 
whois system 128.120.2.9 	information on the computer at
				specified IP address.  Could be served
				by a domain name service querytype
				(QTYPE) PTR.
	
whois !ucdavis-dom 		site contacts and other 
whois domain ucdavis.edu 	information  on the site ucdavis

If any keywords are specified in the query, the server will complete
that specific query and return the results (even if 0 matches are
found).  If no keywords are specified, the server will interpret the
query based upon the rules above. Optionally, the server may be
configured so that if a search yields no matches, the query will
automatically be run again, but with the keyword begin inserted.

Servers must support multiple levels of detail in response to queries.
A query yielding multiple matches should return a short-form record
for each match. A query yielding a single match should return a
long-form record. A query yielding no matches should return
context-sensitive help on expanding the search criteria.


On-line Help

The client should return a minimal (two line) help message for every
query sent to the server. That message should identify the database
being searched and provide instructions for the user to obtain more
detailed help screens.

                                5

WNILS Working Group      Whois++ Lookup Service    Gargano, Weiss


Additional help should be provided in special situations. The server
should recognize queries that return zero matches, and provide a brief
help message explaining how to broaden a search.  If a search returns
more than 50 matches, the server should take two actions.  First, the
user should get a message explaining how to narrow searches.  Second,
the user should be offered the option of re-specifying the search, or
receiving all matching responses.  When multiple matches are found and
returned to the client, the server should add a brief help message
explaining how to use handles to narrow the search to a single record.

If the client queries for "help" or "?" then the server should return
a complete help file.  The help file should contain information in
sufficient detail for the user to understand and access all the features
of WHOIS service.


V.	Extensibility

This Internet Draft defines a limited set of data records and fields
for reliable whois queries.   Mechanisms exist, Deutsch, et. al. August
1992, for whois clients to discover extended data records and query for
fields not defined in this draft.  It is recommended that Whois clients
and servers include this functionality to maximize the extensibility and
usefulness of this service. 


VI.	References

Deutsch, et al. Architecture of the WHOIS++ service. August 1992. 
Available by anonymous FTP as 
ftp.ucdavis.edu://pub/archive/wnils/Architecture.Overview

VII.	Authors Addresses

Joan Gargano
Information Technology
Distributed Computing Analysis and Support
University of California
Davis, CA   95616
[e-mail]

Ken Weiss
Information Technology
Distributed Computing Analysis and Support
University of California
Davis, CA   95616
[e-mail]


This Internet Draft expires December 31, 1993.


                                   6