Network Working Group T. Eklof
Request for Comments: 2969 L. Daigle
Category: Informational October 2000
Wide Area Directory Deployment - Experiences from TISDAG
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
The 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 Gatewayの技術基盤は）大規模なディレクトリサービスを展開する現在の現実に貴重な洞察を提供します。この文書では、既製のディレクトリサービス製品と環境におけるサービスの国民（すなわち、マルチ組織）ディレクトリサービスとパイロット展開のために必要なインフラ整備で得られた経験のいくつかをカタログ。他のディレクトリ展開プロジェクトへのプロジェクトの関係上の視点はいくつかの仕事の将来の拡張のための提案（大規模展開、他の応用分野）と一緒に、提供されます。
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!
これらは、仕事に行われ、一般的なプロジェクトの議論をもとに、私たち自身の観察、です。間違いなく、他のプロジェクト参加者は、プロジェクトの経験の独自のリストを持っています。私たちは、この文書は網羅的であると主張していません！
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
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プロジェクトの本来の意図は、国家ホワイトページディレクトリサービスのインフラストラクチャを提供することでした。効果的であるために、そのようなインフラストラクチャは、エンドユーザーの既存のクライアントソフトウェアの具体的な現実と同様に、情報提供（ - WDSPs 『ホワイトページディレクトリ・サービス・プロバイダ』）のニーズに対応するために必要な。これらの現実は、複数のプロトコル（いわゆるディレクトリ・サービス・アクセス・プロトコル、ならびにHTTPやSMTPなどのより一般的なインターネットアプリケーションプロトコル）の存在が含まれます。プロジェクトはまた、WDSPsが加入者の個人データのコピーを放棄することに消極的であるために多くの良い理由があるという事実に敏感でした。
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つの主要なセクションに分かれています。最初のセクションでは、TISDAGプロジェクトと1つの準拠のシステムの実施を通じて著者が学んだ教訓の特定をレビュー。次に、いくつかの観点では、これらの努力はおそらく対話するかもしれない方法の意味を与えるために、現在、進行している他の大規模なディレクトリのプロジェクトへTISDAGの仕事の関係で提供されています。最後に、他のアプリケーションとデプロイメント環境にDAGシステムを適用する上でいくつかの予備的な考えが概説されています。ネットワーク上のDAGサーバ（メッシュ）を展開するためのさらなる提案は[DAG-メッシュ]で見つけることができます。建築原理の有用な開発のより多くの議論は、別の文書（[DAG ++]）に設けられています。
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]参照）、基本的なホワイトページクエリを実行するための接続ポイントとエンドユーザクライアントソフトウェアを提供しています。 WWW（HTTP）、電子メール（SMTP）、Whoisの++、LDAPv2のとLDAPv3の - 別の接続ポイントは、エンドユーザーが情報にアクセスするために使用したいと思われるさまざまなプロトコルのために提供されています。各クライアントのために、トランザクションは、プロトコルの構文と意味の範囲内で行われます。しかし、TISDAGシステムは、クライアントのクエリ、背景の仕事の公平なビットと一致する回答が含まれている可能性のあるサービスにすべてのホワイトページの情報の複製されたコピーではなく、リダイレクト（紹介）を可能にするデータの索引を維持しないので、クライアントのクエリを満たすためにDAGシステムによって行われなければなりません。
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.
タグ付きの索引オブジェクトに共通インデックスプロトコルによって得られたインデックス情報を（（[CIP1、CIP2、CIP3]参照）を含むサーバー - 最初の、そして最も重要なステップは、DAG紹介インデックスに対してクエリを作成するシステムのためにありますそれは直接関係WDSPsに連絡することができるようにフォーマット（[TIO]を参照）。このインデックスは、クエリを完了するために、連絡しなければならない多くの参加WDSPsのかを示すのに十分な情報が含まれています。可能な限りは、これらの照会はバッククエリクライアントに渡されます。これは、DAGシステム自体によって行われた仕事の量を最小限にし、（システムに参加するためのインセンティブである）WDSPs大きな可視性を可能にする参照をサポートするプロトコルは、ネイティブのWhois ++とのLDAPv3を含む - これらは唯一のサーバと呼ばれることもあるが同じプロトコル。
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クライアントがシステムに接続している場合たとえば、クエリは、クエリのための答えを持っている可能性があるWDSPs決定するために紹介インデックスに対して行われ、その後、DAGシステム内のリソースを指定WDSPs'のサーバーでクエリを追求するために使用されています。これらの異なるサービスからの結果は、クエリを行ったクライアントに設定された単一の応答にパッケージ化されています。
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）、参照インデックス（RI）から入ってくるクエリーを処理するために別個の構成要素にシステムを分離しました関連する情報があるかもしれませんWDSPs、そして最終的にクエリを実行し、クライアントのクエリの結果（「サービス・アクセス・ポイント」、またはSAPを）取得するためにWDSPのホワイトページサーバへのアクセスを仲介するコンポーネントに、実際のデータのクエリに基づいて、紹介を情報提供しています。いくつかのCAPとSAPは、システム内に存在する - はそれぞれ、入ってくるクエリと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 - 別々のプログラムとして実現可能であるように設計され、これらの構成要素は、内部プロトコルの使用を介して互いに相互作用します。実用的に、プロトコルの使用は、異なる成分はロードバランシングおよび性能向上の理由のために、異なるマシン上に存在することができることを意味します。また、クエリを表現し、その結果を受け取るためのCAP、SAPのとRIのための「共通言語」として機能します。
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つの独立した実装が作成された、およびテスト展開は、スウェーデンの大学ネットワーク（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.
成功と驚きの両方 - このセクションの残りの部分は、提案されたアーキテクチャの現実を作るから引き出されたいくつかの結論を概説します。
Implementation and pilot deployment of software meeting the TISDAG technical specification did demonstrate some important successes of the approach.
TISDAG技術仕様を満たすソフトウェアの実装とパイロット展開は、アプローチのいくつかの重要な成功を実証しました。
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.
最も顕著なのは、システムが期待通りにほとんど働くホワイトページのディレクトリサービス用の透明のミドルウェアを提供するために、（下記の例外を参照）。つまり、クライアントソフトウェアと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プロジェクトの目標は、運用、（「アドレス帳の交換」ではないが）合理的な応答時間内のクエリエンドユーザへの応答を提供できるようにしました。プロトタイプシステムは、少なくとも10 WDSPのは、ディレクトリサービスの情報を提供してコンフィギュレーションの限られたテストベッドで、10秒以内に応答を達成するために、いくつかの成功を実証しました。システム性能の詳細な観察は、以下に提供されます。
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のマッピングのN + Mの複雑さに（セマンティック）プロトコルマッピングを行うには、ある意味で、それが可能であることを実証しました。つまり、プロトコル翻訳はに/ DAG / IPから許容エンドユーザーの照会アクセス・プロトコル「N」に対して定義されなければならなかったし、「M」は、WDSPサーバプロトコルをサポート、代わりに個別にマッピングするために、N個の入力成分の各々を必要M出力プロトコル。
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.
システムのスキーマがシンプルに保ち、基本サービスの要件をサポートするための最低限のニーズに焦点を当てていたので、大部分は - 相関問題として、プロトタイプシステムは、異なるプロトコルパラダイムのスキーマ表現の間のマッピングといくつかの成功を実証しました。
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.
実装およびソフトウェアシステムの最初の展開による仕様の最初の「最後の」文書から十ヶ月のスパンで、いくつかの驚きは、表面をしました。理論的な仕様が実用化されたときに浮上しているもの、そして得られたシステムは、商用ソフトウェアクライアントとサーバで動作させたとき、明らかになった他の人：これらは、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.
詳しくは、発生した特定のソフトウェアの問題に関する付録に提供されていますが、実装フェーズの間に浮上し、より大きな問題のいくつかを以下に説明しています。
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者のいずれも（「O」）の組織を含まないオブジェクトクラスという、かなりの驚き、プロジェクトにいくつかのヶ月となりました。基本的な前提は、「O」は、エントリの識別名の一部となり、そのため、別途それをリストアップするために少し（もしあれば）原因があることのようです。これはトリッキー（ISPのディレクトリ・サーバーで、例えば）複数の組織間での人のための情報を保存するために作成し、クエリの洗練に組織名を使用しません。 （ローランドヘドバーグは、この問題を捕まえて、「inetOrgPersonの」オブジェクトクラス文書の作成者にそれをフラグを立てています）。
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.
RIにWDSP情報のインデックスを運ぶために使用されるタグ付きインデックスオブジェクト（「TIO」）は、RIで検索を実行するときに生成された偽陽性の紹介の数を減らすために、レコード（エントリ）タグを持つように設計されています。インデックスオブジェクトのいくつかの点で成長、すなわち - 最初のインデックスオブジェクトタイプの特徴の一つ、Whoisの++の重心が（[重心]を参照）インデックスオブジェクトのサイズがインデックスデータのサイズに直線的に成長しなかったという事実でした基礎となるデータセットに比べて遅く。一見すると、これはまた、TIOのためのケースのようです。インデックスのサイズが大きくなるにつれてしかし、TIOの圧縮係数は、重心と同じ効率を達成しなくてもよいです。この理由の一つは、タグ付けされたリストは、基礎となるデータへのタグの割り当ての順序によっては、かなり長く得ることができるということです。すなわち、定義されたようなタグは、タグの圧縮された発現を可能にする、ある「範囲」 - 例えば、「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.
また、実際にはRIのタグの効率的な利用（時間）を作るために、それを行うことができるようにインデックスオブジェクトを「reinflate」ことはほとんど必要であると一致したトークンに関連付けられているタグリストに結合します。代替的に、圧縮されたタグリストを格納することができ、およびトークンを一致させるためのタグリストを比較に関連する追加コストがある - ベースのデータベース管理システムの範囲外で行わすなわち、リスト比較演算。なされるべき予想外のトレードオフがありました。
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（SAPはいえ）にクエリをチェーンするときWDSPサーバの少なくとも一方がエラーコードを返すか、使用できなくすることは珍しくありません。 1 WDSPに到達することができない場合は、いくつかの照会のうち、クライアントソフトウェアは、クエリが正常に完了し、またはされなかったという印象を与えられるべきですか？ほとんどのクライアントプロトコルのエラー処理モデルは、明確な区別のこのレベルを作るのに十分な洗練されたではありません。
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>").
それはその後、標準的な市販のクライアントとサーバーのソフトウェアとの結果のソフトウェアをテストするための時間だったときに、いくつかのより多くの驚きは、（主にこれらのソフトウェア予想される世界観と時折実装ショートカットの面で）明るみに出ました。ここでも、より詳しくは、付録に提供するが、ハイライトは、非常に小さなプロトコルの定義されたステータスメッセージの語彙（例えば、サポート2つのシステム・メッセージ）のサブセット、および自動的にクエリに追加条件を付加したクライアントソフトウェアを扱うことができ、クライアントソフトウェアが含まれていますユーザーが指定した（例えば、追加「または電子メール= <何をクエリにして入力したユーザー>」）。
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.
紹介インデックスへインデックスオブジェクトを統合するという点で、取り扱いクエリの効率の両方の観点から - 明るみに出たことの一つは、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さんに提案することが可能なはずです。
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の++重心のためのトークン化されたデータと特異的に対処し、すぐにタグ付きインデックスオブジェクトのすべての形式に一般化ではありません。しかし、TIOの特定の構造はTISDAGプロジェクトのために使用したのと同じ「桁」と成長特性が適用可能であることを重心と構造が十分に類似しています。
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.
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.
データは一意である何か、例えば上のトークン化されている場合は電話番号は、その後、概算はnumber_of_tokensの=のnumber_of_data_recordsということです。例えば部品で電話番号を分割し、さまざまな方法でトークン化することが可能であることに留意されたいです。これは、少数のトークンになります。
. 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.
。トークンは、各ディレクトリごとに個別に生成されるので、ディレクトリの数は、データのサイズは、ディレクトリの数に依存します。 100.000レコードを持つ10個のディレクトリが1.000.000レコードを持つ一つのディレクトリとトークンの同じ量を生成します。
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.
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.
。検索の数は、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.
。ディレクトリ数は、ディレクトリの数が多いほど、多くの紹介につながるかもしれないが、それは、クエリに依存します。単純なクエリは、ディレクトリからの大量のデータをフェッチしなければなら意味し、紹介の多くを生成します。また、内部の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.
。結果データは、DAGシステムを介して送信する必要がないため、連鎖していないチェーン紹介クエリの数は、高速です。いくつかのディレクトリにチェーンのクエリは、SAPのに並行して処理することができますが、すべてのデータがクライアントに送信される前に、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.
。トークンの数（タグ付きインデックスオブジェクトのサイズ）トークンの数は、内部のDAGデータベース内のルックアップ時にはほとんど影響を与えます。
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年の間、「生きている」となっています。その間、進化の数があった - プロジェクト以外の技術やアイデアの面で（例えば、ユーザとサービスプロバイダの期待、関連ソフトウェアの導入、など）プロジェクトの範囲内だけでなく、目標と理解。
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 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.
これらの最後の中で最高経営責任者は、プロジェクトが主に国家紹介サービスの役割を果たすために着手し、徐々にクライアントプロトコルのセマンティクスの中に、できるだけ完全にクライアントのクエリを満たす、透明プロトコルプロキシサービスのより多くなってきて向けて進化しているという事実です。この進化は、おそらく多くの理由によって引き起こされた - 既存のクライアント＆サーバーソフトウェアは、そのプロトコルの仕様が記述しているよりも受け入れ（予想される）行動の狭い範囲を持って、技術はいくつかのプロキシにあった後は、すべての道を行くことと思われました手の届くところに、など
>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).
>国民のホワイトページサービスを提供するという観点から、これは非常に肯定的な進化です。しかし、それは場所にいくつかの調整が提案されているため、元のシステムアーキテクチャ、（以下に詳細）上のいくつかの株をしました。何それほど明確であることは、この進化は、システム・アーキテクチャの柔軟性に与える影響である - 他のアプリケーションであるなど、異なるプロトコル（およびプロトコルのパラダイム）を、アドレッシングの観点から、システムの本来の意図は、にした非常に簡単素朴な役割を果たす - 「ソートの入力クエリに一致し、一致が十分に近接している場合、クライアント自身が決定させるものを見つけます」。要件がより高度になるように、システムの簡素化が影響を受け、そしておそらくより脆いれます。 （これを回避するためのいくつかの提案は、基礎的な原理に戻り、そのレベルでのステップを前方に提案しようとする[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.
. 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クエリ言語で追加の制約は、まだ非常に洗練されたクエリを表現するための内部プロトコルを可能にするのに十分ではありません。 （LDAPクエリは、フレーズ志向しているのに対し）もともとクエリルーティングクエリのためにのみ意図され、DAG / IPは、すべてのクエリは、トークンベースであることを期待しています。これは、クエリの履行のためのCAPによって送られたDAG / IPのクエリに一致するように設定しますSAPはWDSP結果の「ポスト・剪定」の良い取引をしなければならないことを意味します。そして、キャップは今度はもっと後の剪定しなければならない元のクエリセマンティクスまで（SAPのから）DAG / IPの結果と一致します。
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, etc. Future improvements should focus on evolving that framework, maintaining the separation from the specific applications, services, and protocols that may use it.
今後の改善に焦点を当てる必要があるクエリ＆スキーマ・マッピング、プロトコルのための構成など - TISDAGプロジェクトの本当の強さは、それが特定のアプリケーションやサービスをサポートするために必要な設定からサービスをサポートするために必要な技術的なフレームワークを分離ということでしたそれを使用することができる特定のアプリケーション、サービス、およびプロトコルからの分離を維持し、そのフレームワークを進化。
The TISDAG project is not alone in attempting to solve the problems of providing coordinated access to resources managed by multiple, disparate services.
TISDAGプロジェクトは、複数の異なるサービスが管理するリソースへの協調のアクセスを提供する問題を解決しようとするだけではありません。
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（v2またはv3の）（WDSPそれ自体で、または他の構成を通じて提供）WDSP情報のアクセシビリティを前提とし、コヒーレントネットワークに合わせて既に運用LDAPサーバをフックに関連したトリッキーな問題の一部を解決することを目指して：制服が区別スキーム、およびコンテンツベースの紹介を命名。んの紹介をサポートしていません。例えば、V2、V3と、 - それはまた、別のLDAPクライアントのバージョンと互換性があることの実用的な現実の一部に対処しています。
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).
システムの心臓部にはノルウェーの組織の上に検索可能なカタログを提供します「紹介インデックスと組織情報」（RIO）サーバー、です。これは、個々の組織のためのホワイトページサーバの場所を促進する（クエリと仮定している組織（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.
この作品は、LDAPディレクトリサーバーを統合するためのより集中サービスを提供するには、TISDAG作業に相補的であるとみなすことができます。しかし、1人が自分の電子メールアドレスの検索を行う前に、所属する組織を知っているいくつかの要件が依然として存在しています。これは、人の仕事の組織に関連付けられたメールアドレスを追求するために合理的であるが、それは個人の電子メールアドレスを見つけることになるとあまり頻繁に成功するかもしれ - ISPがたくさんある時代に、ユーザーのISP識別の事前知識はほとんどありません。
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は）研究と教育に関する情報のための分散欧州のインデックスシステムを開発しています。 DANTEとSURFNETが行ったディレクトリサービスの仕事は、広域ディレクトリサービスインフラストラクチャを作成するには、サーバーのメッシュ構造に適用されるアーキテクチャを提案しています。
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.
このサービスは、両方のホワイトページWDSPsのLDAPサーバーとの情報だけでなく、ウェブ検索が資源や他のインデックスベースのサービスへのクエリのルーティングについては、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ディレクトリサービス事業間のアーキテクチャの違いがありますが、駆動ニーズの多くは同じであり、コンテンツベースのインデックスと紹介を使用してのアプローチも選択されました。
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メッシュ]で議論されています。
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プロジェクトの公共白いページのアプリケーション以外のアプリケーションの分野で幅広いスケールのディレクトリシステムを利用したセキュリティ上の配慮が必要です。ディレクトリサービスは、インターネット上に分散されているかどうか、またはそれは内部、閉じたネットワーク内に完全に機能していても問題があります。
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.
特定の人については、DAGPERSONスキーマ、および組織の役割のためのDAGORGROLEスキーマ - 今日DAGシステムは、2つの情報スキーマを使用しています。技術仕様は、スキーマの定義、ならびにサポートされているプロトコルで使用されるいくつかの標準スキーマに（と）から理解されるマッピングを含みます。それにもかかわらず、スキーマ内のすべての属性を持っていない可能性があり、新たなWDSPs、異なるスキーマを使用するだけでなく、クエリの属性もが含まれるように、新しいカスタマイズ/標準化されたスキーマの作成と使用を提供し、それが必要かどうスキーママッピングを行うことが可能でなければなりません。また、目的のクエリの属性、テンプレート、またはオブジェクトクラスにクエリを制約することができるかもしれません。
In practice, this means that different WDSP's may choose to use different subparts of one defined schema, or even implement local customizations.
実際には、これは異なるWDSPの一つ定義されたスキーマの異なるサブパーツを使用することを選択、あるいはローカルなカスタマイズを実施してもよいことを意味します。
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.
少数の人々は今、標準化プロトコルに基づいて統一されたグローバルなディレクトリサービス、の希望を差し出すが、それ以外の情報サーバのunforgivingly多様性と脱臼のセットであるものに統一されたアクセスを許可するインフラストラクチャを提供するより多くのプロジェクトを見るのは興味深いです。何（標準化されたプロトコルおよびスキーマに）決まることができないことは、まだサービスインフラストラクチャによって収容されていてもよいです。正しいアプローチは、特定の技術上のフレームワークのアーキテクチャに依存せずに、そのような多様なサービスをサポートするためのより良い、より良い枠組みを構築することであると考えられます。
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節で述べたように、将来の仕事には、認証、承認、暗号化、およびそれ以外のオープン環境での機密データを扱うを提供するための追加の機能を提供する必要があります。
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、パトリックグランホルム、Rikard WessbladとサンドロMazzucato：この文書では、経験だけでなく、他の人と多くの実りと啓発の議論に基づいて、視点や著者の意見の概要を説明します。
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
Thommy Eklof Hotsip AB
今トミEclof Hotsip
EMail: thommy.eklof@hotsip.com
メールアドレス：thommy.eklof@hotsip.com
Leslie L. Daigle Thinking Cat Enterprises
レスリーL. Daigle氏猫の企業を考えます
EMail: leslie@thinkingcat.com
メールアドレス：leslie@thinkingcat.com
Request For Comments (RFC) and Internet Draft documents are available from numerous mirror sites.
コメント（RFC）とインターネットドラフト文書の要求は、多数のミラーサイトから入手できます。
[CIP1] Allen, J. and M. Mealling, "The Architecture of the Common Indexing Protocol (CIP)", RFC 2651, August 1999.
[CIP1]アレン、J.とM. Mealling、 "共通インデックスプロトコル（CIP）のアーキテクチャ"、RFC 2651、1999年8月。
[CIP2] Allen, J. and M. Mealling, "MIME Object Definitions for the Common Indexing Protocol (CIP)", RFC 2652, August 1999.
[CIP2]アレン、J.とM. Mealling、 "共通インデックスプロトコル（CIP）のためのMIMEオブジェクト定義"、RFC 2652、1999年8月。
[CIP3] Allen, J., Leach, P. and R. Hedberg, "CIP Transport Protocols", RFC 2653, August 1999.
[CIP3]アレン、J.、リーチ、P.とR.ヘドバーグ、 "CIPトランスポートプロトコル"、RFC 2653、1999年8月。
[DAG++] Daigle, L. and T. Eklof, "An Architecture for Integrated Directory Services", RFC 2970, October 2000.
[DAG ++] Daigle氏、L.とT. Eklof、 "統合ディレクトリサービスのためのアーキテクチャ"、RFC 2970、2000年10月。
[DAG-Mesh] Daigle, L. and T. Eklof, "Networking Multiple DAG servers: Meshes", RFC 2968, October 2000.
[DAG-メッシュ] Daigle氏、L.とT. Eklof、 "複数のDAGサーバネットワーク：メッシュ"、RFC 2968、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）のための技術基盤、" RFC 2967、2000年10月。
[centroid] Deutsch, P., Schoultz, R., Faltstrom, P. and C. Weider, "Architecture of the WHOIS++ service", RFC 1835, August 1995.
[重心]ドイツ語、さらにP.、Schoultz、R.、FALT電気、P.とC.、 "WHOIS ++サービスのアーキテクチャ"、RFC 1835、1995年8月。
[NDD] Hedberg, R. and H. Alvestrand, "Technical Specification, The Norwegian Directory of Directories (NDD)", Work in Progress.
[NDD]ヘドバーグ、R.およびH. Alvestrand、 "技術仕様、ディレクトリのノルウェーのディレクトリ（NDD）" が進行中で働いています。
[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.ワール、「共通インデックスプロトコルにおける使用のためのタグ付きインデックスオブジェクト」、RFC 2654、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、「一般的なインデックスプロトコルの複雑さ：Index Serverのメッシュで検索回数を予測する」、修士論文、KTH、1996年9月。
[WAP] The Wireless Application Protocol, http://www.wapforum.org
[WAP]ワイヤレスアプリケーションプロトコル、http://www.wapforum.org
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.
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.
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.
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.
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:
組織名（属性値）の一部の範囲に、検索焦点を絞るために必要な機能を提供するために、異なるメリット/ detractionsと三つの可能なアプローチがあります。
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".
推奨または属性の組織がオブジェクトクラス「の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).
WDSPに2クエリを提出するLDAP DAG-SAPをビルドします。第二は、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.
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.
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.
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.
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。