RFC2967 日本語訳
2967 TISDAG - Technical Infrastructure for Swedish Directory AccessGateways. L. Daigle, R. Hedberg. October 2000. (Format: TXT=209845 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Daigle
Request for Comments: 2967 Thinking Cat Enterprises
Category: Informational R. Hedberg
Catalogix
October 2000
Daigleがコメントのために要求するワーキンググループL.をネットワークでつないでください: 2967年の考え深い猫エンタープライズカテゴリ: 情報のR.ヘドバーグCatalogix2000年10月
TISDAG - Technical Infrastructure for
Swedish Directory Access Gateways
TISDAG--スウェーデンのディレクトリアクセスゲートウェイへの技術インフラ
Status of this Memo
この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)インターネット協会(2000)。 All rights reserved。
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(スウェーデンのディレクトリAccess Gatewaysのための技術的なInfrastructure)では、プロジェクトのDAG提案はスウェーデン人のインターネットユーザの情報のためのただ一つのアクセスしているポイントのサービスを提供するために必要な技術インフラを定義するということです。 結果として起こるサービスはすべての情報のための一定のアクセスを提供するでしょう--同じレベルの情報入手(7×24サービス)、および情報、それらの電話番号案内プロトコル、またはエンドユーザのクライアントアクセスが議定書を作ると主張するのに責任があるサービスプロバイダーの如何にかかわらず利用可能にされた同じ情報。
Table of Contents
目次
1.0 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Project Goal. . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Executive Summary of Technical Study Result . . . . . . . . . 5 1.3 Document Overview . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.0 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 End-User Requirements . . . . . . . . . . . . . . . . . . . . 8 2.2 WDSPs Requirements. . . . . . . . . . . . . . . . . . . . . . 8 2.3 DAG-System Requirements . . . . . . . . . . . . . . . . . . . 9 3.0 Functional Specification. . . . . . . . . . . . . . . . . . . 9 3.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 The DAG Core. . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3 Client Interface. . . . . . . . . . . . . . . . . . . . . . . 11 3.3.1 Acceptable User Input . . . . . . . . . . . . . . . . . . . 12
1.0序論。 . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1は目標を映し出します。 . . . . . . . . . . . . . . . . . . . . . . . . 5 技術的な研究結果. . . . . . . . . 5 1.3ドキュメント概観. . . . . . . . . . . . . . . . . . . . . . 6 1.4用語. . . . . . . . . . . . . . . . . . . . . . . . . 7 2.0要件の1.2要約。 . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 エンドユーザ要件. . . . . . . . . . . . . . . . . . . . 8 2.2WDSPs要件。 . . . . . . . . . . . . . . . . . . . . . 8 2.3 縁飾りシステム要求の.93.0の機能的な仕様。 . . . . . . . . . . . . . . . . . . 9 3.1概観。 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 縁飾りコア。 . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3クライアントインタフェース。 . . . . . . . . . . . . . . . . . . . . . . 11 3.3の.1の許容できるユーザ入力. . . . . . . . . . . . . . . . . . . 12
Daigle & Hedberg Informational [Page 1] RFC 2967 TISDAG October 2000
[1ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
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
質問タイプを支持しました。 . . . . . . . . . . . . . . . . . . . . 12 合っている意味論. . . . . . . . . . . . . . . . . . . . . . 12文字コード. . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.2のデータが仕様を出力しました。 . . . . . . . . . . . . . . . . . . . . . 14 図式定義。 . . . . . . . . . . . . . . . . . . . . . . 14 紹介定義。 . . . . . . . . . . . . . . . . . . . . . 14のエラー条件. . . . . . . . . . . . . . . . . . . . . . . 14 3.4のディレクトリServer Interface。 . . . . . . . . . . . . . . . . . 14 4.0 構造。 . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1個のソフトウェアコンポーネント. . . . . . . . . . . . . . . . . . . . . 15 4.1.1の内部のコミュニケーション. . . . . . . . . . . . . . . . . . 15 4.1.2紹介インデックス。 . . . . . . . . . . . . . . . . . . . . . . 15 4.1 .3 縁飾りキャップ。 . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1 .4 縁飾り体液。 . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2 重要な建築注意. . . . . . . . . . . . . . . . 17 4.2.1 2別個の機能: 紹介と推論. . . . . . . 17 4.2.2株式会社質問と応答意味論。 . . . . . . . . . . . 17 4.2 .3 目に見えること。 . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2 .4 Query意味論. . . . . . . . . . . . . . . . 18 4.2.5N+MプロトコルMappings. . . . . . . . . . . . . . . . . . . 18 4.2.6DAG-CAPsとDAG-SAPsの豊かは互いから完全に独立しています。 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2 .7、DAG-CAPのRole、.184.2、.8、DAG-SAP.194.2.9DAG/IPのRoleは内部です。 . . . . . . . . . . . . . . . . . . . . 19 4.2 .10の期待. . . . . . . . . . . . . . . . . . . . . . . 19 4.2.11の今後の拡大。 . . . . . . . . . . . . . . . . . . . . 19 5.0 ソフトウェア仕様. . . . . . . . . . . . . . . . . . . 19 5.1の記号法のコンベンション. . . . . . . . . . . . . . . . . . . . 19 5.2縁飾りキャップ基礎。 . . . . . . . . . . . . . . . . . . . . . . . 20 5.2 .1 機能性. . . . . . . . . . . . . . . . . . . . . . . 20 5.2.2Configuration. . . . . . . . . . . . . . . . . . . . . . . 21 5.2.3Error取り扱い。 . . . . . . . . . . . . . . . . . . . . . . 21 5.2 .4 結果を取り除きます。 . . . . . . . . . . . . . . . . . . . . 22 5.3 縁飾りSAP基礎。 . . . . . . . . . . . . . . . . . . . . . . . 22 5.3 .1 機能性. . . . . . . . . . . . . . . . . . . . . . . 22 5.3.2Configuration. . . . . . . . . . . . . . . . . . . . . . . 23 5.3.3Error取り扱い。 . . . . . . . . . . . . . . . . . . . . . . 23 5.3 .4 結果を取り除きます。 . . . . . . . . . . . . . . . . . . . . 23 5.3 .5規制先行、.235.4 Referral Index。 . . . . . . . . . . . . . . . . . . . . . 24 5.4 .1 構造。 . . . . . . . . . . . . . . . . . . . . . . . 24 5.4 WDSPs(CIP). . . . . . . . . . . . . . . 24 5.4.3との.2回の相互作用が物の形式. . . . . . . . . . . . . . . . . . . . 24 5.4.4の縁飾り内部の入出力に索引をつけます。 . . . . . . . . . . . . . . . . . . . . . 24 5.4 .5 インデックスサーバ…、24、5.4.6構成、.255.4、.7セキュリティ . . . . . . . . . . . . . . . . . . . . . . . . . 25
Daigle & Hedberg Informational [Page 2] RFC 2967 TISDAG October 2000
[2ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
5.5 Mail (SMTP) DAG-CAP . . . . . . . . . . . . . . . . . . . . . 25
5.5.1 Mail DAG-CAP Input. . . . . . . . . . . . . . . . . . . . . 26
5.5.2 Translation from Mail query to DAG/IP . . . . . . . . . . . 28
Querying the Referral Index. . . . . . . . . . . . . . . . . . 28
Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 29
5.5.3 Chaining queries in Mail DAG-CAP. . . . . . . . . . . . . . 31
5.5.4 Expression of results in Mail DAG-CAP . . . . . . . . . . . 31
5.5.5 Expression of Errors in Mail DAG-CAP. . . . . . . . . . . . 31
5.6 Web (HTTP) DAG-CAP. . . . . . . . . . . . . . . . . . . . . . 32
5.6.1 Web DAG-CAP Input . . . . . . . . . . . . . . . . . . . . . 32
5.6.2 Translation from Web query to DAG/IP. . . . . . . . . . . . 33
Querying a DAG-SAP Directly. . . . . . . . . . . . . . . . . . 33
Querying the Referral Index. . . . . . . . . . . . . . . . . . 33
Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 35
5.6.3 Chaining queries in Web DAG-CAP . . . . . . . . . . . . . . 36
5.6.4 Expression of results in Web DAG-CAP. . . . . . . . . . . . 36
text/html results. . . . . . . . . . . . . . . . . . . . . . . 36
application/whoispp-response Results . . . . . . . . . . . . . 37
5.6.5 Expression of Errors in Web DAG-CAP . . . . . . . . . . . . 37
Standard Errors. . . . . . . . . . . . . . . . . . . . . . . . 38
5.7 Whois++ DAG-CAP . . . . . . . . . . . . . . . . . . . . . . . 38
5.7.1 Whois++ DAG-CAP Input . . . . . . . . . . . . . . . . . . . 38
5.7.2 Translation from Whois++ query to DAG/IP. . . . . . . . . . 39
Querying the Referral Index. . . . . . . . . . . . . . . . . . 39
Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 39
5.7.3 Chaining in Whois++ DAG-CAP . . . . . . . . . . . . . . . . 40
5.7.4 Expression of results in Whois++. . . . . . . . . . . . . . 41
5.7.5 Expression of Errors in Whois++ DAG-CAP . . . . . . . . . . 41
5.8 LDAPv2 DAG-CAP. . . . . . . . . . . . . . . . . . . . . . . . 42
5.8.1 LDAPv2 DAG-CAP Input. . . . . . . . . . . . . . . . . . . . 42
5.8.2 Translation from LDAPv2 query to DAG/IP . . . . . . . . . . 44
Querying the Referral Index. . . . . . . . . . . . . . . . . . 44
Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 46
5.8.3 Chaining queries in LDAPv2 DAG-CAP. . . . . . . . . . . . . 48
5.8.4 Expression of results in LDAPv2 . . . . . . . . . . . . . . 48
5.8.5 Expression of Errors in LDAPv2 DAG-CAP. . . . . . . . . . . 48
5.9 LDAPv3 DAG-CAP. . . . . . . . . . . . . . . . . . . . . . . . 50
5.9.1 LDAPv3 DAG-CAP Input. . . . . . . . . . . . . . . . . . . . 50
5.9.2 Translation from LDAPv3 query to DAG/IP . . . . . . . . . . 51
Querying the Referral Index. . . . . . . . . . . . . . . . . . 51
Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 54
5.9.3 Chaining queries in LDAPv3 DAG-CAP. . . . . . . . . . . . . 55
5.9.4 Expression of results in LDAPv3 . . . . . . . . . . . . . . 55
5.9.5 Expression of Errors in LDAPv3 DAG-CAP. . . . . . . . . . . 56
5.10 Whois++ DAG-SAP. . . . . . . . . . . . . . . . . . . . . . . 57
5.10.1 Input. . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.10.2 Translation from DAG/IP to Whois++ query . . . . . . . . . 58
5.10.3 Translation of Whois++ results to DAG/IP . . . . . . . . . 58
5.5は.1メール縁飾りキャップが入力した(SMTP)縁飾りキャップ.255.5を郵送します。 . . . . . . . . . . . . . . . . . . . . 26 5.5 .2 メール質問からDAG/IP. . . . . . . . . . . 28Querying Referral Indexまでの翻訳。 . . . . . . . . . . . . . . . . . 28 .295.5にDAG-SAPについて質問して、.3ChainingはメールでDAG-CAPについて質問します。 . . . . . . . . . . . . . 31 5.5 .4 メールDAG-CAPのErrorsのメールDAG-CAP. . . . . . . . . . . 31 5.5.5Expressionの結果の表現。 . . . . . . . . . . . 31 5.6ウェブ(HTTP)縁飾りキャップ。 . . . . . . . . . . . . . . . . . . . . . 32 5.6 .1 ウェブ質問からDAG/IPまでのウェブDAG-CAP Input. . . . . . . . . . . . . . . . . . . . . 32 5.6.2Translation。 . . . . . . . . . . . 33 直接縁飾りSAPについて質問します。 . . . . . . . . . . . . . . . . . 33 紹介インデックスについて質問します。 . . . . . . . . . . . . . . . . . .3ChainingがウェブDAG-CAPで質問するDAG-SAP.355.6について質問する33、.365.6、.4Expression、ウェブDAG-CAPの結果について。 . . . . . . . . . . . 36 テキスト/htmlは結果として生じます。 . . . . . . . . . . . . . . . . . . . . . . 36 ウェブDAG-CAP. . . . . . . . . . . . 37Standard ErrorsのErrorsのwhoisppアプリケーション/応答Results. . . . . . . . . . . . . 37 5.6.5Expression。 . . . . . . . . . . . . . . . . . . . . . . . 38 5.7Whois++DAG-CAP. . . . . . . . . . . . . . . . . . . . . . . 38 5.7.1Whois++DAG-CAP Input、.385.7、.2Translation、Whois++質問からDAG/IPまで。 . . . . . . . . . 39 紹介インデックスについて質問します。 . . . . . . . . . . . . . . . . . DAG-SAPについて質問する39、.395.7、.3Chaining、Whois++DAG-CAP、.405.7、.4Expression、Whois++の結果… 41 5.7 .5 Whois++DAG-CAP.415.8LDAPv2 DAG-CAPのErrorsのExpression。 . . . . . . . . . . . . . . . . . . . . . . . 42 5.8 .1LDAPv2縁飾りキャップ入力。 . . . . . . . . . . . . . . . . . . . 42 5.8 .2 LDAPv2質問からDAG/IP. . . . . . . . . . 44Querying Referral Indexまでの翻訳。 . . . . . . . . . . . . . . . . . 44 .3ChainingがLDAPv2 DAG-CAPで質問するDAG-SAP.465.8について質問します。 . . . . . . . . . . . . 48 5.8 .4 LDAPv2 DAG-CAPのErrorsのLDAPv2. . . . . . . . . . . . . . 48 5.8.5Expressionの結果の表現。 . . . . . . . . . . 48 5.9LDAPv3縁飾りキャップ。 . . . . . . . . . . . . . . . . . . . . . . . 50 5.9 .1LDAPv3縁飾りキャップ入力。 . . . . . . . . . . . . . . . . . . . 50 5.9 .2 LDAPv3質問からDAG/IP. . . . . . . . . . 51Querying Referral Indexまでの翻訳。 . . . . . . . . . . . . . . . . . 51 .3ChainingがLDAPv3 DAG-CAPで質問するDAG-SAP.545.9について質問します。 . . . . . . . . . . . . 55 5.9 .4 LDAPv3 DAG-CAPのErrorsのLDAPv3. . . . . . . . . . . . . . 55 5.9.5Expressionの結果の表現。 . . . . . . . . . . 56 5.10 +縁飾りWhois+体液。 . . . . . . . . . . . . . . . . . . . . . . 57 5.10.1 入力。 . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.10.2 DAG/IPからWhois++質問までの翻訳、.58 5.10、.3Translation、DAG/IP. . . . . . . . . 58へのWhois++結果
Daigle & Hedberg Informational [Page 3] RFC 2967 TISDAG October 2000
[3ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
5.11 LDAPv2 DAG-SAP . . . . . . . . . . . . . . . . . . . . . . . 59
5.11.1 Input. . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.11.2 Translation from DAG/IP to LDAPv2 query. . . . . . . . . . 59
5.11.3 Translation of LDAPv2 results to DAG/IP. . . . . . . . . . 61
5.12 LDAPv3 DAG-SAP . . . . . . . . . . . . . . . . . . . . . . . 62
5.12.1 Input. . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.12.2 Translation from DAG/IP to LDAPv3 query. . . . . . . . . . 62
5.12.3 Translation of LDAPv3 results to DAG/IP. . . . . . . . . . 64
5.13 Example Queries. . . . . . . . . . . . . . . . . . . . . . . 64
5.13.1 A Whois++ Query. . . . . . . . . . . . . . . . . . . . . . 65
What the Whois++ DAG-CAP Receives. . . . . . . . . . . . . . . 65
What the Whois++ DAG-CAP sends to the Referral Index . . . . . 65
What the Whois++ DAG-CAP Sends to an LDAP DAG-SAP. . . . . . . 65
5.13.2 An LDAP Query. . . . . . . . . . . . . . . . . . . . . . . 66
What the LDAP DAG-CAP Receives . . . . . . . . . . . . . . . . 66
5.13.3 What the LDAP DAG-CAP sends to the Referral Index. . . . . 67
What the LDAP DAG-CAP Sends to a Whois++ DAG-SAP . . . . . . . 67
What the LDAP DAG-CAP Sends to an LDAP DAG-SAP . . . . . . . . 68
6.0 Service Specifications. . . . . . . . . . . . . . . . . . . . 68
6.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.2 WDSP Participation. . . . . . . . . . . . . . . . . . . . . . 69
6.3 Load Distribution . . . . . . . . . . . . . . . . . . . . . . 69
6.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 72
7.0 Security. . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.1 Information credibility . . . . . . . . . . . . . . . . . . . 73
7.2 Unauthorized access . . . . . . . . . . . . . . . . . . . . . 73
8.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 74
Appendix A - DAG Schema Definitions . . . . . . . . . . . . . . . 75
A.1 DAG Personal Information Schema (DAGPERSON Schema). . . . . . 76
A.2 DAG Organizational Role Information Schema (DAGORGROLE
Schema). . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Appendix B - Schema Mappings for Whois++ and LDAP . . . . . . . . 77
B.1 LDAP and the DAG Schemas. . . . . . . . . . . . . . . . . . . 78
B.2 Whois++ and the DAG Schemas . . . . . . . . . . . . . . . . . 81
Appendix C - DAG-Internal Protocol (DAG/IP) . . . . . . . . . . . 82
C.1 A word on the choice of DAG/IP. . . . . . . . . . . . . . . . 83
C.2 DAG/IP Input and Output -- Overview . . . . . . . . . . . . . 83
C.3 BNF for DAG/IP input and output . . . . . . . . . . . . . . . 83
C.3.1 The DAG/IP Input Grammar. . . . . . . . . . . . . . . . . . 84
C.3.2 The DAG/IP Response Grammar . . . . . . . . . . . . . . . . 87
C.4 DAG/IP Response Messages. . . . . . . . . . . . . . . . . . . 89
Appendix D - DAG/IP Response Messages Mapping . . . . . . . . . . 93
Appendix E - DAG CIP Usage. . . . . . . . . . . . . . . . . . . . 95
E.1 CIP Index Object. . . . . . . . . . . . . . . . . . . . . . . 95
E.2 CIP Index Object Creation . . . . . . . . . . . . . . . . . . 97
E.3 CIP Index Object Sharing. . . . . . . . . . . . . . . . . . . 98
E.3.1 Registration of Servers . . . . . . . . . . . . . . . . . . 98
E.3.2 Transmission of Objects . . . . . . . . . . . . . . . . . .100
5.11 .1が入力したLDAPv2縁飾りSAP.59 5.11。 . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.11.2 DAG/IPからLDAPv2質問までの翻訳。 . . . . . . . . . 59 5.11.3 DAG/IPへのLDAPv2結果に関する翻訳。 . . . . . . . . . 61 5.12 .1が入力したLDAPv3縁飾りSAP.62 5.12。 . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.12.2 DAG/IPからLDAPv3質問までの翻訳。 . . . . . . . . . 62 5.12.3 DAG/IPへのLDAPv3結果に関する翻訳。 . . . . . . . . . 64 5.13 例の質問。 . . . . . . . . . . . . . . . . . . . . . . 64 5.13.1 Whois++質問。 . . . . . . . . . . . . . . . . . . . . . 65 +縁飾りWhois+キャップが受けるもの。 . . . . . . . . . . . . . . 65、こと、Whois++DAG-CAPはLDAP DAG-SAPへのWhois++DAG-CAP SendsをReferral Index. . . . . 65Whatに送ります。 . . . . . . 65 5.13.2 LDAP質問。 . . . . . . . . . . . . . . . . . . . . . . 66 LDAP DAG-CAP Receives. . . . . . . . . . . . . . . . 66 5.13.3What LDAP DAG-CAPがReferral Indexに送るもの。 . . . . LDAPが縁飾りしてふたをするものは+ + 縁飾りSAP.67にWhoisに発信します。67 LDAP縁飾りキャップがLDAPに送るものは.686.0のサービス仕様を縁飾りして徐々に破壊します。 . . . . . . . . . . . . . . . . . . . 68 6.1概観。 . . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.2 WDSP参加。 . . . . . . . . . . . . . . . . . . . . . 69 6.3は分配. . . . . . . . . . . . . . . . . . . . . . 69 6.4伸展性. . . . . . . . . . . . . . . . . . . . . . . . 72 7.0セキュリティをロードします。 . . . . . . . . . . . . . . . . . . . . . . . . . . 73 7.1 情報真実性. . . . . . . . . . . . . . . . . . . 73 7.2Unauthorizedは.738.0Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 74のAppendix Aにアクセスします--DAG Schema Definitions. . . . . . . . . . . . . . . 75A.1 DAGパーソナル情報Schema(DAGPERSON Schema)。 . . . . . 76A.2縁飾り組織上の任務情報図式(DAGORGROLE図式)。 . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 付録B--+ Whoisの+、LDAP. . . . . . . . 77B.1 LDAP、および縁飾りSchemasのための図式マッピング。 . . . . . . . . . . . . . . . . . . 78B.2 Whoisの+ +とDAG Schemas. . . . . . . . . . . . . . . . . 81Appendix C--DAG/IPの選択に関するDAG内部のプロトコル(DAG/IP). . . . . . . . . . . 82C.1A単語。 . . . . . . . . . . . . . . . 83 C.2 DAG/IPのInputとOutput--DAG/IPのための概観.83C.3 BNFは.83C.3.1DAG/IP Input Grammar84………………C.3.2DAG/IP Response Grammar. . . . . . . . . . . . . . . . 87C.4 DAG/IP Response Messagesを入出力します。 . . . . . . . . . . . . . . . . . . 89 付録D--.93付録Eを写像する縁飾り/IP応答メッセージ--縁飾りCIP用法。 . . . . . . . . . . . . . . . . . . . 95 E.1 CIPは物に索引をつけます。 . . . . . . . . . . . . . . . . . . . . . . 95 E.2 CIPインデックス物の創造. . . . . . . . . . . . . . . . . . 97E.3 CIPは目的語の共有に索引をつけます。 . . . . . . . . . . . . . . . . . . 98 物. . . . . . . . . . . . . . . . . .100のサーバ. . . . . . . . . . . . . . . . . . 98E.3.2送信のE.3.1登録
Daigle & Hedberg Informational [Page 4] RFC 2967 TISDAG October 2000
[4ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
Appendix F - Summary of Technical Survey Results. . . . . . . . .100 Appendix G - Useful References. . . . . . . . . . . . . . . . . .102 Bibliography. . . . . . . . . . . . . . . . . . . . . . . . . . .102 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . .104 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . .105
付録F--技術的な調査の概要は結果として生じます。 . . . . . . . .100 付録G--役に立つ参照。 . . . . . . . . . . . . . . . . .102 図書目録。 . . . . . . . . . . . . . . . . . . . . . . . . . .102人の作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . .104 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . .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
+ +が.38に質問する5.1Allowable Whoisをテーブルの上に置いてください。テーブル3.1 DAGによって支持された質問… .12 Table A.1 DAGPERSON図式属性… .76はA.2 DAGORGROLE図式属性を見送ります。 . . . . . . . . . . . . .77 テーブルB.1 Canonical DAGPERSON図式とLDAP inetorgPerson属性… .79 LDAP organizationalRole属性のためのテーブルB.2 Reasonable Approximations… .79はLDAP organizationalRole属性のためのB.3 Canonicalマッピングを見送ります… .81テーブルB.4 Canonical DAGPERSON図式とWhois + + USER属性。 .81 システム・レスポンスの.82Table C.1 Listがコード化するWhois++ORGROLE属性のためのテーブルB.5 Canonicalマッピング… .90 DAG/IP応答へのテーブルD.1 LDAPv2/v3 resultcodesはマッピングをコード化します。 . . . . . . . . . . . . . . . . . . . . . . . . . . .93はDAG/IP応答コードからLDAPv2/v3 resultcodesまでD.2 Mappingをテーブルの上に置きます。 . . . . . . . . . . . . . . . . . . . . . . . . .94 DAG/IPとWhois++応答の間のテーブルD.3 MappingはTISDAG Survey Resultsの.94Table F.1 Summaryをコード化します: 質問. . . . . . 101はTISDAG調査結果のF.2概要を見送ります: 運用情報。 . . . . . . . . . . . . . . . . . . . . . . . . 101
1.0 Introduction
1.0 序論
1.1 Project Goal
1.1 プロジェクト目標
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.
このプロジェクトのアーチをかける目標はスウェーデン人のインターネットユーザのwhitepages情報を検索するための単一のアクセスポイントサービスを提供するために必要な技術インフラを開発することです。 すべての情報に、サービスは一定であるに違いありません--同じレベルの情報入手(7×24サービス)、およびその情報を保守するのに責任があるサービスプロバイダーの如何にかかわらず利用可能にされた同じwhitepages情報。
1.2 Executive Summary of Technical Study Result
1.2 技術的な研究結果の要約
The strength of the TISDAG project's DAG proposal is that it defines the necessary technical infrastructure to provide a single-access- point service for information on Swedish Internet users. The resulting service will provide uniform access for all information --
TISDAGプロジェクトのDAG提案の強さはスウェーデン人のインターネットユーザの情報のためのただ一つのアクセスしているポイントのサービスを提供するために必要な技術インフラを定義するということです。 結果として起こるサービスはすべての情報のための一定のアクセスを提供するでしょう--
Daigle & Hedberg Informational [Page 5] RFC 2967 TISDAG October 2000
[5ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
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.
同じレベルの情報入手(7×24サービス)と、その情報を保守するのに責任があるサービスプロバイダーの如何にかかわらず利用可能にされた同じ情報か、それらの電話番号案内プロトコルか、エンドユーザのクライアントアクセスが議定書を作ります。
Instead of requiring centralized mirroring of complete information records from Swedish directory service providers, the DAG system uses a well-defined index object summary of that data, updated at the directory service provider's convenience. When an end-user queries the DAG, the referral information is used (by the end-user's software, or by a module within the DAG, as appropriate) to complete the final query directly at the directory service provider's system. This ensures that the end-user gets the most up-to-date complete information, and promotes the directory service provider's main interest: its service. The architecture of the DAG itself is very modular; support for future protocols can be added in the operational system.
スウェーデンの電話番号案内プロバイダーからの完全な情報記録の集結されたミラーリングを必要とすることの代わりに、DAGシステムは電話番号案内プロバイダーの便利でアップデートされたそのデータの明確なインデックス物の合計を使用します。 エンドユーザがDAGについて質問するとき、紹介情報は、直接電話番号案内プロバイダーのシステムに最終的な質問を終了するのに使用されます(エンドユーザのソフトウェア、またはDAGの中のモジュールで適宜)。 これは、エンドユーザが最も最新の完全な情報を得るのを確実にして、電話番号案内プロバイダーの最も関心を持っていることを促進します: そのサービス。 DAG自身の構造は非常にモジュールです。 基幹系システムで将来のプロトコルのサポートを加えることができます。
1.3 Document Overview
1.3 ドキュメント概観
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.
機能的な仕様概観: ユーザの要件から働いていて、独自技術と機能性の詳細は述べられた必要条件を満たす建築家aシステムに概説されています。 これはシステムのための概念的な構造を含んでいます。 Requirements部が異なったユーザが最後の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.
ソフトウェア仕様書: ソフトウェアコンポーネントが上で説明された構造を満たすように、このセクションは仕様を提供します。
Daigle & Hedberg Informational [Page 6] RFC 2967 TISDAG October 2000
[6ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
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システムの成功は操作上の特性にかかるでしょう。 サービス要件の詳細はこのセクションで明らかにされます。
1.4 Terminology
1.4 用語
DAG-CAP: Client Access Point -- point of communication between client-access software and the DAG system.
縁飾りキャップ: クライアントAccess Point--クライアントアクセスソフトウェアと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.
縁飾りシステム: TISDAGプロジェクトから生じるディレクトリAccessゲートウェイシステム。 提供する目的のためのインフラストラクチャのソフトウェアの、そして、サービスの収集はスウェーデンのwhitepages情報へのアクセスを統一しました。
DAG/IP: DAG-Internal Protocol -- communication protocol used between software components of the DAG.
縁飾り/IP: DAG内部のプロトコル--DAGのソフトウェアコンポーネントの間で使用される通信プロトコル。
End-User: People performing White Pages searches and look-ups (via various forms of client software).
エンドユーザ: ホワイトのページ検索を実行している人々とルックアップ(様々な形式のクライアントソフトウェアを通した)。
DAG-SAP: Service Access Point -- point of communication between the DAG and WDSP software.
縁飾りSAP: Access Pointを調整してください--DAGとWDSPソフトウェアとのコミュニケーションのポイント。
WDSP: Whitepages Directory Service Provider -- ISPs, companies, or other interested entities.
WDSP: WhitepagesディレクトリサービスProvider--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.
Whitepages情報: 集まっている情報は個々の人々のために調整されます。 しかし、これが通常含んでいる、(制限されない、)、人の名前、およびEメールアドレス。
2.0 Requirements
2.0 要件
There are 2 primary classes of users for the proposed Whitepages directory access gateway:
提案されたWhitepagesディレクトリアクセスゲートウェイへの2つの第一のクラスのユーザがいます:
- End-users - WDSPs
- エンドユーザ--WDSPs
As outlined below, needs of each of these user classes imposes a set of constraints on the design of the DAG system itself. Some of the requirements shown below are assumed starting criteria for the DAG service; others have been derived from data collected in the Technical Survey or other expertise input.
以下に概説されているように、それぞれのこれらのユーザ・クラスの必要性は1セットの規制をDAGシステム自体の設計に課します。 以下に示された要件のいくつかがDAGサービスの始めの評価基準であると思われます。 Technical Surveyに集められたデータか他の専門的技術入力から他のものを得ました。
Daigle & Hedberg Informational [Page 7] RFC 2967 TISDAG October 2000
[7ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
2.1 End-User Requirements
2.1 エンドユーザ要件
The End-User is to be provided with a specific set of search types:
特定の検索タイプはエンドユーザに提供されることになっています:
Name Name + Organization Role + Organization Name + Locality Name + Organization + Locality Role + Organization + Locality
名前名前+組織役割+組織名前+場所名前+組織+場所役割+組織+場所
The search results will, if available, include the following information for each "hit":
利用可能であるなら、検索結果は各「ヒット」のための以下の情報を含むでしょう:
- Full name - E-mail address - Role - Organization - Locality - Full address - Telephone numbers
- フルネーム--Eメールアドレス--役割--組織--場所--完全なアドレス--電話番号
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.
それで続いて、応答がタイムリーであると予想されます。 標準の検索はウェブサーバーへの平均したアクセスより多くの時間がかかるべきではありません。
2.2 WDSPs Requirements
2.2 WDSPs要件
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.
whitepages情報のサービスを提供するビジネスにこのサービスに参加するWDSPsが既にあるなら、彼らには、これを関係者一同に対するうまくいっていて役に立つサービスにするように尊敬しなければならないある要件があります。
The DAG system must provide reasonable assurances of data integrity for WDSPs; the information the End-User sees should correspond directly to that provided by the WDSPs. The DAG system should be non-preferential in providing whitepages information -- the service is to the End-User, and the source of whitepages information should not influence the search and information presentation processes.
DAGシステムはデータ保全の手頃な保証をWDSPsに供給しなければなりません。 エンドユーザが見る情報は直接WDSPsによって提供されたそれに対応するべきです。 DAGシステムはwhitepages情報を提供することにおいて非優先のであるべきです--エンドユーザにはサービスがあります、そして、whitepages情報の源は検索と情報プレゼンテーションの過程に影響を及ぼすべきではありません。
Daigle & Hedberg Informational [Page 8] RFC 2967 TISDAG October 2000
[8ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
The DAG system must be able to reflect information updates within a reasonable time after receipt from WDSPs; on the flip side, while the DAG system will function best with regular updates from WDSPs, the update and participation overhead for WDSPs should be held within reasonable bounds of what the WDSP should do to support regular access to its information.
DAGシステムはWDSPsからの領収書の適当な時間内に後に情報最新版を反映できなければなりません。 面では、DAGシステムがWDSPsからの定期的なアップデートで最もよく機能する間、WDSPsのためのアップデートと参加オーバーヘッドがWDSPが情報への定期的なアクセスを支持するためにするはずであることに関する妥当な領域の中に保持されるべきです。
Furthermore, given that WDSPs provide directory service information with an eye to value-added service, wherever possible End-Users should be redirected to the WDSP responsible for individual directory service entries for final and further information.
その上、それを考えて、WDSPsは付加価値が付いたサービスへの目を電話番号案内情報に提供します、可能なエンドユーザがどこで決勝と詳細のための個々の電話番号案内エントリーに責任があるWDSPに向け直されても。
2.3 DAG-System Requirements
2.3 縁飾りシステム要求
In order to address the requirements of End-Users and WDSPs, the DAG system itself has certain design constraints that must be taken into account.
エンドユーザとWDSPsの要件を記述するために、DAGシステム自体には考慮に入れなければならないあるデザイン規制があります。
The system must be implementable/operational by Dec 31/98 -- which implies that it must be designed and constructed with already extant technologies.
システムは、12月の31/98(既に実在の技術でそれを設計されていて、組み立てなければならないのを含意する)による実行可能であるか、または操作上であるに違いありません。
The System will have certain requirements for participation -- e.g., 7x24 WDSP availability.
Systemには、参加のためのある要件があるでしょう--例えば、7×24WDSPの有用性。
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).
また、システムも拡大が他の、そして、関連するアプリケーション(例えば、セキュリティ証明書情報に役立つ)にできなければなりません。
3.0 Functional Specification
3.0 機能的な仕様
In the TISDAG pilotservice we have decided to apply some limitations as to what is specified for the DAG/IP. These limitations are presented in this text in the following manner:
TISDAG pilotserviceでは、私たちは、DAG/IPに指定されることに関していくつかの制限を適用すると決めました。 これらの制限は本稿に以下の方法で示されます:
TISDAG: This is a TISDAG comment
TISDAG: これはTISDAGコメントです。
3.1 Overview
3.1 概観
The conceptual environment of the DAG system can be described in three major components:
3個の主要コンポーネントでDAGシステムの概念的な環境について説明できます:
- client access software for end-users - the DAG system core - WDSP directory service software
- エンドユーザへのクライアントアクセスソフトウェア--DAGシステムコア--WDSP電話番号案内ソフトウェア
Daigle & Hedberg Informational [Page 9] RFC 2967 TISDAG October 2000
[9ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
This is illustrated in Figure 3.1
これは図3.1で例証されます。
The DAG (Directory Access Gateway) is the infrastructural core of the service; it maintains the necessary data and transformation facilities to permit the smooth connection of diverse directory service Client Software to the existing WDSPs' directory servers. The key challenges in designing this portion of the system are:
DAG(ディレクトリAccessゲートウェイ)はインフラストラクチャのサービスのコアです。 それは、存在へのさまざまの電話番号案内Client Softwareの滑らかな接続にWDSPsのディレクトリサーバを可能にするために必要なデータと変化施設を保守します。 システムのこの一部を設計することにおける主要な挑戦は以下の通りです。
Quantity of data -- the quantity of whitepages information that will be made available, and diversity of its sources (different WDSPs) introduce challenges in terms of finding a structure that will allow efficient searching, and facilitate the timeliness of updating the necessary information.
データの量--利用可能に作られて、(異なったWDSPs)が紹介するソースの多様性が効率的な探すことを許して、必要事項をアップデートするタイムリーさであるのを容易にする構造を見つけることに関して挑戦するというwhitepages情報の量。
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.
アクセス・プロトコルのクローンズ--最小摂動に伴うwhitepages意識しているソフトウェアを存在することの使用に支えるために、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コアとエンドユーザのディレクトリサービスAccessソフトウェアとのインタフェース--DAGコアとディレクトリサービスServersとのインタフェース
3.2 The DAG Core
3.2 縁飾りコア
In order to reduce the quantity of data the DAG itself must maintain, and to keep the maintenance of the whitepages information as close as possible to the source of information (the WDSPs themselves), the DAG will only maintain index information and will use "query routing" to efficiently refer End-User queries to WDSPs for search refinement and retrieval of information. Although originally developed for the Whois++ protocol, query routing is being pursued in a protocol- independent fashion in the IETF's FIND WG, so the choice of this approach does not limit the selection and support of whitepages access protocols.
DAG自身が保守しなければならないデータの量を減少させて、できるだけ情報源に近く(WDSPs自身)whitepages情報のメインテナンスを保つと、DAGは、インデックス情報を保守するだけであり、絞り込み検索と情報の検索について効率的にエンドユーザ質問をWDSPsを参照するのに「質問ルーティング」を使用するでしょう。 元々Whois++プロトコルのために開発されますが、質問ルーティングがIETFのFIND WGのプロトコルの独立しているファッションで追求することにされるのであるので、このアプローチの選択はwhitepagesアクセス・プロトコルの選択とサポートを制限しません。
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は、明確に限られたセットのwhitepages質問をサポートするために連動するでしょう。
Daigle & Hedberg Informational [Page 10] RFC 2967 TISDAG October 2000
[10ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
+---------+ @
+ ->| | -+-
/|Protocol| | |
/ | / +---------+ / \
/ | "B"
+ | /
| |<-
+-------+ | |
O | | | |
-+- | |<--------->| |
| | | Protocol | |
/ \ | | "A" | |<-
+-------+ | |Protocol
| | \
+ | "A" +---------+ @
\ | \ | | -+-
\ | ->| | |
\| +---------+ / \
+
+---------+ @ + ->|、| -+- /|プロトコル| | | / | / +---------+ / \ / | 「B」+| / | | <、- +-------+ | | O| | | | -+- | | <、-、-、-、-、-、-、-、--、>|、|、|、|、| プロトコル| | / \ | | 「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システムの役割
3.3 Client Interface
3.3 クライアントインタフェース
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サーバへの唯一の紹介を返すためにすべてのクライアントがすべてのアクセス・プロトコルを扱うことができると思うことができません。
Daigle & Hedberg Informational [Page 11] RFC 2967 TISDAG October 2000
[11ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
3.3.1 Acceptable User Input
3.3.1 許容できるユーザ入力
User Input is defined in terms of
Inputが定義されるユーザ
- Searchable Attributes - Matching semantics - Character sets
- 探せるAttributes--合っている意味論--文字集合
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.
DAG図式に関連したAppendix Aで定義されたこれらは必要な質問式の基礎を形成します。 サポートしているプロトコルのためのさらに詳細にClient Access Point(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システムは、限られたセットの「名前」、「組織上の任務」、「組織」、およびデータ属性--「場所」で断片に合う質問をサポートするように設計されています。 属性の選択された許されている質問組み合わせはTable3.1に記載されています。 テーブルから、3つの属性のすべての組み合わせがサポートされるというわけではありません--必要な機能性に必要であるものだけを見ることができます。
Symbol Description ------- ----------- N Name NL Name + Locality NO Name + Organization NOL Name + Organization + Locality RO Role + Organization ROL Role + Organization + Locality
シンボル記述------- ----------- N名前NL名前+場所いいえ名前+組織NOL名前+組織+場所RO役割+組織ROL役割+組織+場所
Table 3.1 DAG-supported queries
テーブル3.1 DAGによってサポートされた質問
The RO and ROL queries are separated from the rest as they are searches for "virtual" persons -- roles within an organization (e.g., president, or customer service desk) for which one might want to find contact information.
ROとROL質問はそれらは「仮想」の人々の捜索です--1つが問い合わせ先を見つけたがっているかもしれない組織(例えば、社長、または顧客サービス・デスク)の中の役割によって残りと切り離されます。
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の基本的な意味論は、以下がすべてのクライアントアクセスソフトウェア(関連するとしての)で利用可能であると予想します:
Daigle & Hedberg Informational [Page 12] RFC 2967 TISDAG October 2000
[12ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
- Full word, exact match - Word substring match (E.g., "cat" would match "scatter") - Case-sensitive and case-insensitive matching
- フルワード、完全な一致--Wordサブストリングマッチ(例えば、「猫」は「散布」に合っている)--大文字と小文字を区別して大文字と小文字を区別しないマッチング
TISDAG: LDAP/X.500, supports case-sensitivity as such but some of
the most used attributes, such as the commonName attribute, are
defined in the standard to be of the case-insensitive
attributetypes. The impact on the DAG system is that even if the
index collected from a LDAP/X.500 server might have upper and
lower case letters in the tokens, they can not be handled as such
since that would be inferring meaning in something which is
natively regarded as meaningless. The conclusion of the above is
that The Referral Index should be case-insensitive and case-
sensitivity should be supported by the SAPs if the native access
protocol supports it.
TISDAG: LDAP/X.500(そのようなものとして感度をケースに入れているサポートにもかかわらず、commonName属性などの最も中古の属性のいくつか)は、大文字と小文字を区別しないattributetypesがあるように規格で定義されます。 DAGシステムの上の影響はそれがネイティブに無意味であると見なされる何かで意味を推論しているでしょう、したがって、LDAP/X.500サーバから集められたインデックスがトークンで大文字と小文字手紙を持つかもしれなくても、そういうものとしてそれらを扱うことができないということです。 上記の結論はReferral Indexが大文字と小文字を区別しないはずであり、固有のアクセス・プロトコルがそれをサポートするならケース感度が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.
[21]) 明確にUTF-8がコード化しているのを見てください。DAG Systemがどこでも、可能であるところでは、ユニコードバージョン2.0の文字集合の使用をサポートして、促進する、(([21]か[20])宿泊設備のAppendix A.2が存在する配布しているベースがソフトウェアであるとサポートするために必要であるところで作られているのを確実にしてください。
Specifically:
明確に:
DAG/IP: All internal communications using the DAG/IP are carried out in UTF-8.
縁飾り/IP: DAG/IPを使用するすべての内部のコミュニケーションがUTF-8で行われます。
TISDAG: not just UTF-8, but UTF-8 based on composed UNICODE
version 2 character encodings.
TISDAG: UTF-8だけではなく、UTF-8もバージョン2文字符号化を落ち着いたユニコードに基礎づけました。
DAG-CAP input: Where specific access protocols permit selection of character sets, DAG-CAPs must support UTF-8. They may additionally support other anticipated character set encodings.
DAG-CAPは以下を入力します。 特定のアクセス・プロトコルが文字集合の品揃えを可能にするところでは、DAG-CAPsはUTF-8をサポートしなければなりません。 彼らは、他の予期された文字集合がencodingsであるとさらに、サポートするかもしれません。
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コミュニケーション: 特定のアクセス・プロトコルが文字集合の品揃えを可能にするところでは、リモートWDSPがそれをサポートするときはいつも、DAG-SAPsはUTF-8をサポートして、UTF-8を使用しなければなりません。 彼らは、他の文字集合がencodingsであるとさらに、サポートするかもしれません。
CIP Index Objects: The Index Objects supplied by the WDSPs to the DAG system shall contain data encoded in UTF-8.
CIPはオブジェクトに索引をつけます: WDSPsによってDAGシステムに供給されたIndex Objectsは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コード化された落ち着いたユニコードバージョン2文字符号化であるべきです。
Daigle & Hedberg Informational [Page 13] RFC 2967 TISDAG October 2000
[13ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
3.3.2 Data Output Spec
3.3.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サービスがAppendix A.Thisで定義されるので、使用される図式はさらにではなくDAGサービスのための必要事項を運ぶことを意図する非常に基本的な情報図式です。 情報プレゼンテーションが、よりジェネリック"whitepages"図式定義が存在していますが、高性能であって、詳細であれば詳細であるほど、それはシームレスに異なったパラダイムのプロトコルの向こう側に図式を写像するのが、より難しいです。その結果、「キス」(「それを簡単に保つ」)原則はここで適切に見えます。
Individual DAG-CAPs define how they express this schema.
個々のDAG-CAPsは彼らがどうこの図式を表すかを定義します。
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は紹介の式を定義します(Appendix Cを見てください)。
Error conditions
エラー条件
Each DAG-CAP may provide more detailed error messages, but will define minimally the support for the following error conditions:
各DAG-CAPは、より詳細なエラーメッセージを提供するかもしれませんが、以下のエラー条件のサポートを最少量で定義するでしょう:
- unrecognized query - too many hits
- 認識されていない質問--あまりに多くのヒット
Apart from these errors, the DAG-CAP may choose to refuse a query by redirecting the end-user to a different DAG-CAP of the same protocol.
これらの誤りは別として、DAG-CAPは、同じプロトコルの異なったDAG-CAPにエンドユーザを向け直すことによって質問を拒否するのを選ぶかもしれません。
3.4 Directory Server Interface
3.4 ディレクトリサーバインタフェース
The DAG will use the Common Indexing Protocol (CIP) server-server protocol to obtain updated index objects from WDSPs. For query- routing purposes, WDSPs are expected to provide Whois++, LDAPv2 or LDAPv3 interface to their data (although their preferred access may be something completely different). N.B.: In the responses from the technical survey, all respondents currently provide access to their service in one of these protocols.
DAGは、WDSPsからアップデートされたインデックスオブジェクトを入手するのにCommon Indexingプロトコル(CIP)サーバサーバプロトコルを使用するでしょう。 質問ルーティング目的のために、WDSPsが+ +、LDAPv2またはLDAPv3が彼らのデータに連結するWhoisを提供すると予想されます(完全に彼らの都合のよいアクセスが何かであるかもしれないこと異なるのであるものにもかかわらず)。 N.B.: 技術的な調査からの応答では、すべての応答者が現在、彼らのサービスへのアクセスをこれらのプロトコルの1つに提供します。
In order to provide a useful and uniform service, WDSPs are expected to provide 7x24 access to their whitepages information. WDSPs are also expected to implement operations, administration, maintenance, and provisioning processes designed to minimize service down time for both planned and unplanned administration and maintenance activities.
役に立って一定のサービスを提供するために、WDSPsが彼らのwhitepages情報への7×24アクセスを提供すると予想されます。 WDSPsはまた、操作、管理にメインテナンスを実装すると予想されて、計画されて無計画な管理とメインテナンス活動の両方のためのサービス休止時間を最小にするように設計されたプロセスに食糧を供給しています。
Daigle & Hedberg Informational [Page 14] RFC 2967 TISDAG October 2000
[14ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
4.0 Architecture
4.0 アーキテクチャ
4.1 Software Components
4.1 ソフトウェアコンポーネント
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に続かれて、一般建築仕様は以下で説明されます。
4.1.1 Internal Communications
4.1.1 内部のコミュニケーション
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/IP)を使用して、DAGの部品のコミュニケーションがTCP/IP接続であるでしょう。 DAG/IPは、Referral IndexとDAG-SAPsとコミュニケートするのにDAG-CAPsによって使用されます。 その結果IPが定義するDAG/
- 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のReferral Index(エンドユーザの要求に対応して紹介を集める)の質問能力の範囲--DAG-CAP要求へのReferral Indexの応答(そして、それらの形式)--DAG-CAPsのDAG-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の詳細はDAG-CAP--紹介IndexとDAG-CAP--DAG-SAP相互作用の詳細が個々のDAG-CAPsとDAG-SAPsの定義で明らかにされるAppendix C.で明らかにされます、(セクション5.5〜5.12)の下で。
4.1.2 Referral Index
4.1.2 紹介インデックス
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.
Referral IndexはWDSP情報のインデックスを維持して、DAG-CAP検索要求に対応して合理的な紹介のリストを提供するのに責任があります。 これらの「紹介」は、エンドユーザの質問に合っている情報を持っているかもしれないWDSPsを特定するために指針を提供します。
4.1.3 DAG-CAPs
4.1.3 縁飾り上限
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は特定の質問アクセス・プロトコルで終わりのユーザー・クエリーを受けて、Referral Index(すなわち、DAG/IPで言い表される)のために要求を質問に変換して、次に、クライアントアクセス・プロトコルに、適切なフォームにReferral Indexの応答を変換します。 これは、直接紹介を戻すことを意味するかもしれません、DAG-SAPsが結果(「推論」)、または両方の組み合わせに紹介を翻訳する仕事を翻訳するよう呼びかけて。
Daigle & Hedberg Informational [Page 15] RFC 2967 TISDAG October 2000
[15ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
+-------------------------------------+
|+====+ |
HTTP <-->+| |<------+ (Full chaining) |
|| | | |
|+====+ | |
| | +----+|
| | Referral-->| ||
| | Result <--| |+<--> Whois++
| | +----+|
|+====+ | |
SMTP <-->+| |<------+ (Full chaining) |
|| | | |
|+====+ | |
| | +----+|
| | Referral-->| ||
| | Result <--| |+<--> LDAPv2
| | +----+|
|+====+ | |
Whois++<-->+| |<------+ (Chain LDAPv2/3) |
|| | | |
|+====+ | |
| | +----+|
| | Referral-->| ||
| | Result <--| |+<--> LDAPv3
| | +----+|
|+====+ | |
LDAPv2 <-->+| |<------+ (Full chaining) |
|| | | |
|+====+ | |
| | |
|+====+ | |
LDAPv3 <-->+| |<------+ (Chain Whois++) |
|| | | |
|+====+ | |
| | |
| v |
| +-----------------------+ |
| | Referral Index |<---------------> Common
| | | | Indexing Protocol
| +-----------------------+ | (CIP)
+-------------------------------------+
+-------------------------------------+ |+====+ | HTTP<-->+| | <、-、-、-、-、--+ (完全な推論)| || | | | |+====+ | | | | +----+| | | 紹介-->| || | | 結果<--| |+<-->Whois++| | +----+| |+====+ | | SMTP<-->+| | <、-、-、-、-、--+ (完全な推論)| || | | | |+====+ | | | | +----+| | | 紹介-->| || | | 結果<--| |+<-->LDAPv2| | +----+| |+====+ | | Whois++<-->+| | <、-、-、-、-、--+ (チェーンLDAPv2/3)| || | | | |+====+ | | | | +----+| | | 紹介-->| || | | 結果<--| |+<-->LDAPv3| | +----+| |+====+ | | LDAPv2<-->+| | <、-、-、-、-、--+ (完全な推論)| || | | | |+====+ | | | | | |+====+ | | LDAPv3<-->+| | <、-、-、-、-、--+ (チェーンWhois++)| || | | | |+====+ | | | | | | v| | +-----------------------+ | | | 紹介インデックス| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-->一般的です。| | | | プロトコルに索引をつけます。| +-----------------------+ | (CIP) +-------------------------------------+
All internal communications are in DAG/IP.
DAG/IPにはすべての内部のコミュニケーションがあります。
Figure 4.1 Conceptual Architecture of the DAG
図4.1 縁飾りの概念的なアーキテクチャ
Daigle & Hedberg Informational [Page 16] RFC 2967 TISDAG October 2000
[16ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
4.1.4 DAG-SAPs
4.1.4 縁飾り体液
Individual DAG-SAPs are called upon (by DAG-CAPs) to take DAG- generated referrals and pursue them -- issuing the indicated query at the specified WDSP service. Results from individual WDSPs are converted back into DAG/IP-specific format for the DAG-CAP that made the request. Each DAG-SAP is responsible for handling referrals to WDSPs of a particular protocol (e.g., LDAPv2, Whois++, etc).
指定されたWDSPサービスのときに示された質問を発行して、紹介であると生成されたDAGを取って、個々のDAG-SAPsがそれらを追求するのが要求されます(DAG-CAPs)。 個々のWDSPsからの結果は要求をしたDAG-CAPのためのIP DAG/特有の形式に変換し返されます。 それぞれのDAG-SAPは特定のプロトコル(例えば、LDAPv2、Whois++など)のWDSPsへの取り扱い紹介に責任があります。
4.2 Important Architectural Notes
4.2 重要な建築注意
This section notes some of the thinking that has driven the architectural and software design specification for the DAG system. This helps to provide the context in which to understand the software specifications that follow, and should give clues for the eventual extension of the DAG system. This section also acts, in some ways, as an FAQ (Frequently Asked Questions) section, as the content is shaped by questions received during the tech spec development phase. It attempts to illuminate context that may not otherwise be apparent on a first reading of the software specifications.
このセクションはDAGシステムのための建築するのとソフトウェアデザイン仕様を追い立てた考えのいくつかに注意します。 これは、DAGシステムの最後の拡大のための手がかりに従って、与えるべきであるソフトウェア仕様書を理解している文脈を提供するのを助けます。 また、このセクションは作動します、ある点では、FAQ(よく出る質問)部として、内容が科学技術の仕様開発段階の間に受け取られた質問によって形成されるとき。 それは、そうでなければソフトウェア仕様書の最初の読みのときに明らかでないかもしれない関係を照らすのを試みます。
4.2.1 2 Distinct Functions: Referrals and Chaining
4.2.1 2 別個の機能: 紹介と推論
At all times, it must be kept in mind that the primary function of the DAG system is to provide users with referrals to WDSP services that may have the information they seek. Since it is the case that not all supported client protocols can handle referrals, the DAG system also provides a chaining service to pursue referrals that the user's client software cannot handle itself. This chaining service does attempt to match the user's query against data from WDSPs, but this is to be seen as a secondary, or support function of the DAG system. In the perfect future, all access protocols will be able to handle all referrals!
いつも、DAGシステムのプライマリ機能が彼らが求める情報を持っているかもしれないWDSPサービスへの紹介をユーザに提供することであることを覚えておかなければなりません。 すべてサポートしていないクライアントプロトコルが紹介を扱うことができるのが、事実であるので、また、DAGシステムはそれ自体で、ユーザのクライアントソフトウェアが処理できない紹介を追求するために推論サービスを提供します。 この推論サービスは、WDSPsからのデータに対してユーザの質問に合っているのを試みますが、これはDAGシステムのセカンダリかサポート機能と考えられることになっています。 申し分のない未来に、すべてのアクセス・プロトコルがすべての紹介を扱うことができるでしょう!
4.2.2 Limited Query and Response Semantics
4.2.2 株式会社質問と応答意味論
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システムが、カメレオンであることを試みないか、または究極のwhitepagesはサービスについて質問します。 それは、機能的なDAGサービスの仕様に概説された質問タイプの限られた数の情報のための紹介を提供するのは焦点を合わせます。 これはDAGシステムを捜査を開始する良い場所にしますが、気品と詳細な問い合せは範囲を超えています。
4.2.3 Visibility
4.2.3 目に見えること
Given the limited query syntax of the DAG system it will not always be possible to exactly match a query posed to a CAP into a query posed to a SAP. This will have the effect that for instance a LDAPv2
DAGシステムの限られた質問構文を考えて、まさにSAPに引き起こされた質問にCAPに引き起こされた質問に合っているのはいつも可能であるというわけではないでしょう。 これには、そんなに例えば効果a LDAPv2があるでしょう。
Daigle & Hedberg Informational [Page 17] RFC 2967 TISDAG October 2000
[17ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
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システムによってLDAPサーバにチェーニングされるDAGシステムに質問を発行するクライアントが同じ結果を得ないかもしれない、クライアント、直接問題のサーバに関連しているところ。
4.2.4 Richness of Query semantics
4.2.4 Query意味論の豊か
Even the limited query syntax of the DAG system is capable of expressing queries that might NOT be possible to represent in the access protocols to the WDSPs. In these cases the DAG-SAP either can refuse the query or try to emulate it.
DAGシステムの限られた質問構文さえアクセス・プロトコルでWDSPsに表すのにおいて可能でないかもしれない質問を言い表すことができます。 これらの場合では、DAG-SAPは、質問を拒否しようとするか、またはそれを見習おうとすることができます。
4.2.5 N+M Protocol Mappings
4.2.5 N+Mプロトコルマッピング
As part of the chaining service offered by the DAG system, a certain amount of mapping between protocols is required -- in theoretical terms, there are "N" allowable end-user query access protocols, and "M" supported WDSP server protocols. The architecture of the software is constructed to use a single internal protocol (the DAG/IP) and data schema, providing a common language between all components. Without this, each input protocol module (DAG-CAP) would have to be constructed to be able to handle every WDSP protocol -- NxM protocol mappings. This would make the system complex, and difficult to expand to include new protocols in future.
DAGシステムで提供された推論サービスの一部として、プロトコルの間のある量のマッピングが必要です--理論上の諸条件には、「N」許容できるエンドユーザ質問アクセス・プロトコルがありました、そして、「M」はサーバプロトコルをWDSPにサポートしました。 ソフトウェアのアーキテクチャはただ一つの内部のプロトコル(DAG/IP)とデータ図式を使用するために構成されます、すべてのコンポーネントの間に共通語を提供して。 これがなければ、それぞれの入力プロトコルモジュール(DAG-CAP)はあらゆるWDSPプロトコルを扱うことができるように構成されなければならないでしょう--NxMプロトコルマッピング。 これは、これから新しいプロトコルを含むようにシステムを広げるのを複雑で、難しくするでしょう。
4.2.6 DAG-CAPs and DAG-SAPs are completely independent of each other
4.2.6 DAG-CAPsとDAG-SAPsは互いから完全に独立しています。
For the above reasons, the DAG-CAP and DAG-SAP modules are intended to be completely independent of each other. A DAG-SAP responds to a query that is posed to it in the DAG/IP, without regard to the protocol of the DAG-CAP that passed the query.
上記の理由で、DAG-CAPとDAG-SAPモジュールが互いから完全に独立していることを意図します。 DAG-SAPはDAG/IPでそれに引き起こされる質問に応じます、質問を通過したDAG-CAPのプロトコルへの尊敬なしで。
4.2.7 The Role of the DAG-CAP
4.2.7 縁飾り上限の役割
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は2つのプロトコルだけを「知っています」: 固有のプロトコル、およびDAG/IP。
Daigle & Hedberg Informational [Page 18] RFC 2967 TISDAG October 2000
[18ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
4.2.8 The Role of the DAG-SAP
4.2.8 縁飾りSAPの役割
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は2つのプロトコルだけを「知っています」: 固有のプロトコル、およびDAG/IP。
4.2.9 DAG/IP is internal
4.2.9 DAG/IPは内部です。
No module outside of the DAG system should be aware of the DAG/IP's construction. End-users use the query protocols supported by DAG- CAPs; WDSPs are contacted using the query protocols supported in the DAG-SAPs.
DAGシステムにおける外のどんなモジュールもDAG/IPの工事を意識しているべきではありません。 エンドユーザはDAG- CAPsによってサポートされた質問プロトコルを使用します。 DAG-SAPsでサポートされた質問プロトコルを使用することでWDSPsは連絡されます。
4.2.10 Expectations
4.2.10 期待
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は、相互機械コミュニケーションを作動させるとそのような方法で指定しました。
4.2.11 Future Extensions
4.2.11 今後の拡大
The DAG system architecture was constructed with a specific view to extensibility. At any time, an individual component may be improved (e.g., the Mail DAG-CAP may be given a different query interface) without disrupting the system.
DAGシステム構築は特定の視点で伸展性に構成されました。 いつでも、システムを混乱させないで、個々のコンポーネントは改良されるかもしれません(異なった質問インタフェースを例えば、メールDAG-CAPに与えるかもしれません)。
Additionally, future versions of the DAG system may support other access protocols -- for end-users, and for WDSPs.
さらに、DAGシステムの将来のバージョンは、エンドユーザ、およびWDSPsのために他のアクセスがプロトコルであるとサポートするかもしれません。
5.0 Software Specifications
5.0 ソフトウェア仕様
5.1 Notational Convention
5.1 記号法のコンベンション
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?
いつもそれは正確に印刷された記録のテキストプロトコルを表す挑戦です。 復帰改行はいつ「ニューライン」であるか、そして、それはいつテキスト・フォーマッタの効果ですか?
Daigle & Hedberg Informational [Page 19] RFC 2967 TISDAG October 2000
[19ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
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>のいくつかの系列にかかるのを示すという事実にもかかわらず
5.2 DAG-CAP Basics
5.2 縁飾り上限基礎
5.2.1 Functionality
5.2.1 機能性
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).
- Referral Indexから関連紹介を得るために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-CAPは以下を行うことができなければなりません、DAGシステムの負荷制限と負荷分散を可能にするために:
- direct the client to a different DAG-CAP of the same type (for
load-balancing)
- 同じタイプの異なったDAG-CAPにクライアントを向けてください。(負荷分散のための)
Daigle & Hedberg Informational [Page 20] RFC 2967 TISDAG October 2000
[20ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
- 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-SAPサービス紹介(DAG-SAP負荷分割法のための)を受け入れて、DAG-CAPsは尊敬できなければなりません。
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).
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).
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: 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.
5.2.2 Configuration
5.2.2 Configuration
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).
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).
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:
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:
- 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
- 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
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).
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).
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.
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.
5.2.3 Error handling
5.2.3 Error handling
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).
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).
Daigle & Hedberg Informational [Page 21] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 21] RFC 2967 TISDAG October 2000
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.
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.
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.
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.
See Appendix D for more information concerning error condition message mappings.
See Appendix D for more information concerning error condition message mappings.
5.2.4 Pruning of results
5.2.4 Pruning of results
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.
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.
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.
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.
5.3 DAG-SAP Basics
5.3 DAG-SAP Basics
5.3.1 Functionality
5.3.1 Functionality
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.
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.
The DAG-SAP is then responsible for
The DAG-SAP is then responsible for
- 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
- 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
Daigle & Hedberg Informational [Page 22] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 22] RFC 2967 TISDAG October 2000
message. If it is emulatable, the DAG-SAP can attempt emulate it
by posing a related query to the WDSP and post-pruning the results
received);
- contacting that WDSP, using the host, port, and protocol
information provided in the referral;
- negotiating the query with the remote WDSP;
- accepting results from the WDSP, possibly doing post-filtering on
the result set; and
- conveying the results back to the calling DAG-CAP using the DAG/IP
and its schema.
message. If it is emulatable, the DAG-SAP can attempt emulate it by posing a related query to the WDSP and post-pruning the results received); - contacting that WDSP, using the host, port, and protocol information provided in the referral; - negotiating the query with the remote WDSP; - accepting results from the WDSP, possibly doing post-filtering on the result set; and - conveying the results back to the calling DAG-CAP using the DAG/IP and its schema.
Note that this implicitly means that the DAG-SAP is responsible for chaining and pursuing any referrals it receives from WDSP services. The DAG-SAP returns only search results to the DAG-CAP that called it.
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.
5.3.2 Configuration
5.3.2 Configuration
DAG-SAPs must be configurable to accept connections only from recognized DAG components.
DAG-SAPs must be configurable to accept connections only from recognized DAG components.
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 that have service limits must be configurable to redirect DAG-CAPs to alternate DAG-SAPs of the same type when necessary.
5.3.3 Error handling
5.3.3 Error handling
A DAG-SAP must translate error codes received from a WDSP server to DAG error codes according to Appendix D.
A DAG-SAP must translate error codes received from a WDSP server to DAG error codes according to Appendix D.
5.3.4 Pruning of results
5.3.4 Pruning of results
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.
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.
5.3.5 Constraint precedence
5.3.5 Constraint precedence
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:
Some constraints, search and case, can appear both as local and global constraints. If this happens in a query then the local constraint specification overrides the global. For a query like the following:
fn=leslie;search=exact and org=think:search=substring
fn=leslie;search=exact and org=think:search=substring
the resulting search constraint for "fn=leslie" will be "exact" while it for "org=think" will be "substring".
the resulting search constraint for "fn=leslie" will be "exact" while it for "org=think" will be "substring".
Daigle & Hedberg Informational [Page 23] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 23] RFC 2967 TISDAG October 2000
5.4 The Referral Index
5.4 The Referral Index
5.4.1 Architecture
5.4.1 Architecture
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).
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).
5.4.2 Interactions with WDSPs (CIP)
5.4.2 Interactions with WDSPs (CIP)
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.
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.
5.4.3 Index Object Format
5.4.3 Index Object Format
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.
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.
TISDAG: The tokens in the Tagged Index Object should be UTF-8
encoded composed UNICODE version 2 character encoding.
TISDAG: The tokens in the Tagged Index Object should be UTF-8 encoded composed UNICODE version 2 character encoding.
5.4.4 DAG-Internal I/O
5.4.4 DAG-Internal I/O
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).
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).
5.4.5 The Index Server
5.4.5 The Index Server
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.
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.
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)
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)
- 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.
- 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.
Daigle & Hedberg Informational [Page 24] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 24] RFC 2967 TISDAG October 2000
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.
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.
5.4.6 Configuration
5.4.6 Configuration
The Referral Index must provide the ability to register interested WDSPs, as outlined in Appendix E.
The Referral Index must provide the ability to register interested WDSPs, as outlined in Appendix E.
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.
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.
5.4.7 Security
5.4.7 Security
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.
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.
The Referral Index must be able to use authenticated communication to receive data from WDSPs (see Appendix E).
The Referral Index must be able to use authenticated communication to receive data from WDSPs (see Appendix E).
5.5 Mail (SMTP) DAG-CAP
5.5 Mail (SMTP) DAG-CAP
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 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.
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.
Daigle & Hedberg Informational [Page 25] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 25] RFC 2967 TISDAG October 2000
5.5.1 Mail DAG-CAP Input
5.5.1 Mail DAG-CAP Input
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.
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.
One query is accepted per e-mail message -- text after a single valid query has been read is simply ignored.
One query is accepted per e-mail message -- text after a single valid query has been read is simply ignored.
The body of the query message must follow the syntax defined below.
Note that all input control terms ("type=", "name=" etc) are shown in
lower case for convenience, but could be upper case or mixed case on
input.
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.
mailquery = [mnl] [controls] mnl terms mnl
controls = [msp] "searchtype" [msp] "=" [msp]
( matchtype /
casetype /
matchtype msp casetype /
casetype msp matchtype /
<nothing> )
matchtype = "substring" / "exact"
; default: substring
casetype = "ignore" / "sensitive"
; default: ignore
mailquery = [mnl] [controls] mnl terms mnl controls = [msp] "searchtype" [msp] "=" [msp] ( matchtype / casetype / matchtype msp casetype / casetype msp matchtype / <nothing> ) matchtype = "substring" / "exact" ; default: substring casetype = "ignore" / "sensitive" ; default: ignore
terms = n / n-l / n-o / n-o-l / r-o / r-o-l
terms = n / n-l / n-o / n-o-l / r-o / r-o-l
n = n-term
n-l = ( n-term l-term / l-term n-term)
n-o = ( n-term o-term / o-term n-term )
n-o-l = ( n-term o-term l-term /
n-term l-term o-term /
l-term n-term o-term /
l-term o-term n-term /
o-term l-term n-term /
o-term n-term l-term )
r-o = ( r-term o-term / o-term r-term )
r-o-l = ( r-term o-term l-term /
r-term l-term o-term /
n = n-term n-l = ( n-term l-term / l-term n-term) n-o = ( n-term o-term / o-term n-term ) n-o-l = ( n-term o-term l-term / n-term l-term o-term / l-term n-term o-term / l-term o-term n-term / o-term l-term n-term / o-term n-term l-term ) r-o = ( r-term o-term / o-term r-term ) r-o-l = ( r-term o-term l-term / r-term l-term o-term /
l-term o-term r-term /
l-term r-term o-term /
o-term l-term r-term /
o-term r-term l-term )
n-term = [msp] "name" [msp] "=" [msp] string mnl
o-term = [msp] "org" [msp] "=" [msp] string mnl
l-term o-term r-term / l-term r-term o-term / o-term l-term r-term / o-term r-term l-term ) n-term = [msp] "name" [msp] "=" [msp] string mnl o-term = [msp] "org" [msp] "=" [msp] string mnl
Daigle & Hedberg Informational [Page 26] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 26] RFC 2967 TISDAG October 2000
l-term = [msp] "loc" [msp] "=" [msp] string mnl r-term = [msp] "role" [msp] "=" [msp] string mnl
l-term = [msp] "loc" [msp] "=" [msp] string mnl r-term = [msp] "role" [msp] "=" [msp] string mnl
string = <US-ASCII or quoted-printable encoded
ISO-8859-1 or UTF-8 except nl and sp>
msp = 1*(sp)
sp = " "
mnl = 1*(nl)
string = <US-ASCII or quoted-printable encoded ISO-8859-1 or UTF-8 except nl and sp> msp = 1*(sp) sp = " " mnl = 1*(nl)
nl = <linebreak>
nl = <linebreak>
The following are valid mail queries:
The following are valid mail queries:
Example 1:
Example 1:
searchtype = <NL> name = thinking cat<NL>
searchtype = <NL> name = thinking cat<NL>
Example 2:
Example 2:
searchtype = exact ignore<NL> name=thinking cat<NL>
searchtype = exact ignore<NL> name=thinking cat<NL>
Example 3:
Example 3:
role=thinking cat<NL> org =space colonization<NL>
role=thinking cat<NL> org =space colonization<NL>
Example 4:
Example 4:
name=thinking cat <NL> <NL> <NL> My signature line follows here in the most annoying fashion <NL>
name=thinking cat <NL> <NL> <NL> My signature line follows here in the most annoying fashion <NL>
Note that the following are not acceptable queries:
Note that the following are not acceptable queries:
Example 5:
Example 5:
searchtype= exact substring <NL> name = thinking cat <NL>
searchtype= exact substring <NL> name = thinking cat <NL>
Example 6:
Example 6:
name=thinking cat org= freedom fighters anonymous<NL>
name=thinking cat org= freedom fighters anonymous<NL>
Daigle & Hedberg Informational [Page 27] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 27] RFC 2967 TISDAG October 2000
In Example 5, two conflicting searchtypes are given. In Example 6, no linebreak follows the n-term.
In Example 5, two conflicting searchtypes are given. In Example 6, no linebreak follows the n-term.
5.5.2 Translation from Mail query to DAG/IP
5.5.2 Translation from Mail query to DAG/IP
Querying the Referral Index
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
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
name= thinking cat<NL>
name= thinking cat<NL>
is tokenized into 2 n-tokens:
is tokenized into 2 n-tokens:
thinking cat
thinking cat
which are then mapped into the following in the DAG/IP query (dag-n- terms):
which are then mapped into the following in the DAG/IP query (dag-n- terms):
FN=thinking and FN=cat<NL>
FN=thinking and FN=cat<NL>
The same is true for all r-terms, l-terms and o-terms. The primary steps in translating the mail input into a DAG/IP query are:
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:
translate quoted-printable encoding, if necessary translate base64 encoding, if necessary tokenize the strings for each term construct the DAG/IP query from the resulting components, as described in more detail below
translate quoted-printable encoding, 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
DAG/IP constraints are constructed from the searchtype information in the query.
DAG/IP constraints are constructed from the searchtype information in the query.
dag-matchtype = "search=" <matchtype> /
"search=substring" ; if matchtype not
; specified
dag-matchtype = "search=" <matchtype> / "search=substring" ; if matchtype not ; specified
dag-casetype = "case=ignore" / ; if casetype not
; specified or
; casetype=ignore
"case=consider" ; if casetype=sensitive
dag-casetype = "case=ignore" / ; if casetype not ; specified or ; casetype=ignore "case=consider" ; if casetype=sensitive
constraints = ":" dag-matchtype ";" dag-casetype
constraints = ":" dag-matchtype ";" dag-casetype
The terms for the DAG/IP query are constructed from the tokenized strings from the mail input.
The terms for the DAG/IP query are constructed from the tokenized strings from the mail input.
Daigle & Hedberg Informational [Page 28] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 28] RFC 2967 TISDAG October 2000
dag-n-terms = "FN=" n-token 0*( " and FN=" n-token) dag-o-terms = "ORG=" o-token 0*( " and ORG=" o-token) dag-l-terms = "LOC=" l-token 0*( " and LOC=" l-token) dag-r-terms = "ROLE=" r-token 0*( " and ROLE=" r-token)
dag-n-terms = "FN=" n-token 0*( " and FN=" n-token) dag-o-terms = "ORG=" o-token 0*( " and ORG=" o-token) dag-l-terms = "LOC=" l-token 0*( " and LOC=" l-token) dag-r-terms = "ROLE=" r-token 0*( " and ROLE=" r-token)
This means that the relevant DAG/IP queries are formulated as one of two types:
This means that the relevant DAG/IP queries are formulated as one of two types:
dagip-query = ( ( ( n-query / nl-query / no-query /
nol-query ) [" and template=DAGPERSON"]":"
dag-matchtype ";" dag-casetype) /
( ( ro-query / rol-query )
[" and template=DAGORGROLE"]":"
dag-matchtype ";" dag-casetype) )
dagip-query = ( ( ( n-query / nl-query / no-query / nol-query ) [" and template=DAGPERSON"]":" dag-matchtype ";" dag-casetype) / ( ( ro-query / rol-query ) [" and template=DAGORGROLE"]":" dag-matchtype ";" dag-casetype) )
n-query = dag-n-terms
nl-query = dag-n-terms " and " dag-l-terms
no-query = dag-n-terms " and " dag-o-terms
nol-query = dag-n-terms " and " dag-o-terms " and "
dag-l-terms
ro-query = dag-r-terms " and " dag-o-terms
rol-query = dag-r-terms " and " dag-o-terms " and "
dag-l-terms
n-query = dag-n-terms nl-query = dag-n-terms " 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
The examples given earlier are then translated as follows.
The examples given earlier are then translated as follows.
Example 1:
Example 1:
FN=thinking and FN=cat:search=substring;case=ignore<NL>
FN=thinking and FN=cat:search=substring;case=ignore<NL>
Example 2:
Example 2:
FN=thinking and FN=cat:search=exact;case=ignore<NL>
FN=thinking and FN=cat:search=exact;case=ignore<NL>
Example 3:
Example 3:
ROLE=thinking and ROLE=cat and ORG=space and ORG=colonization:search=substring;case=ignore<NL>
ROLE=thinking and ROLE=cat and ORG=space and ORG=colonization:search=substring;case=ignore<NL>
Querying a DAG-SAP
Querying a 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):
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):
Daigle & Hedberg Informational [Page 29] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 29] RFC 2967 TISDAG October 2000
":host=" quoted-hostname ";port=" number ";server-info=" quoted-serverinfo ";charset=" charset
":host=" quoted-hostname ";port=" number ";server-info=" quoted-serverinfo ";charset=" charset
where the response from the Referral Index included:
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.
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
For example, the referral
For example, the referral
# SERVER-TO-ASK dagsystem01<NL>
Server-info: o=thinkingcat, c=se<NL>
Host-Name: thinkingcat.com<NL>
Host-Port: 2839<NL>
Protocol: ldapv2<NL>
Source-URI: http://www.thinkcat.com
Charset: T.61<NL>
# END<NL>
# SERVER-TO-ASK dagsystem01<NL> Server-info: o=thinkingcat, c=se<NL> Host-Name: thinkingcat.com<NL> Host-Port: 2839<NL> Protocol: ldapv2<NL> Source-URI: http://www.thinkcat.com Charset: T.61<NL> # END<NL>
would yield the addition
would yield the addition
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\ c\=se;charset=T\.61
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\ c\=se;charset=T\.61
in its query to an LDAPv2 DAG-SAP.
in its query to an LDAPv2 DAG-SAP.
(N.B.: See Appendix C for further definitions of the terms used in the SERVER-TO-ASK response).
(N.B.: See Appendix C for further definitions of the terms used in the SERVER-TO-ASK response).
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.
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.
Daigle & Hedberg Informational [Page 30] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 30] RFC 2967 TISDAG October 2000
5.5.3 Chaining queries in Mail DAG-CAP
5.5.3 Chaining queries in Mail DAG-CAP
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.
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.
5.5.4 Expression of results in Mail DAG-CAP
5.5.4 Expression of results in Mail DAG-CAP
The results message is sent to the "Reply-To:" address of the originating mail, if available (see [4] for appropriate interpretation of mail originator headers). The original query is repeated, along with the message-id. The remainder of the body of the mail message is the concatenation of responses from the DAG-SAP calls, each result having the WDSP's SOURCE URI (from the referral) appended to it, and the system messages also having been removed.
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.
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.
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.
5.5.5 Expression of Errors in Mail DAG-CAP
5.5.5 Expression of Errors in Mail DAG-CAP
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.
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.
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.
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.
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.
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.
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.
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.
Daigle & Hedberg Informational [Page 31] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 31] RFC 2967 TISDAG October 2000
5.6 Web (HTTP) DAG-CAP
5.6 Web (HTTP) DAG-CAP
5.6.1 Web DAG-CAP Input
5.6.1 Web DAG-CAP Input
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.
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.
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.
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.
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.
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.
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.
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.
Daigle & Hedberg Informational [Page 32] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 32] RFC 2967 TISDAG October 2000
The variables that are expected are:
The variables that are expected are:
transaction = "new" / "chain" ; default is "new". This
; should not be user-settable. It is used
; in constructed URLs
resulttype = "all" / "referrals" ; default is "all"
matchtype = "substring" / "exact"
casetype = "case ignore" / "case sensitive"
n-term = string
o-term = string
l-term = string
r-term = string
host-term = string
port-term = string
servinfo-term = string
prot-term = string ; the protocol of the referral
string = <UNICODE-2-0-UTF-8> / <UNICODE-1-1-UTF-8> /
<ISO-8859-1>
取引は「新しい」/「チェーン」と等しいです。 デフォルトは「新しいです」。 これ。 ユーザ「舗装用敷石-可能」であるはずがありません。 それは使用されています。 組み立てられたURLでは、resulttypeは「すべて」/「紹介」と等しいです。 デフォルト「ケースは無視する」「サブストリング」/「正確である」「all」のmatchtype=casetype=が/「大文字と小文字を区別している」というn-用語=ストリングo-用語=ストリングl-用語=ストリングr-用語はストリングホスト用語=ストリングポート用語=ストリングservinfo-用語=ストリングprot-用語=ストリングと等しいです。 紹介ストリング=<ユニコード2-0-UTF-8のプロトコル、>/<ユニコード1-1-UTF-8、>/<ISO-8859-1>。
5.6.2 Translation from Web query to DAG/IP
5.6.2 ウェブ質問からDAG/IPまでの翻訳
Querying a DAG-SAP Directly
直接縁飾り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.
取引変数が「チェーン」であるなら、ポストの情報は、Referral Indexの検索をするのではなく、特定の紹介を追求するのに使用されます。 適切なDAG-SAP(prot-用語から、推論される)は直接連絡されて、質問を発行されます。
Results from this type of query are always full results (i.e., not referrals).
このタイプの質問からの結果はいつも完全な結果(すなわち、紹介でない)です。
Querying the Referral Index
紹介インデックスについて質問します。
A key element of translating from the Web DAG-CAP input into the DAG/IP query format is to "tokenize" the input terms into single token elements for the DAG/IP query. For example, the n-term
ウェブDAG-CAP入力からDAG/IP質問形式に翻訳する主要な要素は入力用語のDAG/IP質問のためにただ一つの象徴要素に"tokenizeする"であることです。 例えば、n-用語
name= thinking cat
猫を考えると=を命名してください。
is tokenized into 2 n-tokens:
2つのn-象徴にtokenizedされます:
thinking cat
猫を考えます。
which are then mapped into the following in the DAG/IP query (dag-n- terms):
次に、どれがDAG/IPで以下に写像されるかが以下について質問します(縁飾り-n用語)。
FN=thinking and FN=cat
FNは考えと等しいです、そして、FNは猫と等しいです。
Daigle & Hedberg Informational [Page 33] RFC 2967 TISDAG October 2000
[33ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
The same is true for the r-term, l-term and o-term.
同じくらいはr-用語、l-用語、およびo-用語のときに本当です。
The primary steps in translating the HTTP input into a DAG/IP query are:
DAG/IP質問にHTTP入力を翻訳することにおける第一のステップは以下の通りです。
translate encodings, if necessary tokenize the strings for each term construct the DAG/IP query from the resulting components, as described in more detail below
encodingsを翻訳して、必要なら、DAG/IPが結果として起こるコンポーネントから質問するそれぞれの用語構造物のためにその他の詳細下で説明されるようにストリングをtokenizeします。
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
縁飾り-matchtypeは「検索=」<matchtype>/「検索=サブストリング」と等しいです。 matchtypeにそうしません。 指定されます。
dag-casetype = "case=ignore" / ; if casetype not
; specified or
; casetype="case ignore"
"case=consider" ; if casetype=
; "case sensitive"
縁飾り-casetypeは「=が無視するケース」/と等しいです。 casetypeにそうしません。 または、指定、。 casetypeが等しい、「ケースが無視する、」 「ケース=は考えます」。 casetype=であるなら。 「大文字と小文字を区別しています」。
constraints = ":" dag-matchtype ";" dag-casetype
「規制=」:、」 「縁飾り-matchtype」;、」 縁飾り-casetype
The terms for the DAG/IP query are constructed from the tokenized strings from the HTTP post input.
DAG/IP質問のための用語はtokenizedストリングからHTTPポスト入力から構成されます。
dag-n-terms = "FN=" n-token 0*( " and FN=" n-token) dag-o-terms = "ORG=" o-token 0*( " and ORG=" o-token) dag-l-terms = "LOC=" l-token 0*( " and LOC=" l-token) dag-r-terms = "ROLE=" r-token 0*( " and ROLE=" r-token)
縁飾り..用語..等しい..象徴..象徴..スペイン系人..用語..等しい..象徴..象徴..縁飾り..用語..等しい..象徴..象徴..縁飾り..用語..等しい..役割..象徴(「役割が」 r-象徴と等しい、)
This means that the relevant DAG/IP queries are formulated as one of two types:
これは、2の1つにタイプされるように関連DAG/IP質問が定式化されることを意味します:
dagip-query = ( ( ( n-query / nl-query / no-query / nol-query )
[" and template=DAGPERSON"]":" dag-matchtype
";" dag-casetype) /
( ( ro-query / rol-query )
[" and template=DAGORGROLE"]":" dag-matchtype
";" dag-casetype) )
dagip-質問=「」 : 」 (nol nl n-質問/質問/質問がない/質問)[「テンプレート=DAGPERSON」]縁飾り-matchtype」 ; 」 : 」 」 縁飾り-casetype) /(rol ro-質問/質問している)[「テンプレート=DAGORGROLE」]縁飾り-matchtype、」、;、」、縁飾り-casetype)
n-query = dag-n-terms
n-質問=縁飾りn用語
Daigle & Hedberg Informational [Page 34] RFC 2967 TISDAG October 2000
[34ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
nl-query = dag-n-terms " and " dag-l-terms
no-query = dag-n-terms " and " dag-o-terms
nol-query = dag-n-terms " and " dag-o-terms " and "
dag-l-terms
ro-query = dag-r-terms " and " dag-o-terms
rol-query = dag-r-terms " and " dag-o-terms " and "
dag-l-terms
nl-質問=縁飾りn用語、「」 縁飾りl質問がない=縁飾りn用語用語、「」 縁飾りo nol-質問=縁飾りn用語用語、「」 縁飾りo用語、「」 縁飾りl ro-質問=縁飾りr用語用語、「」 縁飾りo rol-質問=縁飾りr用語用語、「」 縁飾りo用語、「」 縁飾りl用語
Querying a DAG-SAP
縁飾り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サーバの情報を含まなければなりません。この情報をReferral Index SERVER- TO-ASK紹介情報から得て、Appendix Cでの指定されるとしての質問に追加します:
":host=" quoted-hostname ";port=" number ";server-info=" quoted-serverinfo ";charset=" charset
「「: ホストは」 引用されたホスト名と等しい」; 」 ポート=数」; サーバインフォメーションが」 引用されたserverinfoと等しい、」、;charsetが」 charsetと等しい
where the response from the Referral Index included:
Referral Indexからの応答を含んでいるところで:
"# SERVER-TO-ASK " serverhandle <NL> " Server-info: " serverinfo <NL> " Host-Name: " hostname <NL> " Host-Port: " number <NL> " Protocol: " prot <NL> " Source-URI: " source <NL> " Charset: " charset <NL> "# END" <NL>
「#SERVER-TO-ASK」serverhandle<NL>、「サーバインフォメーション:」 「serverinfo<NL>」ホスト名: 「ホスト名<NL>」ホストポート: 「数の<NL>」は議定書を作ります: 「prot<NL>」ソースURI: 「ソース<NL>」Charset: 「「charset<NL>」#終わり」<NL>。
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
そして、「ホスト名」と"serverinfo"からDAG/IP特殊文字を引用することによって、「引用されたホスト名」と「引用されたserverinfo」をそれぞれ得ます。
For example, the referral
例えば、紹介
# SERVER-TO-ASK dagsystem01<NL>
Server-info: o=thinkingcat, c=se<NL>
Host-Name: thinkingcat.com<NL>
Host-Port: 2839<NL>
Protocol: ldapv2<NL>
Source-URI: http://www.thinkingcat.com
Charset: T.61<NL>
# END<NL>
# 尋ねるサーバdagsystem01<NL>サーバインフォメーション: o=thinkingcat、c=se<NL>Host-名: thinkingcat.com<NL>ホストポート: 2839年の<NL>プロトコル: ldapv2<NL>ソースURI: http://www.thinkingcat.com Charset: T.61<NL>#終わりの<NL>。
would yield the addition
添加をもたらすでしょう。
Daigle & Hedberg Informational [Page 35] RFC 2967 TISDAG October 2000
[35ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\ c\=se;charset=T\.61
:ホスト=thinkingcat\.com; ポートは2839; 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.: SERVER-TO-ASK応答に使用される用語のさらなる定義に関してAppendix 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定義を見てください。
5.6.3 Chaining queries in Web DAG-CAP
5.6.3 ウェブDAG-CAPで質問をチェーニングすること。
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が「すべて」であったなら、Referral Indexから受けられた紹介のすべてが、適切なDAG-SAPsを使用することでチェーニングされます。 紹介だけが要求されたなら、Referral Index結果は返されます。
5.6.4 Expression of results in Web DAG-CAP
5.6.4 ウェブDAG-CAPの結果の表現
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.
デフォルト応答コード化はテキスト/htmlです。 resulttypeが「すべて」であったなら、DAG-SAPsからの推論応答の内容はシステムメッセージなしで1ページ応答(画定された線(例えば、弾丸の品目)あたり1つの結果エントリー)に照合されます。 最初に、明確にFNかROLE値を寄贈するべきです。 それぞれのWDSPsのためのHREFが結果になっている間、それぞれのWDSP紹介のためのSOURCE URIを寄贈するべきです。
At the end of the message, the WDSP servers that failed to respond (i.e., the DAG-SAP handling the referral returned the "% 403 Information Unavailable" message) are listed with their server-info.
「メッセージの終わり、応じなかったWDSPサーバ、(すなわち、紹介を扱うDAG-SAPが戻った、」 入手できない%403情報、」 メッセージ) それらのサーバインフォメーションで、記載されています。
If, 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が「紹介」であったなら、Referral Indexからの結果は、質問(紹介のための「ホスト=」などを含んでいる)を行うために必要事項と共にHREF URLとしてウェブDAG-CAP自身に返されます。
For example, if the original query:
例えば、オリジナルであるなら以下について質問してください。
n-term="thinking cat" resulttype="referrals"
n用語=の「考え深い猫」resulttypeは「紹介」と等しいです。
drew the following referral from the Referral Index:
Referral Indexから以下の紹介を得ました:
# SERVER-TO-ASK DAG-Serverhandle<NL>
Server-Info: c=se, o=tce<NL>
# 尋ねるサーバ縁飾り、-、Serverhandle<NL>サーバインフォメーション: c=se、o=tce<NL>。
Daigle & Hedberg Informational [Page 36] RFC 2967 TISDAG October 2000
[36ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
Host-Name: answers.tce.com<NL>
Host-Port: 1111<NL>
ホスト名: answers.tce.com<NL>ホストポート: 1111<NL>。
Protocol: ldapv3<NL>
Source-URI: http://some.service.se/
Charset: UTF-8<NL>
# END<NL>
プロトコル: ldapv3<NL>ソースURI: http://some.service.se/ Charset: UTF-8<NL>#終わりの<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「ポスト」URLがある1HTML形式のページでしょう:
n-term="thinking cat" transaction="chain" servinfo-term="c=se, o=tce" host-term="answers.tce.com" port-term="1111" prot-term="ldapv3"
「チェーン」servinfo「c=se、o=tce」ホスト"answers.tce.com"ポート「1111」prot-用語用語=用語=「考え深い猫」取引=用語=n用語=が"ldapv3""と等しいです。
The Source-URI should be established in the response as its own HREF URI.
Source-URIはそれ自身のHREF URIと応答に書き立てられるべきです。
application/whoispp-response Results
whoisppアプリケーション/応答Results
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.
コード化を受け入れます: 「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が「すべて」であったなら、すべての紹介がウェブDAG-CAPによってチェーニングされてしまうでしょう、そして、応答は完全なデータレコードだけを含むでしょう。
If the resulttype was "referrals", then all referrals are passed directly back in a single response, in correct Whois++ referral format (conveniently, this is how they are formulated in the DAG/IP). Note that this will include referrals to LDAP-based services as well as Whois++ servers.
resulttypeが「紹介」であったなら、すべての紹介が直接ただ一つの応答で通過されます、正しいWhois++紹介形式で(便利に、これは彼らがDAG/IPでどう定式化されるかということです)。 これがWhois++サーバと同様にLDAPベースのサービスに紹介を含めることに注意してください。
5.6.5 Expression of Errors in Web DAG-CAP
5.6.5 ウェブ縁飾りキャップの誤りの表現
A Web DAG-CAP may redirect a connection to another web DAG-CAP for reasons of load-balancing. This is done simply by using an HTTP redirect.
ウェブDAG-CAPはロードバランシングの理由で別のウェブDAG-CAPに接続を向け直すかもしれません。 単に再直接でHTTPを使用することによって、これをします。
Daigle & Hedberg Informational [Page 37] RFC 2967 TISDAG October 2000
[37ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
Standard Errors
標準誤差
If the web DAG-CAP receives a message that is not parsable using the query grammar described above, it sends an explanatory HTML page saying that the query could not be interpreted, and giving a description of valid queries.
ウェブDAG-CAPが上で説明された質問文法を使用することで「パー-可能」でないメッセージを受け取るなら、それは、説明しているHTML形式のページが質問を解釈できなかったと言って、有効な質問の記述を与えるのをさせます。
If the number of referrals sent by the Referral Index is greater than the pre-determined maximum (for detecting data-mining efforts, or otherwise refusing over-general queries, such as "FN=svensson"), the web DAG-CAP will send a page with an explanatory message describing the "over-generalized query" problem, suggesting the user resubmit a more precise query, and describing the list of valid query types.
Referral Indexによって送られた紹介の数が予定された最大(データマイニングの努力を検出するか、またはそうでなければ、"FN=svensson"などの過剰一般的な質問を拒否するための)より大きいなら、説明しているメッセージが「一般化され過ぎる質問」問題について説明している状態で、ウェブDAG-CAPは1ページ発信するでしょう、ユーザが、より正確な質問を再提出するのを示して、有効な質問タイプのリストについて説明して。
If the web DAG-CAP receives more than one result code from the DAG- SAPs, it must represent them all in a appropriate manner in the response.
ウェブDAG-CAPがDAG- SAPsから1つ以上の結果コードを受け取るなら、それは応答における適切な方法で彼らを皆、表さなければなりません。
application/whoispp-response Errors
whoisppアプリケーション/応答Errors
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".
「あまりに多くの紹介がReferral Indexから発生すると、簡単なテキスト応答には、メッセージがある」という%503Query、も一般的である、」
5.7 Whois++ DAG-CAP
5.7+縁飾りWhois+キャップ
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: システム・コマンドは/に投票しました。私たちが別の方法でする含意を理解するほうがよいまで、リターン値として空集合を引き出すべきです。
5.7.1 Whois++ DAG-CAP Input
5.7.1 + + 縁飾りキャップが入力したWhois
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
Whois++でタイプ表現について質問してください。----------- ------------------------------------ より多くのN1「名前=」とテンプレート=USER
NL One or more "name=" and
One or more "address-locality=" and template=USER
NL Oneか、より多くの「名前=」とOneか、より多くの「アドレス場所=」とテンプレート=USER
NO One or more "name=" and
one or more "organization-name=" and template=USER
どんなOneも、より多くの「名前=」と、1「組織名=」とテンプレートもUSERと等しくはありません。
Daigle & Hedberg Informational [Page 38] RFC 2967 TISDAG October 2000
[38ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
NOL One or more "name=" and
one or more "organization-name=" and
one or more "address-locality=" and template=USER
1個以上のNOL Oneか、より多くの「名前=」と、1「組織名=」と、「アドレス場所=」とテンプレートがUSERと等しいです。
RO One or more "org-role=" and
one or more "organization-name=" and template=ORGROLE
1個以上のRO Oneか、より多くの「org役割=」と、「組織名=」とテンプレートがORGROLEと等しいです。
ROL One or more "org-role=" and
one or more "organization-name=" and
one or more "address-locality=" and template=ORGROLE
1個以上のROL Oneか、より多くの「org役割=」と、1「組織名=」と、「アドレス場所=」とテンプレートがORGROLEと等しいです。
Table 5.1 Allowable Whois++ Queries
テーブル5.1 + +が質問する許容できるWhois
The following constraints must be supported for queries:
質問のために以下の規制を支持しなければなりません:
"search=" (substring / exact) "case=" (ignore / consider)
「検索=」(サブストリング/正確な)「ケース=」(無視するか、または考えます)
If no constraints are defined in a query the default is exact and ignore. For example,
規制が全く質問で定義されないなら、デフォルトはそうです。強要して、無視します。 例えば
FN=foo and loc=kista and fn=bar<NL>
FN=foo、loc=kista、およびfnはバー<NL>と等しいです。
is a perfectly valid Whois++ NL query for "Foo Bar" in "Kista".
+ + 完全に有効なWhoisは"Kista"の「Fooバー」へのNL質問ですか?
5.7.2 Translation from Whois++ query to DAG/IP
5.7.2 Whois++質問からDAG/IPまでの翻訳
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質問を定式化します(Table5.1で定義されるように)。
For example, the above query would be expressed as:
例えば、上の質問は以下として言い表されるでしょう。
FN=foo and LOC=kista and FN=bar and template=DAGPERSON<NL>
FN=foo、LOC=kista、およびFNはバーとテンプレート=DAGPERSON<NL>と等しいです。
Querying a DAG-SAP
縁飾り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サーバの情報を含まなければなりません。この情報をReferral Index SERVER- TO-ASK紹介情報から得て、付録Cにおける指定されるとしての質問に追加します:
":host=" quoted-hostname ";port=" number ";server-info=" quoted-serverinfo ";charset=" charset
「「: ホストは」 引用されたホスト名と等しい」; 」 ポート=数」; サーバインフォメーションが」 引用されたserverinfoと等しい、」、;charsetが」 charsetと等しい
Daigle & Hedberg Informational [Page 39] RFC 2967 TISDAG October 2000
[39ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
where the response from the Referral Index included:
Referral Indexからの応答を含んでいるところで:
"# 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>
「尋ねる#サーバ」serverhandle<NL>、「サーバインフォメーション:」 「serverinfo<NL>」ホスト名: 「ホスト名<NL>」ホストポート: 「数の<NL>」は議定書を作ります: 「prot<NL>」ソースURI: 「ソース<NL>」Charset: 「charset<NL>」#終わりの「<NL>」
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
そして、「ホスト名」と"serverinfo"からDAG/IP特殊文字を引用することによって、「引用されたホスト名」と「引用されたserverinfo」をそれぞれ得ます。
For example, the referral
例えば、紹介
# SERVER-TO-ASK dagsystem01<NL>
Server-info: o=thinkingcat, c=se<NL>
Host-Name: thinkingcat.com<NL>
Host-Port: 2839<NL>
Protocol: ldapv2<NL>
Source-URI: http://www.thinkingcat.com/
Charset: T.61<NL>
# END<NL>
# 尋ねるサーバdagsystem01<NL>サーバインフォメーション: o=thinkingcat、c=se<NL>Host-名: thinkingcat.com<NL>ホストポート: 2839年の<NL>プロトコル: ldapv2<NL>ソースURI: http://www.thinkingcat.com/ Charset: T.61<NL>#終わりの<NL>。
would yield the addition
添加をもたらすでしょう。
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\ c\=se;charset=T\.61
:ホスト=thinkingcat\.com; ポートは2839; 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.: SERVER-TO-ASK応答に使用される用語のさらなる定義に関してAppendix 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定義を見てください。
5.7.3 Chaining in Whois++ DAG-CAP
5.7.3 +縁飾りWhois+キャップでは鎖を作ること。
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)。
Daigle & Hedberg Informational [Page 40] RFC 2967 TISDAG October 2000
[40ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
5.7.4 Expression of results in Whois++
5.7.4 Whois++の結果の表現
Results are expressed in Whois++ by collating the DAG/IP results received from DAG-SAPs (using the FULL response), and using the template and attribute mappings defined in Appendix B. For each result from a given referral, the SOURCE attribute is added, with the value of the SOURCE-URI from the referral.
結果は+ DAG/IP結果を照合するのによる+がDAG-SAPs(FULL応答を使用する)から受けて、テンプレートを使用して、属性マッピングがAppendix B.で定義したWhoisで言い表されます。Forはそれぞれ与えられた紹介から生じて、SOURCE属性は加えられます、紹介からのSOURCE-URIの値で。
Any referrals to other Whois++ servers provided by the Referral Index are sent directly to the Whois++ client as follows:
+ + サーバがReferral Indexで提供した他の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>
尋ねる「尋ねるサーバ=」#サーバ、「縁飾り、-、Serverhandle<NL>、」 サーバハンドル: 「サーバインフォメーション<NL>」ホスト名: 「ホスト<NL>」ホストポート: 「ポート<NL>」は議定書を作ります: 「プロトコル<NL>」#終わりの「<NL>」
where SERVER-INFO, HOST, PORT, PROTOCOL are drawn from the referral provided in the DAG/IP, and the SOURCE-URI information is lost.
DAG/IPに提供された紹介からSERVER-INFO、HOST、PORT、プロトコルを得て、SOURCE-URI情報が無くなるところ。
5.7.5 Expression of Errors in Whois++ DAG-CAP
5.7.5 +縁飾りWhois+キャップの誤りの表現
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++規格に続いて、Whois++DAG-CAPは誤操作を言い表すでしょう。 DAG-CAPが以下で説明されるように扱うDAGシステムの4つの特定のエラー条件があります。
When the Whois++ DAG-CAP receives a query that it cannot reply to within the (data) constraints of the DAG, it sends an error message and closes the connection. The error message includes
Whois++DAG-CAPがそれがDAGの(データ)規制の中で答えることができない質問を受けるとき、それは、エラーメッセージを送って、接続を終えます。 エラーメッセージインクルード
% 502 Search expression too complicated<NL>
%502検索表現の複雑過ぎる<NL>。
If the number of referrals sent by the Referral Index is greater than the pre-determined maximum (for detecting data-mining efforts, or otherwise refusing over-general queries, such as "FN=svensson"), the Whois++ DAG-CAP will send an error message and close the connection. The error message includes
Referral Indexによって送られた紹介の数が予定された最大(データマイニングの努力を検出するか、またはそうでなければ、"FN=svensson"などの過剰一般的な質問を拒否するための)より大きいなら、Whois++DAG-CAPはエラーメッセージを送って、接続を終えるでしょう。 エラーメッセージインクルード
% 503 Query too general<NL>
%503Query、一般的過ぎる<NL>。
(N.B.: this is different from the "Too many hits" reply, which does send partial results.)
(N.B.: これは「あまりに多くのヒット」回答と異なっています。)(回答は部分的な結果を送ります)。
Daigle & Hedberg Informational [Page 41] RFC 2967 TISDAG October 2000
[41ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
A Whois++ DAG-CAP may redirect a connection to another Whois++ DAG- CAP for reasons of load-balancing. This is expressed to the end-user client software using the SERVER-TO-ASK response with appropriate information to reach the designated alternate DAG-CAP.
Whois++DAG-CAPはロードバランシングの理由で別のWhois++DAG- CAPに接続を向け直すかもしれません。 これは、指定された交互のDAG-CAPに達するのに適切な情報があるSERVER-TO-ASK応答を使用することでエンドユーザクライアントソフトウェアに言い表されます。
If a Whois++ DAG-CAP receives several different response codes from DAG-SAPs it should try to represent them all in the response to the end-user client.
Whois++DAG-CAPがいくつかのDAG-SAPsと異なった応答コードを受け取るなら、それはエンドユーザクライアントへの応答で彼らを皆、表そうとするべきです。
The proposed mapping between DAG/IP response codes and Whois++ response codes are given in Appendix D.
DAG/IP応答コードと+ + 応答コードがAppendix Dで与えられているWhoisの間の提案されたマッピング。
5.8 LDAPv2 DAG-CAP
5.8 LDAPv2縁飾りキャップ
5.8.1 LDAPv2 DAG-CAP Input
5.8.1 LDAPv2縁飾りキャップ入力
Input to the LDAPv2 DAG-CAP follows the LDAPv2 standard ([19]). Minimally, the LDAPv2 DAG-CAP must support the following queries (adapted from the ASN.1 grammar of the standard):
LDAPv2 DAG-CAPへの入力はLDAPv2規格([19])に続きます。 最少量で、LDAPv2 DAG-CAPは以下の質問(規格のASN.1文法から、適合させられる)を支持しなければなりません:
BindRequest ::=
[APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication CHOICE {
simple [0] OCTET STRING,
krbv42LDAP [1] OCTET STRING,
krbv42DSA [2] OCTET STRING
}
BindRequest:、:= [APPLICATION0]SEQUENCE、バージョンINTEGER、(1 .127) 名前LDAPDN、認証CHOICE簡単な[0]OCTET STRING、krbv42LDAP[1]OCTET STRING、krbv42DSA[2]OCTET STRING
}
}
BindResponse ::= [APPLICATION 1] LDAPResult
BindResponse:、:= [アプリケーション1] LDAPResult
SearchRequest ::=
[APPLICATION 3] SEQUENCE {
baseObject "dc=se",
scope wholeSubtree (2),
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3)
},
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
attrsOnly BOOLEAN,
filter Filter,
SearchRequest:、:= wholeSubtree(2)は、baseObject"dc=se"と見ます、derefAliases ENUMERATED。[APPLICATION3]SEQUENCE、neverDerefAliases(0)、derefInSearching(1)、derefFindingBaseObj(2)、derefAlways(3)、sizeLimit INTEGER(0maxInt)、attrsOnlyブールであるtimeLimit INTEGER(0maxInt)はFilterをフィルターにかけます。
Daigle & Hedberg Informational [Page 42] RFC 2967 TISDAG October 2000
[42ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
attributes SEQUENCE OF AttributeType
}
属性SEQUENCE OF AttributeType
Filter ::=
CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter
}
以下をフィルターにかけてください:= 選択そして、[2]フィルタ、equalityMatch[3]AttributeValueAssertion、サブストリング[4]SubstringFilterではなく、[0]のSET OF Filter、または[1]SET OF Filter
SubstringFilter ::=
SEQUENCE {
type AttributeType,
SEQUENCE OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString
}
}
SubstringFilter:、:= 系列AttributeTypeをタイプしてください、そして、SEQUENCE OF CHOICEは[0]LDAPString、どんな[1]LDAPString、決勝[2]LDAPStringにも頭文字をつけます。
Queries against attributes in the prescribed LDAP standard schema (see Appendix B) are accepted.
処方されたLDAP標準の図式(Appendix Bを見る)の属性に対する質問を受け入れます。
N.B., this is a minimal set of supported queries, to achieve the basic DAG-defined queries. An LDAP DAG-CAP may choose to support more complex queries than this, if it undertakes to do the translation from the DAG/IP to the LDAPv2 client in a way that responds to the semantics of those queries.
N.B.、これは、基本的なDAGによって定義された質問を達成するためには1人の極小集合の支持された質問です。 LDAP DAG-CAPは、これより複雑な質問を支持するのを選ぶかもしれません、それらの質問の意味論に応じる方法でDAG/IPからLDAPv2クライアントまでの翻訳をするのを引き受けるなら。
TISDAG: Since LDAPv2 didn't specify any characterset but relied
on X.500 to do so, in practice several different charactersets are
in use in Sweden today. That the LDAPv2 CAP has no way of knowing
which characterset that are in use by a connecting client is a
problem that the TISDAG project can not solve.
TISDAG: LDAPv2が少しのキャラクタセットも指定しませんでしたが、そうするためにX.500を当てにしたので、実際には、いくつかの異なったキャラクタセットが今日、スウェーデンで使用中です。 LDAPv2 CAPにはどの接続クライアントで使用中のキャラクタセットを知るか方法が全くないのは、TISDAGプロジェクトが解決できない問題です。
Users of the DAG system will have to configure their specific
client according to information on the TISDAG web page. That page
provides very specific information (including port number) that
can be given to LDAPv2 users. The LDAP DAG-CAP listening on the
default port (389) will be the LDAPv3 one.
情報によると、DAGシステムのユーザはTISDAGウェブページで彼らの特定のクライアントを構成しなければならないでしょう。 そのページはLDAPv2ユーザに与えることができる非常に特定の情報(ポートナンバーを含んでいる)を提供します。 デフォルトポート(389)の上で聴くLDAP DAG-CAPはLDAPv3にな1るでしょう。
Daigle & Hedberg Informational [Page 43] RFC 2967 TISDAG October 2000
[43ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
5.8.2 Translation from LDAPv2 query to DAG/IP
5.8.2 LDAPv2質問からDAG/IPまでの翻訳
Querying the Referral Index
紹介インデックスについて質問します。
The essential stratagem for mapping LDAP queries into DAG/IP Referral Index queries is to tokenize the string-oriented LDAP AttributeValueAssertions or SubstringFilters and construct an appropriate DAG/IP token-oriented query in the DAG/IP. This will generalize the LDAP query and yield false-positive referrals, but should not miss any appropriate referrals.
DAG/IP Referral Index質問にLDAP質問を写像するための不可欠の戦略は、ストリング指向のLDAP AttributeValueAssertionsかSubstringFiltersをtokenizeして、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: cn-用語を含んでいますが、LDAPフィルタがどんな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.
単にAttributeValueAssertionsをtokenizingすることによって、EqualityMatch質問を扱うことができます、象徴(適切なDAGSchema属性を使用する)あたりのDAG/IP質問用語のときにグループの一人となって、DAG/IPで完全な一致を行って。
Consider the following example, represented in the ASCII expression of LDAP Filters as described in [13]):
[13])で説明されるようにLDAP FiltersのASCII表現で表された以下の例を考えてください:
(& (cn=Foo Bar)(objectclass=inetOrgPerson))
((cn=Fooバー)(objectclass=inetOrgPerson))
This query can be represented in the DAG/IP as
DAG/IPでこの質問を表すことができます。
FN="Foo" and FN="Bar":search=exact<NL>
"Foo"とFN=が「禁じる」FN=: 検索=の正確な<NL>。
N.B. The search is set up to be "case=ignore" (the DAG/IP's default) because the relevant LDAP schema attributes are all derivatives of the "name" attribute element, which is defined to have a case insensitive match.
N. B. 関連LDAP図式属性がすべて「名前」属性要素(大文字と小文字を区別しないマッチを持つために定義される)の派生物であるので、検索は「=が無視するケース」(DAG/IPのデフォルト)になるようにセットアップされます。
If no objectclass were defined the query in DAG/IP would have been
objectclassが全く定義されなかったなら、DAG/IPにおける質問があったでしょう。
(FN="Foo" and FN="bar") or (ROLE="Foo" and ROLE="bar"):search=exact
("Foo"とFN=が「禁じる」FN=)か(役割="Foo"と役割=「バー」): =が強要する検索
Daigle & Hedberg Informational [Page 44] RFC 2967 TISDAG October 2000
[44ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
inetOrgPerson is used as the objectclass in this and the following examples, although person or organizationalPerson could also have been used.
inetOrgPersonはobjectclassとしてこれと以下の例で使用されます、また、人かorganizationalPersonが使用されたかもしれませんが。
This query will yield false-positive referrals; the original LDAP query should only match against records for which the "cn" attribute is exactly the phrase "Foo Bar", whereas the DAG/IP query will yield referrals any WDSP containing records that include the two tokens "foo" and "bar" in any order.
この質問は無病誤診紹介をもたらすでしょう。 オリジナルのLDAP質問は"cn"属性がまさに「Fooバー」という句である記録に対して合うだけであるべきであり、DAG/IP質問は紹介をもたらすでしょうが、2の象徴"foo"と「バー」を含んでいる記録を含むどんなWDSPもいずれでも注文します。
For example, this DAG/IP query will yield referrals to WDSPs with records including:
例えば、譲って、:このDAG/IP質問は記録でWDSPsに紹介を譲るでしょう。
cn: Bar Foo cn: Le Bar Foo cn: Foo Bar AB
cn: Foo cnを禁じてください: Le Bar Foo cn: FooバーAB
LDAP substring queries must also be tokenized in order to construct a DAG/IP query. The additional point to bear in mind is that LDAP substring expressions are directed at phrases, which obscure potential token boundaries. Consequently, all points between substring components must be considered as potential token boundaries.
また、DAG/IP質問を構成するためにLDAPサブストリング質問をtokenizedしなければなりません。 覚えておく追加ポイントは句がLDAPサブストリング表現に向けられるということです。(句は潜在的象徴境界をあいまいにします)。 その結果、潜在的象徴境界であるとサブストリングコンポーネントの間のすべてのポイントをみなさなければなりません。
Thus, the LDAP query
その結果、LDAP質問
(& (cn=black) (o=c*t) (objectclass=inetOrgPerson))
((cn=黒)(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>
黒、ORG=c、およびFN=ORG=t: 検索=サブストリング<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,
tokenized質問がLDAPサブストリングにおける外観の注文を保存しないとき、この質問は無病誤診結果をもたらすでしょう、そして、それは句境界を保持しません。 That is,
ORG=c and ORG=t:search=substring
ORG=cとORG=t: 検索=サブストリング
will match
合うでしょう。
tabacco
tabacco
which is not a match by the LDAP query semantics.
LDAP質問意味論によるマッチではありません。
Combined EqualityMatch and Substring queries need special attention. When an LDAP query includes both EqualityMatch components and substring filter components, the DAG/IP query to the Referral Index
結合したEqualityMatchとSubstring質問は特別な注意を必要とします。 DAG/IPは、LDAP質問がいつEqualityMatchの部品とサブストリングフィルタの部品の両方を含んでいるかをReferral Indexに質問します。
Daigle & Hedberg Informational [Page 45] RFC 2967 TISDAG October 2000
[45ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
can be constructed by following the same mechanisms of tokenization, but the whole search will become a substring search, as the DAG/IP defines only search types across the entire query for Referral Index queries.
トークン化の同じメカニズムに従うことで組み立てることができますが、全体の検索はサブストリング検索になるでしょう、DAG/IPがReferral Index質問のための全体の質問の向こう側に検索タイプだけを定義するとき。
Thus,
このようにして
(& (cn=Foo Bar) (o=c*t) (objectclass=inetOrgPerson))
((cn=Fooバー)(o=c*t)(objectclass=inetOrgPerson))
can be expressed as
言い表すことができます。
FN=Foo and FN=Bar and ORG=c and ORG=t:search=substring<NL>
FN=FooとFN=バー、ORG=c、およびORG=t: 検索=サブストリング<NL>。
Alternatively, the LDAP DAG-CAP could conduct two separate queries and take the intersection (the logical "AND") of the two sets of referrals returned by the Referral Index.
あるいはまた、LDAP DAG-CAPは2つの別々の質問を行って、紹介インデックスによって返された2セットの紹介の交差点(論理的な“AND")を取ることができました。
Note that DAG/IP can accept phrases for searches -- the query
DAG/IPが検索のための句を受け入れることができるというメモ--質問
FN=Foo\ bar<NL> (note the escaped space)
FN=Foo\バー<NL>。(逃げられたスペースに注意します)
is perfectly valid. However, it would match only those things which have been tokenized in a way that preserves the space, which is the empty set in the case of the data stored here.
完全に有効です。 しかしながら、それはここに格納されたデータの場合で空集合であるスペースを保持する方法でtokenizedされたそれらのものだけに合っているでしょう。
Querying a DAG-SAP
縁飾り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.
Referral Indexから紹介情報を得るのに使用されたDAG-SAPに同じ実質的な質問を使用するのは決して無効ではありません。 しかしながら、これらの質問の過剰般化は、過度の数の結果をもたらすかもしれなくて、オリジナルのLDAP質問の意味論に対して返された結果を合わせるために結果の何らかの刈り込みを必要とするでしょう。 この刈り込みに責任があるのは、LDAP DAG-CAPです、それがオリジナルの質問、意味論に応じるのに責任があることの受取人であるので。
In concrete terms, when making the DAG/IP query which is to be sent to a DAG-SAP the above mentioned queries are still valid queries, but an alternative finer-grained query is also possible, namely:
すなわち、コンクリートが呼ぶコネ、:(DAG/IPにどれがDAG-SAPに送られることになっていたらよいかを質問させて、上記の質問はまだ有効な質問ですが、また、代替の、よりきめ細かに粒状の質問もその時、可能です)。
FN=foo and FN=bar and ORG=c;search=lstring and ORG=t;search=tstring
FN=fooとFNはバーとORG=cと等しいです; 検索=のlstringとORGはtと等しいです; =tstringを捜してください。
Particularly in the case of the LDAPv2 DAG-CAP, however, there will be cause to use LDAP(v2/v3) DAG-SAPs. Since these DAG-SAPs also deal in phrase-oriented data, a less-over-generalized query can be passed to them:
しかしながら、特にLDAPv2 DAG-CAPの場合には、LDAP(v2/v3)DAG-SAPsを使用する原因があるでしょう。 また、これらのDAG-SAPsが句指向のデータを扱うので、一般化され過ぎた以下質問をそれらに通過できます:
FN=Foo\ Bar:search=exact<NL>
FN=Foo\バー: 検索=の正確な<NL>。
Daigle & Hedberg Informational [Page 46] RFC 2967 TISDAG October 2000
[46ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
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サーバの情報を含まなければなりません。この情報をReferral Index SERVER- TO-ASK紹介情報から得て、Appendix Cでの指定されるとしての質問に追加します:
":host=" quoted-hostname ";port=" number ";server-info=" quoted-serverinfo ";charset=" charset
「「: ホストは」 引用されたホスト名と等しい」; 」 ポート=数」; サーバインフォメーションが」 引用されたserverinfoと等しい、」、;charsetが」 charsetと等しい
where the response from the Referral Index included:
Referral Indexからの応答を含んでいるところで:
"# 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>
「尋ねる#サーバ」serverhandle<NL>、「サーバインフォメーション:」 「serverinfo<NL>」ホスト名: 「ホスト名<NL>」ホストポート: 「数の<NL>」は議定書を作ります: 「prot<NL>」ソースURI: 「ソース<NL>」Charset: 「charset<NL>」#終わりの<NL>。
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
そして、「ホスト名」と"serverinfo"からDAG/IP特殊文字を引用することによって、「引用されたホスト名」と「引用されたserverinfo」をそれぞれ得ます。
For example, the referral
例えば、紹介
# SERVER-TO-ASK dagsystem01<NL>
Server-info: o=thinkingcat, c=se<NL>
Host-Name: thinkingcat.com<NL>
Host-Port: 2839<NL>
Protocol: ldapv2<NL>
Source-URI: http://www.thinkingcat.com <NL>
Charset: T.61<NL>
# END<NL>
# 尋ねるサーバdagsystem01<NL>サーバインフォメーション: o=thinkingcat、c=se<NL>Host-名: thinkingcat.com<NL>ホストポート: 2839年の<NL>プロトコル: ldapv2<NL>ソースURI: http://www.thinkingcat.com <NL>Charset: T.61<NL>#終わりの<NL>。
would yield the addition
添加をもたらすでしょう。
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\ c\=se;charset=T\.61
:ホスト=thinkingcat\.com; ポートは2839; 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.: SERVER-TO-ASK応答に使用される用語のさらなる定義に関してAppendix 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定義を見てください。
Daigle & Hedberg Informational [Page 47] RFC 2967 TISDAG October 2000
[47ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
5.8.3 Chaining queries in LDAPv2 DAG-CAP
5.8.3 LDAPv2 DAG-CAPで質問をチェーニングすること。
The LDAPv2 DAG-CAP relies on DAG-SAPs to resolve every referral.
LDAPv2 DAG-CAPは、あらゆる紹介を決議するためにDAG-SAPsを当てにします。
5.8.4 Expression of results in LDAPv2
5.8.4 LDAPv2の結果の表現
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
}
SearchResponse:、:= 選択エントリー[APPLICATION4]SEQUENCE、objectName LDAPDN、属性SEQUENCE OF SEQUENCE、AttributeType、SET OF AttributeValue、resultCode[APPLICATION5]LDAPResult
where
どこ
LDAPDN = DN / "cn=" (FN/ROLE) [",o="ORG] ",dc=se"
attributes = <all attributes mapped from DAG schema, and
"objectClass = inetOrgPerson",
"objectClass = top",
"objectClass = person" or
"objectClass = organizationalRole", as
appropriate, and "labeledURI = <SOURCE-URI>"
for each result from a given referral>
LDAPDNがDN/「cn=」(FN/ROLE)と等しい、[「o=、「ORG]」、属性すべての属性がDAG図式から写像した=<と、「objectClassはinetOrgPersonと等しい」、「objectClassは先端と等しい」、「objectClassは人と等しい」、または「objectClassはorganizationalRoleと等しい」の、そして、適切なdc=se、与えられた紹介>からの各結果のために「labeledURIは<ソースURI>と等しいです」。
(Where DN,FN,ORG and ROLE are the values from the DAG schema).
(DN、FN、ORG、およびROLEがDAG図式からの値であるところ。)
I.e., where available, the entry's true DN is used; otherwise (e.g., for data coming from Whois++ servers), a reasonable facsimile is constructed.
すなわち、入手できるところでは、エントリーの本当のDNが使用されています。 さもなければ(例えばWhois++サーバから来るデータのために)、合理的なファクシミリは構成されます。
5.8.5 Expression of Errors in LDAPv2 DAG-CAP
5.8.5 LDAPv2縁飾りキャップの誤りの表現
As appropriate, the LDAPv2 DAG-CAP will express system responses following the LDAPv2 standard.
適宜、LDAPv2規格に続いて、LDAPv2 DAG-CAPはシステム・レスポンスを言い表すでしょう。
Daigle & Hedberg Informational [Page 48] RFC 2967 TISDAG October 2000
[48ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
Appendix D gives the proposed mapping between DAG/IP response codes and LDAPv2 resultcodes.
付録DはDAG/IPの応答コードとLDAPv2 resultcodesの間に提案されたマッピングを与えます。
There are 4 particular error conditions of the DAG system that the DAG-CAP will handle as described below.
DAG-CAPが以下で説明されるように扱うDAGシステムの4つの特定のエラー条件があります。
When the LDAPv2 DAG-CAP receives a query that it cannot reply to within the (data) constraints of the DAG queries, it sends an error message and closes the connection. The error message includes the LDAPv2 resultCode:
LDAPv2 DAG-CAPがそれがDAG質問の(データ)規制の中で答えることができない質問を受けるとき、それは、エラーメッセージを送って、接続を終えます。 エラーメッセージはLDAPv2 resultCodeを含んでいます:
noSuchAttribute (for incorrect schema attributes)
inappropriateMatching (when a match type other than those
supported is used, e.g. approxMatch)
unwillingToPerform (when the query is not one of the
defined types)
noSuchAttribute(不正確な図式属性のための)inappropriateMatching、(それら以外のタイプが支えたマッチが例えば使用される、approxMatch) unwillingToPerform(質問が定義されたタイプのひとりでないときに)
If the number of referrals sent by the Referral Index is greater than the pre-determined maximum (for detecting data-mining efforts, or otherwise refusing over-general queries, such as "FN=svensson"), the LDAPv2 DAG-CAP will send an error message. The error message includes one of the following resultCodes:
Referral Indexによって送られた紹介の数が予定された最大(データマイニングの努力を検出するか、またはそうでなければ、"FN=svensson"などの過剰一般的な質問を拒否するための)より大きいなら、LDAPv2 DAG-CAPはエラーメッセージを送るでしょう。 エラーメッセージは以下のresultCodesの1つを含んでいます:
sizeLimitExceeded timeLimitExceeded
sizeLimitExceeded timeLimitExceeded
An LDAPv2 DAG-CAP may redirect a connection to another LDAPv2 DAG-CAP for reasons of load-balancing. This is expressed to the end-user client software using the "umich referral" convention to direct the client software to an alternate DAG-CAP by passing the URL in an error message.
LDAPv2 DAG-CAPはロードバランシングの理由で別のLDAPv2 DAG-CAPに接続を向け直すかもしれません。 これは、エラーメッセージでURLを通過することによって交互のDAG-CAPにクライアントソフトウェアを向けるのに「umich紹介」コンベンションを使用することでエンドユーザクライアントソフトウェアに言い表されます。
Since a LDAPv2 DAG-CAP only can send one resultcode back to a client; If a LDAPv2 DAG-CAP receives several different result codes from the DAG-SAPs it will have to construct a resultmessage that to some extent represents the combination of those. It is proposed that in these cases the following actions are taken:
以来、LDAPv2 DAG-CAPだけが1resultcodeをクライアントに送り返すことができます。 LDAPv2 DAG-CAPがいくつかのDAG-SAPsと異なった結果コードを受け取ると、それはそれらの組み合わせをある程度表すresultmessageを組み立てなければならないでしょう。 これらの場合では、以下の行動が取られるよう提案されます:
- All the response codes are collected
- Each response code are translated into the corresponding LDAPv2
resultcode.
- A resultcode is chosen to represent the collected response on the
following grounds:
If "success" is the only resultcode represented after these
steps the return that result code.
If apart from "success" there is one other resultcode represented
return that other resultcode.
- すべての応答コードが集められます--それぞれの応答コードは対応するLDAPv2 resultcodeに翻訳されます。 - resultcodeは以下の根拠に集まっている応答を表すために選ばれています: 「成功」が唯一のresultcodeがこれらのステップ後に結果がコード化するリターンを表したということであるなら。 他のresultcodeが表した1つが「成功」は別としてあれば、その他のresultcodeを返してください。
Daigle & Hedberg Informational [Page 49] RFC 2967 TISDAG October 2000
[49ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
If apart from "success" there are two or more resultcodes
represented return the resultcode "other".
表された2resultcodesが「成功」は別としてあれば、resultcode「他」を返してください。
5.9 LDAPv3 DAG-CAP
5.9 LDAPv3縁飾りキャップ
5.9.1 LDAPv3 DAG-CAP Input
5.9.1 LDAPv3縁飾りキャップ入力
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定義にLDAPv3 DAG-CAPに続きます。(現在、[17])で定義されます。 最少量で、LDAPv3 DAG-CAPは以下の質問(規格のASN.1文法から、適合させられる)を支持しなければなりません:
BindRequest ::= [APPLICATION 0] SEQUENCE {
BindRequest:、:= [アプリケーション0]系列
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }
バージョンINTEGER、(1 .127) 名前LDAPDN、認証AuthenticationChoice
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials }
AuthenticationChoice:、:= 選択簡単な[0]OCTET STRING、--予約された1と2が[3] SaslCredentialsをsaslする
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
SaslCredentials:、:= 系列メカニズムLDAPString、信任状OCTET STRING OPTIONAL
BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
BindResponse:、:= [アプリケーション1] 系列LDAPResultの部品、serverSaslCreds[7]八重奏ストリング、任意
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject c=se,
scope wholeSubtree (2) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeDescriptionList }
SearchRequest:、:= baseObject c=se、wholeSubtree(2)を見てください、derefAliases ENUMERATED。[APPLICATION3]SEQUENCE、neverDerefAliases(0)、derefInSearching(1)、derefFindingBaseObj(2)、derefAlways(3)、sizeLimit INTEGER(0maxInt)、typesOnlyブールであるtimeLimit INTEGER(0maxInt)がFilterをフィルターにかける、属性AttributeDescriptionList
Daigle & Hedberg Informational [Page 50] RFC 2967 TISDAG October 2000
[50ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
Filter ::= CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter }
以下をフィルターにかけてください:= 選択そして、[2]フィルタ、equalityMatch[3]AttributeValueAssertion、サブストリング[4]SubstringFilterではなく、[0]のSET OF Filter、または[1]SET OF Filter
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
-- at least one must be present
substrings initial [0] LDAPString,
substrings any [1] LDAPString,
substrings final [2] LDAPString}
SubstringFilter:、:= 系列AttributeDescriptionをタイプしてください--少なくとも1つはプレゼントサブストリング初期の[0]LDAPStringであるに違いなく、サブストリングはどんな[1]LDAPStringです、サブストリング決勝[2]LDAPString
Queries against attributes in the proscribed LDAP standard schema (see Appendix B) are accepted.
禁止されたLDAP標準の図式(Appendix Bを見る)の属性に対する質問を受け入れます。
N.B., this is a minimal set of supported queries, to achieve the basic DAG-defined queries. An LDAP DAG-CAP may choose to support more complex queries than this, if it undertakes to do the translation from the DAG/IP to the LDAPv3 client in a way that responds to the semantics of those queries.
N.B.、これは、基本的なDAGによって定義された質問を達成するためには1人の極小集合の支持された質問です。 LDAP DAG-CAPは、これより複雑な質問を支持するのを選ぶかもしれません、それらの質問の意味論に応じる方法でDAG/IPからLDAPv3クライアントまでの翻訳をするのを引き受けるなら。
5.9.2 Translation from LDAPv3 query to DAG/IP
5.9.2 LDAPv3質問からDAG/IPまでの翻訳
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.
DAG/IP Referral Index質問にLDAP質問を写像するための不可欠の戦略は、ストリング指向のLDAP AttributeValueAssertionsかSubstringFiltersをtokenizeして、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: cn-用語を含んでいますが、LDAPフィルタがどんなobjectclass仕様も含んでいないなら、検索が人か役割のためのものであるかが不明瞭です。 これが起こると、DAG質問は、人々と役割の両方のための質問にすべてのベースをカバーしていて、質問を写像するべきです。
Daigle & Hedberg Informational [Page 51] RFC 2967 TISDAG October 2000
[51ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
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.
単にAttributeValueAssertionsをtokenizingすることによって、EqualityMatch質問を扱うことができます、象徴(適切なDAGSchema属性を使用する)あたりのDAG/IP質問用語のときにグループの一人となって、DAG/IPで完全な一致を行って。
Consider the following example, represented in the ASCII expression of LDAP Filters as described in [13]):
[13])で説明されるようにLDAP FiltersのASCII表現で表された以下の例を考えてください:
(& (cn=Foo Bar)(objectclass=person))
((cn=Fooバー)(objectclass=人))
This query can be represented in the DAG/IP as
DAG/IPでこの質問を表すことができます。
FN="Foo" and FN="Bar":search=exact<NL>
"Foo"とFN=が「禁じる」FN=: 検索=の正確な<NL>。
N.B. The search is set up to be "case=ignore" (the DAG/IP's default) because the relevant LDAP schema attributes are all derivatives of the "name" attribute element, which is defined to have a case insensitive match.
N. B. 関連LDAP図式属性がすべて「名前」属性要素(大文字と小文字を区別しないマッチを持つために定義される)の派生物であるので、検索は「=が無視するケース」(DAG/IPのデフォルト)になるようにセットアップされます。
If no objectclass where defined the query in DAG/IP would have been
objectclassでないなら、定義されるところに、DAG/IPにおける質問があったでしょう。
(FN="Foo" and FN="bar") or ( ROLE="Foo" and ROLE="bar"):search=exact
("Foo"とFN=が「禁じる」FN=)か(役割="Foo"と役割=「バー」): =が強要する検索
Although person is used as objectclass in this and the following examples, inetOrgPerson or organizationalPerson could also have been used.
人はobjectclassとしてこれと以下の例で使用されましたが、また、inetOrgPersonかorganizationalPersonが使用されたかもしれません。
This query will yield false-positive referrals; the original LDAP query should only match against records for which the "cn" attribute is exactly the phrase "Foo Bar", whereas the DAG/IP query will yield referrals any WDSP containing records that include the two tokens "foo" and "bar" in any order.
この質問は無病誤診紹介をもたらすでしょう。 オリジナルのLDAP質問は"cn"属性がまさに「Fooバー」という句である記録に対して合うだけであるべきであり、DAG/IP質問は紹介をもたらすでしょうが、2の象徴"foo"と「バー」を含んでいる記録を含むどんなWDSPもいずれでも注文します。
For example, this DAG/IP query will yield referrals to WDSPs with records including:
例えば、譲って、:このDAG/IP質問は記録でWDSPsに紹介を譲るでしょう。
cn: Bar Foo cn: Le Bar Foo cn: Foo Bar AB
cn: Foo cnを禁じてください: Le Bar Foo cn: FooバーAB
LDAP substring queries must also be tokenized in order to construct a DAG/IP query. The additional point to bear in mind is that LDAP substring expressions are directed at phrases, which obscure potential token boundaries. Consequently, all points between substring components must be considered as potential token boundaries.
また、DAG/IP質問を構成するためにLDAPサブストリング質問をtokenizedしなければなりません。 覚えておく追加ポイントは句がLDAPサブストリング表現に向けられるということです。(句は潜在的象徴境界をあいまいにします)。 その結果、潜在的象徴境界であるとサブストリングコンポーネントの間のすべてのポイントをみなさなければなりません。
Daigle & Hedberg Informational [Page 52] RFC 2967 TISDAG October 2000
[52ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
Thus, the LDAP query
その結果、LDAP質問
(& (cn=black) o=c*t) (objectclass=person))
((cnは黒と等しいです)o=c*t) (objectclass=人)
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>
黒、ORG=c、およびFN=ORG=t: 検索=サブストリング<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,
tokenized質問がLDAPサブストリングにおける外観の注文を保存しないとき、この質問は無病誤診結果をもたらすでしょう、そして、それは句境界を保持しません。 That is,
ORG=c and ORG=t:search=substring
ORG=cとORG=t: 検索=サブストリング
will match
合うでしょう。
tabacco
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とSubstring質問は特別な注意を必要とします。 LDAP質問がEqualityMatchの部品とサブストリングフィルタの部品の両方を含んでいるとき、トークン化の同じメカニズムに従うことでReferral IndexへのDAG/IP質問を構成できますが、全体の検索はサブストリング検索になるでしょう、DAG/IPが全体の質問の向こう側に検索タイプを定義するとき。
Thus,
このようにして
(& (cn=Foo Bar) (o=c*t) (objectclass=person))
((cn=Fooバー)(o=c*t)(objectclassは人と等しいです))
can be expressed as
言い表すことができます。
FN=Foo and FN=Bar and ORG=c and ORG=t:search=substring<NL>
FN=FooとFN=バー、ORG=c、およびORG=t: 検索=サブストリング<NL>。
Alternatively, the LDAP DAG-CAP could conduct two separate queries and take the intersection (the logical "AND") of the two sets of referrals returned by the Referral Index.
あるいはまた、LDAP DAG-CAPは2つの別々の質問を行って、紹介インデックスによって返された2セットの紹介の交差点(論理的な“AND")を取ることができました。
Note that DAG/IP can accept phrases for searches -- the query
DAG/IPが検索のための句を受け入れることができるというメモ--質問
FN=Foo\ bar<NL> (note the escaped space)
FN=Foo\バー<NL>。(逃げられたスペースに注意します)
is perfectly valid. However, it would match only those things which have been tokenized in a way that preserves the space, which is the empty set in the case of the data stored here.
完全に有効です。 しかしながら、それはここに格納されたデータの場合で空集合であるスペースを保持する方法でtokenizedされたそれらのものだけに合っているでしょう。
Daigle & Hedberg Informational [Page 53] RFC 2967 TISDAG October 2000
[53ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
Querying a DAG-SAP
縁飾り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.
Referral Indexから紹介情報を得るのに使用されたDAG-SAPに同じ実質的な質問を使用するのは決して無効ではありません。 しかしながら、これらの質問の過剰般化は、過度の数の結果をもたらすかもしれなくて、オリジナルのLDAP質問の意味論に対して返された結果を合わせるために結果の何らかの刈り込みを必要とするでしょう。 この刈り込みに責任があるのは、LDAP DAG-CAPです、それがオリジナルの質問、意味論に応じるのに責任があることの受取人であるので。
In concrete terms, when making the DAG/IP query which is to be sent to a DAG-SAP the above mentioned queries are still valid queries, but an alternative finer-grained query is also possible, namely:
すなわち、コンクリートが呼ぶコネ、:(DAG/IPにどれがDAG-SAPに送られることになっていたらよいかを質問させて、上記の質問はまだ有効な質問ですが、また、代替の、よりきめ細かに粒状の質問もその時、可能です)。
FN=foo and FN=bar and ORG=c;search=lstring and ORG=t;search=tstring
FN=fooとFNはバーとORG=cと等しいです; 検索=のlstringとORGはtと等しいです; =tstringを捜してください。
In querying a DAG-SAP (irrespective of the protocol of that DAG-SAP), the DAG/IP query must include information about the target WDSP server. This information is drawn from the Referral Index SERVER- TO-ASK referral information, and is appended to the query as specified in Appendix C):
DAG-SAP(そのDAG-SAPのプロトコルの如何にかかわらず)について質問する際に、DAG/IP質問は目標WDSPサーバの情報を含まなければなりません。この情報をReferral Index SERVER- TO-ASK紹介情報から得て、Appendix C)での指定されるとしての質問に追加します:
"host=" quoted-hostname ";port=" number ";server-info=" quoted-serverinfo ";charset=" charset
「「ホストは」 引用されたホスト名と等しい」; ポートは」 数と等しい」; サーバインフォメーションが」 引用された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>
Referral Indexからの応答を含んでいるところで: 「#SERVER-TO-ASK」serverhandle<NL>、「サーバインフォメーション:」 「serverinfo<NL>」ホスト名: 「ホスト名<NL>」ホストポート: 「数の<NL>」は議定書を作ります: 「prot<NL>」ソースURI: 「ソース<NL>」Charset: 「charset<NL>」#終わりの「<NL>」
and the "quoted-hostname" and "quoted-serverinfo" are obtained from "hostname" and "serverinfo" respectively, by quoting the DAG/IP special characters.
そして、「ホスト名」と"serverinfo"からDAG/IP特殊文字を引用することによって、「引用されたホスト名」と「引用されたserverinfo」をそれぞれ得ます。
For example, the referral
例えば、紹介
# SERVER-TO-ASK dagsystem01<NL>
Server-info: o=thinkingcat, c=se<NL>
Host-Name: thinkingcat.com<NL>
Host-Port: 2839<NL>
Protocol: ldapv2<NL>
Source-URI:http://www-thinkingcat.se/
# 尋ねるサーバdagsystem01<NL>サーバインフォメーション: o=thinkingcat、c=se<NL>Host-名: thinkingcat.com<NL>ホストポート: 2839年の<NL>プロトコル: ldapv2<NL>ソースURI: http://www-thinkingcat.se/
Daigle & Hedberg Informational [Page 54] RFC 2967 TISDAG October 2000
[54ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
Charset: T.61<NL>
# END<NL>
Charset: T.61<NL>#終わりの<NL>。
would yield the addition
添加をもたらすでしょう。
:host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\ c\=se;charset=T\.61
:ホスト=thinkingcat\.com; ポートは2839; 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.: SERVER-TO-ASK応答に使用される用語のさらなる定義に関してAppendix 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定義を見てください。
5.9.3 Chaining queries in LDAPv3 DAG-CAP
5.9.3 LDAPv3 DAG-CAPで質問をチェーニングすること。
The LDAPv3 DAG-CAP relies on DAG-SAPs to resolve all referrals except those to LDAPv3 servers (i.e., Whois++ referrals, currently).
LDAPv3 DAG-CAPは、LDAPv3サーバ(すなわち、現在のWhois++紹介)へのそれら以外のすべての紹介を決議するためにDAG-SAPsを当てにします。
5.9.4 Expression of results in LDAPv3
5.9.4 LDAPv3の結果の表現
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 }
SearchResultEntry:、:= [アプリケーション4] 系列objectName LDAPDN、属性PartialAttributeList
PartialAttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
PartialAttributeList:、:= 系列の系列AttributeDescription、vals SET OF AttributeValueをタイプしてください。
SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL -- at least one LDAPURL element must be present
SearchResultReference:、:= [APPLICATION19]SEQUENCE OF LDAPURL--少なくとも1つのLDAPURL要素が存在していなければなりません。
SearchResultDone ::= [APPLICATION 5] LDAPResult
SearchResultDone:、:= [アプリケーション5] LDAPResult
where
どこ
LDAPDN = DN / "cn=" (FN/ROLE) [",o=" ORG] ",dc=se"
「LDAPDNがDN/「cn=」(FN/役割)と等しい、[「oが」 ORGと等しい、]、」、dc=se、」
Daigle & Hedberg Informational [Page 55] RFC 2967 TISDAG October 2000
[55ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
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
属性は与えられた紹介>LDAPResult=成功から各結果のためにすべての属性がDAG図式、「objectClassはinetOrgPersonと等しい」、「objectClassは人と等しい」、「objectClassは先端と等しい」、または「objectClassはorganizationalRoleと等しいこと」から適宜写像した<と「labeledURIは<ソースURI>と等しいこと」と等しいです。
(Where DN, FN, ROLE, and ORG are the values from the DAG schema).
(DN、FN、ROLE、およびORGがDAG図式からの値であるところ。)
I.e., where available, the entry's true DN is used; otherwise (e.g., for data coming from Whois++ servers), a reasonable facsimile is constructed.
すなわち、入手できるところでは、エントリーの本当のDNが使用されています。 さもなければ(例えばWhois++サーバから来るデータのために)、合理的なファクシミリは構成されます。
Referral URLs are constructed from the DAG/IP's SERVER-TO-ASK information as follows:
紹介URLは以下のDAG/IPのSERVER-TO-ASK情報から構成されます:
refurl = "ldap://" HOST [":" PORT] "/" (SERVER-INFO / "dc=se")
「「再-巻」くのは「」 ldap://HOST[「:」 ポート]」/と等しいです」(サーバインフォメーション/"dc=se")
The intention is that WDSPs using LDAPv3 servers will provide an appropriate LDAPDN for their server in the SERVER-INFO. Clients are then expected to repeat their query at the server designated by this URL (i.e., the refURL does not include the query).
意志はLDAPv3サーバを使用するWDSPsがSERVER-INFOのそれらのサーバに適切なLDAPDNを提供するということです。 そして、クライアントがこのURLによって指定されたサーバで彼らの質問を繰り返すと予想されます(すなわち、refURLは質問を含んでいません)。
5.9.5 Expression of Errors in LDAPv3 DAG-CAP
5.9.5 LDAPv3縁飾りキャップの誤りの表現
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規格に続いて、LDAPv3 DAG-CAPは誤操作を言い表すでしょう。 DAG-CAPが以下で説明されるように扱うDAGシステムの4つの特定のエラー条件があります。
When the LDAPv3 DAG-CAP receives a query that it cannot reply to within the (data) constraints of the DAG queries, it sends an error message and closes the connection. The error message includes the LDAPv3 resultCode
LDAPv3 DAG-CAPがそれがDAG質問の(データ)規制の中で答えることができない質問を受けるとき、それは、エラーメッセージを送って、接続を終えます。 エラーメッセージはLDAPv3 resultCodeを含んでいます。
noSuchAttribute (for incorrect schema attributes chosen) inappropriateMatching (when a match type other than those supported is used e.g., approxMatch) unwillingToPerform (when the query is not one of the defined types)
noSuchAttribute(選ばれた不正確な図式属性のための)inappropriateMatching、(それら以外のタイプが支えたマッチが使用されている、approxMatch) 例えば、unwillingToPerform(質問が定義されたタイプのひとりでないときに)
If the number of referrals sent by the Referral Index is greater than the pre-determined maximum (for detecting data-mining efforts, or otherwise refusing over-general queries, such as "FN=svensson"), the LDAPv3 DAG-CAP will send an error message. The error message includes the following resultCode:
Referral Indexによって送られた紹介の数が予定された最大(データマイニングの努力を検出するか、またはそうでなければ、"FN=svensson"などの過剰一般的な質問を拒否するための)より大きいなら、LDAPv3 DAG-CAPはエラーメッセージを送るでしょう。 エラーメッセージは以下のresultCodeを含んでいます:
Daigle & Hedberg Informational [Page 56] RFC 2967 TISDAG October 2000
[56ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
adminLimitExceeded
adminLimitExceeded
An LDAPv3 DAG-CAP may redirect a connection to another LDAPv3 DAG-CAP for reasons of load-balancing. In this case, the LDAPv3 DAG-CAP sends a result message including only
LDAPv3 DAG-CAPはロードバランシングの理由で別のLDAPv3 DAG-CAPに接続を向け直すかもしれません。 この場合、LDAPv3 DAG-CAPはメッセージ包含だけを結果に送ります。
SearchResultReference ::= [APPLICATION 19] AltURL
SearchResultReference:、:= [アプリケーション19] AltURL
SearchResultDone ::= referral
SearchResultDone:、:= 紹介
where
どこ
AltURL = "ldap://" <althostport> ":" <altbase>
「AltURLは「」 ldap://<althostport>」と等しいです」 <altbase>。
Since a LDAPv3 DAG-CAP only can send one resultcode back to a client; If a LDAPv3 DAG-CAP receives several different result codes from the DAG-SAPs it will have to construct a resultmessage that to some extent represents the combination of those. It is proposed that in these cases the following actions are taken:
以来、LDAPv3 DAG-CAPだけが1resultcodeをクライアントに送り返すことができます。 LDAPv3 DAG-CAPがいくつかのDAG-SAPsと異なった結果コードを受け取ると、それはそれらの組み合わせをある程度表すresultmessageを組み立てなければならないでしょう。 これらの場合では、以下の行動が取られるよう提案されます:
- All the response codes are collected
- Each response code are translated into the corresponding LDAPv3
resultcode.
- A resultcode is chosen to represent the collected response on the
following grounds:
If "success" is the only resultcode represented after these steps
the return that result code.
If apart from "success" there is one other resultcode represented
return that other resultcode.
If apart from "success" there are two or more resultcodes
represented return the resultcode "other".
- すべての応答コードが集められます--それぞれの応答コードは対応するLDAPv3 resultcodeに翻訳されます。 - resultcodeは以下の根拠に集まっている応答を表すために選ばれています: 「成功」が唯一のresultcodeがこれらのステップ後に結果がコード化するリターンを表したということであるなら。 他のresultcodeが表した1つが「成功」は別としてあれば、その他のresultcodeを返してください。 表された2resultcodesが「成功」は別としてあれば、resultcode「他」を返してください。
5.10 Whois++ DAG-SAP
5.10 +縁飾りWhois+体液
5.10.1 Input
5.10.1 入力
The Whois++ DAG-SAP expects valid DAG/IP communications. Queries must include referral information (see below) and search terms that conform to the DAG-allowed query types (e.g., not searches for organization alone, etc).
Whois++DAG-SAPは有効なDAG/IPコミュニケーションを予想します。 質問は紹介情報(以下を見る)とDAGによって許容された質問タイプに従う検索用語(例えば、組織だけなどを捜し求めない)を含まなければなりません。
The referral information is added to the end of the DAG-SAP query, as defined in the DAG-CAP definition sections:
紹介情報はDAG-CAP定義部で定義されるようにDAG-SAP質問の終わりに加えられます:
":host=" quoted-hostname ";port=" number ";server-info=" quoted-serverinfo ";charset=" charset
「「: ホストは」 引用されたホスト名と等しい」; 」 ポート=数」; サーバインフォメーションが」 引用されたserverinfoと等しい、」、;charsetが」 charsetと等しい
Daigle & Hedberg Informational [Page 57] RFC 2967 TISDAG October 2000
[57ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
5.10.2 Translation from DAG/IP to Whois++ query
5.10.2 DAG/IPからWhois++質問までの翻訳
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:
HOSTとPORT情報は+ + サーバ質問がリモートWhoisに急送したリモートな(推定される)WhoisにTCP/IPベースの接続を作るのに使用されて、+ + サーバがWhois++DAG-SAPが受けたDAG/IP質問の残りです、以下のテンプレートID翻訳でことです:
template=DAGPERSON becomes template=USER
テンプレート=DAGPERSONはテンプレート=USERになります。
and
そして
template=DAGROLE becomes template=ORGROLE
テンプレート=DAGROLEはテンプレート=ORGROLEになります。
Additional mappings for attributes are defined in Appendix B.
属性のための追加マッピングはAppendix Bで定義されます。
Note that the search types used in the DAG/IP are not all required by the Whois++ syntax. Therefore, some Whois++ WDSPs may be using servers that do not support searches other than "exact" and "lstring" (the search types required by the Whois++ protocol standard). The Whois++ DAG-CAP may
DAG/IPに使用される検索タイプが皆、Whois++構文によって必要とされないことに注意してください。 したがって、「正確である」"lstringする"を除いて、サポートではなく、+ WDSPsが使用サーバがそれであったならそうするかもしれない+がそうするいくつかのWhoisが探します(検索タイプがWhois++プロトコル標準が必要です)。 + + 縁飾りキャップがそうするWhois
- 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質問を送ってくださいといって、通って戻ってください、」 502検索表現も複雑にした%、」、WDSPのサーバ--これらの検索タイプ(すべての質問がどんなそれらの検索タイプで表現できるというわけではないとき、不完全な結果をもたらす)だけを使用することでDAG/IP質問を構造物に翻訳してください--どんな検索タイプが彼ら(例えば、正規表現)を使用することでリモートサーバとreformulateによって支持されるかを確かめるのを試みてください。 これは働いているでしょう、過度に複雑なWhois++DAG-SAPを伴って、リモートサーバが少しの任意の検索タイプも支持しないなら少しのより良い結果ももたらさないかもしれませんが。
5.10.3 Translation of Whois++ results to DAG/IP
5.10.3 DAG/IPへのWhois++結果に関する翻訳
Any referrals that the remote WDSP server returns are pursued, following the usual Whois++ (client) fashion, by the Whois++ DAG-SAP.
Whois++DAG-SAPを普通のWhois++(クライアント)ファッションに続けて、リモートWDSPサーバが返すどんな紹介も追求されます。
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
それ自体で+ + リモートサーバかそれともセッションが中断されるかどうかとの受け取られた結果、DAG-SAPの前のセッションが設立するWhoisを設立するのが可能でないなら、結果がなくてエラーメッセージを返してください、含んでいます。
% 403 Information Unavailable<NL>
%403情報の入手できない<NL>。
Daigle & Hedberg Informational [Page 58] RFC 2967 TISDAG October 2000
[58ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
If the remote server issues any other Whois++ error message and does not yield any results, the remote server's error message will be included in the DAG-SAP's own error message; no results will be returned.
リモートサーバがいかなる他のWhois++エラーメッセージも発行して、少しの結果ももたらさないと、リモートサーバのエラーメッセージはDAG-SAPの自己のエラーメッセージに含まれるでしょう。 結果は全く返されないでしょう。
If results are successfully received from the remote server, they will be expressed using the DAG/IP -- essentially passing through all FULL response information received from the remote server, mapped into the DAGSchema using the mappings defined in Appendix A.
リモートサーバから結果を首尾よく受け取ると、本質的にはAppendix Aで定義されたマッピングを使用することでDAGSchemaに写像されたリモートサーバから受け取られたすべてのFULL応答情報を通り抜けて、DAG/IPを使用することでそれらを言い表すでしょう。
5.11 LDAPv2 DAG-SAP
5.11 LDAPv2縁飾りSAP
5.11.1 Input
5.11.1 入力
The LDAPv2 DAG-SAP expects valid DAG/IP communications. Queries must include referral information (see below) and search terms that conform to the DAG-allowed query types (e.g., not searches for organization alone, etc).
LDAPv2 DAG-SAPは有効なDAG/IPコミュニケーションを予想します。 質問は紹介情報(以下を見る)とDAGによって許容された質問タイプに従う検索用語(例えば、組織だけなどを捜し求めない)を含まなければなりません。
The referral information is added to the end of the DAG-SAP query, as defined in the DAG-CAP definition sections (as additional terms in the DAG/IP query):
紹介情報はDAG-SAP質問の終わりに加えられます、DAG-CAP定義部(DAG/IP質問における追加用語としての)で定義されるように:
":host=" quoted-hostname ";port=" number ";server-info=" quoted-serverinfo ";charset=" charset
「「: ホストは」 引用されたホスト名と等しい」; 」 ポート=数」; サーバインフォメーションが」 引用されたserverinfoと等しい、」、;charsetが」 charsetと等しい
5.11.2 Translation from DAG/IP to LDAPv2 query
5.11.2 DAG/IPからLDAPv2質問までの翻訳
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.
HOSTとPORT情報は、TCP/IPベースの接続をリモートな(推定される)LDAPv2サーバにするのに使用されます。DAG-SAPはリモートサーバで取引関係を築くでしょう、標準のLDAPv2交換処理に従って。
The search request itself will be constructed from the DAG/IP query (without the HOST, SERVER-INFO and PORT terms) as follows:
検索要求自体は以下のDAG/IP質問(HOST、SERVER-INFO、およびPORT用語のない)から構成されるでしょう:
SearchRequest ::=
[APPLICATION 3] SEQUENCE {
baseObject LDAPDN, -- from the DAG/IP query
scope baseObject (0) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3)
SearchRequest:、:= [APPLICATION3]SEQUENCE、baseObject LDAPDN--derefAliases ENUMERATED、DAG/IPから、範囲baseObject(0)について質問してください、neverDerefAliases(0)、derefInSearching(1)、derefFindingBaseObj(2)、derefAlways(3)
},
sizeLimit INTEGER (0 .. maxInt),
sizeLimit整数(0maxInt)
Daigle & Hedberg Informational [Page 59] RFC 2967 TISDAG October 2000
[59ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
timeLimit INTEGER (0 .. maxInt),
attrsOnly FALSE
filter Filter,
attributes SEQUENCE OF AttributeType
-- all DAGschema attributes
equivalents in the defined
standard LDAP schema
}
timeLimit INTEGER(0maxInt)、attrsOnly FALSEはFilterをフィルターにかけます、属性SEQUENCE OF AttributeType--すべてのDAGschemaが定義された標準のLDAP図式の同等物を結果と考えます。
Filter ::=
CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
not [2] Filter,
substrings [4] SubstringFilter,
}
以下をフィルターにかけてください:= 選択そして、[2]フィルタ、サブストリング[4]SubstringFilterではなく、[0]のSET OF Filter、または[1]SET OF Filter
SubstringFilter
SEQUENCE {
type AttributeType,
SubstringFilter SEQUENCE、AttributeTypeをタイプしてください。
SEQUENCE OF CHOICE {
substrings initial [0] LDAPString,
substrings any [1] LDAPString,
substrings final [2] LDAPString}
}
SEQUENCE OF CHOICE、サブストリングは[0]LDAPString、サブストリング[1]のいずれもLDAPString、サブストリング決勝[2]LDAPStringに頭文字をつけます。
where and, or and not filters are constructed to preserve the logic of the DAG/IP query.
そして、そして、どこ、どんなフィルタも、DAG/IP質問の論理を保存するために組み立てられません。
For the purposes of matching token-based DAG/IP queries to reasonable LDAP queries, all searches should be passed to the LDAP WDSP as substring searches. The WDSP results must then be pruned to respect token boundaries, where necessary.
象徴を拠点とする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>
\が猫: 検索=サブストリング<NL>であると思うのとFN=Foo\のバーとORGは等しいです。
would be sent to the designated LDAP WDSP as
指定されたLDAP WDSPに送るでしょう。
(& (fn=*Foo Bar*) (o=*Thinking Cat*) (objectclass=person))
((fnは*Fooバー*と等しいです)(oは猫*を考えながら、*と等しいです)(objectclass=人))
Interestingly, the query
おもしろさ、質問
FN=Foo\ Bar and ORG=Thinking\ Cat:search=exact<NL>
\が猫: 検索=の正確な<NL>であると思うのとFN=Foo\のバーとORGは等しいです。
would also be sent to the designated LDAP WDSP as
また、指定されたLDAP WDSPに送るでしょう。
Daigle & Hedberg Informational [Page 60] RFC 2967 TISDAG October 2000
[60ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
(& (fn=*Foo Bar*) (o=*Thinking Cat*) (objectclass=person))
((fnは*Fooバー*と等しいです)(oは猫*を考えながら、*と等しいです)(objectclass=人))
but the WDSPs returned results would have to be pruned to remove any results that had non-tokenizing characters on either side of "Foo Bar" and "Thinking Cat".
しかし、WDSPsはどちらかの非tokenizingしているキャラクタが面があった「Fooバー」のどんな結果も取り除くために剪定されて、「猫を考えなければならない」結果を返しました。
The final consideration for mapping DAG/IP queries into LDAP queries is the issue of character case. In LDAP, individual attribute syntaxes define the consideration of case. All of the attributes used here are case-insensitive in their definitions. Therefore, all LDAP WDSP queries are inherently case-insensitive; if the DAG/IP query calls for a case-sensitive match, the LDAP DAG-SAP will have to do pruning of the results from the DAG-SAP.
DAG/IP質問をLDAP質問に写像するための最終的な考慮はキャラクタ事件の問題です。 LDAPでは、独特の属性構文はケースの考慮を定義します。 ここで使用された属性のすべてが彼らの定義で大文字と小文字を区別しないです。 したがって、すべてのLDAP WDSP質問が本来大文字と小文字を区別しないです。 DAG/IP質問が大文字と小文字を区別するマッチを求めるなら、LDAP DAG-SAPは、DAG-SAPから結果を取り除きながら、大丈夫でなければなりません。
5.11.3 Translation of LDAPv2 results to DAG/IP
5.11.3 DAG/IPへのLDAPv2結果に関する翻訳
If it is not possible to establish an LDAPv2 session with the remote server, or if the session is interrupted before results are received, or if the remote server issues any kind of error message and produces no result, the DAG-SAP will itself return no results and an error message, including
それが可能でないなら、リモートサーバとのLDAPv2セッションかそれともリモートサーバが何か種類のエラーメッセージを発行して、結果を全く生まないなら、DAG-SAPが結果が受け取られているか、中断になる前にセッションがそれ自体で中断されるかどうか証明するために、結果がなくてエラーメッセージを返してください、含んでいます。
% 403 Information Unavailable<NL>
%403情報の入手できない<NL>。
If results are successfully received from the remote server, the attributes and values that are provided for each result message will be incorporated into the DAG/IP result, according to the schema mappings laid out in Appendix B.
リモートサーバから結果を首尾よく受け取ると、それぞれの結果メッセージに提供される属性と値をDAG/IP結果に組み入れるでしょう、Appendix Bで広げられた図式マッピングによると。
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の違いを収容するために1つの特定の調整をしなければなりません。 検索が合わせられる属性("cn"、「l」、およびLDAP schemasの「o」)は平等マッチングに大文字と小文字を区別しないとすべて定義されます。 したがって、DAG/IP質問が「ケース=は考える」規制を含んでいるなら、どんな悪くケースに入れられたものも取り除くためにリモートサーバからの結果を後処理しなければなりません。
TISDAG: The serverhandle and localhandle in the DAG/IP response
should be constructed as follows:
TISDAG: DAG/IP応答におけるserverhandleとlocalhandleは以下の通り組み立てられるべきです:
serverhandle is: <hostname-without-periods><port> (because
server DN's are not enforceably unique). E.g., a
services.bunyip.com server on 7778 would
become servicesbunyipcom7778.
localhandle is: the RDN (relative distinguished name), with
spaces replaced by "_". E.g., cn=leslie_daigle
serverhandleは以下の通りです。 <ホスト名、-期間の><なしで>を移植してください(サーバDNのものがenforceablyにユニークでないので)。 例えば7778に関するservices.bunyip.comサーバはなるでしょう。servicesbunyipcom7778. localhandleは以下の通りです。 空間を"_"に取り替えているRDN(相対的な分類名)。 例えば、cn=leslie_daigle
Daigle & Hedberg Informational [Page 61] RFC 2967 TISDAG October 2000
[61ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
5.12 LDAPv3 DAG-SAP
5.12 LDAPv3縁飾りSAP
5.12.1 Input
5.12.1 入力
The LDAPv3 DAG-SAP expects valid DAG/IP communications. Queries must include referral information (see below) and search terms that conform to the DAG-allowed query types (e.g., not searches for organization alone, etc).
LDAPv3 DAG-SAPは有効なDAG/IPコミュニケーションを予想します。 質問は紹介情報(以下を見る)とDAGによって許容された質問タイプに従う検索用語(例えば、組織だけなどを捜し求めない)を含まなければなりません。
The referral information is added to the end of the DAG-SAP query, as defined in the DAG-CAP definition sections:
紹介情報はDAG-CAP定義部で定義されるようにDAG-SAP質問の終わりに加えられます:
":host=" quoted-hostname ";port=" number ";server-info=" quoted-serverinfo ";charset=" charset
「「: ホストは」 引用されたホスト名と等しい」; 」 ポート=数」; サーバインフォメーションが」 引用されたserverinfoと等しい、」、;charsetが」 charsetと等しい
5.12.2 Translation from DAG/IP to LDAPv3 query
5.12.2 DAG/IPからLDAPv3質問までの翻訳
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.
HOSTとPORT情報は、TCP/IPベースの接続をリモートな(推定される)LDAPv3サーバにするのに使用されます。DAG-SAPはリモートサーバで取引関係を築くでしょう、標準のLDAPv3交換処理に従って。
The search request itself will be constructed from the DAG/IP query (without the HOST, SERVER-INFO and PORT terms) as follows:
検索要求自体は以下のDAG/IP質問(HOST、SERVER-INFO、およびPORT用語のない)から構成されるでしょう:
SearchRequest ::=
[APPLICATION 3] SEQUENCE {
baseObject LDAPDN, -- from the DAG/IP query
scope baseObject (0) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3)
},
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
attrsOnly FALSE
filter Filter,
attributes SEQUENCE OF AttributeType
-- all DAGschema attributes equivalents in
the defined standard LDAP schema
}
SearchRequest:、:= baseObject LDAPDN--derefAliases ENUMERATED、DAG/IPから、範囲baseObject(0)について質問してください。[APPLICATION3]SEQUENCE、neverDerefAliases(0)、derefInSearching(1)、derefFindingBaseObj(2)、derefAlways(3)、sizeLimit INTEGER(0maxInt)、timeLimit INTEGER(0maxInt)、attrsOnly FALSEはFilterをフィルターにかけます、属性SEQUENCE OF AttributeType--、定義された標準のLDAP図式のすべてのDAGschema属性同等物
Filter ::=
CHOICE {
and [0] SET OF Filter,
or [1] SET OF Filter,
以下をフィルターにかけてください:= 特選、[0] そして、フィルタ、またはフィルタの[1]セットのセット
Daigle & Hedberg Informational [Page 62] RFC 2967 TISDAG October 2000
[62ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
not [2] Filter,
substrings [4] SubstringFilter,
}
[2]フィルタ、サブストリング[4]SubstringFilterでない
SubstringFilter
SEQUENCE {
type AttributeType,
SEQUENCE OF CHOICE {
substrings initial [0] LDAPString,
substrings any [1] LDAPString,
substrings final [2] LDAPString}
}
SubstringFilter系列AttributeType、SEQUENCE OF CHOICEをタイプしてください、サブストリングは[0]LDAPString、サブストリング[1]のいずれもLDAPString、サブストリング決勝[2]LDAPStringに頭文字をつけます。
where and, or and not filters are constructed to preserve the logic of the DAG/IP query.
そして、そして、どこ、どんなフィルタも、DAG/IP質問の論理を保存するために組み立てられません。
For the purposes of matching token-based DAG/IP queries to reasonable LDAP queries, all searches should be passed to the LDAP WDSP as substring searches. The WDSP results must then be pruned to respect token boundaries, where necessary.
象徴を拠点とする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>
\が猫: 検索=サブストリング<NL>であると思うのとFN=Foo\のバーとORGは等しいです。
would be sent to the designated LDAP WDSP as
指定されたLDAP WDSPに送るでしょう。
(&(fn=*Foo Bar*)(o=*Thinking Cat*)(objectClass=person))
((fnは*Fooバー*と等しいです)(oは猫*を考えながら、*と等しいです)(objectClass=人))
Interestingly, the query
おもしろさ、質問
FN=Foo\ Bar and ORG=Thinking\ Cat:search=exact<NL>
\が猫: 検索=の正確な<NL>であると思うのとFN=Foo\のバーとORGは等しいです。
would also be sent to the designated LDAP WDSP as
また、指定されたLDAP WDSPに送るでしょう。
(&(fn=*Foo Bar*)(o=*Thinking Cat*)(objectClass=person))
((fnは*Fooバー*と等しいです)(oは猫*を考えながら、*と等しいです)(objectClass=人))
but the WDSP's returned results would have to be pruned to remove any results that had non-tokenizing characters on either side of "Foo Bar" and "Thinking Cat".
しかし、WDSPはどちらかの非tokenizingしているキャラクタが面があった「Fooバー」のどんな結果も取り除くために剪定されて、「猫を考えなければならない」結果を返しました。
The final consideration for mapping DAG/IP queries into LDAP queries is the issue of character case. In LDAP, individual attribute syntaxes define the consideration of case. All of the attributes used here are case-insensitive in their definitions. Therefore, all LDAP WDSP queries are inherently case-insensitive; if the DAG/IP query calls for a case-sensitive match, the LDAP DAG-SAP will have to do pruning of the results from the DAG-SAP.
DAG/IP質問をLDAP質問に写像するための最終的な考慮はキャラクタ事件の問題です。 LDAPでは、独特の属性構文はケースの考慮を定義します。 ここで使用された属性のすべてが彼らの定義で大文字と小文字を区別しないです。 したがって、すべてのLDAP WDSP質問が本来大文字と小文字を区別しないです。 DAG/IP質問が大文字と小文字を区別するマッチを求めるなら、LDAP DAG-SAPは、DAG-SAPから結果を取り除きながら、大丈夫でなければなりません。
Daigle & Hedberg Informational [Page 63] RFC 2967 TISDAG October 2000
[63ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
5.12.3 Translation of LDAPv3 results to DAG/IP
5.12.3 DAG/IPへのLDAPv3結果に関する翻訳
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が結果が受け取られているか、中断になる前にセッションがそれ自体で中断されるかどうか証明するために、結果がなくてエラーメッセージを返してください、含んでいます。
% 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結果に組み入れるでしょう。(それは、Appendix 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の違いを収容するために1つの特定の調整をしなければなりません。 検索が合わせられる属性("cn"、「l」、およびLDAP schemasの「o」)は平等マッチングに大文字と小文字を区別しないとすべて定義されます。 したがって、DAG/IP質問が「ケース=は考える」規制を含んでいるなら、どんな悪くケースに入れられたものも取り除くためにリモートサーバからの結果を後処理しなければなりません。
TISDAG: The serverhandle and localhandle in the DAG/IP response
should be constructed as follows:
TISDAG: DAG/IP応答におけるserverhandleとlocalhandleは以下の通り組み立てられるべきです:
- serverhandle is: <hostname-without-periods><port> (because
server DN's are not enforceably unique). E.g., a
services.bunyip.com server on 7778 would become
servicesbunyipcom7778.
- localhandle is: the RDN (relative distinguished name), with
spaces replaced by "_". E.g., cn=leslie_daigle
- serverhandleは以下の通りです。 <ホスト名、-期間の><なしで>を移植してください(サーバDNのものがenforceablyにユニークでないので)。 例えば7778に関するservices.bunyip.comサーバはservicesbunyipcom7778になるでしょう。 - localhandleは以下の通りです。 空間を"_"に取り替えているRDN(相対的な分類名)。 例えば、cn=leslie_daigle
5.13 Example Queries
5.13 例の質問
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.: これらの例に提示されたデータはしばしば無意味であり、単語注文のときに合うイラストとして機能するように、感度などをケースに入れさえしてくださいという場合、よかったでしょう。
Daigle & Hedberg Informational [Page 64] RFC 2967 TISDAG October 2000
[64ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
5.13.1 A Whois++ Query
5.13.1 Whois++質問
What the Whois++ DAG-CAP Receives
+縁飾りWhois+キャップが受けるもの
In this example, the Whois++ DAG-CAP receives the following query:
この例では、Whois++DAG-CAPは以下の質問を受けます:
name=thinking and name=cat:search=exact;case=consider<NL>
名前=猫: 考えと検索=が強要する名前=; ケース=は、<NLが>であると考えます。
The expected answer can be described as:
予想された答えを以下と説明できます。
Any USER templates that contain the tokens "thinking" and "cat" in a name attribute.
名前属性に象徴「考え」と「猫」を含むどんなUSERテンプレート。
For example:
例えば:
Different records:
異なった記録:
name: the thinking cat name: sublime cat thinking
以下を命名してください。 考え深い猫名: 高尚な猫考え
or a single record with 2 or more name attributes
または、2つ以上の名前属性があるただ一つの記録
name: thinking felines name: erudite cat
以下を命名してください。 考え深いネコ科の動物は以下を命名します。 博学な猫
but not
しかし
name: Thinking Cat Enterprises
以下を命名してください。 猫計画を考えます。
This last record would not match because the query called for case sensitivity, and the case of the name attribute's value does not match the query.
質問がケース感度を求めたので、この最後の記録は合っていないでしょう、そして、名前属性の価値に関するケースは質問に合っていません。
What the Whois++ DAG-CAP sends to the Referral Index
Whois++DAG-CAPがReferral Indexに送るもの
After schema translation, this is sent to the Referral Index as:
図式翻訳の後に、以下としてこれをReferral Indexに送ります。
fn=thinking and fn=cat:search=exact<NL>
fn=考えとfn=猫: 検索=の正確な<NL>。
What the Whois++ DAG-CAP Sends to an LDAP DAG-SAP
+縁飾りWhois+キャップがLDAP縁飾りSAPに送るもの
Note that the Whois++ DAG-CAP will never interact with a Whois++ DAG-SAP as the Whois++ referrals returned by the Referral Index are passed directly back to the Whois++ client.
Whois++DAG-CAPがWhois+ + + + 紹介がReferral Indexで返したWhoisが直接Whoisに渡して戻されるようなDAG-SAPの++クライアントと決して対話しないことに注意してください。
The Whois++ DAG-CAP should send the same substantive query to the DAG-SAP as it sent to the Referral Index, except that it can include the case sensitivity constraint:
Whois++DAG-CAPはReferral Indexに発信したので、同じ実質的な質問をDAG-SAPに送るはずです、ケース感度規制を含むことができるのを除いて:
Daigle & Hedberg Informational [Page 65] RFC 2967 TISDAG October 2000
[65ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
fn=thinking and fn=cat:search=exact;case=consider<NL>
fn=猫: =考えと検索=が強要するfn; ケース=は、<NLが>であると考えます。
which will be translated by the DAG-SAP into an LDAP query of the form:
どれがDAG-SAPによって形式のLDAP質問に翻訳されるだろうか:
(&(cn=*thinking*)(cn=*cat*)(objectclass=inetOrgPerson))
((cnは*を考えながら、*と等しいです)(cn=*猫*)(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).
(すなわち、異なったcnが2つの値で結果と考える2; LDAPは図式属性定義で合っているケース感度を定義します)。
or a record with:
または、以下がある記録
cn: I wish I had a thinking dog and a singing cat
cn: 私は、考え深い犬と歌っている猫を飼っていることを願っています。
The first record should be pruned by the LDAP DAG-SAP, in order to respect the semantics of the DAG/IP query.
最初の記録は、DAG/IP質問の意味論を尊敬するためにLDAP DAG-SAPによって剪定されるべきです。
5.13.2 An LDAP Query
5.13.2 LDAP質問
What the LDAP DAG-CAP Receives
LDAP縁飾りキャップが受けるもの
In this example, the LDAP DAG-CAP receives the following query (using RFC1960 notation):
この例では、LDAP DAG-CAPは以下の質問を受けます(RFC1960記法を使用して):
(& (cn=th*c*t) (o=green groceries) (objectClass=person))
((cnが等しい、第*c*t)(oは緑色の乾物と等しい)(objectClassは人と等しいです)
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"から始まるcn属性を持っている「緑色の乾物」組織の中の記録です、「t」で終わって、中央のどこかに「c」を持っていて。
cn values that would match this include:
これに合っているcn値は:
cn: thinkingcat cn: Thinking Cat cn: The Black Cat cn: Thick Mat
cn: thinkingcat cn: 考え深いCat cn: 黒猫cn: 厚く、もつれてください。
Daigle & Hedberg Informational [Page 66] RFC 2967 TISDAG October 2000
[66ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
5.13.3 What the LDAP DAG-CAP sends to the Referral Index
5.13.3 LDAP DAG-CAPがReferral Indexに送るもの
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はうっかり合っている記録を除かないReferral Indexに象徴ベースの質問を定式化しなければなりません。 最初の挑戦がLDAPのストリングベースの質問における「*」キャラクタが象徴境界をカバーできるという事実にあります。
A suitable query to the Referral Index would be:
Referral Indexへの適当な質問は以下の通りでしょう。
FN=th AND FN=C AND FN=T AND ORG=green AND ORG=groceries:search=substring<NL>
FNが等しい、そして、緑色のAND C、FN=T、およびFN=ORG=ORGは乾物: 検索=サブストリング<NL>と第等しいです。
This will generate some false positive referrals, directing the query to WDSPs containing records with the following attribute values (the match letters are in capitals for ease of identification):
これはいくつかの無病誤診紹介を発生させるでしょう、以下の属性値で記録を含むWDSPsに質問を向けて(マッチ手紙が識別の容易さのための首都にあります):
cn: wiTH three blaCk poTs
cn: wiTH three blaCk poTs
o: peaGREEN and cyan GROCERIES o: GROCERIES are GREENer than electronics
o: peaGREENとシアンGROCERIES o: GROCERIESはエレクトロニクスよりGREENerです。
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がすべてのReferral Index応答に現れるそれらの紹介だけを使用できるような方法でいくつかの質問へのオリジナルの質問を紹介インデックスに切り出すのを含んでいます。 しかしながら、これはそうです。
overkill -- the purpose of the Referral Index is to give direction on
where there may be more information
過剰殺傷--Referral Indexの目的は詳しい情報があるかもしれないところに関する指示を与えることです。
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.
Referral Indexを発生させるのがそれについて質問するのがありそうであるのは、処理する複合体と時間消費です。
What the LDAP DAG-CAP Sends to a Whois++ DAG-SAP
LDAP縁飾りキャップが+縁飾りWhois+体液に送るもの
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は、Referral Indexに発信したので、Whois++DAG-SAPに同じ質問を送るかもしれません。 ここの無病誤診はマッチとしてLDAPクライアントによって予想されない結果を意味します。 LDAP DAG-CAPはWhois++DAG-SAPによって返された情報からこれらの結果を剪定するはずです。
Or it might rewrite the query into:
または、それは質問を以下に書き直すかもしれません。
FN=th;search=lstring AND FN=C;search=substring AND FN=T;search=tstring AND ORG=green AND ORG=groceries:case=ignore<NL>
FNが等しい、第;検索=のlstringとFNはCと等しいです; =サブストリングとFN=Tを捜してください; 検索=tstringと緑色のAND ORG=ORGは乾物と等しいです: ケース=が<NL>を無視する
Daigle & Hedberg Informational [Page 67] RFC 2967 TISDAG October 2000
[67ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
What the LDAP DAG-CAP Sends to an LDAP DAG-SAP
LDAP縁飾りキャップがLDAP縁飾り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.
建築原則として、Referral Indexのために定式化されたDAG-SAPに同じ質問を送るのは決して間違っていません。 また、メモリに閉じ込めるために、すべてのDAG-SAPsが等しい状態ですべてのDAG-CAPsによって扱われるのも、注目に値します、したがって、LDAP DAG-CAPはその時、LDAP DAG-SAPに異なった質問を送る必要はないでしょう。それはいかなる他のDAG-SAPにもそうするでしょう。
So in this case the LDAP DAP-CAP could either send the same query to the LDAP DAG-SAP as it sent to the Referral Index or it could send the augmented version that is allowed to be use with the DAG-SAPs, namely:
それで、この場合Referral Indexに発信したか、またはそれがDAG-SAPsとの使用であることが許容されている増大しているバージョンを送るかもしれないようにLDAP DAP-CAPがLDAP DAG-SAPに同じ質問を送ることができた、すなわち:
FN=th;search=lstring AND FN=C;search=substring AND FN=T;search=tstring AND ORG=green\ groceries:case=ignore<NL>
FNが等しい、第;検索=のlstringとFNはCと等しいです; =サブストリングとFN=Tを捜してください; 検索=のtstringとORGは緑色の\乾物と等しいです: ケース=が<NL>を無視する
Note that this will be translated, by the LDAP DAG-SAP, into a query of the form
これがLDAP DAG-SAPによって形式の質問に翻訳されることに注意してください。
(&(cn=*th*)(cn=*c*)(cn=*t*)(o=*green groceries*) (objectClass=person))
((cnが*と等しい、*) (cnは*c*と等しいです)(cnは*t*と等しいです)(*緑色のo=乾物*)第(objectClass=人)
which is still more general than the original query.
オリジナルの質問よりなお一般的です。
Note the translation from "FN=th;search=lstring" into "cn=*th*". This is necessary, as the DAG/IP lstring constraint is based on tokens, whereas "cn=th*" refers to the beginning of the attribute's value (phrase, not token). The DAG-SAP should therefore prune out any results that include things like "oTHer plaCes for visiTors" in order to match the semantics of the DAG/IP query it received.
翻訳に注意する、「FNが等しい、検索=が第lstringされる、」、「cnが*と等しい、第*、」 これが必要です、ところが、規制をlstringするDAG/IPが象徴に基づいているとき「cnが等しい、第*、」 属性の価値(象徴ではなく、句)の始まりを参照します。 したがって、DAG-SAPは外でそれが受けたDAG/IP質問の意味論を合わせるために「もう一方は訪問者のために置く」同様のものを含んでいるどんな結果も剪定するべきです。
The DAG-CAP should then prune those results to match the semantics of the original LDAP query.
そして、DAG-CAPは、オリジナルのLDAP質問の意味論を合わせるためにそれらの結果を剪定するはずです。
6.0 Service Specifications
6.0 サービス仕様
6.1 Overview
6.1 概観
To satisfy the requirements laid out for the TISDAG project, the software built for the DAG system must be able to meet the following service specifications:
TISDAGプロジェクトのために広げられた要件を満たすために、DAGシステムのために組立てられたソフトウェアは以下のサービス仕様を満たすことができなければなりません:
- primary designated DAG-CAPs of all types (but not necessarily
secondary ones set up for load-balancing) must be available to
provide service or redirect queries on a 7x24 basis.
- すべてのタイプ(しかし、負荷分散のための必ず二次ものセットであるというわけではない)の第一の指定されたDAG-CAPsは、7×24ベースでサービスを提供するか、または質問を向け直すために利用可能でなければなりません。
Daigle & Hedberg Informational [Page 68] RFC 2967 TISDAG October 2000
[68ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
- 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秒未満以降に利用可能であるべきです。 はるかに長い間かかるために、非常に一般化された質問(すなわち、ユーザが本当に検索の焦点を合わせることができるくらいの情報を指定できないとき)を延期できます(結果を持っているのは即答を持っているより重要です)--DAGで少なくとも7日間に一度各WDSPから提供されたデータをアップデートするべきです。
6.2 WDSP Participation
6.2 WDSP参加
WDSPs who wish to participate in the DAG system do so by providing DAG-compatible access to their service, where DAG-compatible means:
DAGシステムに参加したがっているWDSPsが彼らのサービス、どこへのDAGコンパチブルアクセスにDAGコンパチブル手段を提供するかによって、そうします:
- access in (exactly) one of LDAPv2, LDAPv3, or Whois++
- 7x24 service for responding to referrals generated in the DAG
core (minimally) weekly updates of the index object describing the
information their service indexes
- use of USER and ROLE templates for Whois++ servers
- use of inetorgperson and organizationalrole objectclasses for
LDAP servers
- (ちょうど)LDAPv2の1つ、LDAPv3、またはWhois++でのアクセス--紹介に応じるための7×24サービスはDAGコアでLDAPサーバのためにそれらのサービスインデックス(USERとROLEテンプレートのWhois++サーバの使用)が使用するinetorgpersonとorganizationalrole objectclassesの情報について説明するインデックス物の(最少量で)毎週のアップデートを発生させました。
To participate, WDSPs must register each DAG-compliant server with the DAG system, providing details for each data set that it covers:
参加するために、WDSPsはそれぞれのDAG対応することのサーバをDAGシステムに登録しなければなりません、それがカバーする各データセットのための詳細を明らかにして:
- the host, port and protocol of the server
- an identifier for the dataset
- a URL for the service of preference for accessing the data
(preferred source)
- protocol-specific information
- administrative contact information
- CIP object exchange information
- サーバのホスト、ポート、およびプロトコル--データセットのための識別子--データ(ソースを好む)にアクセスするための好みのサービスのためのURL--プロトコル特有の情報--ドメイン管理者情報--CIP物の交換情報
Note that any WDSP wishing to make data available through the DAG system but unable to support these requirements may provide information through an agreement with a third-party which does meet these requirements. Thus, data can be replicated between cooperating WDSPs. The DAG referral index does not claim ownership of personal information; it directs queries to services that do, by whatever agreements with whichever relevant parties. Note that, in this case, the SOURCE-URI may direct end-users to the WDSP's existing services, not the service of the third party.
データをDAGシステムを通して利用可能ですが、これらの要件を支持できないようにしたがっているどんなWDSPも第三者とのこれらの必要条件を満たす協定で情報を提供するかもしれないことに注意してください。 したがって、協力WDSPsの間でデータを模写できます。 DAG紹介インデックスは個人情報の所有権を要求しません。 それはどの関係者と共に何でも協定をするサービスに質問を向けます。 この場合SOURCE-URIが第三者のサービスではなく、WDSPの既存のサービスにエンドユーザを向けるかもしれないことに注意してください。
6.3 Load Distribution
6.3 負荷分配
It is anticipated that the DAG system will be quite popular, and measures must be available to distribute the load of answering queries.
DAGシステムがかなりポピュラーになって、測定が回答質問の負荷を分配するために利用可能でなければならないと予期されます。
Daigle & Hedberg Informational [Page 69] RFC 2967 TISDAG October 2000
[69ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
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、およびReferral Index。 それぞれのこれらのコンポーネントの部品はreplicableであるに違いありません、そして、レプリカの間でサービスを共有しなければなりません。
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.
彼らの人員/顧客にReferral Indexを映すか、または交互のDAG-CAPs/DAG-SAPsを提供する能力を大規模なサービスプロバイダー(大企業、ISP)に許容すると考えるのはおもしろいかもしれません。 それをするための方針と可能性はこのレポートの範囲を超えています。 しかしながら、ソフトウェア・アーキテクチャは、そのような活動を支持するように設計されています。
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ネットワークによって接続された非共同見つけられたサーバハードウェアで動くかもしれないのを示します。 必要に応じてこれらのコンポーネントを模写できます。
Daigle & Hedberg Informational [Page 70] RFC 2967 TISDAG October 2000
[70ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
+====+
| | 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 |
| |
+------------------------+
+====+ | | 縁飾り上限(クライアントアクセスポイント)| | +====+ +----+ | | 縁飾りSAP(サービスアクセスポイント)| | +----+ +====+ HTTP<-->|、|、|、| +----+ +====+ | | <-->Whois++| | +====+ +----+ SMTP<-->|、|、|、| +----+ +====+ | | <-->LDAPv2| | +====+ +----+ Whois++<-->|、|、|、| +====+ +----+ | | <-->LDAPv3| | +----+ | | <-->LDAPv3| | +----+ | | <-->LDAPv3| | +====+ +----+ LDAPv2<-->|、|、|、| +====+ +====+ LDAPv3<-->|、|、|、| +====+ +------------------------+ | 紹介インデックス| <-->の一般的なインデックスプロトコル| | (CIP) +------------------------+ +------------------------+ | 紹介インデックス| | | +------------------------+
Figure 6.1 Distributable nature of DAG components
図6.1 DAGの部品のDistributable本質
Daigle & Hedberg Informational [Page 71] RFC 2967 TISDAG October 2000
[71ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
Thus, the software built to this specification must be configurable to permit the following actions:
したがって、この仕様に組立てられたソフトウェアは以下の動作を可能にするのにおいて構成可能であるに違いありません:
- DAG-CAP software must be able to handle or redistribute the primary
load. Depending on the DAG-CAP software, this may be handled by
having multiple processes attending to incoming queries, or the
DAG-CAP at the primary address for the protocol may be nothing more
than a reflector that redirects incoming queries to the address of
the least-loaded server at the moment.
- This is particularly necessary in synchronous connection protocols,
such as Whois++ and LDAP, where the goal is to minimize the amount
of time a requesting client is connected to the well-advertised
address port.
- DAG-CAP software must be able to direct referrals to different
DAG-SAPs of the same protocol type.
- DAG-CAP software must be able to detect overly general queries
(i.e., have some metric to decide that the number of referrals
generated by the Referral Index is too great).
- DAG-SAPs must be able to redirect DAG-CAP queries at their
discretion, or just refuse service because of loading (therefore
DAG-CAPs must also be able to find other DAG-SAPs)
- DAG-CAPソフトウェアは、主荷重を扱わなければならないか、または再配付できなければなりません。 DAG-CAPソフトウェアによって、複数のプロセスを入って来る質問に気を配らせることによって、これは扱われるかもしれませんか、プロトコルのためのプライマリアドレスのDAG-CAPがただ現在最も満載でないサーバのアドレスに入って来る質問を向け直す反射鏡であるかもしれません。 - これが同期接続プロトコルで特に必要です、Whois++とLDAPなどのように。そこでは、目標は要求しているクライアントがよく広告を出しているアドレス港に接続される時間を最小にすることです。 - DAG-CAPソフトウェアは同じプロトコルタイプの異なったDAG-SAPsに紹介を向けることができなければなりません。 - DAG-CAPソフトウェアはひどく一般的な質問(すなわち、いくつかをReferral Indexによって生成された紹介の数が大き過ぎると決めるためにメートル法にする)を検出できなければなりません。 - 自己判断でDAG-CAP質問を向け直さなければならない、さもなければ、DAG-SAPsはローディングのためにただサービスを拒否できなければなりません。(したがって、また、DAG-CAPsは他のDAG-SAPsを見つけることができなければなりません)
6.4 Extensibility
6.4 伸展性
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-CAPsとDAG-SAPsの基本原理を固く守ることによって、既存のDAG-CAPs、特定のプロトコルのための新しい実装(例えば、より精巧なメールベースの質問システムを構築する)、または全体で異なったプロトコルのための実装(例えば、PH)のソフトウェアを模写するのを加えることができます。 新しいDAG-CAPはDAG/IP(必要なら、後工程結果)への質問と新しいプロトコルの結果に関する翻訳に責任があります。 DAGシステムの他のどんな部分も影響を受けません。
More functionality may be added to the DAG system service (e.g., adding security certificate references to the schema of returned information) by updating the DAG schema.
より多くの機能性が、DAG図式をアップデートすることによって、DAGシステムサービス(例えば、返された情報の図式のセキュリティ証明書参照を加える)に加えられるかもしれません。
Depending on how the load on the service goes, it may be interesting to consider reducing the number of queries that are chained for protocols that inherently can handle the concept of pursuing referrals. Specifically, LDAPv3 and Whois++ both handle referrals, but the current system calls for chaining LDAPv3 (and LDAPv2) referrals for the Whois++ DAG-CAP, and vice versa. Alternatively,
サービスでの負荷がどう行くかによって、本来追求している紹介の概念を扱うことができるプロトコルのためにチェーニングされる質問の数を減少させると考えるのはおもしろいかもしれません。 + + 明確に、LDAPv3とWhois++がともに紹介を扱って、WhoisのためにLDAPv3(そして、LDAPv2)紹介をチェーニングするための現在の唯一のシステムコールがDAG-CAPであり、逆もまた同様です。 代わりに
Daigle & Hedberg Informational [Page 72] RFC 2967 TISDAG October 2000
[72ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
"virtual" DAG-CAPs could be established for each participating WDSP for each protocol the WDSP doesn't support, and referrals to those DAG-CAPs could be given to the calling client. For example, a Whois++ client would be given a Whois++ referral to the virtual Whois++ DAG-CAP for a WDSP that supports only LDAP. The importance of having one virtual DAG-CAP per WDSP is that the point of connection is the only way to distinguish which WDSP the Whois++ client thought it was connecting to.
WDSPがサポートしない各プロトコルのためのそれぞれ参加しているWDSPのために「仮想」のDAG-CAPsを設立できました、そして、それらのDAG-CAPsへの紹介を呼んでいるクライアントに与えることができました。 例えば、Whois++クライアントはWDSPのための仮想のWhois++DAG-CAPへのWhois++紹介を考えて、それがLDAPだけをサポートするということでしょう。 1WDSPあたり1仮想のDAG-CAPを持つ重要性は接続のポイントが接続していた+ + クライアントが、考えたどのWDSP Whoisを区別するか唯一の方法であるということです。
7.0 Security
7.0 セキュリティ
7.1 Information credibility
7.1 情報の真実性
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システムは情報の仲介のように完全にWDSPsから質問しているディレクトリアクセスクライアントまで目に見えなくなければなりません。 現れることができる唯一の可能な変更が別のものへの1つのキャラクタセットからの翻訳です。 うまくいけば、これは情報の意味を変更しません。
7.2 Unauthorized access
7.2 不正アクセス
In keeping with the public nature of the proposed TISDAG service, the DAG system does not provide any access control system beyond components' configuration to accept connections from recognized other components. For more detailed access control, it is up to the connected WDSPs to apply the access control.
提案されたTISDAGサービスの公共の本質で保つには、DAGシステムは、認識されるのからの接続のために他のコンポーネントを受け入れるためにどんなアクセス制御システムもコンポーネントの構成を超えたところまで提供しません。 より詳細なアクセスコントロールのために、アクセス制御を適用するのは、接続WDSPs次第です。
Since the DAG system only supports searching and retrieving information, no updates can occur through the DAG client access points.
以来、DAGシステムは探すことをサポートするだけです、そして、情報を検索して、アップデートは全くDAGクライアントアクセスポイントを通って起こることができません。
Security in updates (CIP index objects) is provided by encryption and signature of objects from registered WDSPs.
登録されたWDSPsからオブジェクトの暗号化と署名でアップデート(CIPインデックスオブジェクト)におけるセキュリティを提供します。
Daigle & Hedberg Informational [Page 73] RFC 2967 TISDAG October 2000
[73ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
8.0 Acknowledgments
8.0 承認
This work came from ideas originally put forward by Patrik Faltstrom. The TISDAG project was supported by the Swedish KK Foundation.
この仕事は元々パトリクFaltstromによって提唱された考えから来ました。 TISDAGプロジェクトはスウェーデンのKK財団によってサポートされました。
Thanks to especially to Jens Lundstrom, Thommy Eklof, Bjorn Larsson and Sandro Mazzucato for their comments on draft versions of this document.
おかげに、特にジェンLundstromに、彼らのコメントに、オンなThommy Eklof、ビヨン・ラーソン、およびサンドロスマッツカートはこのドキュメントのバージョンを作成します。
Daigle & Hedberg Informational [Page 74] RFC 2967 TISDAG October 2000
[74ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
Appendix A - DAG Schema Definitions
付録A--縁飾り図式定義
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情報schemasを利用します--特定の人々の情報のための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の中で使用された属性に関してschemasを定義します。 マッピングはAppendix Bに標準のLDAP、+ + オブジェクトが分類するWhois、およびテンプレート(それぞれ)に説明されます。
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 schemasの役割が情報の間の仲介者が異なったアクセス・プロトコルに提供したので行動することであるので、異なった基本的な図式パラダイムで、図式の属性は必要であるか、または任意であるとして特定されます。 必要な属性は、DAG検索タイプ、そして/または、最小量の返された応答にかかわるので、そう指定されます。 彼らは選択されたアクセス・プロトコルでマッピングを定義しました。 任意の属性はそれらのプロトコルのマッピングを提案しました。
It is important to note that the DAG/IP is constructed to carry any alternative attribute information that may be provided by a given WDSP; individual DAG-SAPs and DAG-CAPs may choose to pass along, interpret, or ignore any attributes not defined in this appendix.
DAG/IPが与えられたWDSPによって提供されるどんな択一的属性情報も運ぶために組み立てられることに注意するのは重要です。 個々のDAG-SAPsと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人の人のための異なったタイプの複数の電話番号を運ぶことができます。
Daigle & Hedberg Informational [Page 75] RFC 2967 TISDAG October 2000
[75ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
A.1 DAG Personal Information Schema (DAGPERSON Schema)
A.1縁飾り個人情報図式(DAGPERSON図式)
Attribute Designation Specific Description
--------- ----------- -------------------------------------
FN Required Free-text representation of full name
EMAIL Required Internet e-mail address
LOC Required Locality -- geographic region
ORG Required Person's organization
ADR-TYPE Optional Type of address that follows
("org", "home", "org-postal",
"home-postal", "unqualified")
ADR Optional Full address
ADR-STREET Optional Street address component
ADR-ROOM Optional Suite or room number component
ADR-CITY Optional City name
ADR-STATE Optional Region of address
ADR-COUNTRY Optional Country
ADR-CODE Optional Postal code component
TEL-TYPE Optional Type of telephone number (
"work", "home", "mobile",
"fax" ,"pager", "unqualified")
in the following attribute
TEL Optional A phone number for the person
SOURCE Optional The WDSP's preferred access to
their service -- a URL
DN Optional Entry's "distinguished name"
(for LDAP)
名称の明確な記述を結果と考えてください。--------- ----------- ------------------------------------- フルネームのメールRequiredインターネット電子メールアドレスLOC Required LocalityのFN Required Free-テキスト表現; ADR Optional FullアドレスADR-通りOptional通りアドレス構成要素ADR-ROOM Optional Suiteか部屋番号コンポーネントADR-市のOptional市の名前ADR-州Optionalに続く("org"、「家へ帰ってください」、「org郵便です」、「ホーム郵便です」、「資格がありません」)アドレスの地理的な領域ORG Required Personの組織ADR-TYPE Optional Type; 彼らのサービスへのWDSPが好んだ人のSOURCE Optionalのための以下の属性TEL Optional A電話番号の電話番号(「仕事」、「ホーム」、「モバイル」は、「ポケットベル」と「ファックスします」、「資格がありません」)のアドレスのADR-COUNTRY Optional Country ADR-CODE Optional Postalコードの部品TEL-TYPE Optional Typeアクセスの範囲; URL DN Optional Entryの「分類名」(LDAPのための)
Table A.1 DAGPERSON schema attributes
テーブルA.1 DAGPERSON図式属性
Daigle & Hedberg Informational [Page 76] RFC 2967 TISDAG October 2000
[76ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
A.2 DAG Organizational Role Information Schema (DAGORGROLE Schema)
A.2縁飾り組織上の任務情報図式(DAGORGROLE図式)
Attribute Designation Specific Description
--------- ----------- ---------------------
ROLE Required Name of organizational role
EMAIL Required E-mail address associated with role
ORG Required Name of organization
LOC Required Locality -- geographic region
TEL-TYPE Optional Type of telephone number
in the TEL attribute immediately
following("org" or "fax")
TEL Optional Phone number
名称の明確な記述を結果と考えてください。--------- ----------- --------------------- 組織LOC Required Localityの役割のORG Required Nameに関連している組織上の任務メールRequired EメールアドレスのROLE Required Name--すぐにTEL Optional電話番号に従う("org"か「ファックス」)TEL属性における電話番号の地理的な領域TEL-TYPE Optional Type
FN Optional Full name of current role occupant
SOURCE Optional The WDSP's preferred access to their
service -- a URL
DN Optional Entry's "distinguished name" (for LDAP)
彼らのサービスへの現在の役割の占有者SOURCE Optional WDSPの都合のよいアクセスのFN Optional Full名--URL DN Optional Entryの「分類名」(LDAPのための)
Table A.2 DAGORGROLE schema attributes
テーブルA.2 DAGORGROLE図式属性
Appendix B - Schema Mappings for Whois++ and LDAP
付録B--Whois++とLDAPのための図式マッピング
The DAG/IP makes use of two specific schemas, as defined above. However, schemas particular to access protocols need to be handled in order to appropriately address incoming user queries, and chaining queries to WDSPs. The recognized standard schemas are:
DAG/IPは上で定義されるように2の特定のschemasを利用します。 しかしながら、プロトコルにアクセスするために特定のschemasは適切に入って来るユーザー・クエリーを扱うために扱われて、WDSPsに質問を束縛する必要があります。 認識された標準のschemasは以下の通りです。
- the USER template for Whois++ ([8]) - the ORGROLE template for Whois++ ([8]) - the inetOrgperson objectclass for LDAP ([16]) - the organizationalrole objectclass for LDAP ([18])
- + + ([8])--Whois++([8])のためのORGROLEテンプレート--LDAP([16])のためのWhois inetOrgperson objectclassのためのUSERテンプレート--LDAPのためのorganizationalrole objectclass([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 schemasは標準のschemasの情報に関連して結果で戻るというTISDAGプロジェクト要件願望が基本的なWDSPでアクセス・プロトコル(LDAPv2/v3とWhois++)を使用したという情報に基づいて開発されました。 しかしながら、特にアドレス情報の場合では、それらのプロトコルに使用されるschemasは情報表現のかなりの範囲を考慮します。 実際には、これは、異なったWDSPsが、図式の異なったサブ部分を使用するか、または地方の改造を実装するのさえ選ぶかもしれないことを意味します。
Therefore, Appendix A outlines a very basic schema that can carry all the necessary information. The basic DAG-CAPs and DAG-SAPs are designed to work to that information structure. This appendix outlines the expected behaviour for DAG-SAPs mapping into the DAG/IP schema, and DAG-CAPs extracting information to pass along to client software after a chaining operation has returned results.
したがって、Appendix Aはすべての必要事項を運ぶことができる非常に基本的な図式について概説します。 基本的なDAG-CAPsとDAG-SAPsは、その情報構造に取り組むように設計されています。 この付録はDAG/IP図式、および推論操作が結果を返した後にクライアントソフトウェアに伝える情報を抜粋するDAG-CAPsにDAG-SAPsマッピングのための予想されたふるまいについて概説します。
Daigle & Hedberg Informational [Page 77] RFC 2967 TISDAG October 2000
[77ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
B.1 LDAP and the DAG Schemas
B.1 LDAPと縁飾りSchemas
The only time information is carried in the DAG schemas is when a DAG-SAP is returning information (obtained from WDSPs' servers) to a DAG-CAP using the DAG/IP. The "canonical" mappings between standard LDAP object classes (inetorgPerson, defined in [16] and organizationalRole, defined in [18] and the DAGPERSON schema and DAGORGROLE schema are defined such that information passed from an LDAP DAG-SAP to an LDAP DAG-CAP (e.g., in the case of an LDAPv3 DAG- SAP returning information chained for an LDAPv2 DAG-CAP) will be mapped into the same attributes as it was extracted.
唯一の時間情報はDAG-SAPが戻る予定であるとき、運ばれて、DAG/IPを使用するDAG-CAPへの情報(WDSPsのサーバから、得る)がDAG schemasに、あるということです。 「正準な」マッピングは標準のLDAPオブジェクトの間で属します。(inetorgPerson、[16]とorganizationalRoleで定義されています、[18]、DAGPERSON図式、およびDAGORGROLE図式で定義されているのは、それが抽出されたとき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.
しかしながら、本当に、いくつかの属性(アドレスなどの)の表現はプロトコルパラダイムの間で広く変えられます。提供される「合理的な近似」マッピングがある目標は非LDAP DAGのSAPソースから得られた情報を伝えるために基本的機構をDAG-CAPsに与えることです。 マッピングは完全でないかもしれませんが、彼らは何らかの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).
Table B.1でLDAP inetorgPersonオブジェクトのクラスとDAGPERSON図式のための正準なマッピングを与えます。 いくつかの妥当な近似マッピングがTable B.2で従います。 それを超えて、DAG-SAPsがDAG/IPにおけるどんな追加属性も回すかもしれなくて、DAG-CAPsは、認識可能ないずれも進めるか、または解釈するのを選ぶかもしれません(DAG-SAPがDAG/IPでそれを返すかもしれません、そして、例えばsn(「姓」)属性はここに記載されませんでしたが、ストリング表現を認識して、DAG-CAPはクライアントへのLDAP応答にそれを含んでいるのを選ぶことができました)。
DAGPERSON Attribute LDAP inetorgPerson attribute ------------------- ---------------------------- FN cn EMAIL mail LOC l ORG o
DAGPERSON Attribute LDAP inetorgPerson属性------------------- ---------------------------- FN cnメールメールLOC l ORG o
ADR-TYPE=org ADR-STREET street ADR-ROOM roomNumber ADR-STATE st ADR-COUNTRY c
ADR-TYPE=org ADR-通り通りのADR-ROOM roomNumber ADR-州、第ADR-COUNTRY c
ADR-TYPE=org-postal ADR postalAddress ADR-ROOM postOfficeBox ADR-CODE postalCode
ADR-タイプはorg郵便のADR postalAddress ADR-余地のpostOfficeBox ADR-コードpostalCodeと等しいです。
Daigle & Hedberg Informational [Page 78] RFC 2967 TISDAG October 2000
[78ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
ADR-TYPE=home-postal ADR homePostalAddress
ADR-タイプはホーム郵便のADR homePostalAddressと等しいです。
TEL-TYPE=work TEL telephoneNumber
TELタイプは仕事TEL telephoneNumberと等しいです。
TEL-TYPE=home TEL homePhone
TELタイプはホームTEL homePhoneと等しいです。
TEL-TYPE=fax TEL facsimileTelephoneNumber
TELタイプはファックスTEL facsimileTelephoneNumberと等しいです。
TEL-TYPE=mobile TEL mobile
TEL-TYPEはモバイルTELモバイルと等しいです。
TEL-TYPE=pager TEL pager
TEL-TYPEはポケットベルTELポケットベルと等しいです。
DN dn SOURCE labeledURI
DN dn SOURCE labeledURI
Table B.1 Canonical DAGPERSON schema & LDAP inetorgPerson attributes
テーブルB.1 Canonical DAGPERSON図式とLDAP inetorgPerson属性
DAGROLE Attribute LDAP organizationalRole attribute ----------------------- --------------------------------- ADR-TYPE=unqualified ADR street ADR-STREET street ADR-ROOM room ADR-STATE st ADR-COUNTRY c
DAGROLE Attribute LDAP organizationalRole属性----------------------- --------------------------------- ADR-TYPEが資格のないADR通りのADR-通り通りのADR-ROOM部屋ADR-州と等しい、第ADR-COUNTRY c
TEL-TYPE=unqualified TEL telephoneNumber
TELタイプは資格のないTEL telephoneNumberと等しいです。
Table B.2 Reasonable Approximations for LDAP organizationalRole attributes
LDAP organizationalRole属性のためのテーブルB.2 Reasonable Approximations
Daigle & Hedberg Informational [Page 79] RFC 2967 TISDAG October 2000
[79ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
For example, consider the following LDAP record information, in LDIF [11] format:
例えば、以下のLDAPがLDIF[11]形式に情報を記録すると考えてください:
dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetorgperson cn: Barbara Jensen cn: Barbara J Jensen cn: Babs Jensen sn: Jensen uid: bjensen telephonenumber: +1 408 5551212 description: A big sailing fan
dn: cnはバーバラ・ジェンセンと等しく、ouは製品Developmentと等しく、oはエースIndustry、c=米国objectclassと等しいです: 最高objectclass: 人のobjectclass: organizationalPerson objectclass: inetorgperson cn: バーバラジェンセンcn: バーバラJジェンセンcn: バブスジェンセンsn: ジェンセンuid: bjensen telephonenumber: +1 408 5551212記述: 航行大ファン
This would validly be carried in the DAGPERSON schema as follows:
これは確実に以下のDAGPERSON図式で運ばれるでしょう:
DN: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US FN: Barbara Jensen FN: Barbara J Jensen FN: Babs Jensen SN: Jensen TEL-TYPE: work TEL: +1 408 5551212
DN: cnはバーバラ・ジェンセンと等しく、ouは商品開発と等しく、oはエース産業と等しく、cは米国FNと等しいです: バーバラジェンセンFN: バーバラJジェンセンFN: バブスジェンセンSN: ジェンセンTELタイプ: 仕事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.
正準なマッピングは、DAG- SAPsがどんな属性、およびDAG-CAPsに沿っても送るのを選ぶかもしれないTable B.3 .BeyondでLDAP organizationalRoleオブジェクトのクラスとDAGORGROLE図式を与えるので、認識可能ないずれも解釈するかもしれません。 N.B.、organizationalRoleのクラスはEメールアドレスの包含への支給を含んでいません。 このマッピングはinetorgPersonのために定義されるようにかなり陽気にメール属性の有用性を仮定します。
Daigle & Hedberg Informational [Page 80] RFC 2967 TISDAG October 2000
[80ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
DAGORGROLE Attribute LDAP organizationalRole attribute -------------------- --------------------------------- ROLE cn EMAIL mail ORG o LOC l
DAGORGROLE Attribute LDAP organizationalRole属性-------------------- --------------------------------- ROLE cnメールメールORG o LOC l
TEL-TYPE=org TEL telephoneNumber
TELタイプはorg TEL telephoneNumberと等しいです。
TEL-TYPE=fax TEL facsimileNumber
TELタイプはファックスTEL facsimileNumberと等しいです。
FN roleOccupant DN dn SOURCE labeledURI
FN roleOccupant DN dn SOURCE labeledURI
Table B.3 Canonical mappings for LDAP organizationalRole attributes
LDAP organizationalRole属性のためのテーブルB.3 Canonicalマッピング
B.2 Whois++ and the DAG Schemas
+ B.2 Whoisの+と縁飾りSchemas
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図式とDAGORGROLE図式の間の「正準な」マッピングはTables 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
DAGPERSON Attribute Whois++USERテンプレート属性------------------- ------------------------------- FN名前メールメールLOCアドレス場所ORG組織名
ADR-TYPE=unqualified ADR address
ADR-TYPEは資格のないADRアドレスと等しいです。
ADR-TYPE=org ADR organization-address ADR-STREET organization-address-street ADR-ROOM organization-address-room ADR-CITY organization-address-city ADR-STATE organization-address-state ADR-COUNTRY organization-address-country ADR-CODE organization-address-zip-code
ADR-TYPE=org ADR組織アドレスADR-通り組織アドレス通りのADR-ROOM組織アドレス部屋ADR-市の組織アドレス都市のADR-州組織アドレス州のADR-COUNTRY組織アドレス国のADR-CODE組織アドレス郵便番号
Daigle & Hedberg Informational [Page 81] RFC 2967 TISDAG October 2000
[81ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
ADR-TYPE=home address-type=home ADR address ADR-STREET address-street ADR-ROOM address-room ADR-CITY address-city ADR-STATE address-state ADR-COUNTRY address-country ADR-CODE address-zip-code
ADR-TYPE=ホームアドレスタイプはホームADRアドレスADR-通りアドレス通りのADR-ROOMアドレス部屋ADR-市のアドレス都市のADR-州アドレス州のADR-COUNTRYアドレス国のADR-CODEアドレス郵便番号と等しいです。
TEL-TYPE=work phone-type=work TEL phone
仕事電話TEL-TYPE=タイプは仕事TEL電話と等しいです。
TEL-TYPE=home phone-type=home TEL phone
ホーム電話TEL-TYPE=タイプはホームTEL電話と等しいです。
TEL-TYPE=fax TEL fax
TEL-TYPEはファックスTELファックスと等しいです。
TEL-TYPE=mobile TEL cellular
TEL TYPE=モバイルのTELセルです。
TEL-TYPE=pager TEL pager
TEL-TYPEはポケットベルTELポケットベルと等しいです。
Table B.4 Canonical DAGPERSON schema & Whois++ USER attributes
テーブルB.4 Canonical DAGPERSON図式とWhois + + USER属性
DAGORGROLE Attribute Whois++ ORGROLE attribute -------------------- ------------------------- ROLE org-role EMAIL email ORG organization-name LOC organization-address-locality FN name
DAGORGROLE Attribute Whois++ORGROLE属性-------------------- ------------------------- ROLE org-役割のメールメールORG組織名のLOC組織アドレス場所FN名
TEL-TYPE=org TEL phone
TEL-TYPE=org TEL電話
TEL-TYPE=fax TEL fax
TEL-TYPEはファックスTELファックスと等しいです。
Table B.5 Canonical mappings for Whois++ ORGROLE attributes
Whois++ORGROLE属性のためのテーブルB.5 Canonicalマッピング
Appendix C - DAG-Internal Protocol (DAG/IP)
付録C--縁飾り内部のプロトコル(縁飾り/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++の質問相互作用プロトコルの派生物と定義されます。
Daigle & Hedberg Informational [Page 82] RFC 2967 TISDAG October 2000
[82ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
C.1 A word on the choice of DAG/IP
C.1はDAG/IPの選択に関する単語です。
The use of the DAG/IP is strictly internal to the DAG system. In that regard, it is possible make use of any query language, or define a new one.
DAG/IPの使用は厳密にDAGシステムに内部です。 そのことについては、それはどんな照会言語の可能な造の使用であるか新しいものを定義してください。
The Whois++ protocol was selected as the basis of the DAG/IP for several reasons:
Whois++プロトコルはいくつかの理由でDAG/IPの基礎として選定されました:
- it has the power and flexibility to convey all necessary queries
- it is a simple, text-based protocol; clients need not implement the
full functionality of the protocol in order to carry out minimal
queries
- the power of the full-fledge directory service query protocol will
give DAG-CAP writers the ability to express more sophisticated
queries if desired (e.g., to produce more intricate "intelligent"
matching of spellings, common character substitutions, etc).
- the text-based, delimited attribute results expression facilitates
optional inclusion of extra data supplied by WDSPs -- DAG-CAPs can
easily ignore any unknown information and continue to interpret the
rest of the result information.
- それには、すべての必要な質問を伝えるパワーと柔軟性があります--それは簡単で、テキストベースのプロトコルです。 クライアントは最小量の質問を行うためにプロトコルの完全な機能性を実装する必要はありません--望まれているなら(例えばスペルの、より複雑な「知的な」マッチング、一般的なキャラクタ代替などを生産する)、完全に羽毛でおおっているディレクトリサービス質問プロトコルのパワーは、より洗練された質問を言い表す能力をDAG-CAP作家に与えるでしょう。 - 式がWDSPsによって提供された付加的なデータの任意の包含を容易にするというテキストベースの、そして、区切られた属性結果--DAG-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++プロトコル順応(Referral Index、およびDAG- SAPsのための)のためのツールの自由に利用可能なテストスイートがあります。 詳細のためにメールを digger-info@bunyip.com に送ってください。
C.2 DAG/IP Input and Output -- Overview
C.2縁飾り/IP入出力--概要
Input interactions in DAG/IP are as defined in RFC1835, "Architecture of the WHOIS++ service" ([6]), sections 2.2 and 2.3. Section C.3 of this document adapts the grammar used in more recent descriptions of the Whois++ protocol to illustrate the syntax of the DAG/IP.
DAG/IPでの入力相互作用がRFC1835、「WHOIS++サービスのアーキテクチャ」([6])、セクション2.2と2.3で定義されるようにあります。 このドキュメントのセクションC.3はDAG/IPの構文を例証するのにWhois++プロトコルの、より最近の記述に使用される文法を適合させます。
DAG/IP output will be a subset of what is defined in RFC1835, section
2.4, except that referral responses ("SERVER-TO-ASK") contain more
information.
DAG/IP出力はRFC1835で定義されることに関する部分集合になるでしょう、セクション2.4、紹介応答(「尋ねるサーバ」)が詳しい情報を含んでいるのを除いて。
C.3 BNF for DAG/IP input and output
DAG/IP入出力のためのC.3 BNF
The following sections are adapted from the Whois++ grammar. For discussion of the semantic intent of the query protocol, and other matters, see Whois++ RFC 1835 [6].
以下のセクションはWhois++文法から適合させられます。質問の意味意図の議論に関して、プロトコル、および他の件はWhois++RFC1835[6]を見ます。
Daigle & Hedberg Informational [Page 83] RFC 2967 TISDAG October 2000
[83ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
C.3.1 The DAG/IP Input Grammar
C.3.1縁飾り/IP入力文法
The following grammar, which uses the Augmented BNF (ABNF) notation as defined in [5], defines the set of acceptable DAG/IP input.
以下の文法([5]で定義されるようにAugmented 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定義に概説されているように、規則名と文字列リテラルは、米国-ASCII文字の組にはあって、大文字と小文字を区別しないです。 「文字が例のように文法でまた、明らかに書かれると」;、」、それはそれらのencodingsの許容文字集合のすべてのそのキャラクタの値がこのプロトコルに使用したバイトを表します。 「特にユニコード」;、」 キャラクタU+003Bを意味します。(UTF-8でキャラクタをコード化するとき、003Bはバイトが次にDAG/IPプロトコルに使用される値の0x3Bであると生成するでしょう)。
dagip-command = ( system-command [":" "hold"]
/ ri-query
/ sap-query ) nl
dagip-command = ( system-command [":" "hold"] / ri-query / sap-query ) nl
ri-query = ri-terms [":" globalcnstrnts]
ri-query = ri-terms [":" globalcnstrnts]
sap-query = sap-terms [":" [sapcnstrnts][ ":" wdspinfo]]
sap-query = sap-terms [":" [sapcnstrnts][ ":" wdspinfo]]
system-command = "constraints"
/ "describe"
/ "commands"
/ "polled-by"
/ "polled-for"
/ "version"
/ "list"
/ "show" [1*sp datastring]
/ "help" [1*sp datastring]
/ "<NL>" [string]
system-command = "constraints" / "describe" / "commands" / "polled-by" / "polled-for" / "version" / "list" / "show" [1*sp datastring] / "help" [1*sp datastring] / "<NL>" [string]
ri-terms = ri-and-expr *(1*sp "or" 1*sp ri-and-expr)
ri-terms = ri-and-expr *(1*sp "or" 1*sp ri-and-expr)
ri-and-expr = ri-basic-expr *(1*sp "and" 1*sp ri-basic- expr)
ri-and-expr = ri-basic-expr *(1*sp "and" 1*sp ri-basic- expr)
ri-basic-expr = ["not" 1*sp] ri-term / ( "(" ri-terms ")" )
ri-basic-expr = ["not" 1*sp] ri-term / ( "(" ri-terms ")" )
ri-term = generalterm / specificterm / combinedterm
ri-term = generalterm / specificterm / combinedterm
sap-terms = sap-and-expr *(1*sp "or" 1*sp sap-and-expr)
sap-terms = sap-and-expr *(1*sp "or" 1*sp sap-and-expr)
sap-and-expr = sap-basic-expr *(1*sp "and" 1*sp
sap-basic-expr)
sap-and-expr = sap-basic-expr *(1*sp "and" 1*sp sap-basic-expr)
sap-basic-expr = ["not" 1*sp] sap-term / ( "(" sap-terms ")" )
sap-basic-expr = ["not" 1*sp] sap-term / ( "(" sap-terms ")" )
Daigle & Hedberg Informational [Page 84] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 84] RFC 2967 TISDAG October 2000
sap-term = ( generalterm / specificterm / combinedterm)
localcnstrnts
sap-term = ( generalterm / specificterm / combinedterm) localcnstrnts
generalterm = datastring
generalterm = datastring
TISDAG: Since the DAG system only supports certain attribute
combinations in its queries, (Table 3.1). The use of generalterm
may lead to unexpected behaviour and is therefore deprecated.
CAPs should therefore not use it even if it is in the protocol.
TISDAG: 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.
specificterm = specificname "=" datastring
specificterm = specificname "=" datastring
specificname = "handle" / "value"
specificname = "handle" / "value"
combinedterm = attributename "=" datastring
combinedterm = attributename "=" datastring
sapcnstrnts = sapcnstrnt *(";" sapcnstrnt)
sapcnstrnts = sapcnstrnt *(";" sapcnstrnt)
sapcnstrnt = localcnstrnt / globalcnstrnt
sapcnstrnt = localcnstrnt / globalcnstrnt
localcnstrnts = [";search=" sap-searchvalue] [";case="
sap-casevalue]
localcnstrnts = [";search=" sap-searchvalue] [";case=" sap-casevalue]
localcnstrnt = "search=" sap-searchvalue / "case="
sap-casevalue
localcnstrnt = "search=" sap-searchvalue / "case=" sap-casevalue
;N.B.: in the case where local and global constraints
; conflict, local constraints take precedence
; and overrides the global constraint
;N.B.: in the case where local and global constraints ; conflict, local constraints take precedence ; and overrides the global constraint
sap-searchvalue = "tstring" / searchvalue
sap-searchvalue = "tstring" / searchvalue
sap-casevalue = "consider" / "ignore"
sap-casevalue = "consider" / "ignore"
globalcnstrnts = globalcnstrnt *(";" globalcnstrnt)
globalcnstrnts = globalcnstrnt *(";" globalcnstrnt)
globalcnstrnt = "search" "=" searchvalue
/ opt-globalcnst
globalcnstrnt = "search" "=" searchvalue / opt-globalcnst
opt-globalcnst = "hold"
/ "case" "=" casevalue
/ "maxfull" "=" 1*digit
/ "maxhits" "=" 1*digit
/ "language" "=" language
/ "incharset" "=" characterset
/ "ignore" "=" attributename
/ "include" "=" attributename
opt-globalcnst = "hold" / "case" "=" casevalue / "maxfull" "=" 1*digit / "maxhits" "=" 1*digit / "language" "=" language / "incharset" "=" characterset / "ignore" "=" attributename / "include" "=" attributename
Daigle & Hedberg Informational [Page 85] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 85] RFC 2967 TISDAG October 2000
; N.B.: If an attribute is named both with the "include" and "ignore" ; constraints, the attribute is to be included in the result, but the ; system message must be "% 112 Requested constraint not fulfilled".
; N.B.: If an attribute is named both with the "include" and "ignore" ; constraints, the attribute is to be included in the result, but the ; system message must be "% 112 Requested constraint not fulfilled".
language = <The language code defined in RFC1766>
language = <The language code defined in RFC1766>
characterset = "UNICODE-2-0-UTF-8"
characterset = "UNICODE-2-0-UTF-8"
searchvalue = "exact" / "substring" / "lstring"
searchvalue = "exact" / "substring" / "lstring"
casevalue = "ignore" / "consider"
casevalue = "ignore" / "consider"
wdspinfo = attrValAss *( ";" attrValAss )
wdspinfo = attrValAss *( ";" attrValAss )
attrValAss = attributename "=" datastring
attrValAss = attributename "=" 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: 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".
datastring = 1*data-elt
datastring = 1*data-elt
attributename = 1*(<%d32-126 except specialbyte>)
; omit 127, which is DEL
attributename = 1*(<%d32-126 except specialbyte>) ; omit 127, which is DEL
data-elt = "\" specialbyte / normalbyte
data-elt = "\" specialbyte / normalbyte
normalbyte = <%d32-255, except specialbyte>
normalbyte = <%d32-255, except specialbyte>
specialbyte = " " / tab / "=" / "," / ":" / ";" / "\" /
"*" / "." / "(" / ")" / "[" / "]" / "^" /
"$" / "!" / "<NL>"
specialbyte = " " / tab / "=" / "," / ":" / ";" / "\" / "*" / "." / "(" / ")" / "[" / "]" / "^" / "$" / "!" / "<NL>"
number = 1*digit
number = 1*digit
digit = "0" / "1" / "2" / "3" / "4" /
"5" / "6" / "7" / "8" / "9"
digit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
tab = %d09 sp = %d32 ; space nl = %d13 %d10 ; CR LF
tab = %d09 sp = %d32 ; space nl = %d13 %d10 ; CR LF
Daigle & Hedberg Informational [Page 86] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 86] RFC 2967 TISDAG October 2000
NOTE: Spaces (sp) that are significant to a query must be escaped.
The following characters, when significant to the query, may be
preceded and/or followed by a single space:
: ; , ( ) = !
NOTE: Spaces (sp) that are significant to a query must be escaped. The following characters, when significant to the query, may be preceded and/or followed by a single space: : ; , ( ) = !
C.3.2 The DAG/IP Response Grammar
C.3.2 The DAG/IP Response Grammar
The following grammar, which uses the Augmented BNF (ABNF) notation as defined in RFC2234 (see [5]),
The following grammar, which uses the Augmented BNF (ABNF) notation as defined in RFC2234 (see [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.: 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.
server-resp = goodmessage mnl output mnl endmessage
/ badmessage nl endmessageclose
server-resp = goodmessage mnl output mnl endmessage / badmessage nl endmessageclose
output = 0*(full-record / server-to-ask)
output = 0*(full-record / server-to-ask)
full-record = "# FULL " template " " serverhandle " "
localhandle system-nl
1*fulldata
"# END" system-nl
full-record = "# FULL " template " " serverhandle " " localhandle system-nl 1*fulldata "# END" system-nl
TISDAG: serverhandle is:
TISDAG: serverhandle is:
- Whois++, whatever the server-handle on the record returned by
the WDSP.
- LDAP, <hostname-without-periods><port> (because server DN's are
not enforceably unique). E.g., a services.bunyip.com server on
7778 would become servicesbunyipcom7778.
- Whois++, 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.
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 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
server-to-ask = "# SERVER-TO-ASK " serverhandle system-nl
server-to-askdata
"# END" system-nl
server-to-ask = "# SERVER-TO-ASK " serverhandle system-nl server-to-askdata "# END" system-nl
fulldata = " " attributename ": " attributevalue system-nl
fulldata = " " attributename ": " attributevalue system-nl
Daigle & Hedberg Informational [Page 87] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 87] RFC 2967 TISDAG October 2000
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
server-to-ask-data = " Server-Info: " serverinfo system-nl " Host-Name: " hostname system-nl " Host-Port: " number system-nl " Protocol: " prot system-nl " Source-URI: " source system-nl " Charset: " characterset system-nl
attributename = r-string
attributename = r-string
attributevalue = longstring
attributevalue = longstring
template = <%d32-%d255 except specialbyte>
template = <%d32-%d255 except specialbyte>
serverhandle = <%d32-%d255 except specialbyte>
serverhandle = <%d32-%d255 except specialbyte>
localhandle = <%d32-%d255 except specialbyte>
localhandle = <%d32-%d255 except specialbyte>
serverinfo = string
serverinfo = string
hostname = string
hostname = string
prot = string ; currently one of "ldapv2"
; "ldapv3" "whois++"
prot = string ; currently one of "ldapv2" ; "ldapv3" "whois++"
characterset = "UTF-8" / "T.61" / "ISO8859-1" / "US-ASCII"
characterset = "UTF-8" / "T.61" / "ISO8859-1" / "US-ASCII"
source = string
source = string
longstring = string 0*( nl ( "+" / "-" ) string )
longstring = string 0*( nl ( "+" / "-" ) string )
string = 0*(%d32-255)
string = 0*(%d32-255)
r-string = 0*(<%d32-126 except specialbyte>)
; omit 127 which is DEL
r-string = 0*(<%d32-126 except specialbyte>) ; omit 127 which is DEL
specialbyte = ":" / " "
specialbyte = ":" / " "
mnl = 1*system-nl
mnl = 1*system-nl
system-nl = nl [ 1*(message nl) ]
system-nl = nl [ 1*(message nl) ]
nl = %d13 %d10 ; CR and LF
nl = %d13 %d10 ; CR and LF
message = [1*( messagestart "-" string nl)]
messagestart " " string nl
message = [1*( messagestart "-" string nl)] messagestart " " string nl
messagestart = "% " digit digit digit
messagestart = "% " digit digit digit
Daigle & Hedberg Informational [Page 88] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 88] RFC 2967 TISDAG October 2000
goodmessage = [1*( goodmessagestart "-" string nl)]
goodmessagestart " " string nl
goodmessage = [1*( goodmessagestart "-" string nl)] goodmessagestart " " string nl
goodmessagestart= "% 200"
goodmessagestart= "% 200"
badmessage = [1*( badmessagestart "-" string nl)]
badmessagestart " " string nl
badmessage = [1*( badmessagestart "-" string nl)] badmessagestart " " string nl
badmessagestart = "% 5" digit digit
badmessagestart = "% 5" digit digit
endmessage = endmessageclose / endmessagecont
endmessage = endmessageclose / endmessagecont
endmessageclose = [endmessagestart " " string nl]
byemessage
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 )
number = 1*( digit )
digit = "0" / "1" / "2" / "3" / "4" / "5" / "6" /
"7" / "8" / "9"
digit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
C.4 DAG/IP Response Messages
C.4 DAG/IP Response Messages
The following list and discussion of response codes is derived from the Whois++ protocol definition, RFC1835 ([6]).
The following list and discussion of response codes is derived from the Whois++ protocol definition, 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.
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.
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.
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.
Example 1
Example 1
% 200 Command okay
% 200 Command okay
Example 2
Example 2
Daigle & Hedberg Informational [Page 89] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 89] RFC 2967 TISDAG October 2000
% 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.
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.
The theory of reply codes is described in Appendix E in STD 10, RFC821 ([15]).
The theory of reply codes is described in Appendix E in STD 10, RFC821 ([15]).
System response code Description
System response code Description
---------------------------- ------------------------------
110 Too many hits The number of matches exceeded
the value specified by the
maxhits constraint. Server
will still reply with as many
records as "maxhits" allows.
---------------------------- ------------------------------ 110 Too many hits The number of matches exceeded the value specified by the maxhits constraint. Server will still reply with as many records as "maxhits" allows.
111 Requested constraint not One or more constraints in query
supported is not implemented, but the
search is still done.
111 Requested constraint not One or more constraints in query supported is not implemented, but the search is still done.
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 Requested constraint not One or more constraints in query fulfilled has unacceptable value and was therefore not used, but the search is still done.
200 Command Ok Command accepted and executed.
The client must wait for a
transaction end system message.
200 Command Ok Command accepted and executed. The client must wait for a transaction end system message.
201 Command Completed Command accepted and executed.
successfully
201 Command Completed Command accepted and executed. successfully
203 Bye Server is closing connection
203 Bye Server is closing connection
Daigle & Hedberg Informational [Page 90] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 90] RFC 2967 TISDAG October 2000
204 Overgeneralized The server could not exactly
match the DAG query into its
native access protocol. The
resulting native query was
"looser".
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 Service Ready Greeting message. Server is accepting commands.
226 Transaction complete End of data. All responses to
query are sent.
226 Transaction complete End of data. All responses to query are sent.
401 Service not available
401 Service not available
402 Search expression
too complicated
402 Search expression too complicated
403 Information Unavailable When a remote service is not
(currently) available.
403 Information Unavailable When a remote service is not (currently) available.
404 Time out
404 Time out
500 Syntax error
500 Syntax error
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 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).
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 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.
505 Operations error Permanent operations error
505 Operations error Permanent operations error
600 <token> Subsequent attribute values are
encoded in the character set
specified by <token>.
600 <token> Subsequent attribute values are encoded in the character set specified by <token>.
601 <token> Subsequent attribute values are
in the language specified by
<token>.
601 <token> Subsequent attribute values are in the language specified by <token>.
Daigle & Hedberg Informational [Page 91] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 91] RFC 2967 TISDAG October 2000
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 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 ANY Subsequent attribute values are
for all languages.
601 ANY Subsequent attribute values are for all languages.
Table C.1 List of system response codes
Table C.1 List of system response codes
Daigle & Hedberg Informational [Page 92] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 92] RFC 2967 TISDAG October 2000
Appendix D - DAG/IP Response Messages Mapping
Appendix D - DAG/IP Response Messages Mapping
LDAPv2/v3 DAG/IP
--------------------------------------- ---------------------
success (0) v2&v3 200 Command Ok
operationsError (1) v2&v3 505 Operations error
protocolError (2) v2&v3 505 Operations error
timeLimitExceeded (3) v2&v3 404 Timeout
sizeLimitExceeded (4) v2&v3 110 To many hits
compareFalse (5) v2&v3 200 OK
compareTrue (6) v2&v3 200 OK
authMethodNotSupported (7) v2&v3 505 Operations error
strongAuthRequired (8) v2&v3 505 Operations error
referral (10) v3 200 OK
adminLimitExceeded (11) v3 110 Too many hits
unavailableCriticalExtension (12) v3 505 Operations error
confidentialityRequired (13) v3 505 Operations error
saslBindInProgress (14) v3 N.A.
noSuchAttribute (16) v2&v3 200 OK
undefinedAttributeType (17) v2&v3 500 Syntax error
inappropriateMatching (18) v2&v3 500 Syntax error
constraintViolation (19) v2&v3 111 Requested constraint
not supported
attributeOrValueExists (20) v2&v3 200 OK
invalidAttributeSyntax (21) v2&v3 500 Syntax error
noSuchObject (32) v2&v3 200 OK
aliasProblem (33) v2&v3 505 Operations error
invalidDNSyntax (34) v2&v3 500 Syntax error
isLeaf (35) v2 N.A.
aliasDereferencingProblem (36) v2&v3 505 Operations error
inappropriateAuthentication (48) v2&v3 500 Syntax error
invalidCredentials (49) v2&v3 403 Information Unavailable
insufficientAccessRights (50) v2&v3 403 Information Unavailable
busy (51) v2&v3 403 Information Unavailable
unavailable (52) v2&v3 401 Service not available
unwillingToPerform (53) v2&v3 505 Operations error
loopDetect (54) v2&v3 505 Operations error
namingViolation (64) v2&v3 N.A.
objectClassViolation (65) v2&v3 N.A.
notAllowedOnNonLeaf (66) v2&v3 N.A.
notAllowedOnRDN (67) v2&v3 N.A.
entryAlreadyExists (68) v2&v3 N.A.
objectClassModsProhibited (69) v2&v3 N.A.
affectsMultipleDSAs (71) v3 N.A.
other (80) v2&v3 403 Information Unavailable
LDAPv2/v3 DAG/IP --------------------------------------- --------------------- success (0) v2&v3 200 Command Ok operationsError (1) v2&v3 505 Operations error protocolError (2) v2&v3 505 Operations error timeLimitExceeded (3) v2&v3 404 Timeout sizeLimitExceeded (4) v2&v3 110 To many hits compareFalse (5) v2&v3 200 OK compareTrue (6) v2&v3 200 OK authMethodNotSupported (7) v2&v3 505 Operations error strongAuthRequired (8) v2&v3 505 Operations error referral (10) v3 200 OK adminLimitExceeded (11) v3 110 Too many hits unavailableCriticalExtension (12) v3 505 Operations error confidentialityRequired (13) v3 505 Operations error saslBindInProgress (14) v3 N.A. noSuchAttribute (16) v2&v3 200 OK undefinedAttributeType (17) v2&v3 500 Syntax error inappropriateMatching (18) v2&v3 500 Syntax error constraintViolation (19) v2&v3 111 Requested constraint not supported attributeOrValueExists (20) v2&v3 200 OK invalidAttributeSyntax (21) v2&v3 500 Syntax error noSuchObject (32) v2&v3 200 OK aliasProblem (33) v2&v3 505 Operations error invalidDNSyntax (34) v2&v3 500 Syntax error isLeaf (35) v2 N.A. aliasDereferencingProblem (36) v2&v3 505 Operations error inappropriateAuthentication (48) v2&v3 500 Syntax error invalidCredentials (49) v2&v3 403 Information Unavailable insufficientAccessRights (50) v2&v3 403 Information Unavailable busy (51) v2&v3 403 Information Unavailable unavailable (52) v2&v3 401 Service not available unwillingToPerform (53) v2&v3 505 Operations error loopDetect (54) v2&v3 505 Operations error namingViolation (64) v2&v3 N.A. objectClassViolation (65) v2&v3 N.A. notAllowedOnNonLeaf (66) v2&v3 N.A. notAllowedOnRDN (67) v2&v3 N.A. entryAlreadyExists (68) v2&v3 N.A. objectClassModsProhibited (69) v2&v3 N.A. affectsMultipleDSAs (71) v3 N.A. other (80) v2&v3 403 Information Unavailable
Table D.1 LDAPv2/v3 resultcodes to DAG/IP response codes mapping
Table D.1 LDAPv2/v3 resultcodes to DAG/IP response codes mapping
Daigle & Hedberg Informational [Page 93] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 93] RFC 2967 TISDAG October 2000
DAG/IP LDAP v2/v3 --------------------------------------- -------------------------- 110 Too many hits sizeLimitExceeded (4) 111 Requested constraint not supported constraintViolation (19) 112 Requested constraint not fullfilled constraintViolation (19) 200 Command Ok Success (0) 201 Command Completed successfully N.A. 203 Bye N.A. 204 Overgeneralized N.A. 220 Service Ready N.A. 226 Transaction complete N.A. 401 Service not available unavailable (52) 402 Search expression too complicated unwillingToPerform (53) 403 Information Unavailable busy (51) 404 Time out timeLimitExceeded (3) 405 Operations error operationsError (1) 500 Syntax error protocolError (2) 502 Search expression too complicated unwillingToPerform (53) 503 Query to general unwillingToPerform (53) 505 Operations error operationsError (1) 600 <token> N.A. 601 <token> N.A. 601 DEF N.A. 601 ANY N.A.
DAG/IP LDAP v2/v3 --------------------------------------- -------------------------- 110 Too many hits sizeLimitExceeded (4) 111 Requested constraint not supported constraintViolation (19) 112 Requested constraint not fullfilled constraintViolation (19) 200 Command Ok Success (0) 201 Command Completed successfully N.A. 203 Bye N.A. 204 Overgeneralized N.A. 220 Service Ready N.A. 226 Transaction complete N.A. 401 Service not available unavailable (52) 402 Search expression too complicated unwillingToPerform (53) 403 Information Unavailable busy (51) 404 Time out timeLimitExceeded (3) 405 Operations error operationsError (1) 500 Syntax error protocolError (2) 502 Search expression too complicated unwillingToPerform (53) 503 Query to general unwillingToPerform (53) 505 Operations error operationsError (1) 600 <token> N.A. 601 <token> N.A. 601 DEF N.A. 601 ANY N.A.
Table D.2 Mapping from DAG/IP response codes to LDAPv2/v3 resultcodes
Table D.2 Mapping from DAG/IP response codes to LDAPv2/v3 resultcodes
DAG/IP Whois++
-------------------------------------- -----------------------------
110 Too Many hits 110 Too Many hits
111 Requested constraint not supported 111 Requested constraint not
supported
112 Requested constraint not fullfilled 112 Requested constraint not
fullfilled
200 Command Ok 200 Command Ok
201 Command Completed successfully 201 Command Completed
successfully
401 Service not available 401 Service not available
403 Information Unavailable 403 Information not available
404 Timeout 404 Timeout
405 Operations error 405 Operations error
500 Syntax error 500 Syntax error
502 Search expression too complicated 502 Search expression too
complicated
503 Query to general 506 Query to general
505 Operations error 505 Operations error
DAG/IP Whois++ -------------------------------------- ----------------------------- 110 Too Many hits 110 Too Many hits 111 Requested constraint not supported 111 Requested constraint not supported 112 Requested constraint not fullfilled 112 Requested constraint not fullfilled 200 Command Ok 200 Command Ok 201 Command Completed successfully 201 Command Completed successfully 401 Service not available 401 Service not available 403 Information Unavailable 403 Information not available 404 Timeout 404 Timeout 405 Operations error 405 Operations error 500 Syntax error 500 Syntax error 502 Search expression too complicated 502 Search expression too complicated 503 Query to general 506 Query to general 505 Operations error 505 Operations error
Table D.3 Mapping between DAG/IP and Whois++ response codes
Table D.3 Mapping between DAG/IP and Whois++ response codes
Daigle & Hedberg Informational [Page 94] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 94] RFC 2967 TISDAG October 2000
Appendix E - DAG CIP Usage
Appendix E - DAG CIP Usage
E.1 CIP Index Object
E.1 CIP Index Object
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:
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:
index-object = 0*(io-part SEP) io-part
io-part = header SEP schema-spec SEP index-info
header = version-spec SEP update-type SEP this-update SEP
last-update context-size
version-spec = "version:" *SPACE "x-tagged-index-1"
update-type = "updatetype:" *SPACE ( "total" |
( "incremental" [*SPACE "tagbased"|"uniqueIDbased" ])
this-update = "thisupdate:" *SPACE TIMESTAMP
last-update = [ "lastupdate:" *SPACE TIMESTAMP SEP]
context-size = [ "contextsize:" *SPACE 1*DIGIT SEP]
schema-spec = "BEGIN IO-Schema" SEP 1*(schema-line SEP)
"END IO-Schema"
schema-line = attribute-name ":" token-type
token-type = "TOKEN"
index-info = full-index | incremental-index
full-index = "BEGIN Index-Info" SEP 1*(index-block SEP)
"END Index-Info"
incremental-index = 1*(add-block | delete-block | update-block)
add-block = "BEGIN Add Block" SEP 1*(index-block SEP)
"END Add Block"
delete-block = "BEGIN Delete Block" SEP 1*(index-block SEP)
"END Delete Block"
update-block = "BEGIN Update Block" SEP
0*(old-index-block SEP)
1*(new-index-block SEP)
"END Update Block"
old-index-block = "BEGIN Old" SEP 1*(index-block SEP)
"END Old"
new-index-block = "BEGIN New" SEP 1*(index-block SEP)
"END New"
index-block = first-line 0*(SEP cont-line)
first-line = attr-name ":" *SPACE taglist "/" attr-value
cont-line = "-" taglist "/" attr-value
taglist = tag 0*("," tag) | "*"
tag = 1*DIGIT ["-" 1*DIGIT]
attr-value = 1*(UTF8)
attr-name = dag-searchattr / "objectclass"
dag-searchattr = "FN" / "LOC" / "ROLE" / "ORG"
TIMESTAMP = 1*DIGIT
NAMECHAR = DIGIT | UPPER | LOWER | "-" | ";" | "."
index-object = 0*(io-part SEP) io-part io-part = header SEP schema-spec SEP index-info header = version-spec SEP update-type SEP this-update SEP last-update context-size version-spec = "version:" *SPACE "x-tagged-index-1" update-type = "updatetype:" *SPACE ( "total" | ( "incremental" [*SPACE "tagbased"|"uniqueIDbased" ]) this-update = "thisupdate:" *SPACE TIMESTAMP last-update = [ "lastupdate:" *SPACE TIMESTAMP SEP] context-size = [ "contextsize:" *SPACE 1*DIGIT SEP] schema-spec = "BEGIN IO-Schema" SEP 1*(schema-line SEP) "END IO-Schema" schema-line = attribute-name ":" token-type token-type = "TOKEN" index-info = full-index | incremental-index full-index = "BEGIN Index-Info" SEP 1*(index-block SEP) "END Index-Info" incremental-index = 1*(add-block | delete-block | update-block) add-block = "BEGIN Add Block" SEP 1*(index-block SEP) "END Add Block" delete-block = "BEGIN Delete Block" SEP 1*(index-block SEP) "END Delete Block" update-block = "BEGIN Update Block" SEP 0*(old-index-block SEP) 1*(new-index-block SEP) "END Update Block" old-index-block = "BEGIN Old" SEP 1*(index-block SEP) "END Old" new-index-block = "BEGIN New" SEP 1*(index-block SEP) "END New" index-block = first-line 0*(SEP cont-line) first-line = attr-name ":" *SPACE taglist "/" attr-value cont-line = "-" taglist "/" attr-value taglist = tag 0*("," tag) | "*" tag = 1*DIGIT ["-" 1*DIGIT] attr-value = 1*(UTF8) attr-name = dag-searchattr / "objectclass" dag-searchattr = "FN" / "LOC" / "ROLE" / "ORG" TIMESTAMP = 1*DIGIT NAMECHAR = DIGIT | UPPER | LOWER | "-" | ";" | "."
Daigle & Hedberg Informational [Page 95] RFC 2967 TISDAG October 2000
Daigle & Hedberg Informational [Page 95] RFC 2967 TISDAG October 2000
SPACE = <ASCII space, %x20>; SEP = (CR LF) | LF CR = <ASCII CR, carriage return, %x0D>;
SPACE = <ASCII space, %x20>; SEP = (CR LF) | LF CR = <ASCII CR, carriage return, %x0D>;
LF = <ASCII LF, line feed, %x0A>;
<ASCII LF、改行、%x0A LF=>。
DIGIT = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
ケタ=「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"
上側の=「A」| 「B」| 「C」| 「D」| 「E」| 「F」| 「G」| 「H」| 「私」| 「J」| 「K」| 「L」| 「M」| 「N」| 「○」| 「P」| 「Q」| 「R」| 「S」| 「T」| 「U」| 「V」| 「W」| 「X」| 「Y」| 「Z」下側の=“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
米国ASCII金庫=%のx01-09/%のx0B-0C/%のx0E-7F。 CRを除いて、米国のASCIIです、LF、NUL UTF8=米国ASCII金庫/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.: タイプが可能にした唯一のトークン化が「トークン」です。 Tagged Index Objectメモは「完全」の使用を可能にしますが(すなわち、属性の全体の価値はただ一つのトークンとして守られます)、それには、あらゆる記録のためのユニークなトークンをもたらすという危険があります。 研究はaとしての図心サイズの成長で記録の数を機能させます。([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.
また、タグがエントリーレベルあたりのaに関するデータに適用されることになっていることに注意してください。 したがって、同じインデックスオブジェクトの2個のインデックス・ラインが同じタグを含んでいるなら、いつもそれらの2つの系列がディレクトリの同じ「記録」を差し戻すのは、事実です。 LDAP用語では、2つの系列が同じディレクトリオブジェクトを差し戻すでしょう。
Daigle & Hedberg Informational [Page 96] RFC 2967 TISDAG October 2000
[96ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
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、2DAG図式オブジェクトはタイプされます。
E.2 CIP Index Object Creation
E.2 CIPインデックスオブジェクト作成
WDSPs are expected to create index objects following the general principles outlined in the Whois++ protocol documentation (creation of centroids) and the Tagged Index Object documentation ([12]). Following the syntax described above, the index object contains token information for each attribute in the DAGSchema:
Whois++プロトコルドキュメンテーション(図心の作成)とTagged Index Objectドキュメンテーション([12])に概説された綱領に従って、WDSPsがインデックスオブジェクトを作成すると予想されます。 上で説明された構文に従って、インデックスオブジェクトはDAGSchemaに各属性のためのトークン情報を含んでいます:
- a list of all the unique tokens (strings delimited by the specified
characters) that appear in the WDSP database for the attribute
- for each token in that list, which records the token appears in
- トークンがその記録に現れるそのリストにWDSPデータベースに属性、各トークンに関して現れるすべてのユニークなトークン(指定されたキャラクタによって区切られたストリング)のリスト
So, for example,
そのように、そして、例えば
Record #1:
FN: Foo Bar
ORG: The Snack Bar
#1、を記録してください: FN: FooはORGを禁じます: スナックバー
Record #2:
FN: Bar Smith
ORG: Snack Shack
#2、を記録してください: FN: スミスORGを禁じてください: 軽食小屋
yields (conceptually) the following information for the attribute FN:
利回り、(概念的に) 属性FNのための以下の情報:
Foo (1), Bar (1,2), Smith (2)
Foo(1)、バー(1、2)、スミス(2)
and the following information for the attribute ORG:
属性ORGのための以下の情報:
The (1), Snack (1, 2), Bar (1), Shack (2)
(1)、軽食(1、2)、バー(1)は住みます。(2)
Note that the record numbers here are used simply as tags or virtual record identifiers to indicate when 2 tokens appear in the same record. The record identifiers are not used for any part of any query to the WDSP.
ここの記録的な数が2つのトークンがいつ同じ記録に現れるかを示すのに単にタグか仮想のレコード識別名として使用されることに注意してください。 レコード識別名はどんな質問のどんな部分にもWDSPに使用されません。
Daigle & Hedberg Informational [Page 97] RFC 2967 TISDAG October 2000
[97ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
There is some discussion as to whether the use of the same record tag for all attributes makes it too easy to "decompile" the index object; i.e., reconstruct a WDSPs data based on re-ordering the tokens associated with each attribute and tag number. However, we are dealing only with the search attributes here, which is a minimal subset of the quantity of data held by the WDSP. The conclusion is then that the improved efficiency given by using the same tag numbers across attributes outweighs the (remote) possibility of information reconstruction.
同じ記録的なタグのすべての属性の使用でインデックスオブジェクトが「逆コンパイル」であることが簡単になり過ぎるかどうかに関して何らかの議論があります。 すなわち、データが各属性とタグ番号に関連しているトークンを再命令するのに基礎づけたWDSPsを再建してください。 しかしながら、私たちはここで検索属性だけに対処しています。(それは、WDSPによって保持されたデータの量の最小量の部分集合です)。 結論はその時属性の向こう側に同じタグ番号を使用することによって与えられた改良された効率が情報再建の(リモート)の可能性より重いということです。
This would yield the index object:
これはインデックスオブジェクトをもたらすでしょう:
version: x-tagged-index-1 update-type: total this-update: 855938804
バージョン: xタグ付けをされたインデックス1アップデートタイプ: 総、これ、-、アップデート、: 855938804
last-update: context-size: BEGIN IO-Schema objectclass: TOKEN
アップデート: 文脈サイズ: BEGIN IO-図式objectclass: トークン
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: トークンORG: TOKEN END IO-図式BEGIN Index-インフォメーションobjectclass: */dagperson FN: 1/Foo-1、2/バー-2/スミスORG: 1/は-1、2/軽食-1/バー-2/小屋の終わりのインデックスインフォメーションです。
TISDAG: Within the project it has been decided to base consistency
between updates on consistent tags. This means that if the
update-type is "incremental" the specifier must be "tagbased".
TISDAG: プロジェクトの中では、それは、アップデートの間の一貫性を一貫したタグに基礎づけるために決められました。 これは、アップデートタイプが「増加である」なら特許説明書の作成書が"tagbasedする"でなければならないと意味します。
E.3 CIP Index Object Sharing
E.3 CIPインデックス目的語の共有
E.3.1 Registration of Servers
サーバのE.3.1登録
It is beyond the scope of this document to define how WDSP servers shall be registered with the DAG Referral Index. Such a procedure must be defined, and the following information established for each WDSP dataset (adapted from the Tagged Index Object specification, [12]):
それは、WDSPサーバがどうDAG Referral Indexに登録されるかを定義するためにこのドキュメントの範囲を超えています。 そのような手順が定義されていてそれぞれのWDSPデータセットのために確立された以下の情報であるに違いない、(Tagged Index Object仕様、[12])から適合する:
Daigle & Hedberg Informational [Page 98] RFC 2967 TISDAG October 2000
[98ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
dsi: An OID which uniquely identifies the subtree and scope of the
dataset for which the index object is created.
dsi: 唯一インデックスオブジェクトが作成されるデータセットの下位木と範囲を特定するOID。
base-uri: One or more URI's which will form the base of any referrals
created based upon the index object that is governed by this
agreement. For example, for LDAP the base-uri would specify (among
other items): the LDAP host, the base object to which this index
object refers (e.g., c=SE), and the scope of the index object
(e.g., single container).
ベース-uri: この協定で治められるインデックスオブジェクトに基づいた状態で作成されたどんな紹介のベースも形成するURIの1つ以上のもの。 例えば、LDAPとして、uriを基礎づけるのは指定するでしょう(他の項目の中で): LDAPホスト、このインデックスオブジェクトが参照されるベースオブジェクト(例えば、c=SE)、およびインデックスの範囲は反対します(例えば、単一のコンテナ)。
supplier: The hostname and listening port number of the supplier
server, as well as any alternative servers holding that same naming
contexts, in case the supplier is unavailable.
供給者: ホスト名と聴取は供給者サーバの数を移植します、文脈を命名しながらその同じことを保持するどんな代替のサーバと同様に、供給者が入手できないといけないので。
source-uri: The URI of the WDSP's preferred source of directory
service information. This might be, for instance, an HTTP-based
service.
ソース-uri: WDSPのディレクトリサービス情報の都合のよい源のURI。 例えば、これはHTTPベースのサービスであるかもしれません。
consumeraddr: This is a URI of the "mailto:" form, with the RFC 822
email address of the consumer server.
consumeraddr: これがURIである、「mailto:」 消費者サーバのRFC822Eメールアドレスで、形成してください。
updateinterval: The maximum duration in seconds between occurrences
of the supplier server generating an update. If the consumer
server has not received an update from the supplier server after
waiting this long since the previous update, it is likely that the
index information is now out of date. A typical value for a server
with frequent updates would be 604800 seconds, or every week.
updateinterval: アップデートを生成する供給者サーバの発生の間の秒の最大の持続時間。 長い間これを待った後に前のアップデート以来消費者サーバが供給者サーバからアップデートを受けていないなら、インデックス情報が現在時代遅れであることは、ありそうです。 頻繁なアップデートがあるサーバのための典型的な値は604800秒、または毎週、そうでしょう。
attributeNamespace: Every set of index servers that together wants to
support a specific usage of indices, has to agree on which
attributenames to use in the index objects. The participating
directory servers also has to agree on the mapping from local
attributenames to the attributenames used in the index. Since one
specific index server might be involved in several such sets, it
has to have some way to connect a update to the proper set of
indexes. One possible solution to this would be to use different
DSIs.
attributeNamespace: そんなに一緒にいるインデックスサーバのあらゆるセットが、インデックスリストの特定の用法をサポートしたくて、インデックスオブジェクトでどのattributenamesを使用したらよいかに同意しなければなりません。 また、参加しているディレクトリサーバは地方のattributenamesからインデックスで使用されるattributenamesまでマッピングに同意しなければなりません。 1つの特定のインデックスサーバがそのような数セットにかかわるかもしれないので、それには、適切なセットのインデックスにアップデートを関連づける何らかの方法がなければなりません。 これへの1つの可能なソリューションは異なったDSIsを使用するだろうことです。
consistencybase: How consistency of the index is maintained over
incremental updates:
complete - every change or delete concerning one object has to
contain all tokens connected to that object. This method must be
supported by any server who wants to comply with this standard
tagbased - starting at a full update every incremental update
referring back to this full updated has to maintain state-
information regarding tags, such that a object within the
original database is assigned the same tagnumber every time.
This method is optional.
consistencybase: インデックスの一貫性はアップデート増加に関してどう維持されるか: 完全--、あらゆる、あるオブジェクトがそのオブジェクトに接続されたすべてのトークンを含むように持っている関係があることを変えるか、または削除してください。 このメソッドはどんなサーバによってもサポートされて、だれがこの規格に従いたがっているかがtagbasedしました--アップデートして、あらゆるアップデート増加が完全なアップデートのときにこれをいっぱいに差し戻し始めると、タグの州の情報は保守されなければなりません、同じtagnumberが毎回オリジナルのデータベースの中のオブジェクトに割り当てられるようにことであるに違いありません。 このメソッドは任意です。
Daigle & Hedberg Informational [Page 99] RFC 2967 TISDAG October 2000
[99ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
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--Datasetのあらゆるオブジェクトには、インデックスの特定の属性のためのユニークな値がなければなりません。 そのような属性に関する例はdistinguishedName属性であるかもしれません。 また、このメソッドも任意です。
securityoption: Whether and how the supplier server should sign and
encrypt the update before sending it to the consumer server.
Options for this version of the DAG service are "none": the update
is sent in plaintext "PGP/MIME": the update is digitally signed and
encrypted using PGP (see [7]). PGP/MIME is recommended.
securityoption: そして. 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」のために、これは両方のサーバの信じられた公開鍵になるでしょう。
E.3.2 Transmission of Objects
オブジェクトのE.3.2トランスミッション
CIP Index Objects are sent to the DAG Referral Index by MIME-encoded SMTP, following the Common Indexing Protocol specification (see [2] and [3]).
CIP Index ObjectsはMIMEでコード化されたSMTPによってDAG Referral Indexに送られます、Common Indexingプロトコル仕様に従って。([2]と[3])を見てください。
Appendix F - Summary of Technical Survey Results
付録F--技術的な調査結果の概要
As part of the TISDAG project, a technical survey was carried out -- announced on the tisdag@swip.net mailing list, all Swedish WDSPs (and potential WDSPs) were encouraged to fill out and submit the WWW-based survey form (see http://tisdag.sunet.se/tisdag-survey.html).
TISDAGプロジェクトの一部として、技術的な調査が行われました-- tisdag@swip.net メーリングリストでは、すべてのスウェーデンのWDSPs(そして、潜在的WDSPs)が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月に行われました。 応答は望まれていたほど良くはありませんでした--結局、5WDSPsが参加しました。 私たちはこれより多くの応答を期待しました、ディレクトリサービスプロバイダーの現在の、そして、計画された状態の具体的な意味を持つために。 しかしながら、数人の人々との非公式の「廊下」の会話は、SollentunaのInteroperabilitet97年に人々が重要でタイムリーなステップであると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以上の記録を持っていると予想します。 どんな本当の驚きもサポートしているプロトコルか検索タイプでありませんでした。
Daigle & Hedberg Informational [Page 100] RFC 2967 TISDAG October 2000
[100ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
Table E.1 summarizes information from the survey concerning types of queries currently supported by WDSPs, and planned for the next 12 months. Note that, at the time of the survey, the requirement of searching by ROLE had not been proposed, so the survey did not specifically ask if WDSPs supported both the DAGPERSON schema protocol-equivalents (i.e., USER template in Whois++ and inetorgperson objectclass in LDAP). In the table, the column "Complete info?" describes whether or not the WDSP currently returns at least as much information as is required for a DAG reply.
テーブルE.1は現在、WDSPsによってサポートされて、次の12カ月計画された質問のタイプに関して調査から情報をまとめます。 調査が、WDSPsが、両方のDAGPERSON図式プロトコル同等物が(すなわち、LDAPのWhois++とinetorgperson objectclassのUSERテンプレート)であるとサポートしたかどうか明確に尋ねなかったように、ROLEで探す要件が調査時点で提案されていなかったことに注意してください。 テーブルでは、「完全なインフォメーション?」というコラムは、WDSPが現在少なくともDAG回答のために必要とされるのと同じくらい多くの情報を返すかどうか説明します。
Resp Search Types Complete info? Access Protocols Access Protocols
(now) (12 months)
---- ------------ -------------- ---------------- ----------------
1 NOL Except ROLE Whois++ Whois++
Resp検索Types Completeインフォメーション? アクセスプロトコルAccessプロトコル(現在)(12カ月)---- ------------ -------------- ---------------- ---------------- 1 役割のWhois++Whois++を除いたNOL
2 N,NO,NL,NOL Except ROLE LDAPv2,DAP,PH, LDAPv2,LDAPv3,DAP,
HTTP,Gopher PH,HTTP,Gopher
2 N、いいえ、PH、NL(役割のLDAPv2以外のNOL)がちょと浸して、LDAPv2(LDAPv3)がちょと浸す、HTTP、ゴーファーPH、HTTP、ゴーファー
3 N,NL,NOL Except ROLE LDAPv2,DAP,HTTP LDAPv2,LDAPv3,DAP,
HTTP
N(NL、役割のLDAPv2以外のNOL)がちょと浸す3、LDAPv2(LDAPv3)がちょと浸すHTTP、HTTP
4 N,NO,NL,NOL Except ROLE Whois++,HTTP LDAPv3,Whois++,
HTTP,E-mail
4 N(いいえNL、役割のWhois+ +、HTTP LDAPv3、Whois++、HTTP以外のNOL)はメールされます。
5 N,NO,NL,NOL Except ROLE LDAPv2,Whois LDAPv2,LDAPv3,
Whois++,HTTP Whois,Whois++,PH,
Finger,HTTP
N(いいえNL、役割のLDAPv2、Whois LDAPv2、LDAPv3、Whois+ +、HTTP Whois、Whois++、PH以外のNOL)が弄る5、HTTP
Table F.1 Summary of TISDAG Survey Results: Queries
TISDAG調査のテーブルF.1概要は結果として生じます: 質問
Resp # of Records (now) # of Records (12 months) Character Sets
----- ------------------ ------------------------ --------------
1 94 280 120 000 - 130 000 ISO-8859-1
2 88 000 100 000 ISO-8859-1
3 N/A 100 000 T.61 (Telex)
4 150 000 250 000 ISO-8859-1
UTF-8 UNICODE
5 4 300 10 000 ISO-8859-1
Records(12カ月)文字コードのRecords(現在)#のResp#----- ------------------ ------------------------ -------------- 1 94 280 120 000--130 000ISO-8859-1 2 88 000 100 000ISO-8859-1 3、なし、100 000T.61(テレックス)4 150 000 250 000ISO-8859-1 UTF-8ユニコード5 4 300 10 000ISO-8859-1
Table F.2 Summary of TISDAG Survey Results: Operational Information
TISDAG調査のテーブルF.2概要は結果として生じます: 運用情報
Daigle & Hedberg Informational [Page 101] RFC 2967 TISDAG October 2000
[101ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
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.: ↓これはこのレポートの材料が引き出されたインターネット規格文書(RFCs)とインターネット草稿の収集です。 インターネット草稿は、執筆中の作品であり、引用されることになっていません。 それらが本書では使用されるところに、インターネット草稿に含まれたテキストには参照があります。 この仕事のための役に立つ出発点さえ、すなわち、彼らが規格を含意することになっていないと予測します。
Electronic copies of the version of the Internet-Drafts documents that were used in preparing this report are available from the project web page, http://tisdag.sunet.se.
このレポートを作成する際に使用されたインターネット草稿ドキュメントのバージョンの電子コピーはプロジェクトウェブページ( http://tisdag.sunet.se )から利用可能です。
Bibliography
図書目録
[1] Allen, J. and M. Mealling, "The Architecture of the Common
Indexing Protocol", RFC 2651, August 1999.
[1] アレンとJ.とM.食事、「一般的なインデックスプロトコルのアーキテクチャ」、RFC2651、1999年8月。
[2] Allen, J. and M. Mealing, "MIME Object Definitions for the
Common Indexing Protocol (CIP)", RFC 2652, August 1999.
[2] アレンとJ.とM.食事、「一般的なインデックスプロトコル(CIP)のためのMIMEオブジェクト定義」、RFC2652、1999年8月。
[3] Allen, J. and P. Leach, "CIP Transport Protocols", RFC 2653,
August 1999.
[3] アレンとJ.とP.リーチ、「CIPトランスポート・プロトコル」、RFC2653、1999年8月。
[4] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[4] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
RFC 2234, November 1997.
[5] クロッカー、D.、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[6] Deutsch, P., Schoultz, R., Falstrom, P. and C. Weider,
"Architecture of the WHOIS++ Service", RFC 1835, July 1995.
[6] ドイツ語とP.とSchoultzとR.とFalstromとP.とC.ワイダー、「WHOIS++サービスのアーキテクチャ」、RFC1835、1995年7月。
[7] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC
2015, October 1996.
[7] エルキンズ、M.、「プリティ・グッド・プライバシ(PGP)があるMIMEセキュリティ」、RFC2015、1996年10月。
[8] Patrik Faltstrom, Martin Hamilton, Leslie L. Daigle, "WHOIS++
templates", Work in Progress.
[8] パトリクFaltstrom、マーチン・ハミルトン、レスリーL.Daigle、「WHOIS++テンプレート」、ProgressのWork。
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Interent Message Bodies",
RFC 2045, November 1996.
解放された[9]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「Interentメッセージボディーの形式」、RFC2045、1996年11月。
[10] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
解放された[10]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
Daigle & Hedberg Informational [Page 102] RFC 2967 TISDAG October 2000
[102ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
[11] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical
Specification", RFC 2849, June 2000.
[11] いいぞ、G.、「LDAPデータは形式(LDIF)を交換します--技術的な仕様」、RFC2849、6月2000日
[12] Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A Tagged
Index Object for use in the Common Indexing Protocol", RFC 2654,
August 1999.
[12] ヘドバーグとR.とグリーンブラットとB.とモウツとR.とM.ウォール、「Common Indexingプロトコルにおける使用のためのTagged Index Object」、RFC2654、1999年8月。
[13] Howes, R., "A String Representation of LDAP Search Filters", RFC
1960, June 1996.
[13] ハウズ、R.、「LDAP検索フィルタのストリング表現」、RFC1960、1996年6月。
[14] Paul Panotzki, "Complexity of the Common Indexing Protocol:
Predicting Search Times in Index Server Meshes", Master's
Thesis, KTH, September 1996.
[14] ポールPanotzki、「一般的なインデックスの複雑さは議定書を作ります」。 「インデックスサーバメッシュで検索時間を予測する」マスターの論文、KTH、1996年9月。
[15] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1982.
[15] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
[16] Smith, M., "Definition of the inetOrgPerson Object Class", RFC
2798, April 2000.
[16] スミス、M.、「inetOrgPersonオブジェクトのクラスの定義」、RFC2798、2000年4月。
[17] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[17] ウォールとM.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。
[18] Wahl, M., "A summary of the X.500(96) User Schema for use with
LDAPv3", RFC 2256, December 1997.
[18] ウォール、M.、「LDAPv3"、RFC2256、1997年12月との使用のためのX.500(96)ユーザSchemaの概要。」
[19] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, March 1995.
[19]YeongとW.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル」、RFC1777、1995年3月。
[20] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[20]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
[21] The Unicode Consortium, "The Unicode Standard -- Version 2.0",
Addison-Wesley, 1996.
[21] ユニコード共同体、「バージョン2インチ、アディソン・ウエスリー、ユニコード規格--1996。」
Daigle & Hedberg Informational [Page 103] RFC 2967 TISDAG October 2000
[103ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
Authors' Addresses
作者のアドレス
Leslie L. Daigle Thinking Cat Enterprises
猫計画を考えるレスリーL.Daigle
EMail: leslie@thinkingcat.com
メール: leslie@thinkingcat.com
Roland Hedberg Catalogix Jegerveien 25 0777 Oslo Norway
ローランドヘドバーグCatalogix Jegerveien25 0777オスロノルウェー
Phone: +47 23 08 29 96 EMail: Roland@catalogix.se
以下に電話をしてください。 +47 23 08 29 96はメールされます: Roland@catalogix.se
Daigle & Hedberg Informational [Page 104] RFC 2967 TISDAG October 2000
[104ページ]RFC2967TISDAG2000年10月の情報のDaigleとヘドバーグ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Daigle & Hedberg Informational [Page 105]
DaigleとヘドバーグInformationalです。[105ページ]
一覧
スポンサーリンク
