📄 rfc1714.txt
字号:
implementation information. It is
recommended that the implementor maintain a
version number separate from the
specification version.
Example of use:
-RWhois V-1.0 [InterNIC B.0.9.7]
2.3 Optional Directives
The following are OPTIONAL RWhois server directives.
2.3.1 load
The -load directive allows the client to make a quick decision about
presenting the query to the current server. If the client determines
that another server can better serve the query, then control may be
transferred to the server with the lower load and better connection.
This directive has no arguments.
2.3.2 limit
The -limit directive will allow the client to request the server
allocate enough space to collect more responses than would currently
be collected by the server.
Williamson & Kosters [Page 7]
RFC 1714 Referral Whois Protocol (RWhois) November 1994
Format for use:
-limit<SP><value>
<Value>{%d} This required argument is the new limit requested by
the client. If the limit exceeds the limit set by
the server administrator, the client must receive an
error message. It is recommended that if the client
receives an error for exceeding the servers upper
limit, it should cut the request in half and resend
the request until an acceptable level has been
negotiated.
Example of use:
-limit 2000
2.3.3 schema
One of the shortcomings of X.500 was the requirement to know the
schema of an object before making a query. RWhois allows the client
to request the schema for an object without knowledge of the object
by using the -schema directive.
Format for use:
-schema<SP>[object]
[object]{%s} This optional argument identifies the objects for
which the schema is being requested. If this
argument is not sent, the schemas for all objects
contained in the server will be sent.
Example of use:
-schema domain
2.3.4 xfer
The -xfer directive is used to transfer all data from a server. This
method of transfer has no limit on the number of records that can be
transferred to the client application. This directive is primarily
used to transfer data contained in an authority area for caching at a
secondary server.
Format for use:
-xfer<SP>[object]<SP>[authority area]<SP>[SOA]
Williamson & Kosters [Page 8]
RFC 1714 Referral Whois Protocol (RWhois) November 1994
[Object]{All|%s} This required argument identifies the
object to transfer. If the keyword all
is sent, all objects contained in the
server will be transferred. Otherwise,
only the object specified will be sent.
[Authority area]{%s} This optional argument contains the
authority area of the object to send
further limiting the data transfer.
[SOA]{%d} This optional argument notifies the server
to send everything that has been updated
since this SOA number.
Example of use:
-xfer domain netsol.com
-xfer domain netsol.com 19940818141259
2.3.5 quit
The -quit directive will inform the server that the client is
finished. The server and client should close the connection. This
directive has no arguments.
2.3.6 status
The -status directive is used to poll the server for its status.
There are seven required responses to this directive. Additional
attributes may be sent in the response. The client should ignore all
unknown attributes. This directive has no arguments.
2.3.7 cache
The RWhois server can hold data that it has no authority over. If
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 system
hosting the server. The -cache directive allows the client to
instruct the server whether or not to send cached data. The RWhois
client should start with the cache turned off. The server must start
with the cache turned on in order to function like the RFC 954 [RFC-
954] whois server. Because of the server's default, the client
should send the -cache off directive during initial session setup if
cached data should not be sent. Details on expiration of cache data
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<SP><mode>
<mode>{on|off}
on: Turns caching on.
off: Turns caching off.
Example of use:
-cache on
2.3.8 holdconnect
The RWhois server must close the connection after the response to a
query has been received. The query is the final exchange between the
client and server. However, this characteristic can be modified with
the -holdconnect directive. If this directive is issued to the
RWhois sever, it will remain connected until the -quit directive is
received. Once the -quit directive is received, both the server and
the client must close their connection.
Format for use:
-holdconnect<SP><mode>
<mode>{on|off}
On: Turns holdconnect on.
Off: Turns holdconnect off.
Example of use:
-holdconnect on
2.3.9 forward
During normal sever operation the server will send %referral or
see-also responses to the client, expecting the client to redirect
the query to the server identified in the response. If the client is
located behind a firewall or is poorly connected, having a server
make the query may improve query performance or allow a query to be
satisfied. The -forward directive will instruct the server to
operate as a forwarding server. Whether or not this directive should
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<SP><mode>
<mode>{on|off}
On: Turns forwarding on.
Off: Turns forwarding off.
Example of use:
-forward on
2.3.10 soa
The identification of authority area is an important part of the
RWhois design. The -soa directive is used to question the server's
authority for a specific area. A positive response will include the
administrative parameters for the authority area as detailed in
section 3.4.3. If the server does not contain an SOA for the
authority area requested, it must send an error message to the
client.
Format for use:
-soa<SP>[authority area]
[Authority area]{%s} This optional argument identifies the
authority area being requested. If this
argument is not sent, information about
all authority areas contained in the
server must be sent.
Example of use:
-soa netsol.com
2.3.11 notify
The -notify directive is used to notify a server of a bad or
recursive referral or a change in a primary server's data.
Format for use:
-notify<SP><action><SP><information>
<action>{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 does
not work, it must report the bad referral to the server
that issued the referral. The referral is bad only if
the referred server does not contain the SOA record for
the authority area in question. It is not considered a
bad referral if the server does not have an answer to
the query, but responds positively to the -soa area
directive. This merely means that there is not an
answer to the query. When a -badref is sent to the
referring server; it should log the bad referral so the
administrator of that server can remove the reference
if it is no longer correct. This action should only be
taken after receiving a negative response to the query
and the SOA request.
recurref When a client receives a referral that results in a
recursive action, the referring server must be
informed. The -recurref directive must be sent
identifying the recursive loop. This directive should
only be sent to the server one level back, even if
multiple server were involved in the referral.
update An RWhois primary server must be aware of its
secondary servers. If the data in the primary server
changes, the primary server may choose to notify the
secondary servers. This allows the secondary servers
to quickly reflect changes in the primary server's data.
inssec This action will inform the authority server that the
server indicated in the argument will be a secondary
for its authority area. The server receiving this
directive must determine if the secondary is
acceptable. If it is, the server should be added to
the update list so that it will be informed if data in
the authority area changes.
delsec This action will inform the server that the server
indicated in the subsequent arguments will no longer be
a secondary. The server receiving this action must
determine if the server is a secondary and if so,
remove it from the update list.
<information>{action=badref|recurref <<server>:<query>>
action=inssec|delsec|update
<<server>:<object>:<authority>>}
Williamson & Kosters [Page 12]
RFC 1714 Referral Whois Protocol (RWhois) November 1994
<server>{%Mserver} This required argument identifies the server
that contained the recursive or bad referral,
or has data that changed.
<query>{%s} This required argument identifies the query
that was sent to the server that gave a
recursive or bad referral.
<object>{%s} This required argument identifies the object
that changed.
<authority>{%s} This required argument identifies the
authority area where the object that changed
currently resides.
Example of use:
-notify recurref netman1.netsol.com:4343:scottw@netsol.com
-notify badref nic.ddn.mil:43:abc.af.mil
-notify update netman1.netsol.com:4343:domain:netsol.com
-notify inssec dmeister.internic.net:4343:domain:netsol.com
-notify delsec dmeister.internic.net:4343:domain:netsol.com
2.3.12 register
This directive allows the client to add, modify, or delete
information that exists or should exist in the server's database.
During the exchange, all attributes of an object must be sent. The
client must wait to send the registration data until the %ok response
is received from the server.
Format for use:
-register<SP><mode><SP>(on:<action><SP><e-mail contact>
<SP><authority info>)
<mode>{on|off}
on: This required argument starts the
registration process.
off: This required argument ends the registration
process.
The following arguments are only required if the mode argument is
sent with the value on:
(<action>){add|mod|del}
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -