rfc2967.txt

RFC 的详细文档！

   - accepting results from the WDSP, possibly doing post-filtering on
     the result set; and
   - conveying the results back to the calling DAG-CAP using the DAG/IP
     and its schema.

   Note that this implicitly means that the DAG-SAP is responsible for
   chaining and pursuing any referrals it receives from WDSP services.
   The DAG-SAP returns only search results to the DAG-CAP that called
   it.

5.3.2 Configuration

   DAG-SAPs must be configurable to accept connections only from
   recognized DAG components.

   DAG-SAPs that have service limits must be configurable to redirect
   DAG-CAPs to alternate DAG-SAPs of the same type when necessary.

5.3.3 Error handling

   A DAG-SAP must translate error codes received from a WDSP server to
   DAG error codes according to Appendix D.

5.3.4 Pruning of results

   Since it might not be possible to exactly map a DAG query into a
   query in the access protocol supported by the a DAG-SAP, the DAG-SAP
   should try to translate it into a more general query (or if necessary
   into a set of queries).  If so, the DAG-SAP must then prune the
   result set received before furthering it to the DAG-CAP.

5.3.5 Constraint precedence

   Some constraints, search and case, can appear both as local and
   global constraints.  If this happens in a query then the local
   constraint specification overrides the global.  For a query like the
   following:

   fn=leslie;search=exact and org=think:search=substring

   the resulting search constraint for "fn=leslie" will be "exact" while
   it for "org=think" will be "substring".



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


5.4 The Referral Index

5.4.1 Architecture

   The Referral Index contains (only) information necessary to deliver
   referrals to DAG-CAPs based on the query types supported by the DAG
   itself.  The Referral Index creates an index over these objects so
   that it can respond to DAG-CAP queries using the DAG/IP.  The
   information is drawn directly from interactions with participating
   WDSPs' software, using the Common Indexing Protocol (CIP).

5.4.2 Interactions with WDSPs (CIP)

   WDSPs that wish to participate in the DAG system must register
   themselves (see Section 5.4.6).  Once registered, the Referral Index
   will interact with the WDSPs using the Common Indexing Protocol as
   defined in [1], using the Index Object defined in Section 5.4.3.

5.4.3 Index Object Format

   The CIP index object type is based on the Tagged Index Object as
   defined in [12].  Appendix E details the expected content of the
   index objects as they are to be provided by the WDSPs.

      TISDAG: The tokens in the Tagged Index Object should be UTF-8
      encoded composed UNICODE version 2 character encoding.

5.4.4 DAG-Internal I/O

   The Referral Index interacts with the rest of the DAG internal
   modules (DAG-CAPs) by listening for queries and responding in the
   DAG/IP (defined in Appendix C).

5.4.5 The Index Server

   The Referral Index must index the necessary attributes of the CIP
   index object in order to respond to queries of the form described in
   Table 3.1.

   The semantics of the chosen CIP object (defined in Appendix E) are
   such that a referral to a WDSP server is sent back if (and only if)

   - the index object of the WDSP contains all the tokens of the query,
     in the attributes specified, according to the logic of the DAG/IP
     query, and
   - all of those tokens are found with a common tag.





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


   This means that a query for the name "Fred Flintstone" (2 tokens)
   will yield a referral to a server that has a record for "Fred Amadeus
   Flintstone", but not to a WDSP with 2 differently tagged records, for
   "Fred Amadeus" and "Julie Flintstone".  Depending on the access
   protocol being used and the original end-user query, the referral to
   the WDSP with "Fred Amadeus Flintstone" may yield a successful
   result, or it may not.  But, it is known that the other WDSP would
   not have yielded successful searches.  That is, the referral approach
   may yield false-positive results, but will not miss appropriate
   WDSPs.

5.4.6 Configuration

   The Referral Index must provide the ability to register interested
   WDSPs, as outlined in Appendix E.

   The Referral Index must be able to configure the port for DAG/IP
   communications.  Also, it must be configurable to recognize only
   registered DAG-CAPs.

5.4.7 Security

   The Referral Index will accept queries only from recognized
   (registered) DAG-CAPs.  This will reduce "denial of service" attack
   types, but is also a reflection on the fact that the Referral Index
   uses the DAG/IP, (i.e., internal) protocol, which should not be
   exposed to non-DAG software.

   The Referral Index must be able to use authenticated communication to
   receive data from WDSPs (see Appendix E).

5.5 Mail (SMTP) DAG-CAP

   This is the default Mail DAG-CAP.  More sophisticated ones could
   certainly be written -- e.g., for pretty-printed output, or for
   handling different philosophies of case-matching.

   This DAG-CAP has been designed on the assumption that mail queries
   will be human-generated (i.e., using a mail program/text editor), as
   opposed to being queries formulated by software agents.  The input
   grammar should therefore be simple and liberal in acceptance of
   variations of whitespace formatting.









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


5.5.1 Mail DAG-CAP Input

   Mail DAG-CAP input is expected to be a regular or MIME-encoded (see
   [9] and [10]) SMTP mail message, sent to an advertised mail address.
   The mail DAG-CAP parses the message and replies to it with a MIME-
   encoded message containing the results of the DAG search.

   One query is accepted per e-mail message -- text after a single valid
   query has been read is simply ignored.

   The body of the query message must follow the syntax defined below.
   Note that all input control terms ("type=", "name=" etc) are shown in
   lower case for convenience, but could be upper case or mixed case on
   input.

   mailquery       = [mnl] [controls] mnl terms mnl
   controls        = [msp] "searchtype" [msp] "=" [msp]
                        ( matchtype /
                          casetype /
                          matchtype msp casetype /
                          casetype msp matchtype /
                          <nothing> )
   matchtype       = "substring" / "exact"
                  ; default:  substring
   casetype        = "ignore" / "sensitive"
                  ; default:  ignore

   terms           = n / n-l / n-o / n-o-l / r-o / r-o-l

   n               = n-term
   n-l             = ( n-term l-term  / l-term n-term)
   n-o             = ( n-term o-term  / o-term n-term )
   n-o-l           = ( n-term o-term l-term /
                    n-term l-term o-term /
                    l-term n-term o-term /
                    l-term o-term n-term /
                    o-term l-term n-term /
                    o-term n-term l-term )
   r-o             = ( r-term o-term / o-term r-term )
   r-o-l           = ( r-term o-term l-term /
                    r-term l-term o-term /

                    l-term o-term r-term /
                    l-term r-term o-term /
                    o-term l-term r-term /
                    o-term r-term l-term )
   n-term          = [msp] "name" [msp] "=" [msp] string mnl
   o-term          = [msp] "org" [msp] "=" [msp] string mnl



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


   l-term          = [msp] "loc" [msp] "=" [msp] string mnl
   r-term          = [msp] "role" [msp] "=" [msp] string mnl

   string          = <US-ASCII or quoted-printable encoded
                   ISO-8859-1 or UTF-8 except nl and sp>
   msp             = 1*(sp)
    sp              = " "
   mnl             = 1*(nl)

   nl              = <linebreak>

   The following are valid mail queries:

   Example 1:

   searchtype =   <NL>
   name = thinking cat<NL>

   Example 2:

   searchtype = exact ignore<NL>
   name=thinking cat<NL>

   Example 3:

   role=thinking cat<NL>
   org =space colonization<NL>

   Example 4:

   name=thinking cat <NL>
   <NL>
   <NL>
   My signature line follows here in the most annoying
   fashion <NL>

   Note that the following are not acceptable queries:

   Example 5:

   searchtype= exact substring <NL>
   name = thinking cat <NL>

   Example 6:

   name=thinking cat org= freedom fighters anonymous<NL>





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


   In Example 5, two conflicting searchtypes are given.  In Example 6,
   no linebreak follows the n-term.

5.5.2 Translation from Mail query to DAG/IP

   Querying the Referral Index

   A key element of translating from the Mail DAG-CAP input into the
   DAG/IP query format is to "tokenize" the input terms into single
   token elements for the DAG/IP query.  For example,  the n-term

   name= thinking cat<NL>

   is tokenized into 2 n-tokens:

   thinking
   cat

   which are then mapped into the following in the DAG/IP query (dag-n-
   terms):

   FN=thinking and FN=cat<NL>

   The same is true for all r-terms, l-terms and o-terms.  The primary
   steps in translating the mail input into a DAG/IP query are:

   translate quoted-printable encoding, if necessary
   translate base64 encoding, if necessary
   tokenize the strings for each term
   construct the DAG/IP query from the resulting components, as
   described in more detail below

   DAG/IP constraints are constructed from the searchtype information in
   the query.

   dag-matchtype = "search=" <matchtype> /