As per Relevance of the word required, we have this rfc below:










Network Working Group S.
Request for Comments: 1714 M.
Category: Informational Network Solutions Inc

November 1994


Referral Whois Protocol (RWhois

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



This memo describes version 1.0 of the client/server interaction
RWhois. RWhois provides a distributed system for the display
hierarchical information. This system is hierarchical by design
allowing for the reduction of a query, and the referral of the
closer to the maintainer of the information

Table of

1. Introduction................................... 3
2. RWhois Client Model............................ 5
2.1 Directives: Client to Server Interaction ... 6
2.2 Required Directives ......................... 6
2.2.1 .................................. 6
2.2.2 RWhois................................... 7
2.3 Optional Directives ......................... 7
2.3.1 load..................................... 7
2.3.2 limit.................................... 7
2.3.3 schema................................... 8
2.3.4 xfer..................................... 8
2.3.5 quit..................................... 9
2.3.6 status................................... 9
2.3.7 cache.................................... 9
2.3.8 holdconnect..............................10
2.3.9 forward..................................10
2.3.10 soa.....................................11
2.3.11 notify..................................11
2.3.12 register................................13
2.3.13 object..................................14
2.3.14 define..................................15
2.3.15 private.................................15
2.3.16 X-......................................16



Williamson & Kosters [Page 1]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


2.3.17 directive...............................17
2.3.18 display.................................17
2.3.19 language................................18
2.4 RWhois Client Model .........................18
3. RWhois Server Model............................20
3.1 Output Display and Restriction Keywords .....20
3.2 Responses: Server to Client Interaction ....21
3.3 Required Responses ..........................22
3.3.1 RWhois...................................22
3.3.2 referral.................................22
3.3.3 ok.......................................24
3.3.4 error....................................24
3.4 Optional Responses ..........................25
3.4.1 see-also.................................25
3.4.2 load.....................................26
3.4.3 soa......................................26
3.4.4 status...................................28
3.4.5 xfer.....................................29
3.4.6 schema...................................30
3.4.7 define...................................32
3.4.8 object...................................32
3.4.9 directive................................33
3.4.10 info....................................34
3.4.11 display.................................34
3.4.12 X-......................................35
3.4.13 language................................35
3.5 Query Reduction .............................36
3.6 Determining Authority .......................36
3.7 Secondary Server Interaction ................37
3.8 Registration Process ........................38
3.9 Out-of-Service ..............................38
4. Interaction: Client Directives and
Server Responses...............................39
4.1 General ......................................39
4.2 On Connection ................................39
4.3 ......................................39
4.4 -RWhois ......................................40
4.5 -load ........................................40
4.6 -limit< value > ..........................40
4.7 -schema[object] ..........................40
4.8 -xfer[object] ............................40
4.9 -quit ........................................40
4.10 -cache ..........................40
4.11 -status .....................................40
4.12 -forward ....................................40
4.13 -soa ........................................40
4.14 -notify .....................................41
4.15 -register ...................................41



Williamson & Kosters [Page 2]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


4.16 -holdconnect ................................41
4.17 -object .....................................41
4.18 -define .....................................41
4.19 -X- .........................................41
4.20 -display ....................................41
4.21 -language ...................................41
5. Error Codes....................................42
5.1 Error Code List .............................42
6. Attribute Format...............................43
6.1 Format Specification Macros .................44
7. Quick Query (RWhois using UDP).................45
8. References.....................................46
9. Security Considerations....................... 46
10. Authors' Addresses.............................46

1.

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

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

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

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




Williamson & Kosters [Page 3]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


The InterNIC has also been involved in the use of X.500 for
of registration information. Among other things, this
defining schemas and Directory information tree structures for
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
for an alternative solution necessary

The information that the various IR's maintain is
hierarchical in nature. (Examples: hammer.nic.ddn.mil is under
nic.ddn.mil domain which is under the ddn.mil domain which is
the .mil domain. 198.41.0.21 is part of network 198.41.0.0/24
is part of the block 198.41.0.0/16 which is part of the
198.0.0.0/8) The InterNIC may not have the information, but will
least be able to reduce the query and point or refer the users
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
functionality of the whois server and client, making all of
extensions optional. The server must respond to the original
client, currently included with many operating systems. The
client must also interact with RFC 954 [RFC-954] whois servers

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

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

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


[arg] optional
required
() conditional required
([arg]) conditional optional
{format} format of
\ continued on next

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



Williamson & Kosters [Page 4]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


interact correctly with other RWhois servers

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

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

2. RWhois Client

The RWhois design requires compatibility with the current Whois
Whois++ servers. Therefore, the RWhois client must wait or
knowledge of server type to determine if the server contacted is
RWhois server. The user should have control over the time the
waits, since this will vary based on network congestion and capacity
If after the wait the server does not respond with the %
response, the client must not send any RWhois extended directives

In this case, the client should only send the query. We realize
the server identification feature may mean that the identity of
RWhois server may be missed. However, it will allow the
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
hierarchical tree. These servers represent a mesh structure from
RWhois perspective. This restriction should not discourage the
of these servers in building the RWhois structure

The RWhois server must remain connected until a query is received
If the client wishes to make multiple queries it must send
-holdconnect directive. In this mode, once the client has sent
last query and received either an answer or the error code
that no records were found, it must issue the -quit directive.
the client only wishes to issue directives, then upon completion
-quit directive must be sent. If it is not sent, the server
wait until it receives non-directive input from the client

Considering the requirement for compatibility with the
whois, the RWhois client in default mode must operate exactly
the current Whois client. However, in the enhanced mode, the
client can do much more based on information received from the
server







Williamson & Kosters [Page 5]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


2.1 Directives: Client to Server

The RWhois client sends directives to the RWhois server.
directives are prefaced with the `-' character always at the start
a new line. However, for compatibility with older Whois clients,
query is not prefaced with the `-' character. Only after the
is certain that the server is an RWhois server should
directives be sent. Compatibility with RFC 954 [RFC-954]
servers is required. All directives must be terminated by .

2.2 Required

The following are required RWhois client directives

2.2.1
The query is generally the final directive sent to the server. It
the only directive that does not start with a `-'. The query is
question that the client wants the server to answer. The
that may proceed the query are addressed in Section 3.1 -
Display and Restriction Keywords

Format for use

[display format][query restriction]
[Display format]{%s} This optional pre-query directive
the requester to select the format
the returned data. Details of
allowable values can be found in
3.1.

[Query restriction]{%s} This optional pre-query directive
the requester to limit the area in
the servers search for a
object

Example of use

dump domain netsol.











Williamson & Kosters [Page 6]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


2.2.2

The -RWhois directive identifies the client as an RWhois
allowing the server to operate using the RWhois protocol exclusively

Format for use

-RWhoisV-[imp identifier

{%2d.%2d} This required argument
the specification version that
client is built to conform with
Clients that are built
accordance with this document
V-1.0. This argument will be
by the server to determine
features introduced in
releases of the protocol
may be used

[Imp identifier]{%s} This optional argument identifies
implementation information. It
recommended that the implementor maintain
version number separate from
specification version

Example of use

-RWhois V-1.0 [InterNIC B.0.9.7]

2.3 Optional

The following are OPTIONAL RWhois server directives

2.3.1

The -load directive allows the client to make a quick decision
presenting the query to the current server. If the client
that another server can better serve the query, then control may
transferred to the server with the lower load and better connection
This directive has no arguments

2.3.2

The -limit directive will allow the client to request the
allocate enough space to collect more responses than would
be collected by the server




Williamson & Kosters [Page 7]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


Format for use

-limit
{%d} This required argument is the new limit requested
the client. If the limit exceeds the limit set
the server administrator, the client must receive
error message. It is recommended that if the
receives an error for exceeding the servers
limit, it should cut the request in half and
the request until an acceptable level has
negotiated

Example of use

-limit 2000

2.3.3

One of the shortcomings of X.500 was the requirement to know
schema of an object before making a query. RWhois allows the
to request the schema for an object without knowledge of the
by using the -schema directive

Format for use

-schema[object

[object]{%s} This optional argument identifies the objects
which the schema is being requested. If
argument is not sent, the schemas for all
contained in the server will be sent

Example of use

-schema

2.3.4

The -xfer directive is used to transfer all data from a server.
method of transfer has no limit on the number of records that can
transferred to the client application. This directive is
used to transfer data contained in an authority area for caching at
secondary server

Format for use

-xfer[object][authority area][SOA



Williamson & Kosters [Page 8]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


[Object]{All|%s} This required argument identifies
object to transfer. If the keyword
is sent, all objects contained in
server will be transferred. Otherwise
only the object specified will be sent

[Authority area]{%s} This optional argument contains
authority area of the object to
further limiting the data transfer

[SOA]{%d} This optional argument notifies the
to send everything that has been
since this SOA number

Example of use

-xfer domain netsol.
-xfer domain netsol.com 19940818141259

2.3.5

The -quit directive will inform the server that the client
finished. The server and client should close the connection.
directive has no arguments

2.3.6

The -status directive is used to poll the server for its status
There are seven required responses to this directive.
attributes may be sent in the response. The client should ignore
unknown attributes. This directive has no arguments

2.3.7

The RWhois server can hold data that it has no authority over.
the server sends this data to a requester, it is considered a non
authoritative response. The holding of this data is called caching
The physical data for these objects is not contained on the
hosting the server. The -cache directive allows the client
instruct the server whether or not to send cached data. The
client should start with the cache turned off. The server must
with the cache turned on in order to function like the RFC 954 [RFC
954] whois server. Because of the server's default, the
should send the -cache off directive during initial session setup
cached data should not be sent. Details on expiration of cache
can be found in section 3.4.3, %soa response





Williamson & Kosters [Page 9]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


Format for use

-cache
{on|off
on: Turns caching on
off: Turns caching off

Example of use
-cache

2.3.8

The RWhois server must close the connection after the response to
query has been received. The query is the final exchange between
client and server. However, this characteristic can be modified
the -holdconnect directive. If this directive is issued to
RWhois sever, it will remain connected until the -quit directive
received. Once the -quit directive is received, both the server
the client must close their connection

Format for use

-holdconnect
{on|off
On: Turns holdconnect on
Off: Turns holdconnect off

Example of use

-holdconnect

2.3.9

During normal sever operation the server will send %referral
see-also responses to the client, expecting the client to
the query to the server identified in the response. If the client
located behind a firewall or is poorly connected, having a
make the query may improve query performance or allow a query to
satisfied. The -forward directive will instruct the server
operate as a forwarding server. Whether or not this directive
be allowed should be a configuration parameter of the server








Williamson & Kosters [Page 10]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


Format for use

-forward
{on|off
On: Turns forwarding on
Off: Turns forwarding off

Example of use

-forward

2.3.10

The identification of authority area is an important part of
RWhois design. The -soa directive is used to question the server'
authority for a specific area. A positive response will include
administrative parameters for the authority area as detailed
section 3.4.3. If the server does not contain an SOA for
authority area requested, it must send an error message to
client

Format for use

-soa[authority area

[Authority area]{%s} This optional argument identifies
authority area being requested. If
argument is not sent, information
all authority areas contained in
server must be sent

Example of use

-soa netsol.

2.3.11

The -notify directive is used to notify a server of a bad
recursive referral or a change in a primary server's data

Format for use

-notify<information

{badref|recurref|update|inssec|delsec





Williamson & Kosters [Page 11]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


badref When a client receives a %referral response that
not work, it must report the bad referral to the
that issued the referral. The referral is bad only
the referred server does not contain the SOA record
the authority area in question. It is not considered
bad referral if the server does not have an answer
the query, but responds positively to the -soa
directive. This merely means that there is not
answer to the query. When a -badref is sent to
referring server; it should log the bad referral so
administrator of that server can remove the
if it is no longer correct. This action should only
taken after receiving a negative response to the
and the SOA request

recurref When a client receives a referral that results in
recursive action, the referring server must
informed. The -recurref directive must be
identifying the recursive loop. This directive
only be sent to the server one level back, even
multiple server were involved in the referral

update An RWhois primary server must be aware of
secondary servers. If the data in the primary
changes, the primary server may choose to notify
secondary servers. This allows the secondary
to quickly reflect changes in the primary server's data

inssec This action will inform the authority server that
server indicated in the argument will be a
for its authority area. The server receiving
directive must determine if the secondary
acceptable. If it is, the server should be added
the update list so that it will be informed if data
the authority area changes

delsec This action will inform the server that the
indicated in the subsequent arguments will no longer
a secondary. The server receiving this action
determine if the server is a secondary and if so
remove it from the update list

<information>{action=badref|recurref <:>
action=inssec|delsec|
<::<authority>>}






Williamson & Kosters [Page 12]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


{%Mserver} This required argument identifies the
that contained the recursive or bad referral
or has data that changed

{%s} This required argument identifies the
that was sent to the server that gave
recursive or bad referral

{%s} This required argument identifies the
that changed

<authority>{%s} This required argument identifies
authority area where the object that
currently resides

Example of use

-notify recurref netman1.netsol.com:4343:scottw@netsol.
-notify badref nic.ddn.mil:43:abc.af.
-notify update netman1.netsol.com:4343:domain:netsol.
-notify inssec dmeister.internic.net:4343:domain:netsol.
-notify delsec dmeister.internic.net:4343:domain:netsol.

2.3.12

This directive allows the client to add, modify, or
information that exists or should exist in the server's database
During the exchange, all attributes of an object must be sent.
client must wait to send the registration data until the %ok
is received from the server

Format for use

-register(on: <authority info>)

{on|off
on: This required argument starts
registration process

off: This required argument ends the
process

The following arguments are only required if the mode argument
sent with the value on

(){add|mod|del




Williamson & Kosters [Page 13]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


add: This conditionally required
indicates that the object being sent
be added to the server's database

mod: This conditionally required
indicates that the object being sent
be modified and should already exist in
server's database

del: This conditionally required
indicates that the object being sent
be deleted from the server's database

(){%Memail} This conditionally
argument identifies the sender
the registration information

(<authority info>){%s} This required argument
information used to
the person sending the
information. The method used
be identified using the -
directive. Work must be done
identify usable
methods for
delegation. This is beyond
scope of this document. However
the authors have made an effort
allow flexibility in
implementation of an
system

Example of use

-register on add scottw@netsol.
Object-type:
Referral:netman1.netsol.com:4343
Domain-Name:netsol.
IP-Network:192.153.247.0
IP-Network:198.41.0.0
-register

2.3.13

RWhois data is a collection of objects with defined attributes.
attributes for an object can be acquired by issuing the -
directive. Each object must at a minimum define the
object-type. This attribute identifies the name of the object



Williamson & Kosters [Page 14]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


will be displayed in response to the -object directive.
directive can be used by a client to verify that a server
the desired object. Another possible use may be to gather all of
objects contained on a server and display them to the user in
form of a menu for selection

Format for use

-object[object

[object]{%s} This optional argument identifies the
requested. If no argument is sent, all
contained in the server will be returned

Example of use

-object

2.3.14

Format strings describing the format of an object's attribute
include format macros. More information about definitions of
macros can be found in Section 6. The -define directive allows
client to request the definition of a format macro

Format for use

-define[macro name

[macro name]{%s} This optional argument identifies the name
the macro to display. If no arguments
sent, the server must return the
of all macros contained in the server

Example of use

-define

2.3.15

The -private directive allows the client to identify
authentication method to be used. More research needs to be
with respect to client authentication. This directive will
more experimentation







Williamson & Kosters [Page 15]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


Format for use

-private[data

{auth|encr} This required argument identifies the
the directive is taking. Currently the
for this argument can be auth
authentication or encr for encryption

{%s} This required argument contains the name
the method to be used. The value must
recognized by the server or an error will
sent. It is beyond the scope of
document to identify the possible method
be used

[data]{%s} This optional argument must be supplied
required by the method identified in
previous argument

Example of use

-private auth pass1 xxjdk998

The above example is a simple password exchange. It is beyond
scope of this document to determine the authentication technique
would best suit this protocol. Development is underway to
the authentication needs and to experiment with potential solutions

2.3.16 X

This directive is the preface to extended directives, mutually
to between the client and server. The client and server must
knowledge of the extended directives to use. Extension
accommodate other uses such as NetHelp, white pages, and many others
If the extensions are public, they should be documented in an RFC
available through the -directive directive














Williamson & Kosters [Page 16]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


Format for use

-X-<directive name>[directive arguments

<directive name>{%s} This required argument identifies
name of the directive being issued

[directive arguments]{?} This optional argument is dependent
the required or optional arguments
the extended directive. There may
multiple directive arguments

Example of use

-X-

2.3.17

Directives allowed by a server may vary. The client can issue
-directive directive to determine if the server allows a
directive or to obtain a list of all acceptable directives for
server

Format for use

-directive[directive

[directive][%s] This optional argument identifies the
being requested. If no arguments are sent,
of the directives accepted by the server
be sent

Example of use

-directive X-

2.3.18

The -display directive is used to set the display mode of the
or to identify display modes the client is capable of. If
directive is sent without arguments, the server will return
available display methods









Williamson & Kosters [Page 17]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


Format for use

-display[action][method

[action]{activate|capable
The `activate' setting enables a
display mode, while a `capable' setting
the display mode the client is capable of

[method]{%s} This optional argument indicates the
method desired by the client

Example of use

-display
-display

2.3.19

The -language directive is used to set the language mode of
server or to identify language modes the client is capable of.
this directive is sent without arguments, the server will return
available languages

Format for use

-language[language

[language]{%s} This optional argument indicates the
desired by the client

Example of use

-language

2.4 RWhois Client

Server <------->

START
<------ Connection (record time to connect
If no server type...Wait up to
time for------> "%RWhois"
(recommend wait of at least 5 seconds

if "%RWhois" is not received from server, assume that it
not an RWhois
goto QUERY



Williamson & Kosters [Page 18]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


else if "%RWhois" is received from
<------- send "-RWhois -VX.X
--------> receive "%ok
DIRECTIVE: if directive for
<------- send
-------> receive server
if "%ok"
goto DIRECTIVE
if "%error"
process error then goto DIRECTIVE
else if no more commands for
goto QUERY
QUERY
<-------- send
--------> Receive and display
PROCESS: if "%referral"
if first
restart server

add to server
if "%see-also"
insert server into server
if in holdconnection
goto DIRECTIVE
if no directive (%)
goto END
goto PROCESS
END
server will
if more servers on Queue and multi or referral mode
goto START

Every time the RWhois client receives a %referral or %see-
response from the RWhois server it must compare the host:port:
with those already executed. If the client discovers that it
being directed to repeat the same query to a server that it
already visited, it must not repeat that query. As an example,
prototype RWhois client maintains a server trail and compares
new directive with the entire list. If a recursive act is about
occur, the client will notify the user and exit. The original
client opens a TCP connection, sends the query, and displays
response. The RWhois client must be more robust in order to
multiple server queries, servers that do not exist, and
referrals. The client must also remain connected while
directives and receiving responses. All of these features have
incorporated into the experimental RWhois client





Williamson & Kosters [Page 19]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


3. RWhois Server

This section describes the functionality of the RWhois server

3.1 Output Display and Restriction

The RWhois server will behave similarly to the original whois
in terms of display formats and restrictions. The following
required in the RWhois server

Display Format

EXPand (*)

~ no sub

SUBdisplay (%) sub

SUMmary ($) Give a short summary for the query on one
many hits (defaults on multiple hits).

Full (=) Give the full record output on one to
hits (defaults on one hit only).

The following was added to whois post RFC 954 [RFC-954] and is
of the RWhois requirements

dump (#) Display the record in a parsable format

In addition to the above, the RWhois server must accept
pre-query directives such as Boolean queries and attribute=
query combinations. The capability to perform partial matches
requested by post fixing a `*' or `.' at the end of the search
for unknown characters. This capability is required for an
server

Example: last-name=williamson and first-name=

Data Restriction Format












Williamson & Kosters [Page 20]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


The following restriction keywords are found in the RFC 954
[RFC-954] whois server

!(handle) Query on Handle
mailbox Query on all records for
person Query on User records
host Query on Host records
domain Query on Domain records
network Query on Network Records
asn Query on Autonomous System Numbers

The RWhois server must allow restriction of search to any
contained on that server. With the exception of the `!'
format keyword, the above listed restriction keywords
defined objects. In the prototype software, each of these
are defined in configuration files, not hard-coded into the server
New objects, and therefore restriction keywords, should be
designed with no code change necessary to the server

3.2 Responses: Server to Client

Responses are sets of data that servers send in response to a
directive. Responses from an RWhois server must be prefaced with
`%' character at the start of a line. Responses are divided into
groups: those that are required to provide minimal
interaction and those that are used to achieve the
characteristics of a fully functional distributed system. A
must respond with an error message indicating that a directive is
available on the server and therefore does not have the
responses





















Williamson & Kosters [Page 21]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


3.3 Required

The following sections describe the required RWhois server responses

3.3.1

The %RWhois response is used to identify a server as an
server. Clients that treat RWhois servers differently will need
response to enable the RWhois capabilities

Format for use

RWhoisV-[imp name
version #]

[V-%2.2f] This required response
the version number of the
protocol specification that
software is capable of handling
The version described in
document is V-1.0.

[%s] This required response is the
name of the computer hosting
RWhois server

[imp name and version #][%s] This optional argument
information about the
implementation. It is
that the version number of
software be indicated.
version may differ from
specification version number

Example of use

%RWhois V-1.0 rs.internic.net (Network Solutions V-1.6)

3.3.2

The %referral response instructs the client to query another
(which could be a whois, RWhois, or whois++ server). Referrals
cumulative. The first referral received during a session
replace the default server list. Any subsequent referrals
must be appended to the end of the server list






Williamson & Kosters [Page 22]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


In the non-Uniform Resource Location (URL) response format below,
authority area equals the reduced query. There are three types
referral. The type can be determined by the client evaluating
authority area which is part of the %referral response

If the authority area received from a referral response is equal
the original query, then it is a link type referral. If
authority area is not equal to the query, then it is a reduction
referral. If no authority area is sent, then it is a punt
referral. (Punt means the server is not a root and cannot answer
query and therefore is referring the client to a level up the tree
to a server that can better answer the query.) [NOTE: the punt
referral may be used to direct a client into the whois++ mesh type.]

The client may receive multiple referrals from a single query.
the SOA for each of these referrals is the same, then the
referral is the primary server and all subsequent servers
secondary. Each of the servers will report the SOA for the
area in question

Format for use

%referral[:type][authority area
%referralurl:
{%Mserver} This required argument identifies
server that the client should re-
with

[type]{%Mstype} This optional argument identifies
server type. This could save wait time
the client trying to identify a
which is non-RWhois

<authority area>{%s} This optional argument identifies
authority area that caused the referral
the query in question. Using this value
the argument for the -soa directive
the referral server should result in
positive response. If this is not
case, the referral is considered bad

{%Murl} This required argument defines the
Resource Location (URL) string that
to the resource containing the
desired





Williamson & Kosters [Page 23]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


Example of use

%referral nic.ddn.mil:43 .
%referral url:http://www.netsol.com

3.3.3

The %ok response must be sent by the RWhois server at the
of every task or to positively acknowledge a directive

Format for use

%

3.3.4

The %error response is used to indicate an error condition to
client. Refer to Section 5 for details on the error
scheme. It is important to note that only the error number will
used to determine the client's action. The text message will only
used to make the error readable by humans connected using telnet
an old whois client. The only exception to this rule is the
message used to indicate problems with registration transactions
The format for these message can be found in Section 5.

Format for use

%error[error text

{%d} This required argument is the error
identified in Section 5. The client can
this number to categorize errors

[error text]{%s} This optional argument is the text
describes the error message. This
must be consistent for each error.
should not be added to this message.
message is only to make the error
human readable. Message sent following
error code associated with the
process will contain the line number of
attribute that is incorrect









Williamson & Kosters [Page 24]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


Example of use

%error400Invalid Server

3.4 Optional

The following are optional RWhois server responses

3.4.1 see-

The %see-also response instructs the client to contact another
for additional information about the current query. See-also
should be inserted into the server list just after the
server. If multiple see-alsos are received from a single query,
subsequent see-also should be inserted after any other see-
previously received. See-alsos should be additional
related to the current query

One example use for the see-also response is to display
system information relating to an IP network number or
interface information relating to an IP host number

Format for use

%see-also[:type]: %see-alsourl:
{%Mserver} This required argument identifies the
the client should reconnect with

[type]{%Mstype] This optional argument identifies the
type. This could save wait time for
client trying to identify a server which
non-RWhois

{%s} This required argument sets the query
must be sent to the referred server.
query may be different from the
query sent to the referring server

{%Murl} This required argument defines the
Resource Location (URL) string that points
the resource containing the
desired







Williamson & Kosters [Page 25]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


Example of use

%see-also prmd.merit.edu:43:handle=
%see-also url:http://www.netsol.com

3.4.2

The %load response returns the current and average load of
computer hosting the RWhois server. We realize that the
may be different depending on the implication of the system's
mechanism. This directive/response was implemented to
experiments with sorting preferred servers to deliver better
to the user

Format for use

%load
{%2.2f} This required argument delivers the
load on the system hosting the RWhois server

{%2.2f} This required argument delivers the
load on the system hosting the RWhois server

Example of use

%load 5.68 1.32

3.4.3

The %soa response delivers information about the authority area
question. If the server does not contain the authority for the
in question, it must respond with the appropriate error message.
SOA data must never be cached. SOA records must originate on
server giving the answer. The increment and refresh attributes
used to provide for incremental updates of the secondary server
Deleted data will remain in the secondary server's cache until
refresh time has been reached. This will reduce the amount of
transferred and not require the primary server to retain
data. The following are the minimum attributes required for the
object

object-








Williamson & Kosters [Page 26]

RFC 1714 Referral Whois Protocol (RWhois) November 1994



tech-
admin-



Format for use

%soaauthority:<authority area
%soattl: %soaserial: %soarefresh: %soaincrement:<incremental
%soaretry: %soatech-contact: %soaadmin-contact: %soahostmaster: %soaprimary:
<authority area>{%s} The authority name of the SOA. (Example
internic.net or 198.41.0.0/24)

{%d} The time to live for data within
authority area that another server may cache
The server caching the data should
the data expired after storage for the
of seconds identified by this attribute

{%Mserial} Serial number of the data contained in
authority area. The serial number must
incremented every time data in the
area has changed. It must be numeric

{%d} The time to completely remove cached data
transfer all data from the primary server

<increment>{%d} The time to wait before checking
incremental updates from a primary server

{%d} The time to wait before retrying
to a server that appears to be out-of-service

{%Memail} E-mail address of the person or
account responsible for the operation
the server






Williamson & Kosters [Page 27]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


{%Memail} E-mail address of the person or
account responsible for the
contained on the server

{%Memail} E-mail address to which changes of
server's data should be sent. A
edit tool can automatically send
to update the data on the server via e-mail

{%Mperm} Primary server for authority area

Example of use

%soa authority: netsol.
%soa ttl: 7200
%soa serial: 19940606203030
%soa refresh: 7200
%soa increment: 60
%soa retry: 1200
%soa tech-contact: markk@netsol.
%soa admin-contact: stanb@netsol.
%soa hostmaster: hostmaster@netsol.
%soa primary: netman1.netsol.com:4343
%

3.4.4

The %status response returns the status of several important flags
values. The response must contain the following elements

Limit: Current limit set on the server. This value
be changed using the -limit directive. This
not the maximum limit of the server. This
is not disclosed to prevent clients
automatically setting the highest limit possible
causing degradation in performance of the server

Load: This is the current load of the host system

Cache: Current status of the cache flag. (on or off

Holdconnect: Current status of the holdconnect flag. (on
off

Forward: Current status of the forward flag. (on or off

Authority records: Number of authority records in server'
database



Williamson & Kosters [Page 28]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


Cached records: Number of records in the server's
database

Display: Indicates the types of display modes
server is using

Format for use

%statuslimit: %statusload: %statuscache: %statusholdconnect: %statusforward: %statusAuthority: %statusCached: %statusDisplay:
See above for the description of these values

{%d
{%2.2f
{on|off
{on|off
{on|off
{%d
{%d
{single|multi
{%s

Example of use
%status limit: 1500
%status load: 1.23
%status cache:
%status holdconnect:
%status forward:
%status Authority:25
%status Cached:200
%status display multi:

3.4.5

The %xfer response will send all instances of an object. This is
response to the -xfer directive. The transfer may be limited by
arguments to the directive. If there are no arguments, the
must send all of the objects in the database. Cached data must
be transferred using this method unless caching is turned on





Williamson & Kosters [Page 29]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


Each object instance is sent with a blank %xfer response
instances

Format for use

%xfer[:<attribute>:]

These arguments are not required if the current response is an
instance separator

{%s} This required argument represents the name
the object being transferred

<attribute>{%s} This required argument identifies the
being sent

{%s} This required argument contains the value of
attribute. If blank, the attribute value
blank

Example of use

%xfer user:last-name:
%xfer user:first-name:
%xfer user:organization-phone:703-555-1212
%
%xfer user:last-name:
%xfer user:first-name:
%xfer user:organization-phone:703-555-1212
%

3.4.6

The %schema response is used to describe the attributes of an object
This is in response to the -schema directive

Each attribute is sent with a blank %schema as a separator

Format for use

%schema:attribute:<attribute name
%schema:format: %schema:description: %schema:indexed: %schema:required:<required
%schema:multi-line: %schema:type: %schema:primary:


Williamson & Kosters [Page 30]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


%

These arguments are not required if the current response is
attribute separator

<attribute name>{%s} This required argument identifies
name of the attribute being described

{%s} This required argument describes
allowed format for the attribute

{%s} This required argument describes
attribute's use

{on|off} This required argument
attributes that are indexed

<required>{on|off} This required argument
attributes that are required

{on|off} This required argument indicates
the attribute can span multiple lines

{text|MIME|see-also|PostScript
This required argument identifies
type of the attribute

{on|off} This required argument indicates
the attribute is a unique key

Example of use

%schema user:attribute:Object-
%schema user:description:Name of the
%
%schema user:attribute:
%schema user:format:[%Memail
%schema user:description:RFC-822 compliant Email
%
%schema user:attribute:Organization-
%schema user:format:[%3d[0-999]-%3d[0-999]-%4d[0-9999]]
%schema user:description:Work phone
%








Williamson & Kosters [Page 31]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


3.4.7

The %define response describes format macros to the client.
format macros used in the schema format definition string must
available to the client through the -define directive. Format
may be nested. It is the client's responsibility to request
format strings that are unrecognized from a server. If the
strings change on a server, the serial number of the schemas that
the format must change

Format for use

%define:<[format string]>

[NOTE: The brackets around the format string are required to
that spaces contained in the format string are interpreted
by the client.]

Example of use

%format server:[%s:%16Bd
%format email:[%s@%s

3.4.8

All visible objects on an RWhois server must be identified
response to a -object directive. The %object response
confirms the existence of an object or returns a complete list of
objects available to the currently connected user

A blank %object line serves as an object separator

Format for use

%
%object:description:description
%object:restrict:<restriction words

{%s} This required argument is the name
the object

description>{%s} This required argument is a
of the object identified

<restriction words>{%s} This required argument is a list
words used to restrict a search to
object




Williamson & Kosters [Page 32]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


Example of use

%object user:description:user records for entity
%object user:restrict:
%object user:restrict:
%object user:restrict:

3.4.9

The %directive response is used to display directives allowed on
connected server. The directive name, description and
attributes must be sent for each directive. If information about
single directive is requested then only information about
directive must be returned

A %directive response with no arguments must be sent
directives

Format for use

%directivedirective:<directive
%directivedescription:<description
%directivesyntax: %

The arguments below are required except when separating directives

<directive>{%s} This required argument indicates the name
the directive

<description>{%s} This required argument describes
directive

{%s} This required argument defines the format
the directive

Example of use

%directive directive:
%directive description:displays schema
%directive syntax:schema[%s
%
%directive directive:
%directive description:transfer all object[authority area
%directive syntax:xfer[%s][%s






Williamson & Kosters [Page 33]

RFC 1714 Referral Whois Protocol (RWhois) November 1994


3.4.10

The %info response is used to give the user of the client a message
This response is not initiated by any directive. The
between the %info on and the %info off should be presented to
user of the client. An ideal use of this response is to present
Message of The Day (MOTD) to the user

Format for use

%info
{on|off

on: Turns the passthru mode on
off: Turns the passthru mode off

Example of use

%info
As of 3/24/1994 at 9:00 EST this server will no longer be
service. If you have this server in your configuration file
recommend that you change it to rs.internic.net:4343. You
automatically be redirected there following this message
%info

3.4.11

The %display response is used to inform the client that the
following this response is using the indicated method. The
selected will continue to be active until a %display response is
without any arguments. The server must send an error message
clients that have been identified as non-RWhois clients.
response allows the use of display methods such as MIME [RFC 1521]
other special character sets such as those used in the
language

Format for use

%displayextended:<<