1. Introduction

   Early in ARPANET development, the SRI-NIC established a centralized
   whois database that provided host and network information about the
   systems connected to the network and the E-mail addresses of the
   users on those systems.  The ARPANET experiment has evolved into a
   global network with countless people and hundreds of thousands of end
   systems.  Given the sheer size and effort needed to maintain a
   centralized database, an alternate, decentralized approach to store
   and display this information is desired.

   The Internet portions of the DDN NIC have been transitioned to what
   is now known as InterNIC Registration Services (RS).  The charter for
   InterNIC RS has been reduced to maintain information only for IP
   networks, top-level domains, Autonomous System Numbers, and the
   points of contact for each of these particular entities.  In
   addition, the InterNIC, in its role as an Internet Registry (IR), has
   delegated IP block assignment authority to Regional Registries such
   as the RIPE NCC for Europe and the APNIC for the Asian Pacific
   region, while retaining authority for North America and all non-
   delegated regions.  This has led to a fragmentation of whois service
   to the Internet user.

   Several different solutions have been proposed and developed by the
   various regional IR's.  Two solutions have been worked on
   extensively:  the Shared Whois Project (SWIP) and X.500.

   The SWIP project has a common exchange format that can be parsed by
   the various IR's for input and output.  Thus, one can synchronize
   their databases with information obtained from the other IR's.  This
   project is showing promise and is now operational.  However, this
   approach still requires a centralized database for store and display.

   The InterNIC has also been involved in the use of X.500 for display
   of registration information.  Among other things, this included
   defining schemas and Directory information tree structures for the
   purpose of distributing information amongst the various IR X.500
   Directory Service Agents (DSA).  Unfortunately, X.500's complexity,
   resource utilization, and lack of Internet support has made a search
   for an alternative solution necessary.

   The information that the various IR's maintain is inherently
   hierarchical in nature.  (Examples: hammer.nic.ddn.mil is under the
   nic.ddn.mil domain which is under the ddn.mil domain which is under
   the .mil domain. 198.41.0.21 is part of network 198.41.0.0/24 which
   is part of the block 198.41.0.0/16 which is part of the block
   198.0.0.0/8)  The InterNIC may not have the information, but will at
   least be able to reduce the query and point or refer the users closer
   to their goal.  This has led to the development of a referral whois,
   and the corresponding RWhois protocol.

   The underlying premise for this project has been to retain the basic
   functionality of the whois server and client, making all of the
   extensions optional.  The server must respond to the original whois
   client, currently included with many operating systems.  The RWhois
   client must also interact with RFC 954(-> 3912draft) [RFC-954] whois servers.

   RWhois has been designed as an extensible protocol to ensure that
   many uses can be accommodated.  Public extensions to the protocol
   should be documented as RFCs.  Private extensions can be used with
   agreement left up to the client and server.

   If extensions are not implemented at the server in question, an
   appropriate error message must be sent.  The use of extended error
   message is outlined in Section 5 - Error Codes.

   Throughout this document the following notations will be used to
   describe the RWhois server/client interaction:

     <SP>      space
     [arg]     optional argument
     <arg>     required argument
     (<arg>)   conditional required argument
     ([arg])   conditional optional argument
     {format}  format of item
     \         continued on next line

   The words should and must are significant in this document.  If
   should is used, the implementor has the option to follow the advice
   of this document.  If must is used then it is a required part of the
   protocol.  Implementations without this functionality may not
   interact correctly with other RWhois servers.

   The format descriptions throughout this document use macro
   definitions described in Section 6.1.  Refer to that section for
   clarification.

   The RWhois protocol specified in this document can be extended to
   accommodate such applications as NetHelp and ZoneGen (DNS zone
   generator).