rfc2967.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   requirements.  This includes a conceptual architecture for the
   system.  While the Requirements section outlines the needs the
   different users have for the eventual DAG system,  implementing and
   providing the eventual service will entail constraints or conditions
   that need to be met in order to be able to participate in the overall
   system.

   Architecture: Once the system has been defined conceptually, a
   proposed software architecture is specified to produce the desired
   functionality and meet the stated requirements.

   Software Specifications: This section provides the specifications for
   software components to meet the architecture described above.





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


   Service Specifications: Once the software has been designed, the
   success of the DAG system will rest on its operational
   characteristics.  Details of service requirements are given in this
   section.

1.4 Terminology

   DAG-CAP: Client Access Point -- point of communication between
   client-access software and the DAG system.

   DAG-System: The Directory Access Gateway system resulting from the
   TISDAG  project.  A collection of infrastructural software and
   services for the purpose of providing unified access to Swedish
   whitepages information.

   DAG/IP: DAG-Internal Protocol -- communication protocol used between
   software components of the DAG.

   End-User: People performing White Pages searches and look-ups (via
   various forms of client software).

   DAG-SAP:  Service Access Point -- point of communication between the
   DAG and WDSP software.

   WDSP: Whitepages Directory Service Provider -- ISPs, companies, or
   other interested entities.

   Whitepages Information: Collected information coordinates for
   individual people.  This typically includes (but is not limited to) a
   person's name, and e-mail address.

2.0 Requirements

   There are 2 primary classes of users for the proposed Whitepages
   directory access gateway:

   - End-users
   - WDSPs

   As outlined below, needs of each of these user classes imposes a set
   of constraints on the design of the DAG system itself.  Some of the
   requirements shown below are assumed starting criteria for the DAG
   service; others have been derived from data collected in the
   Technical Survey or other expertise input.







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


2.1 End-User Requirements

   The End-User is to be provided with a specific set of search types:

   Name
   Name + Organization
   Role + Organization
   Name + Locality
   Name + Organization + Locality
   Role + Organization + Locality

   The search results will, if available, include the following
   information for each "hit":

   - Full name
   - E-mail address
   - Role
   - Organization
   - Locality
   - Full address
   - Telephone numbers

   Access to the service must be available through reasonable and
   current protocols -- such that directory-service-aware software can
   make use of it seamlessly, and there are no reasonable technological
   impediments to making this service useful to all Swedish Internet
   users.

   Following on that, its responses are expected to be timely; a
   standard search should not take more time than the average access to
   a web-server.

2.2 WDSPs Requirements

   Given that the WDSPs that participate in this service are already in
   the business of providing a service of whitepages information, they
   have certain requirements that must be respected in order to make
   this a successful and useful service to all concerned.

   The DAG system must provide reasonable assurances of data integrity
   for WDSPs; the information the End-User sees should correspond
   directly to that provided by the WDSPs.  The DAG system should be
   non-preferential in providing whitepages information -- the service
   is to the End-User, and the source of whitepages information should
   not influence the search and information presentation processes.






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


   The DAG system must be able to reflect information updates within a
   reasonable time after receipt from WDSPs; on the flip side, while the
   DAG system will function best with regular updates from WDSPs, the
   update and participation overhead for WDSPs should be held within
   reasonable bounds of what the WDSP should do to support regular
   access to its information.

   Furthermore, given that WDSPs provide directory service information
   with an eye to value-added service, wherever possible End-Users
   should be redirected to the WDSP responsible for individual directory
   service entries for final and further information.

2.3 DAG-System Requirements

   In order to address the requirements of End-Users and WDSPs, the DAG
   system itself has certain design constraints that must be taken into
   account.

   The system must be implementable/operational by Dec 31/98 -- which
   implies that it must be designed and constructed with already extant
   technologies.

   The System will have certain requirements for participation -- e.g.,
   7x24 WDSP availability.

   In terms of scaling, the system should be able to handle 8M records
   at the outset, with a view to handling larger information systems in
   the future.

   The system must also be capable of extension to other, related
   applications (e.g., serving security certificate information).

3.0 Functional Specification

   In the TISDAG pilotservice we have decided to apply some limitations
   as to what is specified for the DAG/IP.  These limitations are
   presented in this text in the following manner:

      TISDAG: This is a TISDAG comment

3.1 Overview

   The conceptual environment of the DAG system can be described in
   three major components:

   - client access software for end-users
   - the DAG system core
   - WDSP directory service software



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


   This is illustrated in Figure 3.1

   The DAG (Directory Access Gateway) is the infrastructural core of the
   service; it maintains the necessary data and transformation
   facilities to permit the smooth connection of diverse directory
   service Client Software to the existing WDSPs' directory servers.
   The key challenges in designing this portion of the system are:

   Quantity of data -- the quantity of whitepages information that will
   be made available, and diversity of its sources (different WDSPs)
   introduce challenges in terms of finding a structure that will allow
   efficient searching, and facilitate the timeliness of updating the
   necessary information.

   Multiplicity of access protocols -- in order to support the use of
   existing whitepages-aware software with a minimum of perturbation,
   the DAG system will have to present a uniform face in several
   different access protocols, each with its own information search and
   representation paradigm.

   This specification will outline the following areas:

   - the functioning of the DAG core itself
   - the interface between the DAG core and End-Users' Directory Service
     Access software
   - the interface between the DAG core and Directory Services Servers

3.2 The DAG Core

   In order to reduce the quantity of data the DAG itself must maintain,
   and to keep the maintenance of the whitepages information as close as
   possible to the source of information (the WDSPs themselves), the DAG
   will only maintain index information and will use "query routing" to
   efficiently refer End-User queries to WDSPs for search refinement and
   retrieval of information.  Although originally developed for the
   Whois++ protocol, query routing is being pursued in a protocol-
   independent fashion in the IETF's FIND WG, so the choice of this
   approach does not limit the selection and support of whitepages
   access protocols.

   The DAG will look after pursuing queries for access protocols that do
   not support referral mechanisms.  In order to achieve the support of
   multiple access protocols and differing data paradigms, the DAG will
   be geared to specifically support a limited set of whitepages
   queries.






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


                                          +---------+      @
                                 +      ->|         |     -+-
                                /|Protocol|         |      |
                               / |    /   +---------+     / \
                              /  | "B"
                             +   |  /
                             |   |<-
         +-------+           |   |
    O    |       |           |   |
   -+-   |       |<--------->|   |
    |    |       | Protocol  |   |
   / \   |       |  "A"      |   |<-
         +-------+           |   |Protocol
                             |   |   \
                             +   |   "A"  +---------+      @
                              \  |     \  |         |     -+-
                               \ |      ->|         |      |
                                \|        +---------+     / \
                                 +

                             The
   End      Client           DAG           Directory   Directory
   Users    Software         System        Server      Service
                             Core          Software    Providers

           Figure 3.1 The role of the DAG system

3.3 Client Interface

   The DAG will respond to End-User queries in

   - e-mail (SMTP)
   - WWW (HTTP)
   - LDAPv2
   - Whois++
   - LDAPv3

   The DAG will provide responses including the agreed-upon data.  For
   access protocols that can handle referrals, responses will be data
   and/or referrals in that query protocol.  These are Whois++ and
   LDAPv3.  N.B.: the LDAPv3 proposal defines a referral as a URL; no
   limitation is placed on the access protocol.  However it cannot be
   assumed that all clients will be able to handle all access protocols,
   so only referrals to LDAPv3 servers will be returned.







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


3.3.1 Acceptable User Input

   User Input is defined in terms of

   - Searchable Attributes
   - Matching semantics
   - Character sets

   These, in conjunction with the DAG schema, defined in Appendix A,
   form the basis of the required query expression.  Individual queries
   are discussed in more detail in the Client Access Point (DAG-CAP)
   component descriptions for supported protocols.

   Supported Query Types

   The DAG system is designed to support fragment-matching queries on a