User Services DREGs Ken Weiss Discussion Paper University of California, Davis July 8, 1992 Joan Gargano University of California, Davis Specifications for WHOIS Services 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. Newer 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 Directory Resources Engineering Group (DREGs) is to expand and define the standard for WHOIS types of services, to resolve issues associated with the variations in access and the advent of new information retrieval applications 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 discussion paper acknowledges the existance of many distributed directory information servers, and anticipates the creation of many more. To help users locate WHOIS servers, each directory server should be registered with the central NICNAME system. Each distributed server should have a domain name in the form "directory.domain", so that a search in the NICNAME database for "directory" will return a list of all distributed WHOIS servers and their IP addresses. The distributed servers should have a mechanism for automatically forwarding registration information to the central NICNAME database. A field in the local data specification identifies whether or not a given record should be forwarded to the NIC for central registration. Client Design and Behavior The client provides the user interface to the WHOIS/NICNAME 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. All text that follows the last keyword and precedes the CR/LF should be stripped of leading blanks and passed to the server as a single string. 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. 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: LARUSSO1, LARUSSO2, AND LARUSSO3. A search for any one of these handles would return a single match for that particular individual. whois !SMITH1 exact match on the handle, SMITH1 whois handle SMITH1 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 Every query should return a minimal (two line) help message. That message should identify the database being searched and provide instructions for the user to obtain more detailed help screens. Additional minimal help should be provided in special situations. The server should recoginze 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 most of the information in this memo, in sufficient detail for the user to understand and access all the features of WHOIS service. Information Content There are three types of data records supported in this proposal: records for people, hosts, and domains. Individual records Name required Organization required Work telephone optional Fax telephone optional Work address optional Title/Academic status optional Department/Unit/Major optional Electronic mail address optional Handle (server generated) required Forward information to NIC (Y/N) required Last update required Home telephone optional Home address optional Host records Full domain name required IP address required System administrator name optional System administrator telephone optional System administrator address optional System administrator e-mail address optional Type of machine optional Operating system optional Mail exchanger optional Last update optional Location of additional information optional (i.e. anonymous FTP) The data record for a domain should contain the following fields: Domain name required Administrative contact name required Administrative contact telephone required Administrative contact address required Administrative contact e-mail address required Technical contact name required Technical contact telephone required Technical contact address required Technical contact e-mail address required Domain nameservers optional Last update required Example of a friendly system $ whois -h argus.stanford.edu yundt Stanford University Whois Service "whois help" for general info | Problems to "whois-problem@networking" "whois update" for entry update info | Comments to "help@networking" name: Yundt, William H e-mail: gd.why@Forsythe organization: University department: Networking/Communication Sys position: Dir Networking/Comm address: Pine Hall 115 phone: (415) 723-3104 mail-code: 4122 home-address: 817 Lurline Drive, Foster City, Ca, 94404 handle: wyundt updated-by: download date-updated: May 22 1992 8:58PM Example of an unfriendly system $ whois -h uc.edu weiss WHOIS Server says hello to othello.ucdavis.edu [128.120.2.72] WHOIS Server received the following parameter: weiss Parameter Length = 7 User is Gary Weiss WHOIS Server end program. $ whois -h uc.edu "Gary Weiss" WHOIS Server says hello to othello.ucdavis.edu [128.120.2.72] WHOIS Server received the following parameter: Gary Weiss Parameter Length = 12 Unknown user... or other error! WHOIS Server end program.