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
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.
プロジェクトのDAG提案TISDAG（スウェーデンディレクトリアクセスゲートウェイのための技術基盤）の強さは、それがスウェーデンのインターネットユーザーについては、単一のアクセスポイントのサービスを提供するために必要な技術基盤を定義することです。情報へのアクセスの同じレベル（24時間365日サービス）、および利用可能同一の情報にかかわらず、その情報を維持する責任サービスプロバイダの、そのディレクトリサービスプロトコル、またはエンド - 得られたサービスは、すべての情報のための均一なアクセスを提供します-userのクライアントアクセスプロトコル。
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
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.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
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
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.
このプロジェクトの包括的な目標は、スウェーデンのインターネットユーザーのホワイトページの情報を検索するための単一のアクセスポイントのサービスを提供するために必要な技術基盤を開発することです。かかわらず、その情報を維持する責任サービスプロバイダの情報へのアクセスの同じレベル（24時間365日サービス）、および利用可能同じホワイトページ情報、 - サービスは、すべての情報のために均一でなければなりません。
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 -- 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提案の強さは、それがスウェーデンのインターネットユーザーについては、単一のアクセスポイントのサービスを提供するために必要な技術基盤を定義することです。情報へのアクセスの同じレベル（24時間365日サービス）、および利用可能同一の情報にかかわらず、その情報を維持する責任サービスプロバイダの、そのディレクトリサービスプロトコル、またはエンド - 得られたサービスは、すべての情報のための均一なアクセスを提供します-userのクライアントアクセスプロトコル。
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.
アーキテクチャ：システムは概念的に定義されると、提案されたソフトウェアアーキテクチャは、所望の機能性をもたらすと述べた要件を満たすために指定されています。
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：ホワイトページディレクトリ・サービス・プロバイダ - の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:
提案されたホワイトページディレクトリアクセスゲートウェイのユーザーの2つの主要なクラスがあります。
- End-users - WDSPs
- エンドユーザー - WDSPs
As outlined below, needs of each of these user classes imposes a set of constraints on the design of the DAG system itself. Some of the requirements shown below are assumed starting criteria for the DAG service; others have been derived from data collected in the Technical Survey or other expertise input.
下記に概説されるように、これらのユーザーの各クラスのニーズは、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
- フルネーム - E-mailアドレス - 役割 - 組織 - 地域 - フルアドレス - 電話番号
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.
このサービスに参加WDSPsはホワイトページ情報のサービスを提供するビジネスに既にあることを考えると、彼らはこのすべての関係に成功したと便利なサービスを行うために尊重されなければならない一定の要件を持っています。
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システムはWDSPsため、データの整合性の合理的な保証を提供する必要があります。エンドユーザーが見る情報はWDSPsで提供されるものに直接対応する必要があります。 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システムはWDSPsから受領した後、合理的な期間内に情報の更新を反映することができなければなりません。 DAGシステムはWDSPsからの定期的な更新で最高に機能しますしながら、フリップ側で、WDSPsのアップデートと参加オーバーヘッドが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.
さらに、WDSPsが可能エンドユーザーが最終的な詳細については、個々のディレクトリ・サービス・エントリの責任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.
エンドユーザーとWDSPsの要件に対処するためには、DAGシステム自体を考慮する必要があり、特定の設計上の制約があります。
The system must be implementable/operational by Dec 31/98 -- which implies that it must be designed and constructed with already extant technologies.
それは設計されており、すでに現存の技術で構築されなければならないことを意味します - システムは12月98分の31により運用/実装可能でなければなりません。
The System will have certain requirements for participation -- e.g., 7x24 WDSP availability.
例えば、24時間365日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.
スケーリングの面では、システムは、将来的に大きな情報システムの取り扱いを視野に、冒頭で8Mレコードを処理することができるはずです。
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
火曜日：これは火曜日のコメントです
The conceptual environment of the DAG system can be described in three major components:
DAGシステムの概念環境は、3つの主要コンポーネントで説明することができます。
- 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（ディレクトリアクセスゲートウェイ）は、サービスのインフラコアです。それは、既存のWDSPs'ディレクトリ・サーバーへの多様なディレクトリ・サービス・クライアント・ソフトウェアの円滑な接続を可能にするために必要なデータと変換施設を維持しています。システムのこの部分を設計する上で重要な課題は以下のとおりです。
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.
データの量 - 利用可能となるホワイトページ情報の量、及びその供給源の多様性（異なるWDSPs）は、効率的な検索を可能にする構造を見つけるの点で課題を導入し、必要な情報の更新の適時性を容易にします。
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自体は維持する必要があり、情報のソースにできるだけ近いホワイトページ情報（WDSPs自体）のメンテナンスを維持するためにデータの量を低減するために、DAGは、インデックス情報を維持し、「クエリを使用しますルーティングは、」効率的な絞り込み検索や情報の検索のためにWDSPsにエンドユーザーのクエリを参照します。元々の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" +---------+ @
\ | \ | | -+-
\ | ->| | |
\| +---------+ / \
+
The End Client DAG Directory Directory Users Software System Server Service Core Software Providers
エンドクライアントDAGディレクトリDirectoryユーザーソフトウェアシステムサーバーサービスコアソフトウェアプロバイダ
Figure 3.1 The role of the DAG system
DAGシステムの3.1役割図
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です。 N.B：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に記載されています。表から、3つの属性のすべての組み合わせがサポートされていないことがわかる - 唯一の目的の機能のために必要とされています。
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.
組織内の役割1の連絡先情報を検索する可能性があるため（例えば、社長、またはカスタマーサービスデスク） - 彼らは「仮想」の人物を検索しているとして、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
- フル語、完全一致 - Wordのサブストリングが一致（例えば、「猫」は「散布」に一致します） - 大文字と小文字が区別され、大文字と小文字を区別しないマッチング
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の属性として最も使用される属性の一部として、大文字と小文字の区別をサポートしていますが、大文字と小文字を区別しないattributeTypes属性であるように、標準で定義されています。 DAGシステムへの影響はLDAP / X.500サーバーから収集したインデックスは、トークンで大文字と小文字を持っている可能性がある場合でも、それがネイティブである何かに意味を推測されるので、彼らは、このようなとして扱うことができないということです無意味と見なさ。上記の結論は紹介インデックスは大文字と小文字を区別しないとケース感度ネイティブアクセスプロトコルがサポートしている場合のSAPによってサポートされる必要があるべきであるということです。
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が、UTF-8で構成されるUNICODE版の2文字エンコーディングに基づきます。
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.
WDSPsとDAG-SAP通信：特定のアクセスプロトコルは、文字セットの選択を可能に、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インデックスオブジェクト：DAGシステムにWDSPsから供給されたインデックスオブジェクトが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サービスのために使用されるスキーマは、これは非常に基本的な情報のDAGサービスのために必要な情報を伝えることを意図したスキーマ、およびないよりある付録Aで定義されています。一般的な「ホワイトページ」がスキーマ定義は、より洗練された情報提示を詳細に存在しない、より困難それは異なるパラダイムのプロトコル間でシームレススキーマをマッピングすることです。このように、「KISS」（「それをシンプルに保つ、先生は」）原則はここに適切と思われます。
Individual DAG-CAPs define how they express this schema.
個々のDAG-CAPには、彼らがこのスキーマを表現する方法を定義します。
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:
各DAY-CAPEは、より詳細なエラーメッセージを提供することができるが、最低限以下のエラー条件のためのサポートを定義します：
- 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はWDSPsから更新されたインデックスのオブジェクトを取得するための一般的なインデックスプロトコル（CIP）サーバサーバプロトコルを使用します。クエリルーティングの目的のために、WDSPsは（その優先アクセスが完全に異なるものであってもよいが）、そのデータのWhois ++、のLDAPv2またはLDAPv3のインタフェースを提供することが期待されます。 N.Bは：技術的な調査の回答では、すべての回答者は、現在、これらのプロトコルのいずれかで彼らのサービスへのアクセスを提供します。
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.
便利で均一なサービスを提供するために、WDSPsは、そのホワイトページ情報への24時間365日のアクセスを提供することが期待されています。 WDSPsはまた、両方の計画的および計画外の管理と保守活動のための時間をダウンサービス最小限に抑えるように設計運用、管理、保守、およびプロビジョニング・プロセスを実装することが期待されます。
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.12を通じて、個々の部品の仕様のセクション5.5に続いて、以下で説明されています。
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のコンポーネント間の通信は、DAG-内部プロトコル（DAG / IP）を使用して、TCP / IP接続であろう。 DAG / IPを紹介インデックス及びDAG-のSAPと通信するDAGキャップによって使用されます。このように、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-CAP要求への紹介インデックスの応答（およびその形式） - - （エンドユーザーの要求に応じて紹介を収集するために）紹介インデックス内のクエリ能力のDAG-CAPの範囲DAG-のCAP DAG-CAPは、クライアントアクセスソフトウェアの連鎖を行う必要があるときに紹介を追求するためのDAG-のSAPへのクエリ機能の「レンジ - DAG-CAPのにDAG-SAPの応答（およびその形式）。
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の相互作用は、個々のDAG-CAPとDAG-SAPの定義で与えられています下記（セクション5.12経由5.5）。
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の検索要求に応じて合理的な紹介のリストを提供する責任があります。これらの「紹介は、」エンドユーザーのクエリに合致する情報を有していてもよいWDSPsを識別するためのポインタを提供します。
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キャップ（すなわち、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)
+-------------------------------------+
All internal communications are in DAG/IP.
すべての内部通信は、DAG / IPです。
Figure 4.1 Conceptual Architecture of the DAG
DAGの4.1アーキテクチャの概念図
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).
指定されたWDSPサービスで指示されたクエリを発行する - 個々のDAG-SAPはDAG-生成された紹介を取り、それらを追求する（DAG-CAPによる）に呼びかけています。個々WDSPsからの結果は、要求を行ったDAG-CAPのために戻ってDAG / IP固有の形式に変換されます。各DAG-SAPは、特定のプロトコル（例えば、のLDAPv2、フーイズ++、等）のWDSPsに照会を処理する責任があります。
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システムは、ユーザのクライアント・ソフトウェアは、それ自体を扱うことができないという紹介を追求するために連鎖サービスを提供します。この連鎖サービスはWDSPsからのデータに対して、ユーザのクエリに一致する試みを行いますが、これは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 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システムの制限されたクエリ構文を考えると、常に正確にSAPに提起したクエリにCAPに提起したクエリに一致することはできません。これは、例えば、DAGシステムでLDAPサーバーに連鎖されたDAGシステムにクエリを発行のLDAPv2クライアントが直接問題になっているサーバーに接続されたクライアントの場合と同じ結果が得られないかもしれないという効果があります。
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システムのさえ制限されたクエリ構文はWDSPsへのアクセスプロトコルで表現することが可能ではないかもしれないクエリを発現することができます。これらのケースでは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.
「N」許容エンドユーザーの照会アクセス・プロトコルがあり、理論的な用語であり、「M」は、WDSPサーバプロトコルをサポート - DAGシステムによって提供される連鎖サービスの一部として、プロトコル間のマッピングの一定量を必要とします。ソフトウェアのアーキテクチャは、すべてのコンポーネント間の共通言語を提供する、単一の内部プロトコル（DAG / IP）とデータスキーマを使用するように構成されています。 N×Mのプロトコルマッピング - これがないと、各入力プロトコルモジュール（DAG-CAP）は、すべてのWDSPプロトコルを処理することができるように構築されなければなりません。これは、システムの複雑になるだろう、と難しい将来的に新しいプロトコルが含まれるように展開します。
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-CAPのプロトコルに関係なく、DAG / IPでそれに提起されたクエリに応答します。
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 / IP：このように、DAG-CAPはわずか2プロトコルを "知っています"。
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 / IP：このように、DAG-SAPはわずか2プロトコルを "知っています"。
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-のCAPでサポートされているクエリプロトコルを使用します。 WDSPsは、DAG-のSAPでサポートされるクエリプロトコルを使用して接触させます。
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システムの将来のバージョンでは、他のアクセス・プロトコルをサポートすることが可能 - エンドユーザーのために、そしてWDSPsため。
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>
<EN>
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.
3.3.1で定義されているすべてのDAG-CAPは、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).
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-キャップは（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を少なくとも1つの既知
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は、この1つがビジー状態である場合にエンドユーザソフトウェアが導くことができるため、同じタイプの別のDAGキャップの点で構成可能でなければなりません。
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で、または1つまたはより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は1 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は、ユーザへの単一の式に複数のerrorCodeを結合する必要があります機会もあります。 DAG-CAPは、1つまたは複数のWDSPsにDAG-SAPを経由クエリを「チェーン化」されるとDAG-のSAPからresponsecodesのミックスがあった場合、状況が発生することができます。この問題が発生した場合、DAG-CAPは、クエリとその理由を満たすことができなかったWDSPsのインスタンスの、できるだけ具体的であるエンドユーザーのソフトウェアに情報を転送するようにしてください。
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-SAPは他にサポートし、結果はDAG-CAPを収集するために持っている状況があります異なるアクセス・プロトコルの間には完全な一致はありませんので、である「広い」、その後に完璧にマッチがあった場合のケースだっただろうか。これは、管理限界が「不要」はWDSPs上または収集された結果は、DAG-CAPのいるsizelimitを超えていることを超えされる程度のシステムに悪影響を与える可能性があります。
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-のSAPから受信した結果を剪定することができDAG-CAP良くマッチ元の質問。
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.
3.3.1で定義されているすべてのDAG-SAPは、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 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-SAPを交互にDAG-キャップをリダイレクトするように構成可能でなければなりません。
A DAG-SAP must translate error codes received from a WDSP server to DAG error codes according to Appendix D.
DAG-SAPは、エラーコードを変換する必要があります付録D.によるDAGのエラーコードにWDSPサーバから受信しました
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-SAPによってサポートされるアクセスプロトコルでの問合せにDAGクエリをマップできない場合がありますので、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 =レスリー;検索=正確かつORG =思う：検索=ストリング
the resulting search constraint for "fn=leslie" will be "exact" while it for "org=think" will be "substring".
「FN =レスリー」の結果の検索制約はしばらく「ORG =だと思う」となります「サブ」のために「正確」になります。
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）を使用して、参加WDSPsのソフトウェアとの相互作用から直接描かれています。
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システムに参加することを希望するWDSPs（5.4.6項を参照してください）。一度登録、紹介インデックスは、[1]、セクション5.4.3で定義されたインデックスオブジェクトを使用して定義されている一般的なインデックスプロトコルを使用してWDSPsと相互作用します。
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.
[12]で定義されるようにCIPインデックスオブジェクトタイプは、タグ付き索引オブジェクトに基づいています。彼らはWDSPsによって提供されることになっているよう付録Eは、インデックスオブジェクトの期待される内容を詳しく説明します。
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).
紹介インデックスがクエリをリッスンし、（付録Cに定義されている）DAG / IPに応答することによって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.
紹介インデックス必見指数表3.1で説明した形式のクエリに応答するために、CIPインデックスオブジェクトの必要な属性。
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)
（付録Eで定義された）選択されたCIPオブジェクトの意味論は、（および場合のみ）場合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.
- WDSPの索引オブジェクトは、DAG / IPクエリの論理に応じて、指定された属性の問合せのすべてのトークンを含み、 - それらのトークンの全ては、共通のタグを発見しています。
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.
これは、名前「フレッド・フリントストーン」のためのクエリは（2トークン）が異なり、「フレッドアマデウス」のために、レコードをタグ付けではなく、2とWDSPに、「フレッド・アマデウスフリントストーン」のレコードを持っているサーバーへの紹介をもたらすことを意味しますそして「ジュリーフリントストーン」。使用されているアクセスプロトコルと、元のエンドユーザーのクエリに応じて、「フレッド・アマデウスフリントストーン」とWDSPへの紹介が成功した結果をもたらすことがあり、またはそうではないことがあります。しかし、他のWDSPが成功した検索が得られなかったであろうことが知られています。つまり、紹介のアプローチは、偽陽性の結果をもたらすかもしれないが、適切なWDSPsを見逃すことはありません。
The Referral Index must provide the ability to register interested WDSPs, as outlined in Appendix E.
付録E.に概説されているよう紹介指数は、興味WDSPsを登録する機能を提供しなければなりません
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ソフトウェアにさらされるべきではありませんDAG / IP、（すなわち、内部）プロトコルを使用するという事実に反映されます。
The Referral Index must be able to use authenticated communication to receive data from WDSPs (see Appendix E).
紹介インデックスは、（付録Eを参照してください）WDSPsからデータを受信するために認証された通信を使用することができなければなりません。
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入力は、アドバタイズメールアドレスに送信されたSMTPメールメッセージ、（[9]及び[10]を参照）規則的又はMIMEエンコードであると予想されます。メール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] [コントロール] MNL用語MNL対照= [MSP] "検索タイプ" [MSP] "=" [MSP]（matchtype / casetype / matchtypeのMSP casetype / casetype MSPのmatchtype / <無>）matchtypeは= "ストリング" /「正確な」。デフォルト：サブストリングcasetype =「敏感」/「無視」。デフォルト：無視
terms = n / n-l / n-o / n-o-l / r-o / r-o-l
用語= 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-用語NL =（N-用語L-用語/ L-用語N末端）= NO（N-用語O-用語/ O-用語N末端）NOL =（N-用語O項-1-用語/ N-用語L-用語O-用語/ L-用語N-用語O-用語/ L-用語O-用語N-用語/ O-用語L-用語N-用語/ O-用語N末端1-用語）RO =（R-O-用語用語/ O-用語R-用語）ROL =（R-用語O-用語L-用語/ R-用語L期0期/
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-用語O-用語R-用語/ L-用語R-用語O-用語/ O-用語L-用語R-用語/ O-用語R-用語L-用語）は、n-TERM = [MSP] "名前" [MSP] "=" [MSP]列MNL 0期= [MSP] "ORG" [MSP] "=" [MSP]列MNLのL-用語= [MSP] "LOC" [MSP] "=" [MSP ]文字列MNLのR-TERM = [MSP] "役割" [MSP] "=" [MSP]ストリング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)
文字列= <US-ASCIIまたはquoted-printableのエンコードされたISO-8859-1またはUTF-8 NLとSPを除く> MSP = 1 *（SP）SP = "" MNL = 1 *（NL）
nl = <linebreak>
NL = <改行>
The following are valid mail queries:
以下は、有効なメールクエリです：
Example 1:
例1：
searchtype = <NL> name = thinking cat<NL>
検索タイプ= <NL>名前=思考の猫<NL>
Example 2:
例2：
searchtype = exact ignore<NL> name=thinking cat<NL>
検索タイプ=正確な無視<NL>名前=思考の猫<NL>
Example 3:
例3：
role=thinking cat<NL> org =space colonization<NL>
役割=思考猫<NL> ORG =スペース植民地化<NL>
Example 4:
例4：
name=thinking cat <NL> <NL> <NL> My signature line follows here in the most annoying fashion <NL>
名前=思考の猫<NL> <NL> <NL>私の署名ラインは最も厄介なやり方で、ここでは次の<NL>
Note that the following are not acceptable queries:
以下は許容のクエリではないことに注意してください。
Example 5:
例5：
searchtype= exact substring <NL> name = thinking cat <NL>
検索タイプ=正確なサブ<NL>名前=思考猫<NL>
Example 6:
例6：
name=thinking cat org= freedom fighters anonymous<NL>
名前= <NL>匿名猫ORG =自由の戦士を考えます
In Example 5, two conflicting searchtypes are given. In Example 6, no linebreak follows the n-term.
実施例5では、2つの競合searchtypesが挙げられます。実施例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 / IPクエリ形式にメールDAG-CAP入力から翻訳の重要な要素は、DAG / IPクエリの単一のトークン要素に入力された用語を「トークン化」することです。例えば、N末端
name= thinking cat<NL>
名前=思考猫<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-N-用語）DAG / IPクエリで以下にマッピングされます。
FN=thinking and FN=cat<NL>
FN =思考とFN =猫<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
引用された印刷可能なエンコーディングを変換、必要に応じて必要な場合は、各用語の文字列トークン化、base64エンコーディングを翻訳以下でより詳細に説明するように、得られた成分からDAG / IPクエリを構築します
DAG/IP constraints are constructed from the searchtype information in the query.
DAG / IPの制約は、クエリで検索タイプの情報から構成されています。
dag-matchtype = "search=" <matchtype> / "search=substring" ; if matchtype not ; specified
DAG-matchtype = "検索=" <matchtype> / "=部分文字列を検索します"。 matchtypeない場合。指定されました
dag-casetype = "case=ignore" / ; if casetype not ; specified or ; casetype=ignore "case=consider" ; if casetype=sensitive
DAG-casetype = "ケース=無視します" /。 casetypeない場合。指定されましたか; casetype =無視する "ケース=考えます"; 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-用語= "FN =" N-トークン0 *（ "及びFN =" N-トークン）DAG-O-用語= "ORG =" O-トークン0 *（ "とORG =" O-トークン） DAG -1-用語= "LOC =" Lトークン0 *（ "とLOC =" Lトークン）DAG-R-用語= "ロール=" R-トークン0 *（ "とROLE =" R-トークン）
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クエリ=（（（N-クエリ/ NL-クエリ/無クエリ/ NOL-クエリ） "とテンプレート= DAGPERSON "]"：" DAG-matchtype "" DAG-casetype）/（（RO-クエリ/ ROLクエリ） "とテンプレート= 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-クエリ= DAG-N-用語NL-クエリ= DAG-N-用語 "および" DAG -1-用語無クエリ= DAG-N-用語 "および" DAG-O-用語NOLクエリ= DAG-N -terms "および" DAG-O-用語 "および" DAG -1-用語RO-クエリ= DAG-R-用語 "および" DAG-O-用語ROLクエリ= DAG-R-用語 "および" DAG-O- -terms「と」DAG -1-用語
The examples given earlier are then translated as follows.
次のように先に与えられた例は、次に翻訳されます。
Example 1:
例1：
FN=thinking and FN=cat:search=substring;case=ignore<NL>
FN =思考とFN =猫：検索=サブ;ケース=無視<NL>
Example 2:
例2：
FN=thinking and FN=cat:search=exact;case=ignore<NL>
FN =思考とFN =猫：検索=正確な;場合=無視<NL>
Example 3:
例3：
ROLE=thinking and ROLE=cat and ORG=space and ORG=colonization:search=substring;case=ignore<NL>
ROLE =思考とROLE =猫とORG =スペースとORG =植民地化：検索=サブ;ケース=無視<NL>
Querying a DAG-SAP
SAP-DAGの照会
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サーバに関する情報を含まなければなりません。この情報は、紹介インデックス）の紹介情報をSERVER-TO-ASK、および付録Cに指定されたクエリに追加されるから引き出されます。
":host=" quoted-hostname ";port=" number ";server-info=" quoted-serverinfo ";charset=" charset
"：ホスト=" ホスト名引用された ";ポート=" 番号 "; serverinfo ="-serverinfo引用された ";の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
"＃のSERVER-TO-ASK" にserverHandle NL "サーバー情報を：" serverinfo NL "ホスト名：" ホスト名のNL "ホストポート：" 数NL
" Protocol: " prot nl " Source-URI: " source nl " Charset: " charset nl "# END" nl
"プロトコル：" PROT NL "ソース-URI：" ソースNL "文字セット：" 文字セットNL "＃1 END" NL
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
そして、「引用符で囲まれたホスト名」および「引用され-serverinfoは、」DAG / IPの特殊文字を引用して、それぞれ「ホスト名」と「serverinfo」から取得されます。
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>サーバー情報を：O = thinkingcat、C = SE <NL>ホスト名：thinkingcat.com <NL>ホスト・ポート：2839 <NL>プロトコル：LDAPv2の<NL>ソース - URI：http://www.thinkcat.com文字セット：T.61 <NL>＃1 END <NL>
would yield the addition
追加をもたらすであろう
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\ c\=se;charset=T\.61
：ホスト= thinkingcat \ .COM;ポート= 2839;サーバー情報= O \ = thinkingcat \、\ C \ = SE;のcharset = T \ 0.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).
（N.Bは：SERVER-TO-ASK応答で使用される用語のさらなる定義については、付録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.
クエリからこれらの用語を抽出し、連絡するWDSPサーバを識別するためにそれらを使用するDAG-SAPの責任であることに注意してください。以下、個々の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.
Whois ++ DAG-SAP、DAGのLDAPv2-SAP、またはLDAPv3のDAG-SAPへの紹介のための適切な - メールDAG-CAPは、チェーンにすべての参照を持っています。
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]参照）が使用可能な場合：結果メッセージは、「返信先」に送られます。元のクエリは、メッセージ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 =スベンソン」など）、メール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.
ウェブDAG-CAPは、標準のHTTPプロトコルを介してそのインタフェースを提供します。一般的な期待がウェブ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」メソッド（上記、または他の場所で生成されたページのフォームアクションの結果）を介してクエリを受信します。このセクションの残りの部分は、そのポストに発現することがある変数について説明します。ページの実際のレイアウトとほとんどのユーザーインターフェースの問題は、ビルダーの裁量に委ねられています。 HTTP接続のリクエストヘッダ：ウェブDAG-CAPは、異なるコンテンツのエンコーディングに応答を提供するために呼び出されてもよいので、「同意エンコード」に対処しなければならないことに注意してください。
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.
ウェブプロトコル、HTTPは、このクライアントは、これらのプロキシとして、参照情報を要求し、Web DAG-CAP自体を通じて個々の紹介を追求するオプションが与えられている2つの追加の変数を使用して、照会を処理すること自体ではありませんが紹介。これが唯一の紹介を依頼すると、トランザクションが紹介を追求する前の問合せの続きであることを示すために、余分な「制御変数」を介して処理されます。
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メッセージのリクエストヘッダ内：これらは、「アプリケーション/ whoispp応答を受け入れ、コンテンツ」を指定して要求されています。
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>
トランザクション=「新しい」/「連鎖」;デフォルトでは、「新」です。この ;ユーザが設定可能であってはなりません。これは、使用されています。構築されたURLに=「すべて」/「紹介」resultTypeと。デフォルトでは、 "すべて" matchtype = "ストリング" / "正確な" casetype = "場合無視する" / "大文字と小文字を区別" N-用語=ストリングO-TERM =列L-TERM =文字列R-TERM =文字列ホスト用語=文字列でありますポート期=文字列servinfo期=文字列PROT期=文字列。照会ストリングのプロトコル= <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.
トランザクションの変数は「チェーン」である場合は、POST中の情報は、特定の紹介を追求するために使用され、紹介インデックスの検索をしません。 （PROT-期から推定）適切なDAG-SAPに連絡し、直接クエリを発行しています。
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
DAG / IPクエリ形式にウェブDAG-CAP入力から翻訳の重要な要素は、DAG / IPクエリの単一のトークン要素に入力された用語を「トークン化」することです。例えば、N末端
name= thinking cat
名前=思考の猫
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-N-用語）DAG / IPクエリで以下にマッピングされます。
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:
DAG / IPの問合せにHTTP入力を翻訳における主な手順は次のとおりです。
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の制約は、クエリで検索タイプの情報から構成されています。
dag-matchtype = "search=" <matchtype> / "search=substring" ; if matchtype not ; specified
DAG-matchtype = "検索=" <matchtype> / "=部分文字列を検索します"。 matchtypeない場合。指定されました
dag-casetype = "case=ignore" / ; if casetype not ; specified or ; casetype="case ignore" "case=consider" ; if casetype= ; "case sensitive"
DAG-casetype = "ケース=無視します" /。 casetypeない場合。指定されましたか; casetypeは= =「考える場合」「ケースを無視します」。 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ポスト入力からトークン化された文字列から構築されています。
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-用語= "FN =" N-トークン0 *（ "及びFN =" N-トークン）DAG-O-用語= "ORG =" O-トークン0 *（ "とORG =" O-トークン） DAG -1-用語= "LOC =" Lトークン0 *（ "とLOC =" Lトークン）DAG-R-用語= "ロール=" R-トークン0 *（ "とROLE =" R-トークン）
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クエリ=（（（N-クエリ/ NL-クエリ/無クエリ/ NOL-クエリ） "とテンプレート= DAGPERSON "]"：" DAG-matchtype "" DAG-casetype）/（（RO-クエリ/ ROLクエリ） "とテンプレート= 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-クエリ= DAG-N-用語NL-クエリ= DAG-N-用語 "および" DAG -1-用語無クエリ= DAG-N-用語 "および" DAG-O-用語NOLクエリ= DAG-N -terms "および" DAG-O-用語 "および" DAG -1-用語RO-クエリ= DAG-R-用語 "および" DAG-O-用語ROLクエリ= DAG-R-用語 "および" DAG-O- -terms「と」DAG -1-用語
Querying a DAG-SAP
SAP-DAGの照会
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サーバに関する情報を含まなければなりません。この情報は、参照情報をSERVER-TO-ASK紹介インデックスから引き出され、および付録Cに指定されたクエリに追加されます。
":host=" quoted-hostname ";port=" number ";server-info=" quoted-serverinfo ";charset=" charset
"：ホスト=" ホスト名引用された ";ポート=" 番号 "; serverinfo ="-serverinfo引用された ";の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> "サーバー情報：" serverinfo <NL> "ホスト名：" ホスト名<NL> "ホスト・ポート：" 数<NL> "プロトコル：" PROT <NL> "ソース-URI：" ソース<NL> "文字セット：" 文字セット<NL> "＃1 END" <NL>
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
そして、「引用符で囲まれたホスト名」および「引用され-serverinfoは、」DAG / IPの特殊文字を引用して、それぞれ「ホスト名」と「serverinfo」から取得されます。
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>サーバー情報を：O = thinkingcat、C = SE <NL>ホスト名：thinkingcat.com <NL>ホスト・ポート：2839 <NL>プロトコル：LDAPv2の<NL>ソース - URI：http://www.thinkingcat.com文字セット：T.61 <NL>＃1 END <NL>
would yield the addition
追加をもたらすであろう
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\ c\=se;charset=T\.61
：ホスト= thinkingcat \ .COM;ポート= 2839;サーバー情報= O \ = thinkingcat \、\ C \ = SE;のcharset = T \ 0.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).
（N.Bは：SERVER-TO-ASK応答で使用される用語のさらなる定義については、付録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.
クエリからこれらの用語を抽出し、連絡するWDSPサーバを識別するためにそれらを使用するDAG-SAPの責任であることに注意してください。以下、個々の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とは「すべて」であった場合は、紹介インデックスから受け取った紹介の全ては、適切なDAG-SAPを使用して連鎖しています。唯一の紹介が要求された場合は、紹介インデックスの結果が返されます。
text/html results
text / 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.
デフォルトのレスポンスのエンコーディングは、テキスト/ htmlです。 resultTypeとは「すべて」であった場合は、DAG-のSAPから連鎖反応の内容は、システムメッセージなしで、単一ページ応答、区画線（例えば、箇条書き項目）ごとに1つの結果エントリに照合されます。 FNまたはROLE値が最初に明確に提示されるべきです。各WDSP照会のソースURIはWDSPs結果の各々について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とは、「紹介」であった場合は、紹介インデックスからの結果がために、「HOST =」などを含むクエリを（実行するために必要な情報を、ウェブDAG-CAP自体へのHREFのURLとして返されます紹介）。
For example, if the original query:
たとえば、元のクエリの場合：
n-term="thinking cat" resulttype="referrals"
N-用語= "思考猫" 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>サーバー情報：C = SE、O = TCE <NL>
Host-Name: answers.tce.com<NL> Host-Port: 1111<NL>
ホスト名：answers.tce.com <NL>ホスト・ポート：1111 <NL>
Protocol: ldapv3<NL> Source-URI: http://some.service.se/ Charset: UTF-8<NL> # END<NL>
プロトコル：LDAPv3の<NL>ソース-URI：http://some.service.se/文字セット：UTF-8 <NL>＃1 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:
応答が設定され、次の変数を使用してWeb DAG-CAPにHREF HTTP「POST」URLとHTMLページを次のようになります。
n-term="thinking cat" transaction="chain" servinfo-term="c=se, o=tce" host-term="answers.tce.com" port-term="1111" prot-term="ldapv3"
N-用語= "思考猫" トランザクション= "連鎖" servinfo期= "C = SE、O = TCE" ホスト用語= "answers.tce.com" ポート期= "1111" PROT-用語= "のLDAPv3 "
The Source-URI should be established in the response as its own HREF URI.
ソース-URIには、独自のHREF URIとして対応して確立されるべきです。
application/whoispp-response Results
アプリケーション/ whoispp応答結果
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.
-エンコーディングを受け入れた場合：アプリケーション/ whoispp-応答 『「HTTPのリクエストヘッダが値を持っていた』、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とは「すべて」であった場合は、すべての参照は、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とは、「紹介」であった場合は、すべての紹介は、正しいのWhois ++紹介形式で（便利、これは彼らが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.
ウェブDAG-CAPは、負荷分散の理由のために別のウェブ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.
ウェブ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 =スベンソン」と）、ウェブ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.
ウェブDAG-CAPは、DAG-のSAPから複数の結果コードを受信した場合、それは応答して、適切な方法でそれらのすべてを表している必要があります。
application/whoispp-response Errors
アプリケーション/ whoispp応答エラー
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クエリがあまりにも一般的な」メッセージを持っています。
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.
Input to the Whois++ DAG-CAP follows the Whois++ standard ([6]). Minimally, the Whois++ DAG-CAP must support the following queries:
フーイズ++ DAG-CAPへの入力は、フーイズ++標準に従う（[6]）。最低限、Whoisの++ DAG-CAPは、次のクエリをサポートする必要があります。
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つまたは複数の「名前=」1つ以上の「アドレス・地域=」テンプレート= USER
NO One or more "name=" and one or more "organization-name=" and template=USER
NO、1つまたは複数の「名前ません=」1つ以上の「組織名=」テンプレート= USER
NOL One or more "name=" and one or more "organization-name=" and one or more "address-locality=" and template=USER
NOLつまたは複数の「名前=」1つ以上の「組織名=」と1つ以上の「アドレス・地域=」テンプレート= USER
RO One or more "org-role=" and one or more "organization-name=" and template=ORGROLE
RO 1つ以上の「ORG-役割=」1つ以上の「組織名=」テンプレート= ORGROLE
ROL One or more "org-role=" and one or more "organization-name=" and one or more "address-locality=" and template=ORGROLE
ROL 1つ以上の「ORG-役割=」1つ以上の「組織名=」と1つ以上の「アドレス・地域=」テンプレート= ORGROLE
Table 5.1 Allowable Whois++ Queries
表5.1許容のWhois ++クエリ
The following constraints must be supported for queries:
次の制約は、クエリのためにサポートする必要があります。
"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とLOC =シスタおよびfn =バー<NL>を=
is a perfectly valid Whois++ NL query for "Foo Bar" in "Kista".
「シスタ」の「Fooのバー」のための完全に有効なの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).
フーイズ++ 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とLOC =シスタとFN =バーやテンプレートを= = DAGPERSON <NL>
Querying a DAG-SAP
SAP-DAGの照会
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サーバに関する情報を含まなければなりません。この情報は、紹介インデックスサーバー-TO-ASK参照情報から引き出され、および付録Cに指定されたクエリに追加されます。
":host=" quoted-hostname ";port=" number ";server-info=" quoted-serverinfo ";charset=" charset where the response from the Referral Index included:
"：ホスト=" 引用されたホスト名 ";ポートは=" 数 "; serverinfoは=" 引用され-serverinfo ";のcharset =" 文字セット紹介インデックスからの応答が含ま：
"# 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> "サーバー情報：" serverinfo <NL> "ホスト名：" ホスト名<NL> "ホスト・ポート：" 数<NL> "プロトコル：" PROT <NL> "ソース-URI：" ソース<NL> "文字セット：" 文字セット<NL> "＃1 END" <NL>
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
そして、「引用符で囲まれたホスト名」および「引用され-serverinfoは、」DAG / IPの特殊文字を引用して、それぞれ「ホスト名」と「serverinfo」から取得されます。
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>サーバー情報を：O = thinkingcat、C = SE <NL>ホスト名：thinkingcat.com <NL>ホスト・ポート：2839 <NL>プロトコル：LDAPv2の<NL>ソース - URI：http://www.thinkingcat.com/文字セット：T.61 <NL>＃1 END <NL>
would yield the addition
追加をもたらすであろう
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\ c\=se;charset=T\.61
：ホスト= thinkingcat \ .COM;ポート= 2839;サーバー情報= O \ = thinkingcat \、\ C \ = SE;のcharset = T \ 0.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).
（N.Bは：SERVER-TO-ASK応答で使用される用語のさらなる定義については、付録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.
クエリからこれらの用語を抽出し、連絡するWDSPサーバを識別するためにそれらを使用するDAG-SAPの責任であることに注意してください。以下、個々の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は、非のWhois ++の紹介（現在は、LDAPv2のとLDAPv3のDAG-のSAP）チェーンに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 / IP結果がDAG-のSAP（FULL応答を使用して）から受信した照合、および所与の照会からの各結果は、付録Bで定義されたテンプレートと属性マッピングを使用して、フーイズ++で表され、SOURCE属性は、付加され紹介からSOURCE-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" DAG-にserverHandle <NL> "サーバー・ハンドル：" SERVER-INFO <NL> "ホスト名：" HOST <NL> "ホスト・ポート：" PORT < NL> "プロトコル：" PROTOCOL <NL> "＃1 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.
SERVER-INFO、HOST、PORT、PROTOCOLがDAG / IPで提供紹介から引き出されており、どこSOURCE-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 =スベンソン」として）、フーイズ++ DAG-CAPは、送信されますエラーメッセージが表示され、接続を閉じます。エラーメッセージは、
% 503 Query too general<NL>
<NL>あまりにも一般的な％503クエリ
(N.B.: this is different from the "Too many hits" reply, which does send partial results.)
（N.Bは：これは、部分的な結果を送信し、「あまりにも多くのヒット曲」リプライとは異なります。）
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.
フーイズ++ DAG-CAPは、負荷分散の理由のために別のWhois ++ DAG-CAPへの接続をリダイレクトすることができます。これは、指定された代替DAG-CAPに到達するために適切な情報をSERVER-TO-ASK応答を使用してエンドユーザクライアントソフトウェアに表現されています。
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.
DAG / IP応答コードとwhoisの間の提案されたマッピング++応答コードは付録Dに記載されています
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
}
}
｝
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, attributes SEQUENCE OF AttributeType
}
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
}
}
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.
N.B.が、これは基本的なDAGに定義されたクエリを達成するために、サポートされるクエリの最小セットです。それはこれらのクエリのセマンティックに対応した方法でのLDAPv2クライアントにDAG / IPからの翻訳を行うことを約束する場合は、LDAP DAG-CAPは、これよりもより複雑なクエリをサポートすることもできます。
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のWebページ上の情報に基づいてその特定のクライアントを設定する必要があります。このページには、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.
DAG / IP紹介インデックスが照会にマッピングするLDAPクエリに不可欠な計略は、文字列指向のLDAPのAttributeValueAssertionsまたはSubstringFiltersをトークン化し、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-用語なしオブジェクトクラスの仕様が含まれている場合、検索は、人や役割のためであれば、それは不明です。これが発生すると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をトークン化（適切なDAGSchema属性を使用して）トークンごとにDAG / IPのクエリ用語を作り、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バー）（オブジェクトクラス= inetOrgPersonの））
This query can be represented in the DAG/IP as
このクエリは、DAGで表現することができます/ IPなど
FN="Foo" and FN="Bar":search=exact<NL>
FNは= "foo" とFN = "バー"：検索=正確な<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.
N.B.検索は、関連するLDAPスキーマの属性は大文字小文字を区別しないマッチングを持つように定義された「名前」属性要素の全ての誘導体であるので、（DAG / IPのデフォルト）「=ケースを無視」に設定されています。
If no objectclass were defined the query in DAG/IP would have been
何のオブジェクトクラスが定義されていない場合はDAG / IPでのクエリがあったであろう
(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.
（FN =「foo」とFN =「バー」）または（ROLE =「foo」と役割は=「バー」）：個人またはorganizationalPersonをも得るが検索は=正確のinetOrgPersonは、この中のオブジェクトクラスおよび以下の実施例として使用されています使用されています。
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.
このクエリでは、偽陽性の紹介を得られます。 DAG / IPのクエリが紹介に「foo」と「bar」の2つのトークンが含まれるレコードを含む任意のWDSPが得られるのに対し、元のLDAPクエリは、「CN」属性が正確に句「フーバー」であるため、レコードに対して一致している必要がありますいずれかのためです。
For example, this DAG/IP query will yield referrals to WDSPs with records including:
たとえば、このDAG / IPのクエリは、以下を含むレコードを持つWDSPsに紹介を得られます：
cn: Bar Foo cn: Le Bar Foo cn: Foo Bar AB
CN：CNフーバー：ル・バーCNフー：フーバー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.
LDAPのサブストリングクエリはまた、DAG / IPのクエリを構築するためにトークン化されなければなりません。心に留めするための追加点は、LDAPサブストリング式は句、あいまいな潜在的なトークンの境界に向けられているということです。このため、サブコンポーネント間のすべてのポイントは、潜在的なトークンの境界として考慮されなければなりません。
Thus, the LDAP query
このように、LDAPクエリ
(& (cn=black) (o=c*t) (objectclass=inetOrgPerson))
（＆（CN =黒）（C = Oの* tの）（オブジェクトクラス= 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>
検索サブストリング= <NL>：FNは、黒とORG = CとORG = T =
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とORG = T：検索=ストリング
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 only search types across the entire query for Referral Index queries.
複合EqualityMatchとサブストリングクエリは、特別な注意が必要です。 LDAPクエリがEqualityMatchコンポーネントおよびサブストリングフィルタコンポーネントの両方を含む場合、参照インデックスにDAG / IPクエリは、トークン化の同じメカニズムに従うことによって構築することができるが、DAG / IPのみ定義されたように全検索は、文字列検索になります紹介インデックスクエリのクエリ全体にわたる検索タイプ。
Thus,
したがって
(& (cn=Foo Bar) (o=c*t) (objectclass=inetOrgPerson))
（＆（CN =フーバー）（C = Oの* tの）（オブジェクトクラス = inetOrgPersonの））
can be expressed as
以下のように表すことができます。
FN=Foo and FN=Bar and ORG=c and ORG=t:search=substring<NL>
FN = fooとFN =バーとORG = CとORG = T：検索=サブ<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は、2つの別々のクエリを行い、紹介インデックスによって返さ紹介の二組の交点（論理「AND」）を取ることができます。
Note that DAG/IP can accept phrases for searches -- the query
DAG / IPは、検索用のフレーズを受け入れることに注意してください - クエリを
FN=Foo\ bar<NL> (note the escaped space)
FN =はFoo \バー<NL>（エスケープスペースに注意）
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
SAP-DAGの照会
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-SAPに送信するDAG / IPのクエリを作成する際に、上記のクエリは有効なクエリはまだですが、代替きめ細かいクエリはつまり、も可能です。
FN=foo and FN=bar and ORG=c;search=lstring and ORG=t;search=tstring
FNはfooとFN =バー=とORG = C;検索= LSTRINGとORG = T;検索= 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 \バー：検索=正確な<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サーバに関する情報を含まなければなりません。この情報は、参照情報をSERVER-TO-ASK紹介インデックスから引き出され、および付録Cに指定されたクエリに追加されます。
":host=" quoted-hostname ";port=" number ";server-info=" quoted-serverinfo ";charset=" charset
"：ホスト=" ホスト名引用された ";ポート=" 番号 "; serverinfo ="-serverinfo引用された ";の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> "サーバー情報：" serverinfo <NL> "ホスト名：" ホスト名<NL> "ホスト・ポート：" 数<NL> "プロトコル：" PROT <NL> "ソース-URI：" ソース<NL> "文字セット：" 文字セット<NL>「＃1 END <NL>
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
そして、「引用符で囲まれたホスト名」および「引用され-serverinfoは、」DAG / IPの特殊文字を引用して、それぞれ「ホスト名」と「serverinfo」から取得されます。
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>サーバー情報を：O = thinkingcat、C = SE <NL>ホスト名：thinkingcat.com <NL>ホスト・ポート：2839 <NL>プロトコル：LDAPv2の<NL>ソース - URI：http://www.thinkingcat.com <NL>文字セット：T.61 <NL>＃1 END <NL>
would yield the addition
追加をもたらすであろう
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\ c\=se;charset=T\.61
：ホスト= thinkingcat \ .COM;ポート= 2839;サーバー情報= O \ = thinkingcat \、\ C \ = SE;のcharset = T \ 0.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).
（N.Bは：SERVER-TO-ASK応答で使用される用語のさらなる定義については、付録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.
クエリからこれらの用語を抽出し、連絡するWDSPサーバを識別するためにそれらを使用するDAG-SAPの責任であることに注意してください。以下、個々の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-のSAPからの結果は、元のクエリがDAG / IPでの発現のために一般化された場合には、ポスト処理されなければなりません。
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
}
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" と "のobjectClass = inetOrgPersonの"、 "オブジェクトクラス=上"、DAGスキーマからマッピング= <すべての属性を属性"オブジェクトクラス=人" または "オブジェクトクラス= organizationalRole"、適切な、およびAS "れたlabeledURI = <SOURCE-URI>" は、所与の照会からの各結果のために>
(Where DN,FN,ORG and ROLE are the values from the DAG schema).
（DN、FN、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が使用されます。そうでない場合（例えば、フーイズ++サーバから来るデータのため）、合理的なファクシミリ装置が構成されています。
As appropriate, the LDAPv2 DAG-CAP will express system responses following the LDAPv2 standard.
必要に応じて、DAGのLDAPv2-CAPは、LDAPv2の標準以下のシステム応答を表現します。
Appendix D gives the proposed mapping between DAG/IP response codes and LDAPv2 resultcodes.
付録Dは、DAG / IPの応答コードとのLDAPv2 resultcodes間の提案のマッピングを提供します。
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のresultCodeが含まれています。
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（間違ったスキーマ属性の）inappropriateMatching（サポートされているもの以外のマッチタイプを使用する場合、例えばapproxMatch）unwillingToPerform（クエリが定義されたタイプのものではない場合）
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 =スベンソン」として）、のLDAPv2 DAG-CAPは、送信されますエラーメッセージ。エラーメッセージは、次のresultCodesのうちの1つを含みます：
sizeLimitExceeded timeLimitExceeded
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への接続をリダイレクトすることがあります。これは、エラーメッセージにURLを渡すことで、代替DAG-CAPにクライアントソフトウェアを指示するために「umich紹介」規則を使用してエンドユーザクライアントソフトウェアに表現されています。
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はクライアントに1つのResultCodeを送信することができますので、 LDAPv2 DAG-CAPは、DAG-のSAPから、いくつかの異なる結果コードを受信した場合には、ある程度それらの組み合わせを表すことresultmessageを構築しなければなりません。なお、これらのケースでは、次のアクションがとられることが提案されています。
- 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のは以下の理由で収集した応答を表すために選択される：「成功」はこれらの手順の後に、コードを結果のリターンを表すだけResultCodeのであれば。離れて「成功」からの場合は他のResultCodeその1つの他のResultCode表さリターンがあります。
If apart from "success" there are two or more resultcodes
represented return the 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への入力は、（現在[17]で定義される）のLDAPv3の定義に従います。最低限、LDAPv3のDAG-CAPは、（標準のASN.1文法から適応）以下のクエリをサポートする必要があります。
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials }
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials 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 }
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}
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.
N.B.が、これは基本的なDAGに定義されたクエリを達成するために、サポートされるクエリの最小セットです。それはこれらのクエリのセマンティックに対応した方法でのLDAPv3クライアントにDAG / IPからの翻訳を行うことを約束する場合は、LDAP DAG-CAPは、これよりもより複雑なクエリをサポートすることもできます。
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-用語なしオブジェクトクラスの仕様が含まれている場合、検索は、人や役割のためであれば、それは不明です。これが発生すると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をトークン化（適切なDAGSchema属性を使用して）トークンごとにDAG / IPのクエリ用語を作り、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バー）（オブジェクトクラス=人））
This query can be represented in the DAG/IP as
このクエリは、DAGで表現することができます/ IPなど
FN="Foo" and FN="Bar":search=exact<NL>
FNは= "foo" とFN = "バー"：検索=正確な<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.
N.B.検索は、関連するLDAPスキーマの属性は大文字小文字を区別しないマッチングを持つように定義された「名前」属性要素の全ての誘導体であるので、（DAG / IPのデフォルト）「=ケースを無視」に設定されています。
If no objectclass where defined the query in DAG/IP would have been
DAGでクエリを定義していないオブジェクトクラスならば/ IPはあったであろう
(FN="Foo" and FN="bar") or ( ROLE="Foo" and ROLE="bar"):search=exact
（FN = "foo" とFN = "バー"）または（ROLE = "foo" とROLEは= "バー"）：検索=正確な
Although person is used as objectclass in this and the following examples, inetOrgPerson or organizationalPerson could also have been used.
人が、この中にオブジェクトクラスと次の例として使用されているが、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.
このクエリでは、偽陽性の紹介を得られます。 DAG / IPのクエリが紹介に「foo」と「bar」の2つのトークンが含まれるレコードを含む任意のWDSPが得られるのに対し、元のLDAPクエリは、「CN」属性が正確に句「フーバー」であるため、レコードに対して一致している必要がありますいずれかのためです。
For example, this DAG/IP query will yield referrals to WDSPs with records including:
たとえば、このDAG / IPのクエリは、以下を含むレコードを持つWDSPsに紹介を得られます：
cn: Bar Foo cn: Le Bar Foo cn: Foo Bar AB
CN：CNフーバー：ル・バーCNフー：フーバー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.
LDAPのサブストリングクエリはまた、DAG / IPのクエリを構築するためにトークン化されなければなりません。心に留めするための追加点は、LDAPサブストリング式は句、あいまいな潜在的なトークンの境界に向けられているということです。このため、サブコンポーネント間のすべてのポイントは、潜在的なトークンの境界として考慮されなければなりません。
Thus, the LDAP query
このように、LDAPクエリ
(& (cn=black) o=c*t) (objectclass=person))
（＆（CN =黒）O = C *とtの）（オブジェクトクラス=人））
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>
検索サブストリング= <NL>：FNは、黒とORG = CとORG = T =
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とORG = T：検索=ストリング
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バー）（O = Cの*トン）（オブジェクトクラス=人））
can be expressed as
以下のように表すことができます。
FN=Foo and FN=Bar and ORG=c and ORG=t:search=substring<NL>
FN = fooとFN =バーとORG = CとORG = T：検索=サブ<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は、2つの別々のクエリを行い、紹介インデックスによって返さ紹介の二組の交点（論理「AND」）を取ることができます。
Note that DAG/IP can accept phrases for searches -- the query
DAG / IPは、検索用のフレーズを受け入れることに注意してください - クエリを
FN=Foo\ bar<NL> (note the escaped space)
FN =はFoo \バー<NL>（エスケープスペースに注意）
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
SAP-DAGの照会
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-SAPに送信するDAG / IPのクエリを作成する際に、上記のクエリは有効なクエリはまだですが、代替きめ細かいクエリはつまり、も可能です。
FN=foo and FN=bar and ORG=c;search=lstring and ORG=t;search=tstring
FNはfooとFN =バー=とORG = C;検索= LSTRINGとORG = T;検索= 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サーバに関する情報を含まなければなりません。この情報は、紹介インデックス）の紹介情報をSERVER-TO-ASK、および付録Cに指定されたクエリに追加されるから引き出されます。
"host=" quoted-hostname ";port=" number ";server-info=" quoted-serverinfo ";charset=" charset
"ホスト=" 引用されたホスト名 ";ポート=" 番号 "; serverinfo =" 引用され-serverinfo ";の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>
紹介インデックスからの応答が含まれる。ここで、 "＃1 SERVER-TO-ASK" にserverHandle <NL> "サーバー情報：" serverinfo <NL> "ホスト名：" ホスト名<NL> "ホスト・ポート：" 番号<NL > "プロトコル：" PROT <NL> "ソース-URI：" ソース<NL> "文字セット：" 文字セット<NL> "＃1 END" <NL>
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
そして、「引用符で囲まれたホスト名」および「引用され-serverinfoは、」DAG / IPの特殊文字を引用して、それぞれ「ホスト名」と「serverinfo」から取得されます。
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>サーバー情報を：O = thinkingcat、C = SE <NL>ホスト名：thinkingcat.com <NL>ホスト・ポート：2839 <NL>プロトコル：LDAPv2の<NL>ソース - URIます。http：//www-thinkingcat.se/
Charset: T.61<NL> # END<NL>
文字セット：T.61 <NL>＃1 END <NL>
would yield the addition
追加をもたらすであろう
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\ c\=se;charset=T\.61
：ホスト= thinkingcat \ .COM;ポート= 2839;サーバー情報= O \ = thinkingcat \、\ C \ = SE;のcharset = T \ 0.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).
（N.Bは：SERVER-TO-ASK応答で使用される用語のさらなる定義については、付録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.
クエリからこれらの用語を抽出し、連絡するWDSPサーバを識別するためにそれらを使用するDAG-SAPの責任であることに注意してください。以下、個々の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は、LDAPv3のサーバ（すなわち、Whoisの++の紹介、現在）のものを除くすべての参照を解決するために、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. Acceptable results are expressed in LDAPv3 messages containing search result entries (see the standard for more detail):
上述したように、DAG-のSAPからの結果は、元のクエリがDAG / IPでの発現のために一般化された場合には、ポスト処理されなければなりません。許容可能な結果は、（詳細のための標準を参照）、検索結果のエントリを含むのLDAPv3メッセージに表されます。
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
-- at least one LDAPURL element must be present
SearchResultDone ::= [APPLICATION 5] LDAPResult
where
どこ
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
LDAPDN = DN / "CN ="（FN / ROLE） "O =" ORG] "DC = SE" は、DAGスキーマからマッピング= <すべての属性の属性および "オブジェクトクラス= inetOrgPersonの"、 "オブジェクトクラス=人物" 、所与の照会からの各結果は、 "オブジェクトクラス=上" または "オブジェクトクラス= organizationalRole"、必要に応じて、および "れたlabeledURI = <SOURCE-URI>"> LDAPResult =成功
(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が使用されます。そうでない場合（例えば、フーイズ++サーバから来るデータのため）、合理的なファクシミリ装置が構成されています。
Referral URLs are constructed from the DAG/IP's SERVER-TO-ASK information as follows:
次のように紹介URLがDAG / IPのSERVER-TO-ASKの情報から構成されています。
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のサーバーを使用してWDSPsが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のresultCodeを含みます
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（間違ったスキーマ属性のために選択される）inappropriateMatching（サポートされているもの以外のマッチタイプは、例えば使用される場合、approxMatch）unwillingToPerform（クエリが定義されたタイプのものではありません）
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: adminLimitExceeded
紹介インデックスによって送信された照会の数が所定の最大値よりも大きい場合（データマイニング活動を検出する、またはそうでなければ過剰一般クエリーを拒否するためのこのような「FN =スベンソン」として）、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
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はクライアントに1つのResultCodeを送信することができますので、 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のは以下の理由で収集した応答を表すために選択される：「成功」はこれらの手順の後に、コードを結果のリターンを表すだけResultCodeのであれば。離れて「成功」からの場合は他のResultCodeその1つの他のResultCode表さリターンがあります。離れて「成功」から場合表される2つ以上のresultcodesは、「その他」のResultCodeを返すがあります。
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-CAP定義セクションで定義された参照情報は、DAG-SAPクエリの最後に追加されます。
":host=" quoted-hostname ";port=" number ";server-info=" quoted-serverinfo ";charset=" charset
"：ホスト=" ホスト名引用された ";ポート=" 番号 "; serverinfo ="-serverinfo引用された ";の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 ++サーバに発現以下のテンプレートID変換と、フーイズ++ DAG-SAPを受信DAG / IPクエリの残りの部分です。
template=DAGPERSON becomes template=USER
テンプレート= DAGPERSONは、テンプレート= USERなり
and
そして
template=DAGROLE becomes template=ORGROLE
テンプレート= DAGROLEは、テンプレート= 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
DAG / IPで使用する検索タイプは、すべてのWhois ++構文によって必要とされていないことに注意してください。そのため、いくつかのWhois ++ WDSPsは、「正確な」と「LSTRING」（Whoisの++プロトコル標準によって必要な検索タイプ）以外の検索をサポートしていないサーバーを使用しても良いです。 Whois ++ DAG-CAP月
- 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.
- 、WDSPのサーバーから構成（例えば、「=サブ検索」で）としてDAG / IPクエリを送信し、「あまりにも複雑％502検索式」バックパス - 翻訳し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.
、本質的にリモートサーバから受信したすべてのフルレスポンス情報を通過付録Aで定義されたマッピングを使用してDAGSchemaにマッピング - 結果が正常にリモートサーバから受信される場合、それらは、DAG / IPを使用して発現され
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-CAP定義セクションで定義されて参照情報は、DAG-SAPクエリの最後に追加され（DAG / IPクエリに追加条件として）。
":host=" quoted-hostname ";port=" number ";server-info=" quoted-serverinfo ";charset=" charset
"：ホスト=" ホスト名引用された ";ポート=" 番号 "; serverinfo ="-serverinfo引用された ";の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のクエリ（HOSTなし、SERVER-INFOとPORT用語）から構成されます。
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 }
}、SIZELIMIT INTEGER（0 .. MAXINT）、TIMELIMIT INTEGER（0 .. MAXINT）、attrsOnly FALSEフィルタフィルタは、AttributeTypeで一連の属性 - すべてDAGschema}が定義された標準LDAPスキーマに当属性
Filter ::=
CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
substrings [4] SubstringFilter,
}
SubstringFilter SEQUENCE { type AttributeType,
SubstringFilterシーケンス{タイプAttributeTypeで、
SEQUENCE OF CHOICE { substrings initial [0] LDAPString, substrings any [1] LDAPString, substrings final [2] LDAPString} }
} {[2] LDAPStringストリング最終サブストリング[0] LDAPString当初、任意[1] LDAPStringをサブストリング、} CHOICE OF SEQUENCE
where and, or and not filters are constructed to preserve the logic of the DAG/IP query.
どこで、または、フィルターは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.
合理的なLDAPクエリにトークンベースのDAG / IPのクエリに一致する目的のために、すべての検索は、文字列検索としてLDAP WDSPに渡す必要があります。 WDSP結果は、その後、必要なトークンの境界を、尊重することを剪定する必要があります。
So, for example, the DAG/IP query
したがって、たとえば、DAG / IPのクエリ
FN=Foo\ Bar and ORG=Thinking\ Cat:search=substring<NL>
FN =はFoo \バーとORG =思考\猫：検索=サブ<NL>
would be sent to the designated LDAP WDSP as
指定されたLDAP WDSPに送信されます
(& (fn=*Foo Bar*) (o=*Thinking Cat*) (objectclass=person))
（＆（FN = *はFooバー*）（O = *）*猫を考える（オブジェクトクラス=人））
Interestingly, the query
興味深いことに、クエリ
FN=Foo\ Bar and ORG=Thinking\ Cat:search=exact<NL>
FN =はFoo \バーとORG =思考\猫：検索=正確な<NL>
would also be sent to the designated LDAP WDSP as (& (fn=*Foo Bar*) (o=*Thinking Cat*) (objectclass=person))
指定されたLDAP WDSPに送信される（＆（FN = *はFooバー*）（O = *思考猫*）（オブジェクトクラス=人））
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".
しかしWDSPs結果は「Fooのバー」と「猫を考える」のいずれかの側に非トークン化文字を持っていたすべての結果を削除するために剪定しなければならないであろう戻りました。
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.
LDAPクエリへのマッピングDAG / IPのクエリのための最終的な考慮事項は、文字の例問題です。 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間の違いに対応するために行われなければなりません。検索がキー入力された属性（「CN」、「L」、およびLDAPスキーマ内の「O」）は、すべて大文字と小文字を区別しない等価のマッチングのためのものとして定義されます。 DAG / IPのクエリが制約「ケース=考える」が含まれている場合このように、リモート・サーバからの結果は後処理でなければならない任意の間違ったケース入りのものを削除します。
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は次のとおりです。<ホスト名なしの-期間> <ポート>（サーバーのDNさんがenforceably一意ではありませんので）。例えば、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-CAP定義セクションで定義された参照情報は、DAG-SAPクエリの最後に追加されます。
":host=" quoted-hostname ";port=" number ";server-info=" quoted-serverinfo ";charset=" charset
"：ホスト=" ホスト名引用された ";ポート=" 番号 "; serverinfo ="-serverinfo引用された ";の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のクエリ（HOSTなし、SERVER-INFOとPORT用語）から構成されます。
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,
not [2] Filter, substrings [4] SubstringFilter, }
ない[2]フィルタ、サブストリング[4] SubstringFilter、}
SubstringFilter SEQUENCE { type AttributeType, SEQUENCE OF CHOICE { substrings initial [0] LDAPString, substrings any [1] LDAPString, substrings final [2] LDAPString} }
SubstringFilterシーケンス{型AttributeTypeで、CHOICE OF SEQUENCE {サブストリング[0] LDAPString初期には、任意の[1] LDAPStringをサブストリング、ストリング最終[2] LDAPString}}
where and, or and not filters are constructed to preserve the logic of the DAG/IP query.
どこで、または、フィルターは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.
合理的なLDAPクエリにトークンベースのDAG / IPのクエリに一致する目的のために、すべての検索は、文字列検索としてLDAP WDSPに渡す必要があります。 WDSP結果は、その後、必要なトークンの境界を、尊重することを剪定する必要があります。
So, for example, the DAG/IP query
したがって、たとえば、DAG / IPのクエリ
FN=Foo\ Bar and ORG=Thinking\ Cat:search=substring<NL>
FN =はFoo \バーとORG =思考\猫：検索=サブ<NL>
would be sent to the designated LDAP WDSP as
指定されたLDAP WDSPに送信されます
(&(fn=*Foo Bar*)(o=*Thinking Cat*)(objectClass=person))
（＆（FN = *はFooバー*）（O = *思考猫*）（objectClassの=人））
Interestingly, the query
興味深いことに、クエリ
FN=Foo\ Bar and ORG=Thinking\ Cat:search=exact<NL>
FN =はFoo \バーとORG =思考\猫：検索=正確な<NL>
would also be sent to the designated LDAP WDSP as
指定されたLDAP WDSPに送信されます
(&(fn=*Foo Bar*)(o=*Thinking Cat*)(objectClass=person))
（＆（FN = *はFooバー*）（O = *思考猫*）（objectClassの=人））
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のバー」と「猫を考える」のいずれかの側に非トークン化文字を持っていたすべての結果を削除するために剪定しなければならないであろう。
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.
LDAPクエリへのマッピングDAG / IPのクエリのための最終的な考慮事項は、文字の例問題です。 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.
結果が正常リモートサーバから受信している場合は、各結果メッセージのために提供された属性と値が付録Aに概説するようにDAG / IPとスキーママッピングを使用して表現する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間の違いに対応するために行われなければなりません。検索がキー入力された属性（「CN」、「L」、およびLDAPスキーマ内の「O」）は、すべて大文字と小文字を区別しない等価のマッチングのためのものとして定義されます。 DAG / IPのクエリが制約「ケース=考える」が含まれている場合このように、リモート・サーバからの結果は後処理でなければならない任意の間違ったケース入りのものを削除します。
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は次のとおりです。<ホスト名なしの-期間> <ポート>（サーバーのDNさんがenforceably一意ではありませんので）。例えば、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.
N.B .:これらの実施例で提示したデータは、等ワード順序、大文字と小文字の区別、上マッチングの例示としての役割を果たすことがしばしば設けられ、無意味です
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>
名前=思考と名前=猫：検索=正確な;場合=考える<NL>
The expected answer can be described as:
期待の答えは次のように説明することができます。
Any USER templates that contain the tokens "thinking" and "cat" in a name attribute.
name属性のトークン「思考」と「猫」が含まれている任意のユーザテンプレート。
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 =思考およびfn =猫：検索=正確な<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 ++の紹介が直接バックのWhois ++クライアントに渡されるなどのWhois ++ DAG-SAPと対話することはありませんので注意してください。
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: fn=thinking and fn=cat:search=exact;case=consider<NL>
FN =思考およびfn =猫：それは紹介インデックスへ送られたとして、それは大文字と小文字の区別制約含めることができることを除いてのWhois ++ DAG-CAPは、DAG-SAPに同じ実質的なクエリを送信する必要があり、検索=正確に;場合は=考えます< NL>
which will be translated by the DAG-SAP into an LDAP query of the form:
フォームのLDAPクエリにDAG-SAPによって翻訳されます。
(&(cn=*thinking*)(cn=*cat*)(objectclass=inetOrgPerson))
（＆（CN = *思考*）（CN = *猫*）（オブジェクトクラス= 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
私は思考の犬と歌う猫を持っていた希望：することができます
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 = * Cは* tの目）（）緑色食料= O（オブジェクトクラス=人））
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を持っている「緑の食料品」、組織内のすべてのレコードは、「目」で始まる「T」で終わる、とどこか途中で「c」を持つ属性です。
cn values that would match this include:
これをマッチするのcn値は次のとおりです。
cn: thinkingcat cn: Thinking Cat cn: The Black Cat cn: Thick Mat
CN：thinkingcat 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及びFN = CおよびFN = T AND ORG =緑およびORG =食料品：検索ストリング= <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):
これは、次の属性値（一致文字は、識別を容易にするために大文字である）を持つレコードを含むWDSPsにクエリを向ける、いくつかの偽陽性の紹介を生成します。
cn: wiTH three blaCk poTs
CN：3つの黒ポットで
o: peaGREEN and cyan GROCERIES o: GROCERIES are GREENer than electronics
O：peaGREENとシアン食料品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>
ケース=無視<NL>：;検索ストリング= AND FN = T;探索= stringおよびORG =緑およびORG =食料品FN = C =検索文字列と、FNは=
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-SAPは、すべてのDAG-のCAPで同じに扱われていることをメモリに保持することも注目すべきであるため、LDAP DAG-CAPは、その後LDAP 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:
それは紹介インデックスに送信されたか、それはすなわち、DAG-SAPを、で使用することが許される増補版を送ることができるように、この場合にはLDAPのDAP-CAPは、LDAP DAG-SAPに同じクエリを送ることができ、次のいずれか
FN=th;search=lstring AND FN=C;search=substring AND FN=T;search=tstring AND ORG=green\ groceries:case=ignore<NL>
ケース=無視<NL>：;検索ストリング= AND FN = T;探索= stringおよびORG =緑色\食料品FN = C =検索文字列と、FNは=
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 = *グリーン食料品*）（objectClassの=人））
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.
「CN = *第*」に、「検索= LSTRING FN =目」からの翻訳に注意してください。これは、DAG / IPのLSTRING制約がトークンに基づいているのに対し、必要であるが、「CN =目*」属性の値（フレーズではなく、トークン）の先頭を指します。 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-CAPには、サービスを提供したり、24時間365日ごとにクエリをリダイレクトするために使用可能でなければなりません。
- 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から提供されたデータは、内で更新する必要がありますDAGは、少なくとも7日ごとに1回
WDSPs who wish to participate in the DAG system do so by providing DAG-compatible access to their service, where DAG-compatible means:
DAGシステムに参加を希望するWDSPsは、彼らのサービス、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の++の1 - のWhois ++のためのユーザーとロールのテンプレートを使用 - 情報彼らのサービスのインデックスを記述する（最小限）DAGのコアに生じる紹介インデックスオブジェクトの毎週のアップデートに対応するため、24時間365日のサービスサーバ - 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:
参加するには、WDSPsは、それが覆っている各データセットの詳細を提供し、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.
任意のWDSPは、DAGシステムを介してデータを利用できるようにしたいが、これらの要件を満たしていない、サードパーティとの契約を通じて情報を提供することができるこれらの要件をサポートすることができないことに注意してください。したがって、データは、協働WDSPs間で複製することができます。 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-のSAPと紹介索引 - DAGシステムは、いくつかの部品で構成された、概念全体として提示されます。これらの構成部品の各々は、複製可能でなければならず、サービスは、レプリカ間で共有されなければなりません。
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.
大規模サービスプロバイダ（大企業、ISPの）可能紹介インデックスをミラーリングまたは代替DAG-CAPの人員/顧客向け/ DAG-SAPを提供する能力を考慮することは興味深いかもしれません。この報告書の範囲を超えて行うための方針と可能性。しかし、ソフトウェア・アーキテクチャは、このような活動をサポートするように設計されています。
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 |
| |
+------------------------+
Figure 6.1 Distributable nature of DAG components
DAGコンポーネントの6.1再頒布可能な性質を図
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は、最小のアドレスに入ってくるクエリーをリダイレクトする反射に過ぎないかもしれません現時点では、サーバーを-loaded。 - これは、フーイズとして同期接続プロトコル、目標が要求しているクライアントは、よくアドバタイズアドレスポートに接続されている時間の量を最小化することである++およびLDAPにおいて特に必要です。 - DAG-CAPソフトウェアは、同じプロトコルタイプの異なるDAG-のSAPへの参照を指示することができなければなりません。 - DAG-CAPソフトウェアは過度に一般的なクエリーを検出することができなければならない（すなわち、紹介インデックスによって生成された照会の数が多すぎると判断して、いくつかのメトリックを持っています）。 - DAG-SAPは、その裁量で、DAG-CAPクエリーをリダイレクトする、または単にので（したがって、DAG-キャップはまた、他の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-CAPに、特定のプロトコルのための新しい実装（例えば、より精巧なメールベースのクエリシステムの構築）のソフトウェアを複製、または全く異なるプロトコル（例えば、PH）のための実装はの基本原則に付着することで追加することができますを超えてDAG-CAPとDAG-SAPは、ソフトウェアの仕様で定義されています。新しい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のとフーイズ++両方のハンドルの参照が、現在のシステムは、またその逆、フーイズ++ 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.
「仮想」DAG-キャップはWDSPがサポートされていないプロトコルごとに各参加WDSPために確立することができ、それらのDAG-のCAPへの紹介は、呼び出し元のクライアントに与えることができます。例えば、++のWhoisクライアントはLDAPをサポートしていWDSPための仮想のWhois ++ DAG-CAPへのWhois ++の紹介を与えられるであろう。 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.
セキュリティは、「読み取り専用」ディレクトリ・サービスのコンテキストで、それは問い合わせを行うエンドユーザーに元のサーバーから通過する際に、データの整合性を維持するとともに、主に懸念しています。これは、一部のサーバー（s）は正しいユーザー情報を保持し、ディレクトリサービスにアクセスするクライアントがどの情報がクライアントに到達する前に通過しなければならないのサーバー、それは元の情報の真の表現を受け取ることを特定する必要があり、です。
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.
など、DAGシステムは、クエリのディレクトリアクセスクライアントへWDSPsからの情報の仲介者として完全に見えなければなりません。表示されることができる唯一の可能な変更は、別のものに1つのキャラクタからの翻訳です。うまくいけば、これは、情報の意味を変更しません。
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システムが認識し、他のコンポーネントからの接続を受け入れるようにコンポーネントの設定を超えて任意のアクセス制御システムを提供していません。より詳細なアクセス制御の場合は、アクセス制御を適用するために接続されWDSPs次第です。
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インデックスオブジェクト）のセキュリティは、暗号化して登録WDSPsからオブジェクトの署名によって提供されます。
This work came from ideas originally put forward by Patrik Faltstrom. The TISDAG project was supported by the Swedish KK Foundation.
この作品は、もともとパトリックFaltstromによって前方に置くのアイデアから来ました。 TISDAGプロジェクトは、スウェーデンKK財団によってサポートされていました。
Thanks to especially to Jens Lundstrom, Thommy Eklof, Bjorn Larsson and Sandro Mazzucato for their comments on draft versions of this document.
特にイェンスLundstrom、Thommy Eklof、ビョルン・ラーションとサンドロ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).
特定の人については、DAGPERSONスキーマ、およびまたは任意の時点で人によって占められる仕事の位置であってもなくてもよい組織の役割についてDAGORGROLEスキーマ（例えば、組織の社長、顧客サービス - DAGは、2つの情報スキーマを使用しています机など）。
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」を参照）のタイプを記述する情報を運ぶために、1つの属性を使用することが可能であることを意味し、重要であることに注意。
Finally, attributes may be repeated. For example, this schema structure can carry multiple phone numbers of different types for one person.
最後に、属性を繰り返してもよいです。たとえば、このスキーマ構造は一人のために、異なる種類の複数の電話番号を運ぶことができます。
A.1 DAG Personal Information Schema (DAGPERSON Schema)
A.1 DAY個人情報スケジュール（スケジュールDAGPERSON）
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 DAGPERSONスキーマ属性
A.2 DAG Organizational Role Information Schema (DAGORGROLE Schema)
A.2 DAY組織の役割の情報スキーム（スキームDAGORGROLE）
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)
彼らのサービスへの現在の役割乗員SOURCE省略可能WDSPの優先アクセスのFNオプションフルネーム - （LDAP用）URL DNオプションのエントリの「識別名」
Table A.2 DAGORGROLE schema attributes
表A.2 DAGORGROLEスキーマ属性
Appendix B - Schema Mappings for Whois++ and LDAP
付録B - Whoisのためのスキーマ・マッピング++および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は、2つの特定のスキーマを使用しています。しかし、アクセスプロトコルの特定のスキーマが適切に入ってくるユーザーのクエリに対処するために処理される必要があり、WDSPsにクエリをチェーン。認識の標準スキーマは以下のとおりです。
- 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のためORGROLEテンプレート++（[8]） - 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の++）に関する情報と連動して、結果に戻りたいという情報に基づいて開発されました。しかしながら、特にアドレス情報の場合には、それらのプロトコルのために使用されるスキーマは、情報表現のかなりの範囲を可能にします。実際には、これは異なるWDSPsは、スキーマの異なるサブパーツを使用することを選択し、あるいはローカルなカスタマイズを実施してもよいことを意味します。
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 / IPスキーマにDAG-SAPのマッピングのために予想される動作の概要を説明し、DAG-CAPには、連鎖操作が結果を返した後にクライアントソフトウェアに沿って渡すための情報を抽出します。
B.1 LDAP and the DAG Schemas
B.1 LDAPおよびDAGスキーマ
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-SAPはDAG / IPを使用してDAG-CAPに（WDSPs'サーバから取得した）情報を返すされたときに情報がDAGスキーマに運ばれるだけです。で定義された標準LDAPオブジェクトクラスとの間の「標準的な」マッピング（のinetOrgPerson、[16]及びorganizationalRole、[18]で定義されており、DAGPERSONスキーマとDAGORGROLEスキーマは、定義されているLDAPにLDAP DAG-SAPから渡された情報DAG- CAP（例えば、のLDAPv2 DAG-CAPに対する連鎖のLDAPv3 DAG-SAP復帰情報の場合には）それを抽出したと同じ属性にマッピングされます。
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
ADR-TYPE=org ADR-STREET street ADR-ROOM roomNumber ADR-STATE st ADR-COUNTRY c
ADR-TYPE = ORG ADR-STREET通りADR-ROOM roomNumber ADR-STATE ST ADR-C国
ADR-TYPE=org-postal ADR postalAddress ADR-ROOM postOfficeBox ADR-CODE postalCode
ADR-TYPE = ORG-郵便ADR postalAddressのADR-ROOM postOfficeBox ADR-CODE postalCodeの
ADR-TYPE=home-postal ADR homePostalAddress
ADR-TYPE =ホーム郵便ADR homePostalAddress
TEL-TYPE=work TEL telephoneNumber
TEL-TYPE =仕事TEL電話番号
TEL-TYPE=home TEL homePhone
TELのTEL-TYPE =ホームhomePhoneを
TEL-TYPE=fax TEL facsimileTelephoneNumber
TEL-TYPE =ファックスTELのfacsimileTelephoneNumber
TEL-TYPE=mobile TEL mobile
TEL-TYPE =携帯TELモバイル
TEL-TYPE=pager TEL pager
TEL-TYPE =ポケベルTELページャ
DN dn SOURCE labeledURI
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
TEL-TYPE=unqualified TEL telephoneNumber
TEL-TYPE =修飾されていないTELのtelephoneNumberの
Table B.2 Reasonable Approximations for LDAP organizationalRole attributes
LDAP organizationalRole属性のテーブルB.2合理的な近似
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 =バーバラ・ジェンセン、OU =製品開発、O =エース産業、C = USオブジェクトクラス：トップオブジェクトクラス：人物オブジェクトクラス：organizationalPersonをオブジェクトクラス：inetOrgPersonのCN：バーバラ・ジェンセンCN：バーバラJジェンセンCN：バブスジェンセンSN：ジェンセンのUID： bjensenののTelephoneNumber：+1 408 5551212説明：大航海ファン
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 =バーバラ・ジェンセン、OU =製品開発、O =エース産業、C = US UN UNバーバラ・ジェンセン：バーバラJジェンセンUN：バブスジェンセンSN：ジェンセンのTELのTYPE：作業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.
LDAP organizationalRoleオブジェクトクラスとDAGORGROLEスキーマのための標準的なマッピングは、DAG-SAPは任意の属性に沿って送信することを選択するかもしれない、とDAG-CAPには認識されている任意の解釈可能性があることを表B.3 .Beyondに与えられています。 N.B.、organizationalRoleクラスは、電子メールアドレスを含めるための規定が含まれていません。このマッピングは、むしろ軽率InetOrgPersonのために定義されているメール属性の利用可能性を想定しています。
DAGORGROLE Attribute LDAP organizationalRole attribute
-------------------- ---------------------------------
ROLE cn
EMAIL mail
ORG o
LOC l
TEL-TYPE=org TEL telephoneNumber
TEL-TYPE = ORG TELのtelephoneNumberの
TEL-TYPE=fax TEL facsimileNumber
TEL-TYPE =ファックスTELファクシミリ番号
FN roleOccupant DN dn SOURCE labeledURI
FN roleOccupant DN DN SOURCEれたlabeledURI
Table B.3 Canonical mappings for LDAP organizationalRole attributes
LDAP organizationalRole属性のテーブルB.3 Canonicalのマッピング
B.2 Whois++ and the DAG Schemas
B.2のWhois ++およびDAGスキーマ
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.
[8]で定義されており、DAGPERSONスキーマとDAGORGROLEスキーマを表B.4及びB.5に定義されているような標準のWhois ++テンプレートとの間の「標準的な」マッピング。それを越えて、DAG-SAPはDAG / IP内の任意の追加の属性に沿って通過することができる、およびDAGキャップは、順方向または認識され、そのいずれかを解釈することを選択することができます。
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 = ORG ADR機関-アドレスADR-STREET組織アドレス・ストリートADR-ROOM組織アドレス-部屋ADR-CITY組織アドレス市ADR-STATE組織アドレス状態ADR国の組織アドレス、国ADR -CODE組織アドレス・郵便番号
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-STREETアドレス・ストリートADR-ROOMアドレス-部屋ADR-CITYアドレス市ADR-STATEアドレス状態ADR国のアドレス-国ADR-CODEアドレス・郵便番号
TEL-TYPE=work phone-type=work TEL phone
TEL-TYPE =職場の電話型=作業TEL電話
TEL-TYPE=home phone-type=home TEL phone
TEL-TYPE =自宅電話型=自宅TEL電話
TEL-TYPE=fax TEL fax
TEL-TYPE =ファックスTELファックス
TEL-TYPE=mobile TEL cellular
TEL-TYPE =セルラー移動TEL
TEL-TYPE=pager TEL pager
TEL-TYPE =ポケベルTELページャ
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
TEL-TYPE=org TEL phone
TEL-TYPE = ORG TEL電話
TEL-TYPE=fax TEL fax
TEL-TYPE =ファックスTELファックス
Table B.5 Canonical mappings for Whois++ ORGROLE attributes
Whoisの++ ORGROLE属性表のB.5 Canonicalのマッピング
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）は、現在、RFC1835にレイアウトとしてのWhoisのクエリ相互作用プロトコルの誘導体++として定義される（[6]）。
C.1 A word on the choice of DAG/IP
C.1 DAG / IPの選択に単語
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作家に必要に応じて、より多くを生産するために、例えば（より洗練されたクエリを表現する能力を与えるだろう - クライアントは、最小限のクエリを実行するために、プロトコルのすべての機能を実装する必要はありませんスペルの複雑な「インテリジェント」マッチング、一般的な文字の置換、など）。 - テキストベース、区切られた属性の結果式がWDSPsによって提供される追加データのオプションを含めることを容易に - DAG-キャップは簡単に任意の未知の情報を無視し、結果情報の残りの部分を解釈し続けることができます。
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.
（紹介インデックスのための、およびDAG-のSAP用）のテストサーバのWhoisの++プロトコル準拠のためのツールの自由に利用できるテストスイートがあります。詳細についてはdigger-info@bunyip.comにメールを送信します。
C.2 DAG/IP Input and Output -- Overview
C.2 DAG / IPの入力と出力 - 概要
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は、DAG / IPの構文を説明するのWhois ++プロトコルのより最近の説明に使用される文法を適応させます。
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の出力は、より多くの情報が含まれている（「SERVER-TO-ASK」）が紹介応答を除いて、セクション2.4、RFC1835で定義されているもののサブセットとなります。
C.3 BNF for DAG/IP input and output
DAG / IP入力および出力のためのC.3 BNF
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の++のRFC 1835を参照してください[6]。
C.3.1 The DAG/IP Input Grammar
DAG / IP入力文法C.3.1
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定義で概説したようにN.Bは：、ルール名と、文字列リテラルは、US-ASCII文字セットであり、大文字と小文字を区別しません。また、文字は例えばとして、文法で明示的に書かれている時に「;」、それは、このプロトコルで使用される彼らのエンコーディングで許可される文字セットのすべてでその文字のバイト値を表します。具体的にUNICODEで、 ";"次いで、DAG / IPプロトコルで使用されるバイト値0x3Bを生成するUTF-8の文字をエンコードする文字U + 003Bは、手段。
dagip-command = ( system-command [":" "hold"] / ri-query / sap-query ) nl
dagipコマンド=（システムコマンド[ "：" "" ホールド] / RI-クエリ/ SAPクエリ）NL
ri-query = ri-terms [":" globalcnstrnts]
RI-クエリ= RI-用語[ "：" globalcnstrnts]
sap-query = sap-terms [":" [sapcnstrnts][ ":" wdspinfo]]
SAPクエリ= SAP-用語[ "：" [sapcnstrnts] [ "：" wdspinfo]]
system-command = "constraints" / "describe" / "commands" / "polled-by" / "polled-for" / "version" / "list" / "show" [1*sp datastring] / "help" [1*sp datastring] / "<NL>" [string]
システム・コマンド= "制約" / "説明" / "コマンド" / "ポーリング-で" / / "バージョン" / "リスト" / "ショー" "のために、ポーリング" [1 * SPのdatastring] / "ヘルプ" [ 1 * SP datastring] / "<NL>" [文字列]
ri-terms = ri-and-expr *(1*sp "or" 1*sp ri-and-expr)
RI-用語= RI-と-exprを×（1つの* SPの "または" 1 * SPのRI-と-expr）は
ri-and-expr = ri-basic-expr *(1*sp "and" 1*sp ri-basic-expr)
RI-と-exprの里=-基本-exprの*（1つの*属 "と" 1 * SPの里 - 基本-expr）は
ri-basic-expr = ["not" 1*sp] ri-term / ( "(" ri-terms ")" )
RI-基本式expr = [ "しない" 1 * SP] RI-用語/（ "（" RI-用語 "）"）
ri-term = generalterm / specificterm / combinedterm
RI-TERM =総称/特定の用語/合成用語
sap-terms = sap-and-expr *(1*sp "or" 1*sp sap-and-expr)
SAP-用語= SAP-と-exprを×（1つの* SPの "または" 1 * SPのSAP-と-expr）は
sap-and-expr = sap-basic-expr *(1*sp "and" 1*sp sap-basic-expr)
SAP-と-exprの= SAP-基本-たexpr *（1つの*属 "と" 1 * SPのSAP-基本-expr）は
sap-basic-expr = ["not" 1*sp] sap-term / ( "(" sap-terms ")" ) sap-term = ( generalterm / specificterm / combinedterm) localcnstrnts
SAP-基本exprが= [ "しない" 1 * SP] SAP-用語/（ "（" SAP-用語 "）"）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の使用は、予期しない動作を引き起こす可能性があるため、推奨されません。それはプロトコルであってもキャップがそのためにそれを使用しないでください。
specificterm = specificname "=" datastring
specificterm = SPECIFICNAME "=" datastring
specificname = "handle" / "value"
SPECIFICNAME = "ハンドル" / "値"
combinedterm = attributename "=" datastring
combinedterm = attributeNameの "=" datastring
sapcnstrnts = sapcnstrnt *(";" sapcnstrnt)
sapcnstrnts = sapcnstrnt *（ ";" sapcnstrnt）
sapcnstrnt = localcnstrnt / globalcnstrnt
sapcnstrnt = localcnstrnt / globalcnstrnt
localcnstrnts = [";search=" sap-searchvalue] [";case=" sap-casevalue]
localcnstrnts = [ ";検索=" SAP-searchvalue] [ ";ケース=" SAP-casevalue]
localcnstrnt = "search=" sap-searchvalue / "case=" sap-casevalue
localcnstrnt = "検索=" SAP-searchvalue / "ケース=" SAP-casevalue
;N.B.: in the case where local and global constraints ; conflict, local constraints take precedence ; and overrides the global constraint
、ローカルおよびグローバルな制約場合N.B .:。紛争、地元の制約が優先されます。そしてグローバルな制約を上書きします
sap-searchvalue = "tstring" / searchvalue
SAP-searchvalue = "tstring" / searchvalue
sap-casevalue = "consider" / "ignore"
SAP-casevalue = "無視" / "考えます"
globalcnstrnts = globalcnstrnt *(";" globalcnstrnt)
globalcnstrnts = globalcnstrnt *（ ";" globalcnstrnt）
globalcnstrnt = "search" "=" searchvalue / opt-globalcnst
globalcnstrnt = "検索" "=" searchvalueは/ opt-globalcnst
opt-globalcnst = "hold" / "case" "=" casevalue / "maxfull" "=" 1*digit / "maxhits" "=" 1*digit / "language" "=" language / "incharset" "=" characterset / "ignore" "=" attributename / "include" "=" attributename
オプトglobalcnst = "ホールド" / "の場合" "=" casevalue / "maxfull" "=" 1つの*数字/ "maxhits" "=" 1つの*数字/ "言語" "=" 言語/ "incharset" "="キャラクタ/ "= "attributeNameが/" が含まれる" "無視" "=" 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：属性が「含める」と「無視」との両方を命名されている場合は、制約、属性が結果に含まれているが、。システムメッセージは、「満たされていない％112要求された制約」でなければなりません。
language = <The language code defined in RFC1766>
言語= <RFC1766で定義された言語コード>
characterset = "UNICODE-2-0-UTF-8"
キャラクタ= "UNICODE-2-0-UTF-8"
searchvalue = "exact" / "substring" / "lstring"
searchvalue = "正確な" / "サブ" / "LSTRING"
casevalue = "ignore" / "consider"
casevalueは= "無視" / "考えます"
wdspinfo = attrValAss *( ";" attrValAss )
wdspinfo = attrValAss *（ ";" attrValAss）
attrValAss = attributename "=" datastring
attrValAss = attributeNameの "=" datastring
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のためにのみ許可された属性と判断されました。この属性の値は、「ISO8859-1」、「UTF-8」の一つとして、「T \ 0.61」または「US-ASCII」を定義している「文字セット」について。
datastring = 1*data-elt
データ列= 1 *データ混練
attributename = 1*(<%d32-126 except specialbyte>) ; omit 127, which is DEL
たattributeName = 1 *（<％d32-126 specialbyte除きます>）。 127を省略し、DELであります
data-elt = "\" specialbyte / normalbyte
データ-ELT =「\」特別なバイト/バイトノーマル
normalbyte = <%d32-255, except specialbyte>
normalbyte = <％d32-255、specialbyte除きます>
specialbyte = " " / tab / "=" / "," / ":" / ";" / "\" / "*" / "." / "(" / ")" / "[" / "]" / "^" / "$" / "!" / "<NL>"
specialbyte = "" /タブ/ "=" / "" / "：" / ";" / "\" / "*" / "" / "（" / "）" / "[" / "]" / "^" / "$" / "！" / "<NL>"
number = 1*digit
数= 1 *桁
digit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
桁= "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
tab = %d09 sp = %d32 ; space nl = %d13 %d10 ; CR LF
タブ=％D09 SP =％D32;スペース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: : ; , ( ) = !
注：クエリに重要であるスペース（SP）はエスケープする必要があります。以下の文字、クエリに、単一のスペースが先行及び/又は追跡することができる場合に重要：。 、（）=！
C.3.2 The DAG/IP Response Grammar
DAG / IPレスポンス文法C.3.2
The following grammar, which uses the Augmented BNF (ABNF) notation as defined in RFC2234 (see [5]),
RFC2234で定義された拡張BNF（ABNF）表記法を使用し、以下の文法、（[5]を参照）、
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定義で概説したようにN.Bは：、ルール名と、文字列リテラルは、US-ASCII文字セットであり、大文字と小文字を区別しません。また、文字は例えばように、文法に明示的に書かれている場合に「;」は、このプロトコルで使用されるそれらのエンコーディングに許容文字セットの全てにおいてその文字のバイト値を表します。具体的にUNICODEで、 ";"次いで、DAG / IPプロトコルで使用されるバイト値0x3Bを生成するUTF-8の文字をエンコードする文字U + 003Bを意味します。
server-resp = goodmessage mnl output mnl endmessage / badmessage nl endmessageclose
サーバー-RESP = goodmessageのMNL出力MNL endmessage / badmessage NL endmessageclose
output = 0*(full-record / server-to-ask)
出力= 0 *（フルレコード/サーバと尋ねます）
full-record = "# FULL " template " " serverhandle " " localhandle system-nl 1*fulldata "# END" system-nl
フルレコード= "＃FULL" テンプレート "" にserverHandle "" localhandleシステム-NL 1 * fulldata "＃1 END" システム-NL
TISDAG: serverhandle is:
火曜日：サーバー・ハンドルは次のとおりです。
- 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、<ホスト名なしの-期間> <ポート>（サーバーのDNさんがenforceably一意ではありませんので）。例えば、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によって返されたレコードのlocalhandle - LDAP、それは「_」に置き換えた空間で、RDN（相対識別名）です。例えば、CN = leslie_daigle
server-to-ask = "# SERVER-TO-ASK " serverhandle system-nl server-to-askdata "# END" system-nl
サーバと尋ねる= "＃のSERVER-TO-ASK" にserverHandleシステム-NLサーバーツーaskdata "＃1 END" システム-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
attributename = r-string
attributeNameの= R-文字列
attributevalue = longstring
属性値=のLongString
template = <%d32-%d255 except specialbyte>
テンプレート= <％d32-％D255 specialbyte除きます>
serverhandle = <%d32-%d255 except specialbyte>
serverHandle = <％d32-％D255 specialbyte除きます>
localhandle = <%d32-%d255 except specialbyte>
localhandle = <％d32-％D255 specialbyte除きます>
serverinfo = string
serverinfo =文字列
hostname = string
ホスト名=文字列
prot = string ; currently one of "ldapv2" ; "ldapv3" "whois++"
PROT =文字列。現在、「のLDAPv2」の一つ。 "LDAPv3の" "WHOIS ++"
characterset = "UTF-8" / "T.61" / "ISO8859-1" / "US-ASCII"
キャラクタ= "UTF-8" / "T.61" / "ISO8859-1" / "US-ASCII"
source = string
ソース=文字列
longstring = string 0*( nl ( "+" / "-" ) string )
LongString =文字列0 *（NL（ "+" / " - "）の文字列）
string = 0*(%d32-255)
文字列= 0 *（％のd32-255）
r-string = 0*(<%d32-126 except specialbyte>) ; omit 127 which is DEL
Rストリング= 0 *（<％d32-126 specialbyte除きます>）。 DELである127を省略
specialbyte = ":" / " "
specialbyte = "：" / ""
mnl = 1*system-nl
MNL = 1 *システム-NL
system-nl = nl [ 1*(message nl) ]
システム-NL = NL [1 *（メッセージNL）]
nl = %d13 %d10 ; CR and LF
NL =％のD13％以下のD10。 CRとLF
message = [1*( messagestart "-" string nl)] messagestart " " string nl
メッセージ= [1 *（messagestart " - " の文字列NL）] messagestart "" 文字列NL
messagestart = "% " digit digit digit goodmessage = [1*( goodmessagestart "-" string nl)] goodmessagestart " " string nl
messagestart = "％" 桁の数字桁goodmessage = 1 *（goodmessagestart " - " の文字列NL）] goodmessagestart "" 文字列NL
goodmessagestart= "% 200"
goodmessagestart = "200％"
badmessage = [1*( badmessagestart "-" string nl)] badmessagestart " " string nl
badmessage = 1 *（badmessagestart " - " の文字列NL）] badmessagestart "" 文字列NL
badmessagestart = "% 5" digit digit
badmessagestart = "％5" 桁の数字
endmessage = endmessageclose / endmessagecont
endmessage = endmessageclose / endmessagecont
endmessageclose = [endmessagestart " " string nl] byemessage
endmessageclose = [endmessagestart "" 文字列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 )
数= 1 *（桁）
digit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
桁= "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
C.4 DAG/IP Response Messages
C.4 DAG / IPの応答メッセージ
The following list and discussion of response codes is derived from the Whois++ protocol definition, RFC1835 ([6]).
応答コードの次のリストおよび議論は、フーイズ++プロトコル定義、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.
システムメッセージは、空間三桁の数字、スペース、およびオプションのテキストメッセージが続く、「％」で始まります。ラインメッセージは、終端CR LF対を含む、これ以上81バイト以下の長さでなければなりません。生成されるシステムメッセージの数に制限はありません。
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.
ACME株式会社で％220-ようこそ％〜220-の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のリストに「キャラクタ・セット」リストに指定されています
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.
111 Requested constraint not One or more constraints in query supported is not implemented, but the search is still done.
111要求された制約クエリ内の1つのまたは複数の制約がサポートされていないが実装されていませんが、検索はまだ行われています。
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さようならサーバーは接続を閉じています
204 Overgeneralized The server could not exactly match the DAG query into its native access protocol. The resulting native query was "looser".
204 Overgeneralizedサーバーは正確にネイティブのアクセスプロトコルに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
402検索式は複雑すぎます
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クエリは、「あまりにも多くのヒット曲」の状況と似ていますが、サーバーはすべての結果に沿って送信されません。このメッセージは、データマイニングを偏向するために使用されます。
505 Operations error Permanent operations error
505オペレーションエラー常設の操作エラー
600 <token> Subsequent attribute values are encoded in the character set specified by <token>.
600 <トークン>以降の属性値は、<トークン>で指定された文字セットでエンコードされています。
601 <token> Subsequent attribute values are in the language specified by <token>.
601 <トークン>後続の属性値が<トークン>によって指定された言語です。
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 <トークン>」で指定されていないすべての言語のために使用すべきである、すなわち、デフォルト値です。
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
Table D.1 LDAPv2/v3 resultcodes to DAG/IP response codes mapping
DAG / IP応答コードへのマッピング表D.1のLDAPv2 / v3ののresultcodes
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
LDAPv2 / v3のresultcodesにDAG / IP応答コードから表D.2のマッピング
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
DAG / IPとのWhois ++レスポンスコード間の表D.3のマッピング
Appendix E - DAG CIP Usage
付録E - DAYのCIPの使い方
E.1 CIP Index Object
E.1 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:
[12]で定義されるようDAGシステムで使用されるCIPオブジェクトは、タグ付き索引オブジェクトに基づいています。次のように進行中でその仕事から適合文法は、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 | "-" | ";" | "."
索引オブジェクト= 0 *（IO-部SEP）IO-部IO-一部=ヘッダのSEPスキーマ仕様9月インデックス-Infoヘッダ=バージョン仕様のSEP更新系9月この更新9月最終更新コンテキストサイズ版 - スペック= "バージョン：" *空間 "Xタグインデックス-1" UPDATETYPE = "UPDATETYPE：" *空間（ "合計" |（ "インクリメンタル" [* SPACE "tagbased" | "uniqueIDbased"]）this-アップデート= "thisUpdateの：" *空間のタイムスタンプ最終更新日= [ "最終更新日：" * SPACEタイムスタンプ9月] contextsize = [ "contextsize：" * SPACE 1 * DIGIT 9月]スキーマ仕様= "BEGIN IO-スキーマ" 9月1 *（スキーマ行SEP）、 "END IO-スキーマ" スキーマライン=属性名 "：" トークン・タイプのトークン型= "TOKEN" インデックス情報=フルインデックス|インクリメンタル・インデックスのフル指数= " BEGIN索引情報」9月1日*（インデックスブロック9月）、 『END索引情報』インクリメンタル・インデックス= 1 *（アドオンブロック|削除 - ブロック|更新ブロック）アドオンブロック= 『ブロックを追加BEGIN』 9月1日*（インデックスブロックSEP） "ENDはブロックを追加し、" 削除ブロックを= "ブロックを削除BEGIN" 9月1日*（インデックスブロックSEP） "ENDはブロックの削除" 更新ブロック= "BEGIN更新ブロック" 9月0 *（old-インデックスブロックSE P）1 *（新しいインデックスブロックSEP）「END更新ブロック」古いインデックス・ブロック=「BEGIN古い」9月1日*（インデックスブロック9月）、「END旧」新・インデックス・ブロックは、=「新規BEGIN」 9月1日*（インデックスブロックSEP）インデックスブロック=最初のライン0 *（SEPの続きライン）第一= ATTR名を「新規END」「：」*スペースタグリスト「/」ATTR値CONTライン= " - " タグリスト "/" attrの値タグリスト=タグ0 *（ "" タグ）| "*" タグ= 1 * DIGITの[ " - " 1 * DIGIT] ATTR値= 1 *（UTF8）ATTR名= DAG-searchattr / "オブジェクトクラス" 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>;
LF = <ASCII LF, line feed, %x0A>;
LF = <ASCIIのLF、ラインフィード、％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 = "" | "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 ;; CR、LF、除くUS-ASCII 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.
N.Bが許可のみトークン化型は「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.
タグは、エントリごとのレベルでデータに適用されることにも留意されたいです。同じインデックスオブジェクトに2つのインデックス行が、同じタグが含まれている場合はこのように、それはこれらの2行は、ディレクトリ内の同じ「記録」に戻って参照する場合は常にあります。 LDAP用語では、2行は同じディレクトリのオブジェクトへの参照を意味します。
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.
同じインデックスオブジェクトに2つのインデックス行が異なるタグを含んでさらにあれば、それは常にこれらの2行は、ディレクトリ内の別のレコードに戻って参照する場合です。
The attribute "objectclass" is used to denote the record/object types in the data summarized in this index object.
属性「オブジェクトクラスが」このインデックスのオブジェクトにまとめたデータのレコード/オブジェクトの種類を示すために使用されます。
Values for the objectclass attribute should be restricted to: dagperson or dagrole, the two DAG schema object types.
objectclass属性の値に制限する必要があります。dagpersonまたはdagrole、2つのDAGスキーマ・オブジェクト・タイプ。
E.2 CIP Index Object Creation
E.2 CIPインデックスオブジェクトの作成
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:
WDSPsはフーイズ++プロトコルドキュメント（重心の作成）とタグ付き索引オブジェクトドキュメント（[12]）で概説した一般的な原理次インデックスオブジェクトを作成することが期待されます。上記の構文に続き、インデックスオブジェクトは、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：フーバーORG：スナックバー
Record #2: FN: Bar Smith ORG: Snack Shack
レコード＃2：FN：バー・スミスORG：スナックシャック
yields (conceptually) the following information for the attribute FN:
利回り（概念的には）属性FNについて、次の情報：
Foo (1), Bar (1,2), Smith (2)
FOO（1）、バー（1,2）、スミス（2）
and the following information for the attribute ORG:
属性ORGの次の情報：
The (1), Snack (1, 2), Bar (1), Shack (2)
（1）、スナック（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.
ここでは、レコード番号は2つのトークンが同じレコードに表示されることを示すために単にタグまたは仮想レコード識別子として使用されていることに注意してください。レコード識別子は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.
すべての属性の同じレコードタグの使用は、それがあまりにも簡単にインデックスオブジェクトを「コンパイル」することができますかどうかなど、いくつかの議論があります。即ち、各属性タグ番号に関連付けられたトークンを再順序付けに基づいWDSPsデータを再構成します。しかし、我々は、検索がWDSPが保持するデータの量の最小サブセットである、ここでは属性のみを扱っています。結論は、改善された効率は情報復元の（遠隔）の可能性を上回る属性で同じタグ番号を使用することによって与えられること次にです。
This would yield the index object:
これは、インデックスオブジェクトをもたらすであろう。
version: x-tagged-index-1 update-type: total this-update: 855938804
バージョン：Xタグインデックス-1更新型：総この更新：855938804
last-update: context-size: BEGIN IO-Schema objectclass: TOKEN
最終更新：コンテキストサイズ：IO-スキーマオブジェクトクラスをBEGIN：TOKEN
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-スキーマBEGIN索引情報オブジェクトクラス：* / dagperson FN：1 / Fooの-1,2 /バー-2 /スミスORG：1 / -1,2 /スナック-1 /バー - 2 /シャックエンド索引情報
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：プロジェクト内では、一貫性のあるタグの更新の間に、ベースの整合性に決定しています。これは、更新型である場合は、「増分」指定子は「tagbased」でなければならないことを意味しています。
E.3 CIP Index Object Sharing
E.3 CIPインデックスオブジェクトの共有
E.3.1 Registration of Servers
サーバーのE.3.1登録
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：1つ以上の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：コンシューマサーバのRFC 822電子メールアドレスと、フォーム：これは「のmailto」のURIです。
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：一緒にインデックスの特定の使用をサポートしたいインデックスサーバーのすべてのセットは、索引オブジェクトで使用するattributenamesた上で同意する必要があります。参加ディレクトリサーバーは、インデックスで使用attributenamesへのローカルattributenamesからのマッピングに同意する必要があります。一つの特定のインデックスサーバーは、いくつかのようなセットに関与しているかもしれないので、それはインデックスの適切なセットに更新を接続するためのいくつかの方法を持っている必要があります。これに対する一つの可能な解決策は、異なるDSISを使用することです。
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.
consistencybase：どのようにインデックスの整合性を増分更新にわたって維持される：完全 - すべての変更または1つのオブジェクトは、そのオブジェクトに接続されているすべてのトークンが含まれている必要がありに関する削除します。このメソッドは、この規格に準拠したい任意のサーバによってサポートされている必要がありtagbased - すべての増分更新が戻って、このフル更新を参照して完全な更新で始まると、元のデータベース内のオブジェクトが割り当てられているように、タグに関する状態情報を維持しなければなりません同じtagnumber毎回。このメソッドはオプションです。
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.
ユニークID - データセット内のすべてのオブジェクトは、インデックス内の特定の属性に一意の値を持っている必要があります。そのような属性の例としては、distinguishedName属性である可能性があります。この方法はまた、任意です。
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：サプライヤサーバーがコンシューマサーバに送信する前に、更新に署名し、暗号化する必要があるかどうか、どのように。更新が平文で「PGP / MIME」を送られる：DAGサービスのこのバージョンのためのオプションは「なし」ではない更新がデジタル署名および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」の場合、これは、両方のサーバーの信頼された公開鍵となります。
E.3.2 Transmission of Objects
オブジェクトのE.3.2送信
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メーリングリストで発表された、すべてのスウェーデンWDSPs（および潜在的なWDSPs）を記入し、HTTPを参照してください（WWWベースの調査票を提出することを奨励されました：//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.
調査は月に行われた、1997年レスポンスが期待されていたほど良くはなかった - 最後に、5 WDSPsが参加しました。私たちは、ディレクトリ・サービス・プロバイダの現在および計画中の状態の具体的な感覚を持っているために、これ以上の応答を期待していました。しかし、ソルレツナでInteroperabilitet'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ヶ月で貢献し、100件の以上の000レコードを持っていることを期待しています。サポートされるプロトコルまたは検索タイプの面では本当の驚きはなかったです。
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は、現在WDSPsでサポートされているクエリのタイプに関する調査からの情報をまとめたものであり、今後12カ月間に予定。 WDSPsはLDAPでのWhois ++とのinetOrgPersonオブジェクトクラスでDAGPERSONスキーマプロトコル当量（すなわち、ユーザーテンプレートの両方をサポートしている場合、調査が特に要求していないので、調査の時点で、ROLEによる検索の要件が提案されていなかった、ということに注意してください）。表では、列には、「情報を完了します？」 WDSP現在DAG応答のために必要とされるように、少なくともできるだけ多くの情報を返すかどうかを記述しています。
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、NO、NL、NOL役割のLDAPv2、DAP、PH、のLDAPv2、LDAPv3の、DAP、HTTP、GopherのPH、HTTP、Gopherの場合を除き
3 N,NL,NOL Except ROLE LDAPv2,DAP,HTTP LDAPv2,LDAPv3,DAP, HTTP
役割のLDAPv2、DAP、HTTPのLDAPv2、LDAPv3の、DAP、HTTPを除いて3 N、NL、NOL
4 N,NO,NL,NOL Except ROLE Whois++,HTTP LDAPv3,Whois++, HTTP,E-mail
4 N、NO、NL、NOLの役割以外のWhois ++、HTTPのLDAPv3、Whoisの++、HTTP、Eメール
5 N,NO,NL,NOL Except ROLE LDAPv2,Whois LDAPv2,LDAPv3, Whois++,HTTP Whois,Whois++,PH, Finger,HTTP
5 N、役割のLDAPv2、WhoisののLDAPv2、LDAPv3の、Whoisの++、HTTP Whoisの、Whoisの++、PH、指、HTTP以外に、NL、NOL
Table F.1 Summary of TISDAG Survey Results: Queries
TISDAG調査結果の表F.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
TISDAG調査結果の表F.2の概要：運用情報
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.
N.Bは：次は、このレポートの物質が描かれたインターネット標準文書（のRFC）とインターネットドラフトのコレクションです。インターネットドラフトは、作品進行中であり、引用することを意味しません。彼らはこの文書で使用されている場合は、参照は、インターネットドラフトに含まれるテキストにあります。すなわち、それらは、このプロジェクトの作業のための便利な出発点としてそんなに基準を意味するものではありません。
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.
この報告書の作成に使用されたインターネットドラフト文書のバージョンの電子コピーは、プロジェクトのWebページ、http://tisdag.sunet.seから入手できます。
Bibliography
参考文献
[1] Allen, J. and M. Mealling, "The Architecture of the Common Indexing Protocol", RFC 2651, August 1999.
[1]アレン、J.とM. Mealling、 "共通インデックスプロトコルのアーキテクチャ"、RFC 2651、1999年8月。
[2] Allen, J. and M. Mealing, "MIME Object Definitions for the Common Indexing Protocol (CIP)", RFC 2652, August 1999.
[2]アレン、J.とM. Mealing、 "共通インデックスプロトコルのMIMEオブジェクト定義（CIP）"、RFC 2652、1999年8月を。
[3] Allen, J. and P. Leach, "CIP Transport Protocols", RFC 2653, August 1999.
[3]アレン、J.とP.リーチ、 "CIPトランスポートプロトコル"、RFC 2653、1999年8月。
[4] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[4]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
[5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[5]クロッカー、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]、RFC 1835ドイツ、P.、Schoultz、R.、FALS分光計、P.とC.さらに、 "WHOIS ++サービスのアーキテクチャ" を、1995年7月。
[7] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
[7]エルキンズ、M.、 "プリティグッドプライバシーとMIMEセキュリティ（PGP）"、RFC 2015、1996年10月。
[8] Patrik Faltstrom, Martin Hamilton, Leslie L. Daigle, "WHOIS++ templates", Work in Progress.
[8]パトリックFaltstrom、マーティン・ハミルトン、レスリー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]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：Interentメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[10] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[10]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[11] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
[11]グッド、G.、 "LDAPデータ交換フォーマット（LDIF） - 技術仕様"、RFC 2849、2000年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]ヘドバーグ、R.、グリーンブラット、B.、堀、R.及びM.ワール、 "共通インデックスプロトコルにおける使用のためのタグ付きインデックスオブジェクト"、RFC 2654、1999年8月。
[13] Howes, R., "A String Representation of LDAP Search Filters", RFC 1960, June 1996.
[13]ハウズ、R.、 "LDAP検索フィルタの文字列表現"、RFC 1960、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]ポール・Panotzki、「一般的なインデックスプロトコルの複雑さ：Index Serverのメッシュで検索回数を予測する」、修士論文、KTH、1996年9月。
[15] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[15]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、1982年8月。
[16] Smith, M., "Definition of the inetOrgPerson Object Class", RFC 2798, April 2000.
[16]スミス、M.、 "inetOrgPersonオブジェクトクラスの定義"、RFC 2798、2000年4月。
[17] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[17]ワール、M.、ハウズ、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]ワール、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]永、W.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル"、RFC 1777、1995年3月。
[20] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[20] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 2279、1998年1月。
[21] The Unicode Consortium, "The Unicode Standard -- Version 2.0", Addison-Wesley, 1996.
[21]ユニコードコンソーシアム、 "Unicode規格 - バージョン2.0"、アディソン・ウェズリー、1996。
Authors' Addresses
著者のアドレス
Leslie L. Daigle Thinking Cat Enterprises
レスリーL. Daigle氏猫の企業を考えます
EMail: leslie@thinkingcat.com
メールアドレス：leslie@thinkingcat.com
Roland Hedberg Catalogix Jegerveien 25 0777 Oslo Norway
ローランドヘドバーグCatalogixハンターの道25 0777オスロノルウェー
Phone: +47 23 08 29 96 EMail: Roland@catalogix.se
電話：+47 23 08 29 96 Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。