rfc2967.txt

RFC 的详细文档！

   system.  In the perfect future, all access protocols will be able to
   handle all referrals!

4.2.2 Limited Query and Response Semantics

   The DAG system does not attempt to be a chameleon, or the ultimate
   whitepages query service.  It focuses on providing referrals for
   information on the limited number of query types outlined in the
   functional specifications of the DAG service.  This makes the DAG
   system a good place to start a search, but refinements and detailed
   inquiries are beyond its scope.

4.2.3 Visibility

   Given the limited query syntax of the DAG system it will not always
   be possible to exactly match a query posed to a CAP into a query
   posed to a SAP.  This will have the effect that for instance a LDAPv2



Daigle & Hedberg             Informational                     [Page 17]

RFC 2967                         TISDAG                     October 2000


   client that issues a query to the DAG system which by the DAG system
   is chained to a LDAP server might not get the same results as if the
   client where directly connected to the server in question.

4.2.4 Richness of Query semantics

   Even the limited query syntax of the DAG system is capable of
   expressing queries that might NOT be possible to represent in the
   access protocols to the WDSPs.  In these cases the DAG-SAP either can
   refuse the query or try to emulate it.

4.2.5 N+M Protocol Mappings

   As part of the chaining service offered by the DAG system, a certain
   amount of mapping between protocols is required -- in theoretical
   terms, there  are "N" allowable end-user query access protocols, and
   "M" supported WDSP server protocols.  The architecture of the
   software is constructed to use a single internal protocol (the
   DAG/IP) and data schema, providing a common language between all
   components.  Without this, each input protocol module (DAG-CAP) would
   have to be constructed to be able to handle every WDSP protocol --
   NxM protocol mappings.  This would make the system complex, and
   difficult to expand to include new protocols in future.

4.2.6 DAG-CAPs and DAG-SAPs are completely independent of each other

   For the above reasons, the DAG-CAP and DAG-SAP modules are intended
   to be completely independent of each other.  A DAG-SAP responds to a
   query that is posed to it in the DAG/IP, without regard to the
   protocol of the DAG-CAP that passed the query.

4.2.7 The Role of the DAG-CAP

   Thus, the DAG-CAP is responsible for using the DAG/IP to obtain
   referral information and, where necessary, chained responses.  Where
   necessary, it performs adjustments to accommodate the differences in
   semantics between the DAG/IP and its native protocol.  This might
   involved doing post-filtering of the results returned by the DAG-SAPs
   since the query issued in DAG/IP to the DAG-SAP might be "broader"
   then the original query.

   Thus, the DAG-CAP "knows" only 2 protocols:  its native protocol, and
   the DAG/IP.








Daigle & Hedberg             Informational                     [Page 18]

RFC 2967                         TISDAG                     October 2000


4.2.8 The Role of the DAG-SAP

   Similarly, the DAG-SAP is responsible for responding to DAG/IP
   queries by contacting the designated WDSP server.  Where necessary,
   it performs adjustments to accommodate the differences in semantics
   between the DAG/IP and its native protocol.  These adjustments might
   mean that, as a consequence, the DAG-SAP will receive results that do
   not match the original query.  In such cases the DAG-SAP should
   attempt to do post-pruning in order to reduce the mismatch between
   the original query and the results returned.

   Thus, the DAG-SAP "knows" only 2 protocols:  its native protocol, and
   the DAG/IP.

4.2.9 DAG/IP is internal

   No module outside of the DAG system should be aware of the DAG/IP's
   construction.  End-users use the query protocols supported by DAG-
   CAPs; WDSPs are contacted using the query protocols supported in the
   DAG-SAPs.

4.2.10 Expectations

   The expectation is that the DAG system, although defined as a single
   construct, will operate by running modules on several different,
   perhaps widely distributed (in terms of geography and ownership),
   computers.  For this reason, the DAG/IP specified in such a way that
   it will operate on inter-machine communications.

4.2.11 Future Extensions

   The DAG system architecture was constructed with a specific view to
   extensibility.  At any time, an individual component may be improved
   (e.g., the Mail DAG-CAP may be given a different query interface)
   without disrupting the system.

   Additionally, future versions of the DAG system may support other
   access protocols -- for end-users, and for WDSPs.

5.0 Software Specifications

5.1 Notational Convention

   It is always a challenge to accurately represent text protocol in a
   printed document; when is a new line a "newline", and when is it an
   effect of the text formatter?





Daigle & Hedberg             Informational                     [Page 19]

RFC 2967                         TISDAG                     October 2000


   In order to be adequately illustrated, this document includes many
   segments of protocol grammars, sample data, and sample input/output
   in a text protocol.  In order to distinguish newlines that are
   significant in a protocol, the symbol

   <NL>

   is used.  For example,

   This is an example of a very long line of input.  There is only one
   newline in it (at the end), in spite of the fact that this document
   shows it spanning several lines of text.<NL>

5.2 DAG-CAP Basics

5.2.1 Functionality

   Every DAG-CAP must support the full range of DAG queries, as defined
   in 3.3.1.

   Each DAG-CAP accepts queries in its native protocol.  Individual
   DAG-CAP definitions define the expected expression of the DAG queries
   in the native protocol.

   The DAG-CAP is then responsible for:

   - converting that expression into a query in the DAG/IP to obtain
     relevant referrals from the Referral Index.  This might mean that
     parts of the original query are disregarded (e.g., if the query
     included attributes not supported by the DAG application, or if the
     query algebra was not supported by the DAG application);
   - returning referrals in the client's native protocol, where
     possible;
   - expressing the client query to the necessary DAG-SAPs, given the
     limitations mentioned above, to chain those referrals not usefully
     expressible in the client's native protocol;
   - possibly doing post-filtering on the DAG-SAP results; and
   - converting the collected DAG-SAP results for expression in the
     client's native protocol (and schema, where applicable).

   Each DAG-CAP defines the nature of the interaction with the end-user
   (e.g., synchronous or asynchronous, etc).  Additionally, each DAG-CAP
   must be able to carry out the following, in order to permit load-
   limiting and load-balancing in the DAG system:

   - direct the client to a different DAG-CAP of the same type (for
     load-balancing)




Daigle & Hedberg             Informational                     [Page 20]

RFC 2967                         TISDAG                     October 2000


   - decline to return results because too many referrals were generated
     (to discourage data-mining).  Ideally, this should include the
     generation of a message to refine the query in order to produce a
     more manageable number of referrals/replies.

   DAG-CAPs must be capable of accepting and respecting DAG-SAP service
   referrals (for DAG-SAP load-sharing).

   In protocols that permit it, the DAG-CAP should indicate to the end-
   user which services were unavailable for chaining referrals (i.e., to
   indicate there were parts of the search that could not be completed,
   and information might be missing).

      TISDAG: Any CAP that receives commands other than queries, like
      help, answers those on its own.  A CAP should not pass any system
      command on to the RI.

5.2.2 Configuration

   It must be possible to change the expected address of the DAG-CAP by
   configuration of the software (i.e., host and port, e-mail address,
   etc).

   For DAG-CAPs that need to access DAG-SAPs for query chaining, for
   each type (protocol) of DAG-SAP that is needed, the DAG-CAP must be
   configurable in terms of:

   - at least one known DAG-SAP of every necessary protocol to contact
   - for each DAG-SAP, the host and port of the DAG-SAP software

   The DAG-CAPs must also be configurable in terms of a maximum number
   of referrals to handle for a user transaction (i.e., to prevent data
   mining, the DAG-CAP will refuse to reply if the query is too general
   and too many hits are generated at the Referral Index).

   The DAG-CAP must be configurable in terms of alternate DAG-CAPs of
   the same type to which the end-user software may be directed if this
   one is too busy.

5.2.3 Error handling

   Apart from error conditions arising from the operation of the DAG-CAP
   itself, DAG-CAPs are responsible for communicating error conditions
   occurring elsewhere in the system that affect the outcome of the
   user's query (e.g., in the DAG-RI, or in one or more DAG-SAPs).






Daigle & Hedberg             Informational                     [Page 21]

RFC 2967                         TISDAG                     October 2000


   If the DAG-CAP sends a query to the DAG-RI and receives an error
   message, it should attempt to match the the received DAG errorcode
   into its native access protocol's error codes.  The same action is
   appropriate when the DAG-CAP is "chaining" the query to one DAG-SAP.

   There are also occasions when the DAG-CAP may have to combine
   multiple errorcodes into a single expression to the user.  When the
   DAG-CAP is "chaining" the query through DAG-SAPs to one or more
   WDSPs, situations can arise when there is a mix of responsecodes from
   the DAG-SAPs.  If this happens, the DAG-CAP should try to forward
   information to the end-user software that is as specific as possible,
   for instance which of the WDSPs has not been able to fulfill the
   query and why.

   See Appendix D for more information concerning error condition
   message mappings.

5.2.4 Pruning of results

   Since there is no perfect match between the query syntaxes of the DAG
   system on one hand and the different access protocols that the DAG-
   CAPs and DAG-SAPs supports on the other, there will be situations
   where the results a DAG-CAP has to collect is "broader" then what
   would have been the case if there had been a perfect match.  This
   might have adverse effects on the system to the extent that
   administrative limits will "unnecessary" be exceeded on WDSPs or that
   the collected results exceeds the sizelimit of the DAG-CAP.

   Since the DAG-CAP is the only part of the DAG system that actually
   knows what the original query was, the DAG-CAP can prune the results
   received from the DAG-SAPs in such a way that the results presented
   to the client better matches the original question.

5.3 DAG-SAP Basics

5.3.1 Functionality

   Every DAG-SAP must support the full range of DAG queries, as defined
   in 3.3.1.  Results must be complete DAG schemas expressed in well-
   formed DAG/IP result formats (see Appendix C).  Each DAG-SAP accepts
   queries in DAG/IP and converts them to the native schema and protocol
   for which it is designed to proxy.

   The DAG-SAP is then responsible for

   - converting the query into the native schema and protocol of the
     WDSP to which the referral points.  (If the query is not
     representable in the native protocol, it must return an error



Daigle & Hedberg             Informational                     [Page 22]

RFC 2967                         TISDAG                     October 2000


     message.  If it is emulatable, the DAG-SAP can attempt emulate it
     by posing a related query to the WDSP and post-pruning the results
     received);
   - contacting that WDSP, using the host, port, and protocol
     information provided in the referral;
   - negotiating the query with the remote WDSP;