📄 rfc1714.txt
字号:
many hits (defaults on multiple hits).
Full (=) Give the full record output on one to many
hits (defaults on one hit only).
The following was added to whois post RFC 954 [RFC-954] and is part
of the RWhois requirements:
dump (#) Display the record in a parsable format.
In addition to the above, the RWhois server must accept additional
pre-query directives such as Boolean queries and attribute=value
query combinations. The capability to perform partial matches are
requested by post fixing a `*' or `.' at the end of the search item
for unknown characters. This capability is required for an RWhois
server.
Example: last-name=williamson and first-name=scott
Data Restriction Format Keywords
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 only
mailbox Query on all records for person
person 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
The RWhois server must allow restriction of search to any object
contained on that server. With the exception of the `!' restriction
format keyword, the above listed restriction keywords represent
defined objects. In the prototype software, each of these objects
are defined in configuration files, not hard-coded into the server.
New objects, and therefore restriction keywords, should be easily
designed with no code change necessary to the server.
3.2 Responses: Server to Client Interaction
Responses are sets of data that servers send in response to a client
directive. Responses from an RWhois server must be prefaced with the
`%' character at the start of a line. Responses are divided into two
groups: those that are required to provide minimal RWhois
interaction and those that are used to achieve the desired
characteristics of a fully functional distributed system. A server
must respond with an error message indicating that a directive is not
available on the server and therefore does not have the required
responses.
Williamson & Kosters [Page 21]
RFC 1714 Referral Whois Protocol (RWhois) November 1994
3.3 Required Responses
The following sections describe the required RWhois server responses.
3.3.1 RWhois
The %RWhois response is used to identify a server as an RWhois
server. Clients that treat RWhois servers differently will need this
response to enable the RWhois capabilities.
Format for use:
RWhois<SP>V-<Spec version #><SP><server name><SP>[imp name and
version #]
<Spec version #>[V-%2.2f] This required response indicates
the version number of the RWhois
protocol specification that the
software is capable of handling.
The version described in this
document is V-1.0.
<server name>[%s] This required response is the host
name of the computer hosting the
RWhois server.
[imp name and version #][%s] This optional argument contains
information about the server
implementation. It is recommended
that the version number of the
software be indicated. This
version may differ from the
specification version number.
Example of use:
%RWhois V-1.0 rs.internic.net (Network Solutions V-1.6)
3.3.2 referral
The %referral response instructs the client to query another server
(which could be a whois, RWhois, or whois++ server). Referrals are
cumulative. The first referral received during a session must
replace the default server list. Any subsequent referrals received
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, the
authority area equals the reduced query. There are three types of
referral. The type can be determined by the client evaluating the
authority area which is part of the %referral response.
If the authority area received from a referral response is equal to
the original query, then it is a link type referral. If the
authority area is not equal to the query, then it is a reduction type
referral. If no authority area is sent, then it is a punt type
referral. (Punt means the server is not a root and cannot answer the
query and therefore is referring the client to a level up the tree or
to a server that can better answer the query.) [NOTE: the punt type
referral may be used to direct a client into the whois++ mesh type.]
The client may receive multiple referrals from a single query. If
the SOA for each of these referrals is the same, then the first
referral is the primary server and all subsequent servers are
secondary. Each of the servers will report the SOA for the authority
area in question.
Format for use:
%referral<SP><server>[:type]<SP>[authority area]
%referral<SP>url:<url>
<server>{%Mserver} This required argument identifies the
server that the client should re-connect
with.
[type]{%Mstype} This optional argument identifies the
server type. This could save wait time for
the client trying to identify a server
which is non-RWhois.
<authority area>{%s} This optional argument identifies the
authority area that caused the referral for
the query in question. Using this value as
the argument for the -soa directive to
the referral server should result in a
positive response. If this is not the
case, the referral is considered bad.
<url>{%Murl} This required argument defines the Uniform
Resource Location (URL) string that points
to the resource containing the information
desired.
Williamson & Kosters [Page 23]
RFC 1714 Referral Whois Protocol (RWhois) November 1994
Example of use:
%referral nic.ddn.mil:43 .mil
%referral url:http://www.netsol.com/
3.3.3 ok
The %ok response must be sent by the RWhois server at the completion
of every task or to positively acknowledge a directive.
Format for use:
%ok
3.3.4 error
The %error response is used to indicate an error condition to the
client. Refer to Section 5 for details on the error reporting
scheme. It is important to note that only the error number will be
used to determine the client's action. The text message will only be
used to make the error readable by humans connected using telnet or
an old whois client. The only exception to this rule is the error
message used to indicate problems with registration transactions.
The format for these message can be found in Section 5.
Format for use:
%error<SP><error number><SP>[error text]
<error number>{%d} This required argument is the error number
identified in Section 5. The client can use
this number to categorize errors.
[error text]{%s} This optional argument is the text that
describes the error message. This message
must be consistent for each error. Variables
should not be added to this message. This
message is only to make the error message
human readable. Message sent following an
error code associated with the registration
process will contain the line number of the
attribute that is incorrect.
Williamson & Kosters [Page 24]
RFC 1714 Referral Whois Protocol (RWhois) November 1994
Example of use:
%error<SP>400<SP>Invalid Server Directive
3.4 Optional Responses
The following are optional RWhois server responses.
3.4.1 see-also
The %see-also response instructs the client to contact another server
for additional information about the current query. See-also servers
should be inserted into the server list just after the current
server. If multiple see-alsos are received from a single query, each
subsequent see-also should be inserted after any other see-alsos
previously received. See-alsos should be additional information
related to the current query.
One example use for the see-also response is to display autonomous
system information relating to an IP network number or router
interface information relating to an IP host number.
Format for use:
%see-also<SP><server>[:type]:<query>
%see-also<SP>url:<url>
<server>{%Mserver} This required argument identifies the server
the client should reconnect with.
[type]{%Mstype] This optional argument identifies the server
type. This could save wait time for the
client trying to identify a server which is
non-RWhois.
<query>{%s} This required argument sets the query that
must be sent to the referred server. The
query may be different from the original
query sent to the referring server.
<url>{%Murl} This required argument defines the Uniform
Resource Location (URL) string that points to
the resource containing the information
desired.
Williamson & Kosters [Page 25]
RFC 1714 Referral Whois Protocol (RWhois) November 1994
Example of use:
%see-also prmd.merit.edu:43:handle=xxx
%see-also url:http://www.netsol.com/
3.4.2 load
The %load response returns the current and average load of the
computer hosting the RWhois server. We realize that the measurement
may be different depending on the implication of the system's load
mechanism. This directive/response was implemented to allow
experiments with sorting preferred servers to deliver better results
to the user.
Format for use:
%load <SP><current><SP><average>
<current>{%2.2f} This required argument delivers the current
load on the system hosting the RWhois server.
<average>{%2.2f} This required argument delivers the average
load on the system hosting the RWhois server.
Example of use:
%load 5.68 1.32
3.4.3 soa
The %soa response delivers information about the authority area in
question. If the server does not contain the authority for the area
in question, it must respond with the appropriate error message. The
SOA data must never be cached. SOA records must originate on the
server giving the answer. The increment and refresh attributes are
used to provide for incremental updates of the secondary server.
Deleted data will remain in the secondary server's cache until the
refresh time has been reached. This will reduce the amount of data
transferred and not require the primary server to retain deleted
data. The following are the minimum attributes required for the soa
object:
object-type
authority
ttl
serial
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -