rfc1913.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

     _______
    |       |
    |   A   |__
    |_______|  \            _______
                \----------|       |
     _______               |   D   |__             ______
    |       |   /----------|_______|  \           |      |
    |   B   |__/                       \----------|      |
    |_______|                                     |  F   |
                                       /----------|______|
                                      /
     _______                _______  /
    |       |              |       |-
    |   C   |--------------|   E   |
    |_______|              |_______|-
                                     \
                                      \
     _______                           \            ______
    |       |                           \----------|      |
    |   G   |--------------------------------------|  H   |
    |_______|                                      |______|

             Figure 1: Sample layout of the Index Service mesh

   In the portion of the index tree shown above, whois++ servers A and B
   hand their centroids up to index server D, whois++ server C hands its
   centroid up to index server E, and index servers D and E hand their
   centroids up to index server F. Servers E and G also hand their
   centroids up to H.

   The number of levels of index servers, and the number of index
   servers at each level, will depend on the number of whois++ servers
   deployed, and the response time of individual layers of the server
   tree. These numbers will have to be determined in the field.



Weider, et al               Standards Track                     [Page 6]

RFC 1913       Architecture of the Whois++ Index Service   February 1996


5.3.3. Centroid propogation and changes to centroids

   Centroid propogation is initiated by an authenticated POLL command
   (sec. 5.2).  The format of the POLL command allows the poller to
   request the centroid of any or all templates and attributes held by
   the polled server. After the polled server has authenticated the
   poller, it determines which of the requested centroids the poller is
   allowed to request, and then issues a CENTROID-CHANGES report (sec.
   5.3) to transmit the data. When the poller receives the CENTROID-
   CHANGES report, it can authenticate the pollee to determine whether
   to add the centroid changes to its data. Additionally, if a given
   pollee knows what pollers hold centroids from the pollee, it can
   signal to those pollers the fact that its centroid has changed by
   issuing a DATA-CHANGED command. The poller can then determine if and
   when to issue a new POLL request to get the updated information. The
   DATA-CHANGED command is included in this protocol to allow
   'interactive' updating of critical information.

5.3.4. Centroid propogation and mesh traversal

   When an index server issues a POLL request, it may indicate to the
   polled server what relationship it has to the polled. This
   information can be used to help traverse the directory mesh. Two
   fields are specified in the current proposal to transmit the
   relationship information, although it is expected that richer
   relationship information will be shared in future revisions of this
   protocol.

   One field used for this information is the Hierarchy field, and can
   take on three values. The first is 'topology', which indicates that
   the indexing server is at a higher level in the network topology
   (e.g. indexes the whole regional ISP). The second is 'geographical',
   which indicates that the polling server covers a geographical area
   subsuming the pollee. The third is 'administrative', which indicates
   that the indexing server covers an administrative domain subsuming
   the pollee.

   The second field used for this information is the Description field,
   which contains the DESCRIBE record of the polling server. This allows
   users to obtain richer metainformation for the directory mesh,
   enabling them to expand queries more effectively.

5.3.5. Query handling and passing algorithms

   When an index server receives a query, it searches its collection of
   centroids and determines which servers hold records which may fill
   that query. As whois++ becomes widely deployed, it is expected that
   some index servers may specialize in indexing certain whois++



Weider, et al               Standards Track                     [Page 7]

RFC 1913       Architecture of the Whois++ Index Service   February 1996


   templates or perhaps even certain fields within those templates. If
   an index server obtains a match with the query "for those template
   fields and attributes the server indexes", it is to be considered a
   match for the purpose of forwarding the query.

5.3.5.1. Query referral

   Query referral is the process of informing a client which servers to
   contact next to resolve a query.  The syntax for notifying a client
   is outlined in section 5.5.

5.3.6 Loop control

   Since there are no a priori restrictions on which servers may poll
   which other servers, and since a given server may participate in many
   sub-meshes, mechanisms must be installed to allow the detection of
   cycles in the polling relationships. This is accomplished in the
   current protocol by including a hop-count on polling relationships.
   Each time a polled server generates forward information, it informs
   the polling server about its current hopcount, which is the maximum
   of the hopcounts of all the servers it polls, plus 1.  A base level
   server (one which polls no other servers) will have a hopcount of 0.
   When a server decides to poll a new server, if its hopcount goes up,
   then it must information all the other servers which poll it about
   its new hopcount.  A maximum hopcount (8 in the current version) will
   help the servers detect polling loops.

   A second approach to loop detection is to do all the work in the
   client; which would determine which new referrals have already
   appeared in the referral list, and then simply iterate the referral
   process until there are no new servers to ask.  An algorithm to
   accomplish this in WHOIS++ is detailed in [Faltstrom 95].

6. Syntax for operations of the Index Service:

   The syntax for each protocol componenet is listed below. In addition,
   each section contains a listing of which of these attributes is
   required and optional for each of the componenet. All timestamps must
   be in the format YYYYMMDDHHMM and in GMT.

6.1. Data changed syntax

   The data changed template look like this:

# DATA-CHANGED
 Version-number: // version number of index service software, used to
                 // insure compatibility. Current value is 1.0
 Time-of-latest-centroid-change: // time stamp of latest centroid



Weider, et al               Standards Track                     [Page 8]

RFC 1913       Architecture of the Whois++ Index Service   February 1996


                                 // change, GMT
 Time-of-message-generation: // time when this message was generated,
                             // GMT
 Server-handle: // IANA unique identifier for this server
 Host-Name: // Host name of this server (current name)
 Host-Port: // Port number of this server (current port)
 Best-time-to-poll: // For heavily used servers, this will identify
                    // when the server is likely to be lightly
                    // loaded so that response to the poll will be
                    //speedy, GMT
 Authentication-type: // Type of authentication used by server, or NONE
 Authentication-data: // data for authentication
# END // This line must be used to terminate the data changed
                 // message

Required/optional table

Version-Number  REQUIRED
Time-of-latest-centroid-change  REQUIRED
Time-of-message-generation      REQUIRED
Server-handle   REQUIRED
Host-Name       REQUIRED
Host-Port       REQUIRED
Best-time-to-poll       OPTIONAL
Authentication-type     OPTIONAL
Authentication-data     OPTIONAL

6.2. Polling syntax

# POLL:
 Version-number: // version number of poller's index software, used to
                 // insure compatibility
 Type-of-poll: // type of forward data requested. CENTROID or QUERY
               // are the only one currently defined
 Poll-scope: // Selects bounds within which data will be returned.
             // See note.
 Start-time: // give me all the centroid changes starting at this
             // time, GMT
 End-time: // ending at this time, GMT
 Template: // a standard whois++ template name, or the keyword ALL,
           // for a full update.
 Field:    // used to limit centroid update information to specific
           // fields, is either a specific field name, a list of field
           // names, or the keyword ALL
 Server-handle: // IANA unique identifier for the polling server.
                // this handle may optionally be cached by the polled
                // server to announce future changes
 Host-Name: // Host name of the polling server.



Weider, et al               Standards Track                     [Page 9]

RFC 1913       Architecture of the Whois++ Index Service   February 1996


 Host-Port: // Port number of the polling server.
 Hierarchy: // This field indicates the relationship which the poller
              // bears to the pollee. Typical values might include
              // 'Topology', 'Geographical", or "Administrative"
 Description: // This field contains the DESCRIBE record of the
                // polling server
 Authentication-type: // Type of authentication used by poller, or NONE
 Authentication-data: // Data for authentication
# END  // This line must by used to terminate the poll message

   Note: For poll type CENTROID, the allowable values for Poll Scope are
   FULL and RELATIVE. Support of the FULL value is required, this
   provides a complete listing of the centroid or other forward
   information. RELATIVE indicates that these are the relative changes
   in the centroid since the last report to the polling server.

   For poll type QUERY, the allowable values for Poll Scope are a blank
   line, which indicates that all records are to be returned, or a valid
   WHOIS++ query, which indicates that just those records which satisfy
   the query are to be returned. N.B. Security considerations may
   require additional authentication for successful response to the
   Blank Line Poll Scope. This value has been included for server
   replication.

   A polling server may wish to index different types of information
   than the polled server has collected. The POLLED-FOR command will
   indicate which servers the polled server has contacted.

Required/Optional Table

Version-Number  REQUIRED, value is 1.0
Type-Of-Poll    REQUIRED, values CENTROID and QUERY are required
Poll-scope      REQUIRED  If Type-of-poll is CENTROID, FULL is required,
                          RELATIVE is optional
                          If Type-of-poll is QUERY, Blank line is
                          required, and WHOIS++-type queries are
                          required
Start-time      OPTIONAL
End-Time        OPTIONAL
Template        REQUIRED
Field           REQUIRED
Server-handle   REQUIRED
Host-Name       REQUIRED
Host-Port       REQUIRED
Hierarchy       OPTIONAL
Description     OPTIONAL
Authentication-Type:    OPTIONAL
Authentication-data:    OPTIONAL



Weider, et al               Standards Track                    [Page 10]

RFC 1913       Architecture of the Whois++ Index Service   February 1996


Example of a POLL command:
# POLL:
 Version-number: 1.0
 Type-of-poll: CENTROID
 Poll-scope: FULL
 Start-time: 199501281030+0100
 Template: ALL
 Field: ALL
 Server-handle: BUNYIP01
 Host-Name: services.bunyip.com
 Host-Port: 7070
 Hierarchy: Geographical
 # END

6.3. Centroid change report

   As the centroid change report contains nested multiply-occuring
   blocks, each multiply occurring block is surrounded *in this paper*
   by curly braces '{', '}'. These curly braces are NOT part of the
   syntax, they are for identification purposes only.

   The syntax of a Data: item is either a list of words, one word per
   line, or the keyword:

     ANY

   The keyword ANY as the only item of a Data: list means that any value
   for this field should be treated as a hit by the indexing server.

   The field Any-field: needs more explanation than can be given in the
   body of the syntax description below. It can take two values, True or
   False. If the value is True, the pollee is indicating that there are
   fields in this template which are not being exported to the polling
   server, but wishes to treat as a hit. Thus, when the polling server