home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1834 < prev    next >
Text File  |  1995-08-16  |  14KB  |  396 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         J. Gargano
  8. Request for Comments: 1834                                      K. Weiss
  9. Category: Informational                  University of California, Davis
  10.                                                              August 1995
  11.  
  12.  
  13.               Whois and Network Information Lookup Service
  14.                                 Whois++
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. I.  Introduction
  23.  
  24.    As currently defined, NICNAME/WHOIS [HARR85] service is a TCP
  25.    transaction based query/response server, running on a few specific
  26.    central machines, that provides netwide directory service to Internet
  27.    users.  The Network Information Center (NIC) maintains the central
  28.    NICNAME database and server, defined in RFC 954, providing online
  29.    look-up of individuals, network organizations, key host machines, and
  30.    other information of interest to users of the Internet.  The
  31.    usefulness of this service has lead to the development of other
  32.    distributed directory information servers and information retrieval
  33.    tools and it is anticipated more will be created.  Many sites now
  34.    maintain local directory servers with information about individuals,
  35.    departments and services at that specific site.
  36.  
  37.    Typically these directory servers are network accessible.  Local
  38.    development of these services has resulted in wide variations in the
  39.    type of data stored, access methods, search schemes, and user
  40.    interfaces.  The purpose of the Whois and Network Information Lookup
  41.    Service Working Group (WNILS) is to expand and define the standard
  42.    for WHOIS types of services, to resolve issues associated with the
  43.    variations in access and provide a consistent and predictable service
  44.    across the network.  This memo describes new features for WHOIS to
  45.    meet these goals.
  46.  
  47. II.  Architecture
  48.  
  49.    The WHOIS service should be provided in a client/server model.  There
  50.    are no restrictions on the design of the client, provided it is
  51.    capable of passing queries to the server in the proper format, and
  52.    capturing the server's response in some useful format.  Existing
  53.    WHOIS specifications call for clients to display responses in human-
  54.    readable form.  This more general proposal does not impose that
  55.  
  56.  
  57.  
  58. Gargano & Weiss              Informational                      [Page 1]
  59.  
  60. RFC 1834                 Whois++ Lookup Service              August 1995
  61.  
  62.  
  63.    restriction.
  64.  
  65.    This paper acknowledges the existence of many distributed information
  66.    servers, and anticipates the creation of many more. To help users
  67.    locate WHOIS servers, each server should have a nameserver entry in
  68.    the form "whois.domain", i.e. whois.internic.net.
  69.  
  70. III.  Client Design and Behavior
  71.  
  72.    The client provides the user interface to the WHOIS system and a
  73.    mechanism for query generation and display of the response.  The
  74.    client is responsible for providing support for paging of long output
  75.    from the server.  All clients must provide this service.  The server
  76.    will not include any special characters, or make any efforts to
  77.    control output to a screen.
  78.  
  79.    Special search criteria may be specified by the use of keywords or
  80.    special characters, some of which are defined in RFC 954.  Clients
  81.    should be designed to make support for quoted strings unnecessary.
  82.  
  83. IV.  Server Design and Behavior
  84.  
  85.    The server should return the same information in response to a given
  86.    query consistently, regardless of the client software or the hardware
  87.    used to originate the query. Queries should be evaluated on a case-
  88.    insensitive basis. Spaces should not be considered in searches.  A
  89.    search for "La Russo" should return both "LaRusso" and "La Russo" as
  90.    matches.
  91.  
  92.    There are three types of data records supported in this proposal:
  93.    records for people, hosts, and domains.
  94.  
  95.    Individual records
  96.  
  97.    Name                    Name of the individual          required
  98.  
  99.    Organization            Name of the organization        required
  100.  
  101.    Organization-type       Type of organization            optional
  102.                            (university, commercial research)
  103.  
  104.    Work-telephone          Work telephone number           optional
  105.  
  106.    Fax-telephone           Fax telephone number            optional
  107.  
  108.    Work-address            Work postal address             optional
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Gargano & Weiss              Informational                      [Page 2]
  115.  
  116. RFC 1834                 Whois++ Lookup Service              August 1995
  117.  
  118.  
  119.    Title                   Working title or position       optional
  120.                            within an organization
  121.  
  122.    Department              Department                      optional
  123.  
  124.    Email-address           Email address in RFC 822        optional
  125.                            format for this individual
  126.  
  127.    Handle                  A unique identifier for this    required
  128.                            record on the local server
  129.  
  130.    Last-record-update      Date this record was last       required
  131.                            updated
  132.  
  133.    Home-telephone          Home telephone number           optional
  134.  
  135.    Home-address            Home postal address             optional
  136.  
  137.  
  138.    Host records
  139.  
  140.    Hostname                Full domain name                required
  141.    IPAddress               Address                         required
  142.    Sysadmin-name           System administrator name       optional
  143.    Sysadmin-phone          System administrator telephone  optional
  144.    Sysadmin-address        System administrator address    optional
  145.    Sysadmin-email          System admin. e-mail address    optional
  146.    Machine-type            Type of machine                 optional
  147.    OS                      Operating system                optional
  148.    MX                      Mail exchanger                  optional
  149.    Last-update             Last update                     optional
  150.    Info                    Location of additional          optional
  151.                            information (i.e. anonymous FTP)
  152.  
  153.  
  154.    Domain records
  155.  
  156.    Domain-name             Domain name registered with     required
  157.                            the Network Information Center
  158.                            (NIC)
  159.  
  160.    Network-address         Network address associated      required
  161.                            with this domain name
  162.  
  163.    Admin-name              Name of the Administrative      required
  164.                            Contact for this domain
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Gargano & Weiss              Informational                      [Page 3]
  171.  
  172. RFC 1834                 Whois++ Lookup Service              August 1995
  173.  
  174.  
  175.    Admin-address           Postal address of the           required
  176.                            Admintistrative Contact for
  177.                            this domain
  178.  
  179.    Admin-telephone         Telephone number of the         required
  180.                            Admintistrative Contact for
  181.                            this domain
  182.  
  183.    Admin-email             Electronic mail address in      required
  184.                            RFC 1822 format for the
  185.                            Administrative Contact for
  186.                            this domain
  187.  
  188.    Tech-name               Name of the Technical Contact   required
  189.                            for this domain
  190.  
  191.  
  192.    Tech-address            Postal address of the           required
  193.                            Administrative Contact
  194.                            for this domain
  195.  
  196.    Tech-telephone          Telephone number of the         required
  197.                            Technical Contact for this
  198.                            domain
  199.  
  200.    Tech-email              Electronic mail address in      required
  201.                            RFC 822 format for the
  202.                            Administrative Contact
  203.                            for this domain
  204.  
  205.    Nameservers             Primary domain nameservers      optional
  206.                            for this domain
  207.  
  208.    Last-update             Last date this record was       required
  209.                            updated
  210.  
  211. Search Options
  212.  
  213.    A unique handle must be provided for every record in the server
  214.    database to target specific records for display.  For example, if
  215.    there are three individuals named, respectively, A. La  Russo, B.
  216.    LaRusso, and C. Larusso, then a search for "LA RUSSO" would return
  217.    all three as matches.  However, each record would have a unique
  218.    handle, i.e. LARUSSO1, LARUSSO2, and LARUSSO3. A search for any one
  219.    of these handles would return a single match for that particular
  220.    individual.  This is consistent with the RFC 954 query, "whois
  221.    !SMITH1"
  222.  
  223.  
  224.  
  225.  
  226. Gargano & Weiss              Informational                      [Page 4]
  227.  
  228. RFC 1834                 Whois++ Lookup Service              August 1995
  229.  
  230.  
  231.    Other search options which should be supported are:
  232.  
  233.    whois smith             exact match on last name
  234.  
  235.    whois smith,j           exact match on last name, first name
  236.    whois "smith,j"         begins with "J"
  237.    whois j. Smith
  238.    whois "j. Smith"
  239.  
  240.    whois smith, john       exact match on last and first names
  241.    whois "smith, john"
  242.    whois john Smith
  243.    whois "john Smith"
  244.    whois .john Smith
  245.    whois "smith..."        all last names beginning
  246.    whois smith*            with Smith
  247.    whois begins smith
  248.  
  249.    whois smith??           all last names beginning with
  250.                            "Smith" and containing up to two
  251.                            letters after "Smith", i.e. "Smith",
  252.                            "Smithy", "Smithey" and "Smithie"
  253.  
  254.    whois ends smith        all last names ending in "smith"
  255.  
  256.    whois exact A Martinez  exact match for "A Martinez"
  257.  
  258.    whois fuzzy paulson     all last names that sound like or
  259.                            are spelled like "Paulson"
  260.  
  261.    whois first Kazuko      exact match on first name "Kazuko"
  262.  
  263.    whois first begins Art  all first names beginning with "Art"
  264.  
  265.    whois first fuzzy Kasuko  all first names that sound like or are
  266.                              spelled like "Kasuko"
  267.  
  268.    whois hamlet.ucdavis.edu  IP address and other information
  269.    whois system hamlet.ucdavis.edu on the computer called
  270.                                    hamlet.ucdavis.edu.Could be served
  271.                                    by a domain name service querytype
  272.                                    (QTYPE) *
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Gargano & Weiss              Informational                      [Page 5]
  283.  
  284. RFC 1834                 Whois++ Lookup Service              August 1995
  285.  
  286.  
  287.    whois system hamlet     IP address and other
  288.                            information on the computer called
  289.                            hamlet with the default domain
  290.                            appended.  Could be served by a
  291.                            domain name service querytype
  292.                            (QTYPE) *
  293.  
  294.    whois 128.120.2.9       domain name and other
  295.    whois system 128.120.2.9  information on the computer at
  296.                              specified IP address.  Could be served
  297.                              by a domain name service querytype
  298.                              (QTYPE) PTR.
  299.  
  300.    whois !ucdavis-dom              site contacts and other
  301.    whois domain ucdavis.edu        information on the site ucdavis
  302.  
  303.    If any keywords are specified in the query, the server will complete
  304.    that specific query and return the results, even if 0 matches are
  305.    found.  If no keywords are specified, the server will interpret the
  306.    query based upon the rules above. Optionally, the server may be
  307.    configured so that if a search yields no matches, the query will
  308.    automatically be run again, but with the keyword begin inserted.
  309.  
  310.    Servers must support multiple levels of detail in response to
  311.    queries.  A query yielding multiple matches should return a short-
  312.    form record for each match. A query yielding a single match should
  313.    return a long-form record. A query yielding no matches should return
  314.    context-sensitive help on expanding the search criteria.
  315.  
  316. On-line Help
  317.  
  318.    The client should return a minimal (two line) help message for every
  319.    query sent to the server. That message should identify the database
  320.    being searched and provide instructions for the user to obtain more
  321.    detailed help screens.
  322.  
  323.    Additional help should be provided in special situations. The server
  324.    should recognize queries that return zero matches, and provide a
  325.    brief help message explaining how to broaden a search.  If a search
  326.    returns more than 50 matches, the server should take two actions.
  327.    First, the user should get a message explaining how to narrow
  328.    searches.  Second, the user should be offered the option of re-
  329.    specifying the search, or receiving all matching responses.  When
  330.    multiple matches are found and returned to the client, the server
  331.    should add a brief help message explaining how to use handles to
  332.    narrow the search to a single record.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Gargano & Weiss              Informational                      [Page 6]
  339.  
  340. RFC 1834                 Whois++ Lookup Service              August 1995
  341.  
  342.  
  343.    If the client queries for "help" or "?" then the server should return
  344.    a complete help file.  The help file should contain information in
  345.    sufficient detail for the user to understand and access all the
  346.    features of WHOIS service.
  347.  
  348. V.  Extensibility
  349.  
  350.    This RFC defines a limited set of data records and fields for
  351.    reliable whois queries.   Mechanisms exist for whois clients to
  352.    discover extended data records and query for fields not defined in
  353.    this memo.  It is recommended that Whois clients and servers include
  354.    this functionality to maximize the extensibility and usefulness of
  355.    this service.
  356.  
  357. VI.  References
  358.  
  359.    [Harr85] Harrenstein, K., Stahl, M., and E. Feinler, E.,
  360.             "NICNAME/WHOIS", RFC 954, SRI, October 1985.
  361.  
  362. VII.  Security Considerations
  363.  
  364.    Security issues are not discussed in this memo.
  365.  
  366. VIII.  Authors' Addresses
  367.  
  368.    Joan Gargano
  369.    Information Technology
  370.    Distributed Computing Analysis and Support
  371.    University of California
  372.    Davis, CA   95616
  373.  
  374.    EMail: jcgargano@ucdavis.edu
  375.  
  376.  
  377.    Ken Weiss
  378.    Information Technology
  379.    Distributed Computing Analysis and Support
  380.    University of California
  381.    Davis, CA   95616
  382.  
  383.    EMail: krweiss@ucdavis.edu
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Gargano & Weiss              Informational                      [Page 7]
  395.  
  396.