📄 rfc1714.txt
字号:
Network Working Group S. Williamson
Request for Comments: 1714 M. Kosters
Category: Informational Network Solutions Inc.
InterNIC
November 1994
Referral Whois Protocol (RWhois)
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This memo describes version 1.0 of 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 a query, and the referral of the user
closer to the maintainer of the information.
Table of Contents
1. Introduction................................... 3
2. RWhois Client Model............................ 5
2.1 Directives: Client to Server Interaction ... 6
2.2 Required Directives ......................... 6
2.2.1 <query>.................................. 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 Acceptable
Server Responses...............................39
4.1 General ......................................39
4.2 On Connection ................................39
4.3 <QUERY> ......................................39
4.4 -RWhois ......................................40
4.5 -load ........................................40
4.6 -limit<SP>< value > ..........................40
4.7 -schema<SP>[object] ..........................40
4.8 -xfer<SP>[object] ............................40
4.9 -quit ........................................40
4.10 -cache<SP><on/off> ..........................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. 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.
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 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 [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
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 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).
2. RWhois Client Model
The RWhois design requires compatibility with the current Whois and
Whois++ servers. Therefore, the RWhois client must wait or have
knowledge of server type 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. We realize that
the server identification feature may mean that the identity of an
RWhois server may be missed. However, it 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.
The RWhois server must remain connected until a query is received.
If the client wishes to make multiple queries it must send the
-holdconnect directive. In this mode, once the client has sent the
last query and received either an answer or the error code indicating
that no records were found, it must issue the -quit directive. If
the client only wishes to issue directives, then upon completion the
-quit directive must be sent. If it is not sent, the server will
wait until it receives non-directive input from the client.
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.
Williamson & Kosters [Page 5]
RFC 1714 Referral Whois Protocol (RWhois) November 1994
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 RFC 954 [RFC-954] whois
servers is required. All directives must be terminated by <LF><CR>.
2.2 Required Directives
The following are required RWhois client directives.
2.2.1 <query>
The query is generally the final directive sent to the server. It is
the only directive that does not start with a `-'. The query is the
question that the client wants the server to answer. The qualifiers
that may proceed the query are addressed in Section 3.1 - Output
Display and Restriction Keywords.
Format for use:
[display format]<SP>[query restriction]<SP><query>
[Display format]{%s} This optional pre-query directive allows
the requester to select the format of
the returned data. Details of the
allowable values can be found in Section
3.1.
[Query restriction]{%s} This optional pre-query directive allows
the requester to limit the area in which
the servers search for a specific
object.
Example of use:
dump domain netsol.com
Williamson & Kosters [Page 6]
RFC 1714 Referral Whois Protocol (RWhois) November 1994
2.2.2 RWhois
The -RWhois directive identifies the client as an RWhois client
allowing the server to operate using the RWhois protocol exclusively.
Format for use:
-RWhois<SP>V-<spec version #><SP>[imp identifier]
<Spec version #>{%2d.%2d} This required argument identifies
the specification version that the
client is built to conform with.
Clients that are built in
accordance with this document are
V-1.0. This argument will be used
by the server to determine if
features introduced in subsequent
releases of the protocol document
may be used.
[Imp identifier]{%s} This optional argument identifies client
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -