[要約] RFC 2967は、スウェーデンのディレクトリアクセスゲートウェイの技術インフラに関するものであり、その目的は、セキュアなディレクトリアクセスを提供するためのガイドラインを提供することです。
Network Working Group L. Daigle
Request for Comments: 2967 Thinking Cat Enterprises
Category: Informational R. Hedberg
Catalogix
October 2000
TISDAG - Technical Infrastructure for Swedish Directory Access Gateways
TISDAG-スウェーデンのディレクトリアクセスゲートウェイ用の技術インフラストラクチャ
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
The strength of the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) project's DAG proposal is that it defines the necessary technical infrastructure to provide a single-access-point service for information on Swedish Internet users. The resulting service will provide uniform access for all information -- the same level of access to information (7x24 service), and the same information made available, irrespective of the service provider responsible for maintaining that information, their directory service protocols, or the end-user's client access protocol.
TISDAG（スウェーデンのディレクトリアクセスゲートウェイの技術インフラストラクチャ）プロジェクトのDAG提案の強さは、スウェーデンのインターネットユーザーに関する情報にシングルアクセスポイントサービスを提供するために必要な技術インフラストラクチャを定義することです。結果のサービスは、すべての情報に均一なアクセスを提供します - 情報への同じレベルのアクセス（7x24サービス）、およびその情報、そのディレクトリサービスプロトコル、または終了の維持を担当するサービスプロバイダーに関係なく、同じ情報が利用可能になりました。-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.
このプロジェクトの包括的な目標は、スウェーデンのインターネットユーザーに関するホワイトページ情報を検索するための単一アクセスポイントサービスを提供するために必要な技術インフラストラクチャを開発することです。この情報を維持するサービスプロバイダーに関係なく、このサービスはすべての情報（7x24サービス）と同じレベルの情報（7x24サービス）と同じホワイトページ情報に対して均一でなければなりません。
The strength of the TISDAG project's DAG proposal is that it defines the necessary technical infrastructure to provide a single-access-point service for information on Swedish Internet users. The resulting service will provide uniform access for all information -- the same level of access to information (7x24 service), and the same information made available, irrespective of the service provider responsible for maintaining that information, their directory service protocols, or the end-user's client access protocol.
TISDAGプロジェクトのDAG提案の強みは、スウェーデンのインターネットユーザーに関する情報に単一アクセスポイントサービスを提供するために必要な技術インフラストラクチャを定義することです。結果のサービスは、すべての情報に均一なアクセスを提供します - 情報への同じレベルのアクセス（7x24サービス）、およびその情報、そのディレクトリサービスプロトコル、または終了の維持を担当するサービスプロバイダーに関係なく、同じ情報が利用可能になりました。-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.
Swedishディレクトリサービスプロバイダーからの完全な情報レコードの集中ミラーリングを要求する代わりに、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-System：TISDAGプロジェクトから生じるディレクトリアクセスゲートウェイシステム。スウェーデンのホワイトページ情報への統一されたアクセスを提供する目的で、インフラストラクチャソフトウェアとサービスのコレクション。
DAG/IP: DAG-Internal Protocol -- communication protocol used between software components of the DAG.
DAG/IP：DAG-Internal Protocol- DAGのソフトウェアコンポーネント間で使用される通信プロトコル。
End-User: People performing White Pages searches and look-ups (via various forms of client software).
エンドユーザー：ホワイトページの検索とルックアップを実行する人（さまざまな形式のクライアントソフトウェアを介して）。
DAG-SAP: Service Access Point -- point of communication between the DAG and WDSP software.
DAG-SAP：サービスアクセスポイント - DAGソフトウェアとWDSPソフトウェア間の通信ポイント。
WDSP: Whitepages Directory Service Provider -- ISPs, companies, or other interested entities.
WDSP：WhitePagesディレクトリサービスプロバイダー - ISP、企業、またはその他の関心のあるエンティティ。
Whitepages Information: Collected information coordinates for individual people. This typically includes (but is not limited to) a person's name, and e-mail address.
ホワイトページ情報：個々の人向けの収集された情報座標。これには通常、個人の名前と電子メールアドレスが含まれます（ただし、これらに限定されません）。
There are 2 primary classes of users for the proposed Whitepages directory access gateway:
提案されているホワイトページディレクトリアクセスゲートウェイには、2つの主要なクラスのユーザーがあります。
- End-users - WDSPs
- エンドユーザー-WDSP
As outlined below, needs of each of these user classes imposes a set of constraints on the design of the DAG system itself. Some of the requirements shown below are assumed starting criteria for the DAG service; others have been derived from data collected in the Technical Survey or other expertise input.
以下に概説するように、これらの各ユーザークラスのニーズは、DAGシステム自体の設計に一連の制約を課します。以下に示す要件のいくつかは、DAGサービスの開始基準を想定しています。その他は、技術調査またはその他の専門知識入力で収集されたデータから派生しています。
The End-User is to be provided with a specific set of search types:
エンドユーザーには、特定の検索タイプのセットが提供されます。
Name Name + Organization Role + Organization Name + Locality Name + Organization + Locality Role + Organization + Locality
名前名組織役割組織名局所名組織の局所性ロール組織局所性
The search results will, if available, include the following information for each "hit":
検索結果には、利用可能な場合、各「ヒット」の次の情報が含まれます。
- Full name - E-mail address - Role - Organization - Locality - Full address - Telephone numbers
- フルネーム - 電子メールアドレス - 役割 - 組織 - 地域 - フルアドレス - 電話番号
Access to the service must be available through reasonable and current protocols -- such that directory-service-aware software can make use of it seamlessly, and there are no reasonable technological impediments to making this service useful to all Swedish Internet users.
サービスへのアクセスは、リーズナブルで現在のプロトコルを通じて利用できる必要があります。そのため、ディレクトリサービスアウェアソフトウェアがシームレスに利用できるようにし、このサービスをすべてのスウェーデンのインターネットユーザーに役立つことに合理的な技術的障害はありません。
Following on that, its responses are expected to be timely; a standard search should not take more time than the average access to a web-server.
それに続いて、その応答はタイムリーになると予想されます。標準検索では、Webサーバーへの平均アクセスよりも時間がかかりません。
Given that the WDSPs that participate in this service are already in the business of providing a service of whitepages information, they have certain requirements that must be respected in order to make this a successful and useful service to all concerned.
このサービスに参加しているWDSPは、すでにホワイトページ情報のサービスを提供するビジネスにあることを考えると、これを関係者全員にとって成功し、有用なサービスにするために尊重されなければならない特定の要件があります。
The DAG system must provide reasonable assurances of data integrity for WDSPs; the information the End-User sees should correspond directly to that provided by the WDSPs. The DAG system should be non-preferential in providing whitepages information -- the service is to the End-User, and the source of whitepages information should not influence the search and information presentation processes.
DAGシステムは、WDSPのデータ整合性の合理的な保証を提供する必要があります。エンドユーザーが見ている情報は、WDSPによって提供される情報に直接対応する必要があります。DAGシステムは、ホワイトページ情報を提供する上で非適切なものでなければなりません。サービスはエンドユーザーに対するものであり、ホワイトページ情報のソースは検索および情報の表示プロセスに影響を与えてはなりません。
The DAG system must be able to reflect information updates within a reasonable time after receipt from WDSPs; on the flip side, while the DAG system will function best with regular updates from WDSPs, the update and participation overhead for WDSPs should be held within reasonable bounds of what the WDSP should do to support regular access to its information.
DAGシステムは、WDSPから受領後の妥当な時間内に情報の更新を反映できる必要があります。反対に、DAGシステムはWDSPからの定期的な更新で最適に機能しますが、WDSPの更新と参加オーバーヘッドは、その情報への定期的なアクセスをサポートするためにWDSPがすべきことの合理的な境界内に保持する必要があります。
Furthermore, given that WDSPs provide directory service information with an eye to value-added service, wherever possible End-Users should be redirected to the WDSP responsible for individual directory service entries for final and further information.
さらに、WDSPが付加価値サービスに目を向けてディレクトリサービス情報を提供することを考えると、可能な限りエンドユーザーが最終情報と詳細の個々のディレクトリサービスエントリを担当するWDSPにリダイレクトする必要があります。
In order to address the requirements of End-Users and WDSPs, the DAG system itself has certain design constraints that must be taken into account.
エンドユーザーとWDSPの要件に対処するために、DAGシステム自体には、考慮する必要がある特定の設計上の制約があります。
The system must be implementable/operational by Dec 31/98 -- which implies that it must be designed and constructed with already extant technologies.
システムは、98年12月31日までに実装可能/動作する必要があります。これは、すでに現存するテクノロジーで設計および構築する必要があることを意味します。
The System will have certain requirements for participation -- e.g., 7x24 WDSP availability.
システムには、参加のための特定の要件があります - たとえば、7x24 WDSPの可用性。
In terms of scaling, the system should be able to handle 8M records at the outset, with a view to handling larger information systems in the future.
スケーリングに関しては、システムは、将来的には大規模な情報システムを処理することを目的として、最初に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パイロットサービスでは、DAG/IPに指定されているものについていくつかの制限を適用することにしました。これらの制限は、次の方法でこのテキストに示されています。
TISDAG: This is a TISDAG comment
tisdag：これはtisdagのコメントです
The conceptual environment of the DAG system can be described in three major components:
DAGシステムの概念的環境は、3つの主要なコンポーネントで説明できます。
- client access software for end-users - the DAG system core - WDSP directory service software This is illustrated in Figure 3.1
- エンドユーザー向けのクライアントアクセスソフトウェア-DAGシステムコア-WDSPディレクトリサービスソフトウェアこれは図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.
データの量 - 利用可能になるホワイトページ情報の量、およびそのソースの多様性（異なるWDSP）は、効率的な検索を可能にし、必要な情報を更新する適時性を促進する構造を見つけるという点で課題を導入します。
Multiplicity of access protocols -- in order to support the use of existing whitepages-aware software with a minimum of perturbation, the DAG system will have to present a uniform face in several different access protocols, each with its own information search and representation paradigm.
多数のアクセスプロトコル - 最小限の摂動を備えた既存のホワイトページ対応ソフトウェアの使用をサポートするために、DAGシステムは、それぞれ独自の情報検索と表現パラダイムを備えたいくつかの異なるアクセスプロトコルで均一な顔を提示する必要があります。
This specification will outline the following areas:
この仕様では、次の領域の概要を説明します。
- the functioning of the DAG core itself - the interface between the DAG core and End-Users' Directory Service Access software - the interface between the DAG core and Directory Services Servers
- DAGコア自体の機能 - DAGコアとエンドユーザーのディレクトリサービスアクセスソフトウェアの間のインターフェイス - DAGコアサービスサーバーとディレクトリサービスサーバーのインターフェイス
In order to reduce the quantity of data the DAG itself must maintain, and to keep the maintenance of the whitepages information as close as possible to the source of information (the WDSPs themselves), the DAG will only maintain index information and will use "query routing" to efficiently refer End-User queries to WDSPs for search refinement and retrieval of information. Although originally developed for the Whois++ protocol, query routing is being pursued in a protocol-independent fashion in the IETF's FIND WG, so the choice of this approach does not limit the selection and support of whitepages access protocols.
データの量を減らすために、DAG自体が維持する必要があり、ホワイトページ情報のメンテナンスを情報源（WDSP自体）に可能な限り近くに保つために、DAGはインデックス情報のみを維持し、「クエリ」を使用します。ルーティング「エンドユーザークエリをWDSPに効率的に参照して、検索の改良と情報の検索を行います。当初はWOHISプロトコル用に開発されましたが、クエリルーティングは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
Figure 3.1 The role of the DAG system
図3.1 DAGシステムの役割
The DAG will respond to End-User queries in
DAGは、エンドユーザークエリに応答します
- e-mail (SMTP) - WWW (HTTP) - LDAPv2 - Whois++ - LDAPv3
- 電子メール（SMTP）-www（http）-ldapv2 -whois -ldapv3
The DAG will provide responses including the agreed-upon data. For access protocols that can handle referrals, responses will be data and/or referrals in that query protocol. These are Whois++ and LDAPv3. N.B.: the LDAPv3 proposal defines a referral as a URL; no limitation is placed on the access protocol. However it cannot be assumed that all clients will be able to handle all access protocols, so only referrals to LDAPv3 servers will be returned.
DAGは、合意されたデータを含む応答を提供します。紹介を処理できるアクセスプロトコルの場合、応答はそのクエリプロトコルのデータおよび/または紹介になります。これらはWHOISとLDAPV3です。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ダグサポートクエリ
The RO and ROL queries are separated from the rest as they are searches for "virtual" persons -- roles within an organization (e.g., president, or customer service desk) for which one might want to find contact information.
ROおよびROLクエリは、「仮想」の人、つまり連絡先情報を見つけたいと思う可能性のある組織内の役割（社長やカスタマーサービスデスクなど）を検索しているため、残りから分離されています。
Matching Semantics
一致するセマンティクス
As befits the individual client query protocols, more string matching expressions may be provided. The basic semantics of the DAG expect the following to be available in all client access software (as relevant):
個々のクライアントクエリプロトコルにふさわしいように、より多くの文字列マッチング式が提供される場合があります。DAGの基本的なセマンティクスは、すべてのクライアントアクセスソフトウェア（関連する）で以下が利用可能になることを期待しています。
- Full word, exact match - Word substring match (E.g., "cat" would match "scatter") - Case-sensitive and case-insensitive matching
- 完全な単語、正確な一致 - 単語のサブストリングマッチ（例えば、「猫」は「散布」に一致するでしょう） - ケースに敏感でケースに依存しないマッチング
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属性などの最も使用される属性の一部は、標準で定義されていると定義されています。DAGシステムへの影響は、LDAP/X.500サーバーから収集されたインデックスがトークンに上限と小文字と小文字の文字を持っている可能性がある場合でも、ネイティブなものの意味を推測しているため、そのように処理できないことです。意味のないと見なされます。上記の結論は、紹介インデックスがケース非感受性であり、ネイティブアクセスプロトコルがサポートしている場合、SAPSによってケース感受性をサポートする必要があることです。
Character Sets
文字セット
Wherever possible, the DAG System supports and promotes the use of Unicode Version 2.0 for character sets (see [21]) specifically the UTF-8 encoding (see Appendix A.2 of [21] or [20]) Accommodation is made, where necessary, to support the deployed base of existing software.
可能な限り、DAGシステムは、文字セットにUnicodeバージョン2.0の使用をサポートおよび促進します（[21]を参照）具体的にはUTF-8エンコード（[21]または[20]の付録A.2を参照）の宿泊施設が作成されます。既存のソフトウェアの展開ベースをサポートするために必要です。
Specifically:
具体的には：
DAG/IP: All internal communications using the DAG/IP are carried out in UTF-8.
DAG/IP：DAG/IPを使用したすべての内部通信は、UTF-8で実行されます。
TISDAG: not just UTF-8, but UTF-8 based on composed UNICODE version 2 character encodings.
TISDAG：UTF-8だけでなく、構成されたUnicodeバージョン2文字エンコーディングに基づいてUTF-8。
DAG-CAP input: Where specific access protocols permit selection of character sets, DAG-CAPs must support UTF-8. They may additionally support other anticipated character set encodings.
DAG-CAP入力：特定のアクセスプロトコルが文字セットの選択を許可する場合、DAG-CAPSは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-SAPSは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システムにWDSPによって提供されるインデックスオブジェクトには、UTF-8にエンコードされたデータを含める必要があります。
TISDAG: The same limitation as for DAG/IP, that is the basic data should be UTF-8 encoded composed UNICODE version 2 character encodings.
TISDAG：DAG/IPと同じ制限です。つまり、基本データはUTF-8エンコードされたUnicodeバージョン2文字エンコーディングである必要があります。
Schema Definition
スキーマ定義
The schema used for the DAG service is defined in Appendix A. This is a very basic information schema, intended to carry the necessary information for the DAG service, and not more. Although generic "whitepages" schema definitions do exist the more sophisticated and detailed the information presentation, the more difficult it is to map the schema seamlessly across protocols of different paradigms. Thus, the "KISS" ("Keep it simple, sir") principle seems appropriate here.
DAGサービスに使用されるスキーマは、付録Aで定義されています。これは非常に基本的な情報スキーマであり、DAGサービスに必要な情報を運ぶことを目的としています。一般的な「ホワイトページ」スキーマ定義は存在するほど、より洗練された情報プレゼンテーションを詳細に説明するほど、さまざまなパラダイムのプロトコル全体にスキーマをシームレスにマッピングすることがより困難になります。したがって、ここでは「キス」（「シンプル、シンプル、サー」）の原則が適切と思われます。
Individual DAG-CAPs define how they express this schema.
個々のダグキャップは、このスキーマをどのように表現するかを定義します。
Referral Definition
紹介定義
For client access protocols that make use of the concept of referrals, DAG-CAP definitions will define the expression of referrals in those protocols. The DAG/IP defines the expression of referrals (see Appendix C).
紹介の概念を利用するクライアントアクセスプロトコルの場合、DAG-CAP定義はこれらのプロトコルで紹介の表現を定義します。DAG/IPは、紹介の表現を定義します（付録Cを参照）。
Error conditions
エラー条件
Each DAG-CAP may provide more detailed error messages, but will define minimally the support for the following error conditions:
各DAG-CAPは、より詳細なエラーメッセージを提供する場合がありますが、次のエラー条件のサポートを最小限に抑えます。
- unrecognized query - too many hits
- 認識されていないクエリ - ヒットが多すぎます
Apart from these errors, the DAG-CAP may choose to refuse a query by redirecting the end-user to a different DAG-CAP of the same protocol.
これらのエラーとは別に、DAG-CAPは、エンドユーザーを同じプロトコルの異なるDAGキャップにリダイレクトすることにより、クエリを拒否することを選択できます。
The DAG will use the Common Indexing Protocol (CIP) server-server protocol to obtain updated index objects from WDSPs. For query-routing purposes, WDSPs are expected to provide Whois++, LDAPv2 or LDAPv3 interface to their data (although their preferred access may be something completely different). N.B.: In the responses from the technical survey, all respondents currently provide access to their service in one of these protocols.
DAGは、共通インデックスプロトコル（CIP）サーバーサーバープロトコルを使用して、WDSPから更新されたインデックスオブジェクトを取得します。クエリルーティングのために、WDSPはWHOIS、LDAPV2、またはLDAPV3インターフェイスをデータに提供することが期待されています（ただし、好みのアクセスは完全に異なる場合があります）。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.
有用で均一なサービスを提供するために、WDSPはホワイトページ情報への7x24アクセスを提供することが期待されています。また、WDSPは、計画および計画外の管理および保守活動の両方のサービスダウンタイムを最小限に抑えるために設計された運用、管理、メンテナンス、およびプロビジョニングプロセスを実装することも期待されています。
The conceptual architecture of the DAG is represented in Figure 4.1. General architectural specifications are described below, followed by individual component specifications Sections 5.5 through 5.12.
DAGの概念アーキテクチャを図4.1に示します。一般的な建築仕様を以下に説明し、その後、個々のコンポーネント仕様セクション5.5から5.12を説明します。
Communications between components of the DAG will be by TCP/IP connections, using the DAG-Internal Protocol (DAG/IP). DAG/IP is used by DAG-CAPs to communicate with the Referral Index and DAG-SAPs. Thus, the DAG/IP defines
DAGのコンポーネント間の通信は、DAG内部プロトコル（DAG/IP）を使用して、TCP/IP接続によって行われます。DAG/IPは、DAG-CAPSによって紹介インデックスおよび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-CAPSのクエリ能力の範囲（エンドユーザーの要求に応じて紹介を収集するため） - DAG-CAPリクエストへの紹介インデックスの応答（およびその形式） - DAG-CAPSDAG-CAPがクライアントアクセスソフトウェアのチェーンを行う必要がある場合、紹介を追求するためのDAG-SAPSへのクエリ能力の範囲 - DAG-CAPSへのDAG-SAPSの応答（およびその形式）。
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キャップとDAG-SAPの定義に記載されています。以下（セクション5.5〜5.12）。
The Referral Index is responsible for maintaining the index of WDSP information, and providing a list of reasonable referrals in response to DAG-CAP search requests. These "referrals" provide pointers to identify WDSPs that may have information that matches the end-user's query.
紹介インデックスは、WDSP情報のインデックスを維持し、DAG-CAP検索リクエストに応じた合理的な紹介のリストを提供する責任があります。これらの「紹介」は、エンドユーザーのクエリに一致する情報を持つ可能性のあるWDSPを識別するためのポインターを提供します。
Individual DAG-CAPs are responsible for providing a particular client access protocol interface to the DAG service. DAG-CAPs receive end-user queries in a particular query access protocol, convert the request into a query for the Referral Index ( i.e., expressed in DAG/IP), and then convert the Referral Index's response into a form that is appropriate for the client access protocol. This may mean passing back the referrals directly, calling on DAG-SAPs to do the work of translating the referral into results ("chaining"), or a combination of both.
個々のDAG-CAPSは、特定のクライアントアクセスプロトコルインターフェイスをDAGサービスに提供する責任があります。DAG-CAPSは、特定のクエリアクセスプロトコルでエンドユーザークエリを受信し、リクエストを紹介インデックスのクエリに変換し（つまり、DAG/IPで表現）、紹介インデックスの応答を適切なフォームに変換します。クライアントアクセスプロトコル。これは、紹介を直接渡すことを意味する場合があり、紹介を結果（「チェーン」）に翻訳する作業、または両方の組み合わせに翻訳する作業を行うように紹介することを意味する場合があります。
+-------------------------------------+
|+====+ |
HTTP <-->+| |<------+ (Full chaining) |
|| | | |
|+====+ | |
| | +----+|
| | Referral-->| ||
| | Result <--| |+<--> Whois++
| | +----+|
|+====+ | |
SMTP <-->+| |<------+ (Full chaining) |
|| | | |
|+====+ | |
| | +----+|
| | Referral-->| ||
| | Result <--| |+<--> LDAPv2
| | +----+|
|+====+ | |
Whois++<-->+| |<------+ (Chain LDAPv2/3) |
|| | | |
|+====+ | |
| | +----+|
| | Referral-->| ||
| | Result <--| |+<--> LDAPv3
| | +----+|
|+====+ | |
LDAPv2 <-->+| |<------+ (Full chaining) |
|| | | |
|+====+ | |
| | |
|+====+ | |
LDAPv3 <-->+| |<------+ (Chain Whois++) |
|| | | |
|+====+ | |
| | |
| v |
| +-----------------------+ |
| | Referral Index |<---------------> Common
| | | | Indexing Protocol
| +-----------------------+ | (CIP)
+-------------------------------------+
All internal communications are in DAG/IP.
すべての内部通信はDAG/IPです。
Figure 4.1 Conceptual Architecture of the DAG
図4.1ダグの概念アーキテクチャ
Individual DAG-SAPs are called upon (by DAG-CAPs) to take DAG-generated referrals and pursue them -- issuing the indicated query at the specified WDSP service. Results from individual WDSPs are converted back into DAG/IP-specific format for the DAG-CAP that made the request. Each DAG-SAP is responsible for handling referrals to WDSPs of a particular protocol (e.g., LDAPv2, Whois++, etc).
個々のDAG-SAPSは、（DAG-CAPSによって）DAG生成された紹介を行い、それらを追求するよう呼びかけられます - 指定されたWDSPサービスで指定されたクエリを発行します。個々のWDSPの結果は、リクエストを行ったDAG-CAPのDAG/IP固有の形式に変換されます。各DAG-SAPは、特定のプロトコル（LDAPV2、WHOISなどなど）のWDSPへの紹介を処理する責任があります。
This section notes some of the thinking that has driven the architectural and software design specification for the DAG system. This helps to provide the context in which to understand the software specifications that follow, and should give clues for the eventual extension of the DAG system. This section also acts, in some ways, as an FAQ (Frequently Asked Questions) section, as the content is shaped by questions received during the tech spec development phase. It attempts to illuminate context that may not otherwise be apparent on a first reading of the software specifications.
このセクションには、DAGシステムの建築およびソフトウェア設計の仕様を推進した思考の一部を示しています。これは、以下のソフトウェア仕様を理解するためのコンテキストを提供するのに役立ち、DAGシステムの最終的な拡張の手がかりを与える必要があります。また、このセクションは、コンテンツがTech Spec開発段階で受け取った質問によって形作られるため、ある意味でFAQ（よくある質問）セクションとして機能します。ソフトウェア仕様の最初の読み取りでは明らかではない場合があるコンテキストを照らしようとします。
At all times, it must be kept in mind that the primary function of the DAG system is to provide users with referrals to WDSP services that may have the information they seek. Since it is the case that not all supported client protocols can handle referrals, the DAG system also provides a chaining service to pursue referrals that the user's client software cannot handle itself. This chaining service does attempt to match the user's query against data from WDSPs, but this is to be seen as a secondary, or support function of the DAG system. In the perfect future, all access protocols will be able to handle all referrals!
常に、DAGシステムの主な機能は、ユーザーが求めている情報を持っている可能性のあるWDSPサービスへの紹介をユーザーに提供することであることに留意する必要があります。サポートされているすべてのクライアントプロトコルが紹介を処理できるわけではないため、DAGシステムは、ユーザーのクライアントソフトウェアがそれ自体を処理できない紹介を追求するためのチェーンサービスも提供します。このチェーンサービスは、ユーザーのクエリをWDSPのデータと一致させようとしますが、これはDAGシステムのセカンダリまたはサポート機能と見なされます。完璧な未来では、すべてのアクセスプロトコルがすべての紹介を処理できます！
The DAG system does not attempt to be a chameleon, or the ultimate whitepages query service. It focuses on providing referrals for information on the limited number of query types outlined in the functional specifications of the DAG service. This makes the DAG system a good place to start a search, but refinements and detailed inquiries are beyond its scope.
DAGシステムは、カメレオン、または究極のホワイトページクエリサービスになろうとはしません。DAGサービスの機能仕様で概説されている限られた数のクエリタイプに関する情報の紹介を提供することに焦点を当てています。これにより、DAGシステムは検索を開始するのに適した場所になりますが、改良と詳細な問い合わせはその範囲を超えています。
Given the limited query syntax of the DAG system it will not always be possible to exactly match a query posed to a CAP into a query posed to a SAP. This will have the effect that for instance a LDAPv2 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にポーズをとるクエリに正確に一致させることは常に可能ではありません。これは、たとえば、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システムの限られたクエリ構文でさえ、WDSPへのアクセスプロトコルで表現できない可能性のあるクエリを表現できます。これらの場合、DAG-SAPはクエリを拒否するか、それをエミュレートしようとすることができます。
As part of the chaining service offered by the DAG system, a certain amount of mapping between protocols is required -- in theoretical terms, there are "N" allowable end-user query access protocols, and "M" supported WDSP server protocols. The architecture of the software is constructed to use a single internal protocol (the DAG/IP) and data schema, providing a common language between all components. Without this, each input protocol module (DAG-CAP) would have to be constructed to be able to handle every WDSP protocol -- NxM protocol mappings. This would make the system complex, and difficult to expand to include new protocols in future.
DAGシステムが提供するチェーンサービスの一部として、プロトコル間の一定量のマッピングが必要です。理論的用語では、「n」許容エンドユーザークエリアクセスプロトコルと「M」サポートされたWDSPサーバープロトコルがあります。ソフトウェアのアーキテクチャは、単一の内部プロトコル（DAG/IP）とデータスキーマを使用するように構築され、すべてのコンポーネント間で共通言語を提供します。これがなければ、すべてのWDSPプロトコル（NXMプロトコルマッピングを処理できるように、各入力プロトコルモジュール（DAG-CAP）を構築する必要があります。これにより、システムが複雑になり、将来の新しいプロトコルを含めるために拡張が困難になります。
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/IPで発行されたクエリがDAG-SAPに発行されたクエリは、元のクエリに「より広い」可能性があるため、DAG-SAPSによって返された結果のポストフィルタリングを行うことが含まれる場合があります。
Thus, the DAG-CAP "knows" only 2 protocols: its native protocol, and the DAG/IP.
したがって、DAG-CAPは、ネイティブプロトコルとDAG/IPの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-SAPは、ネイティブプロトコルとDAG/IPの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-CAPSでサポートされているクエリプロトコルを使用します。WDSPは、DAG-SAPSでサポートされているクエリプロトコルを使用して連絡されます。
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システムアーキテクチャは、拡張性の特定のビューで構築されました。システムを破壊せずに、個々のコンポーネントが改善される可能性があります（たとえば、メールダグキャップに別のクエリインターフェイスが与えられる場合があります）。
Additionally, future versions of the DAG system may support other access protocols -- for end-users, and for WDSPs.
さらに、DAGシステムの将来のバージョンは、エンドユーザーとWDSPの他のアクセスプロトコルをサポートする場合があります。
It is always a challenge to accurately represent text protocol in a printed document; when is a new line a "newline", and when is it an effect of the text formatter? In order to be adequately illustrated, this document includes many segments of protocol grammars, sample data, and sample input/output in a text protocol. In order to distinguish newlines that are significant in a protocol, the symbol
印刷されたドキュメントでテキストプロトコルを正確に表現することは常に課題です。新しい行はいつ「新しいライン」ですか、そしてそれはいつテキストフォーマッタの効果ですか？適切に説明するために、このドキュメントには、テキストプロトコルのプロトコル文法、サンプルデータ、サンプル入力/出力の多くのセグメントが含まれています。プロトコルで重要なニューラインを区別するために、シンボル
<NL>
<nl>
is used. For example,
使用されている。例えば、
This is an example of a very long line of input. There is only one newline in it (at the end), in spite of the fact that this document shows it spanning several lines of text.<NL>
これは、非常に長い入力ラインの例です。このドキュメントがいくつかのテキストにまたがっていることを示しているにもかかわらず、その中には（最後に）1つの新しいラインしかありません。<nl>
Every DAG-CAP must support the full range of DAG queries, as defined in 3.3.1.
すべてのDAG-CAPは、3.3.1で定義されているように、DAGクエリの全範囲をサポートする必要があります。
Each DAG-CAP accepts queries in its native protocol. Individual DAG-CAP definitions define the expected expression of the DAG queries in the native protocol.
各DAG-CAPは、ネイティブプロトコルのクエリを受け入れます。個々のDAG-CAP定義は、ネイティブプロトコルのDAGクエリの予想される式を定義します。
The DAG-CAP is then responsible for:
Dag-Capは次の責任を負います。
- converting that expression into a query in the DAG/IP to obtain relevant referrals from the Referral Index. This might mean that parts of the original query are disregarded (e.g., if the query included attributes not supported by the DAG application, or if the query algebra was not supported by the DAG application); - returning referrals in the client's native protocol, where possible; - expressing the client query to the necessary DAG-SAPs, given the limitations mentioned above, to chain those referrals not usefully expressible in the client's native protocol; - possibly doing post-filtering on the DAG-SAP results; and - converting the collected DAG-SAP results for expression in the client's native protocol (and schema, where applicable).
- その式をDAG/IPのクエリに変換して、紹介インデックスから関連する紹介を取得します。これは、元のクエリの一部が無視されていることを意味する場合があります（たとえば、クエリにDAGアプリケーションでサポートされていない属性が含まれている場合、またはクエリ代数がDAGアプリケーションによってサポートされていない場合）。 - 可能であれば、クライアントのネイティブプロトコルで紹介を返します。 - 上記の制限を考慮して、クライアントのネイティブプロトコルで有用に表現できない紹介をチェーンするために、クライアントのクエリを必要なDAG-SAPSに表現する。 - おそらく、DAG-SAPの結果についてフィルタリング後に行う可能性があります。および - クライアントのネイティブプロトコル（および該当する場合、スキーマ）での発現のために収集されたDAG -SAP結果を変換します。
Each DAG-CAP defines the nature of the interaction with the end-user (e.g., synchronous or asynchronous, etc). Additionally, each DAG-CAP must be able to carry out the following, in order to permit load-limiting and load-balancing in the DAG system:
各DAG-CAPは、エンドユーザーとの相互作用の性質を定義します（例：同期または非同期など）。さらに、DAGシステムでの負荷制限と負荷分散を可能にするために、各DAG-CAPが以下を実行できる必要があります。
- direct the client to a different DAG-CAP of the same type (for load-balancing)
- クライアントを同じタイプの別のダグキャップに誘導します（ロードバランスのため）
- decline to return results because too many referrals were generated (to discourage data-mining). Ideally, this should include the generation of a message to refine the query in order to produce a more manageable number of referrals/replies.
- あまりにも多くの紹介が生成されたため（データマイニングを阻止するため）、結果を返すことを拒否します。理想的には、これには、より管理しやすい数の紹介/返信を生成するために、クエリを改良するメッセージの生成を含める必要があります。
DAG-CAPs must be capable of accepting and respecting DAG-SAP service referrals (for DAG-SAP load-sharing).
DAG-CAPSは、DAG-SAPサービスの紹介を受け入れ、尊重することができなければなりません（DAG-SAPロードシェアリングの場合）。
In protocols that permit it, the DAG-CAP should indicate to the end-user which services were unavailable for chaining referrals (i.e., to indicate there were parts of the search that could not be completed, and information might be missing).
それを許可するプロトコルでは、DAG-CAPはエンドユーザーに、紹介をチェックするためにどのサービスが利用できなかったかを示す必要があります（つまり、検索の一部が完了できないことを示し、情報が欠落している可能性があります）。
TISDAG: Any CAP that receives commands other than queries, like help, answers those on its own. A CAP should not pass any system command on to the RI.
TisDag：ヘルプなどのクエリ以外のコマンドを受け取るキャップは、それ自体で答えます。キャップは、システムコマンドを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-SAPSにアクセスする必要があるDAG-CAPSの場合、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
- 連絡するために必要なすべてのプロトコルの少なくとも1つの既知のDAG-SAP-各DAG-SAP、DAG-SAPソフトウェアのホストとポートについて
The DAG-CAPs must also be configurable in terms of a maximum number of referrals to handle for a user transaction (i.e., to prevent data mining, the DAG-CAP will refuse to reply if the query is too general and too many hits are generated at the Referral Index).
DAG-CAPSは、ユーザートランザクションの処理に最大数の紹介数に関して構成可能である必要があります（つまり、データマイニングを防ぐために、DAG-CAPはクエリが一般的すぎて生成されすぎる場合に返信を拒否します。紹介インデックスで）。
The DAG-CAP must be configurable in terms of alternate DAG-CAPs of the same type to which the end-user software may be directed if this one is too busy.
DAG-CAPは、これが忙しすぎる場合、エンドユーザーソフトウェアが指示されるのと同じタイプの代替DAGキャップの観点から構成可能でなければなりません。
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またはより多くのダグサップ）。
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が複数のエラーコードをユーザーに単一の式に結合する必要がある場合もあります。DAG-CAPがDAG-SAPSを介して1つ以上のWDSPにクエリを「チェーン」している場合、DAG-SAPからの応答が混在すると状況が発生する可能性があります。これが発生した場合、DAG-CAPは、可能な限り具体的なエンドユーザーソフトウェアに情報を転送しようとする必要があります。たとえば、WDSPのどれがクエリを満たしていないかなどです。
See Appendix D for more information concerning error condition message mappings.
エラー条件メッセージマッピングに関する詳細については、付録Dを参照してください。
Since there is no perfect match between the query syntaxes of the DAG system on one hand and the different access protocols that the DAG-CAPs and DAG-SAPs supports on the other, there will be situations where the results a DAG-CAP has to collect is "broader" then what would have been the case if there had been a perfect match. This might have adverse effects on the system to the extent that administrative limits will "unnecessary" be exceeded on WDSPs or that the collected results exceeds the sizelimit of the DAG-CAP.
一方のDAGシステムのクエリ構文と、他方ではDAGキャップとDAGサップがサポートするさまざまなアクセスプロトコルとの間に完全な一致がないため、DAG-CAPが収集しなければならない結果がある状況があります「より広い」、完璧なマッチがあったらどうだったでしょう。これは、管理制限がWDSPで「不必要」を超えるか、収集された結果がDAG-CAPのサイズを超える程度まで、システムに悪影響を与える可能性があります。
Since the DAG-CAP is the only part of the DAG system that actually knows what the original query was, the DAG-CAP can prune the results received from the DAG-SAPs in such a way that the results presented to the client better matches the original question.
DAG-CAPは、元のクエリが実際に何であるかを実際に知っているDAGシステムの唯一の部分であるため、DAG-CAPは、クライアントに提示された結果がよりよく一致するような方法で、DAG-SAPから受け取った結果をプルネーできます。元の質問。
Every DAG-SAP must support the full range of DAG queries, as defined in 3.3.1. Results must be complete DAG schemas expressed in well-formed DAG/IP result formats (see Appendix C). Each DAG-SAP accepts queries in DAG/IP and converts them to the native schema and protocol for which it is designed to proxy.
すべてのDAG-SAPは、3.3.1で定義されているように、DAGクエリの全範囲をサポートする必要があります。結果は、よく形成されたDAG/IP結果形式で表される完全なDAGスキーマでなければなりません（付録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.
- クエリを、紹介ポイントのWDSPのネイティブスキーマとプロトコルに変換します。（ネイティブプロトコルでクエリが表現できない場合は、エラーメッセージを返す必要があります。エミュラト可能な場合、DAG-SAPは、関連するクエリをWDSPに提起し、受信した結果を開始することでエミュレートすることができます）; - 紹介で提供されるホスト、ポート、およびプロトコル情報を使用して、そのWDSPに連絡します。 - リモートWDSPでクエリを交渉します。-WDSPの結果を受け入れ、結果セットでフィルタリング後に行う可能性があります。および - 結果を、DAG/IPとそのスキーマを使用して、呼び出しのDAG -CAPに戻します。
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-SAPSは、認識された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-SAPSは、必要に応じて同じタイプのDAG-SAPSに代替するDAG-CAPSをリダイレクトするために構成可能でなければなりません。
A DAG-SAP must translate error codes received from a WDSP server to DAG error codes according to Appendix D.
DAG-SAPは、付録Dに従って、WDSPサーバーから受信したエラーコードをDAGエラーコードに変換する必要があります。
Since it might not be possible to exactly map a DAG query into a query in the access protocol supported by the a DAG-SAP, the DAG-SAP should try to translate it into a more general query (or if necessary into a set of queries). If so, the DAG-SAP must then prune the result set received before furthering it to the DAG-CAP.
DAGクエリをA 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
the resulting search constraint for "fn=leslie" will be "exact" while it for "org=think" will be "substring".
「fn = leslie」の結果の検索制約は「正確」になり、「org = think」の「サブストリング」になります。
The Referral Index contains (only) information necessary to deliver referrals to DAG-CAPs based on the query types supported by the DAG itself. The Referral Index creates an index over these objects so that it can respond to DAG-CAP queries using the DAG/IP. The information is drawn directly from interactions with participating WDSPs' software, using the Common Indexing Protocol (CIP).
紹介インデックスには、DAG自体によってサポートされているクエリタイプに基づいて、DAG-CAPSへの紹介を提供するために必要な（のみ）情報が含まれています。紹介インデックスは、これらのオブジェクト上にインデックスを作成し、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システムに参加したいWDSPは、自分自身を登録する必要があります（セクション5.4.6を参照）。登録されると、紹介インデックスは、セクション5.4.3で定義されたインデックスオブジェクトを使用して、[1]で定義されている共通インデックスプロトコルを使用してWDSPと相互作用します。
The CIP index object type is based on the Tagged Index Object as defined in [12]. Appendix E details the expected content of the index objects as they are to be provided by the WDSPs.
CIPインデックスオブジェクトタイプは、[12]で定義されているタグ付きインデックスオブジェクトに基づいています。付録Eは、WDSPによって提供されるインデックスオブジェクトの予想されるコンテンツの詳細を示しています。
TISDAG: The tokens in the Tagged Index Object should be UTF-8 encoded composed UNICODE version 2 character encoding.
TISDAG：タグ付きインデックスオブジェクトのトークンは、UTF-8エンコードされたUnicodeバージョン2文字エンコードである必要があります。
The Referral Index interacts with the rest of the DAG internal modules (DAG-CAPs) by listening for queries and responding in the DAG/IP (defined in Appendix C).
紹介インデックスは、クエリを聞き、DAG/IPで応答することにより、DAG内部モジュール（DAG-CAPS）の残りの部分と相互作用します（付録Cで定義）。
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)
選択したCIPオブジェクトのセマンティクス（付録Eで定義）は、WDSPサーバーへの紹介がif（およびのみ）送信されるようなものです。
- 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.
これは、「Fred Amadeus Flintstone」のレコードを持つサーバーへの紹介を「Fred Amadeus Flintstone」の照会で紹介することを意味しますが、「Fred Amadeus」の2つの異なるタグ付けされたレコードを持つWDSPには紹介されません。「ジュリー・フリントストーン」。使用されているアクセスプロトコルと元のエンドユーザークエリに応じて、「Fred Amadeus Flintstone」を使用したWDSPへの紹介は、成功した結果をもたらす可能性があります。しかし、他のWDSPが検索を成功させなかったことが知られています。つまり、紹介アプローチは偽陽性の結果をもたらす可能性がありますが、適切なWDSPを見逃すことはありません。
The Referral Index must provide the ability to register interested WDSPs, as outlined in Appendix E.
紹介インデックスは、付録Eに概説しているように、関心のあるWDSPを登録する機能を提供する必要があります。
The Referral Index must be able to configure the port for DAG/IP communications. Also, it must be configurable to recognize only registered DAG-CAPs.
紹介インデックスは、DAG/IP通信用のポートを構成できる必要があります。また、登録されたDAGキャップのみを認識するように構成可能でなければなりません。
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キャップからのみクエリを受け入れます。これにより、「サービスの拒否」攻撃タイプが削減されますが、紹介インデックスがDAG/IP（つまり、内部）プロトコルを使用しているという事実も反映しています。
The Referral Index must be able to use authenticated communication to receive data from WDSPs (see Appendix E).
紹介インデックスは、認証された通信を使用してWDSPからデータを受信できる必要があります（付録Eを参照）。
This is the default Mail DAG-CAP. More sophisticated ones could certainly be written -- e.g., for pretty-printed output, or for handling different philosophies of case-matching.
これはデフォルトのメールダグキャップです。より洗練されたものは確かに書くことができます - 例えば、かなり印刷された出力の場合、またはケースマッチングのさまざまな哲学を処理するため。
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.
メールダグキャップ入力は、広告されたメールアドレスに送信された通常のまたはMIMEエンコード（[9]および[10]および[10]]を参照）SMTPメールメッセージであると予想されます。Mail Dag-Capはメッセージを解析し、DAG検索の結果を含むMimeがエンコードされたメッセージで返信します。
One query is accepted per e-mail message -- text after a single valid query has been read is simply ignored.
1つのクエリは電子メールメッセージごとに受け入れられます - 単一の有効なクエリが読み取られた後のテキストは単に無視されます。
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
terms = n / n-l / n-o / n-o-l / r-o / r-o-l
n = n-term
n-l = ( n-term l-term / l-term n-term)
n-o = ( n-term o-term / o-term n-term )
n-o-l = ( n-term o-term l-term /
n-term l-term o-term /
l-term n-term o-term /
l-term o-term n-term /
o-term l-term n-term /
o-term n-term l-term )
r-o = ( r-term o-term / o-term r-term )
r-o-l = ( r-term o-term l-term /
r-term l-term o-term /
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
string = <US-ASCII or quoted-printable encoded
ISO-8859-1 or UTF-8 except nl and sp>
msp = 1*(sp)
sp = " "
mnl = 1*(nl)
nl = <linebreak>
The following are valid mail queries:
以下は有効なメールクエリです。
Example 1:
例1：
searchtype = <NL>
name = thinking cat<NL>
Example 2:
例2：
searchtype = exact ignore<NL>
name=thinking cat<NL>
Example 3:
例3：
role=thinking cat<NL>
org =space colonization<NL>
Example 4:
例4：
name=thinking cat <NL>
<NL>
<NL>
My signature line follows here in the most annoying
fashion <NL>
Note that the following are not acceptable queries:
以下は受け入れられないクエリではないことに注意してください。
Example 5:
例5：
searchtype= exact substring <NL>
name = thinking cat <NL>
Example 6:
例6：
name=thinking cat org= freedom fighters anonymous<NL> In Example 5, two conflicting searchtypes are given. In Example 6, no linebreak follows the n-term.
name =思考猫org = Freedom Fighters Anonymous <nl>例5には、2つの競合する検索タイプが与えられます。例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
Mail Dag-Cap入力からDAG/IPクエリ形式に翻訳する重要な要素は、DAG/IPクエリの入力項を単一のトークン要素に「トークン」することです。たとえば、Nターム
name= thinking cat<NL>
is tokenized into 2 n-tokens:
2つのn-tokenにトークン化されます：
thinking cat
考えている猫
which are then mapped into the following in the DAG/IP query (dag-n-terms):
次に、DAG/IPクエリ（DAG-N-TERMS）で以下にマッピングされます。
FN=thinking and FN=cat<NL>
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-term、l-terms、およびo-termsにも当てはまります。メール入力を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 constraints are constructed from the searchtype information in the query.
DAG/IPの制約は、クエリ内のSearchType情報から構築されます。
dag-matchtype = "search=" <matchtype> /
"search=substring" ; if matchtype not
; specified
dag-casetype = "case=ignore" / ; if casetype not
; specified or
; casetype=ignore
"case=consider" ; if casetype=sensitive
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)
This means that the relevant DAG/IP queries are formulated as one of two types:
これは、関連するDAG/IPクエリが2つのタイプのいずれかとして定式化されることを意味します。
dagip-query = ( ( ( n-query / nl-query / no-query /
nol-query ) [" and template=DAGPERSON"]":"
dag-matchtype ";" dag-casetype) /
( ( ro-query / rol-query )
[" and template=DAGORGROLE"]":"
dag-matchtype ";" dag-casetype) )
n-query = dag-n-terms nl-query = dag-n-terms " and " dag-l-terms no-query = dag-n-terms " and " dag-o-terms nol-query = dag-n-terms " and " dag-o-terms " and " dag-l-terms ro-query = dag-r-terms " and " dag-o-terms rol-query = dag-r-terms " and " dag-o-terms " and " dag-l-terms
n-query = dag-n-terms nl-query = dag-n-terms "および" dag-l-terms no-query = dag-n-terms "および" dag-o-terms nol-query = dag-n-terms "and" dag-o-terms "および" dag-l-terms ro-query = dag-r-terms "および" dag-o-terms rol-query = dag-r-terms "および" dag-o-terms "および" dag-l-terms
The examples given earlier are then translated as follows.
以前の例を次のように翻訳します。
Example 1:
例1：
FN=thinking and FN=cat:search=substring;case=ignore<NL>
Example 2:
例2：
FN=thinking and FN=cat:search=exact;case=ignore<NL>
Example 3:
例3：
ROLE=thinking and ROLE=cat and ORG=space and
ORG=colonization:search=substring;case=ignore<NL>
Querying a DAG-SAP
DAG-SAPのクエリ
In querying a DAG-SAP (irrespective of the protocol of that DAG-SAP), the DAG/IP query must include information about the target WDSP server. This information is drawn from the Referral Index SERVER-TO-ASK referral information, and is appended to the query as specified in Appendix C):
DAG-SAP（そのDAG-SAPのプロトコルに関係なく）の照会では、DAG/IPクエリには、ターゲットWDSPサーバーに関する情報を含める必要があります。この情報は、紹介インデックスサーバーからアスクへの紹介情報から引き出され、付録Cで指定されているクエリに追加されます）：
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
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 "server-info：" serverinfo nl "host-name：" hostname nl "host-port：" number nl
" Protocol: " prot nl " Source-URI: " source nl " Charset: " charset nl "# END" nl
"Protocol：" Prot nl "source-uri：" source nl "charset：" charset nl "＃end" nl
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
また、「引用されたhostname」と「Quoted-serverinfo」は、DAG/IP特殊文字を引用することにより、それぞれ「HostName」と「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>
would yield the addition
追加が得られます
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
c\=se;charset=T\.61
in its query to an LDAPv2 DAG-SAP.
ldapv2 dag-sapへのクエリで。
(N.B.: See Appendix C for further definitions of the terms used in the SERVER-TO-ASK response).
（N.B。：サーバーからアスクの応答で使用される用語のさらなる定義については、付録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、LDAPV2 DAG-SAP、またはLDAPV3 DAG-SAPにすべての紹介をチェーンする必要があります。
The results message is sent to the "Reply-To:" address of the originating mail, if available (see [4] for appropriate interpretation of mail originator headers). The original query is repeated, along with the message-id. The remainder of the body of the mail message is the concatenation of responses from the DAG-SAP calls, each result having the WDSP's SOURCE URI (from the referral) appended to it, and the system messages also having been removed.
結果メッセージは、使用可能な場合は「Reply-to」の元のメールのアドレス（[4]を参照）に送信されます（メールオリジネーターヘッダーの適切な解釈については[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情報が利用できない」メッセージを返しました）がServer-INFOにリストされています。
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.
Mail Dag-Capが上記のクエリ文法を使用して解析できないメッセージを受信した場合、クエリの返信アドレスに説明メッセージを返し、クエリを解釈できず、有効なクエリの説明を提供します。
If the number of referrals sent by the Referral Index is greater than the pre-determined maximum (for detecting data-mining efforts, or otherwise refusing over-general queries, such as "FN=svensson"), the mail DAG-CAP will send an explanatory message to the query mail's reply address describing the "over-generalized query" problem, suggesting the user resubmit a more precise query, and describing the list of valid query types.
紹介インデックスによって送信された紹介の数が事前に決定された最大値よりも大きい場合（データマイニングの取り組みを検出するため、または「FN = SVENSSON」などの将来の質問を拒否します）クエリメールの返信アドレスへの説明メッセージ「過剰なクエリ」の問題を説明し、ユーザーがより正確なクエリを再送信し、有効なクエリタイプのリストを説明することを提案します。
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.
Mail Dag-CapがDag-Sapsからいくつかの異なる結果コードを受信した場合、応答メッセージで適切な方法でそれらを表す必要があります。
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.
メールダグキャップは、ロードバランスの理由から、別のメールダグキャップへの接続をリダイレクトする場合があります。これは、メールクエリを代替メールダグキャップのアドレスに転送するだけで行われます。
The web DAG-CAP provides its interface via standard HTTP protocol. The general expectation is that the web DAG-CAP will provide a form page with radio buttons to select "substring or exact match" and "consider case or ignore case". Other information (about name, role, organization, locality) is solicited as free-form text.
Web Dag-Capは、標準のHTTPプロトコルを介してインターフェイスを提供します。一般的な期待は、Web Dag-Capがラジオボタンを備えたフォームページを提供して、「サブストリングまたは正確な一致」および「ケースを検討するか、ケースを無視する」を選択することです。その他の情報（名前、役割、組織、地域に関する）は、自由形式のテキストとして求められます。
The DAG-CAP receives queries via an HTTP "post" method (the outcome of the form action for the page described above, or generated elsewhere). The rest of this section describes the variables that are to be expressed in that post. The actual layout of the page and most user interface issues are left to the discretion of the builder. Note that the Web DAG-CAP may be called upon to provide responses in different content encoding, and must therefore address the "Accept-Encoding:" request header in the HTTP connection.
DAG-CAPは、HTTP「POST」メソッド（上記のページのフォームアクションの結果、または他の場所で生成されたフォームアクションの結果）を介してクエリを受け取ります。このセクションの残りの部分では、その投稿で表現される変数について説明します。ページの実際のレイアウトとほとんどのユーザーインターフェイスの問題は、ビルダーの裁量に任されています。Web Dag-Capは、異なるコンテンツエンコードで応答を提供するために呼び出される場合があるため、「Accept-Encoding：」にHTTP接続のヘッダーを要求する必要があることに注意してください。
Although the Web protocol, HTTP, is not itself capable of handling referrals, through the use of two extra variables this client is given the option of requesting referral information and then pursuing individual referrals through the Web DAG-CAP itself, as a proxy for those referrals. This is handled through the extra "control variables" to request referrals only, and to indicate when the transaction is a continuation of a previous query to pursue a referral.
WebプロトコルであるHTTPは、2つの追加変数を使用して紹介を処理することはできませんが、このクライアントには紹介情報を要求し、Web Dag-Cap自体を介して個々の紹介を追求するオプションが与えられます。紹介。これは、紹介のみを要求するために、余分な「制御変数」を介して処理され、トランザクションが紹介を追求するための以前のクエリの継続であることを示すために処理されます。
There has been call to have a "machine-readable" version of the search output. As HTML is geared towards visual layout, user agents that intend to do something with the results other than present them in an HTML browser have few cues to use to extract the relevant information from the HTML page. Also, "minor" visual changes, accomplished with extensive HTML updates, can disrupt user agents that were built to blindly parse the original HTML. Therefore, provision has been made to return "raw" format results. These are requested by specifying "Accept-Content: application/whoispp-response" in the request header of the HTTP message to the HTTP DAG-CAP.
検索出力の「マシン読み取り可能な」バージョンを持つように呼びかけられています。HTMLは視覚レイアウトに向けられているため、HTMLブラウザで提示する以外の結果で何かを行うことを意図しているユーザーエージェントは、HTMLページから関連情報を抽出するために使用する手がかりがほとんどありません。また、広範なHTMLアップデートで達成された「マイナーな」視覚的変更は、元のHTMLを盲目的に解析するために構築されたユーザーエージェントを混乱させる可能性があります。したがって、「生」形式の結果を返すための規定がなされています。これらは、HTTPメッセージのリクエストヘッダーにHTTP DAG-CAPに「Accept-Content：Application/WhoISPP Response」を指定することによって要求されます。
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>
Querying a DAG-SAP Directly
DAG-SAPを直接照会します
If the transaction variable is "chain", the information in the POST is used to pursue a particular referral, not do a search of the Referral Index. The appropriate DAG-SAP (deduced from the prot-term) is contacted and issued the query directly.
トランザクション変数が「チェーン」の場合、投稿内の情報は特定の紹介を追求するために使用され、紹介インデックスを検索しません。適切なDAG-SAP（PROT-TEMERから推定）に連絡し、クエリを直接発行します。
Results from this type of query are always full results (i.e., not referrals).
このタイプのクエリの結果は、常に完全な結果です（つまり、紹介ではありません）。
Querying the Referral Index
紹介インデックスのクエリ
A key element of translating from the Web DAG-CAP input into the DAG/IP query format is to "tokenize" the input terms into single token elements for the DAG/IP query. For example, the n-term
Web DAG-CAP入力からDAG/IPクエリ形式に翻訳する重要な要素は、DAG/IPクエリの入力項を単一のトークン要素に「トークン」することです。たとえば、Nターム
name= thinking cat
名前=猫を思う
is tokenized into 2 n-tokens:
2つのn-tokenにトークン化されます：
thinking cat
考えている猫
which are then mapped into the following in the DAG/IP query (dag-n-terms):
次に、DAG/IPクエリ（DAG-N-TERMS）で以下にマッピングされます。
FN=thinking and FN=cat The same is true for the r-term, l-term and o-term.
fn =思考とfn = cat同じことは、r期間、l項、およびo-タームに当てはまります。
The primary steps in translating the HTTP input into a DAG/IP query are:
HTTP入力をDAG/IPクエリに変換する主な手順は次のとおりです。
translate encodings, if necessary tokenize the strings for each term construct the DAG/IP query from the resulting components, as described in more detail below
エンコーディングを翻訳します。必要に応じて、各用語の文字列をトークン化して、以下の詳細について説明するように、結果のコンポーネントからDAG/IPクエリを構築します
DAG/IP constraints are constructed from the searchtype information in the query.
DAG/IPの制約は、クエリ内のSearchType情報から構築されます。
dag-matchtype = "search=" <matchtype> /
"search=substring" ; if matchtype not
; specified
dag-casetype = "case=ignore" / ; if casetype not
; specified or
; casetype="case ignore"
"case=consider" ; if casetype=
; "case sensitive"
constraints = ":" dag-matchtype ";" dag-casetype
The terms for the DAG/IP query are constructed from the tokenized strings from the HTTP post input.
DAG/IPクエリの用語は、HTTP Post入力からのトークン化された文字列から構築されます。
dag-n-terms = "FN=" n-token 0*( " and FN=" n-token)
dag-o-terms = "ORG=" o-token 0*( " and ORG=" o-token)
dag-l-terms = "LOC=" l-token 0*( " and LOC=" l-token)
dag-r-terms = "ROLE=" r-token 0*( " and ROLE=" r-token)
This means that the relevant DAG/IP queries are formulated as one of two types:
これは、関連するDAG/IPクエリが2つのタイプのいずれかとして定式化されることを意味します。
dagip-query = ( ( ( n-query / nl-query / no-query / nol-query )
[" and template=DAGPERSON"]":" dag-matchtype
";" dag-casetype) /
( ( ro-query / rol-query )
[" and template=DAGORGROLE"]":" dag-matchtype
";" dag-casetype) )
n-query = dag-n-terms nl-query = dag-n-terms " and " dag-l-terms no-query = dag-n-terms " and " dag-o-terms nol-query = dag-n-terms " and " dag-o-terms " and " dag-l-terms ro-query = dag-r-terms " and " dag-o-terms rol-query = dag-r-terms " and " dag-o-terms " and " dag-l-terms
n-query = dag-n-terms nl-query = dag-n-terms "および" dag-l-terms no-query = dag-n-terms "および" dag-o-terms nol-query = dag-n-terms "and" dag-o-terms "および" dag-l-terms ro-query = dag-r-terms "および" dag-o-terms rol-query = dag-r-terms "および" dag-o-terms "および" dag-l-terms
Querying a DAG-SAP
DAG-SAPのクエリ
In querying a DAG-SAP (irrespective of the protocol of that DAG-SAP), the DAG/IP query must include information about the target WDSP server. This information is drawn from the Referral Index SERVER-TO-ASK referral information, and is appended to the query as specified in Appendix C:
DAG-SAP（そのDAG-SAPのプロトコルに関係なく）の照会では、DAG/IPクエリには、ターゲットWDSPサーバーに関する情報を含める必要があります。この情報は、紹介インデックスサーバーからアスクへの紹介情報から引き出され、付録Cで指定されているクエリに追加されます。
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
where the response from the Referral Index included:
紹介インデックスからの応答が含まれる場合：
"# SERVER-TO-ASK " serverhandle <NL>
" Server-info: " serverinfo <NL>
" Host-Name: " hostname <NL>
" Host-Port: " number <NL>
" Protocol: " prot <NL>
" Source-URI: " source <NL>
" Charset: " charset <NL>
"# END" <NL>
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
また、「引用されたhostname」と「Quoted-serverinfo」は、DAG/IP特殊文字を引用することにより、それぞれ「HostName」と「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>
would yield the addition
追加が得られます
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
c\=se;charset=T\.61
in its query to an LDAPv2 DAG-SAP
ldapv2 dag-sapへのクエリで
(N.B.: See Appendix C for further definitions of the terms used in the SERVER-TO-ASK response).
（N.B。：サーバーからアスクの応答で使用される用語のさらなる定義については、付録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-SAPSを使用してチェーンされます。紹介のみが要求された場合、紹介インデックスの結果が返されます。
text/html results
テキスト/HTMLの結果
The default response encoding is text/html. If the resulttype was "all", the content of the chaining responses from the DAG-SAPs, without the system messages, is collated into a single page response, one result entry per demarcated line ( e.g., bullet item). The FN or ROLE value should be presented first and clearly. The SOURCE URI for each WDSP referral should be presented as an HREF for each of the WDSPs results.
デフォルトの応答エンコーディングはText/HTMLです。resultTypeが「すべて」である場合、システムメッセージなしでDAG-SAPSからのチェーン応答のコンテンツは、単一のページ応答に照合され、境界線ごとに1つの結果エントリ（例：弾丸項目）に照合されます。FNまたはロール値は、最初に明確に提示する必要があります。各WDSP紹介のソースURIは、各WDSPの結果のHREFとして提示する必要があります。
At the end of the message, the WDSP servers that failed to respond (i.e., the DAG-SAP handling the referral returned the "% 403 Information Unavailable" message) are listed with their server-info.
メッセージの最後に、応答に失敗したWDSPサーバー（つまり、紹介を処理するDAG-SAPが「％403情報が利用できない」メッセージを返しました）がServer-INFOにリストされています。
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 =」などを含む必要な情報を使用して、Web Dag-Cap自体のHREF URLとして返されます。紹介）。
For example, if the original query:
たとえば、元のクエリの場合：
n-term="thinking cat" resulttype="referrals"
n-Term = "思考猫" resultType = "referrals"
drew the following referral from the Referral Index:
紹介インデックスから次の紹介を描きました。
# SERVER-TO-ASK DAG-Serverhandle<NL>
Server-Info: c=se, o=tce<NL>
Host-Name: answers.tce.com<NL>
Host-Port: 1111<NL>
Protocol: ldapv3<NL>
Source-URI: http://some.service.se/
Charset: UTF-8<NL>
# END<NL>
the response would be an HTML page with an HREF HTTP "POST" URL to the Web DAG-CAP with the following variables set:
応答は、次の変数を設定して、href http "post" urlをWeb Dag-capに備えたHTMLページになります。
n-term="thinking cat"
transaction="chain"
servinfo-term="c=se, o=tce"
host-term="answers.tce.com"
port-term="1111"
prot-term="ldapv3"
The Source-URI should be established in the response as its own HREF URI.
Source-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.
Accept-Encoding：「HTTPリクエストヘッダーに値」アプリケーション/WHOISPP応答」の場合、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が「紹介」である場合、すべての紹介は単一の応答で直接渡されます。これには、LDAPベースのサービスとWHOISサーバーへの紹介が含まれることに注意してください。
A Web DAG-CAP may redirect a connection to another web DAG-CAP for reasons of load-balancing. This is done simply by using an HTTP redirect.
Web Dag-Capは、ロードバランスの理由から、別のWeb Dag-Capへの接続をリダイレクトする場合があります。これは、HTTPリダイレクトを使用するだけで行われます。
Standard Errors
標準エラー
If the web DAG-CAP receives a message that is not parsable using the query grammar described above, it sends an explanatory HTML page saying that the query could not be interpreted, and giving a description of valid queries.
Web Dag-Capが上記のクエリ文法を使用して解析できないメッセージを受信した場合、クエリを解釈できず、有効なクエリの説明を提供する説明HTMLページを送信します。
If the number of referrals sent by the Referral Index is greater than the pre-determined maximum (for detecting data-mining efforts, or otherwise refusing over-general queries, such as "FN=svensson"), the web DAG-CAP will send a page with an explanatory message describing the "over-generalized query" problem, suggesting the user resubmit a more precise query, and describing the list of valid query types.
紹介インデックスによって送信された紹介の数が事前に決定された最大値よりも大きい場合（データマイニングの取り組みを検出する場合、または「FN = SVENSSON」などの将来の質問を拒否します）「過剰なクエリ」の問題を説明する説明メッセージがあるページで、ユーザーがより正確なクエリを再送信し、有効なクエリタイプのリストを説明することを提案します。
If the web DAG-CAP receives more than one result code from the DAG-SAPs, it must represent them all in a appropriate manner in the response.
Web DAG-CAPがDAG-SAPSから複数の結果コードを受信した場合、応答で適切な方法でそれらをすべて表す必要があります。
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.
TISDAG：システムは、/-byのポーリングを指揮して、空のセットを返品値として引き出しているはずです。
Input to the Whois++ DAG-CAP follows the Whois++ standard ([6]). Minimally, the Whois++ DAG-CAP must support the following queries:
Whois dag-capへの入力は、whois標準（[6]）に従います。最終的には、WHOIS DAG-CAPは次のクエリをサポートする必要があります。
Query Type Expression in Whois++
----------- ------------------------------------
N One or more "name=" and
template=USER
NL One or more "name=" and One or more "address-locality=" and template=USER
nl 1つ以上の "name ="および1つ以上の "address-locality ="およびtemplate = user
NO One or more "name=" and one or more "organization-name=" and template=USER
1つ以上の「name = "および1つ以上の" gunital-name = "およびtemplate = user
NOL One or more "name=" and one or more "organization-name=" and one or more "address-locality=" and template=USER
nol 1つ以上の「name = "および1つ以上の" gunitagle-name = "および1つ以上の" dresder-locality = "およびtemplate = user
RO One or more "org-role=" and one or more "organization-name=" and template=ORGROLE
RO 1つ以上の「org-role = "および1つ以上の" gurations-name = "およびtemplate = orgrole
ROL One or more "org-role=" and one or more "organization-name=" and one or more "address-locality=" and template=ORGROLE
1つ以上の「org-role = "および1つ以上の「組織」」="および1つ以上の "address-locality ="およびtemplate = 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>
is a perfectly valid Whois++ NL query for "Foo Bar" in "Kista".
「Kista」の「Foo Bar」の完全に有効なWHOIS NLクエリです。
Querying the Referral Index
紹介インデックスのクエリ
The Whois++ DAG-CAP formulates a DAG/IP query by forwarding the search terms received (as defined in Table 5.1).
WHOIS DAG-CAPは、受信した検索用語を転送することにより、DAG/IPクエリを定式化します（表5.1で定義）。
For example, the above query would be expressed as:
たとえば、上記のクエリは次のように表現されます。
FN=foo and LOC=kista and FN=bar and template=DAGPERSON<NL>
Querying a DAG-SAP
DAG-SAPのクエリ
In querying a DAG-SAP (irrespective of the protocol of that DAG-SAP), the DAG/IP query must include information about the target WDSP server. This information is drawn from the Referral Index SERVER-TO-ASK referral information, and is appended to the query as specified in appendix C:
DAG-SAP（そのDAG-SAPのプロトコルに関係なく）の照会では、DAG/IPクエリには、ターゲットWDSPサーバーに関する情報を含める必要があります。この情報は、紹介インデックスサーバーからアスクへの紹介情報から引き出され、付録Cで指定されているクエリに追加されます。
":host=" quoted-hostname ";port=" number ";server-info=" quoted-serverinfo ";charset=" charset where the response from the Referral Index included:
"：host =" quoted-hostname "; port =" number "; server-info =" quoted-serverinfo "; charset =" 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>
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
また、「引用されたhostname」と「Quoted-serverinfo」は、DAG/IP特殊文字を引用することにより、それぞれ「HostName」と「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>
would yield the addition
追加が得られます
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
c\=se;charset=T\.61
in its query to an LDAPv2 DAG-SAP.
ldapv2 dag-sapへのクエリで。
(N.B.: See Appendix C for further definitions of the terms used in the SERVER-TO-ASK response).
（N.B。：サーバーからアスクの応答で使用される用語のさらなる定義については、付録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は、DAG-SAPSに依存して、非Whois紹介（現在、LDAPV2およびLDAPV3 DAG-SAPS）をチェーンしています。
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-SAPSから受信したDAG/IPの結果を（完全な応答を使用して）照合し、付録Bで定義されているテンプレートと属性マッピングを使用してWHOISで表現されます。特定の紹介から結果について、ソース属性が追加されます。紹介からの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>
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、ホスト、ポート、プロトコルは、DAG/IPで提供される紹介から引き出され、ソース-URI情報が失われます。
As appropriate, the Whois++ DAG-CAP will express operational errors following the Whois++ standard. There are 4 particular error conditions of the DAG system that the DAG-CAP will handle as described below.
必要に応じて、WHOIS DAG-CAPは、WHOIS標準に続いて運用上のエラーを表します。以下に説明するように、DAGキャップが処理するDAGシステムには4つの特定のエラー条件があります。
When the Whois++ DAG-CAP receives a query that it cannot reply to within the (data) constraints of the DAG, it sends an error message and closes the connection. The error message includes
WHOIS DAG-CAPがDAGの（データ）制約内で返信できないクエリを受信すると、エラーメッセージが送信され、接続を閉じます。エラーメッセージには含まれます
% 502 Search expression too complicated<NL>
％502検索式が複雑すぎる<nl>
If the number of referrals sent by the Referral Index is greater than the pre-determined maximum (for detecting data-mining efforts, or otherwise refusing over-general queries, such as "FN=svensson"), the Whois++ DAG-CAP will send an error message and close the connection. The error message includes
紹介インデックスによって送信された紹介の数が事前に決定された最大値よりも大きい場合（データマイニングの取り組みを検出するため、または「FN = SVENSSON」などの将来の質問を拒否する場合）エラーメッセージと接続を閉じます。エラーメッセージには含まれます
% 503 Query too general<NL>
％503クエリも一般的な<nl>
(N.B.: this is different from the "Too many hits" reply, which does send partial results.) A Whois++ DAG-CAP may redirect a connection to another Whois++ DAG-CAP for reasons of load-balancing. This is expressed to the end-user client software using the SERVER-TO-ASK response with appropriate information to reach the designated alternate DAG-CAP.
（N.B。：これは、「ヒットが多すぎる」返信とは異なります。これは部分的な結果が送信されます。）Whois dag-capは、負荷分散の理由で他のWhois dag-capへの接続をリダイレクトする場合があります。これは、指定された代替DAGキャップに到達するための適切な情報を使用して、サーバーからアスクの応答を使用してエンドユーザークライアントソフトウェアに表現されます。
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-SAPSからいくつかの異なる応答コードを受け取った場合、エンドユーザークライアントへの応答でそれらすべてを表すようにする必要があります。
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への入力は、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.、これは、基本的なダグ定義クエリを実現するためのサポートされているクエリの最小限のセットです。LDAP DAG-CAPは、DAG/IPからLDAPV2クライアントへの翻訳を行うと、これらのクエリのセマンティクスに応答する方法で翻訳を行う場合、これよりも複雑なクエリをサポートすることを選択できます。
TISDAG: Since LDAPv2 didn't specify any characterset but relied on X.500 to do so, in practice several different charactersets are in use in Sweden today. That the LDAPv2 CAP has no way of knowing which characterset that are in use by a connecting client is a problem that the TISDAG project can not solve.
TISDAG：LDAPV2はキャラクターセットを指定していませんでしたが、X.500に依存しているため、実際にはスウェーデンでいくつかの異なるキャラクターが使用されています。LDAPV2キャップには、接続クライアントが使用しているキャラクターセットが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.
LDAPクエリをDAG/IP紹介インデックスクエリにマッピングするための重要な層は、文字列指向のLDAP属性属性またはサブストリングフィルターをトークン化し、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-TermとObjectClassの仕様が含まれている場合、検索が人または役割のかどうかは不明です。これが発生すると、DAGクエリはすべてのベースをカバーし、クエリを人と役割の両方のクエリにマッピングする必要があります。
EqualityMatch queries can be handled by simply tokenizing the AttributeValueAssertions, making one DAG/IP query term per token (using the appropriate DAGSchema attribute) and carrying out an exact match in the DAG/IP.
equalityMatchクエリは、属性想像力をトークン化し、トークンごとに1つのDAG/IPクエリ項（適切なDagschema属性を使用）を作成し、DAG/IPで正確な一致を実行するだけで処理できます。
Consider the following example, represented in the ASCII expression of LDAP Filters as described in [13]):
[13]で説明されているように、LDAPフィルターのASCII式に表される次の例を考えてみましょう。
(& (cn=Foo Bar)(objectclass=inetOrgPerson))
This query can be represented in the DAG/IP as
このクエリは、dag/ipで表すことができます
FN="Foo" and FN="Bar":search=exact<NL>
N.B. The search is set up to be "case=ignore" (the DAG/IP's default) because the relevant LDAP schema attributes are all derivatives of the "name" attribute element, which is defined to have a case insensitive match.
N.B.検索は、関連するLDAPスキーマ属性がすべて「名前」属性要素の派生物であり、ケースの不屈の一致を持つように定義される「dag/ipのデフォルト）になるように設定されます。
If no objectclass were defined the query in DAG/IP would have been
ObjectClassが定義されていない場合、DAG/IPのクエリは
(FN="Foo" and FN="bar") or (ROLE="Foo" and ROLE="bar"):search=exact inetOrgPerson is used as the objectclass in this and the following examples, although person or organizationalPerson could also have been used.
（fn = "foo"およびfn = "bar"）または（role = "foo"およびrole = "bar"）：search =正確な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.
このクエリは、偽陽性の紹介をもたらします。元のLDAPクエリは、「CN」属性が正確に「Foo Bar」というフレーズであるレコードと一致する必要がありますが、DAG/IPクエリは、2つのトークン「Foo」と「Bar」を含むレコードを含むWDSPを紹介します。任意の順序で。
For example, this DAG/IP query will yield referrals to WDSPs with records including:
たとえば、このDAG/IPクエリは、以下を含むレコードを含むWDSPへの紹介をもたらします。
cn: Bar Foo cn: Le Bar Foo cn: Foo Bar AB
CN：bar foo cn：le bar foo cn：foo bar ab
LDAP substring queries must also be tokenized in order to construct a DAG/IP query. The additional point to bear in mind is that LDAP substring expressions are directed at phrases, which obscure potential token boundaries. Consequently, all points between substring components must be considered as potential token boundaries.
LDAPサブストリングクエリも、DAG/IPクエリを作成するためにトークン化する必要があります。心に留めておくべき追加のポイントは、LDAPサブストリング式がフレーズに向けられており、潜在的なトークン境界を曖昧にするということです。したがって、サブストリング成分間のすべてのポイントは、潜在的なトークン境界と見なす必要があります。
Thus, the LDAP query
したがって、LDAPクエリ
(& (cn=black) (o=c*t) (objectclass=inetOrgPerson))
could be expressed as a DAG/IP query with 3 tokens, in a substring search:
サブストリング検索で、3つのトークンを備えたDAG/IPクエリとして表現できます。
FN=black and ORG=c and ORG=t:search=substring<NL>
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
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))
can be expressed as
として表現できます
FN=Foo and FN=Bar and ORG=c and ORG=t:search=substring<NL>
Alternatively, the LDAP DAG-CAP could conduct two separate queries and take the intersection (the logical "AND") of the two sets of referrals returned by the Referral Index.
あるいは、LDAP DAG-CAPは2つの個別のクエリを実行し、紹介インデックスによって返された2つの紹介の交差点（論理 "および"）を取得することができます。
Note that DAG/IP can accept phrases for searches -- the query
DAG/IPは検索のフレーズを受け入れることができることに注意してください - クエリ
FN=Foo\ bar<NL> (note the escaped space)
is perfectly valid. However, it would match only those things which have been tokenized in a way that preserves the space, which is the empty set in the case of the data stored here.
完全に有効です。ただし、ここに保存されているデータの場合には空のセットであるスペースを保存する方法でトークン化されたものだけが一致します。
Querying a DAG-SAP
DAG-SAPのクエリ
It is never invalid to use the same substantive query to a DAG-SAP as was used to obtain referral information from the Referral Index. However, the over-generalization of these queries may yield excessive numbers of results, and will necessitate some pruning of results in order to match the returned results against the semantics of the original LDAP query. It is the LDAP DAG-CAP that is responsible for this pruning, as it is the recipient of the original query, and responsible for responding to its semantics.
紹介インデックスから紹介情報を取得するために使用されたのと同じ実質的なクエリをDAG-SAPに使用することは無効ではありません。ただし、これらのクエリの過剰な一般化により、過剰な数の結果が得られる可能性があり、元のLDAPクエリのセマンティクスと返された結果を一致させるために、結果の剪定が必要になります。これは、元のクエリの受信者であり、そのセマンティクスへの応答を担当するため、この剪定に責任があるLDAP DAG-CAPです。
In concrete terms, when making the DAG/IP query which is to be sent to a DAG-SAP the above mentioned queries are still valid queries, but an alternative finer-grained query is also possible, namely:
具体的に言えば、DAG/IPクエリをDAG-SAPに送信する場合、上記のクエリは依然として有効なクエリですが、代替のより細かいクエリも可能です。
FN=foo and FN=bar and ORG=c;search=lstring and ORG=t;search=tstring
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を使用する原因があります。これらのダグサップはフレーズ指向のデータも扱っているため、一般化されていないクエリを渡すことができます。
FN=Foo\ Bar:search=exact<NL> In querying a DAG-SAP (irrespective of the protocol of that DAG-SAP), the DAG/IP query must include information about the target WDSP server. This information is drawn from the Referral Index SERVER-TO-ASK referral information, and is appended to the query as specified in Appendix C:
fn = foo \ bar：検索=正確<nl> dag-sapを照会する際（そのdag-sapのプロトコルに関係なく）、dag/ipクエリにはターゲットWDSPサーバーに関する情報を含める必要があります。この情報は、紹介インデックスサーバーからアスクへの紹介情報から引き出され、付録Cで指定されているクエリに追加されます。
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
where the response from the Referral Index included:
紹介インデックスからの応答が含まれる場合：
"# SERVER-TO-ASK " serverhandle<NL>
" Server-info: " serverinfo<NL>
" Host-Name: " hostname<NL>
" Host-Port: " number<NL>
" Protocol: " prot<NL>
" Source-URI: " source<NL>
" Charset: " charset<NL>
"# END<NL>
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
また、「引用されたhostname」と「Quoted-serverinfo」は、DAG/IP特殊文字を引用することにより、それぞれ「HostName」と「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>
would yield the addition
追加が得られます
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
c\=se;charset=T\.61
in its query to an LDAPv2 DAG-SAP.
ldapv2 dag-sapへのクエリで。
(N.B.: See Appendix C for further definitions of the terms used in the SERVER-TO-ASK response).
（N.B。：サーバーからアスクの応答で使用される用語のさらなる定義については、付録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-SAPSに依存しています。
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-SAPSの結果は、元のクエリが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>
(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が使用されます。それ以外の場合は（たとえば、WHOISサーバーからのデータの場合）、合理的なファクシミリが構築されます。
As appropriate, the LDAPv2 DAG-CAP will express system responses following the LDAPv2 standard.
必要に応じて、LDAPV2 DAG-CAPは、LDAPV2標準に従ってシステム応答を表現します。
Appendix D gives the proposed mapping between DAG/IP response codes and LDAPv2 resultcodes.
付録Dでは、DAG/IP応答コードとLDAPV2 resultCodeの間に提案されたマッピングを示します。
There are 4 particular error conditions of the DAG system that the DAG-CAP will handle as described below.
以下に説明するように、DAGキャップが処理する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（誤ったスキーマ属性用）不正確化（サポートされているもの以外のマッチタイプが使用される場合、たとえば、AmproxMatchなど）Unwilltoperform（クエリが定義されたタイプの1つではない場合）
If the number of referrals sent by the Referral Index is greater than the pre-determined maximum (for detecting data-mining efforts, or otherwise refusing over-general queries, such as "FN=svensson"), the LDAPv2 DAG-CAP will send an error message. The error message includes one of the following resultCodes:
紹介インデックスによって送信された紹介の数が事前に決定された最大値よりも大きい場合（データマイニングの取り組みを検出するため、または「FN = SVENSSON」などの将来の質問を拒否します）。エラーメッセージ。エラーメッセージには、次の結果コードのいずれかが含まれています。
sizeLimitExceeded timeLimitExceeded
sizelimitex cuceed timelimitexが成功しました
An LDAPv2 DAG-CAP may redirect a connection to another LDAPv2 DAG-CAP for reasons of load-balancing. This is expressed to the end-user client software using the "umich referral" convention to direct the client software to an alternate DAG-CAP by passing the URL in an error message.
LDAPV2 DAG-CAPは、負荷分散の理由で別のLDAPV2 DAG-CAPへの接続をリダイレクトする場合があります。これは、「UMICH紹介」条約を使用してエンドユーザークライアントソフトウェアに表明され、クライアントソフトウェアをエラーメッセージに渡すことにより、クライアントソフトウェアを代替DAGキャップに導きます。
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つの結果コードをクライアントに送信できるためです。LDAPV2 DAG-CAPがDAG-SAPSからいくつかの異なる結果コードを受信した場合、それらの組み合わせをある程度表す結果の結果を構築する必要があります。これらの場合、次のアクションが取られることが提案されています。
- 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結果コードに変換されます。 - 結果コードが選択され、次の根拠で収集された応答を表します。「成功」がこれらのステップの後に表される唯一の結果コードである場合、結果コードを返します。「成功」とは別に、もう1つのresultCodeを表すもう1つの結果を表します。
If apart from "success" there are two or more resultcodes represented return the resultcode "other".
「成功」とは別に、2つ以上のresultCodeが表されている場合、結果コード「その他」を返します。
Input to the LDAPv3 DAG-CAP follows the LDAPv3 definition (currently defined in [17]). Minimally, the LDAPv3 DAG-CAP must support the following queries (adapted from the ASN.1 grammar of the standard):
LDAPV3 DAG-CAPへの入力は、LDAPV3定義に従います（現在[17]で定義されています）。最終的には、LDAPV3 DAG-CAPは、次のクエリをサポートする必要があります（標準のASN.1文法から編集）：
BindRequest ::= [APPLICATION 0] SEQUENCE {
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.、これは、基本的なダグ定義クエリを実現するためのサポートされているクエリの最小限のセットです。LDAP DAG-CAPは、DAG/IPからLDAPV3クライアントへの翻訳を行うと、これらのクエリのセマンティクスに応答する方法で翻訳を行う場合、これよりも複雑なクエリをサポートすることを選択できます。
Querying the Referral Index
紹介インデックスのクエリ
The essential stratagem for mapping LDAP queries into DAG/IP Referral Index queries is to tokenize the string-oriented LDAP AttributeValueAssertions or SubstringFilters and construct an appropriate DAG/IP token-oriented query in the DAGschema. This will generalize the LDAP query and yield false-positive referrals, but should not miss any appropriate referrals.
LDAPクエリをDAG/IP紹介インデックスクエリにマッピングするための重要な層は、文字列指向のLDAP属性属性またはサブストリングフィルターをトークン化し、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-TermとObjectClassの仕様が含まれている場合、検索が人または役割のかどうかは不明です。これが発生すると、DAGクエリはすべてのベースをカバーし、クエリを人と役割の両方のクエリにマッピングする必要があります。
EqualityMatch queries can be handled by simply tokenizing the AttributeValueAssertions, making one DAG/IP query term per token (using the appropriate DAGSchema attribute) and carrying out an exact match in the DAG/IP.
equalityMatchクエリは、属性想像力をトークン化し、トークンごとに1つのDAG/IPクエリ項（適切なDagschema属性を使用）を作成し、DAG/IPで正確な一致を実行するだけで処理できます。
Consider the following example, represented in the ASCII expression of LDAP Filters as described in [13]):
[13]で説明されているように、LDAPフィルターのASCII式に表される次の例を考えてみましょう。
(& (cn=Foo Bar)(objectclass=person))
This query can be represented in the DAG/IP as
このクエリは、dag/ipで表すことができます
FN="Foo" and FN="Bar":search=exact<NL>
N.B. The search is set up to be "case=ignore" (the DAG/IP's default) because the relevant LDAP schema attributes are all derivatives of the "name" attribute element, which is defined to have a case insensitive match.
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
Although person is used as objectclass in this and the following examples, inetOrgPerson or organizationalPerson could also have been used.
この人はこれと次の例ではオブジェクトクラスとして使用されていますが、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.
このクエリは、偽陽性の紹介をもたらします。元のLDAPクエリは、「CN」属性が正確に「Foo Bar」というフレーズであるレコードと一致する必要がありますが、DAG/IPクエリは、2つのトークン「Foo」と「Bar」を含むレコードを含むWDSPを紹介します。任意の順序で。
For example, this DAG/IP query will yield referrals to WDSPs with records including:
たとえば、このDAG/IPクエリは、以下を含むレコードを含むWDSPへの紹介をもたらします。
cn: Bar Foo cn: Le Bar Foo cn: Foo Bar AB
CN：bar foo cn：le bar foo cn：foo bar ab
LDAP substring queries must also be tokenized in order to construct a DAG/IP query. The additional point to bear in mind is that LDAP substring expressions are directed at phrases, which obscure potential token boundaries. Consequently, all points between substring components must be considered as potential token boundaries.
LDAPサブストリングクエリも、DAG/IPクエリを作成するためにトークン化する必要があります。心に留めておくべき追加のポイントは、LDAPサブストリング式がフレーズに向けられており、潜在的なトークン境界を曖昧にするということです。したがって、サブストリング成分間のすべてのポイントは、潜在的なトークン境界と見なす必要があります。
Thus, the LDAP query
したがって、LDAPクエリ
(& (cn=black) o=c*t) (objectclass=person))
should be expressed as a DAG/IP query with 3 tokens, in a substring search:
サブストリング検索で、3つのトークンを備えたDAG/IPクエリとして表現する必要があります。
FN=black and ORG=c and ORG=t:search=substring<NL>
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
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))
can be expressed as
として表現できます
FN=Foo and FN=Bar and ORG=c and ORG=t:search=substring<NL>
Alternatively, the LDAP DAG-CAP could conduct two separate queries and take the intersection (the logical "AND") of the two sets of referrals returned by the Referral Index.
あるいは、LDAP DAG-CAPは2つの個別のクエリを実行し、紹介インデックスによって返された2つの紹介の交差点（論理 "および"）を取得することができます。
Note that DAG/IP can accept phrases for searches -- the query
DAG/IPは検索のフレーズを受け入れることができることに注意してください - クエリ
FN=Foo\ bar<NL> (note the escaped space)
is perfectly valid. However, it would match only those things which have been tokenized in a way that preserves the space, which is the empty set in the case of the data stored here.
完全に有効です。ただし、ここに保存されているデータの場合には空のセットであるスペースを保存する方法でトークン化されたものだけが一致します。
Querying a DAG-SAP
DAG-SAPのクエリ
It is never invalid to use the same substantive query to a DAG-SAP as was used to obtain referral information from the Referral Index. However, the over-generalization of these queries may yield excessive numbers of results, and will necessitate some pruning of results in order to match the returned results against the semantics of the original LDAP query. It is the LDAP DAG-CAP that is responsible for this pruning, as it is the recipient of the original query, and responsible for responding to its semantics.
紹介インデックスから紹介情報を取得するために使用されたのと同じ実質的なクエリをDAG-SAPに使用することは無効ではありません。ただし、これらのクエリの過剰な一般化により、過剰な数の結果が得られる可能性があり、元のLDAPクエリのセマンティクスと返された結果を一致させるために、結果の剪定が必要になります。これは、元のクエリの受信者であり、そのセマンティクスへの応答を担当するため、この剪定に責任があるLDAP DAG-CAPです。
In concrete terms, when making the DAG/IP query which is to be sent to a DAG-SAP the above mentioned queries are still valid queries, but an alternative finer-grained query is also possible, namely:
具体的に言えば、DAG/IPクエリをDAG-SAPに送信する場合、上記のクエリは依然として有効なクエリですが、代替のより細かいクエリも可能です。
FN=foo and FN=bar and ORG=c;search=lstring and ORG=t;search=tstring
In querying a DAG-SAP (irrespective of the protocol of that DAG-SAP), the DAG/IP query must include information about the target WDSP server. This information is drawn from the Referral Index SERVER-TO-ASK referral information, and is appended to the query as specified in Appendix C):
DAG-SAP（そのDAG-SAPのプロトコルに関係なく）の照会では、DAG/IPクエリには、ターゲットWDSPサーバーに関する情報を含める必要があります。この情報は、紹介インデックスサーバーからアスクへの紹介情報から引き出され、付録Cで指定されているクエリに追加されます）：
"host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
where the response from the Referral Index included:
"# SERVER-TO-ASK " serverhandle <NL>
" Server-info: " serverinfo<NL>
" Host-Name: " hostname<NL>
" Host-Port: " number<NL>
" Protocol: " prot<NL>
" Source-URI: " source<NL>
" Charset: " charset<NL>
"# END"<NL>
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
また、「引用されたhostname」と「Quoted-serverinfo」は、DAG/IP特殊文字を引用することにより、それぞれ「HostName」と「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/
Charset: T.61<NL>
# END<NL>
would yield the addition
追加が得られます
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
c\=se;charset=T\.61
in its query to an LDAPv2 DAG-SAP.
ldapv2 dag-sapへのクエリで。
(N.B.: See Appendix C for further definitions of the terms used in the SERVER-TO-ASK response).
（N.B。：サーバーからアスクの応答で使用される用語のさらなる定義については、付録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は、DAG-SAPSに依存して、LDAPV3サーバーの紹介を除くすべての紹介を解決します（つまり、WHOIS紹介、現在）。
As described above, results from DAG-SAPs will have to be post-processed in cases where the original query was generalized for expression in DAG/IP. Acceptable results are expressed in LDAPv3 messages containing search result entries (see the standard for more detail):
上記のように、DAG-SAPSの結果は、元のクエリが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
(Where DN, FN, ROLE, and ORG are the values from the DAG schema).
（ここで、DN、FN、役割、および組織はDAGスキーマの値です）。
I.e., where available, the entry's true DN is used; otherwise (e.g., for data coming from Whois++ servers), a reasonable facsimile is constructed.
つまり、利用可能な場合、エントリの真のDNが使用されます。それ以外の場合は（たとえば、WHOISサーバーからのデータの場合）、合理的なファクシミリが構築されます。
Referral URLs are constructed from the DAG/IP's SERVER-TO-ASK information as follows:
紹介URLは、次のようにDAG/IPのサーバーツーアスク情報から構築されます。
refurl = "ldap://" HOST [":" PORT] "/" (SERVER-INFO / "dc=se")
The intention is that WDSPs using LDAPv3 servers will provide an appropriate LDAPDN for their server in the SERVER-INFO. Clients are then expected to repeat their query at the server designated by this URL (i.e., the refURL does not include the query).
意図は、LDAPV3サーバーを使用してWDSPがサーバー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キャップが処理する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（選択された誤ったスキーマ属性用）InauppraTematching（サポートされているもの以外のマッチタイプが使用される場合、たとえば、AmplxMatch）UnwillingToperform（クエリが定義されたタイプの1つではない場合）
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 = SVENSSON」などの将来の質問を拒否します）。エラーメッセージ。エラーメッセージには、次の結果コードが含まれています：adminlimitex ceeded
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>
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つの結果コードをクライアントに送信できるためです。LDAPV3 DAG-CAPがDAG-SAPからいくつかの異なる結果コードを受信した場合、それらの組み合わせをある程度表す結果の結果を構築する必要があります。これらの場合、次のアクションが取られることが提案されています。
- 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結果コードに変換されます。 - 結果コードが選択され、次の根拠で収集された応答を表します。「成功」がこれらのステップの後に表される唯一の結果コードである場合、結果コードを返します。「成功」とは別に、もう1つのresultCodeを表すもう1つの結果を表します。「成功」とは別に、2つ以上の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
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翻訳を使用して、WHOIS DAG-SAPが受信したWHOIS DAG-SAPの残りのクエリの残りです。
template=DAGPERSON becomes template=USER
Template = DagpersonはTemplate = 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
- send the DAG/IP query as constructed (e.g., with "search=substring"), and pass back the "% 502 Search expression too complicated" from the WDSP's server, - translate the DAG/IP query into a construct using only these search types (which will yield incomplete results, as not all queries are expressible with those search types), - attempt to ascertain what search types are supported by the remote server and reformulate using them (e.g., regular expressions). This would work, but would entail an excessively complicated Whois++ DAG-SAP, and might not yield any better results if the remote server doesn't support any optional search types.
- 構築されたDAG/IPクエリを送信し（たとえば、「検索=サブストリング」）、WDSPのサーバーから「％502検索式が複雑すぎる」を渡します。タイプ（すべてのクエリがこれらの検索タイプで表現されるわけではないため、不完全な結果が得られます） - リモートサーバーによってサポートされている検索タイプを確認し、それらを使用して再定式化しようとします（例：正規表現）。これは機能しますが、過度に複雑な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> 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.
％403情報利用不可<NL>リモートサーバーが他のWHOISエラーメッセージを発行し、結果を生成しない場合、リモートサーバーのエラーメッセージはDAG-SAP独自のエラーメッセージに含まれます。結果は返されません。
If results are successfully received from the remote server, they will be expressed using the DAG/IP -- essentially passing through all FULL response information received from the remote server, mapped into the DAGSchema using the mappings defined in Appendix A.
結果がリモートサーバーから正常に受信された場合、それらはDAG/IPを使用して表現されます - 基本的にリモートサーバーから受信したすべての完全な応答情報を通過し、付録Aで定義されたマッピングを使用してDagschemaにマッピングされました。
The LDAPv2 DAG-SAP expects valid DAG/IP communications. Queries must include referral information (see below) and search terms that conform to the DAG-allowed query types (e.g., not searches for organization alone, etc).
LDAPV2 DAG-SAPは、有効なDAG/IP通信を期待しています。クエリには、紹介情報（以下を参照）と、DAGが許可されたクエリタイプに準拠する検索用語（たとえば、組織だけの検索など）を含める必要があります。
The referral information is added to the end of the DAG-SAP query, as defined in the DAG-CAP definition sections (as additional terms in the DAG/IP query):
紹介情報は、DAG-CAP定義セクションで定義されているように、DAG-SAPクエリの最後に追加されます（DAG/IPクエリの追加の用語として）：
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
The HOST and PORT information are used to make a TCP/IP-based connection to the remote (presumed) LDAPv2 server. The DAG-SAP will establish a connection with the remote server, following standard LDAPv2 message exchanges.
ホストおよびポート情報は、リモート（推定）LDAPV2サーバーへのTCP/IPベースの接続を作成するために使用されます。DAG-SAPは、標準のLDAPV2メッセージ交換に従って、リモートサーバーとの接続を確立します。
The search request itself will be constructed from the DAG/IP query (without the HOST, SERVER-INFO and PORT terms) as follows:
検索リクエスト自体は、次のように（ホスト、サーバーINFO、およびポート用語なし）DAG/IPクエリから構築されます。
SearchRequest ::=
[APPLICATION 3] SEQUENCE {
baseObject LDAPDN, -- from the DAG/IP query
scope baseObject (0) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3)
}, sizeLimit INTEGER (0 .. maxInt), timeLimit INTEGER (0 .. maxInt), attrsOnly FALSE filter Filter, attributes SEQUENCE OF AttributeType -- all DAGschema attributes equivalents in the defined standard LDAP schema }
}、sizelimit integer（0 .. maxint）、TimeLimit integer（0 .. maxint）、Attrsonly Falseフィルター、属性の属性シーケンス、すべての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シーケンス{type aTtibionType、
SEQUENCE OF CHOICE {
substrings initial [0] LDAPString,
substrings any [1] LDAPString,
substrings final [2] LDAPString}
}
where and, or and not filters are constructed to preserve the logic of the DAG/IP query.
dag/ipクエリのロジックを保持するために、、またはol、またはonではないフィルターが構築されています。
For the purposes of matching token-based DAG/IP queries to reasonable LDAP queries, all searches should be passed to the LDAP WDSP as substring searches. The WDSP results must then be pruned to respect token boundaries, where necessary.
トークンベースのDAG/IPクエリを妥当なLDAPクエリに一致させる目的で、すべての検索をサブストリング検索としてLDAP WDSPに渡す必要があります。必要に応じて、トークンの境界を尊重するために、WDSPの結果を剪定する必要があります。
So, for example, the DAG/IP query
したがって、たとえば、DAG/IPクエリ
FN=Foo\ Bar and ORG=Thinking\ Cat:search=substring<NL>
would be sent to the designated LDAP WDSP as
指定されたLDAP WDSPとして送信されます
(& (fn=*Foo Bar*) (o=*Thinking Cat*) (objectclass=person))
Interestingly, the query
興味深いことに、クエリ
FN=Foo\ Bar and ORG=Thinking\ Cat:search=exact<NL>
would also be sent to the designated LDAP WDSP as
(& (fn=*Foo Bar*) (o=*Thinking Cat*) (objectclass=person))
but the WDSPs returned results would have to be pruned to remove any results that had non-tokenizing characters on either side of "Foo Bar" and "Thinking Cat".
しかし、WDSPが返された結果は、「Foo Bar」と「Thinking Cat」の両側に非トークン化されたキャラクターがある結果を削除するために剪定する必要があります。
The final consideration for mapping DAG/IP queries into LDAP queries is the issue of character case. In LDAP, individual attribute syntaxes define the consideration of case. All of the attributes used here are case-insensitive in their definitions. Therefore, all LDAP WDSP queries are inherently case-insensitive; if the DAG/IP query calls for a case-sensitive match, the LDAP DAG-SAP will have to do pruning of the results from the DAG-SAP.
DAG/IPクエリをLDAPクエリにマッピングするための最後の考慮事項は、キャラクターケースの問題です。LDAPでは、個々の属性構文がケースの考慮事項を定義します。ここで使用されるすべての属性は、定義においてケースに依存しないものです。したがって、すべてのLDAP WDSPクエリは本質的にケース非感受性です。DAG/IPクエリがケースに敏感な一致を必要とする場合、LDAP DAG-SAPはDAG-SAPの結果を剪定する必要があります。
If it is not possible to establish an LDAPv2 session with the remote server, or if the session is interrupted before results are received, or if the remote server issues any kind of error message and produces no result, the DAG-SAP will itself return no results and an error message, including
リモートサーバーでLDAPV2セッションを確立することができない場合、または結果を受信する前にセッションが中断された場合、またはリモートサーバーがいかなる種類のエラーメッセージを発行して結果を生成しない場合、DAG-SAP自体はNOを返します結果とエラーメッセージ
% 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"、および "o" LDAPスキーマ）はすべて、平等マッチングに対して症例感受性があると定義されています。したがって、DAG/IPクエリに制約「ケース=検討」が含まれている場合、リモートサーバーの結果は、間違ったケースのものを削除するために後処理されなければなりません。
TISDAG: The serverhandle and localhandle in the DAG/IP response should be constructed as follows:
TISDAG：DAG/IP応答のサーバーハンドルとローカルハンドルは、次のように構築する必要があります。
serverhandle is: <hostname-without-periods><port> (because server DN's are not enforceably unique). E.g., a services.bunyip.com server on 7778 would become servicesbunyipcom7778. localhandle is: the RDN (relative distinguished name), with spaces replaced by "_". E.g., cn=leslie_daigle
serverHandleは：<hostname-without-periods> <port>（サーバーdnが強制的に一意ではないため）。たとえば、7778のservices.bunyip.comサーバーは、servicesbunyipcom7778になります。LocalHandleは次のとおりです。RDN（相対的な著名な名前）、スペースは「_」に置き換えられます。たとえば、CN = Leslie_Daigle
The LDAPv3 DAG-SAP expects valid DAG/IP communications. Queries must include referral information (see below) and search terms that conform to the DAG-allowed query types (e.g., not searches for organization alone, etc).
LDAPV3 DAG-SAPは、有効なDAG/IP通信を期待しています。クエリには、紹介情報（以下を参照）と、DAGが許可されたクエリタイプに準拠する検索用語（たとえば、組織だけの検索など）を含める必要があります。
The referral information is added to the end of the DAG-SAP query, as defined in the DAG-CAP definition sections:
紹介情報は、DAG-CAP定義セクションで定義されているように、DAG-SAPクエリの最後に追加されます。
":host=" quoted-hostname ";port=" number ";server-info="
quoted-serverinfo ";charset=" charset
The HOST and PORT information are used to make a TCP/IP-based connection to the remote (presumed) LDAPv3 server. The DAG-SAP will establish a connection with the remote server, following standard LDAPv3 message exchanges.
ホストおよびポート情報は、リモート（推定）LDAPV3サーバーへのTCP/IPベースの接続を作成するために使用されます。DAG-SAPは、標準のLDAPV3メッセージ交換に従って、リモートサーバーとの接続を確立します。
The search request itself will be constructed from the DAG/IP query (without the HOST, SERVER-INFO and PORT terms) as follows:
検索リクエスト自体は、次のように（ホスト、サーバーINFO、およびポート用語なし）DAG/IPクエリから構築されます。
SearchRequest ::=
[APPLICATION 3] SEQUENCE {
baseObject LDAPDN, -- from the DAG/IP query
scope baseObject (0) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3)
},
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
attrsOnly FALSE
filter Filter,
attributes SEQUENCE OF AttributeType
-- all DAGschema attributes equivalents in
the defined standard LDAP schema
}
Filter ::=
CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
substrings [4] SubstringFilter,
}
SubstringFilter
SEQUENCE {
type AttributeType,
SEQUENCE OF CHOICE {
substrings initial [0] LDAPString,
substrings any [1] LDAPString,
substrings final [2] LDAPString}
}
where and, or and not filters are constructed to preserve the logic of the DAG/IP query.
dag/ipクエリのロジックを保持するために、、またはol、またはonではないフィルターが構築されています。
For the purposes of matching token-based DAG/IP queries to reasonable LDAP queries, all searches should be passed to the LDAP WDSP as substring searches. The WDSP results must then be pruned to respect token boundaries, where necessary.
トークンベースのDAG/IPクエリを妥当なLDAPクエリに一致させる目的で、すべての検索をサブストリング検索としてLDAP WDSPに渡す必要があります。必要に応じて、トークンの境界を尊重するために、WDSPの結果を剪定する必要があります。
So, for example, the DAG/IP query
したがって、たとえば、DAG/IPクエリ
FN=Foo\ Bar and ORG=Thinking\ Cat:search=substring<NL>
would be sent to the designated LDAP WDSP as
指定されたLDAP WDSPとして送信されます
(&(fn=*Foo Bar*)(o=*Thinking Cat*)(objectClass=person))
Interestingly, the query
興味深いことに、クエリ
FN=Foo\ Bar and ORG=Thinking\ Cat:search=exact<NL>
would also be sent to the designated LDAP WDSP as
指定されたLDAP WDSPにも送信されます
(&(fn=*Foo Bar*)(o=*Thinking Cat*)(objectClass=person))
but the WDSP's returned results would have to be pruned to remove any results that had non-tokenizing characters on either side of "Foo Bar" and "Thinking Cat".
しかし、WDSPの返された結果は、「Foo Bar」と「Thinking Cat」の両側に非トークン化されたキャラクターがある結果を削除するために剪定する必要があります。
The final consideration for mapping DAG/IP queries into LDAP queries is the issue of character case. In LDAP, individual attribute syntaxes define the consideration of case. All of the attributes used here are case-insensitive in their definitions. Therefore, all LDAP WDSP queries are inherently case-insensitive; if the DAG/IP query calls for a case-sensitive match, the LDAP DAG-SAP will have to do pruning of the results from the DAG-SAP.
DAG/IPクエリをLDAPクエリにマッピングするための最後の考慮事項は、キャラクターケースの問題です。LDAPでは、個々の属性構文がケースの考慮事項を定義します。ここで使用されるすべての属性は、定義においてケースに依存しないものです。したがって、すべてのLDAP WDSPクエリは本質的にケース非感受性です。DAG/IPクエリがケースに敏感な一致を必要とする場合、LDAP DAG-SAPはDAG-SAPの結果を剪定する必要があります。
Any referrals that the remote WDSP server returns are pursued, following the usual LDAPv3 (client) fashion, by the LDAPv3 DAG-SAP.
LDAPV3 DAG-SAPによる、通常のLDAPV3（クライアント）ファッションに続いて、リモートWDSPサーバーが返品する紹介が追求されます。
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自体はNOを返します結果とエラーメッセージ
% 403 Information Unavailable<NL>
％403情報利用不可<NL>
If results are successfully received from the remote server, the attributes and values that are provided for each result message will be incorporated into the DAG/IP result, which will be expressed using the DAG/IP and schema mappings as outlined in Appendix A.
リモートサーバーから結果が正常に受信された場合、各結果メッセージに提供される属性と値がDAG/IP結果に組み込まれ、付録Aで概説されているDAG/IPおよびスキーママッピングを使用して表現されます。
One particular adjustment must be done to accommodate differences between LDAP and the DAG/IP. The attributes on which searches are keyed ("cn", "l", and "o" in the LDAP schemas) are all defined as being case-insensitive for equality matching. Thus, if the DAG/IP query includes the constraint "case=consider", the results from the remote server must be post-processed to remove any wrong-cased ones.
LDAPとDAG/IPの違いに対応するために、特定の調整を行う必要があります。検索がキー化されている属性（ "cn"、 "l"、および "o" LDAPスキーマ）はすべて、平等マッチングに対して症例感受性があると定義されています。したがって、DAG/IPクエリに制約「ケース=検討」が含まれている場合、リモートサーバーの結果は、間違ったケースのものを削除するために後処理されなければなりません。
TISDAG: The serverhandle and localhandle in the DAG/IP response should be constructed as follows:
TISDAG：DAG/IP応答のサーバーハンドルとローカルハンドルは、次のように構築する必要があります。
- serverhandle is: <hostname-without-periods><port> (because server DN's are not enforceably unique). E.g., a services.bunyip.com server on 7778 would become servicesbunyipcom7778. - localhandle is: the RDN (relative distinguished name), with spaces replaced by "_". E.g., cn=leslie_daigle
- serverHandleは：<hostname-without-periods> <port>（サーバーdnが強制的に一意ではないため）。たとえば、7778のservices.bunyip.comサーバーは、servicesbunyipcom7778になります。 - ローカルハンドルは：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>
The expected answer can be described as:
予想される答えは、次のように説明できます。
Any USER templates that contain the tokens "thinking" and "cat" in a name attribute.
名前属性にトークンの「思考」と「猫」を含むすべてのユーザーテンプレート。
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
名前：ネコの考えを考える名前：erudite猫
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.
この最後のレコードは、クエリがケースの感度を求めているために一致しません。名前属性の値の場合はクエリと一致しません。
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>
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紹介がWHOISクライアントに直接渡されるため、WHOIS DAG-CAPは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>
which will be translated by the DAG-SAP into an LDAP query of the form:
これは、DAG-SAPによってフォームのLDAPクエリに翻訳されます。
(&(cn=*thinking*)(cn=*cat*)(objectclass=inetOrgPerson))
which will match a record with:
レコードを次のように一致させます。
cn: Thinking cn: Cat
CN：CNを考える：猫
(i.e., 2 different cn attributes, with the 2 values; LDAP defines case sensitivity matching by the schema attribute definition).
（つまり、2つの異なるCN属性、2つの値を持つ属性; LDAPは、Schema属性定義でケース感度の一致を定義します）。
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))
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ユーザーが探しているのは、このクエリを使用して、「TH」で始まり、「T」で終わり、中央のどこかに「C」を持っているCN属性を持つ「グリーン食料品」組織内のすべてのレコードです。
cn values that would match this include:
これに一致するCN値は次のとおりです。
cn: thinkingcat cn: Thinking Cat cn: The Black Cat cn: Thick Mat
CN：ThinkingCat CN：Thinking Cat CN：Black Cat 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>
This will generate some false positive referrals, directing the query to WDSPs containing records with the following attribute values (the match letters are in capitals for ease of identification):
これにより、いくつかの誤った肯定的な紹介が生成され、次の属性値を含むレコードを含むWDSPにクエリを指示します（一致文字は識別を容易にするために首都にあります）：
cn: wiTH three blaCk poTs
CN：3つの黒いポット付き
o: peaGREEN and cyan GROCERIES o: GROCERIES are GREENer than electronics
O：ピーグリーンとシアンの食料品O：食料品はエレクトロニクスよりも環境に優しい
Alternative approaches include breaking the original query into several queries to the referral index in such a way that the DAG-CAP can use only those referrals that appear in all the Referral Index responses. However, this is
代替アプローチには、DAG-CAPがすべての紹介インデックス応答に表示される紹介のみを使用できるように、元のクエリを紹介インデックスのいくつかのクエリに分割することが含まれます。しかし、これはです
overkill -- the purpose of the Referral Index is to give direction on where there may be more information
オーバーキル - 紹介インデックスの目的は、より多くの情報がある可能性のある場所について指示を与えることです
difficult to code into the DAG-CAP in a general way -- it has to identify, by LDAP query type, when and how to do so
一般的な方法でDag-Capにコーディングするのは難しい - それは、LDAPクエリタイプで、いつ、どのように行うかを特定する必要があります
likely to generate Referral Index queries that are complex and time-consuming to process.
複雑で時間がかかる紹介インデックスクエリを生成する可能性があります。
What the LDAP DAG-CAP Sends to a Whois++ DAG-SAP
LDAP DAG-CAPがWHOIS DAG-SAPに送信するもの
The LDAP DAG-CAP may send the same query to a Whois++ DAG-SAP as it sent to the Referral Index. False positives here mean results that are not expected as a match by the LDAP client. The LDAP DAG-CAP should prune these results from the information returned by the Whois++ DAG-SAP.
LDAP DAG-CAPは、紹介インデックスに送信されたwhois dag-sapに同じクエリを送信する場合があります。ここでの誤検知は、LDAPクライアントによる一致として予想されない結果を意味します。LDAP DAG-CAPは、WHOIS DAG-SAPによって返された情報からこれらの結果を剪定する必要があります。
Or it might rewrite the query into:
または、クエリを次のように書き換えることができます。
FN=th;search=lstring AND FN=C;search=substring AND
FN=T;search=tstring AND ORG=green AND ORG=groceries:case=ignore<NL>
What the LDAP DAG-CAP Sends to an 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-capによって等しく処理されることを記憶に保つことは注目に値します。。
So in this case the LDAP DAP-CAP could either send the same query to the LDAP DAG-SAP as it sent to the Referral Index or it could send the augmented version that is allowed to be use with the DAG-SAPs, namely:
したがって、この場合、LDAP DAP-CAPは、紹介インデックスに送信されたLDAP DAG-SAPに同じクエリを送信するか、DAG-SAPで使用できる拡張バージョンを送信できます。
FN=th;search=lstring AND FN=C;search=substring AND
FN=T;search=tstring AND ORG=green\ groceries:case=ignore<NL>
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))
which is still more general than the original query.
これは、元のクエリよりもさらに一般的です。
Note the translation from "FN=th;search=lstring" into "cn=*th*". This is necessary, as the DAG/IP lstring constraint is based on tokens, whereas "cn=th*" refers to the beginning of the attribute's value (phrase, not token). The DAG-SAP should therefore prune out any results that include things like "oTHer plaCes for visiTors" in order to match the semantics of the DAG/IP query it received.
「fn = th; search = lstring」から「cn =*th*」への翻訳に注意してください。これは、DAG/IP LSTRINGの制約はトークンに基づいているため、これが必要です。一方、「CN = TH*」とは、属性の値（フレーズ、トークンではなくフレーズ）の始まりを指します。したがって、DAG-SAPは、受け取ったDAG/IPクエリのセマンティクスと一致するために、「訪問者のための他の場所」のようなものを含む結果を剪定する必要があります。
The DAG-CAP should then prune those results to match the semantics of the original LDAP query.
次に、DAG-CAPは、これらの結果を剪定して、元のLDAPクエリのセマンティクスに一致する必要があります。
To satisfy the requirements laid out for the TISDAG project, the software built for the DAG system must be able to meet the following service specifications:
TISDAGプロジェクトのためにレイアウトされた要件を満たすには、DAGシステム用に構築されたソフトウェアは、次のサービス仕様を満たすことができなければなりません。
- primary designated DAG-CAPs of all types (but not necessarily secondary ones set up for load-balancing) must be available to provide service or redirect queries on a 7x24 basis.
- 7x24ベースでサービスを提供またはリダイレクトするクエリを提供するために、すべてのタイプの主要な指定DAGキャップ（必ずしも負荷分散のために設定されているわけではありません）を利用できる必要があります。
- in general, responses to queries should be available in under 10 seconds; very generalized queries (i.e., when the user truly cannot specify enough information to focus the search) can be deferred to take much longer (having results is more important than having a quick answer) - the data provided from each WDSP should be updated in the DAG at least once every 7 days
- 一般に、クエリへの応答は10秒以内に利用できるようにする必要があります。非常に一般化されたクエリ（つまり、ユーザーが本当に検索に焦点を当てるのに十分な情報を本当に指定できない場合）をより長く延期することができます（結果を得ることは迅速な答えを持っているよりも重要です） - 各WDSPから提供されるデータをで更新する必要があります少なくとも7日に1回DAG
WDSPs who wish to participate in the DAG system do so by providing DAG-compatible access to their service, where DAG-compatible means:
DAGシステムへの参加を希望するWDSPは、DAG互換のサービスへのDAG互換アクセスを提供することでそうします。
- access in (exactly) one of LDAPv2, LDAPv3, or Whois++ - 7x24 service for responding to referrals generated in the DAG core (minimally) weekly updates of the index object describing the information their service indexes - use of USER and ROLE templates for Whois++ servers - use of inetorgperson and organizationalrole objectclasses for LDAP servers
- （正確に）LDAPV2、LDAPV3、またはWHOIS -7x24サービスインデックスのDAGコアで生成された紹介に応答するための7x24サービスサービスインデックスを記述するインデックスオブジェクトの毎週の更新 - ユーザーと役割テンプレートのWHOISサーバーのテンプレートの使用-LDAPサーバー用のInetorgPersonおよびOrganizationalrole Objectlassesの使用
To participate, WDSPs must register each DAG-compliant server with the DAG system, providing details for each data set that it covers:
参加するには、WDSPは各DAGに準拠したサーバーをDAGシステムに登録し、それがカバーする各データセットの詳細を提供する必要があります。
- the host, port and protocol of the server - an identifier for the dataset - a URL for the service of preference for accessing the data (preferred source) - protocol-specific information - administrative contact information - CIP object exchange information
- サーバーのホスト、ポート、およびプロトコル - データセットの識別子 - データにアクセスするための優先サービスのためのURL（優先ソース） - プロトコル固有の情報 - 管理連絡先情報 - CIPオブジェクト交換情報
Note that any WDSP wishing to make data available through the DAG system but unable to support these requirements may provide information through an agreement with a third-party which does meet these requirements. Thus, data can be replicated between cooperating WDSPs. The DAG referral index does not claim ownership of personal information; it directs queries to services that do, by whatever agreements with whichever relevant parties. Note that, in this case, the SOURCE-URI may direct end-users to the WDSP's existing services, not the service of the third party.
DAGシステムを介してデータを利用できるようにしたいが、これらの要件をサポートできないWDSPは、これらの要件を満たすサードパーティとの契約を通じて情報を提供する場合があることに注意してください。したがって、協力するWDSP間でデータを再現できます。DAG紹介インデックスは、個人情報の所有権を請求しません。関連当事者との契約をどのようにしても、それを行うサービスに照会します。この場合、Source-URIは、第三者のサービスではなく、WDSPの既存のサービスにエンドユーザーを向けることができることに注意してください。
It is anticipated that the DAG system will be quite popular, and measures must be available to distribute the load of answering queries.
DAGシステムは非常に人気があり、回答クエリの負荷を配布するための測定値を利用できる必要があります。
The DAG system is presented as a conceptual whole, made up of several component parts -- DAG-CAPs, DAG-SAPs and the Referral Index. Each of these component parts must be replicable, and service must be shared between replicas.
DAGシステムは、DAG-CAPS、DAG-SAPS、紹介インデックスなど、いくつかのコンポーネントパーツで構成される概念全体として提示されます。これらの各コンポーネント部品は複製可能である必要があり、レプリカ間でサービスを共有する必要があります。
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-CAPS/DAG-SAPSを提供できるようにすることを検討することは興味深いかもしれません。このレポートの範囲を超えていることを行うためのポリシーと可能性。ただし、ソフトウェアアーキテクチャは、そのようなアクティビティをサポートするように設計されています。
Figure 6.1 shows that individual components of the DAG system may each run on non-co-located server hardware, connected by TCP/IP networks. These components can be replicated as needed.
図6.1は、DAGシステムの個々のコンポーネントがそれぞれ、TCP/IPネットワークで接続されている非Co-Cocated Serverハードウェアで実行される可能性があることを示しています。これらのコンポーネントは、必要に応じて複製できます。
+====+
| | 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 Thus, the software built to this specification must be configurable to permit the following actions:
図6.1 DAGコンポーネントの分散性の性質したがって、この仕様に合わせて構築されたソフトウェアは、次のアクションを許可するために構成可能でなければなりません。
- 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ソフトウェアに応じて、これは、着信クエリに参加する複数のプロセスを持つことで処理される場合があります。 - 現時点でサーバーをロードしました。 - これは、WHOISやLDAPなどの同期接続プロトコルで特に必要です。ここでは、要求クライアントがよく宣伝されたアドレスポートに接続されている時間を最小限に抑えることです。-DAG-CAPソフトウェアは、同じプロトコルタイプのさまざまなDAG-SAPSに紹介を向けることができなければなりません。-DAG-CAPソフトウェアは、一般的なクエリを検出できる必要があります（つまり、紹介インデックスによって生成された紹介の数が大きすぎると判断するためのメトリックがあります）。-Dag-Sapsは、Dag-Capクエリを裁量でリダイレクトすることができなければなりません。または、読み込みのためにサービスを拒否する必要があります（したがって、DAG-CAPSも他のDAG-SAPを見つけることができなければなりません）
The DAG system has been designed to allow for extensibility in certain key areas:
DAGシステムは、特定の重要な領域での拡張を可能にするように設計されています。
It is possible to add new DAG-CAPs and DAG-SAPs transparently. Beyond replicating the software of existing DAG-CAPs, new implementations for particular protocols (e.g., building a more elaborate mail-based query system), or implementations for altogether different protocols (e.g., PH) can be added by adhering to the basic principles of DAG-CAPs and DAG-SAPs defined in the software specification. The new DAG-CAP is responsible for the translation of queries into DAG/IP (post-processing results, if necessary) and results in the new protocol. No other part of the DAG system is affected.
新しいDag-CapsとDag-Sapsを透過的に追加することができます。既存のDAGキャップのソフトウェアを複製するだけでなく、特定のプロトコルの新しい実装（例：より精巧なメールベースのクエリシステムの構築）、またはまったく異なるプロトコルの実装（例えば、pH）は、基本原則に準拠することで追加できます。ソフトウェア仕様で定義されたDAG-CAPSとDAG-SAPS。新しいDAG-CAPは、クエリのDAG/IPへの翻訳（必要に応じて後処理結果）に責任を負い、新しいプロトコルの結果です。DAGシステムの他の部分は影響を受けません。
More functionality may be added to the DAG system service (e.g., adding security certificate references to the schema of returned information) by updating the DAG schema.
DAGスキーマを更新することにより、DAGシステムサービスに追加の機能を追加することができます（たとえば、返された情報のスキーマにセキュリティ証明書の参照を追加）。
Depending on how the load on the service goes, it may be interesting to consider reducing the number of queries that are chained for protocols that inherently can handle the concept of pursuing referrals. Specifically, LDAPv3 and Whois++ both handle referrals, but the current system calls for chaining LDAPv3 (and LDAPv2) referrals for the Whois++ DAG-CAP, and vice versa. Alternatively,
サービスの負荷がどのように進むかに応じて、紹介を追求するという概念を本質的に処理できるプロトコルのために連鎖しているクエリの数を減らすことを検討することは興味深いかもしれません。具体的には、LDAPV3とWHOISは両方とも紹介を処理しますが、現在のシステムでは、WHOIS DAG-CAPのLDAPV3（およびLDAPV2）の紹介をチェーンする必要があります。または、
"virtual" DAG-CAPs could be established for each participating WDSP for each protocol the WDSP doesn't support, and referrals to those DAG-CAPs could be given to the calling client. For example, a Whois++ client would be given a Whois++ referral to the virtual Whois++ DAG-CAP for a WDSP that supports only LDAP. The importance of having one virtual DAG-CAP per WDSP is that the point of connection is the only way to distinguish which WDSP the Whois++ client thought it was connecting to.
「仮想」DAG-CAPSは、各プロトコルごとに参加するWDSPごとに確立できます。WDSPはサポートしていません。これらのDAGキャップへの紹介は、呼び出しクライアントに与えられます。たとえば、WHOISクライアントには、LDAPのみをサポートするWDSPのVirtual Whois Dag-CapへのWHOIS紹介が与えられます。WDSPごとに1つの仮想DAG-CAPを持つことの重要性は、接続のポイントが、WHOISクライアントが接続していると思っていたWDSPを区別する唯一の方法であることです。
Security, in the context of "read-only" directory services, is primarily concerned with maintaining data integrity as it passes from an originating server to the end-user making an inquiry. That is, some server(s) hold correct user information, and a client accessing a directory service should be certain that whichever servers that the information has to pass through before reaching the client, it receives a true representation of the original information.
セキュリティは、「読み取り専用」ディレクトリサービスのコンテキストで、主にデータの整合性を維持することに関係しています。これは、発信者のサーバーからエンドユーザーに依頼を行うために維持されます。つまり、一部のサーバーは正しいユーザー情報を保持しており、ディレクトリサービスにアクセスするクライアントは、クライアントに到達する前に情報が通過しなければならないサーバーがある場合、元の情報の真の表現を受信することを確認する必要があります。
The DAG system as such MUST be completely invisible as the mediator of the information from the WDSPs to the querying directory access client. The only possible modifications that can appear is translations from one characterset into another. Hopefully, this does not alter the meaning of the information.
DAGシステム自体は、WDSPからクエリディレクトリアクセスクライアントまでの情報のメディエーターとして完全に見えない必要があります。表示できる唯一の可能な変更は、あるキャラクターセットから別のキャラクターへの翻訳です。うまくいけば、これは情報の意味を変えません。
In keeping with the public nature of the proposed TISDAG service, the DAG system does not provide any access control system beyond components' configuration to accept connections from recognized other components. For more detailed access control, it is up to the connected WDSPs to apply the access control.
提案されたTISDAGサービスの公共の性質に沿って、DAGシステムは、認識された他のコンポーネントからの接続を受け入れるコンポーネントの構成を超えたアクセス制御システムを提供しません。より詳細なアクセス制御のために、アクセス制御を適用するのは接続されたWDSP次第です。
Since the DAG system only supports searching and retrieving information, no updates can occur through the DAG client access points.
DAGシステムは情報の検索と取得のみをサポートするため、DAGクライアントアクセスポイントを介して更新は発生しません。
Security in updates (CIP index objects) is provided by encryption and signature of objects from registered WDSPs.
更新のセキュリティ（CIPインデックスオブジェクト）は、登録されたWDSPからのオブジェクトの暗号化と署名によって提供されます。
This work came from ideas originally put forward by Patrik Faltstrom. The TISDAG project was supported by the Swedish KK Foundation.
この作品は、もともとパトリック・ファルトストロームが提唱したアイデアから来ました。TISDAGプロジェクトは、スウェーデンのKK財団によってサポートされていました。
Thanks to especially to Jens Lundstrom, Thommy Eklof, Bjorn Larsson and Sandro Mazzucato for their comments on draft versions of this document.
特にJens Lundstrom、Thommy Eklof、Bjorn Larsson、Sandro Mazzucatoに感謝します。
Appendix A - DAG Schema Definitions
付録A- DAGスキーマ定義
The DAG makes use of 2 information schemas -- the DAGPERSON schema for information about specific people, and the DAGORGROLE schema for organizational roles that may or may not be job positions occupied by people at any given time (e.g., an organization's president, customer service desk, etc).
DAGは2つの情報スキーマを使用しています - 特定の人々に関する情報のためのDagpersonスキーマ、およびいつでも人々が占有する職位であるか、または雇用されていない組織の役割についてはDagorgroleスキーマ（例：組織の社長、顧客サービス机など）。
This appendix defines the schemas in terms of the attributes used within the DAG/IP. Mappings to the standard LDAP and Whois++ object classes and templates (respectively) are described in Appendix B.
この付録は、DAG/IP内で使用される属性に関してスキーマを定義しています。標準のLDAPおよびWHOISオブジェクトクラスとテンプレートへのマッピングは、付録Bで説明されています。
Because the role of the DAG schemas is to act as an intermediary between information provided in different access protocols, with different underlying schema paradigms, the attributes in the schema are identified as being required or optional. The required attributes are so designated because they are involved in the DAG search types and/or the minimal returned response. They have defined mappings in the selected access protocols. The optional attributes have proposed mappings in those protocols.
DAGスキーマの役割は、異なるアクセスプロトコルで提供される情報間の仲介者として機能することであり、異なる基礎となるスキーマパラダイムを使用することであるため、スキーマの属性は必要またはオプションであると特定されます。必要な属性は、DAG検索タイプおよび/または最小限の返された応答に関与しているため、そのように指定されています。選択したアクセスプロトコルのマッピングを定義しています。オプションの属性は、これらのプロトコルのマッピングを提案しています。
It is important to note that the DAG/IP is constructed to carry any alternative attribute information that may be provided by a given WDSP; individual DAG-SAPs and DAG-CAPs may choose to pass along, interpret, or ignore any attributes not defined in this appendix.
DAG/IPは、特定のWDSPによって提供される可能性のある代替属性情報を運ぶために構築されていることに注意することが重要です。個々のDAGSAPSおよびDAG-CAPSは、この付録で定義されていない属性を渡したり、解釈したり、無視したりすることを選択できます。
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の属性の順序は重要であることに注意してください。つまり、1つの属性を使用して、後続のタイプを説明する情報を携帯することが可能です（たとえば、以下の「ADRタイプ」属性を参照）。
Finally, attributes may be repeated. For example, this schema structure can carry multiple phone numbers of different types for one person.
最後に、属性を繰り返すことができます。たとえば、このスキーマ構造は、1人で異なるタイプの複数の電話番号を運ぶことができます。
Attribute Designation Specific Description
--------- ----------- -------------------------------------
FN Required Free-text representation of full name
EMAIL Required Internet e-mail address
LOC Required Locality -- geographic region
ORG Required Person's organization
ADR-TYPE Optional Type of address that follows
("org", "home", "org-postal",
"home-postal", "unqualified")
ADR Optional Full address
ADR-STREET Optional Street address component
ADR-ROOM Optional Suite or room number component
ADR-CITY Optional City name
ADR-STATE Optional Region of address
ADR-COUNTRY Optional Country
ADR-CODE Optional Postal code component
TEL-TYPE Optional Type of telephone number (
"work", "home", "mobile",
"fax" ,"pager", "unqualified")
in the following attribute
TEL Optional A phone number for the person
SOURCE Optional The WDSP's preferred access to
their service -- a URL
DN Optional Entry's "distinguished name"
(for LDAP)
Table A.1 DAGPERSON schema attributes
表A.1ダグパーソンスキーマ属性
Attribute Designation Specific Description
--------- ----------- ---------------------
ROLE Required Name of organizational role
EMAIL Required E-mail address associated with role
ORG Required Name of organization
LOC Required Locality -- geographic region
TEL-TYPE Optional Type of telephone number
in the TEL attribute immediately
following("org" or "fax")
TEL Optional Phone number
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)
Table A.2 DAGORGROLE schema attributes
表A.2 Dagorgroleスキーマ属性
Appendix B - Schema Mappings for Whois++ and LDAP
The DAG/IP makes use of two specific schemas, as defined above. However, schemas particular to access protocols need to be handled in order to appropriately address incoming user queries, and chaining queries to WDSPs. The recognized standard schemas are:
DAG/IPは、上記で定義されている2つの特定のスキーマを使用します。ただし、アクセスプロトコルに特有のスキーマは、着信ユーザークエリとWDSPにクエリを接続するために、処理する必要があります。認識されている標準スキーマは次のとおりです。
- the USER template for Whois++ ([8]) - the ORGROLE template for Whois++ ([8]) - the inetOrgperson objectclass for LDAP ([16]) - the organizationalrole objectclass for LDAP ([18])
- WHOISのユーザーテンプレート（[8]） - WHOISのORGROLEテンプレート（[8]） - LDAPのinetorgperson objeclclass（[16]） - LDAPの組織roledオブジェクトクラス（[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スキーマは、基本的なWDSPアクセスプロトコル（LDAPV2/V3およびWHOIS）で使用される標準スキーマに関する情報と併せて、TISDAGプロジェクトの要件が結果に戻りたいという情報に基づいて開発されました。ただし、特に住所情報の場合、これらのプロトコルに使用されるスキーマは、情報表現のかなりの範囲を可能にします。実際には、これは、異なるWDSPがスキーマの異なるサブパートを使用するか、ローカルのカスタマイズを実装することを選択することを意味します。
Therefore, Appendix A outlines a very basic schema that can carry all the necessary information. The basic DAG-CAPs and DAG-SAPs are designed to work to that information structure. This appendix outlines the expected behaviour for DAG-SAPs mapping into the DAG/IP schema, and DAG-CAPs extracting information to pass along to client software after a chaining operation has returned results.
したがって、付録Aは、必要なすべての情報を伝えることができる非常に基本的なスキーマの概要を説明しています。基本的なダグキャップとダグサップは、その情報構造に取り組むように設計されています。この付録は、チェーン操作が結果を返した後、クライアントソフトウェアに渡すために情報を抽出してDAG-CAPSをDAG/IPスキーマにマッピングするための予想される動作の概要を示しています。
The only time information is carried in the DAG schemas is when a DAG-SAP is returning information (obtained from WDSPs' servers) to a DAG-CAP using the DAG/IP. The "canonical" mappings between standard LDAP object classes (inetorgPerson, defined in [16] and organizationalRole, defined in [18] and the DAGPERSON schema and DAGORGROLE schema are defined such that information passed from an LDAP DAG-SAP to an LDAP DAG-CAP (e.g., in the case of an LDAPv3 DAG-SAP returning information chained for an LDAPv2 DAG-CAP) will be mapped into the same attributes as it was extracted.
DAGスキーマで情報が掲載されるのは、DAG-SAPがDAG/IPを使用して情報（WDSPSサーバーから取得）をDAG-CAPに返信している場合です。標準のLDAPオブジェクトクラス（[16]で定義されているInetorgpersonと[18]およびDagperson SchemaおよびDagorgroleスキーマで定義されている「Inetorgperson」間の「標準的な」マッピングは、LDAP Dag-SapからLDAP 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-Capsに非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-sapsはdag/ipの追加の属性を渡すことができ、dag-capsは認識可能なものを転送または解釈することを選択する場合があります（たとえば、sn（ "surname"）属性はここにリストされていませんが、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-postal
ADR postalAddress
ADR-ROOM postOfficeBox
ADR-CODE postalCode
ADR-TYPE=home-postal
ADR homePostalAddress
TEL-TYPE=work TEL telephoneNumber
Tel-Type = Work Telle ThelephonEnumber
TEL-TYPE=home TEL homePhone
Tel-Type = Home Tel HomePhone
TEL-TYPE=fax TEL facsimileTelephoneNumber
Tel-Type = Fax Tel facsimiletelephoneNumber
TEL-TYPE=mobile TEL mobile
Tel-Type = Mobile Tel Mobile
TEL-TYPE=pager TEL pager
Tel-Type =ポケットターテルページ
DN dn
SOURCE labeledURI
Table B.1 Canonical DAGPERSON schema & LDAP inetorgPerson attributes
表B.1標準的なダグパーソンスキーマ＆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 ThelephonEnumber
Table B.2 Reasonable Approximations for LDAP organizationalRole attributes For example, consider the following LDAP record information, in LDIF [11] format:
表B.2 LDAP組織属性属性の合理的な近似例えば、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
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
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 ObjectクラスとDagorgroleスキーマの標準マッピングを表B.3に示します。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 = Fax Tel Facsimile番号
FN roleOccupant
DN dn
SOURCE labeledURI
Table B.3 Canonical mappings for LDAP organizationalRole attributes
表B.3 LDAP Organizationalrole属性の標準マッピング
The "canonical" mappings between standard Whois++ templates as defined in [8] and the DAGPERSON schema and DAGORGROLE schema are defined in Tables B.4 and B.5. Beyond that, DAG-SAPs may pass along any additional attributes in the DAG/IP, and DAG-CAPs may elect to forward or interpret any that are recognizable.
[8]で定義されている標準WHOISテンプレートとDagpersonスキーマとダゴルグロールスキーマの間の「標準的な」マッピングは、表B.4およびB.5で定義されています。それを超えて、DAG-SAPSはDAG/IPの追加の属性を渡すことができ、DAG-CAPSは認識可能なものを転送または解釈することを選択する場合があります。
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=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
TEL-TYPE=work phone-type=work TEL phone
tel-type = work phone-type = work tel電話
TEL-TYPE=home phone-type=home TEL phone
tel-type = home phone-type = home tel電話
TEL-TYPE=fax TEL fax
Tel-Type = Fax Tel Fax
TEL-TYPE=mobile TEL cellular
Tel-Type = Mobile Tel Cellular
TEL-TYPE=pager TEL pager
Tel-Type =ポケットターテルページ
Table B.4 Canonical DAGPERSON schema & Whois++ USER attributes
表B.4 Canonical Dagperson Schema＆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 = Fax Tel Fax
Table B.5 Canonical mappings for Whois++ ORGROLE attributes
表B.5 Whois Orgrole属性の標準マッピング
Appendix C - DAG-Internal Protocol (DAG/IP)
付録C- DAG内部プロトコル（DAG/IP）
The DAG-Internal Protocol (DAG/IP) is currently defined as a derivative of the query-interaction protocol of Whois++ as laid out in RFC1835 ([6]).
DAG内部プロトコル（DAG/IP）は、現在、RFC1835（[6]）でレイアウトされているWHOISのクエリ相互作用プロトコルの導関数として定義されています。
The use of the DAG/IP is strictly internal to the DAG system. In that regard, it is possible make use of any query language, or define a new one.
DAG/IPの使用は、DAGシステムの内部に厳密です。その点で、クエリ言語を使用したり、新しい言語を定義したりする可能性があります。
The Whois++ protocol was selected as the basis of the DAG/IP for several reasons:
WHOISプロトコルは、いくつかの理由でDAG/IPの基礎として選択されました。
- it has the power and flexibility to convey all necessary queries - it is a simple, text-based protocol; clients need not implement the full functionality of the protocol in order to carry out minimal queries - the power of the full-fledge directory service query protocol will give DAG-CAP writers the ability to express more sophisticated queries if desired (e.g., to produce more intricate "intelligent" matching of spellings, common character substitutions, etc). - the text-based, delimited attribute results expression facilitates optional inclusion of extra data supplied by WDSPs -- DAG-CAPs can easily ignore any unknown information and continue to interpret the rest of the result information.
- 必要なすべてのクエリを伝える力と柔軟性があります。これは、シンプルなテキストベースのプロトコルです。クライアントは、最小限のクエリを実行するためにプロトコルの完全な機能を実装する必要はありません。フルフレッジディレクトリサービスクエリプロトコルのパワーにより、DAG-CAPライターは、必要に応じてより洗練されたクエリを表現する能力を提供します（例えば、より多くの生産を行うためにスペルの複雑な「インテリジェント」マッチング、一般的なキャラクター置換など）。 - テキストベースの区切り属性結果式は、WDSPが提供する追加のデータをオプションの含めることを容易にします。DAG-CAPSは、未知の情報を簡単に無視し、結果情報の残りを解釈し続けることができます。
Also, the use of an existing protocol leverages the experience and time of the creators of the protocol -- hammering out such elusive and yet necessary details as handling line-endings, quoting special characters, etc.
また、既存のプロトコルの使用は、プロトコルの作成者の経験と時間を活用します。これは、ラインエンドの取り扱い、特殊文字を引用するなどのとらえどころのないが必要です。
There is a freely-available test suite of tools for testing servers' Whois++ protocol conformance (for the Referral Index, and for DAG-SAPs). Send mail to digger-info@bunyip.com for further information.
サーバーのWHOISプロトコルの適合性（紹介インデックス、およびDAG-SAPS用）をテストするためのツールの自由に利用できるテストスイートがあります。詳細については、digger-info@bunyip.comにメールを送信してください。
Input interactions in DAG/IP are as defined in RFC1835, "Architecture of the WHOIS++ service" ([6]), sections 2.2 and 2.3. Section C.3 of this document adapts the grammar used in more recent descriptions of the Whois++ protocol to illustrate the syntax of the DAG/IP.
DAG/IPの入力相互作用は、RFC1835、「WHOISサービスのアーキテクチャ」（[6]）、セクション2.2および2.3で定義されています。このドキュメントのセクションC.3は、DAG/IPの構文を説明するために、WOHISプロトコルのより最近の説明で使用された文法を適応させます。
DAG/IP output will be a subset of what is defined in RFC1835, section 2.4, except that referral responses ("SERVER-TO-ASK") contain more information.
DAG/IP出力は、RFC1835、セクション2.4で定義されているもののサブセットになります。
The following sections are adapted from the Whois++ grammar. For discussion of the semantic intent of the query protocol, and other matters, see Whois++ RFC 1835 [6].
次のセクションは、Whoisの文法から採用されています。クエリプロトコルのセマンティック意図およびその他の問題の議論については、WHOIS RFC 1835 [6]を参照してください。
The following grammar, which uses the Augmented BNF (ABNF) notation as defined in [5], defines the set of acceptable DAG/IP input.
[5]で定義されている拡張BNF（ABNF）表記を使用する次の文法は、許容可能なDAG/IP入力のセットを定義します。
N.B.: As outlined in the ABNF definition, rule names and string literals are in the US-ASCII character set, and are case-insensitive. Also, when a character is written explicitly in the grammar, as for example ";", it represents the byte value of that character in all of the allowed character sets in their encodings used in this protocol. Specifically in UNICODE, ";" means the character U+003B, which when encoding the character in UTF-8 will generate the byte value 0x3B which is then used in the DAG/IP protocol.
N.B。：ABNF定義で概説されているように、ルール名と文字列リテラルはUS-ASCII文字セットにあり、ケース非感受性です。また、たとえば「;」など、文字が文法で明示的に書かれている場合、このプロトコルで使用されるエンコーディングのすべての許可されたキャラクターセットのバイト値を表します。具体的にはUnicode、 ";"UTF-8の文字をエンコードするときにバイト値0x3bを生成する文字u 003bを意味し、DAG/IPプロトコルで使用されます。
dagip-command = ( system-command [":" "hold"]
/ ri-query
/ sap-query ) nl
ri-query = ri-terms [":" globalcnstrnts]
ri-query = ri-terms ["：" globalcnstrnts]
sap-query = sap-terms [":" [sapcnstrnts][ ":" wdspinfo]]
system-command = "constraints"
/ "describe"
/ "commands"
/ "polled-by"
/ "polled-for"
/ "version"
/ "list"
/ "show" [1*sp datastring]
/ "help" [1*sp datastring]
/ "<NL>" [string]
ri-terms = ri-and-expr *(1*sp "or" 1*sp ri-and-expr)
ri-and-expr = ri-basic-expr *(1*sp "and" 1*sp ri-basic-
expr)
ri-basic-expr = ["not" 1*sp] ri-term / ( "(" ri-terms ")" )
ri-term = generalterm / specificterm / combinedterm
sap-terms = sap-and-expr *(1*sp "or" 1*sp sap-and-expr)
sap-and-expr = sap-basic-expr *(1*sp "and" 1*sp
sap-basic-expr)
sap-basic-expr = ["not" 1*sp] sap-term / ( "(" sap-terms ")" )
sap-term = ( generalterm / specificterm / combinedterm)
localcnstrnts
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）。一般的なタームの使用は、予期しない行動につながる可能性があるため、非推奨されます。したがって、キャップはプロトコルに含まれていても使用しないでください。
specificterm = specificname "=" datastring
specipyterm = specipyname "=" datastring
specificname = "handle" / "value"
combinedterm = attributename "=" datastring
combinedterm = astributeName "=" datastring
sapcnstrnts = sapcnstrnt *(";" sapcnstrnt)
sapcnstrnt = localcnstrnt / globalcnstrnt
localcnstrnts = [";search=" sap-searchvalue] [";case="
sap-casevalue]
localcnstrnt = "search=" sap-searchvalue / "case="
sap-casevalue
;N.B.: in the case where local and global constraints
; conflict, local constraints take precedence
; and overrides the global constraint
sap-searchvalue = "tstring" / searchvalue
sap-searchvalue = "tstring" / searchValue
sap-casevalue = "consider" / "ignore"
globalcnstrnts = globalcnstrnt *(";" globalcnstrnt)
globalcnstrnt = "search" "=" searchvalue / opt-globalcnst
Globalcnstrnt = "search" "=" searchvalue / opt-globalcnst
opt-globalcnst = "hold"
/ "case" "=" casevalue
/ "maxfull" "=" 1*digit
/ "maxhits" "=" 1*digit
/ "language" "=" language
/ "incharset" "=" characterset
/ "ignore" "=" attributename
/ "include" "=" attributename
; N.B.: If an attribute is named both with the "include" and "ignore"
; constraints, the attribute is to be included in the result, but the
; system message must be "% 112 Requested constraint not fulfilled".
language = <The language code defined in RFC1766>
characterset = "UNICODE-2-0-UTF-8"
searchvalue = "exact" / "substring" / "lstring"
casevalue = "ignore" / "consider"
wdspinfo = attrValAss *( ";" attrValAss )
attrValAss = attributename "=" datastring
attrvalass = aTtibutEname "=" 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の唯一の許可された属性は「ホスト」、「ポート」、「サーバーINFO」、「チャーセット」であることが決定されました。「charset」に関して、この属性の値は、「UTF-8」、「ISO8859-1」、「t \ .61」、または「us-ascii」の1つと定義されます。
datastring = 1*data-elt
attributename = 1*(<%d32-126 except specialbyte>)
; omit 127, which is DEL
data-elt = "\" specialbyte / normalbyte
data-elt = "\" SpecialByte / NormalByte
normalbyte = <%d32-255, except specialbyte>
specialbyte = " " / tab / "=" / "," / ":" / ";" / "\" /
"*" / "." / "(" / ")" / "[" / "]" / "^" /
"$" / "!" / "<NL>"
number = 1*digit
digit = "0" / "1" / "2" / "3" / "4" /
"5" / "6" / "7" / "8" / "9"
tab = %d09
sp = %d32 ; space
nl = %d13 %d10 ; CR LF
NOTE: Spaces (sp) that are significant to a query must be escaped.
The following characters, when significant to the query, may be
preceded and/or followed by a single space:
: ; , ( ) = !
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.
N.B。：ABNF定義で概説されているように、ルール名と文字列リテラルはUS-ASCII文字セットにあり、ケース非感受性です。また、たとえば「;」など、文字が文法で明示的に書かれている場合、このプロトコルで使用されるエンコーディングのすべての許可されたキャラクターセットのバイト値を表します。具体的にはUnicode、 ";"UTF-8の文字をエンコードするときにバイト値0x3bを生成する文字u 003bを意味し、DAG/IPプロトコルで使用されます。
server-resp = goodmessage mnl output mnl endmessage / badmessage nl endmessageclose
server-resp = goodmessage mnl output mnl endmessage / badmessage nl endmessageclose
output = 0*(full-record / server-to-ask)
full-record = "# FULL " template " " serverhandle " " localhandle system-nl 1*fulldata "# END" system-nl
full-record = "＃full"テンプレート "" serverhandle "" localhandle system-nl 1*fulldata "＃end" system-nl
TISDAG: serverhandle is:
tisdag：serverhandleは次のとおりです。
- Whois++, whatever the server-handle on the record returned by the WDSP. - LDAP, <hostname-without-periods><port> (because server DN's are not enforceably unique). E.g., a services.bunyip.com server on 7778 would become servicesbunyipcom7778.
- WHOIS、WDSPによって返されたレコードのサーバーハンドルが何であれ。-LDAP、<hostname-without-feriods> <port>（サーバーdnが強制的に一意ではないため）。たとえば、7778のservices.bunyip.comサーバーは、servicesbunyipcom7778になります。
localhandle is: - Whois++: the localhandle on the record returned by the WDSP - LDAP, it is the RDN (relative distinguished name), with spaces replaced by "_". E.g., cn=leslie_daigle
LocalHandleは次のとおりです。 -WHOIS：WDSP -LDAPによって返されたレコードのローカルハンドルは、RDN（相対的な著名な名前）であり、スペースは「_」に置き換えられます。たとえば、CN = Leslie_Daigle
server-to-ask = "# SERVER-TO-ASK " serverhandle system-nl server-to-askdata "# END" system-nl
Server-to-Ask = "＃Server-to-Ask" ServerHandle System-NL Server-to-AskData "＃end" System-nl
fulldata = " " attributename ": " attributevalue
system-nl
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
attributevalue = longstring
template = <%d32-%d255 except specialbyte>
serverhandle = <%d32-%d255 except specialbyte>
localhandle = <%d32-%d255 except specialbyte>
serverinfo = string
hostname = string
prot = string ; currently one of "ldapv2"
; "ldapv3" "whois++"
characterset = "UTF-8" / "T.61" / "ISO8859-1" / "US-ASCII"
source = string
longstring = string 0*( nl ( "+" / "-" ) string )
string = 0*(%d32-255)
string = 0*（％d32-255）
r-string = 0*(<%d32-126 except specialbyte>)
; omit 127 which is DEL
specialbyte = ":" / " "
mnl = 1*system-nl
system-nl = nl [ 1*(message nl) ]
System-nl = nl [1*（メッセージnl）]
nl = %d13 %d10 ; CR and LF
message = [1*( messagestart "-" string nl)]
messagestart " " string nl
messagestart = "% " digit digit digit
goodmessage = [1*( goodmessagestart "-" string nl)]
goodmessagestart " " string nl
goodmessagestart= "% 200"
goodmessagestart = "％200"
badmessage = [1*( badmessagestart "-" string nl)]
badmessagestart " " string nl
badmessagestart = "% 5" digit digit
BADMESSAGESTART = "％5"桁数字
endmessage = endmessageclose / endmessagecont
endmessageclose = [endmessagestart " " string nl]
byemessage
endmessagecont = endmessagestart " " string nl
endmessagecont = endmessagestart "" string nl
endmessagestart = "% 226"
endmessagestart = "％226"
byemessage = byemessagestart " " string nl
byemessage = byemessagestart "" string nl
byemessagestart = "% 203"
byemessagestart = "％203"
number = 1*( digit )
digit = "0" / "1" / "2" / "3" / "4" / "5" / "6" /
"7" / "8" / "9"
The following list and discussion of response codes is derived from the Whois++ protocol definition, RFC1835 ([6]).
応答コードの次のリストと議論は、WHOISプロトコル定義RFC1835（[6]）から派生しています。
A system message begins with a '%', followed by a space and a three digit number, a space, and an optional text message. The line message must be no more than 81 bytes long, including the terminating CR LF pair. There is no limit to the number of system messages that may be generated.
システムメッセージは「％」から始まり、その後にスペースと3桁の数字、スペース、およびオプションのテキストメッセージが続きます。ラインメッセージは、終了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.
％220-welcome to％220-the Whois server％220 at acme inc。
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要求された制約クエリの1つ以上の制約は、容認できない価値があるため、使用されませんでしたが、検索はまだ行われています。
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
204 Overgeneralized The server could not exactly
match the DAG query into its
native access protocol. The
resulting native query was
"looser".
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 <Token>後続の属性値は、<Token>で指定された文字セットでエンコードされます。
601 <token> Subsequent attribute values are in the language specified by <token>.
601 <token>後続の属性値は、<token>で指定された言語にあります。
601 DEF Subsequent attribute values are default values, i.e. they should be used for all languages not specified by "601 <token>" since last "601 ANY" message.
601 def後続の属性値はデフォルト値です。つまり、最後の「601任意の「任意の」メッセージ以降、「601 <token>」で指定されていないすべての言語に使用する必要があります。
601 ANY Subsequent attribute values are for all languages.
601後続の属性値はすべての言語のものです。
Table C.1 List of system response codes
表C.1システム応答コードのリスト
Appendix D - DAG/IP Response Messages Mapping
付録D- DAG/IP応答メッセージマッピング
LDAPv2/v3 DAG/IP
--------------------------------------- ---------------------
success (0) v2&v3 200 Command Ok
operationsError (1) v2&v3 505 Operations error
protocolError (2) v2&v3 505 Operations error
timeLimitExceeded (3) v2&v3 404 Timeout
sizeLimitExceeded (4) v2&v3 110 To many hits
compareFalse (5) v2&v3 200 OK
compareTrue (6) v2&v3 200 OK
authMethodNotSupported (7) v2&v3 505 Operations error
strongAuthRequired (8) v2&v3 505 Operations error
referral (10) v3 200 OK
adminLimitExceeded (11) v3 110 Too many hits
unavailableCriticalExtension (12) v3 505 Operations error
confidentialityRequired (13) v3 505 Operations error
saslBindInProgress (14) v3 N.A.
noSuchAttribute (16) v2&v3 200 OK
undefinedAttributeType (17) v2&v3 500 Syntax error
inappropriateMatching (18) v2&v3 500 Syntax error
constraintViolation (19) v2&v3 111 Requested constraint
not supported
attributeOrValueExists (20) v2&v3 200 OK
invalidAttributeSyntax (21) v2&v3 500 Syntax error
noSuchObject (32) v2&v3 200 OK
aliasProblem (33) v2&v3 505 Operations error
invalidDNSyntax (34) v2&v3 500 Syntax error
isLeaf (35) v2 N.A.
aliasDereferencingProblem (36) v2&v3 505 Operations error
inappropriateAuthentication (48) v2&v3 500 Syntax error
invalidCredentials (49) v2&v3 403 Information Unavailable
insufficientAccessRights (50) v2&v3 403 Information Unavailable
busy (51) v2&v3 403 Information Unavailable
unavailable (52) v2&v3 401 Service not available
unwillingToPerform (53) v2&v3 505 Operations error
loopDetect (54) v2&v3 505 Operations error
namingViolation (64) v2&v3 N.A.
objectClassViolation (65) v2&v3 N.A.
notAllowedOnNonLeaf (66) v2&v3 N.A.
notAllowedOnRDN (67) v2&v3 N.A.
entryAlreadyExists (68) v2&v3 N.A.
objectClassModsProhibited (69) v2&v3 N.A.
affectsMultipleDSAs (71) v3 N.A.
other (80) v2&v3 403 Information Unavailable
Table D.1 LDAPv2/v3 resultcodes to DAG/IP response codes
mapping
DAG/IP LDAP v2/v3
--------------------------------------- --------------------------
110 Too many hits sizeLimitExceeded (4)
111 Requested constraint not supported constraintViolation (19)
112 Requested constraint not fullfilled constraintViolation (19)
200 Command Ok Success (0)
201 Command Completed successfully N.A.
203 Bye N.A.
204 Overgeneralized N.A.
220 Service Ready N.A.
226 Transaction complete N.A.
401 Service not available unavailable (52)
402 Search expression too complicated unwillingToPerform (53)
403 Information Unavailable busy (51)
404 Time out timeLimitExceeded (3)
405 Operations error operationsError (1)
500 Syntax error protocolError (2)
502 Search expression too complicated unwillingToPerform (53)
503 Query to general unwillingToPerform (53)
505 Operations error operationsError (1)
600 <token> N.A.
601 <token> N.A.
601 DEF N.A.
601 ANY N.A.
Table D.2 Mapping from DAG/IP response codes to LDAPv2/v3 resultcodes
表D.2 DAG/IP応答コードからLDAPV2/V3結果コードへのマッピング
DAG/IP Whois++
-------------------------------------- -----------------------------
110 Too Many hits 110 Too Many hits
111 Requested constraint not supported 111 Requested constraint not
supported
112 Requested constraint not fullfilled 112 Requested constraint not
fullfilled
200 Command Ok 200 Command Ok
201 Command Completed successfully 201 Command Completed
successfully
401 Service not available 401 Service not available
403 Information Unavailable 403 Information not available
404 Timeout 404 Timeout
405 Operations error 405 Operations error
500 Syntax error 500 Syntax error
502 Search expression too complicated 502 Search expression too
complicated
503 Query to general 506 Query to general
505 Operations error 505 Operations error
Table D.3 Mapping between DAG/IP and Whois++ response codes
表D.3 DAG/IPとWHOIS応答コードのマッピング
Appendix E - DAG CIP Usage
付録E- DAG CIPの使用
The CIP object used by the DAG system is based on the Tagged Index Object as defined in [12]. The grammar, adapted from that Work in Progress, for the specific object used by the DAG is as follows:
DAGシステムで使用されるCIPオブジェクトは、[12]で定義されているタグ付きインデックスオブジェクトに基づいています。DAGで使用される特定のオブジェクトのために、進行中のその作業から適応した文法は次のとおりです。
index-object = 0*(io-part SEP) io-part
io-part = header SEP schema-spec SEP index-info
header = version-spec SEP update-type SEP this-update SEP
last-update context-size
version-spec = "version:" *SPACE "x-tagged-index-1"
update-type = "updatetype:" *SPACE ( "total" |
( "incremental" [*SPACE "tagbased"|"uniqueIDbased" ])
this-update = "thisupdate:" *SPACE TIMESTAMP
last-update = [ "lastupdate:" *SPACE TIMESTAMP SEP]
context-size = [ "contextsize:" *SPACE 1*DIGIT SEP]
schema-spec = "BEGIN IO-Schema" SEP 1*(schema-line SEP)
"END IO-Schema"
schema-line = attribute-name ":" token-type
token-type = "TOKEN"
index-info = full-index | incremental-index
full-index = "BEGIN Index-Info" SEP 1*(index-block SEP)
"END Index-Info"
incremental-index = 1*(add-block | delete-block | update-block)
add-block = "BEGIN Add Block" SEP 1*(index-block SEP)
"END Add Block"
delete-block = "BEGIN Delete Block" SEP 1*(index-block SEP)
"END Delete Block"
update-block = "BEGIN Update Block" SEP
0*(old-index-block SEP)
1*(new-index-block SEP)
"END Update Block"
old-index-block = "BEGIN Old" SEP 1*(index-block SEP)
"END Old"
new-index-block = "BEGIN New" SEP 1*(index-block SEP)
"END New"
index-block = first-line 0*(SEP cont-line)
first-line = attr-name ":" *SPACE taglist "/" attr-value
cont-line = "-" taglist "/" attr-value
taglist = tag 0*("," tag) | "*"
tag = 1*DIGIT ["-" 1*DIGIT]
attr-value = 1*(UTF8)
attr-name = dag-searchattr / "objectclass"
dag-searchattr = "FN" / "LOC" / "ROLE" / "ORG"
TIMESTAMP = 1*DIGIT
NAMECHAR = DIGIT | UPPER | LOWER | "-" | ";" | "."
SPACE = <ASCII space, %x20>;
SEP = (CR LF) | LF
CR = <ASCII CR, carriage return, %x0D>;
LF = <ASCII LF, line feed, %x0A>;
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"
US-ASCII-SAFE = %x01-09 / %x0B-0C / %x0E-7F
;; US-ASCII except CR, LF, NUL
UTF8 = US-ASCII-SAFE / UTF8-1 / UTF8-2 / UTF8-3
/ UTF8-4 / UTF8-5
UTF8-CONT = %x80-BF
UTF8-1 = %xC0-DF UTF8-CONT
UTF8-2 = %xE0-EF 2UTF8-CONT
UTF8-3 = %xF0-F7 3UTF8-CONT
UTF8-4 = %xF8-FB 4UTF8-CONT
UTF8-5 = %xFC-FD 5UTF8-CONT
N.B.: The only tokenization type permitted is "TOKEN". While the Tagged Index Object memo permits the use of "FULL" (i.e., the entire value of the attribute is preserved as a single token), that has the danger of yielding a unique token for every record. Studies in the growth of centroid sizes as a function of number of records (see [14]) demonstrate that such unique tokens (e.g., phone numbers) are to be avoided. While storing tag information requires some number of extra bytes of storage per token index entry, using unique tokens causes the number of token entries in the index to continue to grow linearly with the number of records, thereby affecting search efficiency.
N.B。：許可される唯一のトークン化タイプは「トークン」です。タグ付きインデックスオブジェクトメモでは、「完全」（つまり、属性の値全体が単一のトークンとして保存されます）の使用が許可されていますが、それはすべてのレコードに一意のトークンを生成する危険性があります。記録の数の関数としての重心サイズの成長に関する研究（[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.
属性「ObjectClass」は、このインデックスオブジェクトに要約されているデータのレコード/オブジェクトタイプを示すために使用されます。
Values for the objectclass attribute should be restricted to: dagperson or dagrole, the two DAG schema object types.
ObjectClass属性の値は、DagpersonまたはDagrole、2つのDAGスキーマオブジェクトタイプに制限する必要があります。
WDSPs are expected to create index objects following the general principles outlined in the Whois++ protocol documentation (creation of centroids) and the Tagged Index Object documentation ([12]). Following the syntax described above, the index object contains token information for each attribute in the DAGSchema:
WDSPは、WHOISプロトコルドキュメント（Centroidの作成）とタグ付きインデックスオブジェクトドキュメント（[12]）に概説されている一般原則に従ってインデックスオブジェクトを作成することが期待されています。上記の構文に従って、インデックスオブジェクトには、ダグスケマの各属性のトークン情報が含まれています。
- a list of all the unique tokens (strings delimited by the specified characters) that appear in the WDSP database for the attribute - for each token in that list, which records the token appears in
- 属性のWDSPデータベースに表示されるすべての一意のトークン（指定された文字によって区切られた文字列）のリスト - そのリストの各トークンについて、トークンを記録します。
So, for example,
たとえば、
Record #1: FN: Foo Bar ORG: The Snack Bar
レコード＃1：fn：foo bar org：スナックバー
Record #2: FN: Bar Smith ORG: Snack Shack
レコード＃2：FN：バースミス組織：スナックシャック
yields (conceptually) the following information for the attribute FN:
（概念的に）属性FNの次の情報を生成します。
Foo (1), Bar (1,2), Smith (2)
foo（1）、bar（1,2）、Smith（2）
and the following information for the attribute 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-Tagged-Index-1 Update-Type：Total This-Update：855938804
last-update: context-size: BEGIN IO-Schema objectclass: TOKEN
Last-Update：Context-Size：IO-Schema objectClassを開始：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：トークン組織：トークンエンドio -schema begin index -info objectclass： */dagperson fn：1/foo -1,2/bar -2/smith org：1/the -1,2/snack -1/bar -2/Shack End Index-info
TISDAG: Within the project it has been decided to base consistency between updates on consistent tags. This means that if the update-type is "incremental" the specifier must be "tagbased".
TISDAG：プロジェクト内では、一貫したタグの更新間の一貫性の基礎となることが決定されました。これは、更新型が「増分」の場合、指定子が「タグベース」でなければならないことを意味します。
It is beyond the scope of this document to define how WDSP servers shall be registered with the DAG Referral Index. Such a procedure must be defined, and the following information established for each WDSP dataset (adapted from the Tagged Index Object specification, [12]): dsi: An OID which uniquely identifies the subtree and scope of the dataset for which the index object is created.
このドキュメントの範囲を超えて、WDSPサーバーをDAG紹介インデックスに登録する方法を定義することです。このような手順を定義する必要があり、各WDSPデータセット（タグ付きインデックスオブジェクト仕様から編集された[12]から編集された）に確立された以下の情報：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).
Base-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.
Source-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：インデックスの特定の使用法をサポートしたいインデックスサーバーのすべてのセットは、インデックスオブジェクトで使用する属性に同意する必要があります。参加ディレクトリサーバーは、ローカルアトリビネーションからインデックスで使用される属性へのマッピングにも同意する必要があります。1つの特定のインデックスサーバーがそのようないくつかのセットに関与する可能性があるため、更新を適切なインデックスセットに接続する方法が必要です。これに対する可能な解決策の1つは、異なるDSIを使用することです。
consistencybase: How consistency of the index is maintained over incremental updates: complete - every change or delete concerning one object has to contain all tokens connected to that object. This method must be supported by any server who wants to comply with this standard tagbased - starting at a full update every incremental update referring back to this full updated has to maintain state-information regarding tags, such that a object within the original database is assigned the same tagnumber every time. This method is optional.
CONSTENCENCEBASE：インデックスの一貫性がインクリメンタルアップデートでどのように維持されているか：完了 - 1つのオブジェクトに関するすべての変更または削除が、そのオブジェクトに接続されたすべてのトークンを含める必要があります。このメソッドは、この標準のタグベースに準拠したいサーバーによってサポートする必要があります - 完全な更新から始まるこの完全な更新は、タグに関する状態情報を維持する必要があります。毎回同じ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.
uniqueID-データセット内のすべてのオブジェクトには、インデックス内の特定の属性に対して一意の値が必要です。このような属性の例は、DistinguedName属性です。この方法もオプションです。
securityoption: Whether and how the supplier server should sign and encrypt the update before sending it to the consumer server. Options for this version of the DAG service are "none": the update is sent in plaintext "PGP/MIME": the update is digitally signed and encrypted using PGP (see [7]). PGP/MIME is recommended.
SecurityOption：サプライヤーサーバーが消費者サーバーに送信する前に、サプライヤーサーバーがアップデートに署名して暗号化するかどうか、および方法。このバージョンのDAGサービスのオプションは「なし」です。アップデートはプレーンテキスト「PGP/MIME」で送信されます。アップデートは、PGPを使用してデジタル署名および暗号化されます（[7]を参照）。PGP/MIMEをお勧めします。
security credentials: The long-term cryptographic credentials used for key exchange and authentication of the consumer and supplier servers, if a security option was selected. For "PGP/MIME", this will be the trusted public keys of both servers.
セキュリティ資格情報：セキュリティオプションが選択された場合、消費者およびサプライヤーサーバーの主要な交換と認証に使用される長期的な暗号化資格情報。「PGP/MIME」の場合、これは両方のサーバーの信頼できる公開キーになります。
CIP Index Objects are sent to the DAG Referral Index by MIME-encoded SMTP, following the Common Indexing Protocol specification (see [2] and [3]).
CIPインデックスオブジェクトは、共通のインデックス作成プロトコル仕様に従って、MIMEエンコードSMTPによってDAG紹介インデックスに送信されます（[2]および[3]を参照）。
Appendix F - Summary of Technical Survey Results
付録F-技術調査結果の概要
As part of the TISDAG project, a technical survey was carried out -- announced on the tisdag@swip.net mailing list, all Swedish WDSPs (and potential WDSPs) were encouraged to fill out and submit the WWW-based survey form (see http://tisdag.sunet.se/tisdag-survey.html).
TISDAGプロジェクトの一環として、Tisdag@swip.netメーリングリストで発表された技術調査が実施されました。すべてのスウェーデンのWDSP（および潜在的なWDSP）は、WWWベースの調査フォームに記入して提出するよう奨励されました（httpを参照：//tisdag.sunet.se/tisdag-survey.html）。
The survey was carried out in May, 1997. Response was not as good as had been hoped -- in the end, 5 WDSPs participated. We had hoped for more responses than this, in order to have a concrete sense of directory service providers' current and planned status. However, informal "hallway" conversations with a few people at Interoperabilitet'97 in Sollentuna suggest that, while people see the TISDAG project as an important and timely step, they don't necessarily have an immediate understanding of how it will impact them, and what they can/should contribute. So, the results can be seen as informational, though not a definitive statement of the whole directory service picture in Sweden.
調査は1997年5月に実施されました。応答は期待されていたほど良くありませんでした。最終的には、5つのWDSPが参加しました。ディレクトリサービスプロバイダーの現在および計画されたステータスの具体的な感覚を持つために、私たちはこれよりも多くの回答を望んでいました。しかし、ソレントゥナの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は、WDSPによって現在サポートされており、今後12か月間計画されているクエリの種類に関する調査からの情報をまとめたものです。調査の時点で、役割ごとの検索の要件は提案されていなかったため、調査ではWDSPがDagperson Schema Protocol-equivalentsの両方をサポートしているかどうかを具体的に尋ねなかったことに注意してください（すなわち、LDAPのWHOISとInetORGPerson ObjectClassのユーザーテンプレート）。テーブルの中で、「完全な情報？」という列があります。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
3 N、NL、NOLロールLDAPV2、DAP、HTTP LDAPV2、LDAPV3、DAP、HTTPを除く
4 N,NO,NL,NOL Except ROLE Whois++,HTTP LDAPv3,Whois++,
HTTP,E-mail
5 N,NO,NL,NOL Except ROLE LDAPv2,Whois LDAPv2,LDAPv3, Whois++,HTTP Whois,Whois++,PH, Finger,HTTP
5 n、no、nl、nolロールldapv2、whois ldapv2、ldapv3、whois、http whois、whois、ph、finger、http
Table F.1 Summary of TISDAG Survey Results: Queries
表F.1 TISDAG調査結果の概要：クエリ
Resp # of Records (now) # of Records (12 months) Character Sets
----- ------------------ ------------------------ --------------
1 94 280 120 000 - 130 000 ISO-8859-1
2 88 000 100 000 ISO-8859-1
3 N/A 100 000 T.61 (Telex)
4 150 000 250 000 ISO-8859-1
UTF-8 UNICODE
5 4 300 10 000 ISO-8859-1
Table F.2 Summary of TISDAG Survey Results: Operational Information
表F.2 TISDAG調査結果の概要：運用情報
Appendix G - Useful References
付録G-有用な参照
N.B.: The following is a collection of Internet standards documents (RFCs) and Internet-Drafts from which the material in this report was drawn. Internet-Drafts are works-in-progress, and are not meant to be cited. Where they are used in this document, references are to the text contained in the Internet-Draft; i.e., they are not meant to imply standards, so much as useful starting points for the work of this project.
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] Allen、J。and 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] Allen、J。およびM. Mealing、「共通インデックスプロトコル（CIP）のMIMEオブジェクト定義」、RFC 2652、1999年8月。
[3] Allen, J. and P. Leach, "CIP Transport Protocols", RFC 2653, August 1999.
[3] Allen、J。およびP. Leach、「CIP Transport Protocols」、RFC 2653、1999年8月。
[4] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[4] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。
[5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[5] Crocker、D。、「構文仕様のための拡張BNF：ABNF」、RFC 2234、1997年11月。
[6] Deutsch, P., Schoultz, R., Falstrom, P. and C. Weider, "Architecture of the WHOIS++ Service", RFC 1835, July 1995.
[6] Deutsch、P.、Schoultz、R.、Falstrom、P。and C. Weider、「Whois Serviceの建築」、RFC 1835、1995年7月。
[7] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
[7] Elkins、M。、「Pretty Good Privacy（PGP）のMime Security」、RFC 2015、1996年10月。
[8] Patrik Faltstrom, Martin Hamilton, Leslie L. Daigle, "WHOIS++ templates", Work in Progress.
[8] Patrik Faltstrom、Martin Hamilton、Leslie L. Daigle、「Whois Templates」は進行中です。
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Interent Message Bodies", RFC 2045, November 1996.
[9] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[10] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[10] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[11] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
[11] Good、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] Hedberg、R.、Greenblatt、B.、Moats、R。、およびM. Wahl、「共通インデックスプロトコルで使用するタグ付きインデックスオブジェクト」、RFC 2654、1999年8月。
[13] Howes, R., "A String Representation of LDAP Search Filters", RFC 1960, June 1996.
[13] Howes、R。、「LDAP検索フィルターの文字列表現」、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] Paul Panotzki、「共通インデックスプロトコルの複雑さ：インデックスサーバーメッシュの検索時間の予測」、Master's論文、KTH、1996年9月。
[15] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[15] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
[16] Smith, M., "Definition of the inetOrgPerson Object Class", RFC 2798, April 2000.
[16] Smith、M。、「Inetorgpersonオブジェクトクラスの定義」、RFC 2798、2000年4月。
[17] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[17] Wahl、M.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年12月。
[18] Wahl, M., "A summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997.
[18] Wahl、M。、「LDAPV3で使用するX.500（96）ユーザースキーマの要約」、RFC 2256、1997年12月。
[19] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995.
[19] Yeong、W.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol」、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 Consortium、「Unicode Standard-バージョン2.0」、Addison-Wesley、1996。
Authors' Addresses
著者のアドレス
Leslie L. Daigle Thinking Cat Enterprises
レスリーL.デイグル思考猫企業
EMail: leslie@thinkingcat.com
Roland Hedberg Catalogix Jegerveien 25 0777 Oslo Norway
Roland Hedberg Catalogix Jegerveien 25 0777 Oslo Norway
Phone: +47 23 08 29 96
EMail: Roland@catalogix.se
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。