rfc2167.txt

RFC 的详细文档！

Williamson, et. al.          Informational                      [Page 6]

RFC 2167                    RWhois Protocol                    June 1997


    Primary      This is a true or false flag that indicates that this
                 attribute is a primary key. If more than one attribute
                 in a class is marked as primary, then these attributes
                 together form a single primary key. The primary key is
                 intended to be used to force uniqueness among class
                 instances. Therefore, there can be only one instance of
                 a primary key in a database. The Primary flag implies
                 that the attribute is also required.

    Hierarchical This is a true or false flag that indicates that this
                 attribute is lexically hierarchical.

    Private      This is a true or false flag that indicates whether or
                 not this attribute is private (that is, publicly not
                 viewable).  It defaults to false. If it is true, then
                 only the clients that satisfy the
                 authentication/encryption requirements of a guardian
                 (described below) are able to view the attribute-value
                 pair.

2.3.2 Class

   A class is a collection of attributes; it is a structure, not data.
   The concept is equivalent to that of a relational database table. It
   is also equivalent to the second definition of schema, above.

   A class also has some properties that are sometimes referred to as
   its "meta" information. These properties are listed below.

    Version     This is a time/date stamp that is used to quickly detect
                when a class definition has been changed.

    Description This is a natural language description of the class.

2.3.3 Object

   An object is an instance of a class. It is data with a type of
   <class>.

2.3.4 Base Class

   While RWhois does not have or advocate using a specific, standardized
   schema, it does impose a few requirements. It requires that all
   defined classes inherit attributes from a particular base class (or
   base schema).  The RWhois specification does not require the actual
   implementation of inheritance. Instead, all classes must include the
   attributes defined in the base class.




Williamson, et. al.          Informational                      [Page 7]

RFC 2167                    RWhois Protocol                    June 1997


   The base class has the following attributes.

    Class-Name    This attribute contains the name of the class to which
                  the object belongs. It is the type of the object
                  itself. It is of type TEXT and is required.

    Auth-Area     This attribute contains the name of the authority area
                  to which the object belongs. It, along with Class-
                  Name, definitively defines the type of the object. It
                  is of type TEXT and is required.

    ID            This attribute is a universal identifier for the
                  object. It is formed by choosing a string that is
                  unique within an authority area and appending the
                  authority area to it, separating the local string from
                  the authority area name with a period. The only
                  restrictions on the local string are that it must be
                  unique within the authority area and not contain the
                  period character. This attribute is hierarchical in
                  nature. It is always generated by the server (for
                  example, during a register operation). It is of type
                  TEXT and is required.

    Updated       This attribute is a time/date stamp that indicates the
                  time of last modification of the object. It is both
                  informational and a form of record locking. It
                  prevents two clients from modifying the same object at
                  the same time. It is of type TEXT and is required.

    Guardian      This attribute is a link to a guardian object
                  (described below). Its value is the ID of a guardian
                  object. It is of type ID and is optional. It is
                  repeatable, since an object may have multiple
                  guardians.

    Private      This attribute is a true or false flag that indicates
                  whether or not an object is private (that is, publicly
                  not viewable). It defaults to false. If it is true,
                  then only the clients that satisfy the
                  authentication/encryption requirements of one of the
                  object's guardians are able to view the object. If the
                  object is publicly viewable, then the Private
                  attribute property of each of its attributes still
                  applies.







Williamson, et. al.          Informational                      [Page 8]

RFC 2167                    RWhois Protocol                    June 1997


    TTL           This attribute is the "time-to-live" of a given
                  object. It is included only if an object has a
                  different time-to-live than the default given in the
                  Start of Authority information. Its value is specified
                  in seconds. It is of type TEXT and is optional.

   The RWhois specification defines two standard classes that should be
   included in all implementations: the referral and guardian classes.

2.3.5 Referral Class

   The referral class is defined to hold referral information (typically
   for link referrals). It consists of attributes defined as part of the
   base class, the protocol-specific attributes described below, and any
   installation-specific attributes.

    Referred-Auth-Area This attribute contains the name of the authority
                       area to which the referral points. It is used as
                       a search key during the query routing. It is of
                       type TEXT and is required. It is repeatable,
                       since referrals can point to servers hosting more
                       than one authority area.

    Referral           This attribute contains the referral itself. It
                       is an RWhois URL. It is of type TEXT and is
                       required. It is repeatable, since more than one
                       server can host a Referred-Auth-Area.

2.3.6 Guardian Class

   The guardian class is defined to hold security information. The
   fundamental concept behind the guardian class is that an object (or
   another structure) is "guarded" by containing a pointer to a guardian
   object [Guardian]. To modify, delete, or possibly view the guarded
   object, the authentication (or encryption, or both) scheme must be
   satisfied. Guardians are intended to not have rank: if an object is
   guarded by more than one guardian object, satisfying any one of those
   guardians is sufficient. A guardian object that does not have any
   Guardian attribute linking it to other guardians guards itself. That
   is, the authentication scheme in the guardian object itself must be
   satisfied to modify, delete, or possibly view it.

   Guardian objects are typically linked to actual database objects with
   the Guardian attribute found in the base class. However, a guardian
   may also be linked to an entire authority area, in which case the
   guardian becomes implicitly linked to all of the objects contained
   within the authority area.




Williamson, et. al.          Informational                      [Page 9]

RFC 2167                    RWhois Protocol                    June 1997


   The guardian class consists of the base class, the protocol-specific
   attributes described below, and any installation-specific attributes.

    Guard-Scheme This attribute contains a keyword indicating the
                 authentication methodology. Its value must be
                 understood by both the client and server, and its value
                 dictates the contents of the Guard-Info attribute. It
                 is of type TEXT and is required.

    Guard-Info   This attribute contains that data that is used by the
                 Guard-Scheme to verify the authentication. Its actual
                 format is dictated by the Guard-Scheme, for example, it
                 could contain a password or Pretty Good Privacy (PGP)
                 public key id [RFC 1991]. For security reasons, it
                 should not be displayed, and its Private attribute
                 property should be set to true. It is of type TEXT and
                 is required.

2.4 Authority Areas

   The concept of authority areas is pivotal to the RWhois architecture.
   When an RWhois tree is created for a particular lexically
   hierarchical namespace, the different pieces of the hierarchy are
   mapped to authority areas. The most important concept behind an
   authority area is the ability for a portion of the RWhois tree to
   definitively control that portion of the hierarchy. This means that
   an authority area is able to state whether or not a hierarchical tag
   is in the whole RWhois tree. It does this either by returning the
   object containing this tag, returning a referral to a sub-authority
   area, or returning a response indicating that no objects were found.

   This structure enables efficient routing of queries based on the
   hierarchical label to the piece of the hierarchy responsible for it.
   For example, in the domain name namespace as served by RWhois, the
   root of the tree would be an authority area named ".", which would
   delegate a "us" sub-authority area, which would delegate "va", "co",
   "md", and "ca" authority areas, and so forth. When the server with
   the "va.us" authority area is asked about "loudoun.va.us", it will be
   able to authoritatively state that either no "loudoun.va.us" exists
   or it will provide an object for or a referral to "loudoun.va.us".
   Further, if the server is asked about "howard.md.us", it cannot
   answer authoritatively, so it must provide a referral to its
   hierarchical parent ("us" or the root).

   This use of authority area strongly indicates where data should be
   stored within an RWhois tree. Because RWhois uses a specific query
   routing model, data needs to be placed under the proper authority
   area. It is certainly possible to place a piece of data under the



Williamson, et. al.          Informational                     [Page 10]

RFC 2167                    RWhois Protocol                    June 1997


   wrong authority area, for example, putting an object for
   "howard.md.us" under the "va.us" authority area. In such cases, the
   data is considered to be misplaced and unable to be found within the
   RWhois tree. However, while data should be placed under the lowest
   (most specific) authority area, it is also possible that it could be
   placed in a higher (least specific) authority area, for example,
   putting an object for "loudoun.va.us" under the "us" authority. This
   may be acceptable since, in most cases, the data would be able to be
   found.

   In addition to controlling a part of an RWhois hierarchy, an
   authority area is considered to be autonomous. Each authority area is
   treated as a separate database by the protocol. However, it is
   recommended that an authority area share some core schema with the
   rest of the RWhois tree for interoperability reasons. Each authority
   area, however, is not bound by the database schema of its
   hierarchical parent or by any of its sub-authority areas.

2.5 Query Routing

   RWhois is not only a directory access protocol but it can also route
   queries. Routing a query involves redirecting the query to another
   server that is presumed to be closer to the desired data. To route a
   query, the server first determines the location of the next server.
   It then either forwards the query to that server and returns the
   result to the client or returns the location of that server to the
   client. The location of the server must contain its host name (or IP
   address), port number, and authority area.

   The location of the server to which a query is routed is called a
   referral.  There are two types of referrals: punt and link referrals.
   A punt referral is a pointer to a server that is further up an RWhois
   tree, and a link referral is a pointer to a server that is further
   down the tree. For example, in Figure 1, when the server for the
   "va.us" authority area routes a query up to the server for the "us"
   authority area, it generates a punt referral. Alternatively, when it
   routes a query down to the server for the "loudon.va.us" authority
   area, it generates a link referral.

   Query routing depends on whether or not the search value in a query
   is lexically hierarchical. If the search value is hierarchical, the
   server can generate punt or link referrals using the association of
   authority areas with lexically hierarchical labels. Otherwise, the
   server may send the query to a special index server that gathers the
   indexing information for both hierarchical and non-hierarchical data
   from the directory servers and returns referrals to these servers
   [CIP]. If the server receives one or more referrals from the index
   server, it should return them to the client.



Williamson, et. al.          Informational                     [Page 11]

RFC 2167                    RWhois Protocol                    June 1997


   It is important to note that the server may route a query whether it
   could resolve the query or not. Even if a query has been resolved
   locally, the server may also return referrals to the client by
   sending the query to the index server. For example, if the server for
   the "com" authority area receives the "domain Org-Name=IBM" query, it
   may return all the domain objects for IBM within the "com" authority
   area. In addition, it may also return referrals to the server for the
   "nl" authority area if that server contains domain objects for IBM in
   the Netherlands and has fed the corresponding indexing information to
   the index server. This way the client can get back information for
   both "ibm.com" and "ibm.nl" domains.

2.5.1 Query Routing Rules

   An RWhois server routes a query based on certain rules. The objective
   is to determine the location of a server to which to route the query.
   A query may contain one or more query terms. The query routing rules
   are applied on each query term until a referral is found. The rules
   are listed below.

      * Is the search value in the query term hierarchical? If not, go
        to the next query term.
      * Parse the hierarchical portion of the search value. Is it is
        within one of the authority areas? If not, go to the next query
        term.
      * Does the found authority area have any referral objects
        (instances of the referral class)? If not, return the "230 No
        objects found" error to the client.
      * Is the hierarchical portion of the search value within the
        Referred-Auth-Area attribute of one of the referral objects? If
        it is, return the value of the Referral attribute of the found
        referral object as a link referral to the client.
      * Are the search values of some of the query terms hierarchical
        but not within any of the authority areas? If they are, return a
        punt referral to the client.
      * Are the search values of all the query terms non-hierarchical?
        If they are, send the query to a special index server that
        gathers the indexing information for both hierarchical and non-
        hierarchical data from the directory servers and returns
        referrals to these servers. If the server receives one or more
        referrals from the index server, return them to the client.

   Note that there can be more than one referral returned to the client.
   These referrals may point to servers serving different authority
   areas. The client may follow them in any order.






Williamson, et. al.          Informational                     [Page 12]