As per Relevance of the word telephone, we have this rfc below:
Network Working Group J.
Request for Comments: 1834 K.
Category: Informational University of California,
August 1995
Whois and Network Information Lookup
Whois++
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
I.
As currently defined, NICNAME/WHOIS [HARR85] service is a
transaction based query/response server, running on a few
central machines, that provides netwide directory service to
users. The Network Information Center (NIC) maintains the
NICNAME database and server, defined in RFC 954, providing
look-up of individuals, network organizations, key host machines,
other information of interest to users of the Internet.
usefulness of this service has lead to the development of
distributed directory information servers and information
tools and it is anticipated more will be created. Many sites
maintain local directory servers with information about individuals
departments and services at that specific site
Typically these directory servers are network accessible.
development of these services has resulted in wide variations in
type of data stored, access methods, search schemes, and
interfaces. The purpose of the Whois and Network Information
Service Working Group (WNILS) is to expand and define the
for WHOIS types of services, to resolve issues associated with
variations in access and provide a consistent and predictable
across the network. This memo describes new features for WHOIS
meet these goals
II.
The WHOIS service should be provided in a client/server model.
are no restrictions on the design of the client, provided it
capable of passing queries to the server in the proper format,
capturing the server's response in some useful format.
WHOIS specifications call for clients to display responses in human
readable form. This more general proposal does not impose
Gargano & Weiss Informational [Page 1]
RFC 1834 Whois++ Lookup Service August 1995
restriction
This paper acknowledges the existence of many distributed
servers, and anticipates the creation of many more. To help
locate WHOIS servers, each server should have a nameserver entry
the form "whois.domain", i.e. whois.internic.net
III. Client Design and
The client provides the user interface to the WHOIS system and
mechanism for query generation and display of the response.
client is responsible for providing support for paging of long
from the server. All clients must provide this service. The
will not include any special characters, or make any efforts
control output to a screen
Special search criteria may be specified by the use of keywords
special characters, some of which are defined in RFC 954.
should be designed to make support for quoted strings unnecessary
IV. Server Design and
The server should return the same information in response to a
query consistently, regardless of the client software or the
used to originate the query. Queries should be evaluated on a case
insensitive basis. Spaces should not be considered in searches.
search for "La Russo" should return both "LaRusso" and "La Russo"
matches
There are three types of data records supported in this proposal
records for people, hosts, and domains
Individual
Name Name of the individual
Organization Name of the organization
Organization-type Type of organization
(university, commercial research
Work-telephone Work telephone number
Fax-telephone Fax telephone number
Work-address Work postal address
Gargano & Weiss Informational [Page 2]
RFC 1834 Whois++ Lookup Service August 1995
Title Working title or position
within an
Department Department
Email-address Email address in RFC 822
format for this
Handle A unique identifier for this
record on the local
Last-record-update Date this record was last
Home-telephone Home telephone number
Home-address Home postal address
Host
Hostname Full domain name
IPAddress Address
Sysadmin-name System administrator name
Sysadmin-phone System administrator telephone
Sysadmin-address System administrator address
Sysadmin-email System admin. e-mail address
Machine-type Type of machine
OS Operating system
MX Mail exchanger
Last-update Last update
Info Location of additional
information (i.e. anonymous FTP
Domain
Domain-name Domain name registered with
the Network Information
(NIC
Network-address Network address associated
with this domain
Admin-name Name of the Administrative
Contact for this
Gargano & Weiss Informational [Page 3]
RFC 1834 Whois++ Lookup Service August 1995
Admin-address Postal address of the
Admintistrative Contact
this
Admin-telephone Telephone number of the
Admintistrative Contact
this
Admin-email Electronic mail address in
RFC 1822 format for
Administrative Contact
this
Tech-name Name of the Technical Contact
for this
Tech-address Postal address of the
Administrative
for this
Tech-telephone Telephone number of the
Technical Contact for
Tech-email Electronic mail address in
RFC 822 format for
Administrative
for this
Nameservers Primary domain nameservers
for this
Last-update Last date this record was
Search
A unique handle must be provided for every record in the
database to target specific records for display. For example,
there are three individuals named, respectively, A. La Russo, B
LaRusso, and C. Larusso, then a search for "LA RUSSO" would
all three as matches. However, each record would have a
handle, i.e. LARUSSO1, LARUSSO2, and LARUSSO3. A search for any
of these handles would return a single match for that
individual. This is consistent with the RFC 954 query, "
!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
whois smith,j exact match on last name, first
whois "smith,j" begins with "J
whois j.
whois "j. Smith
whois smith, john exact match on last and first
whois "smith, john
whois john
whois "john Smith
whois .john
whois "smith..." all last names
whois smith* with
whois begins
whois smith?? all last names beginning
"Smith" and containing up to
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
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
spelled like "Kasuko
whois hamlet.ucdavis.edu IP address and other
whois system hamlet.ucdavis.edu on the computer
hamlet.ucdavis.edu.Could be
by a domain name service
(QTYPE) *
Gargano & Weiss Informational [Page 5]
RFC 1834 Whois++ Lookup Service August 1995
whois system hamlet IP address and
information on the computer
hamlet with the default
appended. Could be served by
domain name service
(QTYPE) *
whois 128.120.2.9 domain name and
whois system 128.120.2.9 information on the computer
specified IP address. Could be
by a domain name service
(QTYPE) PTR
whois !ucdavis-dom site contacts and
whois domain ucdavis.edu information on the site
If any keywords are specified in the query, the server will
that specific query and return the results, even if 0 matches
found. If no keywords are specified, the server will interpret
query based upon the rules above. Optionally, the server may
configured so that if a search yields no matches, the query
automatically be run again, but with the keyword begin inserted
Servers must support multiple levels of detail in response
queries. A query yielding multiple matches should return a short
form record for each match. A query yielding a single match
return a long-form record. A query yielding no matches should
context-sensitive help on expanding the search criteria
On-line
The client should return a minimal (two line) help message for
query sent to the server. That message should identify the
being searched and provide instructions for the user to obtain
detailed help screens
Additional help should be provided in special situations. The
should recognize queries that return zero matches, and provide
brief help message explaining how to broaden a search. If a
returns more than 50 matches, the server should take two actions
First, the user should get a message explaining how to
searches. Second, the user should be offered the option of re
specifying the search, or receiving all matching responses.
multiple matches are found and returned to the client, the
should add a brief help message explaining how to use handles
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
a complete help file. The help file should contain information
sufficient detail for the user to understand and access all
features of WHOIS service
V.
This RFC defines a limited set of data records and fields
reliable whois queries. Mechanisms exist for whois clients
discover extended data records and query for fields not defined
this memo. It is recommended that Whois clients and servers
this functionality to maximize the extensibility and usefulness
this service
VI.
[Harr85] Harrenstein, K., Stahl, M., and E. Feinler, E.,
"NICNAME/WHOIS", RFC 954, SRI, October 1985.
VII. Security
Security issues are not discussed in this memo
VIII. Authors'
Joan
Information
Distributed Computing Analysis and
University of
Davis, CA 95616
EMail: jcgargano@ucdavis.
Ken
Information
Distributed Computing Analysis and
University of
Davis, CA 95616
EMail: krweiss@ucdavis.
Gargano & Weiss Informational [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
