Network Working Group L. Daigle
Request for Comments: 2967 Thinking Cat Enterprises
Category: Informational R. Hedberg
Catalogix
October 2000
Network Working Group L. Daigle
Request for Comments: 2967 Thinking Cat Enterprises
Category: Informational R. Hedberg
Catalogix
October 2000
TISDAG - Technical Infrastructure for Swedish Directory Access Gateways
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 strength of the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) project's DAG proposal is that it defines the necessary technical infrastructure to provide a single-access-point service for information on Swedish Internet users. The resulting service will provide uniform access for all information -- the same level of access to information (7x24 service), and the same information made available, irrespective of the service provider responsible for maintaining that information, their directory service protocols, or the end-user's client access protocol.
TISDAG（瑞典目录访问网关技术基础设施）项目的DAG提案的优势在于，它定义了必要的技术基础设施，为瑞典互联网用户的信息提供单一访问点服务。由此产生的服务将为所有信息提供统一的访问——相同级别的信息访问（7x24服务），以及相同的可用信息，而不管负责维护该信息的服务提供商、其目录服务协议或最终用户的客户端访问协议如何。
Table of Contents
目录
1.0 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Project Goal. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Executive Summary of Technical Study Result . . . . . . . . . 5
1.3 Document Overview . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.0 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 End-User Requirements . . . . . . . . . . . . . . . . . . . . 8
2.2 WDSPs Requirements. . . . . . . . . . . . . . . . . . . . . . 8
2.3 DAG-System Requirements . . . . . . . . . . . . . . . . . . . 9
3.0 Functional Specification. . . . . . . . . . . . . . . . . . . 9
3.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 The DAG Core. . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Client Interface. . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1 Acceptable User Input . . . . . . . . . . . . . . . . . . . 12
1.0 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Project Goal. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Executive Summary of Technical Study Result . . . . . . . . . 5
1.3 Document Overview . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.0 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 End-User Requirements . . . . . . . . . . . . . . . . . . . . 8
2.2 WDSPs Requirements. . . . . . . . . . . . . . . . . . . . . . 8
2.3 DAG-System Requirements . . . . . . . . . . . . . . . . . . . 9
3.0 Functional Specification. . . . . . . . . . . . . . . . . . . 9
3.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 The DAG Core. . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Client Interface. . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1 Acceptable User Input . . . . . . . . . . . . . . . . . . . 12
Supported Query Types. . . . . . . . . . . . . . . . . . . . . 12
Matching Semantics . . . . . . . . . . . . . . . . . . . . . . 12
Character Sets . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.2 Data Output Spec. . . . . . . . . . . . . . . . . . . . . . 14
Schema Definition. . . . . . . . . . . . . . . . . . . . . . . 14
Referral Definition. . . . . . . . . . . . . . . . . . . . . . 14
Error conditions . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Directory Server Interface. . . . . . . . . . . . . . . . . . 14
4.0 Architecture. . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1 Software Components . . . . . . . . . . . . . . . . . . . . . 15
4.1.1 Internal Communications . . . . . . . . . . . . . . . . . . 15
4.1.2 Referral Index. . . . . . . . . . . . . . . . . . . . . . . 15
4.1.3 DAG-CAPs. . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.4 DAG-SAPs. . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Important Architectural Notes . . . . . . . . . . . . . . . . 17
4.2.1 2 Distinct Functions: Referrals and Chaining . . . . . . . 17
4.2.2 Limited Query and Response Semantics. . . . . . . . . . . . 17
4.2.3 Visibility. . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.4 Richness of Query semantics . . . . . . . . . . . . . . . . 18
4.2.5 N+M Protocol Mappings . . . . . . . . . . . . . . . . . . . 18
4.2.6 DAG-CAPs and DAG-SAPs are completely independent of each
other. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.7 The Role of the DAG-CAP . . . . . . . . . . . . . . . . . . 18
4.2.8 The Role of the DAG-SAP . . . . . . . . . . . . . . . . . . 19
4.2.9 DAG/IP is internal. . . . . . . . . . . . . . . . . . . . . 19
4.2.10 Expectations . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.11 Future Extensions. . . . . . . . . . . . . . . . . . . . . 19
5.0 Software Specifications . . . . . . . . . . . . . . . . . . . 19
5.1 Notational Convention . . . . . . . . . . . . . . . . . . . . 19
5.2 DAG-CAP Basics. . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.3 Error handling. . . . . . . . . . . . . . . . . . . . . . . 21
5.2.4 Pruning of results. . . . . . . . . . . . . . . . . . . . . 22
5.3 DAG-SAP Basics. . . . . . . . . . . . . . . . . . . . . . . . 22
5.3.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . 22
5.3.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . 23
5.3.3 Error handling. . . . . . . . . . . . . . . . . . . . . . . 23
5.3.4 Pruning of results. . . . . . . . . . . . . . . . . . . . . 23
5.3.5 Constraint precedence . . . . . . . . . . . . . . . . . . . 23
5.4 The Referral Index. . . . . . . . . . . . . . . . . . . . . . 24
5.4.1 Architecture. . . . . . . . . . . . . . . . . . . . . . . . 24
5.4.2 Interactions with WDSPs (CIP) . . . . . . . . . . . . . . . 24
5.4.3 Index Object Format . . . . . . . . . . . . . . . . . . . . 24
5.4.4 DAG-Internal I/O. . . . . . . . . . . . . . . . . . . . . . 24
5.4.5 The Index Server. . . . . . . . . . . . . . . . . . . . . . 24
5.4.6 Configuration . . . . . . . . . . . . . . . . . . . . . . . 25
5.4.7 Security. . . . . . . . . . . . . . . . . . . . . . . . . . 25
Supported Query Types. . . . . . . . . . . . . . . . . . . . . 12
Matching Semantics . . . . . . . . . . . . . . . . . . . . . . 12
Character Sets . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.2 Data Output Spec. . . . . . . . . . . . . . . . . . . . . . 14
Schema Definition. . . . . . . . . . . . . . . . . . . . . . . 14
Referral Definition. . . . . . . . . . . . . . . . . . . . . . 14
Error conditions . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Directory Server Interface. . . . . . . . . . . . . . . . . . 14
4.0 Architecture. . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1 Software Components . . . . . . . . . . . . . . . . . . . . . 15
4.1.1 Internal Communications . . . . . . . . . . . . . . . . . . 15
4.1.2 Referral Index. . . . . . . . . . . . . . . . . . . . . . . 15
4.1.3 DAG-CAPs. . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.4 DAG-SAPs. . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Important Architectural Notes . . . . . . . . . . . . . . . . 17
4.2.1 2 Distinct Functions: Referrals and Chaining . . . . . . . 17
4.2.2 Limited Query and Response Semantics. . . . . . . . . . . . 17
4.2.3 Visibility. . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.4 Richness of Query semantics . . . . . . . . . . . . . . . . 18
4.2.5 N+M Protocol Mappings . . . . . . . . . . . . . . . . . . . 18
4.2.6 DAG-CAPs and DAG-SAPs are completely independent of each
other. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.7 The Role of the DAG-CAP . . . . . . . . . . . . . . . . . . 18
4.2.8 The Role of the DAG-SAP . . . . . . . . . . . . . . . . . . 19
4.2.9 DAG/IP is internal. . . . . . . . . . . . . . . . . . . . . 19
4.2.10 Expectations . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.11 Future Extensions. . . . . . . . . . . . . . . . . . . . . 19
5.0 Software Specifications . . . . . . . . . . . . . . . . . . . 19
5.1 Notational Convention . . . . . . . . . . . . . . . . . . . . 19
5.2 DAG-CAP Basics. . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.3 Error handling. . . . . . . . . . . . . . . . . . . . . . . 21
5.2.4 Pruning of results. . . . . . . . . . . . . . . . . . . . . 22
5.3 DAG-SAP Basics. . . . . . . . . . . . . . . . . . . . . . . . 22
5.3.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . 22
5.3.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . 23
5.3.3 Error handling. . . . . . . . . . . . . . . . . . . . . . . 23
5.3.4 Pruning of results. . . . . . . . . . . . . . . . . . . . . 23
5.3.5 Constraint precedence . . . . . . . . . . . . . . . . . . . 23
5.4 The Referral Index. . . . . . . . . . . . . . . . . . . . . . 24
5.4.1 Architecture. . . . . . . . . . . . . . . . . . . . . . . . 24
5.4.2 Interactions with WDSPs (CIP) . . . . . . . . . . . . . . . 24
5.4.3 Index Object Format . . . . . . . . . . . . . . . . . . . . 24
5.4.4 DAG-Internal I/O. . . . . . . . . . . . . . . . . . . . . . 24
5.4.5 The Index Server. . . . . . . . . . . . . . . . . . . . . . 24
5.4.6 Configuration . . . . . . . . . . . . . . . . . . . . . . . 25
5.4.7 Security. . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.5 Mail (SMTP) DAG-CAP . . . . . . . . . . . . . . . . . . . . . 25
5.5.1 Mail DAG-CAP Input. . . . . . . . . . . . . . . . . . . . . 26
5.5.2 Translation from Mail query to DAG/IP . . . . . . . . . . . 28
Querying the Referral Index. . . . . . . . . . . . . . . . . . 28
Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 29
5.5.3 Chaining queries in Mail DAG-CAP. . . . . . . . . . . . . . 31
5.5.4 Expression of results in Mail DAG-CAP . . . . . . . . . . . 31
5.5.5 Expression of Errors in Mail DAG-CAP. . . . . . . . . . . . 31
5.6 Web (HTTP) DAG-CAP. . . . . . . . . . . . . . . . . . . . . . 32
5.6.1 Web DAG-CAP Input . . . . . . . . . . . . . . . . . . . . . 32
5.6.2 Translation from Web query to DAG/IP. . . . . . . . . . . . 33
Querying a DAG-SAP Directly. . . . . . . . . . . . . . . . . . 33
Querying the Referral Index. . . . . . . . . . . . . . . . . . 33
Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 35
5.6.3 Chaining queries in Web DAG-CAP . . . . . . . . . . . . . . 36
5.6.4 Expression of results in Web DAG-CAP. . . . . . . . . . . . 36
text/html results. . . . . . . . . . . . . . . . . . . . . . . 36
application/whoispp-response Results . . . . . . . . . . . . . 37
5.6.5 Expression of Errors in Web DAG-CAP . . . . . . . . . . . . 37
Standard Errors. . . . . . . . . . . . . . . . . . . . . . . . 38
5.7 Whois++ DAG-CAP . . . . . . . . . . . . . . . . . . . . . . . 38
5.7.1 Whois++ DAG-CAP Input . . . . . . . . . . . . . . . . . . . 38
5.7.2 Translation from Whois++ query to DAG/IP. . . . . . . . . . 39
Querying the Referral Index. . . . . . . . . . . . . . . . . . 39
Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 39
5.7.3 Chaining in Whois++ DAG-CAP . . . . . . . . . . . . . . . . 40
5.7.4 Expression of results in Whois++. . . . . . . . . . . . . . 41
5.7.5 Expression of Errors in Whois++ DAG-CAP . . . . . . . . . . 41
5.8 LDAPv2 DAG-CAP. . . . . . . . . . . . . . . . . . . . . . . . 42
5.8.1 LDAPv2 DAG-CAP Input. . . . . . . . . . . . . . . . . . . . 42
5.8.2 Translation from LDAPv2 query to DAG/IP . . . . . . . . . . 44
Querying the Referral Index. . . . . . . . . . . . . . . . . . 44
Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 46
5.8.3 Chaining queries in LDAPv2 DAG-CAP. . . . . . . . . . . . . 48
5.8.4 Expression of results in LDAPv2 . . . . . . . . . . . . . . 48
5.8.5 Expression of Errors in LDAPv2 DAG-CAP. . . . . . . . . . . 48
5.9 LDAPv3 DAG-CAP. . . . . . . . . . . . . . . . . . . . . . . . 50
5.9.1 LDAPv3 DAG-CAP Input. . . . . . . . . . . . . . . . . . . . 50
5.9.2 Translation from LDAPv3 query to DAG/IP . . . . . . . . . . 51
Querying the Referral Index. . . . . . . . . . . . . . . . . . 51
Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 54
5.9.3 Chaining queries in LDAPv3 DAG-CAP. . . . . . . . . . . . . 55
5.9.4 Expression of results in LDAPv3 . . . . . . . . . . . . . . 55
5.9.5 Expression of Errors in LDAPv3 DAG-CAP. . . . . . . . . . . 56
5.10 Whois++ DAG-SAP. . . . . . . . . . . . . . . . . . . . . . . 57
5.10.1 Input. . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.10.2 Translation from DAG/IP to Whois++ query . . . . . . . . . 58
5.10.3 Translation of Whois++ results to DAG/IP . . . . . . . . . 58
5.5 Mail (SMTP) DAG-CAP . . . . . . . . . . . . . . . . . . . . . 25
5.5.1 Mail DAG-CAP Input. . . . . . . . . . . . . . . . . . . . . 26
5.5.2 Translation from Mail query to DAG/IP . . . . . . . . . . . 28
Querying the Referral Index. . . . . . . . . . . . . . . . . . 28
Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 29
5.5.3 Chaining queries in Mail DAG-CAP. . . . . . . . . . . . . . 31
5.5.4 Expression of results in Mail DAG-CAP . . . . . . . . . . . 31
5.5.5 Expression of Errors in Mail DAG-CAP. . . . . . . . . . . . 31
5.6 Web (HTTP) DAG-CAP. . . . . . . . . . . . . . . . . . . . . . 32
5.6.1 Web DAG-CAP Input . . . . . . . . . . . . . . . . . . . . . 32
5.6.2 Translation from Web query to DAG/IP. . . . . . . . . . . . 33
Querying a DAG-SAP Directly. . . . . . . . . . . . . . . . . . 33
Querying the Referral Index. . . . . . . . . . . . . . . . . . 33
Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 35
5.6.3 Chaining queries in Web DAG-CAP . . . . . . . . . . . . . . 36
5.6.4 Expression of results in Web DAG-CAP. . . . . . . . . . . . 36
text/html results. . . . . . . . . . . . . . . . . . . . . . . 36
application/whoispp-response Results . . . . . . . . . . . . . 37
5.6.5 Expression of Errors in Web DAG-CAP . . . . . . . . . . . . 37
Standard Errors. . . . . . . . . . . . . . . . . . . . . . . . 38
5.7 Whois++ DAG-CAP . . . . . . . . . . . . . . . . . . . . . . . 38
5.7.1 Whois++ DAG-CAP Input . . . . . . . . . . . . . . . . . . . 38
5.7.2 Translation from Whois++ query to DAG/IP. . . . . . . . . . 39
Querying the Referral Index. . . . . . . . . . . . . . . . . . 39
Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 39
5.7.3 Chaining in Whois++ DAG-CAP . . . . . . . . . . . . . . . . 40
5.7.4 Expression of results in Whois++. . . . . . . . . . . . . . 41
5.7.5 Expression of Errors in Whois++ DAG-CAP . . . . . . . . . . 41
5.8 LDAPv2 DAG-CAP. . . . . . . . . . . . . . . . . . . . . . . . 42
5.8.1 LDAPv2 DAG-CAP Input. . . . . . . . . . . . . . . . . . . . 42
5.8.2 Translation from LDAPv2 query to DAG/IP . . . . . . . . . . 44
Querying the Referral Index. . . . . . . . . . . . . . . . . . 44
Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 46
5.8.3 Chaining queries in LDAPv2 DAG-CAP. . . . . . . . . . . . . 48
5.8.4 Expression of results in LDAPv2 . . . . . . . . . . . . . . 48
5.8.5 Expression of Errors in LDAPv2 DAG-CAP. . . . . . . . . . . 48
5.9 LDAPv3 DAG-CAP. . . . . . . . . . . . . . . . . . . . . . . . 50
5.9.1 LDAPv3 DAG-CAP Input. . . . . . . . . . . . . . . . . . . . 50
5.9.2 Translation from LDAPv3 query to DAG/IP . . . . . . . . . . 51
Querying the Referral Index. . . . . . . . . . . . . . . . . . 51
Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 54
5.9.3 Chaining queries in LDAPv3 DAG-CAP. . . . . . . . . . . . . 55
5.9.4 Expression of results in LDAPv3 . . . . . . . . . . . . . . 55
5.9.5 Expression of Errors in LDAPv3 DAG-CAP. . . . . . . . . . . 56
5.10 Whois++ DAG-SAP. . . . . . . . . . . . . . . . . . . . . . . 57
5.10.1 Input. . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.10.2 Translation from DAG/IP to Whois++ query . . . . . . . . . 58
5.10.3 Translation of Whois++ results to DAG/IP . . . . . . . . . 58
5.11 LDAPv2 DAG-SAP . . . . . . . . . . . . . . . . . . . . . . . 59
5.11.1 Input. . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.11.2 Translation from DAG/IP to LDAPv2 query. . . . . . . . . . 59
5.11.3 Translation of LDAPv2 results to DAG/IP. . . . . . . . . . 61
5.12 LDAPv3 DAG-SAP . . . . . . . . . . . . . . . . . . . . . . . 62
5.12.1 Input. . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.12.2 Translation from DAG/IP to LDAPv3 query. . . . . . . . . . 62
5.12.3 Translation of LDAPv3 results to DAG/IP. . . . . . . . . . 64
5.13 Example Queries. . . . . . . . . . . . . . . . . . . . . . . 64
5.13.1 A Whois++ Query. . . . . . . . . . . . . . . . . . . . . . 65
What the Whois++ DAG-CAP Receives. . . . . . . . . . . . . . . 65
What the Whois++ DAG-CAP sends to the Referral Index . . . . . 65
What the Whois++ DAG-CAP Sends to an LDAP DAG-SAP. . . . . . . 65
5.13.2 An LDAP Query. . . . . . . . . . . . . . . . . . . . . . . 66
What the LDAP DAG-CAP Receives . . . . . . . . . . . . . . . . 66
5.13.3 What the LDAP DAG-CAP sends to the Referral Index. . . . . 67
What the LDAP DAG-CAP Sends to a Whois++ DAG-SAP . . . . . . . 67
What the LDAP DAG-CAP Sends to an LDAP DAG-SAP . . . . . . . . 68
6.0 Service Specifications. . . . . . . . . . . . . . . . . . . . 68
6.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.2 WDSP Participation. . . . . . . . . . . . . . . . . . . . . . 69
6.3 Load Distribution . . . . . . . . . . . . . . . . . . . . . . 69
6.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 72
7.0 Security. . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.1 Information credibility . . . . . . . . . . . . . . . . . . . 73
7.2 Unauthorized access . . . . . . . . . . . . . . . . . . . . . 73
8.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 74
Appendix A - DAG Schema Definitions . . . . . . . . . . . . . . . 75
A.1 DAG Personal Information Schema (DAGPERSON Schema). . . . . . 76
A.2 DAG Organizational Role Information Schema (DAGORGROLE
Schema). . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Appendix B - Schema Mappings for Whois++ and LDAP . . . . . . . . 77
B.1 LDAP and the DAG Schemas. . . . . . . . . . . . . . . . . . . 78
B.2 Whois++ and the DAG Schemas . . . . . . . . . . . . . . . . . 81
Appendix C - DAG-Internal Protocol (DAG/IP) . . . . . . . . . . . 82
C.1 A word on the choice of DAG/IP. . . . . . . . . . . . . . . . 83
C.2 DAG/IP Input and Output -- Overview . . . . . . . . . . . . . 83
C.3 BNF for DAG/IP input and output . . . . . . . . . . . . . . . 83
C.3.1 The DAG/IP Input Grammar. . . . . . . . . . . . . . . . . . 84
C.3.2 The DAG/IP Response Grammar . . . . . . . . . . . . . . . . 87
C.4 DAG/IP Response Messages. . . . . . . . . . . . . . . . . . . 89
Appendix D - DAG/IP Response Messages Mapping . . . . . . . . . . 93
Appendix E - DAG CIP Usage. . . . . . . . . . . . . . . . . . . . 95
E.1 CIP Index Object. . . . . . . . . . . . . . . . . . . . . . . 95
E.2 CIP Index Object Creation . . . . . . . . . . . . . . . . . . 97
E.3 CIP Index Object Sharing. . . . . . . . . . . . . . . . . . . 98
E.3.1 Registration of Servers . . . . . . . . . . . . . . . . . . 98
E.3.2 Transmission of Objects . . . . . . . . . . . . . . . . . .100
5.11 LDAPv2 DAG-SAP . . . . . . . . . . . . . . . . . . . . . . . 59
5.11.1 Input. . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.11.2 Translation from DAG/IP to LDAPv2 query. . . . . . . . . . 59
5.11.3 Translation of LDAPv2 results to DAG/IP. . . . . . . . . . 61
5.12 LDAPv3 DAG-SAP . . . . . . . . . . . . . . . . . . . . . . . 62
5.12.1 Input. . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.12.2 Translation from DAG/IP to LDAPv3 query. . . . . . . . . . 62
5.12.3 Translation of LDAPv3 results to DAG/IP. . . . . . . . . . 64
5.13 Example Queries. . . . . . . . . . . . . . . . . . . . . . . 64
5.13.1 A Whois++ Query. . . . . . . . . . . . . . . . . . . . . . 65
What the Whois++ DAG-CAP Receives. . . . . . . . . . . . . . . 65
What the Whois++ DAG-CAP sends to the Referral Index . . . . . 65
What the Whois++ DAG-CAP Sends to an LDAP DAG-SAP. . . . . . . 65
5.13.2 An LDAP Query. . . . . . . . . . . . . . . . . . . . . . . 66
What the LDAP DAG-CAP Receives . . . . . . . . . . . . . . . . 66
5.13.3 What the LDAP DAG-CAP sends to the Referral Index. . . . . 67
What the LDAP DAG-CAP Sends to a Whois++ DAG-SAP . . . . . . . 67
What the LDAP DAG-CAP Sends to an LDAP DAG-SAP . . . . . . . . 68
6.0 Service Specifications. . . . . . . . . . . . . . . . . . . . 68
6.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.2 WDSP Participation. . . . . . . . . . . . . . . . . . . . . . 69
6.3 Load Distribution . . . . . . . . . . . . . . . . . . . . . . 69
6.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 72
7.0 Security. . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.1 Information credibility . . . . . . . . . . . . . . . . . . . 73
7.2 Unauthorized access . . . . . . . . . . . . . . . . . . . . . 73
8.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 74
Appendix A - DAG Schema Definitions . . . . . . . . . . . . . . . 75
A.1 DAG Personal Information Schema (DAGPERSON Schema). . . . . . 76
A.2 DAG Organizational Role Information Schema (DAGORGROLE
Schema). . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Appendix B - Schema Mappings for Whois++ and LDAP . . . . . . . . 77
B.1 LDAP and the DAG Schemas. . . . . . . . . . . . . . . . . . . 78
B.2 Whois++ and the DAG Schemas . . . . . . . . . . . . . . . . . 81
Appendix C - DAG-Internal Protocol (DAG/IP) . . . . . . . . . . . 82
C.1 A word on the choice of DAG/IP. . . . . . . . . . . . . . . . 83
C.2 DAG/IP Input and Output -- Overview . . . . . . . . . . . . . 83
C.3 BNF for DAG/IP input and output . . . . . . . . . . . . . . . 83
C.3.1 The DAG/IP Input Grammar. . . . . . . . . . . . . . . . . . 84
C.3.2 The DAG/IP Response Grammar . . . . . . . . . . . . . . . . 87
C.4 DAG/IP Response Messages. . . . . . . . . . . . . . . . . . . 89
Appendix D - DAG/IP Response Messages Mapping . . . . . . . . . . 93
Appendix E - DAG CIP Usage. . . . . . . . . . . . . . . . . . . . 95
E.1 CIP Index Object. . . . . . . . . . . . . . . . . . . . . . . 95
E.2 CIP Index Object Creation . . . . . . . . . . . . . . . . . . 97
E.3 CIP Index Object Sharing. . . . . . . . . . . . . . . . . . . 98
E.3.1 Registration of Servers . . . . . . . . . . . . . . . . . . 98
E.3.2 Transmission of Objects . . . . . . . . . . . . . . . . . .100
Appendix F - Summary of Technical Survey Results. . . . . . . . .100
Appendix G - Useful References. . . . . . . . . . . . . . . . . .102
Bibliography. . . . . . . . . . . . . . . . . . . . . . . . . . .102
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . .104
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . .105
Appendix F - Summary of Technical Survey Results. . . . . . . . .100
Appendix G - Useful References. . . . . . . . . . . . . . . . . .102
Bibliography. . . . . . . . . . . . . . . . . . . . . . . . . . .102
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . .104
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . .105
List of Tables
表格一览表
Table 3.1 DAG-supported queries . . . . . . . . . . . . . . . . .12
Table 5.1 Allowable Whois++ Queries . . . . . . . . . . . . . . .38
Table A.1 DAGPERSON schema attributes . . . . . . . . . . . . . .76
Table A.2 DAGORGROLE schema attributes. . . . . . . . . . . . . .77
Table B.1 Canonical DAGPERSON schema & LDAP inetorgPerson
attributes . . . . . . . . . . . . . . . . . . . . . . . . . .79
Table B.2 Reasonable Approximations for LDAP organizationalRole
attributes . . . . . . . . . . . . . . . . . . . . . . . . . .79
Table B.3 Canonical mappings for LDAP organizationalRole
attributes . . . . . . . . . . . . . . . . . . . . . . . . . .81
Table B.4 Canonical DAGPERSON schema & Whois++ USER attributes. .81
Table B.5 Canonical mappings for Whois++ ORGROLE attributes . . .82
Table C.1 List of system response codes . . . . . . . . . . . . .90
Table D.1 LDAPv2/v3 resultcodes to DAG/IP response codes
mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . .93
Table D.2 Mapping from DAG/IP response codes to LDAPv2/v3
resultcodes. . . . . . . . . . . . . . . . . . . . . . . . . .94
Table D.3 Mapping between DAG/IP and Whois++ response codes . . .94
Table F.1 Summary of TISDAG Survey Results: Queries . . . . . . 101
Table F.2 Summary of TISDAG Survey Results: Operational
Information. . . . . . . . . . . . . . . . . . . . . . . . . 101
Table 3.1 DAG-supported queries . . . . . . . . . . . . . . . . .12
Table 5.1 Allowable Whois++ Queries . . . . . . . . . . . . . . .38
Table A.1 DAGPERSON schema attributes . . . . . . . . . . . . . .76
Table A.2 DAGORGROLE schema attributes. . . . . . . . . . . . . .77
Table B.1 Canonical DAGPERSON schema & LDAP inetorgPerson
attributes . . . . . . . . . . . . . . . . . . . . . . . . . .79
Table B.2 Reasonable Approximations for LDAP organizationalRole
attributes . . . . . . . . . . . . . . . . . . . . . . . . . .79
Table B.3 Canonical mappings for LDAP organizationalRole
attributes . . . . . . . . . . . . . . . . . . . . . . . . . .81
Table B.4 Canonical DAGPERSON schema & Whois++ USER attributes. .81
Table B.5 Canonical mappings for Whois++ ORGROLE attributes . . .82
Table C.1 List of system response codes . . . . . . . . . . . . .90
Table D.1 LDAPv2/v3 resultcodes to DAG/IP response codes
mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . .93
Table D.2 Mapping from DAG/IP response codes to LDAPv2/v3
resultcodes. . . . . . . . . . . . . . . . . . . . . . . . . .94
Table D.3 Mapping between DAG/IP and Whois++ response codes . . .94
Table F.1 Summary of TISDAG Survey Results: Queries . . . . . . 101
Table F.2 Summary of TISDAG Survey Results: Operational
Information. . . . . . . . . . . . . . . . . . . . . . . . . 101
The overarching goal of this project is to develop the necessary technical infrastructure to provide a single-access-point service for searching for whitepages information on Swedish Internet users. The service must be uniform for all information -- the same level of access to information (7x24 service), and the same whitepages information made available, irrespective of the service provider responsible for maintaining that information.
该项目的总体目标是开发必要的技术基础设施，为搜索瑞典互联网用户的白页信息提供单一接入点服务。对于所有信息，服务必须是统一的——相同的信息访问级别（7x24服务），以及相同的可用白页信息，而不管负责维护该信息的服务提供商是谁。
The strength of the TISDAG project's DAG proposal is that it defines the necessary technical infrastructure to provide a single-access-point service for information on Swedish Internet users. The resulting service will provide uniform access for all information --
TISDAG项目DAG提案的优势在于，它定义了必要的技术基础设施，为瑞典互联网用户的信息提供单一接入点服务。由此产生的服务将为所有信息提供统一访问--
the same level of access to information (7x24 service), and the same information made available, irrespective of the service provider responsible for maintaining that information, their directory service protocols, or the end-user's client access protocol.
相同级别的信息访问（7x24服务）和可用的相同信息，而不考虑负责维护该信息的服务提供商、其目录服务协议或最终用户的客户端访问协议。
Instead of requiring centralized mirroring of complete information records from Swedish directory service providers, the DAG system uses a well-defined index object summary of that data, updated at the directory service provider's convenience. When an end-user queries the DAG, the referral information is used (by the end-user's software, or by a module within the DAG, as appropriate) to complete the final query directly at the directory service provider's system. This ensures that the end-user gets the most up-to-date complete information, and promotes the directory service provider's main interest: its service. The architecture of the DAG itself is very modular; support for future protocols can be added in the operational system.
DAG系统不需要集中镜像来自瑞典目录服务提供商的完整信息记录，而是使用该数据的定义良好的索引对象摘要，在目录服务提供商方便时进行更新。当最终用户查询DAG时，参考信息（由最终用户的软件或DAG内的模块（视情况而定）用于直接在目录服务提供商的系统上完成最终查询。这确保最终用户获得最新的完整信息，并促进目录服务提供商的主要兴趣：其服务。DAG本身的架构非常模块化；可在操作系统中添加对未来协议的支持。
This document is broken into 5 major sections:
本文件分为5个主要部分：
Requirements: As a service, the DAG system will have several different types of users. In order to be successful, those users' needs (requirements) must be met. This in turn defines certain constraints, or system requirements, that must be met. This section aims to capture the baseline requirement assumptions to be addressed by the system, and thus lays the groundwork on which the rest of the proposed system is built.
要求：作为一项服务，DAG系统将有几种不同类型的用户。为了成功，这些用户的需求（要求）必须得到满足。这反过来又定义了必须满足的某些约束或系统要求。本节旨在捕获系统要处理的基线需求假设，从而为构建拟议系统的其余部分奠定基础。
Functional Specification Overview: Working from the users' requirements, specific technologies and functionality details are outlined to architect a system that will meet the stated requirements. This includes a conceptual architecture for the system. While the Requirements section outlines the needs the different users have for the eventual DAG system, implementing and providing the eventual service will entail constraints or conditions that need to be met in order to be able to participate in the overall system.
功能规范概述：从用户需求出发，概述特定技术和功能细节，以构建满足所述需求的系统。这包括系统的概念架构。虽然需求部分概述了不同用户对最终DAG系统的需求，但实施和提供最终服务将带来需要满足的约束或条件，以便能够参与整个系统。
Architecture: Once the system has been defined conceptually, a proposed software architecture is specified to produce the desired functionality and meet the stated requirements.
架构（Architecture）：一旦从概念上定义了系统，就指定了一个建议的软件架构，以产生所需的功能并满足所述的需求。
Software Specifications: This section provides the specifications for software components to meet the architecture described above.
软件规范：本节提供满足上述体系结构的软件组件规范。
Service Specifications: Once the software has been designed, the success of the DAG system will rest on its operational characteristics. Details of service requirements are given in this section.
服务规范：软件设计完成后，DAG系统的成功将取决于其运行特性。本节给出了服务要求的详细信息。
DAG-CAP: Client Access Point -- point of communication between client-access software and the DAG system.
DAG-CAP：客户端访问点——客户端访问软件和DAG系统之间的通信点。
DAG-System: The Directory Access Gateway system resulting from the TISDAG project. A collection of infrastructural software and services for the purpose of providing unified access to Swedish whitepages information.
DAG系统：TISDAG项目产生的目录访问网关系统。一组基础设施软件和服务，用于统一访问瑞典白页信息。
DAG/IP: DAG-Internal Protocol -- communication protocol used between software components of the DAG.
DAG/IP:DAG内部协议——DAG软件组件之间使用的通信协议。
End-User: People performing White Pages searches and look-ups (via various forms of client software).
最终用户：执行白页搜索和查找的人员（通过各种形式的客户端软件）。
DAG-SAP: Service Access Point -- point of communication between the DAG and WDSP software.
DAG-SAP：服务接入点——DAG和WDSP软件之间的通信点。
WDSP: Whitepages Directory Service Provider -- ISPs, companies, or other interested entities.
WDSP:Whitepages目录服务提供商——ISP、公司或其他感兴趣的实体。
Whitepages Information: Collected information coordinates for individual people. This typically includes (but is not limited to) a person's name, and e-mail address.
白页信息：为个人收集的信息坐标。这通常包括（但不限于）一个人的姓名和电子邮件地址。
There are 2 primary classes of users for the proposed Whitepages directory access gateway:
建议的Whitepages目录访问网关有2个主要用户类别：
- End-users - WDSPs
- 最终用户-WDSP
As outlined below, needs of each of these user classes imposes a set of constraints on the design of the DAG system itself. Some of the requirements shown below are assumed starting criteria for the DAG service; others have been derived from data collected in the Technical Survey or other expertise input.
如下所述，每个用户类的需求对DAG系统本身的设计施加了一组约束。以下所示的一些要求是DAG服务的假定启动标准；其他数据来源于技术调查中收集的数据或其他专业知识投入。
The End-User is to be provided with a specific set of search types:
向最终用户提供一组特定的搜索类型：
Name Name + Organization Role + Organization Name + Locality Name + Organization + Locality Role + Organization + Locality
名称+组织角色+组织名称+地区名称+组织+地区角色+组织+地区
The search results will, if available, include the following information for each "hit":
如果可用，搜索结果将包括每个“点击”的以下信息：
- Full name - E-mail address - Role - Organization - Locality - Full address - Telephone numbers
- 全名-电子邮件地址-角色-组织-地点-完整地址-电话号码
Access to the service must be available through reasonable and current protocols -- such that directory-service-aware software can make use of it seamlessly, and there are no reasonable technological impediments to making this service useful to all Swedish Internet users.
对该服务的访问必须通过合理且当前的协议实现——这样，目录服务感知软件就可以无缝地使用它，并且使该服务对所有瑞典互联网用户都有用不存在合理的技术障碍。
Following on that, its responses are expected to be timely; a standard search should not take more time than the average access to a web-server.
在此之后，预计其反应将是及时的；标准搜索所花费的时间不应超过对web服务器的平均访问时间。
Given that the WDSPs that participate in this service are already in the business of providing a service of whitepages information, they have certain requirements that must be respected in order to make this a successful and useful service to all concerned.
考虑到参与此服务的WDSP已经开始提供白页信息服务，他们有一些必须遵守的要求，以便使此服务成功且对所有相关方都有用。
The DAG system must provide reasonable assurances of data integrity for WDSPs; the information the End-User sees should correspond directly to that provided by the WDSPs. The DAG system should be non-preferential in providing whitepages information -- the service is to the End-User, and the source of whitepages information should not influence the search and information presentation processes.
DAG系统必须为WDSP提供合理的数据完整性保证；最终用户看到的信息应与WDSP提供的信息直接对应。DAG系统在提供白页信息时不应优先考虑——服务面向最终用户，白页信息的来源不应影响搜索和信息呈现过程。
The DAG system must be able to reflect information updates within a reasonable time after receipt from WDSPs; on the flip side, while the DAG system will function best with regular updates from WDSPs, the update and participation overhead for WDSPs should be held within reasonable bounds of what the WDSP should do to support regular access to its information.
DAG系统必须能够在收到WDSP后的合理时间内反映信息更新；另一方面，虽然DAG系统在WDSP定期更新时功能最佳，但WDSP的更新和参与开销应控制在WDSP支持定期访问其信息的合理范围内。
Furthermore, given that WDSPs provide directory service information with an eye to value-added service, wherever possible End-Users should be redirected to the WDSP responsible for individual directory service entries for final and further information.
此外，鉴于WDSP提供目录服务信息时着眼于增值服务，因此应尽可能将最终用户重定向到负责单个目录服务条目的WDSP，以获取最终和进一步信息。
In order to address the requirements of End-Users and WDSPs, the DAG system itself has certain design constraints that must be taken into account.
为了满足最终用户和WDSP的要求，DAG系统本身具有一定的设计约束，必须予以考虑。
The system must be implementable/operational by Dec 31/98 -- which implies that it must be designed and constructed with already extant technologies.
该系统必须在1998年12月31日前可实施/运行——这意味着它必须使用现有技术进行设计和构建。
The System will have certain requirements for participation -- e.g., 7x24 WDSP availability.
系统将对参与有一定要求，例如7x24 WDSP可用性。
In terms of scaling, the system should be able to handle 8M records at the outset, with a view to handling larger information systems in the future.
在扩展方面，该系统一开始应该能够处理800万条记录，以便将来处理更大的信息系统。
The system must also be capable of extension to other, related applications (e.g., serving security certificate information).
系统还必须能够扩展到其他相关应用程序（例如，提供安全证书信息）。
In the TISDAG pilotservice we have decided to apply some limitations as to what is specified for the DAG/IP. These limitations are presented in this text in the following manner:
在TISDAG pilotservice中，我们决定对DAG/IP的规定施加一些限制。这些限制在本文中以以下方式呈现：
TISDAG: This is a TISDAG comment
TISDAG：这是TISDAG的评论
The conceptual environment of the DAG system can be described in three major components:
DAG系统的概念环境可分为三个主要部分：
- client access software for end-users - the DAG system core - WDSP directory service software
- 终端用户客户端访问软件-DAG系统核心-WDSP目录服务软件
This is illustrated in Figure 3.1
如图3.1所示
The DAG (Directory Access Gateway) is the infrastructural core of the service; it maintains the necessary data and transformation facilities to permit the smooth connection of diverse directory service Client Software to the existing WDSPs' directory servers. The key challenges in designing this portion of the system are:
目录访问网关（DAG）是该服务的基础设施核心；它维护必要的数据和转换设施，以便将各种目录服务客户端软件顺利连接到现有的WDSP目录服务器。设计这部分系统的主要挑战是：
Quantity of data -- the quantity of whitepages information that will be made available, and diversity of its sources (different WDSPs) introduce challenges in terms of finding a structure that will allow efficient searching, and facilitate the timeliness of updating the necessary information.
数据量——将提供的白页信息量及其来源的多样性（不同的WDSP）在寻找一种结构方面带来了挑战，这种结构将允许高效搜索，并有助于及时更新必要的信息。
Multiplicity of access protocols -- in order to support the use of existing whitepages-aware software with a minimum of perturbation, the DAG system will have to present a uniform face in several different access protocols, each with its own information search and representation paradigm.
访问协议的多样性——为了以最小的扰动支持使用现有的白页感知软件，DAG系统必须在几个不同的访问协议中呈现一个统一的界面，每个协议都有自己的信息搜索和表示范例。
This specification will outline the following areas:
本规范将概述以下方面：
- the functioning of the DAG core itself - the interface between the DAG core and End-Users' Directory Service Access software - the interface between the DAG core and Directory Services Servers
- DAG核心本身的功能—DAG核心与最终用户目录服务访问软件之间的接口—DAG核心与目录服务服务器之间的接口
In order to reduce the quantity of data the DAG itself must maintain, and to keep the maintenance of the whitepages information as close as possible to the source of information (the WDSPs themselves), the DAG will only maintain index information and will use "query routing" to efficiently refer End-User queries to WDSPs for search refinement and retrieval of information. Although originally developed for the Whois++ protocol, query routing is being pursued in a protocol-independent fashion in the IETF's FIND WG, so the choice of this approach does not limit the selection and support of whitepages access protocols.
为了减少DAG本身必须维护的数据量，并使白页信息的维护尽可能靠近信息源（WDSP本身），DAG将只维护索引信息，并将使用“查询路由”有效地将最终用户查询引用到WDSP，以优化搜索和检索信息。尽管查询路由最初是为Whois++协议开发的，但IETF的FIND WG以独立于协议的方式进行查询路由，因此这种方法的选择并不限制白页访问协议的选择和支持。
The DAG will look after pursuing queries for access protocols that do not support referral mechanisms. In order to achieve the support of multiple access protocols and differing data paradigms, the DAG will be geared to specifically support a limited set of whitepages queries.
DAG将负责查询不支持转介机制的访问协议。为了实现对多址协议和不同数据范例的支持，DAG将专门支持一组有限的白页查询。
+---------+ @
+ ->| | -+-
/|Protocol| | |
/ | / +---------+ / \
/ | "B"
+ | /
| |<-
+-------+ | |
O | | | |
-+- | |<--------->| |
| | | Protocol | |
/ \ | | "A" | |<-
+-------+ | |Protocol
| | \
+ | "A" +---------+ @
\ | \ | | -+-
\ | ->| | |
\| +---------+ / \
+
+---------+ @
+ ->| | -+-
/|Protocol| | |
/ | / +---------+ / \
/ | "B"
+ | /
| |<-
+-------+ | |
O | | | |
-+- | |<--------->| |
| | | Protocol | |
/ \ | | "A" | |<-
+-------+ | |Protocol
| | \
+ | "A" +---------+ @
\ | \ | | -+-
\ | ->| | |
\| +---------+ / \
+
The End Client DAG Directory Directory Users Software System Server Service Core Software Providers
终端客户端DAG目录用户软件系统服务器服务核心软件提供商
Figure 3.1 The role of the DAG system
图3.1 DAG系统的作用
The DAG will respond to End-User queries in
DAG将响应中的最终用户查询
- e-mail (SMTP) - WWW (HTTP) - LDAPv2 - Whois++ - LDAPv3
- 电子邮件（SMTP）-WWW（HTTP）-LDAPv2-Whois++-LDAPv3
The DAG will provide responses including the agreed-upon data. For access protocols that can handle referrals, responses will be data and/or referrals in that query protocol. These are Whois++ and LDAPv3. N.B.: the LDAPv3 proposal defines a referral as a URL; no limitation is placed on the access protocol. However it cannot be assumed that all clients will be able to handle all access protocols, so only referrals to LDAPv3 servers will be returned.
DAG将提供回复，包括商定的数据。对于可以处理转介的访问协议，响应将是该查询协议中的数据和/或转介。这些是Whois++和LDAPv3。注：LDAPv3提案将转介定义为URL；对访问协议没有任何限制。但是，不能假设所有客户端都能够处理所有访问协议，因此只返回对LDAPv3服务器的引用。
User Input is defined in terms of
用户输入定义为
- Searchable Attributes - Matching semantics - Character sets
- 可搜索属性-匹配语义-字符集
These, in conjunction with the DAG schema, defined in Appendix A, form the basis of the required query expression. Individual queries are discussed in more detail in the Client Access Point (DAG-CAP) component descriptions for supported protocols.
它们与附录A中定义的DAG模式一起构成所需查询表达式的基础。在受支持协议的客户端访问点（DAG-CAP）组件描述中详细讨论了各个查询。
Supported Query Types
支持的查询类型
The DAG system is designed to support fragment-matching queries on a limited set of data attributes -- "Name", "Organizational Role", "Organization", and "Locality". The selected permissible query combinations of attributes are listed in Table 3.1. From the table it can be seen that not all combinations of the three attributes are supported -- only those that are needed for the desired functionality.
DAG系统设计用于支持有限数据属性集上的片段匹配查询——“名称”、“组织角色”、“组织”和“位置”。表3.1中列出了所选允许的属性查询组合。从表中可以看出，并不是三个属性的所有组合都受支持——只支持所需功能所需的组合。
Symbol Description
------- -----------
N Name
NL Name + Locality
NO Name + Organization
NOL Name + Organization + Locality
RO Role + Organization
ROL Role + Organization + Locality
Symbol Description
------- -----------
N Name
NL Name + Locality
NO Name + Organization
NOL Name + Organization + Locality
RO Role + Organization
ROL Role + Organization + Locality
Table 3.1 DAG-supported queries
表3.1 DAG支持的查询
The RO and ROL queries are separated from the rest as they are searches for "virtual" persons -- roles within an organization (e.g., president, or customer service desk) for which one might want to find contact information.
RO和ROL查询与其他查询分开，因为它们是对“虚拟”人员的搜索，即组织内的角色（例如总裁或客户服务台），人们可能希望查找其联系信息。
Matching Semantics
匹配语义
As befits the individual client query protocols, more string matching expressions may be provided. The basic semantics of the DAG expect the following to be available in all client access software (as relevant):
与单个客户端查询协议相适应，可以提供更多的字符串匹配表达式。DAG的基本语义要求在所有客户端访问软件（如相关）中提供以下内容：
- Full word, exact match - Word substring match (E.g., "cat" would match "scatter") - Case-sensitive and case-insensitive matching
- 完整单词，精确匹配-单词子字符串匹配（例如，“cat”将匹配“scatter”）-区分大小写和不区分大小写匹配
TISDAG: LDAP/X.500, supports case-sensitivity as such but some of the most used attributes, such as the commonName attribute, are defined in the standard to be of the case-insensitive attributetypes. The impact on the DAG system is that even if the index collected from a LDAP/X.500 server might have upper and lower case letters in the tokens, they can not be handled as such since that would be inferring meaning in something which is natively regarded as meaningless. The conclusion of the above is that The Referral Index should be case-insensitive and case-sensitivity should be supported by the SAPs if the native access protocol supports it.
TISDAG:LDAP/X.500支持区分大小写，但一些最常用的属性，如commonName属性，在标准中定义为不区分大小写的attributeType。对DAG系统的影响是，即使从LDAP/X.500服务器收集的索引在标记中可能有大写和小写字母，它们也不能被这样处理，因为这将推断出一些原本被认为是无意义的东西的含义。上面的结论是，引用索引应该不区分大小写，如果本机访问协议支持，SAPs应该支持大小写敏感。
Character Sets
字符集
Wherever possible, the DAG System supports and promotes the use of Unicode Version 2.0 for character sets (see [21]) specifically the UTF-8 encoding (see Appendix A.2 of [21] or [20]) Accommodation is made, where necessary, to support the deployed base of existing software.
在可能的情况下，DAG系统支持并促进字符集使用Unicode 2.0版（见[21]），特别是UTF-8编码（见[21]或[20]的附录A.2]），以支持现有软件的部署基础。
Specifically:
明确地：
DAG/IP: All internal communications using the DAG/IP are carried out in UTF-8.
DAG/IP：所有使用DAG/IP的内部通信均在UTF-8中进行。
TISDAG: not just UTF-8, but UTF-8 based on composed UNICODE version 2 character encodings.
TISDAG：不仅仅是UTF-8，而是基于UNICODE第2版字符编码的UTF-8。
DAG-CAP input: Where specific access protocols permit selection of character sets, DAG-CAPs must support UTF-8. They may additionally support other anticipated character set encodings.
DAG-CAP输入：如果特定的访问协议允许选择字符集，DAG CAP必须支持UTF-8。它们还可以支持其他预期的字符集编码。
DAG-SAP communications with WDSPs: Where specific access protocols permit selection of character sets, DAG-SAPs must support UTF-8 and use UTF-8 whenever the remote WDSP supports it. They may additionally support other character set encodings.
DAG-SAP与WDSP的通信：在特定访问协议允许选择字符集的情况下，DAG-SAP必须支持UTF-8，并在远程WDSP支持时使用UTF-8。它们还可以支持其他字符集编码。
CIP Index Objects: The Index Objects supplied by the WDSPs to the DAG system shall contain data encoded in UTF-8.
CIP索引对象：WDSP向DAG系统提供的索引对象应包含UTF-8编码的数据。
TISDAG: The same limitation as for DAG/IP, that is the basic data should be UTF-8 encoded composed UNICODE version 2 character encodings.
TISDAG：与DAG/IP相同的限制，即基本数据应为UTF-8编码，由UNICODE版本2字符编码组成。
Schema Definition
模式定义
The schema used for the DAG service is defined in Appendix A. This is a very basic information schema, intended to carry the necessary information for the DAG service, and not more. Although generic "whitepages" schema definitions do exist the more sophisticated and detailed the information presentation, the more difficult it is to map the schema seamlessly across protocols of different paradigms. Thus, the "KISS" ("Keep it simple, sir") principle seems appropriate here.
用于DAG服务的模式在附录A中定义。这是一个非常基本的信息模式，旨在承载DAG服务的必要信息，而不是更多。虽然通用的“白页”模式定义确实存在，但信息表示越复杂和详细，就越难在不同范例的协议之间无缝地映射模式。因此，“接吻”（“请保持简单，先生”）原则在这里似乎是合适的。
Individual DAG-CAPs define how they express this schema.
单个DAG帽定义了它们如何表达此模式。
Referral Definition
转介定义
For client access protocols that make use of the concept of referrals, DAG-CAP definitions will define the expression of referrals in those protocols. The DAG/IP defines the expression of referrals (see Appendix C).
对于使用转介概念的客户端访问协议，DAG-CAP定义将定义这些协议中的转介表达式。DAG/IP定义了转介的表达（见附录C）。
Error conditions
错误条件
Each DAG-CAP may provide more detailed error messages, but will define minimally the support for the following error conditions:
每个DAG-CAP可能提供更详细的错误消息，但将至少定义对以下错误条件的支持：
- unrecognized query - too many hits
- 无法识别的查询-点击次数过多
Apart from these errors, the DAG-CAP may choose to refuse a query by redirecting the end-user to a different DAG-CAP of the same protocol.
除了这些错误之外，DAG-CAP还可以通过将最终用户重定向到同一协议的不同DAG-CAP来选择拒绝查询。
The DAG will use the Common Indexing Protocol (CIP) server-server protocol to obtain updated index objects from WDSPs. For query-routing purposes, WDSPs are expected to provide Whois++, LDAPv2 or LDAPv3 interface to their data (although their preferred access may be something completely different). N.B.: In the responses from the technical survey, all respondents currently provide access to their service in one of these protocols.
DAG将使用通用索引协议（CIP）服务器协议从WDSP获取更新的索引对象。出于查询路由目的，WDSP应为其数据提供Whois++、LDAPv2或LDAPv3接口（尽管其首选访问可能完全不同）。注意：在技术调查的回复中，所有受访者目前都通过其中一种协议提供对其服务的访问。
In order to provide a useful and uniform service, WDSPs are expected to provide 7x24 access to their whitepages information. WDSPs are also expected to implement operations, administration, maintenance, and provisioning processes designed to minimize service down time for both planned and unplanned administration and maintenance activities.
为了提供有用且统一的服务，WDSP应提供对其白页信息的全天候访问。WDSP还将实施操作、管理、维护和资源调配流程，旨在最大限度地减少计划内和计划外管理和维护活动的服务停机时间。
The conceptual architecture of the DAG is represented in Figure 4.1. General architectural specifications are described below, followed by individual component specifications Sections 5.5 through 5.12.
DAG的概念架构如图4.1所示。一般建筑规范如下所述，随后是单独的部件规范第5.5节至第5.12节。
Communications between components of the DAG will be by TCP/IP connections, using the DAG-Internal Protocol (DAG/IP). DAG/IP is used by DAG-CAPs to communicate with the Referral Index and DAG-SAPs. Thus, the DAG/IP defines
DAG组件之间的通信将通过TCP/IP连接，使用DAG内部协议（DAG/IP）。DAG CAPs使用DAG/IP与参考索引和DAG SAP进行通信。因此，DAG/IP定义了
- the DAG-CAPs' range of query ability in the Referral Index (to gather referrals in response to the end-user's requests) - the responses (and their formats) of the Referral Index to the DAG-CAP requests - the DAG-CAPs' range of query ability to the DAG-SAPs for pursuing referrals when the DAG-CAP needs to do chaining for the client access software - the responses (and their formats) of the DAG-SAPs to the DAG-CAPs.
- DAG CAPs在转介索引中的查询能力范围（收集转介以响应最终用户的请求）-响应（及其格式）DAG-CAP请求的引用索引-DAG-CAP对DAG SAP的查询能力范围，用于在DAG-CAP需要为客户端访问软件进行链接时进行引用-DAG SAP对DAG CAP的响应（及其格式）。
The detail of the planned DAG/IP is given in Appendix C. The detail of the DAG-CAP--Referral Index and DAG-CAP--DAG-SAP interactions is given in the definitions of individual DAG-CAPs and DAG-SAPs, below (Sections 5.5 through 5.12).
计划DAG/IP的详细信息见附录C。DAG-CAP——转诊索引和DAG-CAP——DAG-SAP交互作用的详细信息见下文（第5.5节至第5.12节）中各个DAG CAP和DAG-SAP的定义。
The Referral Index is responsible for maintaining the index of WDSP information, and providing a list of reasonable referrals in response to DAG-CAP search requests. These "referrals" provide pointers to identify WDSPs that may have information that matches the end-user's query.
推荐索引负责维护WDSP信息索引，并提供合理推荐列表，以响应DAG-CAP搜索请求。这些“引用”提供了指针，用于标识可能包含与最终用户查询匹配的信息的WDSP。
Individual DAG-CAPs are responsible for providing a particular client access protocol interface to the DAG service. DAG-CAPs receive end-user queries in a particular query access protocol, convert the request into a query for the Referral Index ( i.e., expressed in DAG/IP), and then convert the Referral Index's response into a form that is appropriate for the client access protocol. This may mean passing back the referrals directly, calling on DAG-SAPs to do the work of translating the referral into results ("chaining"), or a combination of both.
各个DAG CAP负责向DAG服务提供特定的客户端访问协议接口。DAG CAP接收特定查询访问协议中的最终用户查询，将请求转换为引用索引的查询（即，以DAG/IP表示），然后将引用索引的响应转换为适用于客户端访问协议的形式。这可能意味着直接传回转介，要求DAG SAP将转介转化为结果（“链接”），或两者的组合。
+-------------------------------------+
|+====+ |
HTTP <-->+| |<------+ (Full chaining) |
|| | | |
|+====+ | |
| | +----+|
| | Referral-->| ||
| | Result <--| |+<--> Whois++
| | +----+|
|+====+ | |
SMTP <-->+| |<------+ (Full chaining) |
|| | | |
|+====+ | |
| | +----+|
| | Referral-->| ||
| | Result <--| |+<--> LDAPv2
| | +----+|
|+====+ | |
Whois++<-->+| |<------+ (Chain LDAPv2/3) |
|| | | |
|+====+ | |
| | +----+|
| | Referral-->| ||
| | Result <--| |+<--> LDAPv3
| | +----+|
|+====+ | |
LDAPv2 <-->+| |<------+ (Full chaining) |
|| | | |
|+====+ | |
| | |
|+====+ | |
LDAPv3 <-->+| |<------+ (Chain Whois++) |
|| | | |
|+====+ | |
| | |
| v |
| +-----------------------+ |
| | Referral Index |<---------------> Common
| | | | Indexing Protocol
| +-----------------------+ | (CIP)
+-------------------------------------+
+-------------------------------------+
|+====+ |
HTTP <-->+| |<------+ (Full chaining) |
|| | | |
|+====+ | |
| | +----+|
| | Referral-->| ||
| | Result <--| |+<--> Whois++
| | +----+|
|+====+ | |
SMTP <-->+| |<------+ (Full chaining) |
|| | | |
|+====+ | |
| | +----+|
| | Referral-->| ||
| | Result <--| |+<--> LDAPv2
| | +----+|
|+====+ | |
Whois++<-->+| |<------+ (Chain LDAPv2/3) |
|| | | |
|+====+ | |
| | +----+|
| | Referral-->| ||
| | Result <--| |+<--> LDAPv3
| | +----+|
|+====+ | |
LDAPv2 <-->+| |<------+ (Full chaining) |
|| | | |
|+====+ | |
| | |
|+====+ | |
LDAPv3 <-->+| |<------+ (Chain Whois++) |
|| | | |
|+====+ | |
| | |
| v |
| +-----------------------+ |
| | Referral Index |<---------------> Common
| | | | Indexing Protocol
| +-----------------------+ | (CIP)
+-------------------------------------+
All internal communications are in DAG/IP.
所有内部通信均采用DAG/IP。
Figure 4.1 Conceptual Architecture of the DAG
图4.1 DAG的概念架构
Individual DAG-SAPs are called upon (by DAG-CAPs) to take DAG-generated referrals and pursue them -- issuing the indicated query at the specified WDSP service. Results from individual WDSPs are converted back into DAG/IP-specific format for the DAG-CAP that made the request. Each DAG-SAP is responsible for handling referrals to WDSPs of a particular protocol (e.g., LDAPv2, Whois++, etc).
单个DAG SAP（由DAG CAPs调用）接受DAG生成的转介并继续执行--在指定的WDSP服务上发出指示的查询。对于发出请求的DAG-CAP，来自各个WDSP的结果将转换回DAG/IP特定格式。每个DAG-SAP负责处理特定协议（如LDAPv2、Whois++）的WDSP转介。
This section notes some of the thinking that has driven the architectural and software design specification for the DAG system. This helps to provide the context in which to understand the software specifications that follow, and should give clues for the eventual extension of the DAG system. This section also acts, in some ways, as an FAQ (Frequently Asked Questions) section, as the content is shaped by questions received during the tech spec development phase. It attempts to illuminate context that may not otherwise be apparent on a first reading of the software specifications.
本节说明了驱动DAG系统的架构和软件设计规范的一些思想。这有助于提供理解以下软件规范的上下文，并为DAG系统的最终扩展提供线索。在某些方面，本节还充当FAQ（常见问题）部分，因为内容由技术规范开发阶段收到的问题决定。它试图阐明在第一次阅读软件规范时可能不明显的上下文。
At all times, it must be kept in mind that the primary function of the DAG system is to provide users with referrals to WDSP services that may have the information they seek. Since it is the case that not all supported client protocols can handle referrals, the DAG system also provides a chaining service to pursue referrals that the user's client software cannot handle itself. This chaining service does attempt to match the user's query against data from WDSPs, but this is to be seen as a secondary, or support function of the DAG system. In the perfect future, all access protocols will be able to handle all referrals!
在任何时候，都必须记住，DAG系统的主要功能是为用户提供WDSP服务的推荐，这些服务可能包含他们所寻求的信息。由于并非所有受支持的客户端协议都可以处理转介，因此DAG系统还提供链接服务来追踪用户客户端软件无法自行处理的转介。此链接服务确实尝试将用户的查询与来自WDSP的数据进行匹配，但这将被视为DAG系统的辅助功能或支持功能。在完美的未来，所有的访问协议将能够处理所有的转介！
The DAG system does not attempt to be a chameleon, or the ultimate whitepages query service. It focuses on providing referrals for information on the limited number of query types outlined in the functional specifications of the DAG service. This makes the DAG system a good place to start a search, but refinements and detailed inquiries are beyond its scope.
DAG系统并不试图成为变色龙，或最终的白页查询服务。它着重于为DAG服务的功能规范中概述的有限数量的查询类型提供参考。这使得DAG系统成为开始搜索的好地方，但改进和详细查询超出了它的范围。
Given the limited query syntax of the DAG system it will not always be possible to exactly match a query posed to a CAP into a query posed to a SAP. This will have the effect that for instance a LDAPv2
由于DAG系统的查询语法有限，因此不可能总是将提交给CAP的查询与提交给SAP的查询精确匹配。这将产生以下效果，例如，LDAPv2
client that issues a query to the DAG system which by the DAG system is chained to a LDAP server might not get the same results as if the client where directly connected to the server in question.
向DAG系统发出查询的客户端（DAG系统将DAG系统链接到LDAP服务器）可能不会得到与直接连接到相关服务器的客户端相同的结果。
Even the limited query syntax of the DAG system is capable of expressing queries that might NOT be possible to represent in the access protocols to the WDSPs. In these cases the DAG-SAP either can refuse the query or try to emulate it.
即使是DAG系统有限的查询语法也能够表达WDSP访问协议中可能无法表示的查询。在这些情况下，DAG-SAP可以拒绝查询，也可以尝试模拟查询。
As part of the chaining service offered by the DAG system, a certain amount of mapping between protocols is required -- in theoretical terms, there are "N" allowable end-user query access protocols, and "M" supported WDSP server protocols. The architecture of the software is constructed to use a single internal protocol (the DAG/IP) and data schema, providing a common language between all components. Without this, each input protocol module (DAG-CAP) would have to be constructed to be able to handle every WDSP protocol -- NxM protocol mappings. This would make the system complex, and difficult to expand to include new protocols in future.
作为DAG系统提供的链接服务的一部分，协议之间需要一定量的映射——理论上，有“N”个允许的最终用户查询访问协议和“M”个支持的WDSP服务器协议。该软件的体系结构使用单一的内部协议（DAG/IP）和数据模式，在所有组件之间提供通用语言。如果没有这一点，每个输入协议模块（DAG-CAP）必须构造成能够处理每个WDSP协议——NxM协议映射。这将使系统变得复杂，并且很难在将来扩展以包括新的协议。
For the above reasons, the DAG-CAP and DAG-SAP modules are intended to be completely independent of each other. A DAG-SAP responds to a query that is posed to it in the DAG/IP, without regard to the protocol of the DAG-CAP that passed the query.
出于上述原因，DAG-CAP和DAG-SAP模块旨在彼此完全独立。DAG-SAP响应在DAG/IP中向其提出的查询，而不考虑通过查询的DAG-CAP的协议。
Thus, the DAG-CAP is responsible for using the DAG/IP to obtain referral information and, where necessary, chained responses. Where necessary, it performs adjustments to accommodate the differences in semantics between the DAG/IP and its native protocol. This might involved doing post-filtering of the results returned by the DAG-SAPs since the query issued in DAG/IP to the DAG-SAP might be "broader" then the original query.
因此，DAG-CAP负责使用DAG/IP获取转诊信息，并在必要时获得连锁响应。必要时，它会进行调整，以适应DAG/IP及其本机协议之间的语义差异。这可能涉及对DAG SAP返回的结果进行后期筛选，因为以DAG/IP向DAG-SAP发出的查询可能比原始查询“更广泛”。
Thus, the DAG-CAP "knows" only 2 protocols: its native protocol, and the DAG/IP.
因此，DAG-CAP“只知道”两个协议：其本机协议和DAG/IP。
Similarly, the DAG-SAP is responsible for responding to DAG/IP queries by contacting the designated WDSP server. Where necessary, it performs adjustments to accommodate the differences in semantics between the DAG/IP and its native protocol. These adjustments might mean that, as a consequence, the DAG-SAP will receive results that do not match the original query. In such cases the DAG-SAP should attempt to do post-pruning in order to reduce the mismatch between the original query and the results returned.
同样，DAG-SAP负责通过联系指定的WDSP服务器来响应DAG/IP查询。必要时，它会进行调整，以适应DAG/IP及其本机协议之间的语义差异。这些调整可能意味着，因此，DAG-SAP将收到与原始查询不匹配的结果。在这种情况下，DAG-SAP应尝试进行后期修剪，以减少原始查询与返回结果之间的不匹配。
Thus, the DAG-SAP "knows" only 2 protocols: its native protocol, and the DAG/IP.
因此，DAG-SAP“只知道”两个协议：其本机协议和DAG/IP。
No module outside of the DAG system should be aware of the DAG/IP's construction. End-users use the query protocols supported by DAG-CAPs; WDSPs are contacted using the query protocols supported in the DAG-SAPs.
DAG系统外的任何模块都不应知道DAG/IP的结构。最终用户使用DAG CAPs支持的查询协议；使用DAG SAP中支持的查询协议联系WDSP。
The expectation is that the DAG system, although defined as a single construct, will operate by running modules on several different, perhaps widely distributed (in terms of geography and ownership), computers. For this reason, the DAG/IP specified in such a way that it will operate on inter-machine communications.
预期DAG系统虽然被定义为一个单一结构，但将通过在几个不同的、可能分布广泛（在地理和所有权方面）的计算机上运行模块来运行。因此，DAG/IP的指定方式应使其能够在机器间通信中运行。
The DAG system architecture was constructed with a specific view to extensibility. At any time, an individual component may be improved (e.g., the Mail DAG-CAP may be given a different query interface) without disrupting the system.
DAG系统体系结构是从可扩展性的角度构建的。在任何时候，都可以在不中断系统的情况下改进单个组件（例如，邮件DAG-CAP可以提供不同的查询接口）。
Additionally, future versions of the DAG system may support other access protocols -- for end-users, and for WDSPs.
此外，DAG系统的未来版本可能支持其他访问协议——针对最终用户和WDSP。
It is always a challenge to accurately represent text protocol in a printed document; when is a new line a "newline", and when is it an effect of the text formatter?
在打印文档中准确地表示文本协议始终是一个挑战；新行何时为“新行”，何时为文本格式化程序的效果？
In order to be adequately illustrated, this document includes many segments of protocol grammars, sample data, and sample input/output in a text protocol. In order to distinguish newlines that are significant in a protocol, the symbol
为了充分说明，本文档包括协议语法、示例数据和文本协议中的示例输入/输出的许多部分。为了区分协议中重要的换行符，符号
<NL>
<NL>
is used. For example,
使用。例如
This is an example of a very long line of input. There is only one newline in it (at the end), in spite of the fact that this document shows it spanning several lines of text.<NL>
这是一个很长的输入行示例。尽管本文档显示它跨越了几行文本，但其中只有一行换行符（在末尾）。<NL>
Every DAG-CAP must support the full range of DAG queries, as defined in 3.3.1.
每个DAG-CAP必须支持3.3.1中定义的所有DAG查询。
Each DAG-CAP accepts queries in its native protocol. Individual DAG-CAP definitions define the expected expression of the DAG queries in the native protocol.
每个DAG-CAP都接受其本机协议中的查询。单个DAG-CAP定义定义了本机协议中DAG查询的预期表达式。
The DAG-CAP is then responsible for:
然后，DAG-CAP负责：
- converting that expression into a query in the DAG/IP to obtain relevant referrals from the Referral Index. This might mean that parts of the original query are disregarded (e.g., if the query included attributes not supported by the DAG application, or if the query algebra was not supported by the DAG application); - returning referrals in the client's native protocol, where possible; - expressing the client query to the necessary DAG-SAPs, given the limitations mentioned above, to chain those referrals not usefully expressible in the client's native protocol; - possibly doing post-filtering on the DAG-SAP results; and - converting the collected DAG-SAP results for expression in the client's native protocol (and schema, where applicable).
- 将该表达式转换为DAG/IP中的查询，以从引用索引获取相关引用。这可能意味着忽略原始查询的部分内容（例如，如果查询包含DAG应用程序不支持的属性，或者如果DAG应用程序不支持查询代数）；-尽可能在客户端的本机协议中返回转介；-鉴于上述限制，将客户端查询表示为必要的DAG SAP，以链接那些在客户端本机协议中无法有效表达的引用；-可能对DAG-SAP结果进行后期过滤；和-转换收集的DAG-SAP结果，以便在客户端的本机协议（和模式，如适用）中表达。
Each DAG-CAP defines the nature of the interaction with the end-user (e.g., synchronous or asynchronous, etc). Additionally, each DAG-CAP must be able to carry out the following, in order to permit load-limiting and load-balancing in the DAG system:
每个DAG-CAP定义了与最终用户交互的性质（例如，同步或异步等）。此外，每个DAG-CAP必须能够执行以下操作，以允许DAG系统中的负载限制和负载平衡：
- direct the client to a different DAG-CAP of the same type (for load-balancing)
- 将客户端指向同一类型的不同DAG-CAP（用于负载平衡）
- decline to return results because too many referrals were generated (to discourage data-mining). Ideally, this should include the generation of a message to refine the query in order to produce a more manageable number of referrals/replies.
- 拒绝返回结果，因为生成了太多的推荐（以阻止数据挖掘）。理想情况下，这应该包括生成一条消息来优化查询，以便生成数量更易于管理的引用/回复。
DAG-CAPs must be capable of accepting and respecting DAG-SAP service referrals (for DAG-SAP load-sharing).
DAG CAPs必须能够接受并尊重DAG-SAP服务推荐（用于DAG-SAP负载共享）。
In protocols that permit it, the DAG-CAP should indicate to the end-user which services were unavailable for chaining referrals (i.e., to indicate there were parts of the search that could not be completed, and information might be missing).
在允许的协议中，DAG-CAP应向最终用户指示哪些服务不可用于链接转介（即，指示部分搜索无法完成，信息可能缺失）。
TISDAG: Any CAP that receives commands other than queries, like help, answers those on its own. A CAP should not pass any system command on to the RI.
TISDAG：任何接收命令而不是查询的CAP，比如帮助，都会自己回答这些问题。CAP不应将任何系统命令传递给RI。
It must be possible to change the expected address of the DAG-CAP by configuration of the software (i.e., host and port, e-mail address, etc).
必须能够通过软件配置更改DAG-CAP的预期地址（即主机和端口、电子邮件地址等）。
For DAG-CAPs that need to access DAG-SAPs for query chaining, for each type (protocol) of DAG-SAP that is needed, the DAG-CAP must be configurable in terms of:
对于需要访问DAG SAP以进行查询链接的DAG CAP，对于所需的每种DAG-SAP类型（协议），DAG-CAP必须在以下方面进行配置：
- at least one known DAG-SAP of every necessary protocol to contact - for each DAG-SAP, the host and port of the DAG-SAP software
- 至少有一个已知的DAG-SAP，每个需要联系的协议-对于每个DAG-SAP，DAG-SAP软件的主机和端口
The DAG-CAPs must also be configurable in terms of a maximum number of referrals to handle for a user transaction (i.e., to prevent data mining, the DAG-CAP will refuse to reply if the query is too general and too many hits are generated at the Referral Index).
DAG CAP还必须根据用户事务处理的最大转介数量进行配置（即，为了防止数据挖掘，如果查询过于笼统且在转介索引中生成的点击次数过多，DAG-CAP将拒绝答复）。
The DAG-CAP must be configurable in terms of alternate DAG-CAPs of the same type to which the end-user software may be directed if this one is too busy.
如果DAG-CAP太忙，则DAG-CAP必须可配置为最终用户软件可能指向的相同类型的备用DAG CAP。
Apart from error conditions arising from the operation of the DAG-CAP itself, DAG-CAPs are responsible for communicating error conditions occurring elsewhere in the system that affect the outcome of the user's query (e.g., in the DAG-RI, or in one or more DAG-SAPs).
除了因DAG-CAP本身的操作而产生的错误条件外，DAG-CAP还负责传达系统中其他地方发生的影响用户查询结果的错误条件（例如，在DAG-RI中，或在一个或多个DAG SAP中）。
If the DAG-CAP sends a query to the DAG-RI and receives an error message, it should attempt to match the the received DAG errorcode into its native access protocol's error codes. The same action is appropriate when the DAG-CAP is "chaining" the query to one DAG-SAP.
如果DAG-CAP向DAG-RI发送查询并收到错误消息，则应尝试将收到的DAG错误代码与其本机访问协议的错误代码进行匹配。当DAG-CAP将查询“链接”到一个DAG-SAP时，同样的操作也适用。
There are also occasions when the DAG-CAP may have to combine multiple errorcodes into a single expression to the user. When the DAG-CAP is "chaining" the query through DAG-SAPs to one or more WDSPs, situations can arise when there is a mix of responsecodes from the DAG-SAPs. If this happens, the DAG-CAP should try to forward information to the end-user software that is as specific as possible, for instance which of the WDSPs has not been able to fulfill the query and why.
有时，DAG-CAP可能不得不将多个错误代码组合成一个表达式，以供用户使用。当DAG-CAP通过DAG SAP将查询“链接”到一个或多个WDSP时，可能会出现混合来自DAG SAP的响应代码的情况。如果发生这种情况，DAG-CAP应尝试向最终用户软件转发尽可能具体的信息，例如，哪个WDSP无法完成查询以及原因。
See Appendix D for more information concerning error condition message mappings.
有关错误条件消息映射的更多信息，请参见附录D。
Since there is no perfect match between the query syntaxes of the DAG system on one hand and the different access protocols that the DAG-CAPs and DAG-SAPs supports on the other, there will be situations where the results a DAG-CAP has to collect is "broader" then what would have been the case if there had been a perfect match. This might have adverse effects on the system to the extent that administrative limits will "unnecessary" be exceeded on WDSPs or that the collected results exceeds the sizelimit of the DAG-CAP.
由于一方面DAG系统的查询语法与另一方面DAG CAP和DAG SAPs支持的不同访问协议之间不存在完美匹配，因此会出现DAG-CAP必须收集的结果“更广泛”的情况，如果存在完美匹配的情况会是什么情况。这可能会对系统产生不利影响，因为WDSP将“不必要”超过管理限制，或者收集的结果超过DAG-CAP的大小限制。
Since the DAG-CAP is the only part of the DAG system that actually knows what the original query was, the DAG-CAP can prune the results received from the DAG-SAPs in such a way that the results presented to the client better matches the original question.
由于DAG-CAP是DAG系统中唯一真正知道原始查询是什么的部分，因此DAG-CAP可以修剪从DAG SAP收到的结果，以便呈现给客户的结果更好地匹配原始问题。
Every DAG-SAP must support the full range of DAG queries, as defined in 3.3.1. Results must be complete DAG schemas expressed in well-formed DAG/IP result formats (see Appendix C). Each DAG-SAP accepts queries in DAG/IP and converts them to the native schema and protocol for which it is designed to proxy.
每个DAG-SAP必须支持3.3.1中定义的所有DAG查询。结果必须是完整的DAG模式，以格式良好的DAG/IP结果格式表示（见附录C）。每个DAG-SAP都接受DAG/IP中的查询，并将其转换为本机模式和协议，以代理该模式和协议。
The DAG-SAP is then responsible for
然后，DAG-SAP负责
- converting the query into the native schema and protocol of the WDSP to which the referral points. (If the query is not representable in the native protocol, it must return an error
- 将查询转换为引用所指向的WDSP的本机架构和协议。（如果查询在本机协议中不可表示，则必须返回错误。）
message. If it is emulatable, the DAG-SAP can attempt emulate it
by posing a related query to the WDSP and post-pruning the results
received);
- contacting that WDSP, using the host, port, and protocol
information provided in the referral;
- negotiating the query with the remote WDSP;
- accepting results from the WDSP, possibly doing post-filtering on
the result set; and
- conveying the results back to the calling DAG-CAP using the DAG/IP
and its schema.
message. If it is emulatable, the DAG-SAP can attempt emulate it
by posing a related query to the WDSP and post-pruning the results
received);
- contacting that WDSP, using the host, port, and protocol
information provided in the referral;
- negotiating the query with the remote WDSP;
- accepting results from the WDSP, possibly doing post-filtering on
the result set; and
- conveying the results back to the calling DAG-CAP using the DAG/IP
and its schema.
Note that this implicitly means that the DAG-SAP is responsible for chaining and pursuing any referrals it receives from WDSP services. The DAG-SAP returns only search results to the DAG-CAP that called it.
请注意，这意味着DAG-SAP负责链接和追踪从WDSP服务收到的任何转介。DAG-SAP只向调用它的DAG-CAP返回搜索结果。
DAG-SAPs must be configurable to accept connections only from recognized DAG components.
DAG SAP必须可配置为仅接受来自已识别DAG组件的连接。
DAG-SAPs that have service limits must be configurable to redirect DAG-CAPs to alternate DAG-SAPs of the same type when necessary.
必须配置具有服务限制的DAG SAP，以便在必要时将DAG CAP重定向到相同类型的备用DAG SAP。
A DAG-SAP must translate error codes received from a WDSP server to DAG error codes according to Appendix D.
DAG-SAP必须根据附录D将从WDSP服务器接收的错误代码转换为DAG错误代码。
Since it might not be possible to exactly map a DAG query into a query in the access protocol supported by the a DAG-SAP, the DAG-SAP should try to translate it into a more general query (or if necessary into a set of queries). If so, the DAG-SAP must then prune the result set received before furthering it to the DAG-CAP.
由于可能无法将DAG查询准确映射到DAG-SAP支持的访问协议中的查询，因此DAG-SAP应尝试将其转换为更一般的查询（或在必要时转换为一组查询）。如果是这样，则DAG-SAP必须在将其进一步扩展到DAG-CAP之前修剪接收到的结果集。
Some constraints, search and case, can appear both as local and global constraints. If this happens in a query then the local constraint specification overrides the global. For a query like the following:
某些约束（搜索约束和案例约束）可以显示为局部约束和全局约束。如果在查询中发生这种情况，则局部约束规范将覆盖全局约束规范。对于类似以下的查询：
fn=leslie;search=exact and org=think:search=substring
fn=leslie;search=exact and org=think:search=substring
the resulting search constraint for "fn=leslie" will be "exact" while it for "org=think" will be "substring".
“fn=leslie”的搜索约束将是“精确的”，而“org=think”的搜索约束将是“子字符串”。
The Referral Index contains (only) information necessary to deliver referrals to DAG-CAPs based on the query types supported by the DAG itself. The Referral Index creates an index over these objects so that it can respond to DAG-CAP queries using the DAG/IP. The information is drawn directly from interactions with participating WDSPs' software, using the Common Indexing Protocol (CIP).
转介索引包含（仅）根据DAG本身支持的查询类型向DAG CAP传递转介所需的信息。引用索引在这些对象上创建索引，以便使用DAG/IP响应DAG-CAP查询。使用通用索引协议（CIP），直接从与参与WDSP软件的交互中获取信息。
WDSPs that wish to participate in the DAG system must register themselves (see Section 5.4.6). Once registered, the Referral Index will interact with the WDSPs using the Common Indexing Protocol as defined in [1], using the Index Object defined in Section 5.4.3.
希望参与DAG系统的WDSP必须自行注册（见第5.4.6节）。注册后，参考索引将使用第5.4.3节中定义的索引对象，使用[1]中定义的通用索引协议与WDSP交互。
The CIP index object type is based on the Tagged Index Object as defined in [12]. Appendix E details the expected content of the index objects as they are to be provided by the WDSPs.
CIP索引对象类型基于[12]中定义的标记索引对象。附录E详细说明了WDSP将提供的索引对象的预期内容。
TISDAG: The tokens in the Tagged Index Object should be UTF-8 encoded composed UNICODE version 2 character encoding.
TISDAG：标记索引对象中的标记应为UTF-8编码，由UNICODE版本2字符编码组成。
The Referral Index interacts with the rest of the DAG internal modules (DAG-CAPs) by listening for queries and responding in the DAG/IP (defined in Appendix C).
参考索引通过在DAG/IP（定义见附录C）中侦听查询和响应，与DAG内部模块（DAG CAPs）的其余部分交互。
The Referral Index must index the necessary attributes of the CIP index object in order to respond to queries of the form described in Table 3.1.
参考索引必须索引CIP索引对象的必要属性，以便响应表3.1中所述形式的查询。
The semantics of the chosen CIP object (defined in Appendix E) are such that a referral to a WDSP server is sent back if (and only if)
所选CIP对象（在附录E中定义）的语义是这样的：在以下情况下（且仅在以下情况下）发回对WDSP服务器的引用
- the index object of the WDSP contains all the tokens of the query, in the attributes specified, according to the logic of the DAG/IP query, and - all of those tokens are found with a common tag.
- 根据DAG/IP查询的逻辑，WDSP的索引对象在指定的属性中包含查询的所有标记，并且-所有这些标记都使用公共标记找到。
This means that a query for the name "Fred Flintstone" (2 tokens) will yield a referral to a server that has a record for "Fred Amadeus Flintstone", but not to a WDSP with 2 differently tagged records, for "Fred Amadeus" and "Julie Flintstone". Depending on the access protocol being used and the original end-user query, the referral to the WDSP with "Fred Amadeus Flintstone" may yield a successful result, or it may not. But, it is known that the other WDSP would not have yielded successful searches. That is, the referral approach may yield false-positive results, but will not miss appropriate WDSPs.
这意味着对名称“Fred Flintstone”（2个令牌）的查询将产生对具有“Fred Amadeus Flintstone”记录的服务器的引用，但不会产生对具有2个不同标记记录的WDSP的引用，即“Fred Amadeus”和“Julie Flintstone”。根据使用的访问协议和原始最终用户查询，使用“Fred Amadeus Flintstone”引用WDSP可能会产生成功的结果，也可能不会。但是，众所周知，另一个WDSP不会产生成功的搜索结果。也就是说，推荐方法可能会产生假阳性结果，但不会遗漏适当的WDSP。
The Referral Index must provide the ability to register interested WDSPs, as outlined in Appendix E.
如附录E所述，推荐索引必须提供登记感兴趣的WDSP的能力。
The Referral Index must be able to configure the port for DAG/IP communications. Also, it must be configurable to recognize only registered DAG-CAPs.
参考索引必须能够为DAG/IP通信配置端口。此外，它必须可配置为仅识别已注册的DAG CAP。
The Referral Index will accept queries only from recognized (registered) DAG-CAPs. This will reduce "denial of service" attack types, but is also a reflection on the fact that the Referral Index uses the DAG/IP, (i.e., internal) protocol, which should not be exposed to non-DAG software.
推荐索引将只接受来自已识别（注册）DAG CAP的查询。这将减少“拒绝服务”攻击类型，但也反映了引用索引使用DAG/IP（即内部）协议这一事实，该协议不应暴露于非DAG软件。
The Referral Index must be able to use authenticated communication to receive data from WDSPs (see Appendix E).
参考索引必须能够使用经过验证的通信从WDSP接收数据（见附录E）。
This is the default Mail DAG-CAP. More sophisticated ones could certainly be written -- e.g., for pretty-printed output, or for handling different philosophies of case-matching.
这是默认的邮件DAG-CAP。当然可以编写更复杂的代码——例如，用于打印精美的输出，或者用于处理不同的大小写匹配原理。
This DAG-CAP has been designed on the assumption that mail queries will be human-generated (i.e., using a mail program/text editor), as opposed to being queries formulated by software agents. The input grammar should therefore be simple and liberal in acceptance of variations of whitespace formatting.
本DAG-CAP的设计假设邮件查询将由人工生成（即使用邮件程序/文本编辑器），而不是由软件代理制定查询。因此，输入语法应该简单且自由地接受各种各样的空白格式。
Mail DAG-CAP input is expected to be a regular or MIME-encoded (see [9] and [10]) SMTP mail message, sent to an advertised mail address. The mail DAG-CAP parses the message and replies to it with a MIME-encoded message containing the results of the DAG search.
邮件DAG-CAP输入应为常规或MIME编码的SMTP邮件（请参见[9]和[10]），发送到公布的邮件地址。邮件DAG-CAP解析消息，并使用包含DAG搜索结果的MIME编码消息对其进行回复。
One query is accepted per e-mail message -- text after a single valid query has been read is simply ignored.
每封电子邮件接受一个查询——读取单个有效查询后的文本将被忽略。
The body of the query message must follow the syntax defined below. Note that all input control terms ("type=", "name=" etc) are shown in lower case for convenience, but could be upper case or mixed case on input.
查询消息的正文必须遵循下面定义的语法。请注意，为了方便起见，所有输入控制项（“type=”、“name=”等）都以小写显示，但输入时可以是大写或混合大写。
mailquery = [mnl] [controls] mnl terms mnl
controls = [msp] "searchtype" [msp] "=" [msp]
( matchtype /
casetype /
matchtype msp casetype /
casetype msp matchtype /
<nothing> )
matchtype = "substring" / "exact"
; default: substring
casetype = "ignore" / "sensitive"
; default: ignore
mailquery = [mnl] [controls] mnl terms mnl
controls = [msp] "searchtype" [msp] "=" [msp]
( matchtype /
casetype /
matchtype msp casetype /
casetype msp matchtype /
<nothing> )
matchtype = "substring" / "exact"
; default: substring
casetype = "ignore" / "sensitive"
; default: ignore
terms = n / n-l / n-o / n-o-l / r-o / r-o-l
terms = n / n-l / n-o / n-o-l / r-o / r-o-l
n = n-term
n-l = ( n-term l-term / l-term n-term)
n-o = ( n-term o-term / o-term n-term )
n-o-l = ( n-term o-term l-term /
n-term l-term o-term /
l-term n-term o-term /
l-term o-term n-term /
o-term l-term n-term /
o-term n-term l-term )
r-o = ( r-term o-term / o-term r-term )
r-o-l = ( r-term o-term l-term /
r-term l-term o-term /
n = n-term
n-l = ( n-term l-term / l-term n-term)
n-o = ( n-term o-term / o-term n-term )
n-o-l = ( n-term o-term l-term /
n-term l-term o-term /
l-term n-term o-term /
l-term o-term n-term /
o-term l-term n-term /
o-term n-term l-term )
r-o = ( r-term o-term / o-term r-term )
r-o-l = ( r-term o-term l-term /
r-term l-term o-term /
l-term o-term r-term /
l-term r-term o-term /
o-term l-term r-term /
o-term r-term l-term )
n-term = [msp] "name" [msp] "=" [msp] string mnl
o-term = [msp] "org" [msp] "=" [msp] string mnl
l-term o-term r-term /
l-term r-term o-term /
o-term l-term r-term /
o-term r-term l-term )
n-term = [msp] "name" [msp] "=" [msp] string mnl
o-term = [msp] "org" [msp] "=" [msp] string mnl
l-term = [msp] "loc" [msp] "=" [msp] string mnl
r-term = [msp] "role" [msp] "=" [msp] string mnl
l-term = [msp] "loc" [msp] "=" [msp] string mnl
r-term = [msp] "role" [msp] "=" [msp] string mnl
string = <US-ASCII or quoted-printable encoded
ISO-8859-1 or UTF-8 except nl and sp>
msp = 1*(sp)
sp = " "
mnl = 1*(nl)
string = <US-ASCII or quoted-printable encoded
ISO-8859-1 or UTF-8 except nl and sp>
msp = 1*(sp)
sp = " "
mnl = 1*(nl)
nl = <linebreak>
nl = <linebreak>
The following are valid mail queries:
以下是有效的邮件查询：
Example 1:
例1：
searchtype = <NL>
name = thinking cat<NL>
searchtype = <NL>
name = thinking cat<NL>
Example 2:
例2：
searchtype = exact ignore<NL>
name=thinking cat<NL>
searchtype = exact ignore<NL>
name=thinking cat<NL>
Example 3:
例3：
role=thinking cat<NL>
org =space colonization<NL>
role=thinking cat<NL>
org =space colonization<NL>
Example 4:
例4：
name=thinking cat <NL>
<NL>
<NL>
My signature line follows here in the most annoying
fashion <NL>
name=thinking cat <NL>
<NL>
<NL>
My signature line follows here in the most annoying
fashion <NL>
Note that the following are not acceptable queries:
请注意，以下查询是不可接受的：
Example 5:
例5：
searchtype= exact substring <NL>
name = thinking cat <NL>
searchtype= exact substring <NL>
name = thinking cat <NL>
Example 6:
例6：
name=thinking cat org= freedom fighters anonymous<NL>
name=thinking cat org= freedom fighters anonymous<NL>
In Example 5, two conflicting searchtypes are given. In Example 6, no linebreak follows the n-term.
在示例5中，给出了两种相互冲突的搜索类型。在示例6中，n项后面没有换行符。
Querying the Referral Index
查询转介索引
A key element of translating from the Mail DAG-CAP input into the DAG/IP query format is to "tokenize" the input terms into single token elements for the DAG/IP query. For example, the n-term
将邮件DAG-CAP输入转换为DAG/IP查询格式的一个关键要素是将输入术语“标记化”为DAG/IP查询的单个标记元素。例如，n项
name= thinking cat<NL>
name= thinking cat<NL>
is tokenized into 2 n-tokens:
被标记为2个n-标记：
thinking cat
思维猫
which are then mapped into the following in the DAG/IP query (dag-n-terms):
然后在DAG/IP查询（DAG-n-terms）中将其映射为以下内容：
FN=thinking and FN=cat<NL>
FN=thinking and FN=cat<NL>
The same is true for all r-terms, l-terms and o-terms. The primary steps in translating the mail input into a DAG/IP query are:
所有r-项、l-项和o-项也是如此。将邮件输入转换为DAG/IP查询的主要步骤如下：
translate quoted-printable encoding, if necessary translate base64 encoding, if necessary tokenize the strings for each term construct the DAG/IP query from the resulting components, as described in more detail below
translate quoted printable encoding，如有必要translate base64 encoding，如有必要，标记每个术语的字符串，从结果组件构造DAG/IP查询，如下所述
DAG/IP constraints are constructed from the searchtype information in the query.
DAG/IP约束是根据查询中的searchtype信息构造的。
dag-matchtype = "search=" <matchtype> /
"search=substring" ; if matchtype not
; specified
dag-matchtype = "search=" <matchtype> /
"search=substring" ; if matchtype not
; specified
dag-casetype = "case=ignore" / ; if casetype not
; specified or
; casetype=ignore
"case=consider" ; if casetype=sensitive
dag-casetype = "case=ignore" / ; if casetype not
; specified or
; casetype=ignore
"case=consider" ; if casetype=sensitive
constraints = ":" dag-matchtype ";" dag-casetype
constraints = ":" dag-matchtype ";" dag-casetype
The terms for the DAG/IP query are constructed from the tokenized strings from the mail input.
DAG/IP查询的术语是从邮件输入的标记化字符串构造的。
dag-n-terms = "FN=" n-token 0*( " and FN=" n-token)
dag-o-terms = "ORG=" o-token 0*( " and ORG=" o-token)
dag-l-terms = "LOC=" l-token 0*( " and LOC=" l-token)
dag-r-terms = "ROLE=" r-token 0*( " and ROLE=" r-token)
dag-n-terms = "FN=" n-token 0*( " and FN=" n-token)
dag-o-terms = "ORG=" o-token 0*( " and ORG=" o-token)
dag-l-terms = "LOC=" l-token 0*( " and LOC=" l-token)
dag-r-terms = "ROLE=" r-token 0*( " and ROLE=" r-token)
This means that the relevant DAG/IP queries are formulated as one of two types:
这意味着相关的DAG/IP查询被表述为两种类型之一：
dagip-query = ( ( ( n-query / nl-query / no-query /
nol-query ) [" and template=DAGPERSON"]":"
dag-matchtype ";" dag-casetype) /
( ( ro-query / rol-query )
[" and template=DAGORGROLE"]":"
dag-matchtype ";" dag-casetype) )
dagip-query = ( ( ( n-query / nl-query / no-query /
nol-query ) [" and template=DAGPERSON"]":"
dag-matchtype ";" dag-casetype) /
( ( ro-query / rol-query )
[" and template=DAGORGROLE"]":"
dag-matchtype ";" dag-casetype) )
n-query = dag-n-terms nl-query = dag-n-terms " and " dag-l-terms no-query = dag-n-terms " and " dag-o-terms nol-query = dag-n-terms " and " dag-o-terms " and " dag-l-terms ro-query = dag-r-terms " and " dag-o-terms rol-query = dag-r-terms " and " dag-o-terms " and " dag-l-terms
n-query=dag-n-terms nl query=dag-n-terms”和“dag-l-terms no query=dag-n-terms”和“dag-o-terms nol query=dag-n-terms”和“dag-o-terms ro query=dag-r-terms”和“dag-o-terms rol query=dag-r-terms”以及“dag-o-terms”和“dag-l-terms”
The examples given earlier are then translated as follows.
前面给出的例子翻译如下。
Example 1:
例1：
FN=thinking and FN=cat:search=substring;case=ignore<NL>
FN=thinking and FN=cat:search=substring;case=ignore<NL>
Example 2:
例2：
FN=thinking and FN=cat:search=exact;case=ignore<NL>
FN=thinking and FN=cat:search=exact;case=ignore<NL>
Example 3:
例3：
ROLE=thinking and ROLE=cat and ORG=space and
ORG=colonization:search=substring;case=ignore<NL>
ROLE=thinking and ROLE=cat and ORG=space and
ORG=colonization:search=substring;case=ignore<NL>
Querying a DAG-SAP
查询DAG-SAP
In querying a DAG-SAP (irrespective of the protocol of that DAG-SAP), the DAG/IP query must include information about the target WDSP server. This information is drawn from the Referral Index SERVER-TO-ASK referral information, and is appended to the query as specified in Appendix C):
在查询DAG-SAP（不考虑该DAG-SAP的协议）时，DAG/IP查询必须包括有关目标WDSP服务器的信息。该信息取自参考索引服务器到询问参考信息，并按照附录C中的规定附加到查询中）：
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
where the response from the Referral Index included:
其中，来自推荐索引的响应包括：
"# SERVER-TO-ASK " serverhandle nl " Server-info: " serverinfo nl " Host-Name: " hostname nl " Host-Port: " number nl
“#服务器到请求”serverhandle nl“服务器信息：”serverinfo nl“主机名：”hostname nl“主机端口：”编号nl
" Protocol: " prot nl " Source-URI: " source nl " Charset: " charset nl "# END" nl
协议：“保护nl”源URI：“源nl”字符集：“字符集nl”#结束“nl”
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
通过引用DAG/IP特殊字符，分别从“主机名”和“服务器信息”中获取“引用的主机名”和“引用的服务器信息”。
For example, the referral
例如，转介
# SERVER-TO-ASK dagsystem01<NL>
Server-info: o=thinkingcat, c=se<NL>
Host-Name: thinkingcat.com<NL>
Host-Port: 2839<NL>
Protocol: ldapv2<NL>
Source-URI: http://www.thinkcat.com
Charset: T.61<NL>
# END<NL>
# SERVER-TO-ASK dagsystem01<NL>
Server-info: o=thinkingcat, c=se<NL>
Host-Name: thinkingcat.com<NL>
Host-Port: 2839<NL>
Protocol: ldapv2<NL>
Source-URI: http://www.thinkcat.com
Charset: T.61<NL>
# END<NL>
would yield the addition
将产生加法
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
c\=se;charset=T\.61
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
c\=se;charset=T\.61
in its query to an LDAPv2 DAG-SAP.
在其对LDAPv2 DAG-SAP的查询中。
(N.B.: See Appendix C for further definitions of the terms used in the SERVER-TO-ASK response).
（注意：关于服务器对请求响应中使用的术语的进一步定义，请参见附录C）。
Note that it is the DAG-SAP's responsibility to extract these terms from the query and use them to identify the WDSP server to be contacted. See the individual DAG-SAP definitions, below.
请注意，DAG-SAP负责从查询中提取这些术语，并使用它们标识要联系的WDSP服务器。请参见下面的各个DAG-SAP定义。
The Mail DAG-CAP has to chain all referrals -- to the Whois++ DAG-SAP, LDAPv2 DAG-SAP, or LDAPv3 DAG-SAP as appropriate for the referral.
邮件DAG-CAP必须将所有转介链接到Whois++DAG-SAP、LDAPv2 DAG-SAP或LDAPv3 DAG-SAP，视情况而定。
The results message is sent to the "Reply-To:" address of the originating mail, if available (see [4] for appropriate interpretation of mail originator headers). The original query is repeated, along with the message-id. The remainder of the body of the mail message is the concatenation of responses from the DAG-SAP calls, each result having the WDSP's SOURCE URI (from the referral) appended to it, and the system messages also having been removed.
结果消息被发送到原始邮件的“回复地址：”地址（如果可用）（有关邮件发起人标题的适当解释，请参见[4]）。原始查询与message-id一起重复。邮件消息正文的其余部分是来自DAG-SAP调用的响应的串联，每个结果都附加了WDSP的源URI（来自引用），并且系统消息也已被删除。
At the end of the message, the WDSP servers that failed to respond (i.e., the DAG-SAP handling the referral returned the "% 403 Information Unavailable" message) are listed with their server-info.
在消息末尾，未响应的WDSP服务器（即，处理转诊的DAG-SAP返回“%403信息不可用”消息）与其服务器信息一起列出。
If the mail DAG-CAP receives a message that is not parsable using the query grammar described above, it returns an explanatory message to the query mail's reply address saying that the query could not be interpreted, and giving a description of valid queries.
如果邮件DAG-CAP接收到无法使用上述查询语法解析的消息，它将向查询邮件的回复地址返回解释性消息，说明无法解释查询，并给出有效查询的说明。
If the number of referrals sent by the Referral Index is greater than the pre-determined maximum (for detecting data-mining efforts, or otherwise refusing over-general queries, such as "FN=svensson"), the mail DAG-CAP will send an explanatory message to the query mail's reply address describing the "over-generalized query" problem, suggesting the user resubmit a more precise query, and describing the list of valid query types.
如果由转介索引发送的转介数量大于预先确定的最大值（用于检测数据挖掘工作，或以其他方式拒绝过一般查询，如“FN=svensson”），则邮件DAG-CAP将向查询邮件的回复地址发送解释性消息，说明“过一般查询”问题，建议用户重新提交更精确的查询，并描述有效查询类型的列表。
If the mail DAG-CAP receives several different result codes from the DAG-SAPs it should represent those in an appropriate manner in the response message.
如果邮件DAG-CAP从DAG SAP接收到多个不同的结果代码，则应以适当的方式在响应消息中表示这些代码。
A mail DAG-CAP may redirect a connection to another mail DAG-CAP for reasons of load-balancing. This is done simply by forwarding the mail query to the address of the alternate mail DAG-CAP.
出于负载平衡的原因，邮件DAG-CAP可能会将连接重定向到另一个邮件DAG-CAP。这只需将邮件查询转发到备用邮件DAG-CAP的地址即可完成。
The web DAG-CAP provides its interface via standard HTTP protocol. The general expectation is that the web DAG-CAP will provide a form page with radio buttons to select "substring or exact match" and "consider case or ignore case". Other information (about name, role, organization, locality) is solicited as free-form text.
web DAG-CAP通过标准HTTP协议提供其接口。一般期望web DAG-CAP将提供一个带有单选按钮的表单页面，以选择“子字符串或精确匹配”和“考虑大小写或忽略大小写”。其他信息（关于姓名、角色、组织、地点）以自由格式文本形式征求。
The DAG-CAP receives queries via an HTTP "post" method (the outcome of the form action for the page described above, or generated elsewhere). The rest of this section describes the variables that are to be expressed in that post. The actual layout of the page and most user interface issues are left to the discretion of the builder. Note that the Web DAG-CAP may be called upon to provide responses in different content encoding, and must therefore address the "Accept-Encoding:" request header in the HTTP connection.
DAG-CAP通过HTTP“post”方法接收查询（上述页面的表单操作的结果，或在别处生成的结果）。本节的其余部分描述了将在该帖子中表达的变量。页面的实际布局和大多数用户界面问题由构建者自行决定。请注意，可能会调用Web DAG-CAP以不同的内容编码提供响应，因此必须在HTTP连接中寻址“Accept encoding:”请求头。
Although the Web protocol, HTTP, is not itself capable of handling referrals, through the use of two extra variables this client is given the option of requesting referral information and then pursuing individual referrals through the Web DAG-CAP itself, as a proxy for those referrals. This is handled through the extra "control variables" to request referrals only, and to indicate when the transaction is a continuation of a previous query to pursue a referral.
尽管Web协议HTTP本身无法处理转介，但通过使用两个额外变量，该客户机可以选择请求转介信息，然后通过Web DAG-CAP自身进行个人转介，作为这些转介的代理。这是通过额外的“控制变量”来处理的，以仅请求转介，并指示何时事务是前一个查询的继续以进行转介。
There has been call to have a "machine-readable" version of the search output. As HTML is geared towards visual layout, user agents that intend to do something with the results other than present them in an HTML browser have few cues to use to extract the relevant information from the HTML page. Also, "minor" visual changes, accomplished with extensive HTML updates, can disrupt user agents that were built to blindly parse the original HTML. Therefore, provision has been made to return "raw" format results. These are requested by specifying "Accept-Content: application/whoispp-response" in the request header of the HTTP message to the HTTP DAG-CAP.
有人呼吁提供搜索输出的“机器可读”版本。由于HTML面向可视化布局，除了在HTML浏览器中显示结果之外，打算对结果进行处理的用户代理几乎没有从HTML页面提取相关信息的提示。此外，通过大量HTML更新完成的“微小”视觉变化可能会破坏为盲目解析原始HTML而构建的用户代理。因此，已规定返回“原始”格式的结果。通过在HTTP DAG-CAP的HTTP消息的请求头中指定“接受内容：应用程序/WHOISP响应”来请求这些内容。
The variables that are expected are:
预期的变量包括：
transaction = "new" / "chain" ; default is "new". This
; should not be user-settable. It is used
; in constructed URLs
resulttype = "all" / "referrals" ; default is "all"
matchtype = "substring" / "exact"
casetype = "case ignore" / "case sensitive"
n-term = string
o-term = string
l-term = string
r-term = string
host-term = string
port-term = string
servinfo-term = string
prot-term = string ; the protocol of the referral
string = <UNICODE-2-0-UTF-8> / <UNICODE-1-1-UTF-8> /
<ISO-8859-1>
transaction = "new" / "chain" ; default is "new". This
; should not be user-settable. It is used
; in constructed URLs
resulttype = "all" / "referrals" ; default is "all"
matchtype = "substring" / "exact"
casetype = "case ignore" / "case sensitive"
n-term = string
o-term = string
l-term = string
r-term = string
host-term = string
port-term = string
servinfo-term = string
prot-term = string ; the protocol of the referral
string = <UNICODE-2-0-UTF-8> / <UNICODE-1-1-UTF-8> /
<ISO-8859-1>
Querying a DAG-SAP Directly
直接查询DAG-SAP
If the transaction variable is "chain", the information in the POST is used to pursue a particular referral, not do a search of the Referral Index. The appropriate DAG-SAP (deduced from the prot-term) is contacted and issued the query directly.
如果交易变量为“链”，则帖子中的信息用于进行特定的转介，而不是搜索转介索引。联系相应的DAG-SAP（从prot术语推导）并直接发出查询。
Results from this type of query are always full results (i.e., not referrals).
此类查询的结果始终是完整结果（即，不是转介）。
Querying the Referral Index
查询转介索引
A key element of translating from the Web DAG-CAP input into the DAG/IP query format is to "tokenize" the input terms into single token elements for the DAG/IP query. For example, the n-term
将Web DAG-CAP输入转换为DAG/IP查询格式的一个关键要素是将输入项“标记化”为DAG/IP查询的单个标记元素。例如，n项
name= thinking cat
name=思维猫
is tokenized into 2 n-tokens:
被标记为2个n-标记：
thinking cat
思维猫
which are then mapped into the following in the DAG/IP query (dag-n-terms):
然后在DAG/IP查询（DAG-n-terms）中将其映射为以下内容：
FN=thinking and FN=cat
FN=思考，FN=猫
The same is true for the r-term, l-term and o-term.
r项、l项和o项也是如此。
The primary steps in translating the HTTP input into a DAG/IP query are:
将HTTP输入转换为DAG/IP查询的主要步骤如下：
translate encodings, if necessary tokenize the strings for each term construct the DAG/IP query from the resulting components, as described in more detail below
翻译编码，如有必要，标记每个术语的字符串，从结果组件构造DAG/IP查询，如下所述
DAG/IP constraints are constructed from the searchtype information in the query.
DAG/IP约束是根据查询中的searchtype信息构造的。
dag-matchtype = "search=" <matchtype> /
"search=substring" ; if matchtype not
; specified
dag-matchtype = "search=" <matchtype> /
"search=substring" ; if matchtype not
; specified
dag-casetype = "case=ignore" / ; if casetype not
; specified or
; casetype="case ignore"
"case=consider" ; if casetype=
; "case sensitive"
dag-casetype = "case=ignore" / ; if casetype not
; specified or
; casetype="case ignore"
"case=consider" ; if casetype=
; "case sensitive"
constraints = ":" dag-matchtype ";" dag-casetype
constraints = ":" dag-matchtype ";" dag-casetype
The terms for the DAG/IP query are constructed from the tokenized strings from the HTTP post input.
DAG/IP查询的术语是从HTTP post输入的标记化字符串构造的。
dag-n-terms = "FN=" n-token 0*( " and FN=" n-token)
dag-o-terms = "ORG=" o-token 0*( " and ORG=" o-token)
dag-l-terms = "LOC=" l-token 0*( " and LOC=" l-token)
dag-r-terms = "ROLE=" r-token 0*( " and ROLE=" r-token)
dag-n-terms = "FN=" n-token 0*( " and FN=" n-token)
dag-o-terms = "ORG=" o-token 0*( " and ORG=" o-token)
dag-l-terms = "LOC=" l-token 0*( " and LOC=" l-token)
dag-r-terms = "ROLE=" r-token 0*( " and ROLE=" r-token)
This means that the relevant DAG/IP queries are formulated as one of two types:
这意味着相关的DAG/IP查询被表述为两种类型之一：
dagip-query = ( ( ( n-query / nl-query / no-query / nol-query )
[" and template=DAGPERSON"]":" dag-matchtype
";" dag-casetype) /
( ( ro-query / rol-query )
[" and template=DAGORGROLE"]":" dag-matchtype
";" dag-casetype) )
dagip-query = ( ( ( n-query / nl-query / no-query / nol-query )
[" and template=DAGPERSON"]":" dag-matchtype
";" dag-casetype) /
( ( ro-query / rol-query )
[" and template=DAGORGROLE"]":" dag-matchtype
";" dag-casetype) )
n-query = dag-n-terms
n-query = dag-n-terms
nl-query = dag-n-terms " and " dag-l-terms no-query = dag-n-terms " and " dag-o-terms nol-query = dag-n-terms " and " dag-o-terms " and " dag-l-terms ro-query = dag-r-terms " and " dag-o-terms rol-query = dag-r-terms " and " dag-o-terms " and " dag-l-terms
nl查询=dag-n-terms和“dag-l-terms无查询=dag-n-terms”和“dag-o-terms nol查询=dag-n-terms”和“dag-o-terms”和“dag-l-terms ro查询=dag-r-terms”和“dag-o-terms”和“dag-l-terms”
Querying a DAG-SAP
查询DAG-SAP
In querying a DAG-SAP (irrespective of the protocol of that DAG-SAP), the DAG/IP query must include information about the target WDSP server. This information is drawn from the Referral Index SERVER-TO-ASK referral information, and is appended to the query as specified in Appendix C:
在查询DAG-SAP（不考虑该DAG-SAP的协议）时，DAG/IP查询必须包括有关目标WDSP服务器的信息。该信息取自参考索引服务器到询问参考信息，并按照附录C中的规定附加到查询中：
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
where the response from the Referral Index included:
其中，来自推荐索引的响应包括：
"# SERVER-TO-ASK " serverhandle <NL>
" Server-info: " serverinfo <NL>
" Host-Name: " hostname <NL>
" Host-Port: " number <NL>
" Protocol: " prot <NL>
" Source-URI: " source <NL>
" Charset: " charset <NL>
"# END" <NL>
"# SERVER-TO-ASK " serverhandle <NL>
" Server-info: " serverinfo <NL>
" Host-Name: " hostname <NL>
" Host-Port: " number <NL>
" Protocol: " prot <NL>
" Source-URI: " source <NL>
" Charset: " charset <NL>
"# END" <NL>
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
通过引用DAG/IP特殊字符，分别从“主机名”和“服务器信息”中获取“引用的主机名”和“引用的服务器信息”。
For example, the referral
例如，转介
# SERVER-TO-ASK dagsystem01<NL>
Server-info: o=thinkingcat, c=se<NL>
Host-Name: thinkingcat.com<NL>
Host-Port: 2839<NL>
Protocol: ldapv2<NL>
Source-URI: http://www.thinkingcat.com
Charset: T.61<NL>
# END<NL>
# SERVER-TO-ASK dagsystem01<NL>
Server-info: o=thinkingcat, c=se<NL>
Host-Name: thinkingcat.com<NL>
Host-Port: 2839<NL>
Protocol: ldapv2<NL>
Source-URI: http://www.thinkingcat.com
Charset: T.61<NL>
# END<NL>
would yield the addition
将产生加法
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
c\=se;charset=T\.61
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
c\=se;charset=T\.61
in its query to an LDAPv2 DAG-SAP
在其对LDAPv2 DAG-SAP的查询中
(N.B.: See Appendix C for further definitions of the terms used in the SERVER-TO-ASK response).
（注意：关于服务器对请求响应中使用的术语的进一步定义，请参见附录C）。
Note that it is the DAG-SAP's responsibility to extract these terms from the query and use them to identify the WDSP server to be contacted. See the individual DAG-SAP definitions, below.
请注意，DAG-SAP负责从查询中提取这些术语，并使用它们标识要联系的WDSP服务器。请参见下面的各个DAG-SAP定义。
If the resulttype was "all", all of the referrals received from the Referral Index are chained using the appropriate DAG-SAPs. If only referrals were requested, the Referral Index results are returned.
如果resulttype为“all”，则使用适当的DAG SAP链接从引用索引接收的所有引用。如果仅请求转介，则返回转介索引结果。
text/html results
文本/html结果
The default response encoding is text/html. If the resulttype was "all", the content of the chaining responses from the DAG-SAPs, without the system messages, is collated into a single page response, one result entry per demarcated line ( e.g., bullet item). The FN or ROLE value should be presented first and clearly. The SOURCE URI for each WDSP referral should be presented as an HREF for each of the WDSPs results.
默认的响应编码是text/html。如果resulttype为“all”，则来自DAG SAP的链接响应的内容（不包括系统消息）将整理为一个页面响应，每个标线（例如，项目符号项）有一个结果条目。FN或角色价值应首先明确提出。每个WDSP引用的源URI应显示为每个WDSP结果的HREF。
At the end of the message, the WDSP servers that failed to respond (i.e., the DAG-SAP handling the referral returned the "% 403 Information Unavailable" message) are listed with their server-info.
在消息末尾，未响应的WDSP服务器（即，处理转诊的DAG-SAP返回“%403信息不可用”消息）与其服务器信息一起列出。
If, however, the resulttype was "referrals", the results from the Referral Index are returned as HREF URLs to the Web DAG-CAP itself, with the necessary information to carry out the query (including the "HOST=", etc, for the referral).
但是，如果resulttype为“referrals”，则来自Referral Index的结果将作为HREF URL返回到Web DAG-CAP本身，并包含执行查询所需的信息（包括“HOST=”等，用于Referral）。
For example, if the original query:
例如，如果原始查询：
n-term="thinking cat" resulttype="referrals"
n-term=“思考猫”resulttype=“转介”
drew the following referral from the Referral Index:
从推荐索引中提取以下推荐：
# SERVER-TO-ASK DAG-Serverhandle<NL>
Server-Info: c=se, o=tce<NL>
# SERVER-TO-ASK DAG-Serverhandle<NL>
Server-Info: c=se, o=tce<NL>
Host-Name: answers.tce.com<NL>
Host-Port: 1111<NL>
Host-Name: answers.tce.com<NL>
Host-Port: 1111<NL>
Protocol: ldapv3<NL>
Source-URI: http://some.service.se/
Charset: UTF-8<NL>
# END<NL>
Protocol: ldapv3<NL>
Source-URI: http://some.service.se/
Charset: UTF-8<NL>
# END<NL>
the response would be an HTML page with an HREF HTTP "POST" URL to the Web DAG-CAP with the following variables set:
响应将是一个HTML页面，其中包含指向Web DAG-CAP的HREF HTTP“POST”URL，并设置了以下变量：
n-term="thinking cat"
transaction="chain"
servinfo-term="c=se, o=tce"
host-term="answers.tce.com"
port-term="1111"
prot-term="ldapv3"
n-term="thinking cat"
transaction="chain"
servinfo-term="c=se, o=tce"
host-term="answers.tce.com"
port-term="1111"
prot-term="ldapv3"
The Source-URI should be established in the response as its own HREF URI.
源URI应在响应中作为其自己的HREF URI建立。
application/whoispp-response Results
应用程序/WHOISP响应结果
If Accept-Encoding: " HTTP request header had the value "application/whoispp-response", the content of the HTTP response will be constructed in the same syntax and attribute mapping as for the Whois++ DAG-CAP.
如果Accept Encoding:“HTTP请求头的值为”application/Whoisp response”，则HTTP响应的内容将以与Whois++DAG-CAP相同的语法和属性映射进行构造。
If the resulttype was "all", all the referrals will have been chained by the Web DAG-CAP, and the response will include only full data records.
如果resulttype为“all”，则Web DAG-CAP将链接所有引用，并且响应将仅包括完整的数据记录。
If the resulttype was "referrals", then all referrals are passed directly back in a single response, in correct Whois++ referral format (conveniently, this is how they are formulated in the DAG/IP). Note that this will include referrals to LDAP-based services as well as Whois++ servers.
如果resulttype是“referrals”，那么所有的referrals都会在一个响应中以正确的Whois++referral格式直接传回（很方便，DAG/IP中就是这样表述的）。注意，这将包括对基于LDAP的服务以及Whois++服务器的引用。
A Web DAG-CAP may redirect a connection to another web DAG-CAP for reasons of load-balancing. This is done simply by using an HTTP redirect.
出于负载平衡的原因，Web DAG-CAP可能会将连接重定向到另一个Web DAG-CAP。这只需使用HTTP重定向即可完成。
Standard Errors
标准误差
If the web DAG-CAP receives a message that is not parsable using the query grammar described above, it sends an explanatory HTML page saying that the query could not be interpreted, and giving a description of valid queries.
如果web DAG-CAP接收到使用上述查询语法无法解析的消息，它将发送一个解释性HTML页面，说明无法解释该查询，并给出有效查询的说明。
If the number of referrals sent by the Referral Index is greater than the pre-determined maximum (for detecting data-mining efforts, or otherwise refusing over-general queries, such as "FN=svensson"), the web DAG-CAP will send a page with an explanatory message describing the "over-generalized query" problem, suggesting the user resubmit a more precise query, and describing the list of valid query types.
如果转诊索引发送的转诊数量大于预先确定的最大值（用于检测数据挖掘工作，或以其他方式拒绝过度一般查询，如“FN=svensson”），则web DAG-CAP将发送一个页面，其中包含描述“过度一般化查询”问题的解释性消息，建议用户重新提交更精确的查询，并描述有效查询类型的列表。
If the web DAG-CAP receives more than one result code from the DAG-SAPs, it must represent them all in a appropriate manner in the response.
如果web DAG-CAP从DAG SAP接收到多个结果代码，则必须在响应中以适当的方式表示所有结果代码。
application/whoispp-response Errors
应用程序/WHOISP响应错误
An invalid query is responded to with a simple text response with the error: "% 500 Syntax Error".
对无效查询的响应为简单文本响应，错误为：“%500语法错误”。
If too many referrals are generated from the Referral Index, the simple text response will have the message "% 503 Query too general".
如果从引用索引生成的引用太多，则简单文本响应将显示消息“%503 Query too general”。
TISDAG: The system commands polled-for/-by should elicit the empty set as a return value until we better understand the implications of doing otherwise.
TISDAG:poll for/-by的系统命令应该将空集作为返回值，直到我们更好地理解否则的含义。
Input to the Whois++ DAG-CAP follows the Whois++ standard ([6]). Minimally, the Whois++ DAG-CAP must support the following queries:
Whois++DAG-CAP的输入遵循Whois++标准（[6]）。Whois++DAG-CAP至少必须支持以下查询：
Query Type Expression in Whois++
----------- ------------------------------------
N One or more "name=" and
template=USER
Query Type Expression in Whois++
----------- ------------------------------------
N One or more "name=" and
template=USER
NL One or more "name=" and One or more "address-locality=" and template=USER
NL一个或多个“name=”和一个或多个“address locality=”和template=用户
NO One or more "name=" and one or more "organization-name=" and template=USER
没有一个或多个“name=”和一个或多个“organization name=”和template=用户
NOL One or more "name=" and one or more "organization-name=" and one or more "address-locality=" and template=USER
NOL一个或多个“name=”和一个或多个“organization name=”以及一个或多个“address locality=”和template=USER
RO One or more "org-role=" and one or more "organization-name=" and template=ORGROLE
RO一个或多个“org role=”和一个或多个“organization name=”和template=ORGROLE
ROL One or more "org-role=" and one or more "organization-name=" and one or more "address-locality=" and template=ORGROLE
ROL一个或多个“org role=”和一个或多个“organization name=”以及一个或多个“address locality=”和template=org role
Table 5.1 Allowable Whois++ Queries
表5.1允许的Whois++查询
The following constraints must be supported for queries:
查询必须支持以下约束：
"search=" (substring / exact)
"case=" (ignore / consider)
"search=" (substring / exact)
"case=" (ignore / consider)
If no constraints are defined in a query the default is exact and ignore. For example,
如果查询中未定义任何约束，则默认值为“精确”且“忽略”。例如
FN=foo and loc=kista and fn=bar<NL>
FN=foo and loc=kista and fn=bar<NL>
is a perfectly valid Whois++ NL query for "Foo Bar" in "Kista".
是对“Kista”中“Foo-Bar”的完全有效的Whois++NL查询。
Querying the Referral Index
查询转介索引
The Whois++ DAG-CAP formulates a DAG/IP query by forwarding the search terms received (as defined in Table 5.1).
Whois++DAG-CAP通过转发收到的搜索词（如表5.1所定义）来制定DAG/IP查询。
For example, the above query would be expressed as:
例如，上述查询将表示为：
FN=foo and LOC=kista and FN=bar and template=DAGPERSON<NL>
FN=foo and LOC=kista and FN=bar and template=DAGPERSON<NL>
Querying a DAG-SAP
查询DAG-SAP
In querying a DAG-SAP (irrespective of the protocol of that DAG-SAP), the DAG/IP query must include information about the target WDSP server. This information is drawn from the Referral Index SERVER-TO-ASK referral information, and is appended to the query as specified in appendix C:
在查询DAG-SAP（不考虑该DAG-SAP的协议）时，DAG/IP查询必须包括有关目标WDSP服务器的信息。该信息取自参考索引服务器到询问参考信息，并按照附录C中的规定附加到查询中：
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
where the response from the Referral Index included:
其中，来自推荐索引的响应包括：
"# SERVER-TO-ASK " serverhandle<NL>
" Server-info: " serverinfo<NL>
" Host-Name: " hostname<NL>
" Host-Port: " number<NL>
" Protocol: " prot<NL>
" Source-URI: " source<NL>
" Charset: " charset<NL>
"# END"<NL>
"# SERVER-TO-ASK " serverhandle<NL>
" Server-info: " serverinfo<NL>
" Host-Name: " hostname<NL>
" Host-Port: " number<NL>
" Protocol: " prot<NL>
" Source-URI: " source<NL>
" Charset: " charset<NL>
"# END"<NL>
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
通过引用DAG/IP特殊字符，分别从“主机名”和“服务器信息”中获取“引用的主机名”和“引用的服务器信息”。
For example, the referral
例如，转介
# SERVER-TO-ASK dagsystem01<NL>
Server-info: o=thinkingcat, c=se<NL>
Host-Name: thinkingcat.com<NL>
Host-Port: 2839<NL>
Protocol: ldapv2<NL>
Source-URI: http://www.thinkingcat.com/
Charset: T.61<NL>
# END<NL>
# SERVER-TO-ASK dagsystem01<NL>
Server-info: o=thinkingcat, c=se<NL>
Host-Name: thinkingcat.com<NL>
Host-Port: 2839<NL>
Protocol: ldapv2<NL>
Source-URI: http://www.thinkingcat.com/
Charset: T.61<NL>
# END<NL>
would yield the addition
将产生加法
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
c\=se;charset=T\.61
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
c\=se;charset=T\.61
in its query to an LDAPv2 DAG-SAP.
在其对LDAPv2 DAG-SAP的查询中。
(N.B.: See Appendix C for further definitions of the terms used in the SERVER-TO-ASK response).
（注意：关于服务器对请求响应中使用的术语的进一步定义，请参见附录C）。
Note that it is the DAG-SAP's responsibility to extract these terms from the query and use them to identify the WDSP server to be contacted. See the individual DAG-SAP definitions, below.
请注意，DAG-SAP负责从查询中提取这些术语，并使用它们标识要联系的WDSP服务器。请参见下面的各个DAG-SAP定义。
The Whois++ DAG-CAP relies on DAG-SAPs to chain any non-Whois++ referrals (currently, the LDAPv2 and LDAPv3 DAG-SAPs).
Whois++DAG-CAP依赖DAG SAP链接任何非Whois++转介（目前为LDAPv2和LDAPv3 DAG SAP）。
Results are expressed in Whois++ by collating the DAG/IP results received from DAG-SAPs (using the FULL response), and using the template and attribute mappings defined in Appendix B. For each result from a given referral, the SOURCE attribute is added, with the value of the SOURCE-URI from the referral.
通过整理从DAG SAP接收到的DAG/IP结果（使用完整响应），并使用附录B中定义的模板和属性映射，结果以Whois++表示。对于给定引用的每个结果，将添加源属性以及引用的源URI值。
Any referrals to other Whois++ servers provided by the Referral Index are sent directly to the Whois++ client as follows:
由转介索引提供的对其他Whois++服务器的任何转介将直接发送到Whois++客户端，如下所示：
server-to-ask = "# SERVER-TO-ASK " DAG-Serverhandle<NL>
" Server-Handle: " SERVER-INFO<NL>
" Host-Name: " HOST<NL>
" Host-Port: " PORT<NL>
" Protocol: " PROTOCOL<NL>
"# END"<NL>
server-to-ask = "# SERVER-TO-ASK " DAG-Serverhandle<NL>
" Server-Handle: " SERVER-INFO<NL>
" Host-Name: " HOST<NL>
" Host-Port: " PORT<NL>
" Protocol: " PROTOCOL<NL>
"# END"<NL>
where SERVER-INFO, HOST, PORT, PROTOCOL are drawn from the referral provided in the DAG/IP, and the SOURCE-URI information is lost.
其中，从DAG/IP中提供的引用中提取服务器信息、主机、端口和协议，并且源URI信息丢失。
As appropriate, the Whois++ DAG-CAP will express operational errors following the Whois++ standard. There are 4 particular error conditions of the DAG system that the DAG-CAP will handle as described below.
根据需要，Whois++DAG-CAP将按照Whois++标准表示操作错误。DAG-CAP将按如下所述处理DAG系统的4种特殊错误情况。
When the Whois++ DAG-CAP receives a query that it cannot reply to within the (data) constraints of the DAG, it sends an error message and closes the connection. The error message includes
当Whois++DAG-CAP收到无法在DAG的（数据）约束范围内答复的查询时，它将发送错误消息并关闭连接。错误消息包括
% 502 Search expression too complicated<NL>
%502搜索表达式太复杂<NL>
If the number of referrals sent by the Referral Index is greater than the pre-determined maximum (for detecting data-mining efforts, or otherwise refusing over-general queries, such as "FN=svensson"), the Whois++ DAG-CAP will send an error message and close the connection. The error message includes
如果转诊索引发送的转诊数量大于预先确定的最大值（用于检测数据挖掘工作，或以其他方式拒绝常规查询，如“FN=svensson”），Whois++DAG-CAP将发送错误消息并关闭连接。错误消息包括
% 503 Query too general<NL>
%503查询太笼统<NL>
(N.B.: this is different from the "Too many hits" reply, which does send partial results.)
（注意：这与“点击次数过多”的回复不同，后者会发送部分结果。）
A Whois++ DAG-CAP may redirect a connection to another Whois++ DAG-CAP for reasons of load-balancing. This is expressed to the end-user client software using the SERVER-TO-ASK response with appropriate information to reach the designated alternate DAG-CAP.
出于负载平衡的原因，Whois++DAG-CAP可能会将连接重定向到另一个Whois++DAG-CAP。使用服务器对请求的响应以及适当的信息向最终用户客户端软件表示，以达到指定的备用DAG-CAP。
If a Whois++ DAG-CAP receives several different response codes from DAG-SAPs it should try to represent them all in the response to the end-user client.
如果Whois++DAG-CAP从DAG SAP接收到多个不同的响应代码，则应尝试在对最终用户客户端的响应中表示这些代码。
The proposed mapping between DAG/IP response codes and Whois++ response codes are given in Appendix D.
附录D中给出了DAG/IP响应代码和Whois++响应代码之间的拟议映射。
Input to the LDAPv2 DAG-CAP follows the LDAPv2 standard ([19]). Minimally, the LDAPv2 DAG-CAP must support the following queries (adapted from the ASN.1 grammar of the standard):
LDAPv2 DAG-CAP的输入遵循LDAPv2标准（[19]）。LDAPv2 DAG-CAP至少必须支持以下查询（改编自标准ASN.1语法）：
BindRequest ::=
[APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication CHOICE {
simple [0] OCTET STRING,
krbv42LDAP [1] OCTET STRING,
krbv42DSA [2] OCTET STRING
}
BindRequest ::=
[APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication CHOICE {
simple [0] OCTET STRING,
krbv42LDAP [1] OCTET STRING,
krbv42DSA [2] OCTET STRING
}
}
}
BindResponse ::= [APPLICATION 1] LDAPResult
BindResponse ::= [APPLICATION 1] LDAPResult
SearchRequest ::=
[APPLICATION 3] SEQUENCE {
baseObject "dc=se",
scope wholeSubtree (2),
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3)
},
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
attrsOnly BOOLEAN,
filter Filter,
SearchRequest ::=
[APPLICATION 3] SEQUENCE {
baseObject "dc=se",
scope wholeSubtree (2),
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3)
},
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
attrsOnly BOOLEAN,
filter Filter,
attributes SEQUENCE OF AttributeType }
AttributeType的属性序列}
Filter ::=
CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter
}
Filter ::=
CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter
}
SubstringFilter ::=
SEQUENCE {
type AttributeType,
SEQUENCE OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString
}
}
SubstringFilter ::=
SEQUENCE {
type AttributeType,
SEQUENCE OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString
}
}
Queries against attributes in the prescribed LDAP standard schema (see Appendix B) are accepted.
接受对指定LDAP标准模式（见附录B）中属性的查询。
N.B., this is a minimal set of supported queries, to achieve the basic DAG-defined queries. An LDAP DAG-CAP may choose to support more complex queries than this, if it undertakes to do the translation from the DAG/IP to the LDAPv2 client in a way that responds to the semantics of those queries.
注意，这是一组最小的受支持查询，用于实现基本的DAG定义查询。如果LDAP DAG-CAP承诺以响应这些查询语义的方式将DAG/IP转换为LDAPv2客户端，则可以选择支持比这更复杂的查询。
TISDAG: Since LDAPv2 didn't specify any characterset but relied on X.500 to do so, in practice several different charactersets are in use in Sweden today. That the LDAPv2 CAP has no way of knowing which characterset that are in use by a connecting client is a problem that the TISDAG project can not solve.
TISDAG：由于LDAPv2没有指定任何字符集，而是依赖于X.500来指定，因此在实践中，今天瑞典使用了几种不同的字符集。LDAPv2 CAP无法知道连接客户端正在使用哪个字符集，这是TISDAG项目无法解决的问题。
Users of the DAG system will have to configure their specific client according to information on the TISDAG web page. That page provides very specific information (including port number) that can be given to LDAPv2 users. The LDAP DAG-CAP listening on the default port (389) will be the LDAPv3 one.
DAG系统的用户必须根据TISDAG网页上的信息配置其特定客户端。该页面提供了可以提供给LDAPv2用户的非常具体的信息（包括端口号）。在默认端口（389）上侦听的LDAP DAG-CAP将是LDAPv3端口。
Querying the Referral Index
查询转介索引
The essential stratagem for mapping LDAP queries into DAG/IP Referral Index queries is to tokenize the string-oriented LDAP AttributeValueAssertions or SubstringFilters and construct an appropriate DAG/IP token-oriented query in the DAG/IP. This will generalize the LDAP query and yield false-positive referrals, but should not miss any appropriate referrals.
将LDAP查询映射到DAG/IP引用索引查询的基本策略是标记面向字符串的LDAP AttributeValue断言或子字符串筛选器，并在DAG/IP中构造适当的面向DAG/IP令牌的查询。这将泛化LDAP查询并产生假阳性的引用，但不应错过任何适当的引用。
There are 3 particular cases to be considered:
有3种特殊情况需要考虑：
equalityMatch queries substring queries combination equalityMatch and substring queries
equalityMatch查询子字符串查询equalityMatch和子字符串查询的组合
TISDAG: If the LDAP filter contains a cn-term and no objectclass specification it is unclear if the search is for a person or a role. When this happens the DAG query should cover all bases and map the query into a query for both people and roles.
TISDAG：如果LDAP筛选器包含cn术语且没有objectclass规范，则不清楚搜索是针对个人还是角色。发生这种情况时，DAG查询应覆盖所有基础，并将查询映射为针对人员和角色的查询。
EqualityMatch queries can be handled by simply tokenizing the AttributeValueAssertions, making one DAG/IP query term per token (using the appropriate DAGSchema attribute) and carrying out an exact match in the DAG/IP.
EqualityMatch查询可以通过简单地标记AttributeValueAssertions、为每个标记生成一个DAG/IP查询项（使用适当的DAGSchema属性）并在DAG/IP中执行精确匹配来处理。
Consider the following example, represented in the ASCII expression of LDAP Filters as described in [13]):
考虑下面的示例，如在[13 ]中描述的LDAP过滤器的ASCII表达式中表示的：
(& (cn=Foo Bar)(objectclass=inetOrgPerson))
(& (cn=Foo Bar)(objectclass=inetOrgPerson))
This query can be represented in the DAG/IP as
此查询可以在DAG/IP中表示为
FN="Foo" and FN="Bar":search=exact<NL>
FN="Foo" and FN="Bar":search=exact<NL>
N.B. The search is set up to be "case=ignore" (the DAG/IP's default) because the relevant LDAP schema attributes are all derivatives of the "name" attribute element, which is defined to have a case insensitive match.
注意：搜索设置为“case=ignore”（DAG/IP的默认值），因为相关LDAP架构属性都是“name”属性元素的派生，该属性元素定义为不区分大小写的匹配。
If no objectclass were defined the query in DAG/IP would have been
如果未定义objectclass，则DAG/IP中的查询将被删除
(FN="Foo" and FN="bar") or (ROLE="Foo" and ROLE="bar"):search=exact
(FN="Foo" and FN="bar") or (ROLE="Foo" and ROLE="bar"):search=exact
inetOrgPerson is used as the objectclass in this and the following examples, although person or organizationalPerson could also have been used.
inetOrgPerson在本例和以下示例中用作对象类，但也可以使用person或organizationalPerson。
This query will yield false-positive referrals; the original LDAP query should only match against records for which the "cn" attribute is exactly the phrase "Foo Bar", whereas the DAG/IP query will yield referrals any WDSP containing records that include the two tokens "foo" and "bar" in any order.
此查询将产生假阳性转介；原始LDAP查询应仅与“cn”属性正好是短语“Foo-Bar”的记录匹配，而DAG/IP查询将生成任何包含记录的WDSP的引用，这些记录包含任意顺序的两个标记“Foo”和“Bar”。
For example, this DAG/IP query will yield referrals to WDSPs with records including:
例如，此DAG/IP查询将产生对WDSP的转介，其记录包括：
cn: Bar Foo cn: Le Bar Foo cn: Foo Bar AB
cn:Bar-Foo cn:Le-Bar-Foo cn:Foo-Bar AB
LDAP substring queries must also be tokenized in order to construct a DAG/IP query. The additional point to bear in mind is that LDAP substring expressions are directed at phrases, which obscure potential token boundaries. Consequently, all points between substring components must be considered as potential token boundaries.
为了构造DAG/IP查询，LDAP子字符串查询也必须标记化。需要记住的另一点是，LDAP子字符串表达式指向短语，这会模糊潜在的标记边界。因此，子字符串组件之间的所有点都必须视为潜在的令牌边界。
Thus, the LDAP query
因此，LDAP查询
(& (cn=black) (o=c*t) (objectclass=inetOrgPerson))
(& (cn=black) (o=c*t) (objectclass=inetOrgPerson))
could be expressed as a DAG/IP query with 3 tokens, in a substring search:
在子字符串搜索中，可以表示为带有3个标记的DAG/IP查询：
FN=black and ORG=c and ORG=t:search=substring<NL>
FN=black and ORG=c and ORG=t:search=substring<NL>
This query will yield false-positive results as the tokenized query does not preserve the order of appearance in the LDAP substring, and it doesn't preserve phrase-boundaries. That is,
此查询将产生假阳性结果，因为标记化查询不保留LDAP子字符串中的出现顺序，也不保留短语边界。就是，
ORG=c and ORG=t:search=substring
ORG=c and ORG=t:search=substring
will match
将匹配
tabacco
烟草
which is not a match by the LDAP query semantics.
这与LDAP查询语义不匹配。
Combined EqualityMatch and Substring queries need special attention. When an LDAP query includes both EqualityMatch components and substring filter components, the DAG/IP query to the Referral Index
需要特别注意EqualityMatch和子字符串查询的组合。当LDAP查询同时包含EqualityMatch组件和子字符串筛选器组件时，DAG/IP查询将返回到引用索引
can be constructed by following the same mechanisms of tokenization, but the whole search will become a substring search, as the DAG/IP defines only search types across the entire query for Referral Index queries.
可以通过遵循相同的标记化机制来构造，但整个搜索将成为子字符串搜索，因为DAG/IP仅在整个查询中为引用索引查询定义搜索类型。
Thus,
因此
(& (cn=Foo Bar) (o=c*t) (objectclass=inetOrgPerson))
(& (cn=Foo Bar) (o=c*t) (objectclass=inetOrgPerson))
can be expressed as
可以表示为
FN=Foo and FN=Bar and ORG=c and ORG=t:search=substring<NL>
FN=Foo and FN=Bar and ORG=c and ORG=t:search=substring<NL>
Alternatively, the LDAP DAG-CAP could conduct two separate queries and take the intersection (the logical "AND") of the two sets of referrals returned by the Referral Index.
或者，LDAP DAG-CAP可以执行两个单独的查询，并获取由引用索引返回的两组引用的交集（逻辑“and”）。
Note that DAG/IP can accept phrases for searches -- the query
请注意，DAG/IP可以接受用于搜索的短语——查询
FN=Foo\ bar<NL> (note the escaped space)
FN=Foo\ bar<NL> (note the escaped space)
is perfectly valid. However, it would match only those things which have been tokenized in a way that preserves the space, which is the empty set in the case of the data stored here.
这是完全正确的。然而，它将只匹配那些以保留空间的方式标记的东西，对于存储在这里的数据来说，空间是空集。
Querying a DAG-SAP
查询DAG-SAP
It is never invalid to use the same substantive query to a DAG-SAP as was used to obtain referral information from the Referral Index. However, the over-generalization of these queries may yield excessive numbers of results, and will necessitate some pruning of results in order to match the returned results against the semantics of the original LDAP query. It is the LDAP DAG-CAP that is responsible for this pruning, as it is the recipient of the original query, and responsible for responding to its semantics.
对DAG-SAP使用与从转诊索引获取转诊信息相同的实质性查询从来都不是无效的。但是，这些查询的过度泛化可能会产生过多的结果，并且需要对结果进行一些修剪，以便将返回的结果与原始LDAP查询的语义相匹配。LDAP DAG-CAP负责此修剪，因为它是原始查询的接收者，并负责响应其语义。
In concrete terms, when making the DAG/IP query which is to be sent to a DAG-SAP the above mentioned queries are still valid queries, but an alternative finer-grained query is also possible, namely:
具体而言，在进行DAG/IP查询（将发送到DAG-SAP）时，上述查询仍然是有效的查询，但也可以使用另一种更细粒度的查询，即：
FN=foo and FN=bar and ORG=c;search=lstring and ORG=t;search=tstring
FN=foo and FN=bar and ORG=c;search=lstring and ORG=t;search=tstring
Particularly in the case of the LDAPv2 DAG-CAP, however, there will be cause to use LDAP(v2/v3) DAG-SAPs. Since these DAG-SAPs also deal in phrase-oriented data, a less-over-generalized query can be passed to them:
特别是在LDAPv2 DAG-CAP的情况下，使用LDAP（v2/v3）DAG SAP是有原因的。由于这些DAG SAP还处理面向短语的数据，因此可以向它们传递一个不太通用的查询：
FN=Foo\ Bar:search=exact<NL>
FN=Foo\ Bar:search=exact<NL>
In querying a DAG-SAP (irrespective of the protocol of that DAG-SAP), the DAG/IP query must include information about the target WDSP server. This information is drawn from the Referral Index SERVER-TO-ASK referral information, and is appended to the query as specified in Appendix C:
在查询DAG-SAP（不考虑该DAG-SAP的协议）时，DAG/IP查询必须包括有关目标WDSP服务器的信息。该信息取自参考索引服务器到询问参考信息，并按照附录C中的规定附加到查询中：
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
where the response from the Referral Index included:
其中，来自推荐索引的响应包括：
"# SERVER-TO-ASK " serverhandle<NL>
" Server-info: " serverinfo<NL>
" Host-Name: " hostname<NL>
" Host-Port: " number<NL>
" Protocol: " prot<NL>
" Source-URI: " source<NL>
" Charset: " charset<NL>
"# END<NL>
"# SERVER-TO-ASK " serverhandle<NL>
" Server-info: " serverinfo<NL>
" Host-Name: " hostname<NL>
" Host-Port: " number<NL>
" Protocol: " prot<NL>
" Source-URI: " source<NL>
" Charset: " charset<NL>
"# END<NL>
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
通过引用DAG/IP特殊字符，分别从“主机名”和“服务器信息”中获取“引用的主机名”和“引用的服务器信息”。
For example, the referral
例如，转介
# SERVER-TO-ASK dagsystem01<NL>
Server-info: o=thinkingcat, c=se<NL>
Host-Name: thinkingcat.com<NL>
Host-Port: 2839<NL>
Protocol: ldapv2<NL>
Source-URI: http://www.thinkingcat.com <NL>
Charset: T.61<NL>
# END<NL>
# SERVER-TO-ASK dagsystem01<NL>
Server-info: o=thinkingcat, c=se<NL>
Host-Name: thinkingcat.com<NL>
Host-Port: 2839<NL>
Protocol: ldapv2<NL>
Source-URI: http://www.thinkingcat.com <NL>
Charset: T.61<NL>
# END<NL>
would yield the addition
将产生加法
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
c\=se;charset=T\.61
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
c\=se;charset=T\.61
in its query to an LDAPv2 DAG-SAP.
在其对LDAPv2 DAG-SAP的查询中。
(N.B.: See Appendix C for further definitions of the terms used in the SERVER-TO-ASK response).
（注意：关于服务器对请求响应中使用的术语的进一步定义，请参见附录C）。
Note that it is the DAG-SAP's responsibility to extract these terms from the query and use them to identify the WDSP server to be contacted. See the individual DAG-SAP definitions, below.
请注意，DAG-SAP负责从查询中提取这些术语，并使用它们标识要联系的WDSP服务器。请参见下面的各个DAG-SAP定义。
The LDAPv2 DAG-CAP relies on DAG-SAPs to resolve every referral.
LDAPv2 DAG-CAP依靠DAG SAP来解决每次转诊。
As described above, results from DAG-SAPs will have to be post-processed in cases where the original query was generalized for expression in DAG/IP.
如上所述，如果原始查询被泛化为DAG/IP中的表达式，则必须对来自DAG SAPs的结果进行后处理。
Acceptable results are expressed in the LDAP search response:
可接受的结果在LDAP搜索响应中表示：
SearchResponse ::=
CHOICE {
entry [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes SEQUENCE OF SEQUENCE
{
AttributeType,
SET OF AttributeValue
}
},
resultCode [APPLICATION 5] LDAPResult
}
SearchResponse ::=
CHOICE {
entry [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes SEQUENCE OF SEQUENCE
{
AttributeType,
SET OF AttributeValue
}
},
resultCode [APPLICATION 5] LDAPResult
}
where
哪里
LDAPDN = DN / "cn=" (FN/ROLE) [",o="ORG] ",dc=se"
attributes = <all attributes mapped from DAG schema, and
"objectClass = inetOrgPerson",
"objectClass = top",
"objectClass = person" or
"objectClass = organizationalRole", as
appropriate, and "labeledURI = <SOURCE-URI>"
for each result from a given referral>
LDAPDN = DN / "cn=" (FN/ROLE) [",o="ORG] ",dc=se"
attributes = <all attributes mapped from DAG schema, and
"objectClass = inetOrgPerson",
"objectClass = top",
"objectClass = person" or
"objectClass = organizationalRole", as
appropriate, and "labeledURI = <SOURCE-URI>"
for each result from a given referral>
(Where DN,FN,ORG and ROLE are the values from the DAG schema).
（其中DN、FN、ORG和ROLE是DAG模式中的值）。
I.e., where available, the entry's true DN is used; otherwise (e.g., for data coming from Whois++ servers), a reasonable facsimile is constructed.
即，在可用的情况下，使用条目的真实DN；否则（例如，对于来自Whois++服务器的数据），将构造合理的传真。
As appropriate, the LDAPv2 DAG-CAP will express system responses following the LDAPv2 standard.
根据需要，LDAPv2 DAG-CAP将根据LDAPv2标准表达系统响应。
Appendix D gives the proposed mapping between DAG/IP response codes and LDAPv2 resultcodes.
附录D给出了DAG/IP响应代码和LDAPv2结果代码之间的拟议映射。
There are 4 particular error conditions of the DAG system that the DAG-CAP will handle as described below.
DAG-CAP将按如下所述处理DAG系统的4种特殊错误情况。
When the LDAPv2 DAG-CAP receives a query that it cannot reply to within the (data) constraints of the DAG queries, it sends an error message and closes the connection. The error message includes the LDAPv2 resultCode:
当LDAPv2 DAG-CAP接收到无法在DAG查询的（数据）约束范围内答复的查询时，它将发送错误消息并关闭连接。错误消息包括LDAPv2结果代码：
noSuchAttribute (for incorrect schema attributes) inappropriateMatching (when a match type other than those supported is used, e.g. approxMatch) unwillingToPerform (when the query is not one of the defined types)
noSuchAttribute（对于不正确的架构属性）不适当匹配（当使用了不支持的匹配类型时，例如approxMatch）不愿意操作（当查询不是定义的类型之一时）
If the number of referrals sent by the Referral Index is greater than the pre-determined maximum (for detecting data-mining efforts, or otherwise refusing over-general queries, such as "FN=svensson"), the LDAPv2 DAG-CAP will send an error message. The error message includes one of the following resultCodes:
如果转诊索引发送的转诊数量大于预先确定的最大值（用于检测数据挖掘工作，或以其他方式拒绝常规查询，如“FN=svensson”），LDAPv2 DAG-CAP将发送错误消息。错误消息包括以下结果代码之一：
sizeLimitExceeded timeLimitExceeded
尺寸超出了时间限制
An LDAPv2 DAG-CAP may redirect a connection to another LDAPv2 DAG-CAP for reasons of load-balancing. This is expressed to the end-user client software using the "umich referral" convention to direct the client software to an alternate DAG-CAP by passing the URL in an error message.
出于负载平衡的原因，LDAPv2 DAG-CAP可能会将连接重定向到另一个LDAPv2 DAG-CAP。这通过使用“umich参考”约定向最终用户客户端软件表示，通过在错误消息中传递URL将客户端软件定向到备用DAG-CAP。
Since a LDAPv2 DAG-CAP only can send one resultcode back to a client; If a LDAPv2 DAG-CAP receives several different result codes from the DAG-SAPs it will have to construct a resultmessage that to some extent represents the combination of those. It is proposed that in these cases the following actions are taken:
由于LDAPv2 DAG-CAP只能将一个结果代码发送回客户端；如果LDAPv2 DAG-CAP从DAG SAP接收到多个不同的结果代码，则必须构造一个结果消息，在某种程度上表示这些代码的组合。建议在这些情况下采取以下行动：
- All the response codes are collected - Each response code are translated into the corresponding LDAPv2 resultcode. - A resultcode is chosen to represent the collected response on the following grounds: If "success" is the only resultcode represented after these steps the return that result code. If apart from "success" there is one other resultcode represented return that other resultcode.
- 收集所有响应代码-将每个响应代码转换为相应的LDAPv2 resultcode。-选择resultcode来表示收集的响应，理由如下：如果“success”是这些步骤之后表示的唯一resultcode，则返回该结果代码。如果除了“success”之外，还有一个resultcode表示返回另一个resultcode。
If apart from "success" there are two or more resultcodes represented return the resultcode "other".
如果除了“success”之外，还有两个或多个resultcode表示返回resultcode“other”。
Input to the LDAPv3 DAG-CAP follows the LDAPv3 definition (currently defined in [17]). Minimally, the LDAPv3 DAG-CAP must support the following queries (adapted from the ASN.1 grammar of the standard):
LDAPv3 DAG-CAP的输入遵循LDAPv3定义（当前定义见[17]）。LDAPv3 DAG-CAP至少必须支持以下查询（改编自标准的ASN.1语法）：
BindRequest ::= [APPLICATION 0] SEQUENCE {
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127), name LDAPDN, authentication AuthenticationChoice }
版本整数（1..127），名称LDAPDN，身份验证选择}
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials }
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials }
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject c=se,
scope wholeSubtree (2) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeDescriptionList }
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject c=se,
scope wholeSubtree (2) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeDescriptionList }
Filter ::= CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter }
Filter ::= CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter }
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
-- at least one must be present
substrings initial [0] LDAPString,
substrings any [1] LDAPString,
substrings final [2] LDAPString}
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
-- at least one must be present
substrings initial [0] LDAPString,
substrings any [1] LDAPString,
substrings final [2] LDAPString}
Queries against attributes in the proscribed LDAP standard schema (see Appendix B) are accepted.
接受对被禁止的LDAP标准模式（见附录B）中的属性的查询。
N.B., this is a minimal set of supported queries, to achieve the basic DAG-defined queries. An LDAP DAG-CAP may choose to support more complex queries than this, if it undertakes to do the translation from the DAG/IP to the LDAPv3 client in a way that responds to the semantics of those queries.
注意，这是一组最小的受支持查询，用于实现基本的DAG定义查询。如果LDAP DAG-CAP承诺以响应这些查询语义的方式将DAG/IP转换为LDAPv3客户机，则可以选择支持比这更复杂的查询。
Querying the Referral Index
查询转介索引
The essential stratagem for mapping LDAP queries into DAG/IP Referral Index queries is to tokenize the string-oriented LDAP AttributeValueAssertions or SubstringFilters and construct an appropriate DAG/IP token-oriented query in the DAGschema. This will generalize the LDAP query and yield false-positive referrals, but should not miss any appropriate referrals.
将LDAP查询映射到DAG/IP引用索引查询的基本策略是将面向字符串的LDAP AttributeValueAssertions或SubstringFilters标记化，并在DAGschema中构造适当的面向DAG/IP标记的查询。这将泛化LDAP查询并产生假阳性的引用，但不应错过任何适当的引用。
There are 3 particular cases to be considered:
有3种特殊情况需要考虑：
equalityMatch queries substring queries combination equalityMatch and substring queries
equalityMatch查询子字符串查询equalityMatch和子字符串查询的组合
TISDAG: If the LDAP filter contains a cn-term and no objectclass specification it is unclear if the search is for a person or a role. When this happens the DAG query should cover all bases and map the query into a query for both people and roles.
TISDAG：如果LDAP筛选器包含cn术语且没有objectclass规范，则不清楚搜索是针对个人还是角色。发生这种情况时，DAG查询应覆盖所有基础，并将查询映射为针对人员和角色的查询。
EqualityMatch queries can be handled by simply tokenizing the AttributeValueAssertions, making one DAG/IP query term per token (using the appropriate DAGSchema attribute) and carrying out an exact match in the DAG/IP.
EqualityMatch查询可以通过简单地标记AttributeValueAssertions、为每个标记生成一个DAG/IP查询项（使用适当的DAGSchema属性）并在DAG/IP中执行精确匹配来处理。
Consider the following example, represented in the ASCII expression of LDAP Filters as described in [13]):
考虑下面的示例，如在[13 ]中描述的LDAP过滤器的ASCII表达式中表示的：
(& (cn=Foo Bar)(objectclass=person))
(& (cn=Foo Bar)(objectclass=person))
This query can be represented in the DAG/IP as
此查询可以在DAG/IP中表示为
FN="Foo" and FN="Bar":search=exact<NL>
FN="Foo" and FN="Bar":search=exact<NL>
N.B. The search is set up to be "case=ignore" (the DAG/IP's default) because the relevant LDAP schema attributes are all derivatives of the "name" attribute element, which is defined to have a case insensitive match.
注意：搜索设置为“case=ignore”（DAG/IP的默认值），因为相关LDAP架构属性都是“name”属性元素的派生，该属性元素定义为不区分大小写的匹配。
If no objectclass where defined the query in DAG/IP would have been
如果没有在DAG/IP中定义的objectclass，则会创建查询
(FN="Foo" and FN="bar") or ( ROLE="Foo" and ROLE="bar"):search=exact
(FN="Foo" and FN="bar") or ( ROLE="Foo" and ROLE="bar"):search=exact
Although person is used as objectclass in this and the following examples, inetOrgPerson or organizationalPerson could also have been used.
尽管在本例和以下示例中person用作对象类，但也可以使用inetOrgPerson或organizationalPerson。
This query will yield false-positive referrals; the original LDAP query should only match against records for which the "cn" attribute is exactly the phrase "Foo Bar", whereas the DAG/IP query will yield referrals any WDSP containing records that include the two tokens "foo" and "bar" in any order.
此查询将产生假阳性转介；原始LDAP查询应仅与“cn”属性正好是短语“Foo-Bar”的记录匹配，而DAG/IP查询将生成任何包含记录的WDSP的引用，这些记录包含任意顺序的两个标记“Foo”和“Bar”。
For example, this DAG/IP query will yield referrals to WDSPs with records including:
例如，此DAG/IP查询将产生对WDSP的转介，其记录包括：
cn: Bar Foo cn: Le Bar Foo cn: Foo Bar AB
cn:Bar-Foo cn:Le-Bar-Foo cn:Foo-Bar AB
LDAP substring queries must also be tokenized in order to construct a DAG/IP query. The additional point to bear in mind is that LDAP substring expressions are directed at phrases, which obscure potential token boundaries. Consequently, all points between substring components must be considered as potential token boundaries.
为了构造DAG/IP查询，LDAP子字符串查询也必须标记化。需要记住的另一点是，LDAP子字符串表达式指向短语，这会模糊潜在的标记边界。因此，子字符串组件之间的所有点都必须视为潜在的令牌边界。
Thus, the LDAP query
因此，LDAP查询
(& (cn=black) o=c*t) (objectclass=person))
(& (cn=black) o=c*t) (objectclass=person))
should be expressed as a DAG/IP query with 3 tokens, in a substring search:
在子字符串搜索中，应表示为带有3个标记的DAG/IP查询：
FN=black and ORG=c and ORG=t:search=substring<NL>
FN=black and ORG=c and ORG=t:search=substring<NL>
This query will yield false-positive results as the tokenized query does not preserve the order of appearance in the LDAP substring, and it doesn't preserve phrase-boundaries. That is,
此查询将产生假阳性结果，因为标记化查询不保留LDAP子字符串中的出现顺序，也不保留短语边界。就是，
ORG=c and ORG=t:search=substring
ORG=c and ORG=t:search=substring
will match
将匹配
tabacco
烟草
which is not a match by the LDAP query semantics.
这与LDAP查询语义不匹配。
Combined EqualityMatch and Substring queries need special attention. When an LDAP query includes both EqualityMatch components and substring filter components, the DAG/IP query to the Referral Index can be constructed by following the same mechanisms of tokenization, but the whole search will become a substring search, as the DAG/IP defines search types across the entire query.
需要特别注意EqualityMatch和子字符串查询的组合。当LDAP查询同时包含EqualityMatch组件和子字符串筛选器组件时，可以通过遵循相同的标记化机制来构造对引用索引的DAG/IP查询，但整个搜索将成为子字符串搜索，因为DAG/IP定义了整个查询的搜索类型。
Thus,
因此
(& (cn=Foo Bar) (o=c*t) (objectclass=person))
(& (cn=Foo Bar) (o=c*t) (objectclass=person))
can be expressed as
可以表示为
FN=Foo and FN=Bar and ORG=c and ORG=t:search=substring<NL>
FN=Foo and FN=Bar and ORG=c and ORG=t:search=substring<NL>
Alternatively, the LDAP DAG-CAP could conduct two separate queries and take the intersection (the logical "AND") of the two sets of referrals returned by the Referral Index.
或者，LDAP DAG-CAP可以执行两个单独的查询，并获取由引用索引返回的两组引用的交集（逻辑“and”）。
Note that DAG/IP can accept phrases for searches -- the query
请注意，DAG/IP可以接受用于搜索的短语——查询
FN=Foo\ bar<NL> (note the escaped space)
FN=Foo\ bar<NL> (note the escaped space)
is perfectly valid. However, it would match only those things which have been tokenized in a way that preserves the space, which is the empty set in the case of the data stored here.
这是完全正确的。然而，它将只匹配那些以保留空间的方式标记的东西，对于存储在这里的数据来说，空间是空集。
Querying a DAG-SAP
查询DAG-SAP
It is never invalid to use the same substantive query to a DAG-SAP as was used to obtain referral information from the Referral Index. However, the over-generalization of these queries may yield excessive numbers of results, and will necessitate some pruning of results in order to match the returned results against the semantics of the original LDAP query. It is the LDAP DAG-CAP that is responsible for this pruning, as it is the recipient of the original query, and responsible for responding to its semantics.
对DAG-SAP使用与从转诊索引获取转诊信息相同的实质性查询从来都不是无效的。但是，这些查询的过度泛化可能会产生过多的结果，并且需要对结果进行一些修剪，以便将返回的结果与原始LDAP查询的语义相匹配。LDAP DAG-CAP负责此修剪，因为它是原始查询的接收者，并负责响应其语义。
In concrete terms, when making the DAG/IP query which is to be sent to a DAG-SAP the above mentioned queries are still valid queries, but an alternative finer-grained query is also possible, namely:
具体而言，在进行DAG/IP查询（将发送到DAG-SAP）时，上述查询仍然是有效的查询，但也可以使用另一种更细粒度的查询，即：
FN=foo and FN=bar and ORG=c;search=lstring and ORG=t;search=tstring
FN=foo and FN=bar and ORG=c;search=lstring and ORG=t;search=tstring
In querying a DAG-SAP (irrespective of the protocol of that DAG-SAP), the DAG/IP query must include information about the target WDSP server. This information is drawn from the Referral Index SERVER-TO-ASK referral information, and is appended to the query as specified in Appendix C):
在查询DAG-SAP（不考虑该DAG-SAP的协议）时，DAG/IP查询必须包括有关目标WDSP服务器的信息。该信息取自参考索引服务器到询问参考信息，并按照附录C中的规定附加到查询中）：
"host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
"host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
where the response from the Referral Index included:
"# SERVER-TO-ASK " serverhandle <NL>
" Server-info: " serverinfo<NL>
" Host-Name: " hostname<NL>
" Host-Port: " number<NL>
" Protocol: " prot<NL>
" Source-URI: " source<NL>
" Charset: " charset<NL>
"# END"<NL>
where the response from the Referral Index included:
"# SERVER-TO-ASK " serverhandle <NL>
" Server-info: " serverinfo<NL>
" Host-Name: " hostname<NL>
" Host-Port: " number<NL>
" Protocol: " prot<NL>
" Source-URI: " source<NL>
" Charset: " charset<NL>
"# END"<NL>
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
通过引用DAG/IP特殊字符，分别从“主机名”和“服务器信息”中获取“引用的主机名”和“引用的服务器信息”。
For example, the referral
例如，转介
# SERVER-TO-ASK dagsystem01<NL>
Server-info: o=thinkingcat, c=se<NL>
Host-Name: thinkingcat.com<NL>
Host-Port: 2839<NL>
Protocol: ldapv2<NL>
Source-URI:http://www-thinkingcat.se/
# SERVER-TO-ASK dagsystem01<NL>
Server-info: o=thinkingcat, c=se<NL>
Host-Name: thinkingcat.com<NL>
Host-Port: 2839<NL>
Protocol: ldapv2<NL>
Source-URI:http://www-thinkingcat.se/
Charset: T.61<NL>
# END<NL>
Charset: T.61<NL>
# END<NL>
would yield the addition
将产生加法
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
c\=se;charset=T\.61
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
c\=se;charset=T\.61
in its query to an LDAPv2 DAG-SAP.
在其对LDAPv2 DAG-SAP的查询中。
(N.B.: See Appendix C for further definitions of the terms used in the SERVER-TO-ASK response).
（注意：关于服务器对请求响应中使用的术语的进一步定义，请参见附录C）。
Note that it is the DAG-SAP's responsibility to extract these terms from the query and use them to identify the WDSP server to be contacted. See the individual DAG-SAP definitions, below.
请注意，DAG-SAP负责从查询中提取这些术语，并使用它们标识要联系的WDSP服务器。请参见下面的各个DAG-SAP定义。
The LDAPv3 DAG-CAP relies on DAG-SAPs to resolve all referrals except those to LDAPv3 servers (i.e., Whois++ referrals, currently).
LDAPv3 DAG-CAP依赖DAG SAP解决除LDAPv3服务器外的所有转介（即Whois++转介，目前）。
As described above, results from DAG-SAPs will have to be post-processed in cases where the original query was generalized for expression in DAG/IP. Acceptable results are expressed in LDAPv3 messages containing search result entries (see the standard for more detail):
如上所述，如果原始查询被泛化为DAG/IP中的表达式，则必须对来自DAG SAPs的结果进行后处理。可接受的结果在包含搜索结果条目的LDAPv3消息中表示（有关更多详细信息，请参阅标准）：
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
-- at least one LDAPURL element must be present
SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
-- at least one LDAPURL element must be present
SearchResultDone ::= [APPLICATION 5] LDAPResult
SearchResultDone ::= [APPLICATION 5] LDAPResult
where
哪里
LDAPDN = DN / "cn=" (FN/ROLE) [",o=" ORG] ",dc=se"
LDAPDN = DN / "cn=" (FN/ROLE) [",o=" ORG] ",dc=se"
attributes = <all attributes mapped from the DAG schema, and
"objectClass = inetOrgPerson",
"objectClass = person",
"objectClass = top" or
"objectClass = organizationalRole", as
appropriate, and "labeledURI = <SOURCE-URI>"
for each result from a given referral>
LDAPResult = success
attributes = <all attributes mapped from the DAG schema, and
"objectClass = inetOrgPerson",
"objectClass = person",
"objectClass = top" or
"objectClass = organizationalRole", as
appropriate, and "labeledURI = <SOURCE-URI>"
for each result from a given referral>
LDAPResult = success
(Where DN, FN, ROLE, and ORG are the values from the DAG schema).
（其中DN、FN、ROLE和ORG是DAG模式中的值）。
I.e., where available, the entry's true DN is used; otherwise (e.g., for data coming from Whois++ servers), a reasonable facsimile is constructed.
即，在可用的情况下，使用条目的真实DN；否则（例如，对于来自Whois++服务器的数据），将构造合理的传真。
Referral URLs are constructed from the DAG/IP's SERVER-TO-ASK information as follows:
参考URL根据DAG/IP的服务器到请求信息构建，如下所示：
refurl = "ldap://" HOST [":" PORT] "/" (SERVER-INFO / "dc=se")
refurl = "ldap://" HOST [":" PORT] "/" (SERVER-INFO / "dc=se")
The intention is that WDSPs using LDAPv3 servers will provide an appropriate LDAPDN for their server in the SERVER-INFO. Clients are then expected to repeat their query at the server designated by this URL (i.e., the refURL does not include the query).
其目的是，使用LDAPv3服务器的WDSP将在server-INFO中为其服务器提供适当的LDAPDN。然后，客户机将在该URL指定的服务器上重复其查询（即，refURL不包括该查询）。
As appropriate, the LDAPv3 DAG-CAP will express operational errors following the LDAPv3 standard. There are 4 particular error conditions of the DAG system that the DAG-CAP will handle as described below.
根据情况，LDAPv3 DAG-CAP将根据LDAPv3标准表示操作错误。DAG-CAP将按如下所述处理DAG系统的4种特殊错误情况。
When the LDAPv3 DAG-CAP receives a query that it cannot reply to within the (data) constraints of the DAG queries, it sends an error message and closes the connection. The error message includes the LDAPv3 resultCode
当LDAPv3 DAG-CAP收到无法在DAG查询的（数据）约束范围内答复的查询时，它将发送错误消息并关闭连接。错误消息包括LDAPv3结果代码
noSuchAttribute (for incorrect schema attributes chosen) inappropriateMatching (when a match type other than those supported is used e.g., approxMatch) unwillingToPerform (when the query is not one of the defined types)
noSuchAttribute（对于选择的架构属性不正确）不适当匹配（当使用了不支持的匹配类型时，例如approxMatch）不愿意操作（当查询不是定义的类型之一时）
If the number of referrals sent by the Referral Index is greater than the pre-determined maximum (for detecting data-mining efforts, or otherwise refusing over-general queries, such as "FN=svensson"), the LDAPv3 DAG-CAP will send an error message. The error message includes the following resultCode:
如果转诊索引发送的转诊数量大于预先确定的最大值（用于检测数据挖掘工作，或以其他方式拒绝常规查询，如“FN=svensson”），LDAPv3 DAG-CAP将发送错误消息。错误消息包括以下resultCode：
adminLimitExceeded
超出管理限制
An LDAPv3 DAG-CAP may redirect a connection to another LDAPv3 DAG-CAP for reasons of load-balancing. In this case, the LDAPv3 DAG-CAP sends a result message including only
出于负载平衡的原因，LDAPv3 DAG-CAP可能会将连接重定向到另一个LDAPv3 DAG-CAP。在这种情况下，LDAPv3 DAG-CAP发送的结果消息仅包括
SearchResultReference ::= [APPLICATION 19] AltURL
SearchResultReference ::= [APPLICATION 19] AltURL
SearchResultDone ::= referral
SearchResultDone ::= referral
where
哪里
AltURL = "ldap://" <althostport> ":" <altbase>
AltURL = "ldap://" <althostport> ":" <altbase>
Since a LDAPv3 DAG-CAP only can send one resultcode back to a client; If a LDAPv3 DAG-CAP receives several different result codes from the DAG-SAPs it will have to construct a resultmessage that to some extent represents the combination of those. It is proposed that in these cases the following actions are taken:
由于LDAPv3 DAG-CAP只能将一个结果代码发送回客户端；如果LDAPv3 DAG-CAP从DAG SAP接收到多个不同的结果代码，则必须构造一个resultmessage，在某种程度上表示这些代码的组合。建议在这些情况下采取以下行动：
- All the response codes are collected - Each response code are translated into the corresponding LDAPv3 resultcode. - A resultcode is chosen to represent the collected response on the following grounds: If "success" is the only resultcode represented after these steps the return that result code. If apart from "success" there is one other resultcode represented return that other resultcode. If apart from "success" there are two or more resultcodes represented return the resultcode "other".
- 收集所有响应代码-将每个响应代码转换为相应的LDAPv3 resultcode。-选择resultcode来表示收集的响应，理由如下：如果“success”是这些步骤之后表示的唯一resultcode，则返回该结果代码。如果除了“success”之外，还有一个resultcode表示返回另一个resultcode。如果除了“success”之外，还有两个或多个resultcode表示返回resultcode“other”。
The Whois++ DAG-SAP expects valid DAG/IP communications. Queries must include referral information (see below) and search terms that conform to the DAG-allowed query types (e.g., not searches for organization alone, etc).
Whois++DAG-SAP需要有效的DAG/IP通信。查询必须包括推荐信息（见下文）和符合DAG允许的查询类型的搜索词（例如，不单独搜索组织等）。
The referral information is added to the end of the DAG-SAP query, as defined in the DAG-CAP definition sections:
参照信息将添加到DAG-SAP查询的末尾，如DAG-CAP定义部分中所定义：
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
The HOST and PORT information are used to make a TCP/IP-based connection to the remote (presumed) Whois++ server. The query expressed to the remote Whois++ server is the remainder of the DAG/IP query the Whois++ DAG-SAP received, with the following template ID translations:
主机和端口信息用于与远程（假定）Whois++服务器建立基于TCP/IP的连接。表示给远程Whois++服务器的查询是Whois++DAG-SAP接收的DAG/IP查询的剩余部分，具有以下模板ID转换：
template=DAGPERSON becomes template=USER
template=DAGPERSON变成template=USER
and
和
template=DAGROLE becomes template=ORGROLE
template=DAGROLE变为template=ORGROLE
Additional mappings for attributes are defined in Appendix B.
附录B中定义了属性的其他映射。
Note that the search types used in the DAG/IP are not all required by
the Whois++ syntax. Therefore, some Whois++ WDSPs may be using
servers that do not support searches other than "exact" and "lstring"
(the search types required by the Whois++ protocol standard). The
Whois++ DAG-CAP may
Note that the search types used in the DAG/IP are not all required by
the Whois++ syntax. Therefore, some Whois++ WDSPs may be using
servers that do not support searches other than "exact" and "lstring"
(the search types required by the Whois++ protocol standard). The
Whois++ DAG-CAP may
- send the DAG/IP query as constructed (e.g., with "search=substring"), and pass back the "% 502 Search expression too complicated" from the WDSP's server, - translate the DAG/IP query into a construct using only these search types (which will yield incomplete results, as not all queries are expressible with those search types), - attempt to ascertain what search types are supported by the remote server and reformulate using them (e.g., regular expressions). This would work, but would entail an excessively complicated Whois++ DAG-SAP, and might not yield any better results if the remote server doesn't support any optional search types.
- 按构造发送DAG/IP查询（例如，使用“search=substring”），并从WDSP的服务器传回“%502 search expression too complex”—将DAG/IP查询转换为仅使用这些搜索类型的构造（这将产生不完整的结果，因为并非所有查询都可以用这些搜索类型表示），-尝试确定远程服务器支持哪些搜索类型，并使用它们重新格式化（例如，正则表达式）。这将起作用，但将需要一个过于复杂的Whois++DAG-SAP，如果远程服务器不支持任何可选的搜索类型，可能不会产生任何更好的结果。
Any referrals that the remote WDSP server returns are pursued, following the usual Whois++ (client) fashion, by the Whois++ DAG-SAP.
远程WDSP服务器返回的任何引用都由Whois++DAG-SAP按照通常的Whois++（客户端）方式进行。
If it is not possible to establish a Whois++ session with the remote server, or if the session is interrupted, before results are received, the DAG-SAP will itself return no results and an error message, including
如果无法与远程服务器建立Whois++会话，或者会话在收到结果之前中断，DAG-SAP本身将不返回任何结果和错误消息，包括
% 403 Information Unavailable<NL>
%403信息不可用<NL>
If the remote server issues any other Whois++ error message and does not yield any results, the remote server's error message will be included in the DAG-SAP's own error message; no results will be returned.
如果远程服务器发出任何其他Whois++错误消息且未产生任何结果，则远程服务器的错误消息将包含在DAG-SAP自身的错误消息中；不会返回任何结果。
If results are successfully received from the remote server, they will be expressed using the DAG/IP -- essentially passing through all FULL response information received from the remote server, mapped into the DAGSchema using the mappings defined in Appendix A.
如果从远程服务器成功接收到结果，它们将使用DAG/IP表示——基本上是通过从远程服务器接收到的所有完整响应信息，并使用附录A中定义的映射映射到DAGSchema中。
The LDAPv2 DAG-SAP expects valid DAG/IP communications. Queries must include referral information (see below) and search terms that conform to the DAG-allowed query types (e.g., not searches for organization alone, etc).
LDAPv2 DAG-SAP需要有效的DAG/IP通信。查询必须包括推荐信息（见下文）和符合DAG允许的查询类型的搜索词（例如，不单独搜索组织等）。
The referral information is added to the end of the DAG-SAP query, as defined in the DAG-CAP definition sections (as additional terms in the DAG/IP query):
参考信息添加到DAG-SAP查询的末尾，如DAG-CAP定义部分中所定义（作为DAG/IP查询中的附加术语）：
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
The HOST and PORT information are used to make a TCP/IP-based connection to the remote (presumed) LDAPv2 server. The DAG-SAP will establish a connection with the remote server, following standard LDAPv2 message exchanges.
主机和端口信息用于与远程（假定）LDAPv2服务器建立基于TCP/IP的连接。DAG-SAP将在标准LDAPv2消息交换后与远程服务器建立连接。
The search request itself will be constructed from the DAG/IP query (without the HOST, SERVER-INFO and PORT terms) as follows:
搜索请求本身将根据DAG/IP查询（不含主机、服务器信息和端口术语）构造，如下所示：
SearchRequest ::=
[APPLICATION 3] SEQUENCE {
baseObject LDAPDN, -- from the DAG/IP query
scope baseObject (0) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3)
SearchRequest ::=
[APPLICATION 3] SEQUENCE {
baseObject LDAPDN, -- from the DAG/IP query
scope baseObject (0) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3)
}, sizeLimit INTEGER (0 .. maxInt),
}，sizeLimit整数（0..maxInt），
timeLimit INTEGER (0 .. maxInt), attrsOnly FALSE filter Filter, attributes SEQUENCE OF AttributeType -- all DAGschema attributes equivalents in the defined standard LDAP schema }
timeLimit INTEGER（0..maxInt），attrsOnly FALSE filter filter，AttributeType的属性序列--定义的标准LDAP架构中的所有DAGschema属性等价项}
Filter ::=
CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
substrings [4] SubstringFilter,
}
Filter ::=
CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
substrings [4] SubstringFilter,
}
SubstringFilter SEQUENCE { type AttributeType,
子字符串筛选器序列{type AttributeType，
SEQUENCE OF CHOICE {
substrings initial [0] LDAPString,
substrings any [1] LDAPString,
substrings final [2] LDAPString}
}
SEQUENCE OF CHOICE {
substrings initial [0] LDAPString,
substrings any [1] LDAPString,
substrings final [2] LDAPString}
}
where and, or and not filters are constructed to preserve the logic of the DAG/IP query.
where and、or和not过滤器用于保留DAG/IP查询的逻辑。
For the purposes of matching token-based DAG/IP queries to reasonable LDAP queries, all searches should be passed to the LDAP WDSP as substring searches. The WDSP results must then be pruned to respect token boundaries, where necessary.
为了将基于令牌的DAG/IP查询与合理的LDAP查询进行匹配，所有搜索都应作为子字符串搜索传递给LDAP WDSP。然后，必要时，必须修剪WDSP结果以尊重令牌边界。
So, for example, the DAG/IP query
例如，DAG/IP查询
FN=Foo\ Bar and ORG=Thinking\ Cat:search=substring<NL>
FN=Foo\ Bar and ORG=Thinking\ Cat:search=substring<NL>
would be sent to the designated LDAP WDSP as
将发送到指定的LDAP WDSP作为
(& (fn=*Foo Bar*) (o=*Thinking Cat*) (objectclass=person))
(& (fn=*Foo Bar*) (o=*Thinking Cat*) (objectclass=person))
Interestingly, the query
有趣的是，这个问题
FN=Foo\ Bar and ORG=Thinking\ Cat:search=exact<NL>
FN=Foo\ Bar and ORG=Thinking\ Cat:search=exact<NL>
would also be sent to the designated LDAP WDSP as
还将发送到指定的LDAP WDSP作为
(& (fn=*Foo Bar*) (o=*Thinking Cat*) (objectclass=person))
(& (fn=*Foo Bar*) (o=*Thinking Cat*) (objectclass=person))
but the WDSPs returned results would have to be pruned to remove any results that had non-tokenizing characters on either side of "Foo Bar" and "Thinking Cat".
但是WDSP返回的结果必须被删减，以删除在“Foo-Bar”和“Thinking-Cat”两侧都有非标记化字符的任何结果。
The final consideration for mapping DAG/IP queries into LDAP queries is the issue of character case. In LDAP, individual attribute syntaxes define the consideration of case. All of the attributes used here are case-insensitive in their definitions. Therefore, all LDAP WDSP queries are inherently case-insensitive; if the DAG/IP query calls for a case-sensitive match, the LDAP DAG-SAP will have to do pruning of the results from the DAG-SAP.
将DAG/IP查询映射到LDAP查询的最后一个考虑事项是字符大小写问题。在LDAP中，单个属性语法定义了对大小写的考虑。这里使用的所有属性的定义都不区分大小写。因此，所有LDAP WDSP查询本质上都不区分大小写；如果DAG/IP查询需要区分大小写的匹配，LDAP DAG-SAP将不得不对DAG-SAP的结果进行修剪。
If it is not possible to establish an LDAPv2 session with the remote server, or if the session is interrupted before results are received, or if the remote server issues any kind of error message and produces no result, the DAG-SAP will itself return no results and an error message, including
如果无法与远程服务器建立LDAPv2会话，或者如果会话在收到结果之前中断，或者如果远程服务器发出任何类型的错误消息但未产生任何结果，DAG-SAP本身将不返回任何结果和错误消息，包括
% 403 Information Unavailable<NL>
%403信息不可用<NL>
If results are successfully received from the remote server, the attributes and values that are provided for each result message will be incorporated into the DAG/IP result, according to the schema mappings laid out in Appendix B.
如果从远程服务器成功接收到结果，则根据附录B中列出的模式映射，为每个结果消息提供的属性和值将合并到DAG/IP结果中。
One particular adjustment must be done to accommodate differences between LDAP and the DAG/IP. The attributes on which searches are keyed ("cn", "l", and "o" in the LDAP schemas) are all defined as being case-insensitive for equality matching. Thus, if the DAG/IP query includes the constraint "case=consider", the results from the remote server must be post-processed to remove any wrong-cased ones.
必须进行一项特殊调整，以适应LDAP和DAG/IP之间的差异。对搜索进行键控的属性（LDAP模式中的“cn”、“l”和“o”）都定义为不区分大小写的相等匹配。因此，如果DAG/IP查询包含约束“case=consive”，则必须对来自远程服务器的结果进行后处理，以删除任何错误的case。
TISDAG: The serverhandle and localhandle in the DAG/IP response should be constructed as follows:
TISDAG:DAG/IP响应中的serverhandle和localhandle应按如下方式构造：
serverhandle is: <hostname-without-periods><port> (because server DN's are not enforceably unique). E.g., a services.bunyip.com server on 7778 would become servicesbunyipcom7778. localhandle is: the RDN (relative distinguished name), with spaces replaced by "_". E.g., cn=leslie_daigle
serverhandle是：<hostname without periods><port>（因为服务器DN不是强制唯一的）。例如，7778上的services.bunyip.com服务器将成为servicesbunyipcom7778。localhandle是：RDN（相对可分辨名称），空格替换为“\”。例如，cn=leslie_daigle
The LDAPv3 DAG-SAP expects valid DAG/IP communications. Queries must include referral information (see below) and search terms that conform to the DAG-allowed query types (e.g., not searches for organization alone, etc).
LDAPv3 DAG-SAP需要有效的DAG/IP通信。查询必须包括推荐信息（见下文）和符合DAG允许的查询类型的搜索词（例如，不单独搜索组织等）。
The referral information is added to the end of the DAG-SAP query, as defined in the DAG-CAP definition sections:
参照信息将添加到DAG-SAP查询的末尾，如DAG-CAP定义部分中所定义：
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
The HOST and PORT information are used to make a TCP/IP-based connection to the remote (presumed) LDAPv3 server. The DAG-SAP will establish a connection with the remote server, following standard LDAPv3 message exchanges.
主机和端口信息用于与远程（假定）LDAPv3服务器建立基于TCP/IP的连接。DAG-SAP将在标准LDAPv3消息交换后与远程服务器建立连接。
The search request itself will be constructed from the DAG/IP query (without the HOST, SERVER-INFO and PORT terms) as follows:
搜索请求本身将根据DAG/IP查询（不含主机、服务器信息和端口术语）构造，如下所示：
SearchRequest ::=
[APPLICATION 3] SEQUENCE {
baseObject LDAPDN, -- from the DAG/IP query
scope baseObject (0) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3)
},
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
attrsOnly FALSE
filter Filter,
attributes SEQUENCE OF AttributeType
-- all DAGschema attributes equivalents in
the defined standard LDAP schema
}
SearchRequest ::=
[APPLICATION 3] SEQUENCE {
baseObject LDAPDN, -- from the DAG/IP query
scope baseObject (0) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3)
},
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
attrsOnly FALSE
filter Filter,
attributes SEQUENCE OF AttributeType
-- all DAGschema attributes equivalents in
the defined standard LDAP schema
}
Filter ::=
CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
Filter ::=
CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter, substrings [4] SubstringFilter, }
非[2]筛选器，子字符串[4]子字符串筛选器，}
SubstringFilter
SEQUENCE {
type AttributeType,
SEQUENCE OF CHOICE {
substrings initial [0] LDAPString,
substrings any [1] LDAPString,
substrings final [2] LDAPString}
}
SubstringFilter
SEQUENCE {
type AttributeType,
SEQUENCE OF CHOICE {
substrings initial [0] LDAPString,
substrings any [1] LDAPString,
substrings final [2] LDAPString}
}
where and, or and not filters are constructed to preserve the logic of the DAG/IP query.
where and、or和not过滤器用于保留DAG/IP查询的逻辑。
For the purposes of matching token-based DAG/IP queries to reasonable LDAP queries, all searches should be passed to the LDAP WDSP as substring searches. The WDSP results must then be pruned to respect token boundaries, where necessary.
为了将基于令牌的DAG/IP查询与合理的LDAP查询进行匹配，所有搜索都应作为子字符串搜索传递给LDAP WDSP。然后，必要时，必须修剪WDSP结果以尊重令牌边界。
So, for example, the DAG/IP query
例如，DAG/IP查询
FN=Foo\ Bar and ORG=Thinking\ Cat:search=substring<NL>
FN=Foo\ Bar and ORG=Thinking\ Cat:search=substring<NL>
would be sent to the designated LDAP WDSP as
将发送到指定的LDAP WDSP作为
(&(fn=*Foo Bar*)(o=*Thinking Cat*)(objectClass=person))
(&(fn=*Foo Bar*)(o=*Thinking Cat*)(objectClass=person))
Interestingly, the query
有趣的是，这个问题
FN=Foo\ Bar and ORG=Thinking\ Cat:search=exact<NL>
FN=Foo\ Bar and ORG=Thinking\ Cat:search=exact<NL>
would also be sent to the designated LDAP WDSP as
还将发送到指定的LDAP WDSP作为
(&(fn=*Foo Bar*)(o=*Thinking Cat*)(objectClass=person))
(&(fn=*Foo Bar*)(o=*Thinking Cat*)(objectClass=person))
but the WDSP's returned results would have to be pruned to remove any results that had non-tokenizing characters on either side of "Foo Bar" and "Thinking Cat".
但是WDSP返回的结果必须被删减，以删除在“Foo-Bar”和“Thinking-Cat”两侧都有非标记化字符的任何结果。
The final consideration for mapping DAG/IP queries into LDAP queries is the issue of character case. In LDAP, individual attribute syntaxes define the consideration of case. All of the attributes used here are case-insensitive in their definitions. Therefore, all LDAP WDSP queries are inherently case-insensitive; if the DAG/IP query calls for a case-sensitive match, the LDAP DAG-SAP will have to do pruning of the results from the DAG-SAP.
将DAG/IP查询映射到LDAP查询的最后一个考虑事项是字符大小写问题。在LDAP中，单个属性语法定义了对大小写的考虑。这里使用的所有属性的定义都不区分大小写。因此，所有LDAP WDSP查询本质上都不区分大小写；如果DAG/IP查询需要区分大小写的匹配，LDAP DAG-SAP将不得不对DAG-SAP的结果进行修剪。
Any referrals that the remote WDSP server returns are pursued, following the usual LDAPv3 (client) fashion, by the LDAPv3 DAG-SAP.
远程WDSP服务器返回的任何引用都由LDAPv3 DAG-SAP按照通常的LDAPv3（客户端）方式进行。
If it is not possible to establish an LDAPv3 session with the remote server, or if the session is interrupted before results are received, or if the remote server issues any kind of error message and produces no result, the DAG-SAP will itself return no results and an error message, including
如果无法与远程服务器建立LDAPv3会话，或者如果会话在收到结果之前中断，或者如果远程服务器发出任何类型的错误消息但未产生任何结果，DAG-SAP本身将不返回任何结果和错误消息，包括
% 403 Information Unavailable<NL>
%403信息不可用<NL>
If results are successfully received from the remote server, the attributes and values that are provided for each result message will be incorporated into the DAG/IP result, which will be expressed using the DAG/IP and schema mappings as outlined in Appendix A.
如果从远程服务器成功接收到结果，则为每个结果消息提供的属性和值将合并到DAG/IP结果中，该结果将使用附录A中概述的DAG/IP和模式映射来表示。
One particular adjustment must be done to accommodate differences between LDAP and the DAG/IP. The attributes on which searches are keyed ("cn", "l", and "o" in the LDAP schemas) are all defined as being case-insensitive for equality matching. Thus, if the DAG/IP query includes the constraint "case=consider", the results from the remote server must be post-processed to remove any wrong-cased ones.
必须进行一项特殊调整，以适应LDAP和DAG/IP之间的差异。对搜索进行键控的属性（LDAP模式中的“cn”、“l”和“o”）都定义为不区分大小写的相等匹配。因此，如果DAG/IP查询包含约束“case=consive”，则必须对来自远程服务器的结果进行后处理，以删除任何错误的case。
TISDAG: The serverhandle and localhandle in the DAG/IP response should be constructed as follows:
TISDAG:DAG/IP响应中的serverhandle和localhandle应按如下方式构造：
- serverhandle is: <hostname-without-periods><port> (because server DN's are not enforceably unique). E.g., a services.bunyip.com server on 7778 would become servicesbunyipcom7778. - localhandle is: the RDN (relative distinguished name), with spaces replaced by "_". E.g., cn=leslie_daigle
- serverhandle是：<hostname without periods><port>（因为服务器DN不是强制唯一的）。例如，7778上的services.bunyip.com服务器将成为servicesbunyipcom7778。-localhandle是：RDN（相对可分辨名称），空格替换为“\”。例如，cn=leslie_daigle
The following sample end-user queries illustrate some of the more delicate steps of query/schema semantics translations in the DAG system.
以下示例最终用户查询说明了DAG系统中查询/模式语义转换的一些更微妙的步骤。
N.B.: the data presented in these examples is often senseless, provided only to serve as illustrations of matching on word-ordering, case sensitivity, etc.
注：这些示例中提供的数据通常是毫无意义的，仅用于说明词序、区分大小写等方面的匹配。
What the Whois++ DAG-CAP Receives
Whois++DAG-CAP接收到的内容
In this example, the Whois++ DAG-CAP receives the following query:
在本例中，Whois++DAG-CAP接收以下查询：
name=thinking and name=cat:search=exact;case=consider<NL>
name=thinking and name=cat:search=exact;case=consider<NL>
The expected answer can be described as:
预期的答案可以描述为：
Any USER templates that contain the tokens "thinking" and "cat" in a name attribute.
名称属性中包含标记“thinking”和“cat”的任何用户模板。
For example:
例如：
Different records:
不同记录：
name: the thinking cat name: sublime cat thinking
名称：思考猫名称：崇高的思考猫
or a single record with 2 or more name attributes
或具有2个或多个名称属性的单个记录
name: thinking felines name: erudite cat
名称：思考猫名称：博学猫
but not
但不是
name: Thinking Cat Enterprises
名称：思维猫企业
This last record would not match because the query called for case sensitivity, and the case of the name attribute's value does not match the query.
最后一条记录不匹配，因为查询要求区分大小写，并且name属性值的大小写与查询不匹配。
What the Whois++ DAG-CAP sends to the Referral Index
Whois++DAG-CAP发送到推荐索引的内容
After schema translation, this is sent to the Referral Index as:
模式转换后，将其发送到引用索引，如下所示：
fn=thinking and fn=cat:search=exact<NL>
fn=thinking and fn=cat:search=exact<NL>
What the Whois++ DAG-CAP Sends to an LDAP DAG-SAP
Whois++DAG-CAP发送到LDAP DAG-SAP的内容
Note that the Whois++ DAG-CAP will never interact with a Whois++ DAG-SAP as the Whois++ referrals returned by the Referral Index are passed directly back to the Whois++ client.
请注意，Whois++DAG-CAP永远不会与Whois++DAG-SAP交互，因为由引用索引返回的Whois++引用会直接传递回Whois++客户端。
The Whois++ DAG-CAP should send the same substantive query to the DAG-SAP as it sent to the Referral Index, except that it can include the case sensitivity constraint:
Whois++DAG-CAP应向DAG-SAP发送与发送至参考索引相同的实质性查询，但可包括区分大小写约束：
fn=thinking and fn=cat:search=exact;case=consider<NL>
fn=thinking and fn=cat:search=exact;case=consider<NL>
which will be translated by the DAG-SAP into an LDAP query of the form:
DAG-SAP将其转换为以下形式的LDAP查询：
(&(cn=*thinking*)(cn=*cat*)(objectclass=inetOrgPerson))
(&(cn=*thinking*)(cn=*cat*)(objectclass=inetOrgPerson))
which will match a record with:
将记录与以下内容匹配：
cn: Thinking cn: Cat
cn:思考cn:猫
(i.e., 2 different cn attributes, with the 2 values; LDAP defines case sensitivity matching by the schema attribute definition).
（即，2个不同的cn属性，具有2个值；LDAP通过模式属性定义定义大小写敏感度匹配）。
or a record with:
或记录有：
cn: I wish I had a thinking dog and a singing cat
cn：我希望我有一只会思考的狗和一只会唱歌的猫
The first record should be pruned by the LDAP DAG-SAP, in order to respect the semantics of the DAG/IP query.
为了尊重DAG/IP查询的语义，LDAP DAG-SAP应该修剪第一条记录。
What the LDAP DAG-CAP Receives
LDAP DAG-CAP接收的内容
In this example, the LDAP DAG-CAP receives the following query (using RFC1960 notation):
在本例中，LDAP DAG-CAP接收以下查询（使用RFC1960表示法）：
(& (cn=th*c*t) (o=green groceries) (objectClass=person))
(& (cn=th*c*t) (o=green groceries) (objectClass=person))
What the LDAP user is looking for, with this query, is all records within the "green groceries" organization that have a cn attribute starting with "th", ending with "t", and having a "c" somewhere in the middle.
LDAP用户在这个查询中所寻找的是“绿色食品杂货店”组织中的所有记录，这些记录有一个CN属性从“Th”开始，以“T”结尾，中间有一个“C”。
cn values that would match this include:
与此匹配的cn值包括：
cn: thinkingcat cn: Thinking Cat cn: The Black Cat cn: Thick Mat
cn:思考猫cn:思考猫cn:黑猫cn:厚垫子
The LDAP DAG-CAP must formulate a token-based query to the Referral Index that will not inadvertently exclude records that would match. The first challenge lies in the fact that the "*" characters in the LDAP string-based query can cover token-boundaries.
LDAP DAG-CAP必须制定对引用索引的基于令牌的查询，该查询不会无意中排除匹配的记录。第一个挑战在于，基于LDAP字符串的查询中的“*”字符可以覆盖令牌边界。
A suitable query to the Referral Index would be:
对推荐索引的适当查询应为：
FN=th AND FN=C AND FN=T AND ORG=green AND
ORG=groceries:search=substring<NL>
FN=th AND FN=C AND FN=T AND ORG=green AND
ORG=groceries:search=substring<NL>
This will generate some false positive referrals, directing the query to WDSPs containing records with the following attribute values (the match letters are in capitals for ease of identification):
这将生成一些误报引用，将查询定向到包含以下属性值的记录的WDSP（匹配字母以大写字母表示，以便于识别）：
cn: wiTH three blaCk poTs
cn：有三个黑锅
o: peaGREEN and cyan GROCERIES o: GROCERIES are GREENer than electronics
o：绿色和青色食品o：食品比电子产品更环保
Alternative approaches include breaking the original query into several queries to the referral index in such a way that the DAG-CAP can use only those referrals that appear in all the Referral Index responses. However, this is
替代方法包括将原始查询分解为多个查询，以使DAG-CAP只能使用出现在所有查询索引响应中的那些查询。然而，这是
overkill -- the purpose of the Referral Index is to give direction on where there may be more information
过度杀伤力——推荐索引的目的是提供更多信息的方向
difficult to code into the DAG-CAP in a general way -- it has to identify, by LDAP query type, when and how to do so
很难以通用的方式编码到DAG-CAP中——它必须通过LDAP查询类型确定何时以及如何这样做
likely to generate Referral Index queries that are complex and time-consuming to process.
可能会生成复杂且耗时的引用索引查询。
What the LDAP DAG-CAP Sends to a Whois++ DAG-SAP
LDAP DAG-CAP发送给Whois++DAG-SAP的内容
The LDAP DAG-CAP may send the same query to a Whois++ DAG-SAP as it sent to the Referral Index. False positives here mean results that are not expected as a match by the LDAP client. The LDAP DAG-CAP should prune these results from the information returned by the Whois++ DAG-SAP.
LDAP DAG-CAP可以向Whois++DAG-SAP发送与发送到参考索引相同的查询。此处的误报是指LDAP客户端预期不匹配的结果。LDAP DAG-CAP应该从Whois++DAG-SAP返回的信息中删除这些结果。
Or it might rewrite the query into:
或者，它可能会将查询重写为：
FN=th;search=lstring AND FN=C;search=substring AND
FN=T;search=tstring AND ORG=green AND ORG=groceries:case=ignore<NL>
FN=th;search=lstring AND FN=C;search=substring AND
FN=T;search=tstring AND ORG=green AND ORG=groceries:case=ignore<NL>
What the LDAP DAG-CAP Sends to an LDAP DAG-SAP
LDAP DAG-CAP发送给LDAP DAG-SAP的内容
As an architectural principle, it is never wrong to send the same query to a DAG-SAP as was formulated for the Referral Index. It is also noteworthy to keep in memory that all DAG-SAPs are handled equal by all DAG-CAPs therefore a LDAP DAG-CAP will not need to send a different query to a LDAP DAG-SAP then it would to any other DAG-SAP.
作为一项体系结构原则，向DAG-SAP发送与为引用索引制定的查询相同的查询是绝对正确的。还值得注意的是，在内存中，所有DAG SAP都由所有DAG CAP进行同等处理，因此LDAP DAG-CAP不需要向LDAP DAG-SAP发送与其他DAG-SAP不同的查询。
So in this case the LDAP DAP-CAP could either send the same query to the LDAP DAG-SAP as it sent to the Referral Index or it could send the augmented version that is allowed to be use with the DAG-SAPs, namely:
因此，在这种情况下，LDAP DAP-CAP可以向LDAP DAG-SAP发送与发送到参考索引相同的查询，也可以发送允许与DAG SAP一起使用的增强版本，即：
FN=th;search=lstring AND FN=C;search=substring AND
FN=T;search=tstring AND ORG=green\ groceries:case=ignore<NL>
FN=th;search=lstring AND FN=C;search=substring AND
FN=T;search=tstring AND ORG=green\ groceries:case=ignore<NL>
Note that this will be translated, by the LDAP DAG-SAP, into a query of the form
请注意，LDAP DAG-SAP会将其转换为表单的查询
(&(cn=*th*)(cn=*c*)(cn=*t*)(o=*green groceries*)
(objectClass=person))
(&(cn=*th*)(cn=*c*)(cn=*t*)(o=*green groceries*)
(objectClass=person))
which is still more general than the original query.
这仍然比原始查询更一般。
Note the translation from "FN=th;search=lstring" into "cn=*th*". This is necessary, as the DAG/IP lstring constraint is based on tokens, whereas "cn=th*" refers to the beginning of the attribute's value (phrase, not token). The DAG-SAP should therefore prune out any results that include things like "oTHer plaCes for visiTors" in order to match the semantics of the DAG/IP query it received.
注意从“FN=th；search=lstring”到“cn=*th*”的翻译。这是必要的，因为DAG/IP lstring约束基于令牌，而“cn=th*”指的是属性值的开头（短语，而不是令牌）。因此，DAG-SAP应该删掉任何包含“访客的其他地方”之类内容的结果，以匹配其收到的DAG/IP查询的语义。
The DAG-CAP should then prune those results to match the semantics of the original LDAP query.
然后，DAG-CAP应该删减这些结果，以匹配原始LDAP查询的语义。
To satisfy the requirements laid out for the TISDAG project, the software built for the DAG system must be able to meet the following service specifications:
为满足TISDAG项目的要求，为DAG系统构建的软件必须能够满足以下服务规范：
- primary designated DAG-CAPs of all types (but not necessarily secondary ones set up for load-balancing) must be available to provide service or redirect queries on a 7x24 basis.
- 必须提供所有类型的主要指定DAG上限（但不一定是为负载平衡设置的次要DAG上限），以便全天候提供服务或重定向查询。
- in general, responses to queries should be available in under 10 seconds; very generalized queries (i.e., when the user truly cannot specify enough information to focus the search) can be deferred to take much longer (having results is more important than having a quick answer) - the data provided from each WDSP should be updated in the DAG at least once every 7 days
- 一般来说，对查询的响应应在10秒内可用；非常一般化的查询（即，当用户确实无法指定足够的信息来集中搜索时）可以推迟到更长的时间（有结果比快速回答更重要）-每个WDSP提供的数据应至少每7天在DAG中更新一次
WDSPs who wish to participate in the DAG system do so by providing DAG-compatible access to their service, where DAG-compatible means:
希望参与DAG系统的WDSP通过提供与DAG兼容的服务访问来实现，其中DAG兼容是指：
- access in (exactly) one of LDAPv2, LDAPv3, or Whois++ - 7x24 service for responding to referrals generated in the DAG core (minimally) weekly updates of the index object describing the information their service indexes - use of USER and ROLE templates for Whois++ servers - use of inetorgperson and organizationalrole objectclasses for LDAP servers
- 访问（确切地说）LDAPv2、LDAPv3或Whois++-7x24服务中的一个，用于响应在DAG核心（最少）每周更新索引对象中生成的引用，该索引对象描述了其服务索引的信息-对Whois++服务器使用用户和角色模板-对LDAP服务器使用inetorgperson和organizationalrole对象类
To participate, WDSPs must register each DAG-compliant server with the DAG system, providing details for each data set that it covers:
要参与，WDSP必须向DAG系统注册每个符合DAG的服务器，并提供其涵盖的每个数据集的详细信息：
- the host, port and protocol of the server - an identifier for the dataset - a URL for the service of preference for accessing the data (preferred source) - protocol-specific information - administrative contact information - CIP object exchange information
- 服务器的主机、端口和协议-数据集的标识符-访问数据的首选服务的URL（首选源）-协议特定信息-管理联系信息-CIP对象交换信息
Note that any WDSP wishing to make data available through the DAG system but unable to support these requirements may provide information through an agreement with a third-party which does meet these requirements. Thus, data can be replicated between cooperating WDSPs. The DAG referral index does not claim ownership of personal information; it directs queries to services that do, by whatever agreements with whichever relevant parties. Note that, in this case, the SOURCE-URI may direct end-users to the WDSP's existing services, not the service of the third party.
请注意，任何希望通过DAG系统提供数据但无法支持这些要求的WDSP可通过与符合这些要求的第三方签订的协议提供信息。因此，可以在协作的WDSP之间复制数据。DAG转介索引不主张个人信息的所有权；它将查询指向通过与任何相关方达成的任何协议提供的服务。注意，在这种情况下，SOURCE-URI可能会将最终用户指向WDSP的现有服务，而不是第三方的服务。
It is anticipated that the DAG system will be quite popular, and measures must be available to distribute the load of answering queries.
预计DAG系统将非常流行，必须采取措施分配回答查询的负载。
The DAG system is presented as a conceptual whole, made up of several component parts -- DAG-CAPs, DAG-SAPs and the Referral Index. Each of these component parts must be replicable, and service must be shared between replicas.
DAG系统是一个概念性的整体，由几个组成部分组成——DAG CAP、DAG SAP和参考索引。这些组件中的每一个都必须是可复制的，并且服务必须在副本之间共享。
It may be interesting to consider allowing large-scale service providers (large companies, ISPs) the ability to mirror the Referral Index or provide alternate DAG-CAPs/DAG-SAPs for their personnel/customers. Policies and possibilities for doing that are beyond the scope of this report; however, the software architecture has been designed to support such activity.
考虑允许大型服务提供商（大公司、ISPS）镜像转诊索引或为他们的人员/客户提供备用DAG CAP/DAG SAPS的能力可能是有趣的。超出本报告范围的政策和可能性；然而，软件体系结构的设计是为了支持此类活动。
Figure 6.1 shows that individual components of the DAG system may each run on non-co-located server hardware, connected by TCP/IP networks. These components can be replicated as needed.
图6.1显示了DAG系统的各个组件可以在通过TCP/IP网络连接的非同址服务器硬件上运行。可以根据需要复制这些组件。
+====+
| | DAG-CAP (Client Access Point)
| |
+====+
+----+
| | DAG-SAP (Service Access Point)
| |
+----+
+====+
HTTP <-->| |
| | +----+
+====+ | |<--> Whois++
| |
+====+ +----+
SMTP <-->| |
| | +----+
+====+ | |<--> LDAPv2
| |
+====+ +----+
Whois++<-->| |
| |
+====+ +----+
| |<--> LDAPv3
| |
+----+
| |<--> LDAPv3
| |
+----+
| |<--> LDAPv3
| |
+====+ +----+
LDAPv2 <-->| |
| |
+====+
+====+
LDAPv3 <-->| |
| |
+====+
+------------------------+
| Referral Index |<--> Common Indexing Protocol
| | (CIP)
+------------------------+
+------------------------+
| Referral Index |
| |
+------------------------+
+====+
| | DAG-CAP (Client Access Point)
| |
+====+
+----+
| | DAG-SAP (Service Access Point)
| |
+----+
+====+
HTTP <-->| |
| | +----+
+====+ | |<--> Whois++
| |
+====+ +----+
SMTP <-->| |
| | +----+
+====+ | |<--> LDAPv2
| |
+====+ +----+
Whois++<-->| |
| |
+====+ +----+
| |<--> LDAPv3
| |
+----+
| |<--> LDAPv3
| |
+----+
| |<--> LDAPv3
| |
+====+ +----+
LDAPv2 <-->| |
| |
+====+
+====+
LDAPv3 <-->| |
| |
+====+
+------------------------+
| Referral Index |<--> Common Indexing Protocol
| | (CIP)
+------------------------+
+------------------------+
| Referral Index |
| |
+------------------------+
Figure 6.1 Distributable nature of DAG components
图6.1 DAG组件的可分配性质
Thus, the software built to this specification must be configurable to permit the following actions:
因此，根据本规范构建的软件必须可配置，以允许以下操作：
- DAG-CAP software must be able to handle or redistribute the primary load. Depending on the DAG-CAP software, this may be handled by having multiple processes attending to incoming queries, or the DAG-CAP at the primary address for the protocol may be nothing more than a reflector that redirects incoming queries to the address of the least-loaded server at the moment. - This is particularly necessary in synchronous connection protocols, such as Whois++ and LDAP, where the goal is to minimize the amount of time a requesting client is connected to the well-advertised address port. - DAG-CAP software must be able to direct referrals to different DAG-SAPs of the same protocol type. - DAG-CAP software must be able to detect overly general queries (i.e., have some metric to decide that the number of referrals generated by the Referral Index is too great). - DAG-SAPs must be able to redirect DAG-CAP queries at their discretion, or just refuse service because of loading (therefore DAG-CAPs must also be able to find other DAG-SAPs)
- DAG-CAP软件必须能够处理或重新分配主要负载。根据DAG-CAP软件的不同，这可以通过让多个进程处理传入查询来处理，或者协议主地址处的DAG-CAP可能只是一个反射器，将传入查询重定向到当前负载最少的服务器的地址。-在同步连接协议（如Whois++和LDAP）中，这一点尤为必要，因为同步连接协议的目标是最大限度地减少请求客户端连接到广告客户机地址端口的时间。-DAG-CAP软件必须能够直接转介到相同协议类型的不同DAG SAP。-DAG-CAP软件必须能够检测过于笼统的查询（即，有一些指标来确定由转介索引生成的转介数量太多）。-DAG SAP必须能够自行决定重定向DAG-CAP查询，或者仅仅因为加载而拒绝服务（因此，DAG CAPs还必须能够找到其他DAG SAP）
The DAG system has been designed to allow for extensibility in certain key areas:
DAG系统的设计允许在某些关键领域进行扩展：
It is possible to add new DAG-CAPs and DAG-SAPs transparently. Beyond replicating the software of existing DAG-CAPs, new implementations for particular protocols (e.g., building a more elaborate mail-based query system), or implementations for altogether different protocols (e.g., PH) can be added by adhering to the basic principles of DAG-CAPs and DAG-SAPs defined in the software specification. The new DAG-CAP is responsible for the translation of queries into DAG/IP (post-processing results, if necessary) and results in the new protocol. No other part of the DAG system is affected.
可以透明地添加新的DAG CAP和DAG SAP。除了复制现有DAG CAPs的软件外，还可以通过遵循软件规范中定义的DAG CAPs和DAG SAP的基本原则，添加特定协议的新实现（例如，构建更复杂的基于邮件的查询系统）或完全不同协议的实现（例如，PH）。新的DAG-CAP负责将查询转换为DAG/IP（如有必要，可转换为后处理结果）并生成新协议。DAG系统的其他部分不受影响。
More functionality may be added to the DAG system service (e.g., adding security certificate references to the schema of returned information) by updating the DAG schema.
通过更新DAG模式，可以向DAG系统服务添加更多功能（例如，向返回信息的模式添加安全证书引用）。
Depending on how the load on the service goes, it may be interesting to consider reducing the number of queries that are chained for protocols that inherently can handle the concept of pursuing referrals. Specifically, LDAPv3 and Whois++ both handle referrals, but the current system calls for chaining LDAPv3 (and LDAPv2) referrals for the Whois++ DAG-CAP, and vice versa. Alternatively,
取决于服务上的负载如何，考虑减少被链接的查询的数量可能是有趣的，因为协议固有地可以处理寻求转介的概念。具体来说，LDAPv3和Whois++都处理转介，但当前系统要求为Whois++DAG-CAP链接LDAPv3（和LDAPv2）转介，反之亦然。或者，
"virtual" DAG-CAPs could be established for each participating WDSP for each protocol the WDSP doesn't support, and referrals to those DAG-CAPs could be given to the calling client. For example, a Whois++ client would be given a Whois++ referral to the virtual Whois++ DAG-CAP for a WDSP that supports only LDAP. The importance of having one virtual DAG-CAP per WDSP is that the point of connection is the only way to distinguish which WDSP the Whois++ client thought it was connecting to.
对于WDSP不支持的每个协议，可以为每个参与的WDSP建立“虚拟”DAG上限，并且可以向呼叫客户端推荐这些DAG上限。例如，对于仅支持LDAP的WDSP，Whois++客户机将获得Whois++对虚拟Whois++DAG-CAP的引用。每个WDSP有一个虚拟DAG-CAP的重要性在于，连接点是区分Whois++客户端认为它连接到哪个WDSP的唯一方法。
Security, in the context of "read-only" directory services, is primarily concerned with maintaining data integrity as it passes from an originating server to the end-user making an inquiry. That is, some server(s) hold correct user information, and a client accessing a directory service should be certain that whichever servers that the information has to pass through before reaching the client, it receives a true representation of the original information.
在“只读”目录服务的上下文中，安全性主要涉及在数据从原始服务器传递到进行查询的最终用户时保持数据完整性。也就是说，某些服务器持有正确的用户信息，并且访问目录服务的客户机应该确保信息在到达客户机之前必须经过的任何服务器都会收到原始信息的真实表示。
The DAG system as such MUST be completely invisible as the mediator of the information from the WDSPs to the querying directory access client. The only possible modifications that can appear is translations from one characterset into another. Hopefully, this does not alter the meaning of the information.
作为从WDSP到查询目录访问客户端的信息中介，DAG系统本身必须是完全不可见的。唯一可能出现的修改是从一个字符集到另一个字符集的翻译。希望这不会改变信息的含义。
In keeping with the public nature of the proposed TISDAG service, the DAG system does not provide any access control system beyond components' configuration to accept connections from recognized other components. For more detailed access control, it is up to the connected WDSPs to apply the access control.
为符合拟议TISDAG服务的公共性质，DAG系统不提供任何超出组件配置的访问控制系统，以接受来自公认其他组件的连接。有关更详细的访问控制，应由连接的WDSP应用访问控制。
Since the DAG system only supports searching and retrieving information, no updates can occur through the DAG client access points.
由于DAG系统仅支持搜索和检索信息，因此无法通过DAG客户端访问点进行更新。
Security in updates (CIP index objects) is provided by encryption and signature of objects from registered WDSPs.
更新（CIP索引对象）中的安全性由来自已注册WDSP的对象的加密和签名提供。
This work came from ideas originally put forward by Patrik Faltstrom. The TISDAG project was supported by the Swedish KK Foundation.
这项工作来自帕特里克·法特斯特罗姆最初提出的想法。TISDAG项目得到瑞典KK基金会的支持。
Thanks to especially to Jens Lundstrom, Thommy Eklof, Bjorn Larsson and Sandro Mazzucato for their comments on draft versions of this document.
特别感谢Jens Lundstrom、Thommy Eklof、Bjorn Larsson和Sandro Mazzucato对本文件草稿的评论。
Appendix A - DAG Schema Definitions
附录A-DAG模式定义
The DAG makes use of 2 information schemas -- the DAGPERSON schema for information about specific people, and the DAGORGROLE schema for organizational roles that may or may not be job positions occupied by people at any given time (e.g., an organization's president, customer service desk, etc).
DAG使用了两种信息模式——用于特定人员信息的DAGPERSON模式和用于组织角色的DAGORGROLE模式，组织角色可能是也可能不是在任何给定时间由人员占据的职位（例如，组织的总裁、客户服务台等）。
This appendix defines the schemas in terms of the attributes used within the DAG/IP. Mappings to the standard LDAP and Whois++ object classes and templates (respectively) are described in Appendix B.
本附录根据DAG/IP中使用的属性定义了模式。到标准LDAP和Whois++对象类和模板的映射（分别）在附录B中描述。
Because the role of the DAG schemas is to act as an intermediary between information provided in different access protocols, with different underlying schema paradigms, the attributes in the schema are identified as being required or optional. The required attributes are so designated because they are involved in the DAG search types and/or the minimal returned response. They have defined mappings in the selected access protocols. The optional attributes have proposed mappings in those protocols.
由于DAG模式的作用是充当不同访问协议中提供的信息之间的中介，具有不同的底层模式范例，因此模式中的属性被标识为必需的或可选的。之所以指定必需的属性，是因为它们涉及DAG搜索类型和/或最小返回响应。他们在选定的访问协议中定义了映射。可选属性在这些协议中建议了映射。
It is important to note that the DAG/IP is constructed to carry any alternative attribute information that may be provided by a given WDSP; individual DAG-SAPs and DAG-CAPs may choose to pass along, interpret, or ignore any attributes not defined in this appendix.
重要的是要注意，DAG/IP被构造为承载给定WDSP可能提供的任何可选属性信息；单个DAG SAP和DAG CAP可以选择传递、解释或忽略本附录中未定义的任何属性。
Additionally, note that the order of attributes in the DAG/IP is significant, which means that it is possible to use one attribute to carry the information describing the type of subsequent ones (e.g., see the "ADR-TYPE" attribute below).
此外，请注意，DAG/IP中属性的顺序是重要的，这意味着可以使用一个属性来携带描述后续属性类型的信息（例如，请参阅下面的“ADR-type”属性）。
Finally, attributes may be repeated. For example, this schema structure can carry multiple phone numbers of different types for one person.
最后，属性可以重复。例如，此模式结构可以为一个人携带多个不同类型的电话号码。
Attribute Designation Specific Description
--------- ----------- -------------------------------------
FN Required Free-text representation of full name
EMAIL Required Internet e-mail address
LOC Required Locality -- geographic region
ORG Required Person's organization
ADR-TYPE Optional Type of address that follows
("org", "home", "org-postal",
"home-postal", "unqualified")
ADR Optional Full address
ADR-STREET Optional Street address component
ADR-ROOM Optional Suite or room number component
ADR-CITY Optional City name
ADR-STATE Optional Region of address
ADR-COUNTRY Optional Country
ADR-CODE Optional Postal code component
TEL-TYPE Optional Type of telephone number (
"work", "home", "mobile",
"fax" ,"pager", "unqualified")
in the following attribute
TEL Optional A phone number for the person
SOURCE Optional The WDSP's preferred access to
their service -- a URL
DN Optional Entry's "distinguished name"
(for LDAP)
Attribute Designation Specific Description
--------- ----------- -------------------------------------
FN Required Free-text representation of full name
EMAIL Required Internet e-mail address
LOC Required Locality -- geographic region
ORG Required Person's organization
ADR-TYPE Optional Type of address that follows
("org", "home", "org-postal",
"home-postal", "unqualified")
ADR Optional Full address
ADR-STREET Optional Street address component
ADR-ROOM Optional Suite or room number component
ADR-CITY Optional City name
ADR-STATE Optional Region of address
ADR-COUNTRY Optional Country
ADR-CODE Optional Postal code component
TEL-TYPE Optional Type of telephone number (
"work", "home", "mobile",
"fax" ,"pager", "unqualified")
in the following attribute
TEL Optional A phone number for the person
SOURCE Optional The WDSP's preferred access to
their service -- a URL
DN Optional Entry's "distinguished name"
(for LDAP)
Table A.1 DAGPERSON schema attributes
表A.1个人模式属性
Attribute Designation Specific Description
--------- ----------- ---------------------
ROLE Required Name of organizational role
EMAIL Required E-mail address associated with role
ORG Required Name of organization
LOC Required Locality -- geographic region
TEL-TYPE Optional Type of telephone number
in the TEL attribute immediately
following("org" or "fax")
TEL Optional Phone number
Attribute Designation Specific Description
--------- ----------- ---------------------
ROLE Required Name of organizational role
EMAIL Required E-mail address associated with role
ORG Required Name of organization
LOC Required Locality -- geographic region
TEL-TYPE Optional Type of telephone number
in the TEL attribute immediately
following("org" or "fax")
TEL Optional Phone number
FN Optional Full name of current role occupant SOURCE Optional The WDSP's preferred access to their service -- a URL DN Optional Entry's "distinguished name" (for LDAP)
FN可选当前角色占用者源的全名可选WDSP对其服务的首选访问--URL DN可选项的“可分辨名称”（用于LDAP）
Table A.2 DAGORGROLE schema attributes
表A.2 DAGORGROLE架构属性
Appendix B - Schema Mappings for Whois++ and LDAP
Appendix B - Schema Mappings for Whois++ and LDAP
The DAG/IP makes use of two specific schemas, as defined above. However, schemas particular to access protocols need to be handled in order to appropriately address incoming user queries, and chaining queries to WDSPs. The recognized standard schemas are:
DAG/IP使用了两种特定的模式，如上所述。但是，需要处理特定于访问协议的模式，以便适当地处理传入的用户查询，并将查询链接到WDSP。公认的标准模式包括：
- the USER template for Whois++ ([8]) - the ORGROLE template for Whois++ ([8]) - the inetOrgperson objectclass for LDAP ([16]) - the organizationalrole objectclass for LDAP ([18])
- Whois++（[8]）的用户模板-Whois++（[8]）的ORGROLE模板-LDAP的inetOrgperson对象类（[16]）-LDAP的organizationalrole对象类（[18]）
The DAG/IP schemas were developed based on the information that the TISDAG project requirements wish to return in results, in conjunction with information about standard schemas used in the basic WDSP access protocols (LDAPv2/v3 and Whois++). However, particularly in the case of address information, the schemas used for those protocols allow for considerable scope of information representation. In practice, this means that different WDSPs may choose to use different sub-parts of the schema, or even implement local customizations.
DAG/IP模式是根据TISDAG项目要求希望返回结果的信息，以及基本WDSP访问协议（LDAPv2/v3和Whois++）中使用的标准模式信息开发的。然而，特别是在地址信息的情况下，用于这些协议的模式允许相当大范围的信息表示。实际上，这意味着不同的WDSP可以选择使用模式的不同子部分，甚至实现本地定制。
Therefore, Appendix A outlines a very basic schema that can carry all the necessary information. The basic DAG-CAPs and DAG-SAPs are designed to work to that information structure. This appendix outlines the expected behaviour for DAG-SAPs mapping into the DAG/IP schema, and DAG-CAPs extracting information to pass along to client software after a chaining operation has returned results.
因此，附录A概述了一个可以承载所有必要信息的非常基本的模式。基本DAG CAP和DAG SAP设计用于该信息结构。本附录概述了DAG SAPs映射到DAG/IP模式的预期行为，以及DAG CAPs提取信息以在链接操作返回结果后传递给客户端软件。
The only time information is carried in the DAG schemas is when a DAG-SAP is returning information (obtained from WDSPs' servers) to a DAG-CAP using the DAG/IP. The "canonical" mappings between standard LDAP object classes (inetorgPerson, defined in [16] and organizationalRole, defined in [18] and the DAGPERSON schema and DAGORGROLE schema are defined such that information passed from an LDAP DAG-SAP to an LDAP DAG-CAP (e.g., in the case of an LDAPv3 DAG-SAP returning information chained for an LDAPv2 DAG-CAP) will be mapped into the same attributes as it was extracted.
DAG模式中携带信息的唯一时间是DAG-SAP使用DAG/IP向DAG-CAP返回信息（从WDSP的服务器获取）时。定义了标准LDAP对象类（inetorgPerson，在[16]中定义）和organizationalRole，在[18]中定义）与DAGPERSON模式和DAGORGROLE模式之间的“规范”映射，以便将信息从LDAP DAG-SAP传递到LDAP DAG-CAP（例如，在LDAPv3 DAG-SAP返回LDAPv2 DAG-CAP链接信息的情况下）将映射到提取时的相同属性中。
However, the representation of some attributes (such as address) is truly widely varied between protocol paradigms. The goal with the "reasonable approximation" mappings that are provided is to give DAG-CAPs a basic mechanism for communicating information drawn from non-LDAP DAG-SAP sources. The mappings may not be perfect, but they will convey the information to the end-user in some LDAP-understandable fashion, which is the goal of this project's effort.
然而，某些属性（如地址）的表示在不同的协议范例中确实存在很大差异。提供的“合理近似”映射的目标是为DAG CAP提供一种基本机制，用于通信从非LDAP DAG-SAP源获取的信息。映射可能并不完美，但它们将以某种LDAP可理解的方式将信息传递给最终用户，这是本项目的目标。
The canonical mappings for the LDAP inetorgPerson object class and the DAGPERSON schema are given in Table B.1. A few reasonable approximation mappings follow in Table B.2. Beyond that, DAG-SAPs may pass along any additional attributes in the DAG/IP, and DAG-CAPs may elect to forward or interpret any that are recognizable (e.g., the sn ("surname") attribute is not listed here, but a DAG-SAP might return that in the DAG/IP, and a DAG-CAP, recognizing the string representation, could elect to include it in its LDAP response to the client).
LDAP inetorgPerson对象类和DAGPERSON模式的规范映射如表B.1所示。表B.2给出了一些合理的近似映射。除此之外，DAG SAP可以传递DAG/IP中的任何附加属性，DAG CAP可以选择转发或解释任何可识别的属性（例如，sn（“姓氏”）属性未在此处列出，但DAG-SAP可能会在DAG/IP中返回该属性，而识别字符串表示的DAG-CAP可以选择将其包含在其对客户端的LDAP响应中）。
DAGPERSON Attribute LDAP inetorgPerson attribute
------------------- ----------------------------
FN cn
EMAIL mail
LOC l
ORG o
DAGPERSON Attribute LDAP inetorgPerson attribute
------------------- ----------------------------
FN cn
EMAIL mail
LOC l
ORG o
ADR-TYPE=org ADR-STREET street ADR-ROOM roomNumber ADR-STATE st ADR-COUNTRY c
ADR-TYPE=组织ADR-街道ADR-房间号ADR-州st ADR-国家c
ADR-TYPE=org-postal ADR postalAddress ADR-ROOM postOfficeBox ADR-CODE postalCode
ADR-TYPE=组织邮政ADR邮资ADR-ROOM邮局邮箱ADR-CODE邮政编码
ADR-TYPE=home-postal ADR homePostalAddress
ADR-TYPE=家庭邮政ADR家庭邮政礼服
TEL-TYPE=work TEL telephoneNumber
TEL-TYPE=工作电话号码
TEL-TYPE=home TEL homePhone
TEL-TYPE=家庭电话
TEL-TYPE=fax TEL facsimileTelephoneNumber
TEL-TYPE=传真电话传真机传真号码
TEL-TYPE=mobile TEL mobile
TEL-TYPE=移动电话
TEL-TYPE=pager TEL pager
电话类型=寻呼机电话寻呼机
DN dn SOURCE labeledURI
源标签
Table B.1 Canonical DAGPERSON schema & LDAP inetorgPerson attributes
表B.1规范的DAGPERSON模式和LDAP inetorgPerson属性
DAGROLE Attribute LDAP organizationalRole attribute
----------------------- ---------------------------------
ADR-TYPE=unqualified
ADR street
ADR-STREET street
ADR-ROOM room
ADR-STATE st
ADR-COUNTRY c
DAGROLE Attribute LDAP organizationalRole attribute
----------------------- ---------------------------------
ADR-TYPE=unqualified
ADR street
ADR-STREET street
ADR-ROOM room
ADR-STATE st
ADR-COUNTRY c
TEL-TYPE=unqualified TEL telephoneNumber
TEL-TYPE=不合格的电话号码
Table B.2 Reasonable Approximations for LDAP organizationalRole attributes
表B.2 LDAP organizationalRole属性的合理近似值
For example, consider the following LDAP record information, in LDIF [11] format:
例如，在LDIF（11）格式中考虑以下LDAP记录信息：
dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry,
c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
cn: Barbara Jensen
cn: Barbara J Jensen
cn: Babs Jensen
sn: Jensen
uid: bjensen
telephonenumber: +1 408 5551212
description: A big sailing fan
dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry,
c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
cn: Barbara Jensen
cn: Barbara J Jensen
cn: Babs Jensen
sn: Jensen
uid: bjensen
telephonenumber: +1 408 5551212
description: A big sailing fan
This would validly be carried in the DAGPERSON schema as follows:
这将有效地在DAGPERSON模式中进行，如下所示：
DN: cn=Barbara Jensen, ou=Product Development, o=Ace Industry,
c=US
FN: Barbara Jensen
FN: Barbara J Jensen
FN: Babs Jensen
SN: Jensen
TEL-TYPE: work
TEL: +1 408 5551212
DN: cn=Barbara Jensen, ou=Product Development, o=Ace Industry,
c=US
FN: Barbara Jensen
FN: Barbara J Jensen
FN: Babs Jensen
SN: Jensen
TEL-TYPE: work
TEL: +1 408 5551212
The canonical mappings for the LDAP organizationalRole object class and the DAGORGROLE schema are given in Table B.3 .Beyond that, DAG-SAPs may elect to send along any attributes, and DAG-CAPs may interpret any that are recognizable. N.B., the organizationalRole class does not include provision for inclusion of an e-mail address. This mapping rather blithely assumes the availability of the mail attribute as defined for inetorgPerson.
表B.3给出了LDAP organizationalRole对象类和DAGORGROLE架构的规范映射。除此之外，DAG SAP可以选择发送任何属性，DAG CAP可以解释任何可识别的属性。注意，organizationalRole类不包含包含电子邮件地址的规定。这种映射相当轻松地假设了为inetorgPerson定义的邮件属性的可用性。
DAGORGROLE Attribute LDAP organizationalRole attribute
-------------------- ---------------------------------
ROLE cn
EMAIL mail
ORG o
LOC l
DAGORGROLE Attribute LDAP organizationalRole attribute
-------------------- ---------------------------------
ROLE cn
EMAIL mail
ORG o
LOC l
TEL-TYPE=org TEL telephoneNumber
TEL-TYPE=组织电话号码
TEL-TYPE=fax TEL facsimileNumber
电话类型=传真电话传真号码
FN roleOccupant DN dn SOURCE labeledURI
FN roleOccupant DN源标签
Table B.3 Canonical mappings for LDAP organizationalRole attributes
表B.3 LDAP organizationalRole属性的规范映射
The "canonical" mappings between standard Whois++ templates as defined in [8] and the DAGPERSON schema and DAGORGROLE schema are defined in Tables B.4 and B.5. Beyond that, DAG-SAPs may pass along any additional attributes in the DAG/IP, and DAG-CAPs may elect to forward or interpret any that are recognizable.
表B.4和表B.5定义了[8]中定义的标准Whois++模板与DAGPERSON模式和DAGORGROLE模式之间的“规范”映射。除此之外，DAG SAP可以传递DAG/IP中的任何附加属性，DAG CAP可以选择转发或解释任何可识别的属性。
DAGPERSON Attribute Whois++ USER template attribute
------------------- -------------------------------
FN name
EMAIL email
LOC address-locality
ORG organization-name
DAGPERSON Attribute Whois++ USER template attribute
------------------- -------------------------------
FN name
EMAIL email
LOC address-locality
ORG organization-name
ADR-TYPE=unqualified ADR address
ADR-TYPE=不合格的ADR地址
ADR-TYPE=org ADR organization-address ADR-STREET organization-address-street ADR-ROOM organization-address-room ADR-CITY organization-address-city ADR-STATE organization-address-state ADR-COUNTRY organization-address-country ADR-CODE organization-address-zip-code
ADR-TYPE=组织ADR组织地址ADR-街道组织地址街道ADR-房间组织地址房间ADR-城市组织地址城市ADR-州组织地址州ADR-国家组织地址国家ADR-代码组织地址邮政编码
ADR-TYPE=home address-type=home ADR address ADR-STREET address-street ADR-ROOM address-room ADR-CITY address-city ADR-STATE address-state ADR-COUNTRY address-country ADR-CODE address-zip-code
ADR-TYPE=家庭地址类型=家庭ADR地址ADR-街道地址ADR-房间地址房间ADR-城市地址城市ADR-州地址州ADR-国家地址国家ADR-代码地址邮政编码
TEL-TYPE=work phone-type=work TEL phone
电话类型=工作电话类型=工作电话
TEL-TYPE=home phone-type=home TEL phone
电话类型=家庭电话类型=家庭电话
TEL-TYPE=fax TEL fax
电话类型=传真电话传真
TEL-TYPE=mobile TEL cellular
TEL-TYPE=移动电话蜂窝
TEL-TYPE=pager TEL pager
电话类型=寻呼机电话寻呼机
Table B.4 Canonical DAGPERSON schema & Whois++ USER attributes
表B.4规范的DAGPERSON模式和Whois++用户属性
DAGORGROLE Attribute Whois++ ORGROLE attribute
-------------------- -------------------------
ROLE org-role
EMAIL email
ORG organization-name
LOC organization-address-locality
FN name
DAGORGROLE Attribute Whois++ ORGROLE attribute
-------------------- -------------------------
ROLE org-role
EMAIL email
ORG organization-name
LOC organization-address-locality
FN name
TEL-TYPE=org TEL phone
电话类型=组织电话
TEL-TYPE=fax TEL fax
电话类型=传真电话传真
Table B.5 Canonical mappings for Whois++ ORGROLE attributes
表B.5 Whois++ORGROLE属性的规范映射
Appendix C - DAG-Internal Protocol (DAG/IP)
附录C-DAG内部协议（DAG/IP）
The DAG-Internal Protocol (DAG/IP) is currently defined as a derivative of the query-interaction protocol of Whois++ as laid out in RFC1835 ([6]).
DAG内部协议（DAG/IP）目前被定义为Whois++查询交互协议的派生协议，如RFC1835（[6]）所述。
The use of the DAG/IP is strictly internal to the DAG system. In that regard, it is possible make use of any query language, or define a new one.
DAG/IP的使用严格属于DAG系统内部。在这方面，可以使用任何查询语言，或者定义一种新的查询语言。
The Whois++ protocol was selected as the basis of the DAG/IP for several reasons:
出于以下几个原因，选择Whois++协议作为DAG/IP的基础：
- it has the power and flexibility to convey all necessary queries - it is a simple, text-based protocol; clients need not implement the full functionality of the protocol in order to carry out minimal queries - the power of the full-fledge directory service query protocol will give DAG-CAP writers the ability to express more sophisticated queries if desired (e.g., to produce more intricate "intelligent" matching of spellings, common character substitutions, etc). - the text-based, delimited attribute results expression facilitates optional inclusion of extra data supplied by WDSPs -- DAG-CAPs can easily ignore any unknown information and continue to interpret the rest of the result information.
- 它具有传递所有必要查询的能力和灵活性——它是一个简单的、基于文本的协议；客户端无需实现协议的全部功能即可执行最低限度的查询-完整的目录服务查询协议的强大功能将使DAG-CAP编写器能够在需要时表达更复杂的查询（例如，生成更复杂的“智能查询”）拼写匹配、常用字符替换等）。-基于文本的分隔属性结果表达式有助于可选地包含WDSP提供的额外数据——DAG CAPs可以轻松忽略任何未知信息，并继续解释其余的结果信息。
Also, the use of an existing protocol leverages the experience and time of the creators of the protocol -- hammering out such elusive and yet necessary details as handling line-endings, quoting special characters, etc.
此外，现有协议的使用利用了协议创建者的经验和时间——敲定了诸如处理行尾、引用特殊字符等难以捉摸但必要的细节。
There is a freely-available test suite of tools for testing servers' Whois++ protocol conformance (for the Referral Index, and for DAG-SAPs). Send mail to digger-info@bunyip.com for further information.
有一个免费提供的测试工具套件，用于测试服务器的Whois++协议一致性（用于引用索引和DAG SAP）。给迪格发邮件-info@bunyip.com以获取更多信息。
Input interactions in DAG/IP are as defined in RFC1835, "Architecture of the WHOIS++ service" ([6]), sections 2.2 and 2.3. Section C.3 of this document adapts the grammar used in more recent descriptions of the Whois++ protocol to illustrate the syntax of the DAG/IP.
DAG/IP中的输入交互如RFC1835“WHOIS++服务的体系结构”（[6]）第2.2和2.3节所定义。本文件第C.3节修改了Whois++协议最新描述中使用的语法，以说明DAG/IP的语法。
DAG/IP output will be a subset of what is defined in RFC1835, section 2.4, except that referral responses ("SERVER-TO-ASK") contain more information.
DAG/IP输出将是RFC1835第2.4节中定义的子集，但参考响应（“服务器到询问”）包含更多信息除外。
The following sections are adapted from the Whois++ grammar. For discussion of the semantic intent of the query protocol, and other matters, see Whois++ RFC 1835 [6].
以下部分改编自Whois++语法。有关查询协议的语义意图和其他事项的讨论，请参见Whois++RFC1835[6]。
The following grammar, which uses the Augmented BNF (ABNF) notation as defined in [5], defines the set of acceptable DAG/IP input.
以下语法使用[5]中定义的增广BNF（ABNF）表示法，定义了可接受的DAG/IP输入集。
N.B.: As outlined in the ABNF definition, rule names and string literals are in the US-ASCII character set, and are case-insensitive. Also, when a character is written explicitly in the grammar, as for example ";", it represents the byte value of that character in all of the allowed character sets in their encodings used in this protocol. Specifically in UNICODE, ";" means the character U+003B, which when encoding the character in UTF-8 will generate the byte value 0x3B which is then used in the DAG/IP protocol.
注意：如ABNF定义中所述，规则名称和字符串文字在US-ASCII字符集中，不区分大小写。此外，当一个字符在语法中显式写入时，例如“；”，它表示该字符在本协议中使用的编码中的所有允许字符集中的字节值。特别是在UNICODE中，“；”表示字符U+003B，在UTF-8中对字符进行编码时，将生成字节值0x3B，然后在DAG/IP协议中使用。
dagip-command = ( system-command [":" "hold"]
/ ri-query
/ sap-query ) nl
dagip-command = ( system-command [":" "hold"]
/ ri-query
/ sap-query ) nl
ri-query = ri-terms [":" globalcnstrnts]
ri query=ri terms[“：”globalcntrnts]
sap-query = sap-terms [":" [sapcnstrnts][ ":" wdspinfo]]
sap-query = sap-terms [":" [sapcnstrnts][ ":" wdspinfo]]
system-command = "constraints"
/ "describe"
/ "commands"
/ "polled-by"
/ "polled-for"
/ "version"
/ "list"
/ "show" [1*sp datastring]
/ "help" [1*sp datastring]
/ "<NL>" [string]
system-command = "constraints"
/ "describe"
/ "commands"
/ "polled-by"
/ "polled-for"
/ "version"
/ "list"
/ "show" [1*sp datastring]
/ "help" [1*sp datastring]
/ "<NL>" [string]
ri-terms = ri-and-expr *(1*sp "or" 1*sp ri-and-expr)
ri-terms = ri-and-expr *(1*sp "or" 1*sp ri-and-expr)
ri-and-expr = ri-basic-expr *(1*sp "and" 1*sp ri-basic-
expr)
ri-and-expr = ri-basic-expr *(1*sp "and" 1*sp ri-basic-
expr)
ri-basic-expr = ["not" 1*sp] ri-term / ( "(" ri-terms ")" )
ri-basic-expr = ["not" 1*sp] ri-term / ( "(" ri-terms ")" )
ri-term = generalterm / specificterm / combinedterm
ri-term = generalterm / specificterm / combinedterm
sap-terms = sap-and-expr *(1*sp "or" 1*sp sap-and-expr)
sap-terms = sap-and-expr *(1*sp "or" 1*sp sap-and-expr)
sap-and-expr = sap-basic-expr *(1*sp "and" 1*sp
sap-basic-expr)
sap-and-expr = sap-basic-expr *(1*sp "and" 1*sp
sap-basic-expr)
sap-basic-expr = ["not" 1*sp] sap-term / ( "(" sap-terms ")" )
sap-basic-expr = ["not" 1*sp] sap-term / ( "(" sap-terms ")" )
sap-term = ( generalterm / specificterm / combinedterm)
localcnstrnts
sap-term = ( generalterm / specificterm / combinedterm)
localcnstrnts
generalterm = datastring
generalterm = datastring
TISDAG: Since the DAG system only supports certain attribute combinations in its queries, (Table 3.1). The use of generalterm may lead to unexpected behaviour and is therefore deprecated. CAPs should therefore not use it even if it is in the protocol.
TISDAG：由于DAG系统在其查询中仅支持某些属性组合（表3.1）。使用generalterm可能会导致意外行为，因此不推荐使用。因此，即使在协议中，CAP也不应使用它。
specificterm = specificname "=" datastring
specificterm=specificname“=”数据字符串
specificname = "handle" / "value"
specificname = "handle" / "value"
combinedterm = attributename "=" datastring
combinedterm=attributename“=”数据字符串
sapcnstrnts = sapcnstrnt *(";" sapcnstrnt)
sapcnstrnts = sapcnstrnt *(";" sapcnstrnt)
sapcnstrnt = localcnstrnt / globalcnstrnt
sapcnstrnt = localcnstrnt / globalcnstrnt
localcnstrnts = [";search=" sap-searchvalue] [";case="
sap-casevalue]
localcnstrnts = [";search=" sap-searchvalue] [";case="
sap-casevalue]
localcnstrnt = "search=" sap-searchvalue / "case="
sap-casevalue
localcnstrnt = "search=" sap-searchvalue / "case="
sap-casevalue
;N.B.: in the case where local and global constraints
; conflict, local constraints take precedence
; and overrides the global constraint
;N.B.: in the case where local and global constraints
; conflict, local constraints take precedence
; and overrides the global constraint
sap-searchvalue = "tstring" / searchvalue
sap searchvalue=“tstring”/searchvalue
sap-casevalue = "consider" / "ignore"
sap-casevalue = "consider" / "ignore"
globalcnstrnts = globalcnstrnt *(";" globalcnstrnt)
globalcnstrnts = globalcnstrnt *(";" globalcnstrnt)
globalcnstrnt = "search" "=" searchvalue / opt-globalcnst
globalcnsrnt=“搜索”“=”搜索值/opt globalcnst
opt-globalcnst = "hold"
/ "case" "=" casevalue
/ "maxfull" "=" 1*digit
/ "maxhits" "=" 1*digit
/ "language" "=" language
/ "incharset" "=" characterset
/ "ignore" "=" attributename
/ "include" "=" attributename
opt-globalcnst = "hold"
/ "case" "=" casevalue
/ "maxfull" "=" 1*digit
/ "maxhits" "=" 1*digit
/ "language" "=" language
/ "incharset" "=" characterset
/ "ignore" "=" attributename
/ "include" "=" attributename
; N.B.: If an attribute is named both with the "include" and "ignore"
; constraints, the attribute is to be included in the result, but the
; system message must be "% 112 Requested constraint not fulfilled".
; N.B.: If an attribute is named both with the "include" and "ignore"
; constraints, the attribute is to be included in the result, but the
; system message must be "% 112 Requested constraint not fulfilled".
language = <The language code defined in RFC1766>
language = <The language code defined in RFC1766>
characterset = "UNICODE-2-0-UTF-8"
characterset = "UNICODE-2-0-UTF-8"
searchvalue = "exact" / "substring" / "lstring"
searchvalue = "exact" / "substring" / "lstring"
casevalue = "ignore" / "consider"
casevalue = "ignore" / "consider"
wdspinfo = attrValAss *( ";" attrValAss )
wdspinfo = attrValAss *( ";" attrValAss )
attrValAss = attributename "=" datastring
attrValAss=attributename“=”数据字符串
TISDAG: Within the boundaries of the TISDAG project it has been decided that the only permitted attributes for wdspinfo are "host","port","server-info" and "charset". Regarding "charset" the values for this attribute are defined to be one of "UTF-8", "ISO8859-1","T\.61" or "US-ASCII".
TISDAG：在TISDAG项目的范围内，已确定wdspinfo的唯一允许属性是“主机”、“端口”、“服务器信息”和“字符集”。关于“字符集”，该属性的值定义为“UTF-8”、“ISO8859-1”、“T\.61”或“US-ASCII”之一。
datastring = 1*data-elt
datastring = 1*data-elt
attributename = 1*(<%d32-126 except specialbyte>)
; omit 127, which is DEL
attributename = 1*(<%d32-126 except specialbyte>)
; omit 127, which is DEL
data-elt = "\" specialbyte / normalbyte
数据elt=“\”特殊字节/正常字节
normalbyte = <%d32-255, except specialbyte>
normalbyte = <%d32-255, except specialbyte>
specialbyte = " " / tab / "=" / "," / ":" / ";" / "\" /
"*" / "." / "(" / ")" / "[" / "]" / "^" /
"$" / "!" / "<NL>"
specialbyte = " " / tab / "=" / "," / ":" / ";" / "\" /
"*" / "." / "(" / ")" / "[" / "]" / "^" /
"$" / "!" / "<NL>"
number = 1*digit
number = 1*digit
digit = "0" / "1" / "2" / "3" / "4" /
"5" / "6" / "7" / "8" / "9"
digit = "0" / "1" / "2" / "3" / "4" /
"5" / "6" / "7" / "8" / "9"
tab = %d09
sp = %d32 ; space
nl = %d13 %d10 ; CR LF
tab = %d09
sp = %d32 ; space
nl = %d13 %d10 ; CR LF
NOTE: Spaces (sp) that are significant to a query must be escaped.
The following characters, when significant to the query, may be
preceded and/or followed by a single space:
: ; , ( ) = !
NOTE: Spaces (sp) that are significant to a query must be escaped.
The following characters, when significant to the query, may be
preceded and/or followed by a single space:
: ; , ( ) = !
The following grammar, which uses the Augmented BNF (ABNF) notation as defined in RFC2234 (see [5]),
以下语法使用RFC2234（见[5]）中定义的增广BNF（ABNF）表示法，
N.B.: As outlined in the ABNF definition, rule names and string literals are in the US-ASCII character set, and are case-insensitive. Also, when a character is written explicitely in the grammar, as for example ";", it represents the byte value of that character in all of the allowed character sets in their encodings used in this protocol. Specifically in UNICODE, ";" means the character U+003B which when encoding the character in UTF-8 will generate the byte value 0x3B which is then used in the DAG/IP protocol.
注意：如ABNF定义中所述，规则名称和字符串文字在US-ASCII字符集中，不区分大小写。此外，当一个字符明确地写在语法中时，例如“；”，它表示该字符在本协议中使用的编码中的所有允许字符集中的字节值。特别是在UNICODE中，“；”表示字符U+003B，在UTF-8中对字符进行编码时，将生成字节值0x3B，然后在DAG/IP协议中使用。
server-resp = goodmessage mnl output mnl endmessage / badmessage nl endmessageclose
server resp=goodmessage mnl output mnl endmessage/badmessage nl endmessageclose
output = 0*(full-record / server-to-ask)
output = 0*(full-record / server-to-ask)
full-record = "# FULL " template " " serverhandle " " localhandle system-nl 1*fulldata "# END" system-nl
完整记录=“#完整”模板“服务器句柄”本地句柄系统nl 1*完整数据“#结束”系统nl
TISDAG: serverhandle is:
TISDAG:serverhandle是：
- Whois++, whatever the server-handle on the record returned by the WDSP. - LDAP, <hostname-without-periods><port> (because server DN's are not enforceably unique). E.g., a services.bunyip.com server on 7778 would become servicesbunyipcom7778.
- Whois++，无论WDSP返回的记录上的服务器句柄是什么。-LDAP，<hostname without periods><port>（因为服务器DN不是强制唯一的）。例如，7778上的services.bunyip.com服务器将成为servicesbunyipcom7778。
localhandle is: - Whois++: the localhandle on the record returned by the WDSP - LDAP, it is the RDN (relative distinguished name), with spaces replaced by "_". E.g., cn=leslie_daigle
localhandle是：-Whois++：WDSP-LDAP返回的记录上的localhandle，它是RDN（相对可分辨名称），空格替换为“\ux”。例如，cn=leslie_daigle
server-to-ask = "# SERVER-TO-ASK " serverhandle system-nl server-to-askdata "# END" system-nl
server to ask=“#server-to-ask”serverhandle system nl server to askdata”#END”system nl
fulldata = " " attributename ": " attributevalue
system-nl
fulldata = " " attributename ": " attributevalue
system-nl
server-to-ask-data = " Server-Info: " serverinfo system-nl " Host-Name: " hostname system-nl " Host-Port: " number system-nl " Protocol: " prot system-nl " Source-URI: " source system-nl " Charset: " characterset system-nl
服务器询问数据=“服务器信息：”服务器信息系统nl”主机名：“主机名系统nl”主机端口：“数字系统nl”协议：“保护系统nl”源URI:“源系统nl”字符集：“字符集系统nl”
attributename = r-string
attributename = r-string
attributevalue = longstring
attributevalue = longstring
template = <%d32-%d255 except specialbyte>
template = <%d32-%d255 except specialbyte>
serverhandle = <%d32-%d255 except specialbyte>
serverhandle = <%d32-%d255 except specialbyte>
localhandle = <%d32-%d255 except specialbyte>
localhandle = <%d32-%d255 except specialbyte>
serverinfo = string
serverinfo = string
hostname = string
hostname = string
prot = string ; currently one of "ldapv2"
; "ldapv3" "whois++"
prot = string ; currently one of "ldapv2"
; "ldapv3" "whois++"
characterset = "UTF-8" / "T.61" / "ISO8859-1" / "US-ASCII"
characterset = "UTF-8" / "T.61" / "ISO8859-1" / "US-ASCII"
source = string
source = string
longstring = string 0*( nl ( "+" / "-" ) string )
longstring = string 0*( nl ( "+" / "-" ) string )
string = 0*(%d32-255)
字符串=0*（%d32-255）
r-string = 0*(<%d32-126 except specialbyte>)
; omit 127 which is DEL
r-string = 0*(<%d32-126 except specialbyte>)
; omit 127 which is DEL
specialbyte = ":" / " "
specialbyte = ":" / " "
mnl = 1*system-nl
mnl = 1*system-nl
system-nl = nl [ 1*(message nl) ]
系统nl=nl[1*（消息nl）]
nl = %d13 %d10 ; CR and LF
nl = %d13 %d10 ; CR and LF
message = [1*( messagestart "-" string nl)]
messagestart " " string nl
message = [1*( messagestart "-" string nl)]
messagestart " " string nl
messagestart = "% " digit digit digit
messagestart=“%”位
goodmessage = [1*( goodmessagestart "-" string nl)]
goodmessagestart " " string nl
goodmessage = [1*( goodmessagestart "-" string nl)]
goodmessagestart " " string nl
goodmessagestart= "% 200"
goodmessagestart=“%200”
badmessage = [1*( badmessagestart "-" string nl)]
badmessagestart " " string nl
badmessage = [1*( badmessagestart "-" string nl)]
badmessagestart " " string nl
badmessagestart = "% 5" digit digit
badmessagestart=“%5”位
endmessage = endmessageclose / endmessagecont
endmessage = endmessageclose / endmessagecont
endmessageclose = [endmessagestart " " string nl]
byemessage
endmessageclose = [endmessagestart " " string nl]
byemessage
endmessagecont = endmessagestart " " string nl
endmessagecont=endmessagestart“”字符串nl
endmessagestart = "% 226"
endmessagestart=“%226”
byemessage = byemessagestart " " string nl
byemessage=byemessagestart“”字符串nl
byemessagestart = "% 203"
byemessagestart=“%203”
number = 1*( digit )
number = 1*( digit )
digit = "0" / "1" / "2" / "3" / "4" / "5" / "6" /
"7" / "8" / "9"
digit = "0" / "1" / "2" / "3" / "4" / "5" / "6" /
"7" / "8" / "9"
The following list and discussion of response codes is derived from the Whois++ protocol definition, RFC1835 ([6]).
以下响应代码列表和讨论源自Whois++协议定义RFC1835（[6]）。
A system message begins with a '%', followed by a space and a three digit number, a space, and an optional text message. The line message must be no more than 81 bytes long, including the terminating CR LF pair. There is no limit to the number of system messages that may be generated.
系统消息以“%”开头，后跟空格、三位数、空格和可选文本消息。线路消息的长度不得超过81字节，包括终止的CR LF对。可能生成的系统消息数量没有限制。
A multiline system message have a hyphen instead of a space in column 6, immediately after the numeric response code in all lines, except the last one, where the space is used.
多行系统消息在第6列中的数字响应代码后面有一个连字符，而不是空格，除了最后一行使用空格外。
Example 1
例1
% 200 Command okay
%200命令行吗
Example 2
例2
% 220-Welcome to % 220-the Whois++ server % 220 at ACME inc.
%220欢迎使用ACME inc.的Whois++服务器%220。
The client is not expected to parse the text part of the response message except when receiving reply 600 or 601, in which case the text part is in the former case the name of a character set that will be used by the server in the rest of the response, and in the latter case when it specifies what language the attribute value is in. The valid values for characters sets is specified in the "characterset" list in the BNF listing in Appendix C.
客户机不希望解析响应消息的文本部分，除非在接收应答600或601时，在这种情况下，文本部分在前一种情况下是服务器将在响应的其余部分中使用的字符集的名称，在后一种情况下，当它指定属性值所用的语言时。字符集的有效值在附录C中BNF列表的“characterset”列表中指定。
The theory of reply codes is described in Appendix E in STD 10, RFC821 ([15]).
回复码的理论在STD 10 RFC821（[15]）的附录E中描述。
System response code Description
系统响应代码说明
---------------------------- ------------------------------
110 Too many hits The number of matches exceeded
the value specified by the
maxhits constraint. Server
will still reply with as many
records as "maxhits" allows.
---------------------------- ------------------------------
110 Too many hits The number of matches exceeded
the value specified by the
maxhits constraint. Server
will still reply with as many
records as "maxhits" allows.
111 Requested constraint not One or more constraints in query supported is not implemented, but the search is still done.
111请求的约束未实现支持的查询中的一个或多个约束，但搜索仍在进行。
112 Requested constraint not One or more constraints in query fulfilled has unacceptable value and was therefore not used, but the search is still done.
112请求的约束查询中没有一个或多个约束具有不可接受的值，因此未使用，但搜索仍然完成。
200 Command Ok Command accepted and executed. The client must wait for a transaction end system message.
接受并执行200命令Ok命令。客户端必须等待事务结束系统消息。
201 Command Completed Command accepted and executed. successfully
201命令完成接受并执行的命令。成功地
203 Bye Server is closing connection
203 Bye服务器正在关闭连接
204 Overgeneralized The server could not exactly match the DAG query into its native access protocol. The resulting native query was "looser".
204服务器无法将DAG查询与其本机访问协议精确匹配。生成的本机查询“更松散”。
220 Service Ready Greeting message. Server is accepting commands.
220服务就绪问候语。服务器正在接受命令。
226 Transaction complete End of data. All responses to query are sent.
226事务完成数据结束。将发送对查询的所有响应。
401 Service not available
401服务不可用
402 Search expression too complicated
搜索表达式太复杂
403 Information Unavailable When a remote service is not (currently) available.
403远程服务（当前）不可用时，信息不可用。
404 Time out
404超时
500 Syntax error
500语法错误
502 Search expression too This message is sent when the complicated server is not able to resolve a query (i.e. when a client sent a regular expression that is too deeply nested).
502搜索表达式太多当复杂的服务器无法解析查询时（即当客户端发送嵌套太深的正则表达式时），会发送此消息。
503 Query to general This is like the "too many hits" situation, but the server does not send along any results. This message is used to deflect data mining.
503查询到general这类似于“点击次数过多”的情况，但服务器不发送任何结果。此消息用于转移数据挖掘。
505 Operations error Permanent operations error
505操作错误永久性操作错误
600 <token> Subsequent attribute values are encoded in the character set specified by <token>.
600<token>后续属性值编码在<token>指定的字符集中。
601 <token> Subsequent attribute values are in the language specified by <token>.
601<token>后续属性值使用<token>指定的语言。
601 DEF Subsequent attribute values are default values, i.e. they should be used for all languages not specified by "601 <token>" since last "601 ANY" message.
601 DEF后续属性值是默认值，即，自上次“601 ANY”消息以来，“601<token>”未指定的所有语言都应使用这些值。
601 ANY Subsequent attribute values are for all languages.
601任何后续属性值都适用于所有语言。
Table C.1 List of system response codes
表C.1系统响应代码列表
Appendix D - DAG/IP Response Messages Mapping
附录D-DAG/IP响应消息映射
LDAPv2/v3 DAG/IP
--------------------------------------- ---------------------
success (0) v2&v3 200 Command Ok
operationsError (1) v2&v3 505 Operations error
protocolError (2) v2&v3 505 Operations error
timeLimitExceeded (3) v2&v3 404 Timeout
sizeLimitExceeded (4) v2&v3 110 To many hits
compareFalse (5) v2&v3 200 OK
compareTrue (6) v2&v3 200 OK
authMethodNotSupported (7) v2&v3 505 Operations error
strongAuthRequired (8) v2&v3 505 Operations error
referral (10) v3 200 OK
adminLimitExceeded (11) v3 110 Too many hits
unavailableCriticalExtension (12) v3 505 Operations error
confidentialityRequired (13) v3 505 Operations error
saslBindInProgress (14) v3 N.A.
noSuchAttribute (16) v2&v3 200 OK
undefinedAttributeType (17) v2&v3 500 Syntax error
inappropriateMatching (18) v2&v3 500 Syntax error
constraintViolation (19) v2&v3 111 Requested constraint
not supported
attributeOrValueExists (20) v2&v3 200 OK
invalidAttributeSyntax (21) v2&v3 500 Syntax error
noSuchObject (32) v2&v3 200 OK
aliasProblem (33) v2&v3 505 Operations error
invalidDNSyntax (34) v2&v3 500 Syntax error
isLeaf (35) v2 N.A.
aliasDereferencingProblem (36) v2&v3 505 Operations error
inappropriateAuthentication (48) v2&v3 500 Syntax error
invalidCredentials (49) v2&v3 403 Information Unavailable
insufficientAccessRights (50) v2&v3 403 Information Unavailable
busy (51) v2&v3 403 Information Unavailable
unavailable (52) v2&v3 401 Service not available
unwillingToPerform (53) v2&v3 505 Operations error
loopDetect (54) v2&v3 505 Operations error
namingViolation (64) v2&v3 N.A.
objectClassViolation (65) v2&v3 N.A.
notAllowedOnNonLeaf (66) v2&v3 N.A.
notAllowedOnRDN (67) v2&v3 N.A.
entryAlreadyExists (68) v2&v3 N.A.
objectClassModsProhibited (69) v2&v3 N.A.
affectsMultipleDSAs (71) v3 N.A.
other (80) v2&v3 403 Information Unavailable
LDAPv2/v3 DAG/IP
--------------------------------------- ---------------------
success (0) v2&v3 200 Command Ok
operationsError (1) v2&v3 505 Operations error
protocolError (2) v2&v3 505 Operations error
timeLimitExceeded (3) v2&v3 404 Timeout
sizeLimitExceeded (4) v2&v3 110 To many hits
compareFalse (5) v2&v3 200 OK
compareTrue (6) v2&v3 200 OK
authMethodNotSupported (7) v2&v3 505 Operations error
strongAuthRequired (8) v2&v3 505 Operations error
referral (10) v3 200 OK
adminLimitExceeded (11) v3 110 Too many hits
unavailableCriticalExtension (12) v3 505 Operations error
confidentialityRequired (13) v3 505 Operations error
saslBindInProgress (14) v3 N.A.
noSuchAttribute (16) v2&v3 200 OK
undefinedAttributeType (17) v2&v3 500 Syntax error
inappropriateMatching (18) v2&v3 500 Syntax error
constraintViolation (19) v2&v3 111 Requested constraint
not supported
attributeOrValueExists (20) v2&v3 200 OK
invalidAttributeSyntax (21) v2&v3 500 Syntax error
noSuchObject (32) v2&v3 200 OK
aliasProblem (33) v2&v3 505 Operations error
invalidDNSyntax (34) v2&v3 500 Syntax error
isLeaf (35) v2 N.A.
aliasDereferencingProblem (36) v2&v3 505 Operations error
inappropriateAuthentication (48) v2&v3 500 Syntax error
invalidCredentials (49) v2&v3 403 Information Unavailable
insufficientAccessRights (50) v2&v3 403 Information Unavailable
busy (51) v2&v3 403 Information Unavailable
unavailable (52) v2&v3 401 Service not available
unwillingToPerform (53) v2&v3 505 Operations error
loopDetect (54) v2&v3 505 Operations error
namingViolation (64) v2&v3 N.A.
objectClassViolation (65) v2&v3 N.A.
notAllowedOnNonLeaf (66) v2&v3 N.A.
notAllowedOnRDN (67) v2&v3 N.A.
entryAlreadyExists (68) v2&v3 N.A.
objectClassModsProhibited (69) v2&v3 N.A.
affectsMultipleDSAs (71) v3 N.A.
other (80) v2&v3 403 Information Unavailable
Table D.1 LDAPv2/v3 resultcodes to DAG/IP response codes mapping
表D.1 LDAPv2/v3结果代码到DAG/IP响应代码映射
DAG/IP LDAP v2/v3
--------------------------------------- --------------------------
110 Too many hits sizeLimitExceeded (4)
111 Requested constraint not supported constraintViolation (19)
112 Requested constraint not fullfilled constraintViolation (19)
200 Command Ok Success (0)
201 Command Completed successfully N.A.
203 Bye N.A.
204 Overgeneralized N.A.
220 Service Ready N.A.
226 Transaction complete N.A.
401 Service not available unavailable (52)
402 Search expression too complicated unwillingToPerform (53)
403 Information Unavailable busy (51)
404 Time out timeLimitExceeded (3)
405 Operations error operationsError (1)
500 Syntax error protocolError (2)
502 Search expression too complicated unwillingToPerform (53)
503 Query to general unwillingToPerform (53)
505 Operations error operationsError (1)
600 <token> N.A.
601 <token> N.A.
601 DEF N.A.
601 ANY N.A.
DAG/IP LDAP v2/v3
--------------------------------------- --------------------------
110 Too many hits sizeLimitExceeded (4)
111 Requested constraint not supported constraintViolation (19)
112 Requested constraint not fullfilled constraintViolation (19)
200 Command Ok Success (0)
201 Command Completed successfully N.A.
203 Bye N.A.
204 Overgeneralized N.A.
220 Service Ready N.A.
226 Transaction complete N.A.
401 Service not available unavailable (52)
402 Search expression too complicated unwillingToPerform (53)
403 Information Unavailable busy (51)
404 Time out timeLimitExceeded (3)
405 Operations error operationsError (1)
500 Syntax error protocolError (2)
502 Search expression too complicated unwillingToPerform (53)
503 Query to general unwillingToPerform (53)
505 Operations error operationsError (1)
600 <token> N.A.
601 <token> N.A.
601 DEF N.A.
601 ANY N.A.
Table D.2 Mapping from DAG/IP response codes to LDAPv2/v3 resultcodes
表D.2从DAG/IP响应代码到LDAPv2/v3结果代码的映射
DAG/IP Whois++
-------------------------------------- -----------------------------
110 Too Many hits 110 Too Many hits
111 Requested constraint not supported 111 Requested constraint not
supported
112 Requested constraint not fullfilled 112 Requested constraint not
fullfilled
200 Command Ok 200 Command Ok
201 Command Completed successfully 201 Command Completed
successfully
401 Service not available 401 Service not available
403 Information Unavailable 403 Information not available
404 Timeout 404 Timeout
405 Operations error 405 Operations error
500 Syntax error 500 Syntax error
502 Search expression too complicated 502 Search expression too
complicated
503 Query to general 506 Query to general
505 Operations error 505 Operations error
DAG/IP Whois++
-------------------------------------- -----------------------------
110 Too Many hits 110 Too Many hits
111 Requested constraint not supported 111 Requested constraint not
supported
112 Requested constraint not fullfilled 112 Requested constraint not
fullfilled
200 Command Ok 200 Command Ok
201 Command Completed successfully 201 Command Completed
successfully
401 Service not available 401 Service not available
403 Information Unavailable 403 Information not available
404 Timeout 404 Timeout
405 Operations error 405 Operations error
500 Syntax error 500 Syntax error
502 Search expression too complicated 502 Search expression too
complicated
503 Query to general 506 Query to general
505 Operations error 505 Operations error
Table D.3 Mapping between DAG/IP and Whois++ response codes
Table D.3 Mapping between DAG/IP and Whois++ response codes
Appendix E - DAG CIP Usage
附录E-DAG CIP的使用
The CIP object used by the DAG system is based on the Tagged Index Object as defined in [12]. The grammar, adapted from that Work in Progress, for the specific object used by the DAG is as follows:
DAG系统使用的CIP对象基于[12]中定义的标记索引对象。根据正在进行的工作改编的DAG使用的特定对象的语法如下：
index-object = 0*(io-part SEP) io-part
io-part = header SEP schema-spec SEP index-info
header = version-spec SEP update-type SEP this-update SEP
last-update context-size
version-spec = "version:" *SPACE "x-tagged-index-1"
update-type = "updatetype:" *SPACE ( "total" |
( "incremental" [*SPACE "tagbased"|"uniqueIDbased" ])
this-update = "thisupdate:" *SPACE TIMESTAMP
last-update = [ "lastupdate:" *SPACE TIMESTAMP SEP]
context-size = [ "contextsize:" *SPACE 1*DIGIT SEP]
schema-spec = "BEGIN IO-Schema" SEP 1*(schema-line SEP)
"END IO-Schema"
schema-line = attribute-name ":" token-type
token-type = "TOKEN"
index-info = full-index | incremental-index
full-index = "BEGIN Index-Info" SEP 1*(index-block SEP)
"END Index-Info"
incremental-index = 1*(add-block | delete-block | update-block)
add-block = "BEGIN Add Block" SEP 1*(index-block SEP)
"END Add Block"
delete-block = "BEGIN Delete Block" SEP 1*(index-block SEP)
"END Delete Block"
update-block = "BEGIN Update Block" SEP
0*(old-index-block SEP)
1*(new-index-block SEP)
"END Update Block"
old-index-block = "BEGIN Old" SEP 1*(index-block SEP)
"END Old"
new-index-block = "BEGIN New" SEP 1*(index-block SEP)
"END New"
index-block = first-line 0*(SEP cont-line)
first-line = attr-name ":" *SPACE taglist "/" attr-value
cont-line = "-" taglist "/" attr-value
taglist = tag 0*("," tag) | "*"
tag = 1*DIGIT ["-" 1*DIGIT]
attr-value = 1*(UTF8)
attr-name = dag-searchattr / "objectclass"
dag-searchattr = "FN" / "LOC" / "ROLE" / "ORG"
TIMESTAMP = 1*DIGIT
NAMECHAR = DIGIT | UPPER | LOWER | "-" | ";" | "."
index-object = 0*(io-part SEP) io-part
io-part = header SEP schema-spec SEP index-info
header = version-spec SEP update-type SEP this-update SEP
last-update context-size
version-spec = "version:" *SPACE "x-tagged-index-1"
update-type = "updatetype:" *SPACE ( "total" |
( "incremental" [*SPACE "tagbased"|"uniqueIDbased" ])
this-update = "thisupdate:" *SPACE TIMESTAMP
last-update = [ "lastupdate:" *SPACE TIMESTAMP SEP]
context-size = [ "contextsize:" *SPACE 1*DIGIT SEP]
schema-spec = "BEGIN IO-Schema" SEP 1*(schema-line SEP)
"END IO-Schema"
schema-line = attribute-name ":" token-type
token-type = "TOKEN"
index-info = full-index | incremental-index
full-index = "BEGIN Index-Info" SEP 1*(index-block SEP)
"END Index-Info"
incremental-index = 1*(add-block | delete-block | update-block)
add-block = "BEGIN Add Block" SEP 1*(index-block SEP)
"END Add Block"
delete-block = "BEGIN Delete Block" SEP 1*(index-block SEP)
"END Delete Block"
update-block = "BEGIN Update Block" SEP
0*(old-index-block SEP)
1*(new-index-block SEP)
"END Update Block"
old-index-block = "BEGIN Old" SEP 1*(index-block SEP)
"END Old"
new-index-block = "BEGIN New" SEP 1*(index-block SEP)
"END New"
index-block = first-line 0*(SEP cont-line)
first-line = attr-name ":" *SPACE taglist "/" attr-value
cont-line = "-" taglist "/" attr-value
taglist = tag 0*("," tag) | "*"
tag = 1*DIGIT ["-" 1*DIGIT]
attr-value = 1*(UTF8)
attr-name = dag-searchattr / "objectclass"
dag-searchattr = "FN" / "LOC" / "ROLE" / "ORG"
TIMESTAMP = 1*DIGIT
NAMECHAR = DIGIT | UPPER | LOWER | "-" | ";" | "."
SPACE = <ASCII space, %x20>;
SEP = (CR LF) | LF
CR = <ASCII CR, carriage return, %x0D>;
SPACE = <ASCII space, %x20>;
SEP = (CR LF) | LF
CR = <ASCII CR, carriage return, %x0D>;
LF = <ASCII LF, line feed, %x0A>;
LF = <ASCII LF, line feed, %x0A>;
DIGIT = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
DIGIT = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
UPPER = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
"I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
"Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
"Y" | "Z"
LOWER = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
"i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
"q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
"y" | "z"
UPPER = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
"I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
"Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
"Y" | "Z"
LOWER = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
"i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
"q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
"y" | "z"
US-ASCII-SAFE = %x01-09 / %x0B-0C / %x0E-7F
;; US-ASCII except CR, LF, NUL
UTF8 = US-ASCII-SAFE / UTF8-1 / UTF8-2 / UTF8-3
/ UTF8-4 / UTF8-5
UTF8-CONT = %x80-BF
UTF8-1 = %xC0-DF UTF8-CONT
UTF8-2 = %xE0-EF 2UTF8-CONT
UTF8-3 = %xF0-F7 3UTF8-CONT
UTF8-4 = %xF8-FB 4UTF8-CONT
UTF8-5 = %xFC-FD 5UTF8-CONT
US-ASCII-SAFE = %x01-09 / %x0B-0C / %x0E-7F
;; US-ASCII except CR, LF, NUL
UTF8 = US-ASCII-SAFE / UTF8-1 / UTF8-2 / UTF8-3
/ UTF8-4 / UTF8-5
UTF8-CONT = %x80-BF
UTF8-1 = %xC0-DF UTF8-CONT
UTF8-2 = %xE0-EF 2UTF8-CONT
UTF8-3 = %xF0-F7 3UTF8-CONT
UTF8-4 = %xF8-FB 4UTF8-CONT
UTF8-5 = %xFC-FD 5UTF8-CONT
N.B.: The only tokenization type permitted is "TOKEN". While the Tagged Index Object memo permits the use of "FULL" (i.e., the entire value of the attribute is preserved as a single token), that has the danger of yielding a unique token for every record. Studies in the growth of centroid sizes as a function of number of records (see [14]) demonstrate that such unique tokens (e.g., phone numbers) are to be avoided. While storing tag information requires some number of extra bytes of storage per token index entry, using unique tokens causes the number of token entries in the index to continue to grow linearly with the number of records, thereby affecting search efficiency.
注意：唯一允许的标记化类型是“TOKEN”。虽然标记的索引对象备忘录允许使用“FULL”（即，属性的整个值作为单个标记保留），但存在为每个记录生成唯一标记的危险。关于形心大小随记录数量的增加而增加的研究（见[14]）表明，应避免使用此类独特的标记（如电话号码）。虽然存储标记信息需要每个令牌索引项额外存储一定数量的字节，但使用唯一令牌会导致索引中的令牌项数量继续随记录数线性增长，从而影响搜索效率。
Note also that tags are to be applied to the data on a per entry level. Thus, if two index lines in the same index object contain the same tag, then it is always the case that those two lines refer back to the same "record" in the directory. In LDAP terminology, the two lines would refer back to the same directory object.
还请注意，标记将应用于每个条目级别的数据。因此，如果同一索引对象中的两个索引行包含相同的标记，那么这两行总是引用目录中相同的“记录”。在LDAP术语中，这两行将引用回同一个目录对象。
Additionally if two index lines in the same index object contain different tags, then it is always the case that those two lines refer back to different records in the directory.
另外，如果同一索引对象中的两个索引行包含不同的标记，那么这两行总是引用目录中的不同记录。
The attribute "objectclass" is used to denote the record/object types in the data summarized in this index object.
属性“objectclass”用于表示此索引对象中汇总的数据中的记录/对象类型。
Values for the objectclass attribute should be restricted to: dagperson or dagrole, the two DAG schema object types.
objectclass属性的值应限制为：dagperson或dagrole这两种DAG架构对象类型。
WDSPs are expected to create index objects following the general principles outlined in the Whois++ protocol documentation (creation of centroids) and the Tagged Index Object documentation ([12]). Following the syntax described above, the index object contains token information for each attribute in the DAGSchema:
WDSP应按照Whois++协议文档（质心创建）和标记索引对象文档（[12]）中概述的一般原则创建索引对象。按照上述语法，index对象包含DAGSchema中每个属性的标记信息：
- a list of all the unique tokens (strings delimited by the specified characters) that appear in the WDSP database for the attribute - for each token in that list, which records the token appears in
- WDSP数据库中显示的属性的所有唯一标记（由指定字符分隔的字符串）的列表-对于该列表中记录标记的每个标记，该列表显示在中
So, for example,
那么比如说,，
Record #1: FN: Foo Bar ORG: The Snack Bar
记录#1:FN:Foo Bar组织：快餐店
Record #2: FN: Bar Smith ORG: Snack Shack
记录#2:FN:Bar Smith组织：快餐店
yields (conceptually) the following information for the attribute FN:
产生（概念上）属性FN的以下信息：
Foo (1), Bar (1,2), Smith (2)
傅（1）、巴（1、2）、史密斯（2）
and the following information for the attribute ORG:
以及属性组织的以下信息：
The (1), Snack (1, 2), Bar (1), Shack (2)
快餐店（1，2），酒吧（1），棚屋（2）
Note that the record numbers here are used simply as tags or virtual record identifiers to indicate when 2 tokens appear in the same record. The record identifiers are not used for any part of any query to the WDSP.
请注意，此处的记录编号仅用作标记或虚拟记录标识符，以指示两个令牌何时出现在同一记录中。记录标识符不用于对WDSP的任何查询的任何部分。
There is some discussion as to whether the use of the same record tag for all attributes makes it too easy to "decompile" the index object; i.e., reconstruct a WDSPs data based on re-ordering the tokens associated with each attribute and tag number. However, we are dealing only with the search attributes here, which is a minimal subset of the quantity of data held by the WDSP. The conclusion is then that the improved efficiency given by using the same tag numbers across attributes outweighs the (remote) possibility of information reconstruction.
对于是否对所有属性使用相同的记录标记会使索引对象“反编译”过于容易，存在一些讨论；i、 例如，基于对与每个属性和标签号相关联的令牌重新排序，重构WDSPs数据。然而，我们在这里只处理搜索属性，它是WDSP所持有数据量的最小子集。结论是，通过在属性之间使用相同的标签号所提高的效率超过了（远程）信息重建的可能性。
This would yield the index object:
这将生成索引对象：
version: x-tagged-index-1 update-type: total this-update: 855938804
版本：x-tagged-index-1更新类型：总计此更新：855938804
last-update: context-size: BEGIN IO-Schema objectclass: TOKEN
上次更新：上下文大小：开始IO架构对象类：标记
FN: TOKEN
ORG: TOKEN
END IO-Schema
BEGIN Index-Info
objectclass: */dagperson
FN: 1/Foo
-1,2/Bar
-2/Smith
ORG: 1/The
-1,2/Snack
-1/Bar
-2/Shack
End Index-Info
FN: TOKEN
ORG: TOKEN
END IO-Schema
BEGIN Index-Info
objectclass: */dagperson
FN: 1/Foo
-1,2/Bar
-2/Smith
ORG: 1/The
-1,2/Snack
-1/Bar
-2/Shack
End Index-Info
TISDAG: Within the project it has been decided to base consistency between updates on consistent tags. This means that if the update-type is "incremental" the specifier must be "tagbased".
TISDAG：在项目中，已决定将更新之间的一致性建立在一致的标记上。这意味着，如果更新类型为“增量”，则说明符必须为“基于标记”。
It is beyond the scope of this document to define how WDSP servers shall be registered with the DAG Referral Index. Such a procedure must be defined, and the following information established for each WDSP dataset (adapted from the Tagged Index Object specification, [12]):
定义如何在DAG参考索引中注册WDSP服务器超出了本文件的范围。必须定义此类程序，并为每个WDSP数据集建立以下信息（改编自标记索引对象规范[12]）：
dsi: An OID which uniquely identifies the subtree and scope of the dataset for which the index object is created.
dsi：唯一标识为其创建索引对象的数据集的子树和范围的OID。
base-uri: One or more URI's which will form the base of any referrals created based upon the index object that is governed by this agreement. For example, for LDAP the base-uri would specify (among other items): the LDAP host, the base object to which this index object refers (e.g., c=SE), and the scope of the index object (e.g., single container).
基本uri：一个或多个uri，将构成基于本协议管辖的索引对象创建的任何引用的基础。例如，对于LDAP，基本uri将指定（除其他项外）：LDAP主机、该索引对象所引用的基本对象（例如，c=SE）和索引对象的范围（例如，单个容器）。
supplier: The hostname and listening port number of the supplier server, as well as any alternative servers holding that same naming contexts, in case the supplier is unavailable.
供应商：供应商服务器的主机名和侦听端口号，以及在供应商不可用的情况下保存相同命名上下文的任何替代服务器。
source-uri: The URI of the WDSP's preferred source of directory service information. This might be, for instance, an HTTP-based service.
源uri：WDSP首选目录服务信息源的uri。例如，这可能是一个基于HTTP的服务。
consumeraddr: This is a URI of the "mailto:" form, with the RFC 822 email address of the consumer server.
consumeraddr：这是“mailto:”表单的URI，具有消费者服务器的RFC 822电子邮件地址。
updateinterval: The maximum duration in seconds between occurrences of the supplier server generating an update. If the consumer server has not received an update from the supplier server after waiting this long since the previous update, it is likely that the index information is now out of date. A typical value for a server with frequent updates would be 604800 seconds, or every week.
updateinterval：供应商服务器生成更新之间的最长持续时间（秒）。如果消费者服务器在上次更新后等待了这么长时间后仍未收到供应商服务器的更新，则索引信息现在可能已过期。频繁更新的服务器的典型值为604800秒或每周。
attributeNamespace: Every set of index servers that together wants to support a specific usage of indices, has to agree on which attributenames to use in the index objects. The participating directory servers also has to agree on the mapping from local attributenames to the attributenames used in the index. Since one specific index server might be involved in several such sets, it has to have some way to connect a update to the proper set of indexes. One possible solution to this would be to use different DSIs.
attributeNamespace：想要共同支持索引的特定用法的每一组索引服务器，必须就在索引对象中使用哪些AttributeName达成一致。参与的目录服务器还必须就从本地AttributeName到索引中使用的AttributeName的映射达成一致。由于一个特定的索引服务器可能涉及多个这样的集合，因此它必须有某种方式将更新连接到适当的索引集合。一种可能的解决方案是使用不同的DSI。
consistencybase: How consistency of the index is maintained over incremental updates: complete - every change or delete concerning one object has to contain all tokens connected to that object. This method must be supported by any server who wants to comply with this standard tagbased - starting at a full update every incremental update referring back to this full updated has to maintain state-information regarding tags, such that a object within the original database is assigned the same tagnumber every time. This method is optional.
一致性数据库：如何在增量更新中保持索引的一致性：完成-关于一个对象的每次更改或删除都必须包含连接到该对象的所有标记。任何希望遵守此基于标记的标准的服务器都必须支持此方法-从完全更新开始，每次引用此完全更新的增量更新都必须维护有关标记的状态信息，以便每次为原始数据库中的对象分配相同的标记号。此方法是可选的。
uniqueID - every object in the Dataset has to have a unique value for a specific attribute in the index. A example of such a attribute could be the distinguishedName attribute. This method is also optional.
uniqueID-数据集中的每个对象都必须具有索引中特定属性的唯一值。这种属性的一个示例可以是DiscriminatedName属性。此方法也是可选的。
securityoption: Whether and how the supplier server should sign and encrypt the update before sending it to the consumer server. Options for this version of the DAG service are "none": the update is sent in plaintext "PGP/MIME": the update is digitally signed and encrypted using PGP (see [7]). PGP/MIME is recommended.
securityoption：供应商服务器是否以及如何在将更新发送到消费者服务器之前对其进行签名和加密。此版本的DAG服务选项为“无”：以明文“PGP/MIME”发送更新：使用PGP对更新进行数字签名和加密（参见[7]）。建议使用PGP/MIME。
security credentials: The long-term cryptographic credentials used for key exchange and authentication of the consumer and supplier servers, if a security option was selected. For "PGP/MIME", this will be the trusted public keys of both servers.
安全凭据：如果选择了安全选项，则用于用户和供应商服务器的密钥交换和身份验证的长期加密凭据。对于“PGP/MIME”，这将是两台服务器的受信任公钥。
CIP Index Objects are sent to the DAG Referral Index by MIME-encoded SMTP, following the Common Indexing Protocol specification (see [2] and [3]).
CIP索引对象通过MIME编码的SMTP发送到DAG引用索引，遵循通用索引协议规范（请参见[2]和[3]）。
Appendix F - Summary of Technical Survey Results
附录F-技术调查结果汇总
As part of the TISDAG project, a technical survey was carried out -- announced on the tisdag@swip.net mailing list, all Swedish WDSPs (and potential WDSPs) were encouraged to fill out and submit the WWW-based survey form (see http://tisdag.sunet.se/tisdag-survey.html).
作为TISDAG项目的一部分，进行了一项技术调查——在tisdag@swip.net鼓励所有瑞典WDSP（和潜在WDSP）填写并提交基于WWW的调查表（见http://tisdag.sunet.se/tisdag-survey.html).
The survey was carried out in May, 1997. Response was not as good as had been hoped -- in the end, 5 WDSPs participated. We had hoped for more responses than this, in order to have a concrete sense of directory service providers' current and planned status. However, informal "hallway" conversations with a few people at Interoperabilitet'97 in Sollentuna suggest that, while people see the TISDAG project as an important and timely step, they don't necessarily have an immediate understanding of how it will impact them, and what they can/should contribute. So, the results can be seen as informational, though not a definitive statement of the whole directory service picture in Sweden.
调查于一九九七年五月进行。反应不如预期的好——最终有5名WDSP参与。我们希望得到更多的回应，以便具体了解目录服务提供商的当前和计划状态。然而，在Sollentuna的Interoperabiliet'97上，与一些人进行的非正式“走廊”对话表明，尽管人们认为TISDAG项目是一个重要而及时的步骤，但他们不一定立即了解它将如何影响他们，以及他们可以/应该做出什么贡献。因此，结果可以被视为信息性的，尽管不是瑞典整个目录服务状况的最终陈述。
Interesting things to note from these results include the fact that, although there were only 5 respondents, these are clearly significant players -- 4 expect to have more than 100 000 records to contribute by 12 months from now. There were no real surprises in terms of the supported protocols or search types.
从这些结果中值得注意的有趣事情包括，尽管只有5名受访者，但他们显然是重要的参与者——4名受访者预计在12个月后将有超过10万张记录做出贡献。就支持的协议或搜索类型而言，并没有什么真正的惊喜。
Table E.1 summarizes information from the survey concerning types of queries currently supported by WDSPs, and planned for the next 12 months. Note that, at the time of the survey, the requirement of searching by ROLE had not been proposed, so the survey did not specifically ask if WDSPs supported both the DAGPERSON schema protocol-equivalents (i.e., USER template in Whois++ and inetorgperson objectclass in LDAP). In the table, the column "Complete info?" describes whether or not the WDSP currently returns at least as much information as is required for a DAG reply.
表E.1总结了WDSP目前支持并计划在未来12个月进行的查询类型调查的信息。请注意，在调查时，还没有提出按角色搜索的要求，因此调查没有明确询问WDSP是否同时支持DAGPERSON模式协议等价物（即Whois++中的用户模板和LDAP中的inetorgperson对象类）。在表中，“完整信息”列描述了WDSP当前是否返回至少与DAG回复所需信息相同的信息。
Resp Search Types Complete info? Access Protocols Access Protocols
(now) (12 months)
---- ------------ -------------- ---------------- ----------------
1 NOL Except ROLE Whois++ Whois++
Resp Search Types Complete info? Access Protocols Access Protocols
(now) (12 months)
---- ------------ -------------- ---------------- ----------------
1 NOL Except ROLE Whois++ Whois++
2 N,NO,NL,NOL Except ROLE LDAPv2,DAP,PH, LDAPv2,LDAPv3,DAP, HTTP,Gopher PH,HTTP,Gopher
2 N、否、NL、NOL，角色LDAPv2、DAP、PH、LDAPv2、LDAPv3、DAP、HTTP、地鼠PH、HTTP、地鼠除外
3 N,NL,NOL Except ROLE LDAPv2,DAP,HTTP LDAPv2,LDAPv3,DAP, HTTP
3 N、NL、NOL，角色LDAPv2、DAP、HTTP LDAPv2、LDAPv3、DAP、HTTP除外
4 N,NO,NL,NOL Except ROLE Whois++,HTTP LDAPv3,Whois++,
HTTP,E-mail
4 N,NO,NL,NOL Except ROLE Whois++,HTTP LDAPv3,Whois++,
HTTP,E-mail
5 N,NO,NL,NOL Except ROLE LDAPv2,Whois LDAPv2,LDAPv3, Whois++,HTTP Whois,Whois++,PH, Finger,HTTP
5 N、否、NL、NOL，角色LDAPv2、Whois LDAPv2、LDAPv3、Whois++、HTTP Whois、Whois++、PH、Finger、HTTP除外
Table F.1 Summary of TISDAG Survey Results: Queries
表F.1 TISDAG调查结果汇总：查询
Resp # of Records (now) # of Records (12 months) Character Sets
----- ------------------ ------------------------ --------------
1 94 280 120 000 - 130 000 ISO-8859-1
2 88 000 100 000 ISO-8859-1
3 N/A 100 000 T.61 (Telex)
4 150 000 250 000 ISO-8859-1
UTF-8 UNICODE
5 4 300 10 000 ISO-8859-1
Resp # of Records (now) # of Records (12 months) Character Sets
----- ------------------ ------------------------ --------------
1 94 280 120 000 - 130 000 ISO-8859-1
2 88 000 100 000 ISO-8859-1
3 N/A 100 000 T.61 (Telex)
4 150 000 250 000 ISO-8859-1
UTF-8 UNICODE
5 4 300 10 000 ISO-8859-1
Table F.2 Summary of TISDAG Survey Results: Operational Information
表F.2 TISDAG调查结果汇总：运营信息
Appendix G - Useful References
附录G-有用参考资料
N.B.: The following is a collection of Internet standards documents (RFCs) and Internet-Drafts from which the material in this report was drawn. Internet-Drafts are works-in-progress, and are not meant to be cited. Where they are used in this document, references are to the text contained in the Internet-Draft; i.e., they are not meant to imply standards, so much as useful starting points for the work of this project.
注：以下是互联网标准文件（RFC）和互联网草案的集合，本报告中的材料来源于这些文件和草案。互联网草稿是正在进行的工作，并不打算被引用。本文件中使用的参考文件是指互联网草案中包含的文本；i、 例如，它们并不意味着标准，而是本项目工作的有用起点。
Electronic copies of the version of the Internet-Drafts documents that were used in preparing this report are available from the project web page, http://tisdag.sunet.se.
编制本报告时使用的互联网草稿文件版本的电子副本可从项目网页上获得，http://tisdag.sunet.se.
Bibliography
参考文献
[1] Allen, J. and M. Mealling, "The Architecture of the Common Indexing Protocol", RFC 2651, August 1999.
[1] Allen，J.和M.Mealling，“通用索引协议的架构”，RFC 26511999年8月。
[2] Allen, J. and M. Mealing, "MIME Object Definitions for the Common Indexing Protocol (CIP)", RFC 2652, August 1999.
[2] Allen，J.和M.Mealing，“通用索引协议（CIP）的MIME对象定义”，RFC 2652，1999年8月。
[3] Allen, J. and P. Leach, "CIP Transport Protocols", RFC 2653, August 1999.
[3] Allen，J.和P.Leach，“CIP传输协议”，RFC 2653，1999年8月。
[4] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[4] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[5] Crocker，D.，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[6] Deutsch, P., Schoultz, R., Falstrom, P. and C. Weider, "Architecture of the WHOIS++ Service", RFC 1835, July 1995.
[6] Deutsch，P.，Schoultz，R.，Falstrom，P.和C.Weider，“WHOIS++服务的体系结构”，RFC 18351995年7月。
[7] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
[7] Elkins，M.，“具有良好隐私的MIME安全性（PGP）”，RFC 2015，1996年10月。
[8] Patrik Faltstrom, Martin Hamilton, Leslie L. Daigle, "WHOIS++ templates", Work in Progress.
[8] Patrik Faltstrom、Martin Hamilton、Leslie L.Daigle，“WHOIS++模板”，正在进行中。
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Interent Message Bodies", RFC 2045, November 1996.
[9] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[10] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[10] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[11] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
[11] Good，G.，“LDAP数据交换格式（LDIF）-技术规范”，RFC 28492000年6月。
[12] Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A Tagged Index Object for use in the Common Indexing Protocol", RFC 2654, August 1999.
[12] Hedberg，R.，Greenblatt，B.，Moats，R.和M.Wahl，“通用索引协议中使用的标记索引对象”，RFC 2654，1999年8月。
[13] Howes, R., "A String Representation of LDAP Search Filters", RFC 1960, June 1996.
[13] Howes，R.，“LDAP搜索过滤器的字符串表示”，RFC1960，1996年6月。
[14] Paul Panotzki, "Complexity of the Common Indexing Protocol: Predicting Search Times in Index Server Meshes", Master's Thesis, KTH, September 1996.
[14] Paul Panotzki，“通用索引协议的复杂性：预测索引服务器网格中的搜索时间”，硕士论文，KTH，1996年9月。
[15] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[15] Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[16] Smith, M., "Definition of the inetOrgPerson Object Class", RFC 2798, April 2000.
[16] Smith，M.“inetOrgPerson对象类的定义”，RFC 2798，2000年4月。
[17] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[17] Wahl，M.，Howes，T.和S.Kille，“轻量级目录访问协议（v3）”，RFC 2251，1997年12月。
[18] Wahl, M., "A summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997.
[18] Wahl，M.，“与LDAPv3一起使用的X.500（96）用户模式摘要”，RFC 2256，1997年12月。
[19] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995.
[19] Yeong，W.，Howes，T.和S.Kille，“轻量级目录访问协议”，RFC 17771995年3月。
[20] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[20] “UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[21] The Unicode Consortium, "The Unicode Standard -- Version 2.0", Addison-Wesley, 1996.
[21] Unicode联盟，“Unicode标准——2.0版”，Addison Wesley，1996年。
Authors' Addresses
作者地址
Leslie L. Daigle Thinking Cat Enterprises
莱斯利·L·戴格尔思维猫企业
EMail: leslie@thinkingcat.com
EMail: leslie@thinkingcat.com
Roland Hedberg Catalogix Jegerveien 25 0777 Oslo Norway
挪威奥斯陆罗兰·赫德伯格目录25 0777
Phone: +47 23 08 29 96
EMail: Roland@catalogix.se
Phone: +47 23 08 29 96
EMail: Roland@catalogix.se
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编辑功能的资金目前由互联网协会提供。