Whois and Network Information Lookup Service Whois++ Ken Weiss Joan Gargano University of California, Davis Status of this Memo This paper proposes changes to the NICNAME/WHOIS protocol. This memo describes the protocol and the service. This is intended to update RFC 954. Distribution of this memo is unlimited. 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 Interrnet. Other distributed directory information servers and information retrieval tools have been developed 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 Group (WNILG) is to expand and define the standard for WHOIS types of services, to resolve issues associated with the variations in access and and provide a consistent and predictable service across the network. This paper describes features for consideration. Architecture 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 existance 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.ddn.mil. Client Design and Behavior The client provides the user interface to the WHOIS system, providing 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 charaters, 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. 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 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 required this record on the local server Last-update Date this record was last required updated Home-telephone Home telepone number optional Home-address Home postal address optional Host records Domain-name Fully qualified domain required name IP-address Complete IP address required Sysadmin Name of the System optional Administrator for this host Sysadmin-telephone Telephone number of the optional System Administrator for this host Sysadmin-address Postal address of the optional System Administrator for this host Sysadmin-email Electronic mail address in optional RFC 822 format of the System Administrator for this host Machine-type Type of machine or optional manufacturer Operating-system Operating system optional Mail-exchanger Fully qualified domain optional name of any machine acting as a mail exchanger for this host Last-update Date this record was last optional updated Domain records Domain-name Domain name registered with required the Network Information Center (NIC) Network-address Network address associated required with this domain name Admin-name Name of the Administrative required Contact for this domain Admin-address Postal address of the required Administrative Contact for this domain Admin-telephone Telepone number of the required Administrative Contact for this domain Admin-email Electronic mail address in required RFC 822 format for the Administrative Contact for this domain Tech-name Name of the Technical required Contact for this domain Tech-address Postal address of the required Administrative Contact for this domain Tech-telephone Telepone number of the required Technical Contact for this domain Tech-email Electronic mail address in required RFC 822 format for the Administrative Contact for this domain Nameservers Primary domain nameservers optional for this domain Last-update Last date this record was required updated Search Options A unique handle must be provided for every record in the server database to target specifc 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 consistant with the RFC 954 query, "whois !SMITH1" Other search options which should be supported are: *** This area needs work *** whois smith exact match on last name whois smith,j exact match on last name, whois "smith,j" first name 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 with Smith whois 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" 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 on whois system hamlet.ucdavis.edu 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 information on whois system 128.120.2.9 the computer at specified IP address. Could be served by a domain name service querytype (QTYPE) PTR. whois !ucdavis-dom site contacts and other information whois domain ucdavis.edu 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-senstive 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. 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 informaton in sufficient detail for the user to understand and access all the features of WHOIS service.