rfc1714.txt

中、英文RFC文档大全打包下载完全版 .

   !(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
      refresh
      increment



Williamson & Kosters                                           [Page 26]

RFC 1714            Referral Whois Protocol (RWhois)       November 1994


      retry
      tech-contact
      admin-contact
      hostmaster
      primary

   Format for use:

   %soa<SP>authority:<SP><authority area>
   %soa<SP>ttl:<SP><ttl>
   %soa<SP>serial:<SP><serial>
   %soa<SP>refresh:<SP><refresh>
   %soa<SP>increment:<SP><incremental>
   %soa<SP>retry:<SP><retry>
   %soa<SP>tech-contact:<SP><tech-contact>
   %soa<SP>admin-contact:<SP><admin-contact>
   %soa<SP>hostmaster:<SP><hostmaster>
   %soa<SP>primary:<SP><primary>

   <authority area>{%s}  The authority name of the SOA. (Example:
                         internic.net or 198.41.0.0/24)

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

   <serial>{%Mserial}  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.  It must be numeric.

   <refresh>{%d}       The time to completely remove cached data and
                       transfer all data from the primary server.

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

   <retry>{%d}         The time to wait before retrying connection
                       to a server that appears to be out-of-service.