summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1834.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1834.txt')
-rw-r--r--doc/rfc/rfc1834.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc1834.txt b/doc/rfc/rfc1834.txt
new file mode 100644
index 0000000..144f572
--- /dev/null
+++ b/doc/rfc/rfc1834.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group J. Gargano
+Request for Comments: 1834 K. Weiss
+Category: Informational University of California, Davis
+ August 1995
+
+
+ Whois and Network Information Lookup Service
+ Whois++
+
+Status of this Memo
+
+ This memo provides information for the Internet community. This memo
+ does not specify an Internet standard of any kind. Distribution of
+ this memo is unlimited.
+
+I. Introduction
+
+ As currently defined, NICNAME/WHOIS [HARR85] 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 memo describes new features for WHOIS to
+ meet these goals.
+
+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
+
+
+
+Gargano & Weiss Informational [Page 1]
+
+RFC 1834 Whois++ Lookup Service August 1995
+
+
+ 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
+
+ Fax-telephone Fax telephone number optional
+
+ Work-address Work postal address optional
+
+
+
+
+
+Gargano & Weiss Informational [Page 2]
+
+RFC 1834 Whois++ Lookup Service August 1995
+
+
+ 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-record-update Date this record was last required
+ updated
+
+ Home-telephone Home telephone number optional
+
+ Home-address Home postal address optional
+
+
+ Host records
+
+ Hostname Full domain name required
+ IPAddress Address required
+ Sysadmin-name System administrator name optional
+ Sysadmin-phone System administrator telephone optional
+ Sysadmin-address System administrator address optional
+ Sysadmin-email System admin. e-mail address optional
+ Machine-type Type of machine optional
+ OS Operating system optional
+ MX Mail exchanger optional
+ Last-update Last update optional
+ Info Location of additional optional
+ information (i.e. anonymous FTP)
+
+
+ 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
+
+
+
+
+
+Gargano & Weiss Informational [Page 3]
+
+RFC 1834 Whois++ Lookup Service August 1995
+
+
+ Admin-address Postal address of the required
+ Admintistrative Contact for
+ this domain
+
+ Admin-telephone Telephone number of the required
+ Admintistrative Contact for
+ this domain
+
+ Admin-email Electronic mail address in required
+ RFC 1822 format for the
+ Administrative Contact for
+ this domain
+
+ Tech-name Name of the Technical Contact required
+ for this domain
+
+
+ Tech-address Postal address of the required
+ Administrative Contact
+ for this domain
+
+ Tech-telephone Telephone 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 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"
+
+
+
+
+Gargano & Weiss Informational [Page 4]
+
+RFC 1834 Whois++ Lookup Service August 1995
+
+
+ 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"
+
+ 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) *
+
+
+
+
+
+
+
+
+
+Gargano & Weiss Informational [Page 5]
+
+RFC 1834 Whois++ Lookup Service August 1995
+
+
+ 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.
+
+ 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.
+
+
+
+
+
+Gargano & Weiss Informational [Page 6]
+
+RFC 1834 Whois++ Lookup Service August 1995
+
+
+ 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 RFC defines a limited set of data records and fields for
+ reliable whois queries. Mechanisms exist for whois clients to
+ discover extended data records and query for fields not defined in
+ this memo. It is recommended that Whois clients and servers include
+ this functionality to maximize the extensibility and usefulness of
+ this service.
+
+VI. References
+
+ [Harr85] Harrenstein, K., Stahl, M., and E. Feinler, E.,
+ "NICNAME/WHOIS", RFC 954, SRI, October 1985.
+
+VII. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+VIII. Authors' Addresses
+
+ Joan Gargano
+ Information Technology
+ Distributed Computing Analysis and Support
+ University of California
+ Davis, CA 95616
+
+ EMail: jcgargano@ucdavis.edu
+
+
+ Ken Weiss
+ Information Technology
+ Distributed Computing Analysis and Support
+ University of California
+ Davis, CA 95616
+
+ EMail: krweiss@ucdavis.edu
+
+
+
+
+
+
+
+
+
+
+Gargano & Weiss Informational [Page 7]
+