📄 rfc2967.txt
字号:
constraints, or system requirements, that must be met. This section
aims to capture the baseline requirement assumptions to be addressed
by the system, and thus lays the groundwork on which the rest of the
proposed system is built.
Functional Specification Overview: Working from the users'
requirements, specific technologies and functionality details are
outlined to architect a system that will meet the stated
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -