Network Working Group Scott Williamson Someday an Internet Draft Mark Kosters March 1994 Network Solutions Inc./ InterNIC Referral Whois Protocol (RWhois) Abstract This memo describes the client/server interaction of RWhois. RWhois provides a distributed system for the display of hierarchical information. This system is hierarchical by design allowing for the reduction of an original query and referral of the requester closer to the maintainer of the information. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. 1.0 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 storing and displaying 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,APNIC for the Asian Pacific region, and to itself 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 DSA's. 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 which is part of the 256 block of 198.41 which is part of the big block 198.) 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 the original whois server. Throughout this document the following notations will be used to describe the RWhois server/client interaction. space [aug] optional part of the directive or response required part of the directive or response server server's fully qualified domain name port server's TCP/IP port number query question to ask the server \ continued on next line 2.0 RWhois client model The RWhois design requires compatibility with the current Whois and Whois++ servers. Therefore, the RWhois client must wait to determine if the server contacted is an RWhois server. The user should have control over the time the client waits, since this will vary based on network congestion and capacity. If after the wait the server does not respond with the %RWhois response, the client must not send any RWhois extended directives. In this case, the client should only send the query. This server identification feature will allow the RWhois system to utilize the current Whois and Whois++ infrastructure. Referrals from RWhois can be directed toward a Whois or Whois++ server. These non-RWhois servers must be placed as a leaf on the hierarchical tree. These servers represent a mesh structure from the RWhois perspective. This restriction should not discourage the use of these servers in building the RWhois structure. 2.1 DIRECTIVES: Client to Server Interaction The RWhois client sends directives to the RWhois server. These directives are prefaced with the '-' character always at the start of a new line. However, for compatibility with older Whois clients, the query is not prefaced with the '-' character. Only after the client is certain that the server is an RWhois server should these directives be sent. Compatibility with the original Whois server is required. The following are acceptable RWhois server directives: -RWhoisV- -load -limit -schema[type] -xfer[type] -quit -status -cache -holdconnect -forward -soa[authority area] -badref -recurref -registeron\ * -registeroff * Must work on some type of authentication for unsupervised delegation. Considering the requirement for compatibility with the original whois, the RWhois client in default mode must operate exactly like the current Whois client. However, in the enhanced mode, the RWhois client can do much more based on information received from the RWhois server. 2.2 RWhois Client model. Server <-------> Client START: <------ Connection ( record time to connect) Wait up to specified time for ------> "%RWhois" ( recommend wait of 5 seconds ) if "%RWhois" is not received from server assume that it is not an RWhois server goto QUERY: else if "%RWhois" is received from server <------- send "-RWhois -VX.X" --------> receive "%ok" COMMAND: if command for server <------- send command -------> receive server response if %ok received goto COMMAND: if %error received process error then goto COMMAND: else if no more commands for server goto QUERY: QUERY: <-------- send query --------> Receive and display response PROCESS: if %referral received if first referral restart server list else add to server list if %see-also received insert server into current list if in holdconnection mode goto COMMAND: if no directive (%) goto END: goto PROCESS: END: server will disconnect if more servers on Queue and multi or referral mode active goto START: Every time the RWhois client receives a referral or see-also response from the RWhois server it must compare the host:port:query with those already executed. If the client discovers that it is being directed to repeat the same query to a server that it has already visited, it must not repeat that query. As an example, the experimental RWhois client maintains a server trail and compares each new directive with the entire list. If a recursive act is about to occur, the client will notify the user and exit. The original Whois client opens a TCP connection, sends the query, and displays the response. The RWhois client must be more robust in order to handle multiple server queries, servers that do not exist, and recursive referrals. The client must also remain connected while sending directives and receiving responses. All of these features have been incorporated into the experimental RWhois client. 3.0 RWhois server model 3.1 Original Whois server The RWhois server will behave similarly to the original whois server in terms of display formats and restrictions: Display format Keywords: ? Expand ~ no sub displays % sub displays summary Give a short summary for the query on one to many hits (defaults on multiple hits). full Give the full record output one to many hits (defaults on one hit only). dump Display the record in a parsable format. # same as dump above. Data Restriction Format Keywords: ! Query on Handle only user Query on User records only* host Query on Host records only* domain Query on Domain records only* network Query on Network Records only* asn Query on Autonomous System Numbers only* * These objects are defined in configuration files that are not hard-coded into the server. New Objects can be easily designed with no code change necessary in the server. 3.2 RWhois directives (commands) Extensions The RWhois server must allow for additional commands such as Boolean queries and attribute=value query combinations. Partial matches can be found by post fixing a "*" at the end of the search item or inserting a "." for unknown characters. Example: last-name=williamson and first-name=scott The RWhois server adds the following Data Restriction Format Keywords: nsap Query on Network Service Access Point address only* 3.3 RESPONSES: Server to client interaction Responses from the RWhois server are prefaced with the '%' character at the start of the line. Acceptable responses are: %RWhoisserverV- [example: %RWhois rs.internic.net V-1.0.1] %referral [example: %referral nic.ddn.mil:43 .mil] This refers the query to another whois server (could be whois, RWhois, or whois++). If = query then the referral is a link. If != query then the referral is a reduction. If = "" then the referral is a punt. ( Punt means the server is not a root and cannot answer the query and is referring the client to the next level) %see-also [example: %see-also prmd.merit.edu:43:handle=xxx] This brings additional information to this particular record. %load [example: %load 5.68 1.32] %ok %error [example: %error400Invalid Server Directive] There is some sort of error on the server %soaauthority: %soattl: %soaserial: %soarefresh: %soaretry: %soatech-contact: %soaadmin-contact: %soahostmaster: [example: %soa authority: netsol.com %soa ttl: 7500 %soa serial: 45 %soa refresh: 3600 %soa retry: 3600 %soa tech-contact: markk@netsol.com %soa admin-contact: joe@netsol.com %soa hostmaster: hostmaster@netsol.com %ok ] authority: The authority name of the SOA. [string] ( Example: internic.net or 198.41.0.0/24 ) ttl: The time to live for data within this authority area that another serve may cache. The server caching the data should consider the data expired after the time given. [numeric] serial: Serial number of the data contained in the authority area. The serial number must be incremented every time data in the authority area has changed. The number must be numeric. A single decimal point may be used. [numeric (no more than one decimal)] ( 1, 1.1, and 1.123 are acceptable. 1.1.2 is not acceptable.) refresh: The time to completely remove cached data after failure to update. [numeric] retry: The time to wait before retrying contact of a server that appears to be out-of-service. [numeric] tech-contact: E-mail address of the person or role account responsible for the operation of the server. [string: legal e-mail address] admin-contact: E-mail address of the person or role account responsible for the data contained on the server. [string: legal e-mail address] hostmaster: E-mail address that changes to the data should be send. Data edit tool can automatically send changes to data. [string: legal e-mail address] %statuslimit: %statusload: %statuscache: %statusholdconnect: [Example: %status limit: 1500 %status load: 1.234 %status cache: on %status holdconnect: off] limit: Current session's limit. Either the default limit or the limit set by the "-limit" directive. [numeric] load: Current load of the system hosting the RWhois server. [numeric] cache: Current status of the cache flag. This will either be "on" or "off". [string: on/off] holdconnect: Current status of the holdconnect flag. This will either be "on" or "off". [string: on/off] The critical component of the referral whois server is the ability to reduce the query to find a server that is "closer" to the data. The search algorithm of the server is the following: 1) accept a query, 2) find any local matches - display them 3) find any referrals - display them 4) if no local or referral hits, reduce the query and goto 3 Here is an example of the query ietf.cnri.reston.va.us : 1) query whois for ietf.cnri.reston.va.us 2) search rs.internic.net for information (no hits). 3) search referrals for ietf.cnri.reston.va.us (no hits). 4) search referrals for cnri.reston.va.us (no hits). 5) search referrals for reston.va.us (no hits). 6) search referrals for va.us (no hits). 7) search referrals for us (referral found) - referral to isi.edu. [currently on rs.internic.net:4343 for proof of concept]. 4.0 INTERACTION: Client directive and acceptable server responses Expected responses to directives: GENERAL %ok %error400Invalid Server Directive %error100Get Peer Name query failed %error500Memory Allocation Problem %error401Not authorized for directive %error402Unidentified error ... continue %error502Unrecoverable error ... goodbye ON CONNECTION %RWhoisserverV- %error501Service not available %referral %referral %see-also %error334pre-query directive not implemented %error230No Records Found %error130Not authority for answer ... TTL good %error231Not authority for answer ... TTL expired -RWhoisV- %error300Not compatible with that version number -load %loadXX.XXXX.XX %error335Systems load not available -limit< value > %error330Exceeded Max Records Limit %error331Invalid Max Records Size -schema[type] %error330schema type not found -xfer[ type ] %error332Nothing to transfer %error330schema type not found -quit %ok -cache %error232Cache disabled -status %statuslimit: %statusload: %statuscache: %statusholdconnect: -forward %error431Server cannot forward request %error433Bad reference on forward -soa %soadomain: %soattl: