rfc2968.txt

RFC 的详细文档！

                           +-------->|CAP:Prot1|       |
                                     |---------+       |     +-------+
                                     |    +-------+    |     |B-WDSP2|
                                     |    | RI-B  |    |     | Prot3 |
                                     +-----------------+     +-------+
                                                              [...]

   where
      Prot[i] is some particular query protocol
      RI-A has an index over all A-WDSP[i] and RI-B
      RI-B has an index over all B-WDSP[i]
      (1) is the query to the Country A DAG system, which
          yields a referral based on the index object from RI-B
      (2) is that referral
      (3) is the resolution of that referral, which the client takes
          to the Country B DAG system directly, but to a CAP that
          is specifically designed to accommodate protocols from
          Country A's service, and map it (and schema) into Country
          B's service.  Likely, all Country B referrals will be
          chained for the Country A client







Daigle & Eklof               Informational                      [Page 5]

RFC 2968              Mesh of Multiple DAG servers          October 2000


   Case 3:

   The third possibility is, in fact, a refinement of the first.  If
   Country A and Country B are running services that are every way
   identical except for the data (WDSPs covered), then it may make sense
   to NOT aggregate Country B's WDSP index objects, but to copy them to
   Country A's server.  Then, Country A's CAPs might be given access to
   the SAPs of Country B in order to carry out chaining directly at the
   remote service (instead of implicating Country A's SAPs and Country
   B's CAPs, as in the first example above).  The answer does not come
   from technology -- it depends entirely on the nature of the
   relationship that can be established between Country A and Country
   B's services.

1.1.2  Scenario 2:  Working Up

   The above scenario implicitly assumes that Country A's server had
   received index objects from Country B's server.  This will be the
   case if Country A's server is higher in the levels of a hierarchy of
   services (established by agreements between the service operators),
   or if the network is comprised of servers that share their index
   objects with all others, for example.  In the latter case, searching
   at any one of the servers in the service yields the full range of
   results -- referrals will be made to any other server that might have
   data that fulfills the user's query.  The sharing of the index
   objects is a mechanism to allow each server to manage local data,
   while enabling distributed load-sharing on the basic query handling.

   However, if a hierarchical, or at least not-completely-connected
   model is used for the server network, queries carried out at a level
   other than the top of the hierarchy, or in one particular branch of
   the hierarchy, will not actually be matched against all index
   objects.  Therefore, there may be other servers to which the query
   should be directed if the full space needs to be searched. Suppose,
   for example, that in the above example Country B is in fact lower in
   the hierarchy than Country A.  A user sending a query to Country B's
   service may be content to limit the scope of the query to that
   country's information (this is true in enough real-life situations
   that this hierarchical relationship becomes an effective mechanism
   for scoping queries and avoiding having to flood the entire network
   with every single query or keep full copies of all data in every
   server).

   Still in theoretical stages, the DAG/IP provides control constructs
   to allow DAG components to act according to the topology of the mesh.
   A CAP might use the "polled-by" system command to establish what
   other servers in the mesh exist in higher levels (and therefore would
   be worth contacting if the scope of the search is to be increased).



Daigle & Eklof               Informational                      [Page 6]

RFC 2968              Mesh of Multiple DAG servers          October 2000


   In the example above, a CAP in Country B's system could determine
   that Country A's service was polling Country B, and therefore make it
   a logical target for expanding the scope of the query.  More
   experience (primarily with server mesh topologies) is necessary
   before it will be clear how to best make use of these capabilities:

       .  should the CAP always broaden the scope? only if there are no
          local referrals? under user direction?
       .  should the CAP use a local SAP to contact the remote service's
          CAP?
       .  is it better to completely connect the mesh of servers, or
          produce some kind of hierarchy?
       .  etc

2. Other considerations

   Depending on the context in which a mesh is established (e.g.,
   between national white pages services, or different units of a
   corporate organization, etc), it may be useful to allow individual
   WDSPs to indicate whether they are willing to have their data
   included in a DAG system's aggregated index object (i.e., allowing
   the DAG system to receive referrals from other systems in the mesh).

3. Security Considerations

   This document describes different configurations for sharing
   information between information services.  It introduces no security
   considerations beyond those attendant in (and addressed by)
   particular directory service access protocols.

4. Acknowledgements

   The work described in this document was carried out as part of an on-
   going project of Ericsson.  For further information regarding that
   project, contact:

      Bjorn Larsson
      [e-mail]













Daigle & Eklof               Informational                      [Page 7]

RFC 2968              Mesh of Multiple DAG servers          October 2000


5. Authors' Addresses

   Leslie L. Daigle
   Thinking Cat Enterprises

   EMail:  [e-mail]


   Thommy Eklof
   Hotsip AB

   EMail: [e-mail]

6. References

   Request For Comments (RFC) and Internet Draft documents are available
   from numerous mirror sites.

   [CIP1]   Allen, J. and M. Mealling, "The Architecture of the Common
            Indexing Protocol (CIP)", RFC 2651, August 1999.

   [TISDAG] Daigle, L. and R. Hedberg "Technical Infrastructure for
            Swedish Directory Access Gateways (TISDAG)," RFC 2967,
            October 2000.

   [DAGEXP] Eklof, T. and L. Daigle, "Wide Area Directory Deployment
            Experiences", RFC 2969, October 2000.

   [NDD]    Hedberg, R. and H. Alvestrand, "Technical Specification, The
            Norwegian Directory of Directories (NDD)", Work in Progress.





















Daigle & Eklof               Informational                      [Page 8]

RFC 2968              Mesh of Multiple DAG servers          October 2000


7. Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Daigle & Eklof               Informational                      [Page 9]