RFC2969 日本語訳
2969 Wide Area Directory Deployment - Experiences from TISDAG. T.Eklof, L. Daigle. October 2000. (Format: TXT=43002 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Eklof Request for Comments: 2969 L. Daigle Category: Informational October 2000
Eklofがコメントのために要求するワーキンググループT.をネットワークでつないでください: 2969年のL.Daigleカテゴリ: 情報の2000年10月
Wide Area Directory Deployment - Experiences from TISDAG
広い領域ディレクトリ展開--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 TISDAG (Technical Infrastructure for Swedish Directory Access Gateway) project provided valuable insight into the current reality of deploying a wide-scale directory service. This document catalogues some of the experiences gained in developing the necessary infrastructure for a national (i.e., multi-organizational) directory service and pilot deployment of the service in an environment with off-the-shelf directory service products. A perspective on the project's relationship to other directory deployment projects is provided, along with some proposals for future extensions of the work (larger scale deployment, other application areas).
TISDAG(スウェーデンのディレクトリAccessゲートウェイのための技術的なInfrastructure)プロジェクトは広いスケールディレクトリサービスを配布する現在の現実への貴重な見識を提供しました。 このドキュメントは環境におけるサービスの国家(すなわち、マルチ組織的な)のディレクトリサービスとパイロット展開のためにすぐ入手できるディレクトリサービス製品で必要なインフラを開発する際に行われた経験のいくつかをカタログに載せます。 他のディレクトリ展開プロジェクトとのプロジェクトの関係の見解を提供します、仕事(より大きいスケール展開、他の応用分野)の今後の拡大のためのいくつかの提案と共に。
These are our own observations, based on work done and general project discussions. No doubt, other project participants have their own list of project experiences; we don't claim this document is exhaustive!
これらは行われた仕事と一般的なプロジェクト議論に基づいた私たち自身の観測です。 間違いなく、他のプロジェクトの参加者には、それら自身のプロジェクト経験のリストがあります。 私たちは、このドキュメントが徹底的であると主張しません!
Eklof & Daigle Informational [Page 1] RFC 2969 Wide Area Directory Deployment October 2000
領域ディレクトリ展開2000年10月に広いEklof&Daigle情報[1ページ]のRFC2969
Table of Contents
目次
1.0 Introduction ................................................ 2 1.1 Overview of the TISDAG project .............................. 2 1.2 Organization of this document ............................... 3 2.0 The TISDAG project itself ................................... 3 2.1 TISDAG overview ............................................ 3 2.2 Some successes .............................................. 4 2.3 Some surprises .............................................. 5 2.3.1 LDAP objectclasses and the "o" attribute .................. 6 2.3.1 The Tagged Index Object ................................... 6 2.3.3 Handling Status Messages ................................. 7 2.3.4 Deployment with Commercial Software ...................... 7 2.4 Some observations ........................................... 7 2.4.1 Participation of the WDSPs ................................ 7 2.4.2 Index Objects and Referral Index size ..................... 8 2.4.3 Index Object and Query Performance ........................ 8 2.5 Some evolutions ............................................. 9 3.0 Related Projects ............................................ 11 3.1 The Norwegian Directory of Directories (NDD) ................ 11 3.2 DESIRE Directory Services ................................... 11 4.0 Some Directions for TISDAG Next Steps ....................... 12 4.1 Security support ............................................ 12 4.2 WDSPs attributes and schemas ............................... 12 5.0 Some conclusions ............................................ 13 6.0 Security Considerations ..................................... 13 7.0 Acknowledgements ............................................ 13 8.0 Authors' Addresses .......................................... 13 9.0 References .................................................. 14 Appendix -- Specific Software Issues and Deployment Experiences.. 15 Full Copyright Statement ........................................ 18
1.0序論… 2 TISDAGプロジェクトの1.1概要… 2 1.2 このドキュメントの組織… 3 2.0 TISDAGはそれ自体を映し出します… 3 2.1TISDAG概要… 3 2.2 いくつかの成功… 4 2.3 いくつかの驚き… 5 2.3 .1LDAP objectclassesと「o」属性… 6 2.3 .1 タグ付けをされたインデックスオブジェクト… 6 2.3 .3 取り扱いステータスメッセージ… 7 2.3 商用ソフトウェアとの.4展開… 7 2.4 いくつかの観測… 7 2.4 .1 WDSPsの参加… 7 2.4 .2 ObjectsとReferral Indexサイズに索引をつけてください… 8 2.4 .3 オブジェクトと質問パフォーマンスに索引をつけてください… 8 2.5 いくらかのevolutions… 9 3.0 プロジェクトを関係づけます… 11 3.1 ディレクトリ(NDD)のノルウェーのディレクトリ… 11 3.2 ディレクトリサービスを望んでください… 11 4.0 TISDAGのための次のいくつかの方向が踏まれます… 12 4.1 セキュリティサポート… 12 4.2WDSPs属性とschemas… 12 5.0 いくつかの結論… 13 6.0 セキュリティ問題… 13 7.0の承認… 13 8.0人の作者のアドレス… 13 9.0の参照箇所… 14 付録--特定のソフトウェア問題と展開経験。 15 完全な著作権宣言文… 18
1.0 Introduction
1.0 序論
1.1 Overview of the TISDAG project
1.1 TISDAGプロジェクトの概要
As described in more detail in [TISDAG], the original intention of
the TISDAG project was to provide the infrastructure for a national
whitepages directory service. To be effective, such an
infrastructure needed to address the concrete realities of end-users'
existing client software, as well as the needs of information
providers ("Whitepages Directory Service Providers" -- WDSPs). These
realities include the existence of multiple protocols (so-called
directory service access protocols, as well as more general Internet
application protocols such as HTTP and SMTP). The project was also
sensitive to the fact that WDSPs have many good reasons for being
reluctant to relinquish copies of their subscribers' personal data.
さらに詳細に[TISDAG]で説明されるように、TISDAGプロジェクトのオリジナルの意志は国家のwhitepagesディレクトリサービスにインフラストラクチャを提供することでした。 有効に、なるように、そのようなインフラストラクチャは、エンドユーザの存在の具体的な現実がクライアントソフトウェアと、情報提供者の必要性(「Whitepagesディレクトリサービスプロバイダー」--WDSPs)であると扱う必要がありました。 これらの現実は複数のプロトコル(いわゆるディレクトリサービスアクセス・プロトコル、およびHTTPやSMTPなどの、より一般的なインターネットアプリケーション・プロトコル)の存在を含んでいます。 また、プロジェクトもWDSPsには彼らの加入者の個人的なデータのコピーを放棄するのに気が重いことの多くのもっともな理由があるという事実に敏感でした。
Eklof & Daigle Informational [Page 2] RFC 2969 Wide Area Directory Deployment October 2000
領域ディレクトリ展開2000年10月に広いEklof&Daigle情報[2ページ]のRFC2969
1.2 Organization of this document
1.2 このドキュメントの組織
In an effort to communicate the experiences with this project, from conception through implementation and pilot deployment, this document is divided into 3 major sections. The first section reviews specific lessons learned by the authors through the TISDAG project and implementation of one conformant system. Next, some perspectives are offered on the relationship of the TISDAG work to other large-scale directory projects that are currently on-going, to give a sense of how these efforts might possibly interact. Finally, some preliminary thoughts on applying the DAG system to other applications and deployment environments are outlined. Further suggestions for deploying networked DAG servers (meshes) can be found in [DAG-Mesh]. More discussion of useful development of architectural principles is provided in a separate document ([DAG++]).
実装と概念からパイロット展開でこのプロジェクトの経験を伝える取り組みでは、このドキュメントは3つの主要なセクションに分割されます。 最初のセクションは1台のconformantシステムのTISDAGプロジェクトと実装を通して作者によって学習された特定のレッスンを見直します。 次に、TISDAG仕事の関係で他の現在これらの取り組みがことによるとどう相互作用するかもしれないかに関する感覚を与えるために継続している大規模なディレクトリプロジェクトにいくつかの見解を提供します。 最終的に、他のアプリケーションと展開環境にDAGシステムを適用することに関するいくつかの予備の考えが概説されています。 展開がDAGサーバ(メッシュ)をネットワークでつないだので、[DAG-メッシュ]でさらなる提案を見つけることができます。 別々のドキュメント([DAG++])に建築原則の役に立つ開発の、より多くの議論を提供します。
2.0 The TISDAG project itself
2.0 TISDAGプロジェクト自体
2.1 TISDAG overview
2.1 TISDAG概要
Briefly, the technical infrastructure proposed for the TISDAG project (see [TISDAG] for the complete overview and technical specification) provides end-user client software with connection points to perform basic whitepages queries. Different connection points are provided for the various protocols end-users are likely to wish to use to access the information -- WWW (http), e-mail (SMTP), Whois++, LDAPv2 and LDAPv3. For each client, a transaction will be carried out within the bounds of the protocol's syntax and semantics. However, since the TISDAG system does not maintain a replicated copy of all whitepages information, but rather an index over the data that allows redirection (referrals) to services that are likely to contain responses that match the client's query, a fair bit of background work must be done by the DAG system in order to fulfill the client's query.
簡潔に、TISDAGプロジェクト(完全な概要と技術仕様書に関して[TISDAG]を見る)のために提案された技術インフラは、基本的なwhitepages質問を実行するためにエンドユーザクライアントソフトウェアに接続拠点を提供します。 異なった接続拠点は様々なプロトコルにおいて、エンドユーザがアクセスに情報を使用することを願いそうであるかどうかということです--WWW(http)、メール(SMTP。)(Whois++、LDAPv2、およびLDAPv3) 各クライアントに関しては、トランザクションがプロトコルの構文と意味論の領域の中で行われるでしょう。 しかしながら、クライアントの質問に合っている応答を含みそうなサービスにリダイレクション(紹介)を許容するデータの上に、DAGシステムは、TISDAGシステムはすべてのwhitepages情報の模写されたコピーを維持するのではなく、むしろインデックスを維持するので、クライアントの質問を実現させるためにバックグラウンド仕事の公正なビットをしなければなりません。
The first, and most important step, is for the system to make a query against the DAG Referral Index -- a server containing index information (obtained by the Common Indexing Protocol (see [CIP1, CIP2, CIP3]) in the Tagged Index Object format (see [TIO]). This index contains sufficient information to indicate which of the many participating WDSPs should be contacted to complete the query. Wherever possible, these referrals are passed back to the querying client so that it can contact relevant WDSPs directly. This minimizes the amount of work done by the DAG system itself, and allows WDSPs greater visibility (which is an incentive for participating in the system). Protocols which support referrals natively include Whois++ and LDAPv3 -- although these may only be referred to servers of the same protocol.
1番目、およびほとんどの重要なステップはシステムがDAG Referral Indexに対して質問をすることです; サーバ含有は情報に索引をつけます。(Tagged Index ObjectでCommon Indexingプロトコルで得て(CIP1を見てください、CIP2、CIP3)、形式(TIOを見る)このインデックスは多くの参加WDSPsのどれが質問を終了するために連絡されるべきであるかを示すことができるくらいの情報を含んでいます; どこでも、可能であるところでは、これらの紹介が、直接関連WDSPsに連絡できるように、質問しているクライアントに戻されます。これは、DAGシステム自体によって行われた仕事量を最小にして、より大きい目に見えること(システムに参加するための誘因である)をWDSPsに許容します。紹介がネイティブであるとサポートするプロトコルがWhois++とLDAPv3を含んでいます; これらは同じくらいのサーバを参照されるだけであるかもしれませんが、議定書を作ってください。
Eklof & Daigle Informational [Page 3] RFC 2969 Wide Area Directory Deployment October 2000
領域ディレクトリ展開2000年10月に広いEklof&Daigle情報[3ページ]のRFC2969
Since many protocols do not support referrals (e.g., LDAPv2), and in order to address referrals to servers using a protocol other than the calling client's own, a secondary step of "query chaining" is provided to pursue these extra referrals within the DAG system itself. For example, if an LDAPv2 client connects to the system, a query is made against the Referral Index to determine which WDSPs may have answers for the query, and then resources within the DAG system are used to pursue the query at the designated WDSPs' servers. The results from these different services are packaged into a single response set for the client that made the query.
多くのプロトコルが、紹介が(例えば、LDAPv2)であるとサポートしないで、クライアントが呼ぶのを除いたプロトコルを使用することでサーバに紹介を扱うために自己であるので、DAGシステム自体の中でこれらの付加的な紹介を追求するために「質問推論」のセカンダリステップを提供します。 例えば、LDAPv2クライアントがシステムに接続するなら、Referral Indexに対してどのWDSPsに質問のための答えがあるかもしれないかを決定するのを質問をします、そして、次に、指定されたWDSPsのサーバで質問を追求するのにDAGシステムの中のリソースを使用します。 これらの異なったサービスからの結果は質問をしたクライアントのためにただ一つの応答セットにパッケージされます。
The architecture that was developed in order to support the required
functionality separated the system into distinct components to handle
incoming queries from client software ("Client Access Points", or
CAPs), a referral index (RI) to maintain an index over the collected
whitepages information and provide referrals, based on actual data
queries, to WDSPs that might have relevant information, and finally
components that mediate access to WDSP whitepages servers to perform
queries and retrieve results for the client's query ("Service Access
Points", or SAPs). Several CAPs and SAPs exist within the system --
at least one for every protocol supported for incoming queries and
WDSP servers, respectively.
必要な機能性をサポートするために開発されたアーキテクチャはクライアントソフトウェア(「クライアントアクセスポイント」、またはCAPs)から入って来る質問を扱うために異なったコンポーネントにシステムを切り離しました、集まっているwhitepages情報に関してインデックスを維持して、紹介を提供する紹介インデックス(ロードアイランド); 実際のデータ質問に基づいて、それは、WDSPsに、質問を実行するためにWDSP whitepagesサーバへのアクセスを調停する関連情報、および最終的にコンポーネントを持って、クライアントの質問(「サービスアクセスポイント」、またはSAPs)のために結果を検索するかもしれません。 数個のCAPsとSAPsはシステムの中に存在しています--少なくとも入って来る質問とWDSPサーバのためにそれぞれサポートされた各プロトコルあたり1つ。
Designed to be implementable as separate programs, these components interact with each other through the use of an internal protocol -- the DAG/IP. Pragmatically, the use of the protocol means that different components can reside on different machines, for reasons of load-balancing and performance enhancement. It also acts as a "common language" for the CAPs, SAPs and RI to express queries and receive results.
別々のプログラムとして実装可能になるように設計されていて、これらのコンポーネントは内部のプロトコルの使用で互いに対話します--DAG/IP。 実践的に、プロトコルの使用は、異なったコンポーネントが負荷分散とパフォーマンス強化の理由による異なったマシンの上にあることができることを意味します。 また、CAPs、SAPs、およびロードアイランドが質問を言い表して、結果を受けるように、それは「共通語」として機能します。
This outlines the planned or ideal behaviour of the system; once designed, a pilot phase was started for the project to compare reality against expectations. Two independent implementations of the software were created, and a test deployment was set up within the Swedish University Network (SUNET). More detail on the project and its current status can be found at http://tisdag.sunet.se/.
これはシステムの計画されたか理想的なふるまいについて概説します。 一度設計されていて、プロジェクトが期待に対して現実をたとえるように、試験段階は始められました。 ソフトウェアの2つの独立している実装が作成されました、そして、テスト展開はスウェーデンの大学Network(SUNET)の中でセットアップされました。 http://tisdag.sunet.se/ でプロジェクトに関するその他の詳細とその現在の状態を見つけることができます。
The rest of this section outlines some conclusions drawn from making a reality of the proposed architecture -- both successes and surprises.
このセクションの残りは提案されたアーキテクチャの現実のものを作るのから得られたいくつかの結論について概説します--成功と驚きの両方。
2.2 Some successes
2.2 いくつかの成功
Implementation and pilot deployment of software meeting the TISDAG technical specification did demonstrate some important successes of the approach.
TISDAG技術仕様書を満たすソフトウェアの実装とパイロット展開はアプローチのいくつかの重要な成功を示しました。
Eklof & Daigle Informational [Page 4] RFC 2969 Wide Area Directory Deployment October 2000
領域ディレクトリ展開2000年10月に広いEklof&Daigle情報[4ページ]のRFC2969
Most notably, the system works pretty much as expected (see exceptions below) to provide transparent middleware for whitepages directory services. That is, client software and WDSP servers were minimally affected -- from the point of view of behaviour and configuration, the DAG system looked like a server to clients, and a client to servers.
ほとんどwhitepagesディレクトリサービスのための見え透いたミドルウェアを提供すると予想されるように(以下の例外を見ます)最も著しく、システムは動作します。 すなわち、クライアントソフトウェアとWDSPサーバは最少量で影響を受けました--ふるまいと構成の観点から、DAGシステムはクライアントへのサーバ、およびサーバへのクライアントに似ていました。
The goal of the TISDAG project, operationally, was to be able to provide responses to end-user queries in reasonable response times (although not "an addressbook replacement"). The prototype systems demonstrated some success in achieving responses within 10 seconds, at least with the limited testbed of a configuration with 10 WDSP's providing directory service information. More observations on system performance are provided below.
TISDAGプロジェクトの目標はエンドユーザ質問への応答を妥当な応答時間に操作上提供する(「addressbook交換」ではありませんが)ことであることができました。 プロトタイプ装置は何らかの成功を10秒以内に応答を達成するのを示しました、少なくとも10WDSPのものがディレクトリサービス情報を提供している構成の限られたテストベッドで。 システム性能におけるより多くの観測を以下に提供します。
The DAG system does demonstrate that it is possible to build referral-level services at a national level (although the deployment has yet to prove conclusively that it can, in its current formulation, operate as a transparent query-fulfillment proxy service).
DAGシステムは、全国レベルで紹介レベルサービスを組み込むのが可能であることを示します(展開は、それがわかりやすい質問遂行代理業務として現在の定式化で作動できるとまだ最終的に立証していませんが)。
The success of the implementation demonstrated that it is possible, in some sense, to do (semantic) protocol mapping with N+M complexity instead of NxM mappings. That is, protocol translations had to be defined for "N" allowable end-user query access protocols to/from the DAG/IP, and "M" supported WDSP server protocols, instead of requiring each of the N input components to individually map to the M output protocols.
実装の成功は、それがN+Mの複雑さがNxMマッピングの代わりにある状態で(意味)のプロトコルマッピングをするために何らかの意味で可能であることを示しました。 すなわち、プロトコル変換は「N」許容できるエンドユーザ質問アクセス・プロトコルのために縁飾り/IP、およびWDSPサーバプロトコルであるとサポートされた「M」からの/と定義されなければなりませんでした、個別に出力プロトコルをMに写像するためにそれぞれのN入力コンポーネントを必要とすることの代わりに。
As a correlated issue, the prototype system demonstrated some successes with mapping between schema representations in the different protocol paradigms -- in a large part because system's schemas were kept simple and focused on the minimal needs to support the base service requirements.
関連問題として、異なったプロトコルパラダイムにおける図式表現の間には、マッピングがある状態で、プロトタイプ装置はいくつかの成功を示しました--システムのschemasが簡単に保たれて、ベースをサポートする最小量の必要性に焦点を合わせたので、かなりの部分では、要件を修理してください。
2.3 Some surprises
2.3 いくつかの驚き
Over the span of a dozen months from the first "final" document of the specification through the implementation and first deployment of the software system, a few surprises did surface. These fell into two categories: those that surfaced when the theoretical specification was put into practice, and others that became apparent when the resulting system was put into operation with commercial software clients and servers.
仕様の最初の「最終的な」ドキュメントから実装の12カ月の期間と最初に、ソフトウェア・システムの展開に関して、いくつかの驚きが表面化しました。 これらは2つのカテゴリになりました: 理論上の仕様が実行に移されたとき浮上したもの、および商用ソフトウェアクライアントとサーバと共に結果として起こるシステムを操作に入れたとき明らかになった他のもの。
More detail is provided in the Appendix concerning specific software issues encountered, but some of the larger issues that surfaced during the implementation phase are describe below.
問題が遭遇した特定のソフトウェアに関してその他の詳細をAppendixに提供しますが、より大きい問題のいくつかが下について説明します。
Eklof & Daigle Informational [Page 5] RFC 2969 Wide Area Directory Deployment October 2000
領域ディレクトリ展開2000年10月に広いEklof&Daigle情報[5ページ]のRFC2969
2.3.1 LDAP objectclasses and the "o" attribute
2.3.1 LDAP objectclassesと「o」属性
It came as a considerable surprise, some months into the project,
that none of the "standard" LDAP person objectclasses included
organization ("o") as an attribute. The basic assumption seems to be
that "o" will be part of the distinguished name for an entry, and
therefore there is little (if any) cause to list it out separately.
This does make it trickier to store information for people across
multiple organizations (e.g., at an ISP's directory server) and use
the organization name in query refinement. (Roland Hedberg caught
this issue, and has flagged it to the authors of the "inetorgperson"
objectclass document).
かなりの驚き、プロジェクトへの数カ月として、「標準」のLDAP人のobjectclassesのいずれも属性として組織(「o」)を含んでいなかったのは来ました。 基本仮定は「o」がエントリーへの分類名の一部になるということであるように思えます、そして、したがって、別々に外にそれを記載する原因がほとんど(もしあれば)ありません。 これは、複数の組織(例えば、ISPのディレクトリサーバにおける)の向こう側に人々のために情報を保存するのをより扱いにくくして、質問気品に組織名を使用します。 (ローランド・ヘドバーグは、この問題を捕らえて、"inetorgperson"objectclassドキュメントの作者にそれに旗を揚げさせました。)
2.3.1 The Tagged Index Object
2.3.1 タグ付けをされたインデックスオブジェクト
The Tagged Index Object ("TIO"), used to carry indexes of WDSP
information to the RI, is designed to have record (entry) tags to
reduce the number of false positive referrals generated when doing a
search in the RI. One of the features of the first index object
type, Whois++'s centroid (see [centroid]) was the fact that the index
object size did not grow linearly with the size of data indexed --
i.e., at some point the growth of the index object slowed as compared
to that of the underlying data set. At first glance, this also seems
to be the case for the TIO. However, as the index grows in size the
compression factor of the TIO may not achieve the same efficiency as
the centroids. One reason for this is that the tagged lists can get
quite long, depending on the ordering of the assignment of tags to
the underlying data. That is, the tagging as defined allows for a
compressed expression of tag "ranges" -- e.g., "1-500" instead of
"1,2,3,[...]500". Thus, it might be interesting to explore an
optimal "sorting" of underlying data, before applying tags, in order
to arrange the most common tokens have consecutive tags (maximal
compression of the tag lists). It's not clear if this can be done
efficiently over the entire set of records, attributes, and tokens,
but it would bear some investigation, to produce the most compressed
TIO for transmission.
WDSP情報のインデックスをロードアイランドまで運ぶのに使用されるTagged Index Object("TIO")は、ロードアイランドを検索するとき生成された無病誤診紹介の数を減少させるために記録的な(エントリー)タグを持つように設計されています。 最初のインデックスオブジェクト・タイプの特徴の1つ、Whois++の図心([図心]を見る)はインデックスオブジェクトサイズがすなわち、索引をつけられるデータのサイズ、基本的なデータセットのものと比べて、インデックスオブジェクトの成長が遅くした何らかのポイントで直線的にならなかったという事実でした。 また、一見したところでは、これはTIOのためのケースであるように思えます。 しかしながら、インデックスがサイズに生えているのに従って、TIOの圧縮要素は図心と同じ効率を実現しないかもしれません。 この1つの理由はタグ付けをされたリストがかなり長くなることができるということです、基本的なデータへのタグの課題の注文であることによって。 の代わりにする、すなわち、定義されるとしてのタグ付けはタグ「範囲」の圧縮された式を考慮します--例えば、「1-500」、「1 2 3 […] 500インチ。 したがって、基本的なデータの最適の「ソーティング」を探検するのはおもしろいかもしれません、タグを適用する前に手配するために、最も一般的なトークンには連続したタグ(タグリストの最大限度の要約)があります。 効率的に全体のセットの記録、属性、およびトークンの上にこれができるかどうかは明確ではありませんが、それは、トランスミッションのために最も圧縮されたTIOを生産するために何らかの調査に堪えるでしょう。
Additionally, in order to make (time) efficient use of the tags in the RI in practice, it is almost necessary to "reinflate" the index object to be able to do joins on tag lists associated with tokens that match. Alternatively, the compressed tag list can be stored, and there is an additional cost associated with comparing the tag lists for matching tokens -- i.e., list comparison operations done outside the scope of a base database management system. There was an unexpected tradeoff to be made.
さらに、できるインデックスオブジェクトが合っているトークンに関連しているタグリストを合するのが、実際にはロードアイランドでのタグの(時間)効率的な使用をするのに"reinflate"にほとんど必要です。 あるいはまた、圧縮されたタグリストはそこに保存されているのは、合っているトークンのためのタグリストを比較すると関連している別途費用です--すなわち、ベースデータベース管理システムの範囲の外で行われたリスト比較操作ということであるかもしれません。 作られている予期していなかった見返りがありました。
Eklof & Daigle Informational [Page 6] RFC 2969 Wide Area Directory Deployment October 2000
領域ディレクトリ展開2000年10月に広いEklof&Daigle情報[6ページ]のRFC2969
2.3.3 Handling Status Messages
2.3.3 取り扱いステータスメッセージ
Mapping of status messages from multiple sub-transactions into a single status communication for the end-user client software became something of a challenge. When chaining a query to multiple WDSPs (though the SAPs), it is not uncommon for at least one of the WDSP servers to return an error code or be unavailable. If one WDSP cannot be reached, out of several referrals, should the client software be given the impression that the query was completed successfully, or not? Most client protocol error handling models are not sophisticated enough to make this level of distinction clear.
エンドユーザクライアントソフトウェアのためのただ一つの状態コミュニケーションへの複数のサブトランザクションからのステータスメッセージに関するマッピングはある種の挑戦になりました。 複数のWDSPs(もっとも、SAPs)に質問を束縛するとき、少なくともWDSPサーバの1つがエラーコードを返すか、または入手できないのが、珍しくはありません。 1WDSPにいくつかの紹介から達することができないなら、質問が首尾よく終了したという印象をクライアントソフトウェアに与えるべきですか? ほとんどのクライアントプロトコルエラー処理モデルはこのレベルの区別を明らかにするくらいには精巧ではありません。
2.3.4 Deployment with Commercial Software
2.3.4 商用ソフトウェアとの展開
When it then was time to test the resulting software with standard commercial client and server software, a few more surprises came to light (primarily in terms of these softwares' expected worldview and occasional implementation shortcuts). Again, more detail is provided in the Appendix, but highlights included client software that could only handle a very small subset of a protocol's defined status message lexicon (e.g., 2 system messages supported), and client software that automatically appended additional terms to a query specified by the user (e.g., adding "or email=<what the user typed in to the query>").
次に、標準の広告の顧客とサーバソフトウェアで結果として起こるソフトウェアを検査するために、驚きがもうもう少し明るみに出るべき(主としてこれらのsoftwaresの予想された世界観と時々の実装近道に関して)時間であったとき。 一方、その他の詳細は、Appendixに供給しますが、プロトコルの定義されたステータスメッセージレキシコン(例えばサポートされた2つのシステムメッセージ)の非常に小さい部分集合を処理できただけである含まれているクライアントソフトウェアを目立たせます、そして、ユーザ(例えば、「または、ユーザが質問>にタイプしたものを=<にメールしてください」と言い足す)で自動的に追加用語を質問に追加したクライアントソフトウェアが指定しました。
2.4 Some observations
2.4 いくつかの観測
2.4.1 Participation of the WDSPs
2.4.1 WDSPsの参加
One of the things that came to light was that the nature of the index object generated by the WDSPs has an important impact on performance -- both in terms of integrating the index object into the Referral Index, and in terms of efficiency of handling queries. A proposal might be either to define more clearly how the WDSPs should generate the CIP index object (currently left to their discretion), or to alert individual WDSPs when their index objects are considered substandard.
明るみに出たものの1つは性能、インデックスオブジェクトをReferral Indexと統合する、および取り扱い質問の効率に関してWDSPsによって生成されたインデックスオブジェクトの自然には重要な影響力があるということでした。 提案は、より明確にWDSPsがどう、CIPインデックスオブジェクト(現在、彼らの思慮深さにいなくなる)を生成するはずであるかを定義するためにはどちらかであるかもしれませんか彼らのインデックスが反対するとき、個々のWDSPsを警告するのが標準以下で考えられます。
On another front, when chaining referrals to WDSP servers, some servers perform more efficiently than others, affecting the overall response time of the DAG system. From a service point of view, it should also be possible to suggest to WDSP's that are consistently slow (longer than some selected response time) that they are substandard.
WDSPサーバに紹介を束縛するとき、別の面では、いくつかのサーバが他のものより効率的に働きます、DAGシステムの総合的な応答時間に影響して。 また、視点のサービスポイントから、それらが標準以下であると一貫して遅い(或るものが応答時間を選択したより長い)WDSPのものに示唆するのも可能であるべきです。
Eklof & Daigle Informational [Page 7] RFC 2969 Wide Area Directory Deployment October 2000
領域ディレクトリ展開2000年10月に広いEklof&Daigle情報[7ページ]のRFC2969
2.4.2 Index Objects and Referral Index size
2.4.2 インデックスObjectsとReferral Indexサイズ
As described in more detail [complex], there are many factors that can influence the growth factor of index objects (as more data is indexed). That work dealt specifically with tokenized data for Whois++ centroids, and is not immediately generalizable to all forms of the Tagged Index Object. However, the particular structure of the TIO used for the TISDAG project is similar enough in structure to a centroid that the same "order of magnitude" and growth characteristics are applicable.
さらに詳細に[複雑な]説明されるように、インデックスオブジェクトに関する増殖因子に影響を及ぼすことができる多くの要素があります(より多くのデータが索引をつけられるとき)。 その仕事は、Whois++図心に特にtokenizedデータに対処して、すぐに、Tagged Index Objectのすべてのフォームに一般化可能ではありません。 しかしながら、TISDAGプロジェクトに使用されるTIOの特定の構造は構造において図心と同じ「桁」と成長の特性が適切であるほど同様です。
Factors that affects the size of the data ("number of entries"):
データ(「エントリーの数」)のサイズに影響する要素:
. Number of generated tokens
The number of tokens generated from the directory data depends
on what is tokenized. If data is tokenized on names and
addresses (i.e. not unique data like phone numbers) a rough
estimation is that the number_of_tokens = 0.2 *
number_of_data_records. The growth is linear in the span from
a few thousand to at least 1.2 million records. The growth
should then level off since the sets of names and addresses
are finite, but the current tests have not shown a break
point.
. トークンの数がディレクトリデータから生成した発生しているトークンの数はtokenizedされることに依存します。 データが名前とアドレス(すなわち、電話番号のようなユニークなデータでない)でtokenizedされるなら、概算は_トークンの数の_が_データ_記録の0.2*数の_と等しいということです。 成長は長さで数1,000〜少なくとも120万の記録まで直線的です。 次に、名前とアドレスのセットが有限であるので、成長は平らになるべきですが、現在のテストはブレークポイントを示していません。
If data is tokenized on something that is unique, e.g. phone
numbers, then a rough estimation is that the number_of_tokens
= number_of_data_records. Note that it is possible to tokenize
in different ways, for example divide the phone numbers in
parts. This would result in fewer tokens.
データが例えば、何かユニークなもの電話番号でtokenizedされるなら、概算は_トークンの数の_が_データ_記録の数の_と等しいということです。 異なった方法でtokenizeするのが可能であることに注意してください、そして、例えば、部品で電話番号を分割してください。 これは、より少ないトークンをもたらすでしょう。
. Number of directories
Since the tokens are generated individually for each
directory, the data size depends on the number of directories.
10 directories with 100.000 records will generate the same
amount of tokens as one directory with 1.000.000 records.
. トークンが各ディレクトリのために個別に生成されるディレクトリSinceの数、データサイズはディレクトリの数に依存します。 100.000の記録がある10のディレクトリが1.000の.000記録で1つのディレクトリと同じ量のトークンを生成するでしょう。
2.4.3 Index Object and Query Performance
2.4.3 インデックスオブジェクトと質問パフォーマンス
Factors that affects the performance ("queries/second"):
性能(「質問/秒」)に影響する要素:
. Type of query (exact, substring, etc.)
A 'substring' query is slower than an 'exact' query due to:
1) somewhat slower look-up in the internal DAG database than
an exact query.
2) Mostly, a larger amount of data is fetched from the
internal DAG database due to more hits, which generates
more index processing.
. 質問のタイプ、(正確である、サブストリングなど) 'サブストリング'質問は以下のために'正確な'質問より遅いです。 1) 内部のDAGデータベースのいくらか遅いルックアップ、正確な質問より。 2) ほとんど、多く以上のデータ量は、より多くのヒットによる内部のDAGデータベースからとって来られます。(それは、より多くのインデックスが処理であると生成します)。
Eklof & Daigle Informational [Page 8] RFC 2969 Wide Area Directory Deployment October 2000
領域ディレクトリ展開2000年10月に広いEklof&Daigle情報[8ページ]のRFC2969
3) Substring queries are sent to the directory servers which
also results in more hits and more data fetched. The
directory servers may also be more or less effective in
handling substring queries.
3) また、どれが、より多くのヒットをもたらすか、そして、より多くのデータがとって来たディレクトリサーバにサブストリング質問を送ります。 また、ディレクトリサーバも取り扱いサブストリング質問で多少有効であるかもしれません。
. Number of search attributes
A query with one or few attributes will most of the time
result in many hits, which results in a lot of data, both
internally in DAG and from the directory servers. On the other
hand, a query with many attributes will result in a somewhat
slower look-up in the internal DAG database.
. 属性Aが1で質問する検索の数かわずかな属性しかDAGとディレクトリサーバから多くのヒットにおける結果に両方をたいてい内部的に望んでいません。(それは、多くのデータをもたらします)。 他方では、多くの属性がある質問は内部のDAGデータベースのいくらか遅いルックアップをもたらすでしょう。
. Number of directories
A larger number of directories may result in many referrals,
but it depends on the query. A simple query will generate a
lot of referrals, which means a lot of data from the
directories has to be fetched. It will also result in a
somewhat slower look-up in the internal DAG database.
. より多くのディレクトリがそうするディレクトリAの数は多くの紹介をもたらしますが、それは質問によります。 簡単な質問は多くの紹介を生成するでしょう。(紹介は、ディレクトリからの多くのデータがとって来られなければならないことを意味します)。 また、それは内部のDAGデータベースのいくらか遅いルックアップをもたらすでしょう。
. Number of chained referrals
Queries that are not chained are faster, since the result data
does not have to be sent through the DAG system. Chained
queries to several directories can be processed in parallel in
the SAPs, but all data has to be processed in the CAP before
sent to the client.
. チェーニングされないチェーニングされた紹介Queriesの数は、より速いです、DAGシステムを通して結果データを送る必要はないので。 SAPsでいくつかのディレクトリへのチェーニングされた質問を平行に処理できますが、クライアントに送る前にCAPですべてのデータを処理しなければなりません。
. Response time in the directory servers
The response time from the directory servers are of course
critical. The total response time for DAG is never faster than
the slowest involved directory server.
. ディレクトリサーバでは、ディレクトリサーバからの応答時間がもちろん重要である応答時間。 DAGのための総応答時間は最も遅いかかわったディレクトリサーバより決して速くはありません。
. Number of tokens (size of Tagged Index Objects)
The number of tokens has little impact on the look-up time in
the internal DAG database.
. トークンの数が持っているトークン(Tagged Index Objectsのサイズ)の数にルックアップ時に内部のDAGデータベースで少ししか影響を与えません。
2.5 Some evolutions
2.5 いくらかのevolutions
To date, the TISDAG project has been "alive" for just over two years. During that time, there have been a number of evolutions -- in terms of technologies and ideas outside the project (e.g., user and service provider expectations, deployment of related software, etc) as well as goals and understanding within the scope of the project.
これまで、TISDAGプロジェクトはちょうど2年間以上「生きています」。 その時の間、プロジェクトの範囲の中に目標と理解と同様にプロジェクト(例えば、ユーザとサービスプロバイダー期待、関連するソフトウェアの展開など)の外で多くのevolutionsが技術と考えであります。
Chief among these last is the fact that the project set out to primarily fulfill the role of a national referral service, and gradually evolved towards becoming more of a transparent protocol proxy service, fulfilling client queries as completely as possible, within the client protocol's semantics. This evolution was probably
これらの最終の中のチーフは国家の紹介サービスの役割を主として徐々に実現させようとしているプロジェクトセットが一層のわかりやすいプロトコル代理業務になることに向かって発展したという事実です、クライアント質問をできるだけ完全に実現させて、クライアントプロトコルの意味論の中で。 この発展はたぶんそうでした。
Eklof & Daigle Informational [Page 9] RFC 2969 Wide Area Directory Deployment October 2000
領域ディレクトリ展開2000年10月に広いEklof&Daigle情報[9ページ]のRFC2969
provoked by a number of reasons -- existing client & server software has a narrower range of accepted (expected) behaviour than their protocol specs may describe, once the technology was there for some proxying, going all the way seemed to be within reach, etc.
数によって引き起こされて、クライアントとサーバソフトウェアが持っている理由--存在では、それらのプロトコル仕様より狭い範囲の受け入れられた(予想される)ふるまいは説明するかもしれません、技術がいくつかのproxyingのためにそこにいったんありました、とはるばる行くのが範囲などの中にあるように思えました。
>From the point of view of providing a national whitepages service, this is a very positive evolution. However, it did place some strains on the original system architecture, for which some adjustments have been proposed (more detail below). What is less clear is the impact this evolution will have on the flexibility of the system architecture -- in terms of addressing other applications, different protocols (and protocol paradigms), etc. That is, the original intention of the system was to very simply fulfill an unsophisticated role -- "find things that sort of match the input query and let the client itself determine if the match is close enough". As the requirements become more sophisticated, the simplicity of the system is impacted, and perhaps more brittle. (Some proposals for avoiding this are outlined in [DAG++], which attempts to return to the underlying principles and propose steps forward at that level).
同胞を提供する観点からの>はサービスをwhitepagesして、これは非常に積極的な発展です。 しかしながら、それはオリジナルのシステム構築(以下のその他の詳細)にいくつかの緊張を置きました。いくつかの調整がシステム構築において提案されました。 それほど明確でないことはこの発展がシステム構築の柔軟性に他のアプリケーション、異なったプロトコル(パラダイムについて議定書の中で述べる)などを扱うことに関して持っている影響力です。 すなわち、システムのオリジナルの意志は世慣れていない役割を非常に単に実現させることでした--「入力質問にちょっと合っていて、クライアント自身がマッチが近くにあるかどうかと決心できるものが十分であると確かめてください。」 要件が、より洗練されるようになるのに従って、システムの簡単さは、影響を与えて、恐らくよりもろいです。 (これを避けるためのいくつかの提案が[DAG++]に概説されています。)(]は、基本的な原則に戻って、そのレベルで前方にステップを提案するのを試みます)。
In terms of impact within the TISDAG project, this evolution lead to the following technical adjustments:
TISDAGプロジェクトの中の影響、以下の技術的な調整へのこの発展リードに関して:
. The latest version of the technical specification makes a
distinction (in the internal protocol grammar) between queries
directed at the Referral Index, and those passed to SAPs to
fulfill a query. This distinction keeps the query-routing
queries simple, but allows more sophistication in expressing a
query designed to fulfill the client's original semantic
expression.
. 技術仕様書の最新版はReferral Indexが向けられた質問の間で区別(内部のプロトコル文法の)をして、それらは、質問を実現させるためにSAPsに通りました。 この区別は、質問ルーティング質問を簡単に保ちますが、クライアントのオリジナルの意味式を実現させるように設計された質問を言い表す際に、より多くの洗練を許容します。
. The additional constraints in the SAP query language is still
not enough to allow the internal protocol to express very
sophisticated queries. Originally intended only for query-
routing queries, the DAG/IP expects all queries to be token-
based (whereas LDAP queries are phrase-oriented). This means
that SAPs have to do a good deal of "post-pruning" of WDSP
result sets to match the DAG/IP query sent by a CAP for query
fulfillment. And, CAPs must in turn do more post-pruning to
match the DAG/IP results (from the SAPs) to the original query
semantics.
. SAP照会言語における追加規制は、内部のプロトコルが非常に洗練された質問を言い表すのを許容するためにまだ十分ではありません。 元々質問ルーティング質問のためだけに意図していて、DAG/IPは、すべての質問が基づくトークンであると予想します(LDAP質問は句指向です)。 これは、SAPsが質問遂行のためにCAPによって送られたDAG/IP質問に合うようにWDSP結果セットの多くの「ポスト刈り込み」をしなければならないことを意味します。 そして、CAPsは、DAG/IP結果(SAPsからの)をオリジナルの質問意味論に合わせるために順番により多くのポスト刈り込みをしなければなりません。
The real strength of the TISDAG project was that it separated the technical framework needed to support the service from the configuration required in order to support a particular application or service -- query & schema mapping, configuration for protocols,
TISDAGプロジェクトの底力は特定用途かサービスをサポートするのに必要である構成からサービスをサポートするのに必要である技術的なフレームワークを切り離したということでした--、質問図式マッピング、プロトコルのための構成
Eklof & Daigle Informational [Page 10] RFC 2969 Wide Area Directory Deployment October 2000
領域ディレクトリ展開2000年10月に広いEklof&Daigle情報[10ページ]のRFC2969
etc. Future improvements should focus on evolving that framework, maintaining the separation from the specific applications, services, and protocols that may use it.
など 今後の改良は、そのフレームワークを発展するのは焦点を合わせるべきです、それを使用するかもしれない特定のアプリケーション、サービス、およびプロトコルから分離を維持して。
3.0 Related Projects
3.0 関連プロジェクト
The TISDAG project is not alone in attempting to solve the problems of providing coordinated access to resources managed by multiple, disparate services.
複数の、そして、異種のサービスで管理されたリソースへの連携アクセスを提供するという問題を解決するのを試みるのにおいてTISDAGプロジェクトは単独ではありません。
3.1 The Norwegian Directory of Directories (NDD)
3.1 ディレクトリのノルウェーのディレクトリ(NDD)
Described in [NDD], the Norwegian Directory of Directories project also aims to provide necessary infrastructure for a national directory service. It assumes LDAP (v2 or v3) accessibility of WDSP information (provided by the WDSP itself, or through other arrangements), and aims to resolve some of the trickier issues associated with hooking together already-operational LDAP servers into a coherent network: uniform distinguished naming scheme, and content-based referrals. It also addresses some of the pragmatic realities of being compatible with different versions of LDAP clients -- e.g., v2, which does not support referrals, and v3, which does.
[NDD]で説明されていて、また、ディレクトリプロジェクトのノルウェーのディレクトリは、国家のディレクトリサービスに必要なインフラを提供することを目指します。 それは、より油断のならない問題のいくつかが既に一緒にいるフッキングでの操作上のLDAPサーバをコヒーレントネットワークに関連づけたと決議するためにWDSP情報(WDSP自身か、他のアレンジメントを通して提供する)、および目的のLDAP(v2かv3)のアクセシビリティを仮定します: ユニフォームは、体系、および内容ベースの紹介を命名しながら、区別されました。 (そのv3はそうします)。(v2は紹介をサポートしません)。また、それはLDAPクライアントの異なった見解と互換性があることの実践的な現実のいくつかを扱います--例えば、v2とv3。
At the heart of the system is the "Referral Index and Organizational information" (RIO) server, which provides a searchable catalogue over Norwegian organization. This facilitates the location of whitepages servers for individual organizations (assuming the query includes information about which organization(s) is(are) interesting).
「紹介IndexとOrganizational情報」(RIO)サーバ(ノルウェーの組織の上に探せるカタログを提供する)はシステムの中心です。 これは個々の組織のためのwhitepagesサーバの位置を容易にします(質問を仮定すると、情報は(s)がどの組織(ある)であるかに関しておもしろい状態で包含します)。
This work can be seen as being complementary to the TISDAG work, in that it provides a more focused service for integrating LDAP directory servers. However, there is still some requirement that one knows the organization to which a person belongs before doing a search for their e-mail address. This may be reasonable for seeking mail addresses associated with a person's work organization, but is less often successful when it comes to finding a personal e-mail address -- in an age where ISPs abound, a priori knowledge of a user's ISP identification is unlikely.
この仕事をTISDAG仕事を補足しているとみなすことができます、LDAPディレクトリサーバを統合するための、より集中しているサービスを提供するので。 しかしながら、まだ、人がそれらのEメールアドレスを検索する前に人が属する組織を知っているという何らかの要件があります。 人の仕事組織に関連している郵便の宛先を求めるのに、これは妥当であるかもしれませんが、ISPが富むところに時代に個人的なEメールアドレスを見つけるのに至って、ユーザのISP識別に関する先験的な知識がありそうもない以下はしばしばうまくいっていますか?
3.2 DESIRE Directory Services
3.2 願望ディレクトリサービス
The EC funded project DESIRE II (http://www.desire.org) is developing a distributed European indexing system for information on Research and Education. The Directory Services work undertaken by DANTE and SURFnet proposes an architecture applied to a server mesh structure to create a wide-area directory service infrastructure.
ECの資金を供給されたプロジェクトDESIRE II( http://www.desire.org )はResearchとEducationの情報の分配されたヨーロッパのインデキシング方式を開発しています。 ダンテとSURFnetによって引き受けられたディレクトリサービス仕事は、広い領域ディレクトリサービスインフラストラクチャを作成するためにサーバメッシュ構造に適用されたアーキテクチャを提案します。
Eklof & Daigle Informational [Page 11] RFC 2969 Wide Area Directory Deployment October 2000
領域ディレクトリ展開2000年10月に広いEklof&Daigle情報[11ページ]のRFC2969
This service is intended to support both whitepages information with LDAP servers at WDSPs, as well as a Web-search meshes at various places using Whois++ for information about resources and routing of queries to other index-based services.
LDAPサーバがWDSPsにある状態でこのサービスが、両方のwhitepagesが情報であるとサポートすることを意図して、ウェブ検索がかみ合うのに従って、様々では、また、+ 他のインデックスベースのサービスへの質問のリソースとルーティングの情報のための+は、Whoisを使用することで入賞しています。
Like the TISDAG project, the DESIRE directory services project aims to act as a focal point for queries, allowing client software to access appropriate resources from a wide range of disparate services.
TISDAGプロジェクトのように、DESIREディレクトリサービスは、目的が質問のための焦点として機能すると予測します、クライアントソフトウェアがさまざまな異種のサービスから適切なリソースにアクセスするのを許容して。
There are architectural differences between the approach used in the TISDAG project and the DESIRE directory service project, but many of the driving needs are the same, and the approach of using content- based indexing and referrals was also selected.
運転する必要性の多くが同じです、そして、TISDAGプロジェクトに使用されるアプローチとDESIREディレクトリサービスプロジェクトの間には、建築違いがありましたが、また、満足しているベースのインデックスと紹介を使用するアプローチは選択されました。
4.0 Some Directions for TISDAG Next Steps
4.0 TISDAGのための次のいくつかの方向が踏まれます。
The fun thing with technology is that there are always more tweaks and changes that can be made. However, a service should evolve in response to specific customer needs, and there are several ways in which the TISDAG service itself could advance. Some of them are outlined below, in terms of possibilities perceived at this time, rather than specific recommendations for underlying technology changes that would be necessary to fulfill them. A related topic, networking DAG servers (meshes), is discussed in [DAG-Mesh].
技術があるおもしろいものは行うことができるより多くのひねりと変更がいつもあるということです。 しかしながら、サービスは特定の顧客の要望に対応して発展するべきです、そして、TISDAGサービス自体が進むことができたいくつかの方法があります。 それらのいくつかが以下に概説されています、このとき、それらを実現させるのに必要な基本的な技術変化のための特定の推薦よりむしろ知覚された可能性に関して。 [DAG-メッシュ]で関連した話題(ネットワークDAGサーバ(メッシュ))について議論します。
4.1 Security support
4.1 セキュリティサポート
There is a need for security considerations when making use of a wide-scaled directory system in other application areas than the public white-pages application of the TISDAG project. There are issues whether the directory service is distributed across the Internet, or even if it functions completely within an internal, closed network.
TISDAGプロジェクトの公共のホワイトページアプリケーション以外の応用分野で広くスケーリングされたディレクトリシステムを利用するとき、セキュリティ問題の必要があります。 ディレクトリサービスがインターネットの向こう側に分配される、または内部の、そして、閉じているネットワークの完全中で機能しても、問題があります。
4.2 WDSPs attributes and schemas
4.2 WDSPs属性とschemas
Today the DAG system makes use of 2 information schemas -- the DAGPERSON schema for information about specific people, and the DAGORGROLE schema for organizational roles. The technical specification includes a definition of the schema, as well as an understood mapping to (and from) some standard schemas used in the supported protocols. Nevertheless, to include new WDSPs which may not have all attributes in schemas, may use different schemas as well as query attributes, it should be possible to provide creation and use of new customized/standardized schemas and perform schema mapping if it's necessary. It might also be possible to constrain queries to desired query attributes, templates, or object classes.
今日、DAGシステムは2情報schemasを利用します--特定の人々の情報のためのDAGPERSON図式、および組織上の任務のためのDAGORGROLE図式。 技術仕様書は図式の定義を含んでいます、いくらかの標準のschemasがサポートしているプロトコルに使用した(and from)への理解されているマッピングと同様に。 それにもかかわらず、schemasにすべての属性を持っているかもしれないというわけではなくて、異なったschemasを使用して、属性について質問するかもしれない新しいWDSPsを含むように、それが必要であるなら、新しいカスタム設計されたか標準化されたschemasの作成と使用を提供して、図式マッピングを実行するのは可能であるべきです。 また、必要な質問属性、テンプレート、またはオブジェクトのクラスに質問を抑制するのも可能であるかもしれません。
Eklof & Daigle Informational [Page 12] RFC 2969 Wide Area Directory Deployment October 2000
領域ディレクトリ展開2000年10月に広いEklof&Daigle情報[12ページ]のRFC2969
In practice, this means that different WDSP's may choose to use different subparts of one defined schema, or even implement local customizations.
実際には、これは、異なったWDSPのものが、1つの定義された図式の異なった下位区分を使用するか、または地方の改造を実装するのさえ選ぶかもしれないことを意味します。
5.0 Some conclusions
5.0 いくつかの結論
Although fewer people now hold out the hope of a unified global directory service, based on standardize protocols, it is interesting to see more projects providing infrastructure that permits unified access to what is otherwise an unforgivingly diverse and dislocated set of information servers. What cannot be dictated (in standardized protocols and schemas) may yet be accommodated through service infrastructure. The right approach seems to be to build better and better frameworks for supporting such diversified services, without making the framework architecture dependent on specific technologies.
現在がベースの統一されたグローバルなディレクトリサービスの望みから成立するより少ない人々がプロトコルを標準化しますが、可能にするインフラストラクチャがそうでなければ容赦なく多様で脱臼されたセットの情報サーバであることへのアクセスを統一したなら、より多くのプロジェクトを見るのはおもしろいです。 書き取ることができない(標準化されたプロトコルとschemasで)ことはやがて、サービスインフラストラクチャを通して収容されるかもしれません。 正しい解決法はそのような様々なサービスをサポートするためにますます良いフレームワークを築き上げることになっているように思えます、フレームワークアーキテクチャを独自技術に依存するようにしないで。
6.0 Security Considerations
6.0 セキュリティ問題
To date, the TISDAG project has focused on serving only publicly- sharable information. As noted in Section 4.1, any future work will have to provide additional facilities for providing authentication, authorization, encryption, and otherwise handling sensitive data in an open environment.
これまで、TISDAGプロジェクトは、公的にだけ共有可能情報に役立つのは焦点を合わせました。 セクション4.1に述べられるように、どんな今後の活動もオープンな環境で認証、承認、暗号化、およびそうでなければ取り扱うのを提供するための追加の便宜供与に機密のデータを提供しなければならないでしょう。
7.0 Acknowledgements
7.0 承認
This document outlines the perspectives and opinions of the authors, based on experience as well as many fruitful and enlightening discussions with others: Roland Hedberg, Torbjorn Granat, Patrik Granholm, Rikard Wessblad and Sandro Mazzucato.
このドキュメントは作者の見解と意見について概説します、他のものとの多くの実り多くて啓蒙的な議論と同様に経験に基づいて: ローランド・ヘドバーグ、Torbjorn Granat、パトリクGranholm、Rikard Wessblad、およびサンドロスマッツカート。
The work described in this document was carried out as part of an on-going project of Ericsson. For further information regarding that project, contact:
本書では説明された仕事がエリクソンの継続しているプロジェクトの一部として行われました。 そのプロジェクトに関する詳細に関しては、以下に連絡してください。
Bjorn Larsson
bjorn.x.larsson@era.ericsson.se
ビヨンラーソン bjorn.x.larsson@era.ericsson.se
Eklof & Daigle Informational [Page 13] RFC 2969 Wide Area Directory Deployment October 2000
領域ディレクトリ展開2000年10月に広いEklof&Daigle情報[13ページ]のRFC2969
8.0 Authors' Addresses
8.0 作者のアドレス
Thommy Eklof Hotsip AB
Thommy Eklof Hotsip AB
EMail: thommy.eklof@hotsip.com
メール: thommy.eklof@hotsip.com
Leslie L. Daigle Thinking Cat Enterprises
猫計画を考えるレスリーL.Daigle
EMail: leslie@thinkingcat.com
メール: leslie@thinkingcat.com
9.0 References
9.0の参照箇所
Request For Comments (RFC) and Internet Draft documents are available from numerous mirror sites.
For Comments(RFC)とインターネットDraftドキュメントが多数のミラーサイトから利用可能であるよう要求してください。
[CIP1] Allen, J. and M. Mealling, "The Architecture of the Common
Indexing Protocol (CIP)", RFC 2651, August 1999.
[CIP1] アレンとJ.とM.食事、「一般的なインデックスプロトコル(CIP)のアーキテクチャ」、RFC2651、1999年8月。
[CIP2] Allen, J. and M. Mealling, "MIME Object Definitions for
the Common Indexing Protocol (CIP)", RFC 2652, August
1999.
[CIP2] アレンとJ.とM.食事、「一般的なインデックスプロトコル(CIP)のためのMIMEオブジェクト定義」、RFC2652、1999年8月。
[CIP3] Allen, J., Leach, P. and R. Hedberg, "CIP Transport
Protocols", RFC 2653, August 1999.
[CIP3] アレンとJ.とリーチとP.とR.ヘドバーグ、「CIPトランスポート・プロトコル」、RFC2653、1999年8月。
[DAG++] Daigle, L. and T. Eklof, "An Architecture for Integrated
Directory Services", RFC 2970, October 2000.
[2000年10月の縁飾り+ +] Daigle、L.とT.Eklof、「統合ディレクトリサービスのためのアーキテクチャ」RFC2970。
[DAG-Mesh] Daigle, L. and T. Eklof, "Networking Multiple DAG servers:
Meshes", RFC 2968, October 2000.
[DAG-メッシュ]のDaigle、L.、およびT.Eklof、「ネットワークMultiple DAGサーバ:」 「メッシュ」、RFC2968、2000年10月。
[TISDAG] Daigle, L. and R. Hedberg "Technical Infrastructure for
Swedish Directory Access Gateways (TISDAG)," RFC 2967,
October 2000.
[TISDAG]Daigle、L.、およびR.ヘドバーグ、「スウェーデンのディレクトリアクセスゲートウェイ(TISDAG)への技術インフラ」、RFC2967、10月2000日
[centroid] Deutsch, P., Schoultz, R., Faltstrom, P. and C. Weider,
"Architecture of the WHOIS++ service", RFC 1835, August
1995.
[図心] ドイツ語とP.とSchoultzとR.とFaltstromとP.とC.ワイダー、「WHOIS++サービスのアーキテクチャ」、RFC1835、1995年8月。
[NDD] Hedberg, R. and H. Alvestrand, "Technical Specification,
The Norwegian Directory of Directories (NDD)", Work in
Progress.
[NDD] 「技術的な仕様、ディレクトリ(NDD)のノルウェーのディレクトリ」というヘドバーグ、R.、およびH.Alvestrandは進行中で働いています。
Eklof & Daigle Informational [Page 14] RFC 2969 Wide Area Directory Deployment October 2000
領域ディレクトリ展開2000年10月に広いEklof&Daigle情報[14ページ]のRFC2969
[TIO] Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A
Tagged Index Object for use in the Common Indexing
Protocol", RFC 2654, August 1999.
[TIO]ヘドバーグとR.とグリーンブラットとB.とモウツとR.とM.ウォール、「Common Indexingプロトコルにおける使用のためのTagged Index Object」、RFC2654、1999年8月。
[complex] P. Panotzki, "Complexity of the Common Indexing Protocol:
Predicting Search Times in Index Server Meshes", Master's
Thesis, KTH, September 1996.
[複雑]のP.Panotzki、「一般的なインデックスの複雑さは議定書を作ります」。 「インデックスサーバメッシュで検索時間を予測する」マスターの論文、KTH、1996年9月。
[WAP] The Wireless Application Protocol, http://www.wapforum.org
[WAP] ワイヤレス・アプリケーション・プロトコル、 http://www.wapforum.org
Eklof & Daigle Informational [Page 15] RFC 2969 Wide Area Directory Deployment October 2000
領域ディレクトリ展開2000年10月に広いEklof&Daigle情報[15ページ]のRFC2969
Appendix -- Specific Software Issues and Deployment Experiences
付録--特定のソフトウェア問題と展開経験
The following paragraphs outline practical deployment experiences in an anecdotal fashion. This is not meant to be construed as an exhaustive, authoritative evaluation of existing client software, but rather an indication of the types of challenges the average implementation team may expect to encounter in a development and deployment effort.
以下のパラグラフは逸話のファッションの実用的な展開経験について概説します。 これはしかし、既存のクライアントソフトウェアの徹底的で、正式の評価、むしろ開発と展開取り組みで遭遇する平均した実装チームが、予想するかもしれない挑戦のタイプのしるしに理解されることになっていません。
Character encoding ------------------ One client's addressbook sends iso-8859 encoding (depending on the font configuration in the browser) when querying a directory server but the directory server responds with Unicode (UTF-8) encoding. This means that the LDAP CAP would have to handle different character set encodings for request and response.
文字符号化------------------ ディレクトリサーバについて質問するとき、1人のクライアントのaddressbookはコード化(ブラウザでのフォント構成に依存する)をiso-8859に送りますが、ディレクトリサーバはユニコード(UTF-8)コード化で反応します。 これは、LDAP CAPが要求と応答のために異なった文字集合encodingsを扱わなければならないことを意味します。
Referrals --------- Today there appears to be only one commercial addressbook supporting LDAPv3. All the others support only LDAPv2. However, this LDAPv3 client software does not handle referrals correctly -- the client couldn't handle server the result contains "response code 10" (designated for referrals). From what was observed, there was now way for the client or the end-user to decide if, or which, referrals to follow-up. It is therefore not clear how the LDAP clients handle a combination of both referrals and results -- but the supposition is that it doesn't work.
紹介--------- 今日、LDAPv3をサポートする1商業addressbookだけがあるように見えます。 すべての他のものがLDAPv2だけをサポートします。 しかしながら、このLDAPv3クライアントソフトウェアは正しく紹介を処理しません--クライアントは結果が「応答コード10インチ(紹介のために、指定される)」含むサーバを扱うことができませんでした。 観測されたことからクライアントかエンドユーザが決める方法が今や来ていた、どれ、追求する紹介。 したがって、LDAPクライアントがどのように紹介と結果の両方の組み合わせを扱うかが、明確ではありませんが、仮定は働いていないということです。
Objectclasses in LDAP --------------------- No objectclass is defined in the query to the DAG-system from the LDAP-clients. This means that the DAG-system doesn't see any differences between "inetOrgPerson" and "organisationalRole" when attribute "cn" is representing both "name" and "role". This is not so much a problem as that it has interesting side effects. Namely, although most directory user interfaces (found in browsers, mail programs) claim only to support person-related queries, in practise a user of the client could use the interface to send a query with role in the name entry.
LDAPのObjectclasses--------------------- objectclassは全くLDAP-クライアントから質問でDAG-システムと定義されません。 これは、属性"cn"が「名前」と「役割」の両方を表しているとき、DAG-システムが"inetOrgPerson"と"organisationalRole"の少しの違いも見ないことを意味します。 それには面白い側面効果があることにおいてこれはそれと同じくらい多くの問題ではありません。 すなわち、大部分のディレクトリユーザは単に人の関連の質問をサポートして、中でユーザを練習するクレームを連結しますが(中にブラウザを設立してください、メールプログラム)、クライアントは、著者記入における役割がある質問を送るのにインタフェースを使用できました。
Query with attribute Organisation --------------------------------- It is possible to send a query with attribute "organisation" but it would result in no hits because of that the organisation attribute is not included in the objectclass "inetOrgPerson". Roland Hedberg has proposed a change for the latest release of the objectclass definition document.
属性で、Organisationについて質問してください。--------------------------------- それのためにヒットがないのにおけるそれだけがそうする属性「機構」結果がある質問を送るために、機構属性がobjectclass"inetOrgPerson"に含まれていないのは、可能です。 ローランド・ヘドバーグはobjectclass定義ドキュメントの最新のリリースのために変化を提案しました。
Eklof & Daigle Informational [Page 16] RFC 2969 Wide Area Directory Deployment October 2000
領域ディレクトリ展開2000年10月に広いEklof&Daigle情報[16ページ]のRFC2969
To provide the desired ability to narrow search focus to some range of organization names (attribute values), there are three possible approaches with differing merits/detractions:
何らかの範囲の組織名(属性値)への狭い検索焦点に必要な能力を提供するために、異なった長所/非難に関する3つの可能なアプローチがあります:
Recommend the use of the "locality" attribute -- although a more
standard definition would be required (locality is currently used
for everything from organization to county to map coordinates).
より標準の定義が必要でしょうが(組織からカウンティーまでのすべてが座標を写像するのに場所は現在、使用されます)、「場所」属性の使用を推薦してください。
Recommend or require that the attribute organisation should be
inherited in objectclass "inetOrgPerson".
属性機構がobjectclass"inetOrgPerson"で引き継がれるべきであるのを推薦するか、または必要であってください。
Build the LDAP DAG-SAP to submit 2 query to the WDSP. The second
is the same as the first, with only cn filters if the entire query
including "o" results in no hits (i.e., back off from the
organization filtering if it doesn't seem to be supported).
LDAP DAG-SAPを建てて、2質問をWDSPに提出してください。 2番目が1番目と同じである、cnフィルタだけで、「o」は全体の質問であるならヒットを全くもたらして(すなわち、組織フィルタリングから、サポートされるように思えないなら、引き返してください)、包含することがないです。
Configuration ------------- It is not possible to see what character set a LDAP clients want to use. The recommendation so far in he project has been to define a unique port for each character set. This requires extra end-user configuration of client software, and proper advertising of the port number-charset mapping provided in the service.
構成------------- LDAPクライアントがどんな文字集合を使用したがっているかわかるのは可能ではありません。 中の今までのところ、彼が映し出す推薦は各文字集合のためにユニークなポートを定義することです。 これはクライアントソフトウェアの付加的なエンドユーザ構成、およびサービスに提供されたポート数charsetマッピングの適切な広告を必要とします。
DN -- When the user wants to look-up more information about a person found in a preliminary search, the LDAP client uses the entry's DN together with host and port to the DAG system. Not only does that mean that the client submits a non-compliant query to the DAG system, as DNs are not part of any of the defined queries for the service, it simply does not provide the desired effect of getting to the user's entry.
DN--ユーザが予備調査で見つけられた人に関する詳しい情報がルックアップに欲しいときに、LDAPクライアントはホストとポートと共にDAGシステムにエントリーのDNを使用します。 それは、DNsが一部でないのでサービスのための定義された質問のどんなもクライアントがDAGシステムに不従順な質問を提出することを意味するだけではなく、それはユーザのエントリーに着くという所期の効果を絶対に供給しません。
Response Codes -------------- The LDAPv3 client that was used does not support more than 2 response codes -- "success" and "size limit exceeded". All the other response codes are translated to "size limit exceeded", although no results are returned. That is, if the error was in fact that the size limit was exceeded, the results up to the size limit are presented. If it was another response code mapped to that one, no results are presented.
応答コード-------------- 使用されたLDAPv3クライアントは、2以上応答がコードであるとサポートしません--「成功」と「超えられていたサイズ限界。」 結果は全く返されませんが、他のすべての応答コードが「超えられていたサイズ限界」に翻訳されます。 すなわち、誤りが事実上、サイズ限界が超えられていたということであったなら、サイズ限界までの結果は提示されます。 それがそれに写像された別の応答コードであったなら、結果は全く提示されません。
Eklof & Daigle Informational [Page 17] RFC 2969 Wide Area Directory Deployment October 2000
領域ディレクトリ展開2000年10月に広いEklof&Daigle情報[17ページ]のRFC2969
Sending and loading CIP Index Objects ------------------------------------- At least one server is quoting the CIP-object incorrectly for the Swedish characters A-Ring, A-Umlaut and O-Umlaut. Sending quoted printable CIP-objects with PINE mail software works.
発信とローディングCIP Index Objects------------------------------------- 少なくとも1つのサーバがスウェーデンのキャラクタA-一味、A-ウムラウト符号、およびO-ウムラウト符号のために不当にCIP-オブジェクトを引用しています。 発信はソフトウェアが扱うPINEメールで印刷可能なCIP-オブジェクトを引用しました。
Source - Labeled URI -------------------- The original plan for the use of the labeled-URI attribute was to use it to return a pointer to the WDSP that provided the user information. However, the standard use of the labeled-URI attribute, which may in fact be populated in the data returned by a WDSP, is to contain the URI for more private related homepages.
ソース--ラベルされたURI-------------------- ラベルされたURI属性の使用のための原案はユーザー情報を提供したWDSPに指針を返すのにそれを使用することでした。 しかしながら、事実上、WDSPによって返されたデータで居住されるかもしれないラベルされたURI属性の標準的用法は、より個人的な関連するホームページのためのURIを含むことです。
Eklof & Daigle Informational [Page 18] RFC 2969 Wide Area Directory Deployment October 2000
領域ディレクトリ展開2000年10月に広いEklof&Daigle情報[18ページ]のRFC2969
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機能のための基金は現在、インターネット協会によって提供されます。
Eklof & Daigle Informational [Page 19]
Eklof&Daigle情報です。[19ページ]
一覧
スポンサーリンク
