rfc2967.txt

中、英文RFC文档大全打包下载完全版 .

   limited set of data attributes -- "Name", "Organizational Role",
   "Organization", and "Locality".  The selected permissible query
   combinations of attributes are listed in Table 3.1.  From the table
   it can be seen that not all combinations of the three attributes are
   supported -- only those that are needed for the desired
   functionality.

   Symbol  Description
   ------- -----------
   N       Name
   NL      Name + Locality
   NO      Name + Organization
   NOL     Name + Organization + Locality
   RO      Role + Organization
   ROL     Role + Organization + Locality

   Table 3.1 DAG-supported queries

   The RO and ROL queries are separated from the rest as they are
   searches for "virtual" persons -- roles within an organization (e.g.,
   president, or customer service desk) for which one might want to find
   contact information.

   Matching Semantics

   As befits the individual client query protocols, more string matching
   expressions may be provided.  The basic semantics of the DAG expect
   the following to be available in all client access software (as
   relevant):






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


   - Full word, exact match
   - Word substring match (E.g., "cat" would match "scatter")
   - Case-sensitive and case-insensitive matching

      TISDAG: LDAP/X.500, supports case-sensitivity as such but some of
      the most used attributes, such as the commonName attribute, are
      defined in the standard to be of the case-insensitive
      attributetypes.  The impact on the DAG system is that even if the
      index collected from a LDAP/X.500 server might have upper and
      lower case letters in the tokens, they can not be handled as such
      since that would be inferring meaning in something which is
      natively regarded as meaningless.  The conclusion of the above is
      that The Referral Index should be case-insensitive and case-
      sensitivity should be supported by the SAPs if the native access
      protocol supports it.

   Character Sets

   Wherever possible, the DAG System supports and promotes the use of
   Unicode Version 2.0 for character sets (see [21]) specifically the
   UTF-8 encoding (see Appendix A.2 of [21] or [20]) Accommodation is
   made, where necessary, to support the deployed base of existing
   software.

   Specifically:

   DAG/IP: All internal communications using the DAG/IP are carried out
   in UTF-8.

      TISDAG: not just UTF-8, but UTF-8 based on composed UNICODE
      version 2 character encodings.

   DAG-CAP input: Where specific access protocols permit selection of
   character sets, DAG-CAPs must support UTF-8.  They may additionally
   support other anticipated character set encodings.

   DAG-SAP communications with WDSPs:  Where specific access protocols
   permit selection of character sets, DAG-SAPs must support UTF-8 and
   use UTF-8 whenever the remote WDSP supports it.  They may
   additionally support other character set encodings.

   CIP Index Objects: The Index Objects supplied by the WDSPs to the DAG
   system shall contain data encoded in UTF-8.

      TISDAG: The same limitation as for DAG/IP, that is the basic data
      should be UTF-8 encoded composed UNICODE version 2 character
      encodings.




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


3.3.2 Data Output Spec

   Schema Definition

   The schema used for the DAG service  is defined in Appendix A.  This
   is a very basic information schema, intended to carry the necessary
   information  for the DAG service, and not more.  Although generic
   "whitepages" schema definitions do exist the more sophisticated and
   detailed the information presentation, the more difficult it is to
   map the schema seamlessly across protocols of different paradigms.
   Thus, the "KISS" ("Keep it simple, sir") principle seems appropriate
   here.

   Individual DAG-CAPs define how they express this schema.

   Referral Definition

   For client access protocols that make use of the concept of
   referrals, DAG-CAP definitions will define the expression of
   referrals in those protocols.  The DAG/IP defines the expression of
   referrals (see Appendix  C).

   Error conditions

   Each DAG-CAP may provide more detailed error messages, but will
   define minimally the support for the following error conditions:

   - unrecognized query
   - too many hits

   Apart from these errors, the DAG-CAP may choose to refuse a query by
   redirecting the end-user to a different DAG-CAP of the same protocol.

3.4 Directory Server Interface

   The DAG will use the Common Indexing Protocol (CIP) server-server
   protocol to obtain updated index objects from WDSPs.  For query-
   routing purposes, WDSPs are expected to  provide Whois++, LDAPv2 or
   LDAPv3 interface to their data (although their preferred access may
   be something completely different).  N.B.:  In the responses from the
   technical survey, all respondents currently provide access to their
   service in one of these protocols.

   In order to provide a useful and uniform service, WDSPs are expected
   to provide 7x24 access to their whitepages information.  WDSPs are
   also expected to implement operations, administration, maintenance,
   and provisioning processes designed to minimize service down time for
   both planned and unplanned administration and maintenance activities.



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


4.0 Architecture

4.1 Software Components

   The conceptual architecture of the DAG is represented in Figure 4.1.
   General architectural specifications are described below, followed by
   individual component specifications Sections 5.5 through 5.12.

4.1.1 Internal Communications

   Communications between components of the DAG  will be by TCP/IP
   connections, using the DAG-Internal Protocol (DAG/IP).  DAG/IP is
   used by DAG-CAPs to communicate with the Referral Index and DAG-SAPs.
   Thus, the DAG/IP defines

   - the DAG-CAPs' range of query ability in the Referral Index (to
     gather referrals in response to the end-user's requests)
   - the responses (and their formats) of the Referral Index to the
     DAG-CAP requests
   - the DAG-CAPs' range of query ability to the DAG-SAPs for pursuing
     referrals when the DAG-CAP needs to do chaining for the client
     access software
   - the responses (and their formats) of the DAG-SAPs to the DAG-CAPs.

   The detail of the planned DAG/IP is given in Appendix C.  The detail
   of the DAG-CAP--Referral Index and DAG-CAP--DAG-SAP interactions  is
   given in the definitions of individual DAG-CAPs and DAG-SAPs, below
   (Sections 5.5 through 5.12).

4.1.2 Referral Index

   The Referral Index is responsible for maintaining the index of WDSP
   information, and providing a list of reasonable referrals in response
   to DAG-CAP search requests.  These "referrals" provide pointers to
   identify WDSPs that may have information that matches the end-user's
   query.

4.1.3 DAG-CAPs

   Individual DAG-CAPs are responsible for providing a particular client
   access protocol interface to the DAG service.  DAG-CAPs receive end-
   user queries in a particular query access protocol, convert the
   request into a query for the Referral Index ( i.e., expressed in
   DAG/IP), and then convert the Referral Index's response into a form
   that is appropriate for the client access protocol.  This may mean
   passing back the referrals directly, calling on DAG-SAPs to do the
   work of translating the referral into results ("chaining"), or a
   combination of both.



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


              +-------------------------------------+
              |+====+                               |
   HTTP   <-->+|    |<------+  (Full chaining)      |
              ||    |       |                       |
              |+====+       |                       |
              |             |                 +----+|
              |             |      Referral-->|    ||
              |             |      Result  <--|    |+<--> Whois++
              |             |                 +----+|
              |+====+       |                       |
   SMTP   <-->+|    |<------+  (Full chaining)      |
              ||    |       |                       |
              |+====+       |                       |
              |             |                 +----+|
              |             |      Referral-->|    ||
              |             |      Result  <--|    |+<--> LDAPv2
              |             |                 +----+|
              |+====+       |                       |
   Whois++<-->+|    |<------+  (Chain LDAPv2/3)     |
              ||    |       |                       |
              |+====+       |                       |
              |             |                 +----+|
              |             |      Referral-->|    ||
              |             |      Result  <--|    |+<--> LDAPv3
              |             |                 +----+|
              |+====+       |                       |
   LDAPv2 <-->+|    |<------+  (Full chaining)      |
              ||    |       |                       |
              |+====+       |                       |
              |             |                       |
              |+====+       |                       |
   LDAPv3 <-->+|    |<------+  (Chain Whois++)      |
              ||    |       |                       |
              |+====+       |                       |
              |             |                       |
              |             v                       |
              |   +-----------------------+         |
              |   |  Referral Index       |<---------------> Common
              |   |                       |         | Indexing Protocol
              |   +-----------------------+         | (CIP)
              +-------------------------------------+

            All internal communications are in DAG/IP.

            Figure 4.1 Conceptual Architecture of the DAG






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


4.1.4 DAG-SAPs

   Individual DAG-SAPs are called upon (by DAG-CAPs) to take DAG-
   generated referrals and pursue them -- issuing the indicated query at
   the specified WDSP service.  Results from individual WDSPs are
   converted back into DAG/IP-specific format for the DAG-CAP that made
   the request.  Each DAG-SAP is responsible for handling referrals to
   WDSPs of a particular protocol (e.g., LDAPv2, Whois++, etc).

4.2 Important Architectural Notes

   This section notes some of the thinking that has driven the
   architectural and software design specification for the DAG system.
   This helps to provide the context in which to understand the software
   specifications that follow, and should give clues for the eventual
   extension of the DAG system.  This section also acts, in some ways,
   as an FAQ (Frequently Asked Questions) section, as the content is
   shaped by questions received during the tech spec development phase.
   It attempts to illuminate context that may not otherwise be apparent
   on a first reading of the software specifications.

4.2.1 2 Distinct Functions:  Referrals and Chaining

   At all times, it must be kept in mind that the primary function of
   the DAG system is to provide users with referrals to WDSP services
   that may have the information they seek.  Since it is the case that
   not all supported client protocols can handle referrals, the DAG
   system also provides a chaining service to pursue referrals that the
   user's client software cannot handle itself.  This chaining service
   does attempt to match the user's query against data from WDSPs, but
   this is to be seen as a secondary, or support function of the DAG
   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