[要約] 要約：RFC 2969は、TISDAG（広域ディレクトリ展開）の経験に基づいて、広域ディレクトリの展開に関するガイドラインを提供しています。 目的：このRFCの目的は、広域ディレクトリの展開における経験とベストプラクティスを共有し、他の組織が効果的なディレクトリ展開を行うための支援を提供することです。
Network Working Group T. Eklof
Request for Comments: 2969 L. Daigle
Category: Informational October 2000
Wide Area Directory Deployment - Experiences from TISDAG
ワイドエリアディレクトリの展開-TISDAGからの経験
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
The 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（スウェーデンのディレクトリアクセスゲートウェイ用の技術インフラストラクチャ）プロジェクトは、幅広いディレクトリサービスを展開するという現在の現実に関する貴重な洞察を提供しました。このドキュメントは、既製のディレクトリサービス製品を備えた環境でサービスの国家（つまり、マルチ組織）ディレクトリサービスとパイロット展開に必要なインフラストラクチャを開発する際に得られた経験の一部をカタログ化します。他のディレクトリの展開プロジェクトとのプロジェクトの関係に関する視点が提供され、作業の将来の拡張に関するいくつかの提案（大規模な展開、その他のアプリケーション領域）が提供されます。
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プロジェクトの当初の意図は、National Whitepagesディレクトリサービスにインフラストラクチャを提供することでした。効果的には、エンドユーザーの既存のクライアントソフトウェアの具体的な現実と情報プロバイダー（「Whitepages Directory Service Providers」 - WDSP）のニーズに対処するために必要なこのようなインフラストラクチャ。これらの現実には、複数のプロトコル（いわゆるディレクトリサービスアクセスプロトコル、およびHTTPやSMTPなどのより一般的なインターネットアプリケーションプロトコル）の存在が含まれます。また、このプロジェクトは、WDSPが加入者の個人データのコピーを放棄することに消極的であるという多くの正当な理由があるという事実にも敏感でした。
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-Mesh]にあります。建築原則の有用な開発に関するより多くの議論は、別のドキュメント（[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.
最初の、そして最も重要なステップは、システムがDAG紹介インデックスに対してクエリを作成することです。これは、タグ付きインデックスオブジェクトのインデックス情報（[CIP1、CIP2、CIP3]を参照）を含むサーバー（インデックス情報）を含むサーバーです。形式（[TIO]を参照）。このインデックスには、参加する多くのWDSPのどれが連絡してクエリを完了するかを示すのに十分な情報が含まれています。可能な場合は、これらの紹介は、関連するWDSPに直接連絡できるようにクエリクライアントに渡されます。これにより、DAGシステム自体が行う作業の量が最小限に抑えられ、WDSPがより大きな可視性（これはシステムへの参加のインセンティブです）を可能にします。同じプロトコル。
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クライアントがシステムに接続した場合、どのWDSPがクエリの回答を持っているかを判断するために紹介インデックスに対してクエリが作成され、DAGシステム内のリソースを使用して、指定されたWDSPのサーバーでクエリを追求するために使用されます。。これらの異なるサービスの結果は、クエリを作成したクライアントの単一の応答セットにパッケージ化されます。
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）で収集されたホワイトページ上でインデックスを維持します。情報と、実際のデータクエリに基づいて、関連情報を持つ可能性のあるWDSPへの紹介を提供し、最後にWDSPホワイトページサーバーへのアクセスを媒介してクエリを実行し、クライアントのクエリ（「サービスアクセスポイント」、またはSAP）の結果を取得するコンポーネントを提供します。システム内には、いくつかのキャップと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）を使用して相互作用します。実用的には、プロトコルを使用すると、ロードバランスとパフォーマンスの向上の理由により、さまざまなコンポーネントが異なるマシンに存在する可能性があります。また、キャップ、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サーバーは、動作と構成の観点からは、クライアントにとってサーバーのように見え、クライアントはサーバーに見えました。
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秒以内に10秒以内に応答を達成することにある程度の成功を示しました。これは、10個のWDSPの提供ディレクトリサービス情報を含む構成の限られたテストベッドで。システムのパフォーマンスに関するより多くの観察結果を以下に示します。
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.
実装の成功により、ある意味では、NXMマッピングの代わりに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」objectclassドキュメントの著者にフラグを立てました）。
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情報のインデックスをRIに伝達するために使用されるタグ付きインデックスオブジェクト（ "Tio"）は、RIで検索を行うときに生成される偽陽性紹介の数を減らすために、記録（エントリ）タグを持つように設計されています。最初のインデックスオブジェクトタイプの機能の1つであるWhoisのCentroid（[Centroid]を参照）は、インデックスオブジェクトサイズがインデックス化されたデータのサイズで直線的に成長しなかったという事実でした。基礎となるデータセットのそれと比較して、インデックスオブジェクトが遅くなりました。一見すると、これもTIOの場合のようです。ただし、インデックスのサイズが大きくなると、TIOの圧縮係数は重心と同じ効率を達成できない可能性があります。この理由の1つは、タグのあるタグの割り当てが基礎となるデータへの割り当てに応じて、タグ付けされたリストがかなり長くなる可能性があることです。つまり、定義されたタグ付けにより、「1,2,3、[...] 500」ではなく、「範囲」（例えば、「1-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でタグを（時間）効率的に使用するためには、一致するトークンに関連付けられたタグリストに結合できるようにインデックスオブジェクトを「再フフロフ化」する必要があります。あるいは、圧縮タグリストを保存することができ、トークンのマッチングのタグリストを比較することに関連する追加のコストがあります。つまり、ベースデータベース管理システムの範囲外で行われるリスト比較操作です。予想外のトレードオフが行われました。
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.
エンドユーザークライアントソフトウェアの複数のサブトランザクションから単一のステータス通信へのステータスメッセージのマッピングは、課題になりました。複数のWDSPにクエリをチェックする場合（SAPS）、WDSPサーバーの少なくとも1つがエラーコードを返したり、利用できないことは珍しくありません。いくつかの紹介のうち、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>").
その後、標準の商用クライアントおよびサーバーソフトウェアで得られたソフトウェアをテストする時が来たとき、さらにいくつかの驚きが明らかになりました（主にこれらのソフトウェアの予想される世界観と時折の実装ショートカットの観点から）。繰り返しますが、詳細は付録に記載されていますが、ハイライトには、プロトコルの定義されたステータスメッセージLexicon（サポートされている2つのシステムメッセージなど）の非常に小さなサブセットのみを処理できるクライアントソフトウェア、およびクエリに追加の用語を自動的に追加するクライアントソフトウェアが含まれています。ユーザーによって指定された（例えば、「またはemail = <ユーザーがクエリに入力したもの>」を追加）。
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つは、WDSPによって生成されたインデックスオブジェクトの性質がパフォーマンスに重要な影響を及ぼし、紹介インデックスにインデックスオブジェクトを統合するという点で、およびクエリの処理の効率の観点からです。提案は、WDSPがCIPインデックスオブジェクトをどのように生成するか（現在はその裁量に任されている）か、インデックスオブジェクトが標準以下と見なされている場合に個々のWDSPに警告することです。
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 Centroidsのトークン化データを特に扱い、タグ付きインデックスオブジェクトのあらゆる形式にすぐに一般化できません。ただし、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.
。生成されたトークンの数ディレクトリデータから生成されたトークンの数は、トークン化されたものによって異なります。データが名前とアドレス（つまり、電話番号のような一意のデータではない）でトークン化されている場合、大まかな推定は、number_of_tokens = 0.2 * number_of_data_recordsであるということです。成長は、数千から120万の記録から少なくとも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.
データがユニークなものにトークン化されている場合、例えば電話番号、大まかな推定では、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のレコードを備えた1つのディレクトリと同じ量のトークンを生成します。
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データベースから大量のデータがフェッチされ、より多くのインデックス処理が生成されます。
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システムを介して送信する必要がないため、チェーンされていないチェーンの紹介クエリの数が高速になります。いくつかのディレクトリのチェーンクエリは、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.
。トークンの数（タグ付きインデックスオブジェクトのサイズ）トークンの数は、内部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]で概説されています。[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.
。技術仕様の最新バージョンは、紹介インデックスに向けられたクエリとクエリを満たすために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結果セットの多くの「導入」を行う必要があることを意味します。また、CAPは、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, 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]に記載されているNorwegian Directory of Directories Projectは、全国ディレクトリサービスに必要なインフラストラクチャを提供することも目的としています。WDSP情報のLDAP（V2またはV3）アクセシビリティ（WDSP自体によって、または他のアレンジメントによって提供される）を想定し、すでに操作性のあるLDAPサーバーをコヒーレントネットワークに接続することに関連するトリッキーな問題のいくつかを解決することを目的としています：命名スキーム、およびコンテンツベースの紹介。また、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).
システムの中心にあるのは、「紹介インデックスと組織情報」（RIO）サーバーで、ノルウェーの組織を介して検索可能なカタログを提供します。これにより、個々の組織向けのホワイトページサーバーの場所が容易になります（クエリには、どの組織が興味深いかについての情報が含まれていると仮定します）。
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作業を補完するものと見なすことができます。ただし、電子メールアドレスを検索する前に、人が属する組織を知っているという要件がまだあります。これは、個人の作業組織に関連するメールアドレスを求めるのが合理的かもしれませんが、個人の電子メールアドレスを見つけることに関してはあまり成功していません - 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に資金提供されたProject 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.
このサービスは、WDSPのLDAPサーバーを使用して両方のホワイトページ情報をサポートすることを目的としています。また、他のインデックスベースのサービスへのリソースとクエリのルーティングに関する情報については、WOHISを使用してさまざまな場所でWeb検索メッシュをサポートすることを目的としています。
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 Directory Servicesプロジェクトは、クエリの焦点として機能し、クライアントソフトウェアが幅広い異なるサービスから適切なリソースにアクセスできるようにすることを目的としています。
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 Directory Serviceプロジェクトにはアーキテクチャの違いがありますが、運転のニーズの多くは同じであり、コンテンツベースのインデックス作成と紹介を使用するアプローチも選択されました。
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-Mesh]で説明されています。
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.
今日、DAGシステムは2つの情報スキーマを使用しています - 特定の人々に関する情報のためのDagpersonスキーマ、および組織的な役割のためのダゴルグロールスキーマ。技術仕様には、スキーマの定義、およびサポートされているプロトコルで使用されるいくつかの標準スキーマへの（および（およびそれから）理解されたマッピングが含まれます。それにもかかわらず、スキーマにすべての属性を持たない可能性のある新しいWDSPを含めるには、異なるスキーマとクエリ属性を使用する場合があります。必要に応じて、新しいカスタマイズ/標準化されたスキーマの作成と使用を提供し、スキーママッピングを実行することができるはずです。また、希望のクエリ属性、テンプレート、またはオブジェクトクラスにクエリを制約することも可能かもしれません。
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つの定義されたスキーマの異なるサブパートを使用するか、ローカルのカスタマイズを実装することを選択することを意味します。
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.
標準化プロトコルに基づいて、統一されたグローバルディレクトリサービスの希望を保持する人は少なくなりますが、それ以外の場合は容赦なく多様で脱臼した情報サーバーに統一されたアクセスを可能にするインフラストラクチャを提供するプロジェクトが増えるのは興味深いことです。（標準化されたプロトコルとスキーマで）決定できないものは、サービスインフラストラクチャを通じてまだ対応することができます。適切なアプローチは、特定のテクノロジーに依存するフレームワークアーキテクチャを作成することなく、このような多様化されたサービスをサポートするためのより良いフレームワークを構築することです。
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.
この文書は、経験と他の人との多くの実り豊かで啓発的な議論に基づいて、著者の視点と意見の概要を説明しています：ローランド・ヘドバーグ、トービョルン・グラナト、パトリック・グランホルム、リカード・ウェスブラッド、サンドロ・マッツカト。
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 Larsson bjorn.x.larsson@era.ericsson.se
Thommy Eklof Hotsip AB
Thommy Eklof Hotsip AB
EMail: thommy.eklof@hotsip.com
Leslie L. Daigle Thinking Cat Enterprises
レスリーL.デイグル思考猫企業
EMail: 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] Allen、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] Allen、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] Allen、J.、Leach、P。およびR. Hedberg、「CIP Transport Protocols」、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-Mesh] Daigle、L。およびT. Eklof、「ネットワーク複数のDAGサーバー：Meshes」、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. Hedberg「スウェーデンのディレクトリアクセスゲートウェイの技術インフラストラクチャ（TISDAG）」、RFC 2967、2000年10月。
[centroid] Deutsch, P., Schoultz, R., Faltstrom, P. and C. Weider, "Architecture of the WHOIS++ service", RFC 1835, August 1995.
[Centroid] Deutsch、P.、Schoultz、R.、Faltstrom、P.およびC. Weider、「Whoisサービスの建築」、RFC 1835、1995年8月。
[NDD] Hedberg, R. and H. Alvestrand, "Technical Specification, The Norwegian Directory of Directories (NDD)", Work in Progress.
[NDD] Hedberg、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] Hedberg、R.、Greenblatt、B.、Moats、R。、およびM. Wahl、「共通インデックスプロトコルで使用するタグ付きインデックスオブジェクト」、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、「一般的なインデックス作成プロトコルの複雑さ：インデックスサーバーメッシュの検索時間の予測」、Master's Thesis、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:
いくつかの組織名（属性値）に焦点を絞るための望ましい能力を提供するには、さまざまなメリット/中傷を持つ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を構築して、WDSPに2つのクエリを送信します。2番目は最初と同じであり、「O」を含むクエリ全体がヒットにならない場合のみCNフィルターがあります（つまり、サポートされていないように見える場合は、組織フィルタリングからバックオフ）。
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クライアントはエントリのDNをホストとポートとともにDAGシステムに使用します。それは、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.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。