Network Working Group L. Daigle
Request for Comments: 2970 T. Eklof
Category: Informational October 2000
Network Working Group L. Daigle
Request for Comments: 2970 T. Eklof
Category: Informational October 2000
Architecture for Integrated Directory Services - Result from TISDAG
集成目录服务的体系结构-来自TISDAG的结果
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
A single, unified, global whitepages directory service remains elusive. Nonetheless, there is increasing call for participation of widely-dispersed directory servers (i.e., across multiple organizations) in large-scale directory services. These services range from national whitepages services, to multi-national indexes of WWW resources, and beyond. Drawing from experiences with the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) ([TISDAG]) project, this document outlines an approach to providing the necessary infrastructure for integrating such widely-scattered servers into a single service, rather than attempting to mandate a single protocol and schema set for all participating servers to use.
单一、统一、全局的whitepages目录服务仍然难以实现。尽管如此，越来越多的人呼吁广泛分布的目录服务器（即跨多个组织）参与大规模目录服务。这些服务范围从全国性的白页服务，到WWW资源的多国索引，等等。根据TISDAG（瑞典目录访问网关技术基础设施）（[TISDAG]）项目的经验，本文件概述了一种提供必要基础设施的方法，以将这些广泛分散的服务器集成到单一服务中，而不是试图强制所有参与服务器使用单个协议和模式集。
The TISDAG project addressed the issue of providing centralized access to distributed information for whitepages information on a national scale. The specification of the eventual system is presented in [TISDAG], and [DAGEXP] outlines some of the practical experience already gained in implementing a system of this scale and nature. [DAG-Mesh] considers the issues and possibilities of networking multiple DAG services. Following on from those, this document attempts to describe some of the architectural underpinnings of the system, and propose directions in which the approach can be generalized, within the bounds of applicability.
TISDAG项目解决了在全国范围内为白页信息提供分布式信息集中访问的问题。[TISDAG]中介绍了最终系统的规范，[DAGESP]概述了在实施这种规模和性质的系统时已经获得的一些实践经验。[DAG Mesh]考虑将多个DAG服务联网的问题和可能性。在此基础上，本文件试图描述系统的一些架构基础，并在适用范围内提出该方法可以推广的方向。
The proposed architecture inserts a coordinated set of modules between the client access software and participating servers. While the client software interacts with the service at a single entry point, the remaining modules are called upon (behind the scenes) to provide the necessary application support. This may come in the form of modules that provide query proxying, schema translation, lookups, referrals, security infrastructure, etc.
建议的体系结构在客户端访问软件和参与服务器之间插入一组协调的模块。当客户端软件在单个入口点与服务交互时，其余模块（在后台）被调用以提供必要的应用程序支持。这可能以模块的形式出现，这些模块提供查询代理、模式转换、查找、引用、安全基础设施等。
Part of this architecture is an "internal protocol" -- called the "DAG/IP" in the TISDAG project. This document also outlines the perceived requirements for this protocol in the extended DAG.
该体系结构的一部分是“内部协议”——在TISDAG项目中称为“DAG/IP”。本文件还概述了扩展DAG中对本协议的感知要求。
Terms used in this document are compliant with those set out in [ALVE]. For the purposes of this document, important distinctions and relationships are defined between applications, services, servers and systems. These are defined as follows:
本文件中使用的术语符合[ALVE]中规定的术语。在本文档中，定义了应用程序、服务、服务器和系统之间的重要区别和关系。这些定义如下：
Application: this is meant in the general sense, as a solution to a particular (set of) user need(s). That is, the definition is not tied to a particular piece of software (as in "application program").
应用：这是指在一般意义上，作为解决特定（一组）用户需求的解决方案。也就是说，定义与特定的软件不相关（如“应用程序”）。
The definition of an application includes the type(s) of information to be exchanged, expected behavior, etc. Thus, a whitepages (search) application may expect to receive a name as input to a query engine, and will return all information associated with the name. By contrast, a specific security application might use the same input name to verify access controls.
应用程序的定义包括要交换的信息类型、预期行为等。因此，whitepages（搜索）应用程序可能期望接收名称作为查询引擎的输入，并将返回与该名称相关的所有信息。相反，特定的安全应用程序可能使用相同的输入名称来验证访问控制。
Service: an operational system providing (controlled) access to fulfill a particular application's needs.
服务：提供（受控）访问以满足特定应用程序需求的操作系统。
One service may be changed by configuring location, access controls, etc. Changing application means changing the service.
可以通过配置位置、访问控制等来更改一项服务。更改应用程序意味着更改服务。
Server: a single component offering access through a dedicated protocol, without regard to a specific service (or services) it may be supporting in a given configuration. Typically programmed for a particular application.
服务器：通过专用协议提供访问的单个组件，不考虑它在给定配置中可能支持的特定服务。通常为特定应用编程。
System: a set of components with established interconnections.
系统：具有既定互连的一组组件。
Thus, a service can be split between several servers. A collection of services (independently, or interrelated through specified agreements) act as an implementation of an application. A system is composed of one or more servers and services.
因此，可以在多个服务器之间拆分服务。服务的集合（独立的或通过指定的协议相互关联的）充当应用程序的实现。系统由一个或多个服务器和服务组成。
A "system architecture" identifies specific software components, their behavior, communication channels and messages needed to fulfill a particular service's needs. The TISDAG specification [TISDAG] includes just such a description, defining a software system that will meet the needs of a national whitepages directory service. Here, we outline some of the general principles which lead to that specific system architecture and discuss ways in which the principles can be applied in other contexts.
“系统架构”确定了满足特定服务需求所需的特定软件组件、它们的行为、通信通道和消息。TISDAG规范[TISDAG]包括这样一个描述，定义了一个软件系统，该系统将满足国家白页目录服务的需求。这里，我们概述了导致特定系统架构的一些一般原则，并讨论了这些原则在其他环境中的应用方式。
Looking at this bigger picture, we present a "service architecture", or a framework for assembling components into systems that meet the needs of a wider variety of services. This is not a question of developing one or more new protocols for services, but rather to examine a useful framework of interoperating components. The goal is to reduce the overall number of (specialized) protocols that are developed requiring incorporation of some very general concepts that are common to all protocols.
从更大的角度来看，我们提出了一个“服务体系结构”，或一个框架，用于将组件组装到满足更广泛服务需求的系统中。这不是为服务开发一个或多个新协议的问题，而是检查互操作组件的有用框架。目标是减少（专门的）协议的总体数量，这些协议需要合并所有协议共有的一些非常通用的概念。
The Swedish TISDAG project (described in detail in [TISDAG], with some experiences reported in [DAGEXP]) was designed to fulfill the requirements of a particular national directory service. The experience of developing component-based system for providing a directory service through a uniform interface (client access point) provided valuable insight into the possibilities of extending the system architecture so that services with different base requirements can benefit from many of the same advantages.
瑞典TISDAG项目（在[TISDAG]中详细描述，在[DAGEP]中报告了一些经验）旨在满足特定国家目录服务的要求。开发基于组件的系统以通过统一接口（客户端访问点）提供目录服务的经验为扩展系统体系结构的可能性提供了宝贵的见解，从而使具有不同基本需求的服务可以从许多相同的优势中受益。
In retrospect, we can describe the TISDAG system architecture in terms of 3 key requirements and 4 basic design principles:
回顾过去，我们可以从3个关键需求和4个基本设计原则来描述TISDAG系统架构：
R1. The service had to function with (several) existing client and server software for the white pages application.
R1。该服务必须与白页应用程序的（多个）现有客户端和服务器软件一起运行。
R2. It had to be possible to extend the service to accommodate new client and server protocols if and when they became relevant.
R2。如果新的客户端和服务器协议变得相关，则必须能够扩展服务以适应新的客户端和服务器协议。
R3. The service had to be easily reconfigurable -- to accommodate more machines (load-sharing), etc.
R3。服务必须易于重新配置——以适应更多的机器（负载共享）等。
D1. As a design principle, it was important to consider the possibility that queries and information templates (schema) other than the originally-defined set might eventually be supported.
D1。作为一种设计原则，重要的是考虑可能最终支持除原始定义的集合之外的查询和信息模板（schema）的可能性。
D2. As the architecture was already modular and geared towards extensibility, it seemed important to keep in mind that the same (or a similar) system could be applied to other (non-white pages) applications.
D2。由于该体系结构已经是模块化的，并且面向可扩展性，因此必须记住，相同（或类似）的系统可以应用于其他（非白页）应用程序。
D3. There is an "inside" and an "outside" to the service -- distinguishing between components that are accessible to the world at large and those that are open only to other components of the system.
D3。服务有一个“内部”和一个“外部”——区分对整个世界可访问的组件和只对系统其他组件开放的组件。
D4. Internally, there is a single protocol framework for all communications -- this facilitates service support functions (e.g., security of transmission), ensures distributability, and provides the base mechanism for allowing/ascertaining interoperability of components.
D4。在内部，所有通信都有一个单一的协议框架——这有助于服务支持功能（例如，传输的安全性），确保可分发性，并提供允许/确定组件互操作性的基本机制。
The resulting system architecture featured modular component (types) to fulfill a small number of functional roles, interconnected by a generic query-response language. The functional roles were defined as:
由此产生的系统架构以模块化组件（类型）为特色，以实现少量功能角色，并通过通用查询响应语言进行互连。职能角色定义为：
CAPs -- "client access points" -- responsible for accepting and responding to incoming requests through programmed and configured behavior -- to translate the incoming query into some set of DAG-internal actions (queries) and dealing with the responses, filtering and recombining them in such a way as to fulfill the client request within the scope of the service. In the TISDAG system, all CAPs are responsible for handling whitepages queries, but the CAPs are distinguished by the application protocol in which they will receive queries (e.g., LDAPv2, LDAPv3, HTTP, etc). To the client software, the TISDAG system appears as a server of that particular protocol. In the more general case, CAPs may be configured to handle different aspects of a service (e.g., authenticated vs. non-authenticated access). While the TISDAG CAPs all had a simple control structure, the more general case would also see CAPs drawing on different subsets of DAG (internal) servers in order to handle different query types. (See the "Operator Service" example, in section 5.2 below).
CAPs--“客户端访问点”--负责通过编程和配置的行为接受和响应传入请求--将传入查询转换为一组DAG内部操作（查询）并处理响应，过滤和重新组合它们，以便在服务范围内满足客户机请求。在TISDAG系统中，所有CAP都负责处理白页查询，但CAP通过接收查询的应用程序协议（如LDAPv2、LDAPv3、HTTP等）进行区分。对于客户端软件，TISDAG系统显示为该特定协议的服务器。在更一般的情况下，可以将cap配置为处理服务的不同方面（例如，认证访问与非认证访问）。虽然TISDAG CAPs都有一个简单的控制结构，但更一般的情况是，CAPs在DAG（内部）服务器的不同子集上绘制，以便处理不同的查询类型。（参见下文第5.2节中的“操作员服务”示例）。
SAPs -- "service access points" -- responsible for proxying DAG-internal queries to specified services. These are resources drawn upon by other components within the system. Through programmed and configured behavior, they translate queries in the internal protocol into actions against (typically external) servers, taking care of any necessary overhead or differences in interaction style, and converting the responses back into the internal protocol. In the TISDAG system, all SAPs are responsible for handling whitepages queries, but they are distinguished by the
SAPs--“服务访问点”--负责将DAG内部查询代理到指定的服务。这些资源由系统内的其他组件使用。通过编程和配置的行为，它们将内部协议中的查询转换为针对（通常是外部）服务器的操作，处理任何必要的开销或交互方式的差异，并将响应转换回内部协议。在TISDAG系统中，所有SAP都负责处理白页查询，但它们的区别在于
application protocol in which they will access remote services. Further distinctions could be made based on the (remote service's) schema mappings they handle, and other service differentiators.
他们将在其中访问远程服务的应用程序协议。可以根据它们所处理的（远程服务的）模式映射和其他服务差异来进一步区分。
Internal Servers respond to queries in the internal protocol and provide specific types of information. In the TISDAG system, there is one internal server which provides referral information in response to queries.
内部服务器响应内部协议中的查询并提供特定类型的信息。在TISDAG系统中，有一个内部服务器，用于响应查询提供参考信息。
Note that all these components are defined by the functional roles they play in the system, not the particular protocols they handle, or even the aspect of the service they are meant to support. That is, a client access point is responsible for handling client traffic, whether its for searching, establishing security credentials, or some other task.
请注意，所有这些组件都是由它们在系统中扮演的功能角色定义的，而不是它们处理的特定协议，甚至是它们要支持的服务的方面。也就是说，客户机访问点负责处理客户机流量，无论是用于搜索、建立安全凭据还是其他任务。
The Requirements and Design principles outlined above are not particular to a national whitepages service. They are equally applicable in any application based on a query-response model, in services where multiple protocols need to be supported, and/or when the service requires specialized behavior "behind the scenes". In the TISDAG project, this last was inherent in the way the service first looks for referrals, then makes queries as appropriate. For protocols that don't handle the referral concept natively, the TISDAG system proxies the queries.
以上概述的要求和设计原则并非特定于国家白页服务。它们同样适用于基于查询响应模型的任何应用程序、需要支持多种协议的服务和/或服务需要“幕后”特殊行为的服务。在TISDAG项目中，服务首先查找推荐，然后根据需要进行查询，这是服务的固有方式。对于本机不处理引用概念的协议，TISDAG系统将代理查询。
Because of its particular application to query-response situations, the term "Directory Access Gateway", or "DAG" still fits as a label for this type of system architecture.
由于其在查询响应情况中的特殊应用，术语“目录访问网关”或“DAG”仍然适合作为此类系统体系结构的标签。
Internet applications are evolving, and require more sophisticated features (e.g., security mechanisms, accounting mechanisms, integration of historical session data). Continuing to develop a dedicated protocol per application type results in encumbered and unwieldy protocols, as each must implement coverage of all of these common aspects. But creating a single multi-application protocol seems unlikely at best. The implicit proposal here is that, rather than overloading protocols to support multiple aspects of a service, those aspects can be managed by breaking the service into multiple supporting components to carry out the specialized tasks of authentication, etc.
互联网应用正在发展，需要更复杂的功能（例如，安全机制、记帐机制、历史会话数据的集成）。继续为每种应用程序类型开发一个专用协议会导致协议阻塞和笨拙，因为每个协议都必须实现对所有这些公共方面的覆盖。但创建一个单一的多应用程序协议似乎不太可能。这里隐含的建议是，与重载协议以支持服务的多个方面不同，可以通过将服务分解为多个支持组件来管理这些方面，以执行身份验证等专门任务。
In the TISDAG project, the choice was made to use a single "internal protocol" (DAG/IP). The particular protocol used is not relevant to the architecture, but the principle is important. By selecting a single query-response transaction protocol, the needs of the particular application could be mapped onto it in terms of queries and data particular to the application. This makes the internal communications more flexible for configuration to other environments (services, applications).
在TISDAG项目中，选择使用单一的“内部协议”（DAG/IP）。使用的特定协议与体系结构无关，但原则很重要。通过选择单个查询-响应事务协议，可以根据特定于应用程序的查询和数据将特定应用程序的需求映射到该协议上。这使得内部通信在配置到其他环境（服务、应用程序）时更加灵活。
It is common today to select an existing, widely deployed protocol for transferring commands and data between client and server -- e.g., HTTP. However, apart from any issues of the appropriateness (or inappropriateness) of extending HTTP to this use, the work would have remained to define all the transaction types and data types over that protocol -- the specification of the interaction semantics and syntax.
如今，选择一种广泛部署的现有协议在客户端和服务器之间传输命令和数据是很常见的，例如HTTP。然而，除了将HTTP扩展到这种用途的适当性（或不适当性）之外，还需要定义该协议上的所有事务类型和数据类型——交互语义和语法的规范。
Apart from the potential to divide and conquer service aspects, as described above, this approach has many perceived benefits:
除了如上所述的划分和征服服务方面的潜力外，这种方法还有许多明显的好处：
- For multi-protocol environments, it requires on the order of N+M inter-protocol mappings, not NxM. - distribution of development - distribution of operation - eventual possibilities of hooking together different systems (of different backgrounds) - separation of - architectural principles - implementation to a specific application - configuration for a given service
- 对于多协议环境，它需要N+M协议间映射的顺序，而不是NxM。-开发分布-操作分布-将不同系统（不同背景）连接在一起的最终可能性-分离-架构原则-特定应用程序的实现-给定服务的配置
It is not the goal to say that a standardized system architecture can be made so that single components can be built for all possible applications. However, this approach in general permits the decoupling of access protocols from specific applications, and facilitates the integration of necessary infrastructure independently of access protocol (e.g., referrals, security, lookup services, distribution etc).
我们的目标不是说可以建立一个标准化的系统架构，以便为所有可能的应用程序构建单个组件。然而，这种方法通常允许将访问协议与特定应用程序分离，并促进独立于访问协议的必要基础设施的集成（例如，转介、安全、查找服务、分发等）。
Pictorially, the DAG architecture is as follows:
从图形上看，DAG架构如下所示：
+-------------------------------------------+
"a" | | +--------+ |
<-----> CAP a | | SAP A | |
| | | | |
|---------+ +-+------+---+ |
| |(Internal)| |
| "DAG/IP" | Server i | |
| +----------+ |
| |
| |
| +--------+ | "B"
| | SAP B <-------------->
| | | |
| +--------+ |
| |
+-------------------------------------------+
+-------------------------------------------+
"a" | | +--------+ |
<-----> CAP a | | SAP A | |
| | | | |
|---------+ +-+------+---+ |
| |(Internal)| |
| "DAG/IP" | Server i | |
| +----------+ |
| |
| |
| +--------+ | "B"
| | SAP B <-------------->
| | | |
| +--------+ |
| |
+-------------------------------------------+
Note that the bounding box is conceptual -- all components may or may not reside on one server, or a set of servers governed by the provider of the service.
请注意，边界框是概念性的——所有组件可能驻留在一台服务器上，也可能不驻留在一组由服务提供者管理的服务器上。
As we saw in the TISDAG project, the provider of this DAG-based service may be only loosely affiliated with the remote services that are used (Whitepages Directory Service Providers (WDSPs) in this case).
正如我们在TISDAG项目中所看到的，基于DAG的服务的提供者可能只是松散地与所使用的远程服务（在本例中为Whitepages目录服务提供者（WDSP））关联。
Building a service on this architecture requires:
在此体系结构上构建服务需要：
Service implementation: 1. definition of the overall application to be supported by the system -- whitepages, web resource indexing, medical information 2. requirements 3. expected behavior
服务实现：1。系统支持的整体应用程序的定义——白页、web资源索引、医疗信息2。要求3。预期行为
System architecture: 1. nature of deployment -- distributed, security requirements, etc. 2. identification of necessary CAPs -- in terms of access protocols to be supported, different service levels to be provided (e.g., secure and unsecure connections)
系统架构：1。部署的性质——分布式、安全需求等。识别必要的CAP——根据要支持的访问协议，提供不同的服务级别（例如，安全和不安全的连接）
3. identification of necessary services -- e.g., proxying to remote information search services, lookup services, "AAA[A]" (Authentication, Authorization, Accounting, [and Access]) servers, etc 4. definition of the transaction process for the service: insofar as the CAPs represent the service to client software, CAP modules manage the necessary transactions with other service modules
3. 识别必要的服务——例如，代理远程信息搜索服务、查找服务、“AAA[A]”（身份验证、授权、记帐和访问）服务器等4。服务事务处理的定义：就CAP代表客户端软件的服务而言，CAP模块管理与其他服务模块的必要事务
Data architecture:
数据架构：
1. selection of schemas to be used (in each protocol) 2. definition of schema and protocol mappings -- into and out of some DAG/IP representation
1. 选择要使用的模式（在每个协议中）2。模式和协议映射的定义——进入和离开某些DAG/IP表示
Consider the TISDAG project in the light of the above definitions.
鉴于上述定义考虑TISDAG项目。
Service implementation: 1. A national-scale subset of Whitepages lookups, with specific query types supported: only certain schema attributes were permitted in queries, and the expected behavior was limited in scope. 2. Requirements: the service had to support multiple query protocols (from clients and for servers), and be capable of searching the entire space of data without centralizing the storage of records. 3. Given a query of accepted type, provide referrals to whitepages servers that might have information to fulfill the query; if necessary, proxy the referrals (chain) to retrieve the information for the client.
服务实现：1。Whitepages查找的一个全国范围的子集，支持特定的查询类型：查询中只允许某些模式属性，并且预期行为的范围有限。2.要求：该服务必须支持多种查询协议（来自客户端和服务器），并且能够搜索整个数据空间，而无需集中存储记录。3.给定一个接受类型的查询，提供对whitepages服务器的引用，这些服务器可能具有完成查询所需的信息；如有必要，代理转介（链）为客户检索信息。
System architecture: 1. distributable components 2. publicly accessible CAPs in HTTP, SMTP, Whois++, LDAPv2, and LDAPv3 3. referral proxies to Whois++, LDAPv2 and LDAPv3 WDSPs, as well as a referral query service 4. the basic transaction process, uniform across all CAPs, is: - query the RI for relevant referrals - where necessary, chain referrals through SAPs of appropriate protocol return, in the native protocol, all remaining referrals and data
系统架构：1。可分配组件2。HTTP、SMTP、Whois++、LDAPv2和LDAPv3中的可公开访问CAP。Whois++、LDAPv2和LDAPv3 WDSP的转介代理，以及转介查询服务4。在所有CAP中统一的基本交易流程是：-向RI查询相关转介-必要时，通过适当协议返回的SAP链转介，在本机协议中，所有剩余转介和数据
Data architecture: see the spec.
数据架构：参见规范。
In the TISDAG project, the above diagram could be mapped as follows:
在TISDAG项目中，上图可绘制如下：
CAP a LDAPv2 CAP SAP A the Referral Index (RI) interface Server i the Referral Index (RI) SAP B LDAPv3 SAP
CAP a LDAPv2 CAP SAP a参考索引（RI）接口服务器i参考索引（RI）SAP B LDAPv3 SAP
Note that, in the TISDAG project specification, the designation SAP referred exclusively to proxy components designed to deal with external servers. The Referral Index was considered an entity in its own right. However, generalizing the concepts of the TISDAG experience lead to the proposal of regarding all DAG/IP-supporting service components as SAPs, each designed to carry out a particular type of service functionality, and whether the server is managed internally to the DAG system or not is immaterial.
请注意，在TISDAG项目规范中，名称SAP仅指设计用于处理外部服务器的代理组件。推荐索引本身被视为一个实体。然而，概括TISDAG经验的概念导致将所有DAG/IP支持服务组件视为SAP的建议，每个组件旨在执行特定类型的服务功能，并且服务器是否由DAG系统内部管理无关紧要。
Consider the case of "number portability" -- wherein it is necessary to determine the current service provider of a specific phone number. The basic assumption is that phone numbers are assigned to be globally unique, but are not in any way tied to a specific service provider. Therefore, it is necessary to determine the current service provider for the given number before being able to retrieve current information. For the sake of our illustration, let us assume that the management of numbers is two-tiered -- suppose the system stores (internally) the mapping between these random digit strings and the country in which each was originally activated, but relies on external (country-specific) services to manage the updated information about which service provider currently manages a given number. Then, the service data need only be updated when new numbers are assigned, or national services change their access points.
考虑“数字便携性”的情况，其中有必要确定特定电话号码的当前服务提供商。基本假设是，电话号码分配为全局唯一，但不以任何方式与特定服务提供商绑定。因此，在能够检索当前信息之前，有必要确定给定号码的当前服务提供商。为了便于说明，让我们假设数字的管理是两层的——假设系统存储（内部）这些随机数字字符串与每个字符串最初激活的国家之间的映射，但依赖于外部（特定于国家）服务，以管理有关哪个服务提供商当前管理给定号码的更新信息。然后，仅当分配了新号码或国家服务更改其接入点时，才需要更新服务数据。
We can look at a grossly-simplified version of the problem as an illustration of some of the concepts proposed in this service architecture. We couple it with the "name search" facet of the TISDAG example, to underscore that a single service ("operator") may in fact be supported by several disjunct underlying activities.
我们可以将此问题的一个非常简化的版本作为此服务体系结构中提出的一些概念的说明。我们将其与TISDAG示例的“名称搜索”方面结合起来，以强调单个服务（“运营商”）实际上可能由几个不相交的底层活动支持。
Service implementation: 1. Retrieving service information for a particular (unstructured) phone number digit sequence, or searching for numbers associated with a particular name (or fragment thereof). 2. Requirements: support IP-telephony through HTTP-based requests, wireless device requests through WAP [WAP].
服务实现：1。检索特定（非结构化）电话号码数字序列的服务信息，或搜索与特定姓名（或其片段）关联的号码。2.要求：通过基于HTTP的请求支持IP电话，通过WAP[WAP]支持无线设备请求。
3. Expected behavior: given a name (fragment), return a list of names and numbers to match the fragment; given a phone number, return appropriately-structured information re. the current service mapping for that number.
3. 预期行为：给定名称（片段），返回与片段匹配的名称和数字列表；给定一个电话号码，返回相应的结构化信息。该号码的当前服务映射。
System architecture: 1. Publicly accessible through CAPs; components widely distributed. 2. Need one CAP for HTTP, one for WAP. 3. Support services include: an internal service for lookup of number strings (to identify nation of origin of the number), a proxy to access national services for registration of numbers and service providers, and a proxy for remote service provider for retrieval of detailed information regarding numbers. For the name searching, we also need a referral index over the names, and a proxy to whatever remote servers are managing the whitepages directories. 4. Now, 2 different types of transaction are possible: search for name, or look-up a number. In the name search case, the CAP receives a name or name fragment, looks it up in the internal referral index, and finds associated numbers through external whitepages services (WDSPs). To look-up a number, the CAP first uses the internal look-up service to determine the country of origin of the number, and then uses a SAP to access that nation's number-service provider directory, and finally uses a different SAP to access the current service provider to determine the information required to make the call.
系统架构：1。可通过CAP公开访问；广泛分布的组件。2.HTTP需要一个CAP，WAP需要一个CAP。3.支持服务包括：用于查找数字字符串的内部服务（用于标识数字的来源国）、用于访问数字和服务提供商注册的国家服务的代理，以及用于检索数字详细信息的远程服务提供商的代理。对于名称搜索，我们还需要名称的引用索引，以及管理whitepages目录的任何远程服务器的代理。4.现在，有两种不同类型的事务是可能的：搜索名称或查找数字。在名称搜索案例中，CAP接收一个名称或名称片段，在内部引用索引中查找，并通过外部whitepages服务（WDSP）查找相关号码。要查找号码，CAP首先使用内部查找服务确定号码的来源国，然后使用SAP访问该国的号码服务提供商目录，最后使用其他SAP访问当前服务提供商以确定拨打电话所需的信息。
Data architecture: [Out of scope for the purposes of this illustration]
数据架构：[在本说明中超出范围]
Note that some elements of the system architecture are deliberately vague. Per the requirements, no structure is expected in the number string, and therefore the lookup server must maintain an index of number-to-country mappings and relies on an external number-to-service mapping service (in each country). However, were there any structure to the numbers, the lookup server could make use of that structure in the indexing, or in distribution of the index itself. This would have no effect on the CAPs, which have no inherent reliance on how the lookup server performs its task.
请注意，系统架构的某些元素故意含糊不清。根据要求，数字字符串中不应包含任何结构，因此查找服务器必须维护数字到国家/地区映射的索引，并依赖外部数字到服务映射服务（在每个国家/地区）。但是，如果数字有任何结构，查找服务器可以在索引或索引本身的分发中使用该结构。这对CAP没有影响，CAP与查找服务器执行任务的方式没有内在的依赖性。
Pictorially, the example can be rendered as follows:
从图形上看，示例可以呈现如下：
+-------------------------------------------+
"a" | | +--------+ |
<-----> CAP a | | SAP A | |
| | | | |
|---------+ +-+------+---+ |
| |(Internal)| |
| "DAG/IP" | Server i | |
| +----------+ |
| |
| +--------+ | "B"
| | SAP B <-------------->
| | | |
| +--------+ |
| |
| +--------+ | "C"
|---------+ | SAP C <-------------->
"b" | | | | |
<-----> CAP b | +--------+ |
| | |
|---------+ +--------+ |
| | SAP D | |
| | | |
| +-+------+---+ |
| |(Internal)| |
| | Server j | |
| +----------+ |
| |
| +--------+ | "E"
| | SAP E <-------------->
| | | |
| +--------+ |
+-------------------------------------------+
+-------------------------------------------+
"a" | | +--------+ |
<-----> CAP a | | SAP A | |
| | | | |
|---------+ +-+------+---+ |
| |(Internal)| |
| "DAG/IP" | Server i | |
| +----------+ |
| |
| +--------+ | "B"
| | SAP B <-------------->
| | | |
| +--------+ |
| |
| +--------+ | "C"
|---------+ | SAP C <-------------->
"b" | | | | |
<-----> CAP b | +--------+ |
| | |
|---------+ +--------+ |
| | SAP D | |
| | | |
| +-+------+---+ |
| |(Internal)| |
| | Server j | |
| +----------+ |
| |
| +--------+ | "E"
| | SAP E <-------------->
| | | |
| +--------+ |
+-------------------------------------------+
where
哪里
CAP a HTTP CAP CAP b WAP CAP SAP A the number-nation lookup interface Server i number-nation lookup server (what country) SAP B nation-service lookup SAP (what service provider) SAP C service-number information lookup SAP (current service details) SAP D referral index interface Server j referral index service SAP E proxy for chaining queries to remote WDSPs
CAP a HTTP CAP CAP b WAP CAP SAP a号码国家查找接口服务器i号码国家查找服务器（哪个国家）SAP b国家服务查找SAP（哪个服务提供商）SAP C服务号码信息查找SAP（当前服务详细信息）SAP D参考索引接口服务器j参考索引服务SAP E proxy用于将查询链接到远程WDSP
The service architecture is useful for applications outside the scope of "telecoms". In another hypothetical illustration, consider the case of medical information -- records about patients that may be created and stored at a variety of institutions which they visit. It is not unusual to need to access all information concerning a patient, whether or not the person can recollect (or communicate) conditions that were treated, procedures that were performed, or medical institutions visited. The data may include everything from prescriptions, to X-rays and other images, to incident reports and other elements of medical history, etc. Typically, the information is stored where it is collected (or by an agency authorized by that institution) -- not in a central repository. Any service that looks to provide complete answers to queries must deal with these realities, and clearly must function with a strong security model.
服务架构对于“电信”范围之外的应用非常有用。在另一个假设性的例证中，考虑医疗信息的情况——关于病人可以在他们访问的各种机构中创建和存储的记录。无论患者是否能够回忆（或交流）治疗情况、执行的程序或访问的医疗机构，都需要访问患者的所有信息，这并不罕见。数据可能包括从处方、X光片和其他图像到事件报告和其他病史要素等所有内容。通常，信息存储在收集信息的地方（或由该机构授权的机构），而不是存储在中央存储库中。任何希望为查询提供完整答案的服务都必须处理这些现实，并且显然必须使用强大的安全模型。
Service implementation:
1. Retrieving all medical information for a particular person.
2. Requirements: must retrieve, or at least locate, all
available information, regardless of its storage location;
cannot require central repository of information; must
implement authorization and access controls. Must
support a proprietary protocol for secure connections
within hospitals, wireless access for personnel in
emergency vehicles (not considered secure access).
3. Expected behavior: given a patient's national ID, and
authorized access by medical personnel in secure locations,
determine what kinds of records are available, and where;
given a request for a specific type of record, retrieve
the record. Given a patient's national ID, and authorized
access from a wireless device, provide information re.
any known medical flags (e.g., medicine allergies,
conditions, etc).
Service implementation:
1. Retrieving all medical information for a particular person.
2. Requirements: must retrieve, or at least locate, all
available information, regardless of its storage location;
cannot require central repository of information; must
implement authorization and access controls. Must
support a proprietary protocol for secure connections
within hospitals, wireless access for personnel in
emergency vehicles (not considered secure access).
3. Expected behavior: given a patient's national ID, and
authorized access by medical personnel in secure locations,
determine what kinds of records are available, and where;
given a request for a specific type of record, retrieve
the record. Given a patient's national ID, and authorized
access from a wireless device, provide information re.
any known medical flags (e.g., medicine allergies,
conditions, etc).
System architecture: 1. Only 2 CAP types are needed, but instances of these will be established at major medical institutions. 2. Need one CAP to support the proprietary protocol, one to support wireless access. 3. Support services include: an internal server to support security authentication and access control determination; an internal server to act as referral index for finding information pertinent to a particular patient, and one or more proxies for accessing remote data storage servers. 4. The basic transaction requires that the first step be to authenticate the end-user and determine access privileges. In the case of wireless access, this last will not involve
系统架构：1。只需要两种CAP类型，但这些类型的实例将在主要医疗机构中建立。2.需要一个CAP来支持专有协议，一个CAP来支持无线接入。3.支持服务包括：支持安全认证和访问控制确定的内部服务器；内部服务器用作查找特定患者相关信息的转诊索引，以及一个或多个用于访问远程数据存储服务器的代理。4.基本事务要求第一步是验证最终用户并确定访问权限。在无线接入的情况下，最后一个将不涉及
a specific lookup, but rather will be set to allow the user to see the list of publicized medical conditions. Depending on the query type, the next step will be to contact the referral index to determine what records exist, and then track down information at the remote sources.
特定的查找，但将设置为允许用户查看已公布的医疗状况列表。根据查询类型，下一步是联系参考索引以确定存在哪些记录，然后跟踪远程源的信息。
Data architecture: [Out of scope for the purposes of this illustration]
数据架构：[在本说明中超出范围]
Pictorially, the example can be rendered as follows:
从图形上看，示例可以呈现如下：
+-------------------------------------------+
"a" | | +--------+ |
<-----> CAP a | | SAP A | |
| | | | |
|---------+ +-+------+---+ |
| |(Internal)| |
| "DAG/IP" | Server i | |
| +----------+ |
| |
| |
| +--------+ | "B"
|---------+ | SAP B <-------------->
"b" | | | | |
<-----> CAP b | +--------+ |
| | |
|---------+ +--------+ |
| | SAP C | |
| | | |
| +-+------+---+ |
| |(Internal)| |
| | Server j | |
| +----------+ |
+-------------------------------------------+
+-------------------------------------------+
"a" | | +--------+ |
<-----> CAP a | | SAP A | |
| | | | |
|---------+ +-+------+---+ |
| |(Internal)| |
| "DAG/IP" | Server i | |
| +----------+ |
| |
| |
| +--------+ | "B"
|---------+ | SAP B <-------------->
"b" | | | | |
<-----> CAP b | +--------+ |
| | |
|---------+ +--------+ |
| | SAP C | |
| | | |
| +-+------+---+ |
| |(Internal)| |
| | Server j | |
| +----------+ |
+-------------------------------------------+
where
哪里
CAP a CAP for proprietary protocol, secure clients CAP b WAP CAP, for roaming access SAP A authentication and ACL lookup interface Server i authentication and ACL lookup server SAP B remote service SAP -- probably LDAPv3 SAP C Referral Index interface Server j Referral Index
CAP a CAP用于专有协议，安全客户端CAP b WAP CAP用于漫游访问SAP a身份验证和ACL查找接口服务器i身份验证和ACL查找服务器SAP b远程服务SAP--可能是LDAPv3 SAP C参考索引接口服务器j参考索引
The role of the DAG/IP is less as a query protocol, and more as a framework or structure for carrying basic query-response transactions of different (configurable) types.
DAG/IP的作用不是作为一个查询协议，而是作为一个框架或结构，用于承载不同（可配置）类型的基本查询响应事务。
Whatever the syntax or grammar, the basic requirements for the DAG/IP include that it be:
无论语法如何，DAG/IP的基本要求包括：
- lightweight; CAPs, SAPs should be able to be quite small - flexible enough to carry queries of different paradigms, results of different types - able to support authentication, authorization, accounting and audit mechanisms -- not necessarily native to the protocol - able to support encryption and end-to-end security within the DAG system - sophisticated enough to allow negotiation of capabilities -- querying & identifying application type supported (e.g., whitepages vs. service location vs. URN resolution), query types supported, results types supported
- 轻量的CAP、SAP应能够非常小-足够灵活以承载不同范例的查询、不同类型的结果-能够支持身份验证、授权、，记帐和审计机制——不一定是协议的固有机制——能够支持DAG系统内的加密和端到端安全性——足够复杂，可以协商功能——查询和识别支持的应用程序类型（例如，白页与服务位置与URN解析）、支持的查询类型，支持的结果类型
This also means:
这也意味着：
Better support for query-passing/other query semantics (need to balance that against the fact that you don't want DAG-CAPs/SAPs to have to know a multiplicity of semantic possibilities.
更好地支持查询传递/其他查询语义（需要在这一点与您不希望DAG CAPs/SAP必须知道多种语义可能性这一事实之间取得平衡）。
Security infrastructure -- ability to establish security credentials, maintain a secure transaction, and propagate the security information forward in the transaction (don't want to reinvent the wheel, just want to be able to use it!).
安全基础设施--能够建立安全凭据，维护安全事务，并在事务中向前传播安全信息（不想重新发明轮子，只想能够使用它！）。
Ability to do lookups, instead of searches -- might mean connecting to different services than the RI and/or presenting things in a slightly different light -- e.g., lookup <blat> in the <foo> space, as opposed to search for all things concerning <blat>.
能够进行查找，而不是搜索——可能意味着连接到不同于RI的服务和/或以稍微不同的方式呈现事物——例如，在<foo>空间中查找<blat>，而不是搜索所有与<blat>有关的事物。
Ability to access other services -- e.g., Norwegian Directory of Directories [NDD] -- beyond just for specific characteristics of the service (e.g., security).
能够访问其他服务——例如挪威目录[NDD]——而不仅仅是服务的特定特征（例如安全性）。
In short, the model that seems to stand out from these requirements one of a protocol framework that looks after establishing secure and authenticated (authorized, accountable, auditable...) connections, with transaction negotiation facilities. Within that framework, it must be possible to identify transaction types, provide suitable input information (negotiation?) for those transactions, and accept transaction result objects back.
简言之，从这些需求中脱颖而出的模型是一个协议框架，它负责建立安全的、经过认证的（授权的、可问责的、可审核的…）连接，并提供事务协商设施。在该框架内，必须能够识别事务类型，为这些事务提供适当的输入信息（协商？），并接受事务结果对象。
In the light of the above proposals, we can revisit the way the TISDAG CAPs would be defined.
根据上述建议，我们可以重新审视TISDAG上限的定义方式。
The whitepages-application service known as TISDAG could have SAPs that supported 2 types of query, and 2 types of result sets:
名为TISDAG的whitepages应用程序服务可能具有支持2种查询类型和2种结果集类型的SAP：
query types: . token-based . phrase-based
查询类型：。基于令牌的。基于短语的
result types: . result data . referrals
结果类型：。结果数据。转介
The Whois++ CAP would be configured to contact LDAPv2 and LDAPv3 SAPs because they are identified as providing that kind of service (i.e., if referral protocol == LDAPv2 connect to a particular service). The query paradigm will be phrase-oriented -- NOT because the Whois++ CAP understands LDAP, but because that is one of the defined query types.
Whois++CAP将配置为联系LDAPv2和LDAPv3 SAP，因为它们被标识为提供此类服务（即，如果引用协议==LDAPv2连接到特定服务）。查询范例将是面向短语的——不是因为Whois++CAP理解LDAP，而是因为它是定义的查询类型之一。
As it stands, this type of service architecture is limited to query-response type transactions. This does account for a broad range of applications and services, although it would be interesting to consider broadening the concept to make it applicable to tunneling other protocols (e.g., to connect a call through a SAP, in the number portability example above).
目前，这种类型的服务体系结构仅限于查询响应类型的事务。这确实说明了广泛的应用和服务，尽管考虑拓宽概念以使其适用于隧道其他协议（例如，通过SAP连接呼叫，在上面的号码可携性示例中）是很有意思的。
This document takes a high-level perspective on service architecture, and as such it neither introduces nor addresses security concerns at an implementation level.
本文档从高层次的角度介绍服务体系结构，因此它既不介绍也不解决实现级别的安全问题。
A distributed service built following this approach must address issues of authentication of users, authorization for access to material/components of the system, and encryption of links between them, as befits the nature of the information and service provided.
按照这种方法构建的分布式服务必须解决用户身份验证、访问系统材料/组件的授权以及它们之间链接的加密等问题，这符合所提供信息和服务的性质。
In discussing this perspective on the evolution of DAG/IP, it seemed to us that the requirements for DAG/IP are falling into line with the proposed text-based directory access protocol that has variously been discussed. Whether it survives in a recognizable form or not :-) some of the above has been drawn from discussions of that protocol with Michael Mealling and Patrik Faltstrom.
在讨论DAG/IP演进的这一观点时，我们认为，DAG/IP的要求似乎与已讨论过的基于文本的目录访问协议一致。无论它是否以一种可识别的形式存在：-）上述部分内容是从与迈克尔·米林和帕特里克·法特斯特罗姆讨论该议定书时得出的。
The work described in this document was carried out as part of an on-going project of Ericsson. For further information regarding that project, contact:
本文件中描述的工作是作为爱立信正在进行的项目的一部分进行的。有关该项目的更多信息，请联系：
Bjorn Larsson bjorn.x.larsson@era.ericsson.se
比约恩·拉尔森比约恩.x。larsson@era.ericsson.se
Leslie L. Daigle Thinking Cat Enterprises
莱斯利·L·戴格尔思维猫企业
EMail: leslie@thinkingcat.com
EMail: leslie@thinkingcat.com
Thommy Eklof Hotsip AB
托米·埃克洛夫酒店
EMail: thommy.eklof@hotsip.com
EMail: thommy.eklof@hotsip.com
Request For Comments (RFC) and Internet Draft documents are available from numerous mirror sites.
许多镜像站点都提供了征求意见（RFC）和互联网草稿文档。
[ALVE] Alvestrand, H., "Definitions for Talking about Directories", Work in Progress.
[ALVE]Alvestrand，H.，“关于目录的定义”，正在进行中。
[TISDAG] Daigle, L. and R. Hedberg "Technical Infrastructure for Swedish Directory Access Gateways (TISDAG)", RFC 2967, October 2000.
[TISDAG]Daigle，L.和R.Hedberg，“瑞典目录访问网关（TISDAG）的技术基础设施”，RFC 2967，2000年10月。
[DAGEXP] Eklof, T. and L. Daigle, "Wide Area Directory Deployment Experiences", RFC 2969, September 2000.
[DAGEXP]Eklof，T.和L.Daigle，“广域目录部署经验”，RFC 2969，2000年9月。
[DAG-Mesh] Daigle, L. and T. Eklof, "Networking Multiple DAG servers: Meshes", RFC 2968, September 2000.
[DAG Mesh]Daigle，L.和T.Eklof，“将多个DAG服务器联网：Mesh”，RFC 2968，2000年9月。
[NDD] Hedberg, R. and H. Alvestrand, "Technical Specification, The Norwegian Directory of Directories (NDD)", Work in Progress.
[NDD]Hedberg，R.和H.Alvestrand，“技术规范，挪威目录目录（NDD）”，正在进行的工作。
[WAP] The Wireless Application Protocol, http://www.wapforum.org
[WAP] The Wireless Application Protocol, http://www.wapforum.org
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。