rfc1714.txt

<VC++网络游戏建摸与实现>源代码

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:[e-mail]
   -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}




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


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

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

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

   (<e-mail contact>){%Memail}   This conditionally required
                                 argument identifies the sender of
                                 the registration information.

   (<authority info>){%s}        This required argument contains