Network Working Group T. Eklof
Request for Comments: 2969 L. Daigle
Category: Informational October 2000
Network Working Group T. Eklof
Request for Comments: 2969 L. Daigle
Category: Informational October 2000
Wide Area Directory Deployment - Experiences 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
摘要
The TISDAG (Technical Infrastructure for Swedish Directory Access Gateway) project provided valuable insight into the current reality of deploying a wide-scale directory service. This document catalogues some of the experiences gained in developing the necessary infrastructure for a national (i.e., multi-organizational) directory service and pilot deployment of the service in an environment with off-the-shelf directory service products. A perspective on the project's relationship to other directory deployment projects is provided, along with some proposals for future extensions of the work (larger scale deployment, other application areas).
TISDAG（瑞典目录访问网关技术基础设施）项目为当前部署大规模目录服务的现实提供了有价值的见解。本文件列举了为国家（即多组织）目录服务开发必要基础设施以及在具有现成目录服务产品的环境中试点部署该服务所取得的一些经验。本文提供了该项目与其他目录部署项目关系的透视图，以及对该工作的未来扩展（更大规模部署、其他应用领域）的一些建议。
These are our own observations, based on work done and general project discussions. No doubt, other project participants have their own list of project experiences; we don't claim this document is exhaustive!
这些是我们自己的观察，基于所做的工作和一般项目讨论。毫无疑问，其他项目参与者有自己的项目经验清单；我们并不认为这份文件是详尽无遗的！
Table of Contents
目录
1.0 Introduction ................................................ 2
1.1 Overview of the TISDAG project .............................. 2
1.2 Organization of this document ............................... 3
2.0 The TISDAG project itself ................................... 3
2.1 TISDAG overview ............................................ 3
2.2 Some successes .............................................. 4
2.3 Some surprises .............................................. 5
2.3.1 LDAP objectclasses and the "o" attribute .................. 6
2.3.1 The Tagged Index Object ................................... 6
2.3.3 Handling Status Messages ................................. 7
2.3.4 Deployment with Commercial Software ...................... 7
2.4 Some observations ........................................... 7
2.4.1 Participation of the WDSPs ................................ 7
2.4.2 Index Objects and Referral Index size ..................... 8
2.4.3 Index Object and Query Performance ........................ 8
2.5 Some evolutions ............................................. 9
3.0 Related Projects ............................................ 11
3.1 The Norwegian Directory of Directories (NDD) ................ 11
3.2 DESIRE Directory Services ................................... 11
4.0 Some Directions for TISDAG Next Steps ....................... 12
4.1 Security support ............................................ 12
4.2 WDSPs attributes and schemas ............................... 12
5.0 Some conclusions ............................................ 13
6.0 Security Considerations ..................................... 13
7.0 Acknowledgements ............................................ 13
8.0 Authors' Addresses .......................................... 13
9.0 References .................................................. 14
Appendix -- Specific Software Issues and Deployment Experiences.. 15
Full Copyright Statement ........................................ 18
1.0 Introduction ................................................ 2
1.1 Overview of the TISDAG project .............................. 2
1.2 Organization of this document ............................... 3
2.0 The TISDAG project itself ................................... 3
2.1 TISDAG overview ............................................ 3
2.2 Some successes .............................................. 4
2.3 Some surprises .............................................. 5
2.3.1 LDAP objectclasses and the "o" attribute .................. 6
2.3.1 The Tagged Index Object ................................... 6
2.3.3 Handling Status Messages ................................. 7
2.3.4 Deployment with Commercial Software ...................... 7
2.4 Some observations ........................................... 7
2.4.1 Participation of the WDSPs ................................ 7
2.4.2 Index Objects and Referral Index size ..................... 8
2.4.3 Index Object and Query Performance ........................ 8
2.5 Some evolutions ............................................. 9
3.0 Related Projects ............................................ 11
3.1 The Norwegian Directory of Directories (NDD) ................ 11
3.2 DESIRE Directory Services ................................... 11
4.0 Some Directions for TISDAG Next Steps ....................... 12
4.1 Security support ............................................ 12
4.2 WDSPs attributes and schemas ............................... 12
5.0 Some conclusions ............................................ 13
6.0 Security Considerations ..................................... 13
7.0 Acknowledgements ............................................ 13
8.0 Authors' Addresses .......................................... 13
9.0 References .................................................. 14
Appendix -- Specific Software Issues and Deployment Experiences.. 15
Full Copyright Statement ........................................ 18
As described in more detail in [TISDAG], the original intention of the TISDAG project was to provide the infrastructure for a national whitepages directory service. To be effective, such an infrastructure needed to address the concrete realities of end-users' existing client software, as well as the needs of information providers ("Whitepages Directory Service Providers" -- WDSPs). These realities include the existence of multiple protocols (so-called directory service access protocols, as well as more general Internet application protocols such as HTTP and SMTP). The project was also sensitive to the fact that WDSPs have many good reasons for being reluctant to relinquish copies of their subscribers' personal data.
如[TISDAG]所述，TISDAG项目的初衷是为国家白页目录服务提供基础设施。为了有效，这种基础设施需要满足最终用户现有客户端软件的具体现实，以及信息提供商（“白页目录服务提供商”——WDSP）的需求。这些现实包括存在多种协议（所谓的目录服务访问协议，以及更通用的Internet应用程序协议，如HTTP和SMTP）。该项目还敏感地认识到，WDSP有许多很好的理由不愿意放弃其订户的个人数据副本。
In an effort to communicate the experiences with this project, from conception through implementation and pilot deployment, this document is divided into 3 major sections. The first section reviews specific lessons learned by the authors through the TISDAG project and implementation of one conformant system. Next, some perspectives are offered on the relationship of the TISDAG work to other large-scale directory projects that are currently on-going, to give a sense of how these efforts might possibly interact. Finally, some preliminary thoughts on applying the DAG system to other applications and deployment environments are outlined. Further suggestions for deploying networked DAG servers (meshes) can be found in [DAG-Mesh]. More discussion of useful development of architectural principles is provided in a separate document ([DAG++]).
为了交流本项目的经验，从概念到实施和试点部署，本文件分为3个主要部分。第一节回顾了作者通过TISDAG项目和一个合规系统的实施所获得的具体经验教训。接下来，就TISDAG工作与当前正在进行的其他大型目录项目的关系提供一些观点，以了解这些工作可能如何相互作用。最后，概述了将DAG系统应用于其他应用和部署环境的一些初步想法。有关部署联网DAG服务器（网格）的更多建议，请参见[DAG网格]。在单独的文档（[DAG++]）中提供了关于架构原则有用开发的更多讨论。
Briefly, the technical infrastructure proposed for the TISDAG project (see [TISDAG] for the complete overview and technical specification) provides end-user client software with connection points to perform basic whitepages queries. Different connection points are provided for the various protocols end-users are likely to wish to use to access the information -- WWW (http), e-mail (SMTP), Whois++, LDAPv2 and LDAPv3. For each client, a transaction will be carried out within the bounds of the protocol's syntax and semantics. However, since the TISDAG system does not maintain a replicated copy of all whitepages information, but rather an index over the data that allows redirection (referrals) to services that are likely to contain responses that match the client's query, a fair bit of background work must be done by the DAG system in order to fulfill the client's query.
简而言之，为TISDAG项目拟定的技术基础设施（完整概述和技术规范见[TISDAG]）为最终用户客户端软件提供了连接点，以执行基本的白页查询。为最终用户可能希望用于访问信息的各种协议提供了不同的连接点——WWW（http）、电子邮件（SMTP）、Whois++、LDAPv2和LDAPv3。对于每个客户端，将在协议的语法和语义范围内执行一个事务。但是，由于TISDAG系统并不维护所有白页信息的复制副本，而是一个数据索引，允许重定向（引用）到可能包含与客户端查询匹配的响应的服务，为了完成客户的查询，DAG系统必须做大量的后台工作。
The first, and most important step, is for the system to make a query against the DAG Referral Index -- a server containing index information (obtained by the Common Indexing Protocol (see [CIP1, CIP2, CIP3]) in the Tagged Index Object format (see [TIO]). This index contains sufficient information to indicate which of the many participating WDSPs should be contacted to complete the query. Wherever possible, these referrals are passed back to the querying client so that it can contact relevant WDSPs directly. This minimizes the amount of work done by the DAG system itself, and allows WDSPs greater visibility (which is an incentive for participating in the system). Protocols which support referrals natively include Whois++ and LDAPv3 -- although these may only be referred to servers of the same protocol.
第一步，也是最重要的一步，是系统对DAG引用索引进行查询，DAG引用索引是一个包含索引信息（通过通用索引协议（参见[CIP1，CIP2，CIP3]）的服务器，采用标记索引对象格式（参见[TIO]）。此索引包含足够的信息，以指示应联系多个参与的WDSP中的哪一个来完成查询。只要有可能，这些引用将传递回查询客户端，以便它可以直接联系相关的WDSP。这将最大限度地减少DAG系统本身所做的工作量，并允许WDSP完成更大的查询可见性（这是参与系统的一个激励因素）。本机支持转介的协议包括Whois++和LDAPv3——尽管这些协议可能只被转介到相同协议的服务器。
Since many protocols do not support referrals (e.g., LDAPv2), and in order to address referrals to servers using a protocol other than the calling client's own, a secondary step of "query chaining" is provided to pursue these extra referrals within the DAG system itself. For example, if an LDAPv2 client connects to the system, a query is made against the Referral Index to determine which WDSPs may have answers for the query, and then resources within the DAG system are used to pursue the query at the designated WDSPs' servers. The results from these different services are packaged into a single response set for the client that made the query.
由于许多协议不支持转介（例如，LDAPv2），并且为了使用调用客户机自己的协议以外的协议来处理对服务器的转介，提供了“查询链接”的第二步，以在DAG系统本身内进行这些额外的转介。例如，如果LDAPv2客户端连接到系统，则会根据参考索引进行查询，以确定哪些WDSP可能有查询的答案，然后使用DAG系统中的资源在指定的WDSP服务器上执行查询。来自这些不同服务的结果被打包到进行查询的客户端的单个响应集中。
The architecture that was developed in order to support the required functionality separated the system into distinct components to handle incoming queries from client software ("Client Access Points", or CAPs), a referral index (RI) to maintain an index over the collected whitepages information and provide referrals, based on actual data queries, to WDSPs that might have relevant information, and finally components that mediate access to WDSP whitepages servers to perform queries and retrieve results for the client's query ("Service Access Points", or SAPs). Several CAPs and SAPs exist within the system -- at least one for every protocol supported for incoming queries and WDSP servers, respectively.
为支持所需功能而开发的体系结构将系统划分为不同的组件，以处理来自客户端软件（“客户端访问点”或CAP）的传入查询，参考索引（RI）用于维护收集的白页信息索引，并根据实际数据查询提供参考，到可能具有相关信息的WDSP，最后到调解对WDSP whitepages服务器的访问以执行查询和检索客户端查询结果的组件（“服务访问点”，或SAP）。系统中存在多个CAP和SAP——传入查询和WDSP服务器分别支持的每个协议至少有一个CAP和SAP。
Designed to be implementable as separate programs, these components interact with each other through the use of an internal protocol -- the DAG/IP. Pragmatically, the use of the protocol means that different components can reside on different machines, for reasons of load-balancing and performance enhancement. It also acts as a "common language" for the CAPs, SAPs and RI to express queries and receive results.
这些组件被设计为可以作为单独的程序实现，它们通过使用内部协议（DAG/IP）相互交互。实际上，由于负载平衡和性能增强的原因，协议的使用意味着不同的组件可以驻留在不同的机器上。它还充当CAP、SAPs和RI表达查询和接收结果的“通用语言”。
This outlines the planned or ideal behaviour of the system; once designed, a pilot phase was started for the project to compare reality against expectations. Two independent implementations of the software were created, and a test deployment was set up within the Swedish University Network (SUNET). More detail on the project and its current status can be found at http://tisdag.sunet.se/.
这概述了系统的计划或理想行为；设计完成后，项目开始了一个试验阶段，将现实与预期进行比较。创建了两个独立的软件实现，并在瑞典大学网络（SUNET）内建立了测试部署。有关该项目及其当前状态的更多详细信息，请访问http://tisdag.sunet.se/.
The rest of this section outlines some conclusions drawn from making a reality of the proposed architecture -- both successes and surprises.
本节的其余部分概述了从实现所提议的体系结构中得出的一些结论，包括成功和意外。
Implementation and pilot deployment of software meeting the TISDAG technical specification did demonstrate some important successes of the approach.
符合TISDAG技术规范的软件的实施和试点部署确实证明了该方法的一些重要成功。
Most notably, the system works pretty much as expected (see exceptions below) to provide transparent middleware for whitepages directory services. That is, client software and WDSP servers were minimally affected -- from the point of view of behaviour and configuration, the DAG system looked like a server to clients, and a client to servers.
最值得注意的是，该系统的工作原理与预期基本一致（参见下面的例外情况），为whitepages目录服务提供了透明的中间件。也就是说，客户端软件和WDSP服务器受到的影响最小——从行为和配置的角度来看，DAG系统看起来就像客户端的服务器，客户端到服务器。
The goal of the TISDAG project, operationally, was to be able to provide responses to end-user queries in reasonable response times (although not "an addressbook replacement"). The prototype systems demonstrated some success in achieving responses within 10 seconds, at least with the limited testbed of a configuration with 10 WDSP's providing directory service information. More observations on system performance are provided below.
TISDAG项目的目标在操作上是能够在合理的响应时间内对最终用户查询提供响应（尽管不是“地址簿替换”）。原型系统在10秒内实现响应方面取得了一些成功，至少在10个WDSP提供目录服务信息的有限配置测试台上是如此。下文提供了关于系统性能的更多观察结果。
The DAG system does demonstrate that it is possible to build referral-level services at a national level (although the deployment has yet to prove conclusively that it can, in its current formulation, operate as a transparent query-fulfillment proxy service).
DAG系统确实证明了有可能在国家一级建立转诊级别的服务（尽管部署尚未最终证明，在其当前的表述中，它可以作为透明的查询实现代理服务运行）。
The success of the implementation demonstrated that it is possible, in some sense, to do (semantic) protocol mapping with N+M complexity instead of NxM mappings. That is, protocol translations had to be defined for "N" allowable end-user query access protocols to/from the DAG/IP, and "M" supported WDSP server protocols, instead of requiring each of the N input components to individually map to the M output protocols.
实现的成功表明，在某种意义上，可以使用N+M复杂度而不是NxM映射来进行（语义）协议映射。也就是说，必须为DAG/IP之间的“N”允许最终用户查询访问协议和“M”支持的WDSP服务器协议定义协议转换，而不是要求N个输入组件中的每一个单独映射到M个输出协议。
As a correlated issue, the prototype system demonstrated some successes with mapping between schema representations in the different protocol paradigms -- in a large part because system's schemas were kept simple and focused on the minimal needs to support the base service requirements.
作为一个相关的问题，原型系统在不同协议范例中的模式表示之间的映射方面取得了一些成功——这在很大程度上是因为系统的模式保持简单，并侧重于支持基本服务需求的最低需求。
Over the span of a dozen months from the first "final" document of the specification through the implementation and first deployment of the software system, a few surprises did surface. These fell into two categories: those that surfaced when the theoretical specification was put into practice, and others that became apparent when the resulting system was put into operation with commercial software clients and servers.
从规范的第一份“最终”文档到软件系统的实现和首次部署，在十几个月的时间里，出现了一些惊喜。这些可分为两类：一类是在理论规范付诸实践时出现的，另一类是在最终系统与商业软件客户端和服务器一起投入运行时出现的。
More detail is provided in the Appendix concerning specific software issues encountered, but some of the larger issues that surfaced during the implementation phase are describe below.
附录中提供了有关遇到的特定软件问题的更多详细信息，但在实施阶段出现的一些较大问题将在下文中描述。
It came as a considerable surprise, some months into the project, that none of the "standard" LDAP person objectclasses included organization ("o") as an attribute. The basic assumption seems to be that "o" will be part of the distinguished name for an entry, and therefore there is little (if any) cause to list it out separately. This does make it trickier to store information for people across multiple organizations (e.g., at an ISP's directory server) and use the organization name in query refinement. (Roland Hedberg caught this issue, and has flagged it to the authors of the "inetorgperson" objectclass document).
在项目开始的几个月里，没有一个“标准”LDAP person对象类将organization（“o”）作为属性，这是一个相当令人惊讶的事实。基本假设似乎是“o”将是条目的可分辨名称的一部分，因此几乎没有（如果有的话）理由单独列出它。这确实使跨多个组织（例如，在ISP的目录服务器上）为人们存储信息并在查询细化中使用组织名称变得更加棘手。（Roland Hedberg发现了这个问题，并将其标记给了“inetorgperson”对象类文档的作者）。
The Tagged Index Object ("TIO"), used to carry indexes of WDSP information to the RI, is designed to have record (entry) tags to reduce the number of false positive referrals generated when doing a search in the RI. One of the features of the first index object type, Whois++'s centroid (see [centroid]) was the fact that the index object size did not grow linearly with the size of data indexed -- i.e., at some point the growth of the index object slowed as compared to that of the underlying data set. At first glance, this also seems to be the case for the TIO. However, as the index grows in size the compression factor of the TIO may not achieve the same efficiency as the centroids. One reason for this is that the tagged lists can get quite long, depending on the ordering of the assignment of tags to the underlying data. That is, the tagging as defined allows for a compressed expression of tag "ranges" -- e.g., "1-500" instead of "1,2,3,[...]500". Thus, it might be interesting to explore an optimal "sorting" of underlying data, before applying tags, in order to arrange the most common tokens have consecutive tags (maximal compression of the tag lists). It's not clear if this can be done efficiently over the entire set of records, attributes, and tokens, but it would bear some investigation, to produce the most compressed TIO for transmission.
标记索引对象（“TIO”）用于将WDSP信息的索引传送到RI，其设计为具有记录（条目）标记，以减少在RI中执行搜索时生成的误报转介的数量。第一种索引对象类型Whois++的形心（参见[centroid]）的一个特点是，索引对象的大小并没有随着索引数据的大小而线性增长——即，在某个点上，索引对象的增长比基础数据集的增长慢。乍一看，TIO的情况似乎也是如此。然而，随着指数的增大，TIO的压缩因子可能无法达到与质心相同的效率。这样做的一个原因是，标记列表可能会变得相当长，这取决于标记分配给基础数据的顺序。也就是说，定义的标记允许标记“范围”的压缩表达式——例如，“1-500”而不是“1,2,3，[…]500”。因此，在应用标记之前，探索底层数据的最佳“排序”可能会很有趣，以便将最常见的标记安排为具有连续标记（标记列表的最大压缩）。目前还不清楚是否可以在整个记录、属性和令牌集上有效地执行此操作，但需要进行一些调查，以生成用于传输的最压缩的TIO。
Additionally, in order to make (time) efficient use of the tags in the RI in practice, it is almost necessary to "reinflate" the index object to be able to do joins on tag lists associated with tokens that match. Alternatively, the compressed tag list can be stored, and there is an additional cost associated with comparing the tag lists for matching tokens -- i.e., list comparison operations done outside the scope of a base database management system. There was an unexpected tradeoff to be made.
此外，为了在实践中（时间）有效地使用RI中的标记，几乎有必要“重新调整”索引对象，以便能够在与匹配的标记相关联的标记列表上进行连接。或者，可以存储压缩的标记列表，并且存在与比较标记列表以匹配令牌相关的额外成本——即，在基本数据库管理系统范围之外执行的列表比较操作。有一个意料之外的交易要做。
Mapping of status messages from multiple sub-transactions into a single status communication for the end-user client software became something of a challenge. When chaining a query to multiple WDSPs (though the SAPs), it is not uncommon for at least one of the WDSP servers to return an error code or be unavailable. If one WDSP cannot be reached, out of several referrals, should the client software be given the impression that the query was completed successfully, or not? Most client protocol error handling models are not sophisticated enough to make this level of distinction clear.
将来自多个子事务的状态消息映射到最终用户客户端软件的单个状态通信成为一项挑战。将查询链接到多个WDSP（尽管是SAP）时，至少一个WDSP服务器返回错误代码或不可用的情况并不少见。如果在多个转介中无法联系到一个WDSP，是否应给客户端软件一个查询成功完成的印象？大多数客户端协议错误处理模型都不够复杂，无法清楚地区分这一级别。
When it then was time to test the resulting software with standard commercial client and server software, a few more surprises came to light (primarily in terms of these softwares' expected worldview and occasional implementation shortcuts). Again, more detail is provided in the Appendix, but highlights included client software that could only handle a very small subset of a protocol's defined status message lexicon (e.g., 2 system messages supported), and client software that automatically appended additional terms to a query specified by the user (e.g., adding "or email=<what the user typed in to the query>").
当使用标准的商业客户机和服务器软件测试生成的软件时，更多的惊喜出现了（主要是在这些软件的预期世界观和偶尔的实现快捷方式方面）。同样，附录中提供了更多详细信息，但重点介绍了包含的客户端软件，这些软件只能处理协议定义的状态消息词典的一小部分（例如，支持2条系统消息），以及客户端软件，这些软件会自动向用户指定的查询添加附加术语（例如，添加“或电子邮件=<用户在查询中键入的内容>”）。
One of the things that came to light was that the nature of the index object generated by the WDSPs has an important impact on performance -- both in terms of integrating the index object into the Referral Index, and in terms of efficiency of handling queries. A proposal might be either to define more clearly how the WDSPs should generate the CIP index object (currently left to their discretion), or to alert individual WDSPs when their index objects are considered substandard.
其中一件事情是，WDSP生成的索引对象的性质对性能有着重要的影响——无论是在将索引对象集成到引用索引中，还是在处理查询的效率方面。一个建议可能是更明确地定义WDSP应如何生成CIP索引对象（目前由其自行决定），或者在其索引对象被视为不合格时提醒各个WDSP。
On another front, when chaining referrals to WDSP servers, some servers perform more efficiently than others, affecting the overall response time of the DAG system. From a service point of view, it should also be possible to suggest to WDSP's that are consistently slow (longer than some selected response time) that they are substandard.
另一方面，将引用链接到WDSP服务器时，某些服务器的执行效率高于其他服务器，从而影响DAG系统的总体响应时间。从服务的角度来看，还可以向持续缓慢（超过某些选定响应时间）的WDSP建议其不符合标准。
As described in more detail [complex], there are many factors that can influence the growth factor of index objects (as more data is indexed). That work dealt specifically with tokenized data for Whois++ centroids, and is not immediately generalizable to all forms of the Tagged Index Object. However, the particular structure of the TIO used for the TISDAG project is similar enough in structure to a centroid that the same "order of magnitude" and growth characteristics are applicable.
如更详细[complex]所述，有许多因素会影响索引对象的增长因子（随着索引数据的增加）。这项工作专门处理Whois++质心的标记化数据，并不能立即推广到所有形式的标记索引对象。然而，用于TISDAG项目的TIO的特殊结构在结构上与质心足够相似，因此相同的“数量级”和生长特征适用。
Factors that affects the size of the data ("number of entries"):
影响数据大小的因素（“条目数”）：
. Number of generated tokens The number of tokens generated from the directory data depends on what is tokenized. If data is tokenized on names and addresses (i.e. not unique data like phone numbers) a rough estimation is that the number_of_tokens = 0.2 * number_of_data_records. The growth is linear in the span from a few thousand to at least 1.2 million records. The growth should then level off since the sets of names and addresses are finite, but the current tests have not shown a break point.
. 生成的标记数从目录数据生成的标记数取决于标记化的内容。如果数据是在名称和地址上标记的（即不是唯一的数据，如电话号码），则粗略估计是标记的数量=0.2*数据记录的数量。从几千条记录到至少120万条记录，增长是线性的。由于名称和地址集是有限的，但当前的测试没有显示断点，因此增长应该趋于平稳。
If data is tokenized on something that is unique, e.g. phone numbers, then a rough estimation is that the number_of_tokens = number_of_data_records. Note that it is possible to tokenize in different ways, for example divide the phone numbers in parts. This would result in fewer tokens.
如果数据标记为唯一的数据，例如电话号码，则粗略估计为标记的数量=数据记录的数量。请注意，可以用不同的方式标记，例如将电话号码分成若干部分。这将导致更少的令牌。
. Number of directories Since the tokens are generated individually for each directory, the data size depends on the number of directories. 10 directories with 100.000 records will generate the same amount of tokens as one directory with 1.000.000 records.
. 目录数由于令牌分别为每个目录生成，因此数据大小取决于目录数。10个具有100.000条记录的目录将生成与一个具有1.000.000条记录的目录相同数量的令牌。
Factors that affects the performance ("queries/second"):
影响性能的因素（“查询/秒”）：
. Type of query (exact, substring, etc.) A 'substring' query is slower than an 'exact' query due to: 1) somewhat slower look-up in the internal DAG database than an exact query. 2) Mostly, a larger amount of data is fetched from the internal DAG database due to more hits, which generates more index processing.
. 查询类型（精确、子字符串等）‘子字符串’查询比‘精确’查询慢，原因是：1）内部DAG数据库中的查找比精确查询慢一些。2） 大多数情况下，由于点击次数较多，从内部DAG数据库获取的数据量较大，这会产生更多的索引处理。
3) Substring queries are sent to the directory servers which also results in more hits and more data fetched. The directory servers may also be more or less effective in handling substring queries.
3) 子字符串查询被发送到目录服务器，这也会导致更多点击和获取更多数据。目录服务器在处理子字符串查询时也可能或多或少有效。
. Number of search attributes A query with one or few attributes will most of the time result in many hits, which results in a lot of data, both internally in DAG and from the directory servers. On the other hand, a query with many attributes will result in a somewhat slower look-up in the internal DAG database.
. 搜索属性的数量具有一个或几个属性的查询在大多数情况下都会导致多次点击，从而在DAG内部和目录服务器中产生大量数据。另一方面，具有许多属性的查询将导致在内部DAG数据库中的查找速度稍慢。
. Number of directories A larger number of directories may result in many referrals, but it depends on the query. A simple query will generate a lot of referrals, which means a lot of data from the directories has to be fetched. It will also result in a somewhat slower look-up in the internal DAG database.
. 目录的数量更多的目录可能会导致许多引用，但这取决于查询。一个简单的查询将生成大量的引用，这意味着必须从目录中获取大量数据。这还将导致在内部DAG数据库中的查找速度稍慢。
. Number of chained referrals Queries that are not chained are faster, since the result data does not have to be sent through the DAG system. Chained queries to several directories can be processed in parallel in the SAPs, but all data has to be processed in the CAP before sent to the client.
. 由于结果数据不必通过DAG系统发送，因此未链接的链接引用查询的数量更快。对多个目录的链接查询可以在SAPs中并行处理，但所有数据在发送到客户端之前必须在CAP中处理。
. Response time in the directory servers The response time from the directory servers are of course critical. The total response time for DAG is never faster than the slowest involved directory server.
. 目录服务器的响应时间当然，目录服务器的响应时间至关重要。DAG的总响应时间永远不会比最慢的目录服务器快。
. Number of tokens (size of Tagged Index Objects) The number of tokens has little impact on the look-up time in the internal DAG database.
. 令牌数（标记索引对象的大小）令牌数对内部DAG数据库中的查找时间几乎没有影响。
To date, the TISDAG project has been "alive" for just over two years. During that time, there have been a number of evolutions -- in terms of technologies and ideas outside the project (e.g., user and service provider expectations, deployment of related software, etc) as well as goals and understanding within the scope of the project.
到目前为止，TISDAG项目已经“活跃”了两年多。在此期间，在项目之外的技术和理念（例如，用户和服务提供商的期望、相关软件的部署等）以及项目范围内的目标和理解方面，出现了许多变化。
Chief among these last is the fact that the project set out to primarily fulfill the role of a national referral service, and gradually evolved towards becoming more of a transparent protocol proxy service, fulfilling client queries as completely as possible, within the client protocol's semantics. This evolution was probably
其中最主要的一个事实是，该项目开始主要履行国家转介服务的角色，并逐渐演变为更透明的协议代理服务，在客户端协议的语义范围内尽可能完整地完成客户端查询。这种演变可能是
provoked by a number of reasons -- existing client & server software has a narrower range of accepted (expected) behaviour than their protocol specs may describe, once the technology was there for some proxying, going all the way seemed to be within reach, etc.
原因有很多——现有的客户机和服务器软件的可接受（预期）行为范围比其协议规范所描述的要小，一旦技术在那里进行代理，一路走来似乎触手可及，等等。
>From the point of view of providing a national whitepages service, this is a very positive evolution. However, it did place some strains on the original system architecture, for which some adjustments have been proposed (more detail below). What is less clear is the impact this evolution will have on the flexibility of the system architecture -- in terms of addressing other applications, different protocols (and protocol paradigms), etc. That is, the original intention of the system was to very simply fulfill an unsophisticated role -- "find things that sort of match the input query and let the client itself determine if the match is close enough". As the requirements become more sophisticated, the simplicity of the system is impacted, and perhaps more brittle. (Some proposals for avoiding this are outlined in [DAG++], which attempts to return to the underlying principles and propose steps forward at that level).
>从提供国家白页服务的角度来看，这是一个非常积极的发展。然而，它确实给原始系统架构带来了一些压力，为此提出了一些调整（详情如下）。不太清楚的是，这一演变将对系统架构的灵活性产生影响——在解决其他应用程序、不同协议（和协议范例）等方面。也就是说，系统的初衷是非常简单地完成一个简单的角色--“查找与输入查询匹配的内容，并让客户机自己确定匹配是否足够”。随着需求变得更加复杂，系统的简单性受到影响，甚至可能变得更加脆弱。（关于避免这种情况的一些建议，请参见[DAG++]，试图回到基本原则，并在这一层面上提出前进的步骤）。
In terms of impact within the TISDAG project, this evolution lead to the following technical adjustments:
就TISDAG项目内的影响而言，这一演变导致以下技术调整：
. The latest version of the technical specification makes a distinction (in the internal protocol grammar) between queries directed at the Referral Index, and those passed to SAPs to fulfill a query. This distinction keeps the query-routing queries simple, but allows more sophistication in expressing a query designed to fulfill the client's original semantic expression.
. 最新版本的技术规范（在内部协议语法中）区分了针对引用索引的查询和传递给SAP以完成查询的查询。这种区别使查询路由查询保持简单，但允许更复杂地表达为满足客户机原始语义表达式而设计的查询。
. The additional constraints in the SAP query language is still not enough to allow the internal protocol to express very sophisticated queries. Originally intended only for query-routing queries, the DAG/IP expects all queries to be token-based (whereas LDAP queries are phrase-oriented). This means that SAPs have to do a good deal of "post-pruning" of WDSP result sets to match the DAG/IP query sent by a CAP for query fulfillment. And, CAPs must in turn do more post-pruning to match the DAG/IP results (from the SAPs) to the original query semantics.
. SAP查询语言中的附加约束仍然不足以允许内部协议表达非常复杂的查询。DAG/IP最初只用于查询路由查询，它希望所有查询都基于令牌（而LDAP查询是面向短语的）。这意味着SAP必须对WDSP结果集进行大量的“后期修剪”，以匹配CAP发送的DAG/IP查询以实现查询。而且，CAP必须依次进行更多的后期修剪，以将DAG/IP结果（来自SAPs）与原始查询语义相匹配。
The real strength of the TISDAG project was that it separated the technical framework needed to support the service from the configuration required in order to support a particular application or service -- query & schema mapping, configuration for protocols,
TISDAG项目的真正优势在于它将支持服务所需的技术框架与支持特定应用程序或服务所需的配置分离开来——查询和模式映射、协议配置、，
etc. Future improvements should focus on evolving that framework, maintaining the separation from the specific applications, services, and protocols that may use it.
等。未来的改进应侧重于改进该框架，保持与可能使用该框架的特定应用程序、服务和协议的分离。
The TISDAG project is not alone in attempting to solve the problems of providing coordinated access to resources managed by multiple, disparate services.
TISDAG项目并不是唯一一个试图解决提供对由多个不同服务管理的资源的协调访问的问题的项目。
Described in [NDD], the Norwegian Directory of Directories project also aims to provide necessary infrastructure for a national directory service. It assumes LDAP (v2 or v3) accessibility of WDSP information (provided by the WDSP itself, or through other arrangements), and aims to resolve some of the trickier issues associated with hooking together already-operational LDAP servers into a coherent network: uniform distinguished naming scheme, and content-based referrals. It also addresses some of the pragmatic realities of being compatible with different versions of LDAP clients -- e.g., v2, which does not support referrals, and v3, which does.
如[NDD]所述，挪威目录项目还旨在为国家目录服务提供必要的基础设施。它假定WDSP信息的LDAP（v2或v3）可访问性（由WDSP本身提供，或通过其他安排提供），并旨在解决与将已经运行的LDAP服务器连接到一个一致的网络中相关的一些棘手问题：统一的可分辨命名方案和基于内容的引用。它还解决了与不同版本的LDAP客户端兼容的一些实际问题，例如，v2不支持引用，v3支持引用。
At the heart of the system is the "Referral Index and Organizational information" (RIO) server, which provides a searchable catalogue over Norwegian organization. This facilitates the location of whitepages servers for individual organizations (assuming the query includes information about which organization(s) is(are) interesting).
该系统的核心是“推荐索引和组织信息”（RIO）服务器，该服务器提供挪威组织的可搜索目录。这有助于确定各个组织的whitepages服务器的位置（假设查询包含有关哪些组织感兴趣的信息）。
This work can be seen as being complementary to the TISDAG work, in that it provides a more focused service for integrating LDAP directory servers. However, there is still some requirement that one knows the organization to which a person belongs before doing a search for their e-mail address. This may be reasonable for seeking mail addresses associated with a person's work organization, but is less often successful when it comes to finding a personal e-mail address -- in an age where ISPs abound, a priori knowledge of a user's ISP identification is unlikely.
这项工作可以看作是对TISDAG工作的补充，因为它为集成LDAP目录服务器提供了一个更为集中的服务。但是，在搜索某人的电子邮件地址之前，仍有一些要求，即必须知道此人所属的组织。这对于查找与个人工作组织相关的邮件地址来说可能是合理的，但在查找个人电子邮件地址时往往不太成功——在ISP大量存在的时代，事先了解用户的ISP身份是不可能的。
The EC funded project DESIRE II (http://www.desire.org) is developing a distributed European indexing system for information on Research and Education. The Directory Services work undertaken by DANTE and SURFnet proposes an architecture applied to a server mesh structure to create a wide-area directory service infrastructure.
欧共体资助的DESIRE II项目(http://www.desire.org)正在开发一个分布式欧洲研究和教育信息索引系统。DANTE和SURFnet开展的目录服务工作提出了一种应用于服务器网状结构的体系结构，以创建广域目录服务基础设施。
This service is intended to support both whitepages information with LDAP servers at WDSPs, as well as a Web-search meshes at various places using Whois++ for information about resources and routing of queries to other index-based services.
此服务旨在支持WDSP上LDAP服务器的白页信息，以及使用Whois++在不同位置进行的Web搜索，以获取有关资源的信息以及查询到其他基于索引的服务的路由。
Like the TISDAG project, the DESIRE directory services project aims to act as a focal point for queries, allowing client software to access appropriate resources from a wide range of disparate services.
与TISDAG项目一样，DESIRE目录服务项目旨在充当查询的焦点，允许客户端软件从各种不同的服务中访问适当的资源。
There are architectural differences between the approach used in the TISDAG project and the DESIRE directory service project, but many of the driving needs are the same, and the approach of using content-based indexing and referrals was also selected.
TISDAG项目和DESIRE目录服务项目中使用的方法在体系结构上存在差异，但许多驱动需求是相同的，并且还选择了使用基于内容的索引和引用的方法。
The fun thing with technology is that there are always more tweaks and changes that can be made. However, a service should evolve in response to specific customer needs, and there are several ways in which the TISDAG service itself could advance. Some of them are outlined below, in terms of possibilities perceived at this time, rather than specific recommendations for underlying technology changes that would be necessary to fulfill them. A related topic, networking DAG servers (meshes), is discussed in [DAG-Mesh].
技术的有趣之处在于，总是可以进行更多的调整和更改。然而，服务应该根据特定的客户需求而发展，TISDAG服务本身可以通过几种方式来发展。以下概述了其中一些问题，这些问题是根据目前所感知到的可能性，而不是针对实现这些问题所需的基础技术变革的具体建议。[DAG Mesh]中讨论了一个相关主题，即网络DAG服务器（Mesh）。
There is a need for security considerations when making use of a wide-scaled directory system in other application areas than the public white-pages application of the TISDAG project. There are issues whether the directory service is distributed across the Internet, or even if it functions completely within an internal, closed network.
在TISDAG项目的公共白页应用程序以外的其他应用程序领域使用大规模目录系统时，需要考虑安全性。目录服务是否分布在Internet上，甚至是否完全在内部封闭网络中运行，都存在一些问题。
Today the DAG system makes use of 2 information schemas -- the DAGPERSON schema for information about specific people, and the DAGORGROLE schema for organizational roles. The technical specification includes a definition of the schema, as well as an understood mapping to (and from) some standard schemas used in the supported protocols. Nevertheless, to include new WDSPs which may not have all attributes in schemas, may use different schemas as well as query attributes, it should be possible to provide creation and use of new customized/standardized schemas and perform schema mapping if it's necessary. It might also be possible to constrain queries to desired query attributes, templates, or object classes.
今天，DAG系统使用了两种信息模式——用于特定人员信息的DAGPERSON模式和用于组织角色的DAGORGROLE模式。技术规范包括模式的定义，以及与支持协议中使用的一些标准模式之间的映射。尽管如此，为了包括可能在模式中没有所有属性、可能使用不同模式以及查询属性的新WDSP，应该可以提供新定制/标准化模式的创建和使用，并在必要时执行模式映射。还可以将查询约束到所需的查询属性、模板或对象类。
In practice, this means that different WDSP's may choose to use different subparts of one defined schema, or even implement local customizations.
实际上，这意味着不同的WDSP可以选择使用一个已定义模式的不同子部分，甚至实现本地定制。
Although fewer people now hold out the hope of a unified global directory service, based on standardize protocols, it is interesting to see more projects providing infrastructure that permits unified access to what is otherwise an unforgivingly diverse and dislocated set of information servers. What cannot be dictated (in standardized protocols and schemas) may yet be accommodated through service infrastructure. The right approach seems to be to build better and better frameworks for supporting such diversified services, without making the framework architecture dependent on specific technologies.
尽管现在越来越少的人希望基于标准化协议实现统一的全球目录服务，但有趣的是，越来越多的项目提供了基础设施，允许统一访问一组不可饶恕的多样化和混乱的信息服务器。无法规定的内容（在标准化协议和模式中）仍然可以通过服务基础设施进行调整。正确的方法似乎是构建越来越好的框架来支持这种多样化的服务，而不是让框架架构依赖于特定的技术。
To date, the TISDAG project has focused on serving only publicly-sharable information. As noted in Section 4.1, any future work will have to provide additional facilities for providing authentication, authorization, encryption, and otherwise handling sensitive data in an open environment.
迄今为止，TISDAG项目的重点是只提供可公开共享的信息。如第4.1节所述，任何未来的工作都必须提供额外的设施，以便在开放环境中提供身份验证、授权、加密和以其他方式处理敏感数据。
This document outlines the perspectives and opinions of the authors, based on experience as well as many fruitful and enlightening discussions with others: Roland Hedberg, Torbjorn Granat, Patrik Granholm, Rikard Wessblad and Sandro Mazzucato.
本文件概述了作者的观点和观点，这些观点和观点基于经验以及与其他人进行的许多富有成果和启发性的讨论：罗兰·赫德伯格、托尔比约恩·格拉纳特、帕特里克·格兰霍姆、里卡德·韦斯布拉德和桑德罗·马祖卡托。
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
Thommy Eklof Hotsip AB
托米·埃克洛夫酒店
EMail: thommy.eklof@hotsip.com
EMail: thommy.eklof@hotsip.com
Leslie L. Daigle Thinking Cat Enterprises
莱斯利·L·戴格尔思维猫企业
EMail: leslie@thinkingcat.com
EMail: leslie@thinkingcat.com
Request For Comments (RFC) and Internet Draft documents are available from numerous mirror sites.
许多镜像站点都提供了征求意见（RFC）和互联网草稿文档。
[CIP1] Allen, J. and M. Mealling, "The Architecture of the Common Indexing Protocol (CIP)", RFC 2651, August 1999.
[CIP1]Allen，J.和M.Melling，“公共索引协议（CIP）的架构”，RFC 26511999年8月。
[CIP2] Allen, J. and M. Mealling, "MIME Object Definitions for the Common Indexing Protocol (CIP)", RFC 2652, August 1999.
[CIP2]Allen，J.和M.Mealling，“通用索引协议（CIP）的MIME对象定义”，RFC 2652，1999年8月。
[CIP3] Allen, J., Leach, P. and R. Hedberg, "CIP Transport Protocols", RFC 2653, August 1999.
[CIP3]Allen，J.，Leach，P.和R.Hedberg，“CIP传输协议”，RFC 2653，1999年8月。
[DAG++] Daigle, L. and T. Eklof, "An Architecture for Integrated Directory Services", RFC 2970, October 2000.
[DAG++]Daigle，L.和T.Eklof，“集成目录服务的体系结构”，RFC 29702000年10月。
[DAG-Mesh] Daigle, L. and T. Eklof, "Networking Multiple DAG servers: Meshes", RFC 2968, October 2000.
[DAG Mesh]Daigle，L.和T.Eklof，“将多个DAG服务器联网：Mesh”，RFC 2968，2000年10月。
[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月。
[centroid] Deutsch, P., Schoultz, R., Faltstrom, P. and C. Weider, "Architecture of the WHOIS++ service", RFC 1835, August 1995.
[质心]Deutsch，P.，Schoultz，R.，Faltstrom，P.和C.Weider，“WHOIS++服务的体系结构”，RFC 18351995年8月。
[NDD] Hedberg, R. and H. Alvestrand, "Technical Specification, The Norwegian Directory of Directories (NDD)", Work in Progress.
[NDD]Hedberg，R.和H.Alvestrand，“技术规范，挪威目录目录（NDD）”，正在进行的工作。
[TIO] Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A Tagged Index Object for use in the Common Indexing Protocol", RFC 2654, August 1999.
[TIO]Hedberg，R.，Greenblatt，B.，Moats，R.和M.Wahl，“通用索引协议中使用的标记索引对象”，RFC 2654，1999年8月。
[complex] P. Panotzki, "Complexity of the Common Indexing Protocol: Predicting Search Times in Index Server Meshes", Master's Thesis, KTH, September 1996.
[complex]P.Panotzki，“通用索引协议的复杂性：预测索引服务器网格中的搜索时间”，硕士论文，KTH，1996年9月。
[WAP] The Wireless Application Protocol, http://www.wapforum.org
[WAP] The Wireless Application Protocol, http://www.wapforum.org
Appendix -- Specific Software Issues and Deployment Experiences
附录—特定软件问题和部署经验
The following paragraphs outline practical deployment experiences in an anecdotal fashion. This is not meant to be construed as an exhaustive, authoritative evaluation of existing client software, but rather an indication of the types of challenges the average implementation team may expect to encounter in a development and deployment effort.
以下段落以轶事的方式概述了实际部署经验。这并不意味着要解释为对现有客户机软件的详尽、权威的评估，而是对一般实施团队在开发和部署工作中可能遇到的挑战类型的指示。
Character encoding
------------------
One client's addressbook sends iso-8859 encoding (depending on the
font configuration in the browser) when querying a directory server
but the directory server responds with Unicode (UTF-8) encoding.
This means that the LDAP CAP would have to handle different character
set encodings for request and response.
Character encoding
------------------
One client's addressbook sends iso-8859 encoding (depending on the
font configuration in the browser) when querying a directory server
but the directory server responds with Unicode (UTF-8) encoding.
This means that the LDAP CAP would have to handle different character
set encodings for request and response.
Referrals
---------
Today there appears to be only one commercial addressbook supporting
LDAPv3. All the others support only LDAPv2. However, this LDAPv3
client software does not handle referrals correctly -- the client
couldn't handle server the result contains "response code 10"
(designated for referrals). From what was observed, there was now
way for the client or the end-user to decide if, or which, referrals
to follow-up. It is therefore not clear how the LDAP clients handle
a combination of both referrals and results -- but the supposition
is that it doesn't work.
Referrals
---------
Today there appears to be only one commercial addressbook supporting
LDAPv3. All the others support only LDAPv2. However, this LDAPv3
client software does not handle referrals correctly -- the client
couldn't handle server the result contains "response code 10"
(designated for referrals). From what was observed, there was now
way for the client or the end-user to decide if, or which, referrals
to follow-up. It is therefore not clear how the LDAP clients handle
a combination of both referrals and results -- but the supposition
is that it doesn't work.
Objectclasses in LDAP
---------------------
No objectclass is defined in the query to the DAG-system from the
LDAP-clients. This means that the DAG-system doesn't see any
differences between "inetOrgPerson" and "organisationalRole" when
attribute "cn" is representing both "name" and "role". This is not
so much a problem as that it has interesting side effects. Namely,
although most directory user interfaces (found in browsers, mail
programs) claim only to support person-related queries, in practise a
user of the client could use the interface to send a query with role
in the name entry.
Objectclasses in LDAP
---------------------
No objectclass is defined in the query to the DAG-system from the
LDAP-clients. This means that the DAG-system doesn't see any
differences between "inetOrgPerson" and "organisationalRole" when
attribute "cn" is representing both "name" and "role". This is not
so much a problem as that it has interesting side effects. Namely,
although most directory user interfaces (found in browsers, mail
programs) claim only to support person-related queries, in practise a
user of the client could use the interface to send a query with role
in the name entry.
Query with attribute Organisation
---------------------------------
It is possible to send a query with attribute "organisation" but it
would result in no hits because of that the organisation attribute is
not included in the objectclass "inetOrgPerson". Roland Hedberg has
proposed a change for the latest release of the objectclass
definition document.
Query with attribute Organisation
---------------------------------
It is possible to send a query with attribute "organisation" but it
would result in no hits because of that the organisation attribute is
not included in the objectclass "inetOrgPerson". Roland Hedberg has
proposed a change for the latest release of the objectclass
definition document.
To provide the desired ability to narrow search focus to some range of organization names (attribute values), there are three possible approaches with differing merits/detractions:
为了提供所需的能力，将搜索焦点缩小到组织名称（属性值）的某个范围，有三种可能的方法，各有优缺点：
Recommend the use of the "locality" attribute -- although a more standard definition would be required (locality is currently used for everything from organization to county to map coordinates).
建议使用“Location”属性——尽管需要更标准的定义（Location目前用于从组织到县到地图坐标的所有方面）。
Recommend or require that the attribute organisation should be inherited in objectclass "inetOrgPerson".
建议或要求在objectclass“inetOrgPerson”中继承属性Organization。
Build the LDAP DAG-SAP to submit 2 query to the WDSP. The second is the same as the first, with only cn filters if the entire query including "o" results in no hits (i.e., back off from the organization filtering if it doesn't seem to be supported).
构建LDAP DAG-SAP以向WDSP提交2个查询。第二种方法与第一种方法相同，如果包含“o”的整个查询没有命中，则只使用cn过滤器（即，如果不支持组织过滤，则退出组织过滤）。
Configuration
-------------
It is not possible to see what character set a LDAP clients want to
use. The recommendation so far in he project has been to define a
unique port for each character set. This requires extra end-user
configuration of client software, and proper advertising of the port
number-charset mapping provided in the service.
Configuration
-------------
It is not possible to see what character set a LDAP clients want to
use. The recommendation so far in he project has been to define a
unique port for each character set. This requires extra end-user
configuration of client software, and proper advertising of the port
number-charset mapping provided in the service.
DN -- When the user wants to look-up more information about a person found in a preliminary search, the LDAP client uses the entry's DN together with host and port to the DAG system. Not only does that mean that the client submits a non-compliant query to the DAG system, as DNs are not part of any of the defined queries for the service, it simply does not provide the desired effect of getting to the user's entry.
DN——当用户想要查找有关在初步搜索中找到的人的更多信息时，LDAP客户端将使用条目的DN以及DAG系统的主机和端口。这不仅意味着客户端向DAG系统提交一个不符合要求的查询，因为DNs不是服务的任何已定义查询的一部分，它根本无法提供访问用户条目的预期效果。
Response Codes
--------------
The LDAPv3 client that was used does not support more than 2 response
codes -- "success" and "size limit exceeded". All the other response
codes are translated to "size limit exceeded", although no results
are returned. That is, if the error was in fact that the size limit
was exceeded, the results up to the size limit are presented. If it
was another response code mapped to that one, no results are
presented.
Response Codes
--------------
The LDAPv3 client that was used does not support more than 2 response
codes -- "success" and "size limit exceeded". All the other response
codes are translated to "size limit exceeded", although no results
are returned. That is, if the error was in fact that the size limit
was exceeded, the results up to the size limit are presented. If it
was another response code mapped to that one, no results are
presented.
Sending and loading CIP Index Objects
-------------------------------------
At least one server is quoting the CIP-object incorrectly for the
Swedish characters A-Ring, A-Umlaut and O-Umlaut. Sending quoted
printable CIP-objects with PINE mail software works.
Sending and loading CIP Index Objects
-------------------------------------
At least one server is quoting the CIP-object incorrectly for the
Swedish characters A-Ring, A-Umlaut and O-Umlaut. Sending quoted
printable CIP-objects with PINE mail software works.
Source - Labeled URI
--------------------
The original plan for the use of the labeled-URI attribute was to use
it to return a pointer to the WDSP that provided the user
information. However, the standard use of the labeled-URI attribute,
which may in fact be populated in the data returned by a WDSP, is to
contain the URI for more private related homepages.
Source - Labeled URI
--------------------
The original plan for the use of the labeled-URI attribute was to use
it to return a pointer to the WDSP that provided the user
information. However, the standard use of the labeled-URI attribute,
which may in fact be populated in the data returned by a WDSP, is to
contain the URI for more private related homepages.
Full Copyright Statement
完整版权声明
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编辑功能的资金目前由互联网协会提供。