Network Working Group J. Allen
Request for Comments: 2651 WebTV Networks
Category: Standards Track M. Mealling
Network Solutions, Inc.
August 1999
The Architecture of the Common Indexing Protocol (CIP)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
The Common Indexing Protocol (CIP) is used to pass indexing information from server to server in order to facilitate query routing. Query routing is the process of redirecting and replicating queries through a distributed database system towards servers holding the desired results. This document describes the CIP framework, including its architecture and the protocol specifics of exchanging indices.
一般的なインデックスプロトコル（CIP）は、クエリのルーティングを容易にするためにサーバにサーバからインデックス情報を渡すために使用されます。クエリルーティングは、所望の結果を保持しているサーバに向けて分散データベースシステムを介してクエリーをリダイレクトし、複製するプロセスです。この文書では、そのアーキテクチャとインデックスを交換するプロトコル仕様を含む、CIPのフレームワークを記述する。
The Common Indexing Protocol (CIP) is an evolution and refinement of distributed indexing concepts first introduced in the Whois++ Directory Service [RFC1913, RFC1914]. While indexing proved useful in that system to promote query routing, the centroid index object which is passed among Whois++ servers is specifically designed for template-based databases searchable by token-based matching. With alternative index objects, the index-passing technology will prove useful to many more application domains, not simply Directory Services and those applications which can be cast into the form of template collections.
一般的なインデックスプロトコル（CIP）は、最初のWhois ++ディレクトリサービス[RFC1913、RFC1914]で導入された分散インデックスの概念の進化と改良したものです。インデックスがクエリのルーティングを促進するために、そのシステムに有用であることが分かっている間、Whoisの++サーバ間で渡される重心インデックスオブジェクトは、特にトークンベースのマッチングにより検索可能なテンプレートベースのデータベースのために設計されています。代替索引オブジェクトを使用すると、インデックス・パッシング技術は、より多くのアプリケーションドメインではなく、単純にディレクトリサービスとテンプレートのコレクションの形にキャストすることができ、それらのアプリケーションに有用であることが分かるだろう。
The indexing part of Whois++ is integrated with the data access protocol. The goal in designing CIP is to extract the indexing portion of Whois++, while abstracting the index objects to apply more broadly to information retrieval. In addition, another kind of technology reuse has been undertaken by converting the ad-hoc data representations used by Whois++ into structures based on the MIME specification for structured Internet mail.
Whoisの++のインデックス部分はデータアクセスプロトコルに統合されています。 CIP設計の目標は、情報検索に、より広く適用するインデックスオブジェクトを抽象化しながら、フーイズ++の割出し部分を抽出することです。また、技術の再利用の別の種類は、構造化されたインターネットメールのMIMEの仕様に基づいた構造にWhoisの++が使用するアドホックなデータ表現を変換することによって行われています。
Whois++ used a version number field in centroid objects to facilitate future growth. The initial version was "1". Version 1 of CIP (then embedded in Whois++, and not referred to separately as CIP) had support for only ISO-8895-1 characters, and for only the centroid index object type.
Whois ++は、将来の成長を促進するために、重心オブジェクトにバージョン番号フィールドを使用していました。最初のバージョンは「1」でした。 CIPのバージョン1はISO-8895から1文字のサポートを持っていた、とだけ重心インデックスオブジェクトタイプのために（そして、別途CIPと呼ばないのWhois ++に埋め込まれ、かつ）。
Version 2 of the Whois++ centroid was used in the Digger software by Bunyip Information Systems to notify recipients that the centroid carried extra character set information. Digger's centroids can carry UTF-8 encoded 16-bit Unicode characters, or ISO-8859-1 characters, determined by a field in the headers.
Whoisの++重心のバージョン2は、重心は、余分な文字が情報を設定し実施することを受信者に通知するためにバニップ情報システムによってディガーソフトウェアで使用されました。ディガーの重心は、ヘッダー内のフィールドによって決定UTF-8でエンコード16ビットUnicode文字、またはISO-8859-1文字を、運ぶことができます。
This specification is for CIP version 3. Version 3 is a major overhaul to the protocol. However, by using of a short negotiation sequence, CIP version 3 servers can interoperate with earlier servers in an index-passing mesh.
この仕様は、プロトコルへの主要なオーバーホールであるCIPバージョンの3バージョン3です。しかし、短い交渉配列から使用することにより、CIPバージョン3のサーバーは、インデックス・パッシングメッシュで以前のサーバーと相互運用することができます。
For unclear terms the reader is referred to the glossary in Appendix A.
不明確な用語については、読者は、付録Aの用語集を参照します
CIP facilitates query routing. CIP is a protocol used between servers in a network to pass hints which make data access by clients at a later date more efficient. Query routing is the act of redirecting and replicating queries through a distributed database system towards the servers holding the actual results via reference to indexing information.
CIPは、クエリのルーティングを容易にします。 CIPは、より効率的な後日クライアントによるデータアクセスを作るヒントを渡すために、ネットワーク内のサーバー間で使用されるプロトコルです。クエリルーティングは、インデックス情報の参照を介して実際の結果を保持するサーバに向けて分散データベースシステムを介してクエリーをリダイレクトし、複製する行為です。
CIP is a "backend" protocol -- it is implemented in and "spoken" only among network servers. These same servers must also speak some kind of data access protocol to communicate with clients. During query resolution in the native protocol implementation, the server will refer to the indexing information collected by the CIP implementation for guidance on how to route the query.
CIPは、「バックエンド」プロトコルである - それはで実装し、専用のネットワークサーバー間で「話」されます。これらの同じサーバは、クライアントと通信するためのデータ・アクセス・プロトコルのいくつかの種類を話さなければなりません。ネイティブプロトコル実装におけるクエリの解決中に、サーバがどのようにルーティングクエリに指導のためのCIP実装によって収集したインデックス情報を参照します。
Data access protocols used with CIP must have some provision for control information in the form of a referral. The syntax and semantics of these referrals are outside the scope of this specification.
CIPで使用するデータ・アクセス・プロトコルは、紹介の形で制御情報のためのいくつかの規定を持っている必要があります。これらの紹介の構文と意味はこの仕様の範囲外です。
This document is one of three documents. This document describes the fundamental concepts and framework of CIP.
この文書では、3つの文書の一つです。このドキュメントでは、基本的な概念とCIPの枠組みを説明しています。
The document "MIME Object Definitions for the Common Indexing Protocol" [CIP-MIME] describes the MIME objects that make up the items that are passed by the transport system.
文書「共通インデックスプロトコルのためのMIMEオブジェクト定義」[CIP-MIME]は輸送システムによって渡される項目を構成するMIMEオブジェクトについて説明します。
Requirements and examples of several transport systems are specified in the "CIP Transport Protocols" [CIP-TRANSPORT] document.
いくつかの輸送システムの要件および例は、「CIPトランスポートプロトコル」[CIP-TRANSPORT]文書で指定されています。
A second set of document describe the various specifications for specific index types.
文書の第2のセットは、特定のインデックス・タイプのためのさまざまな仕様を記述します。
In order to better understand how CIP fits into the information retrieval world, we need to first understand the unifying abstract features of existing information retrieval technology. Next, we discuss why adding indexing technology to this model results in a system capable of query routing, and why query routing is useful.
より良いCIPは、情報検索の世界にどのように適合するかを理解するためには、まず既存の情報検索技術の統一抽象的な特徴を理解する必要があります。クエリのルーティングが可能なシステムで、このモデルの結果にインデックス技術を追加する理由次に、我々は議論し、なぜクエリルーティングは便利です。
An abstract view of the client/server data retrieval process includes data sets and data access protocols. An individual server is responsible for handling queries over a fixed domain of data. For the purposes of CIP, we call this domain of data the dataset. Clients make searches in the dataset and retrieve parts of it via a data access protocol. There are many data access protocols, each optimized for the data in question. For instance, LDAP and Whois++ are access protocols that reflect the needs of the directory services application domain. Other data access protocols include HTTP and Z39.50.
クライアント/サーバデータ検索処理の抽象ビューは、データセットとデータ・アクセス・プロトコルを含んでいます。個々のサーバは、データの固定ドメイン上のクエリを処理する責任を負っています。 CIPの目的のために、我々は、データセットのデータのこのドメインを呼び出します。クライアントは、データセット内の検索を行い、データ・アクセス・プロトコルを介してその一部を取得します。多くのデータ・アクセス・プロトコル、問題のデータ用に最適化され、それぞれがあります。たとえば、LDAPとのWhois ++は、ディレクトリサービスのアプリケーションドメインのニーズを反映アクセスプロトコルです。他のデータ・アクセス・プロトコルはHTTPとZ39.50が含まれます。
The above description reflects a world without indexing, where no server knows about any other server. In some cases (as with X.500 referrals, and HTTP redirects) a server will, as part of its reply, implicate another server in the process of resolving the query. However, those servers generate replies based solely on their local knowledge. When indexing information is introduced into a server's local database, the server now knows not only answers based on the local dataset, but also answers based on external indices. These indices come from peer servers, via an indexing protocol. CIP is one such indexing protocol.
上記の説明には、サーバが他のサーバについて知っていないインデックスのない世界を、反映しています。 （X.500の紹介、およびHTTPリダイレクトのように）いくつかのケースでは、サーバは、その応答の一部として、クエリを解決するプロセス内の別のサーバを巻き込むであろう。しかし、これらのサーバーは、ローカルの知識のみに基づいて応答を生成します。インデクシング情報は、サーバのローカルデータベースに導入されると、サーバーは、今ではない外部の指標に基づいて、ローカルのデータセットに基づいて解答するだけでなく、答えを知っています。これらのインデックスは、インデックスのプロトコルを介して、ピア・サーバーから来ます。 CIPは、そのようなインデックスプロトコルです。
Replies based on index information may not be the complete answer. After all, an index is not a replicated version of the remote dataset, but a possibly reduced version of it. Thus, in addition to giving complete replies from the local dataset, the server may give referrals to other datasets. These referrals are the core feature necessary for effective query routing. When servers use CIP to pass indices from server to server, they make a kind of investment. At the cost of some resources to create, transmit and store the indices, query routing becomes possible.
インデックス情報に基づいて回答は完全な答えではないかもしれません。すべての後、インデックスは、リモートデータセットの複製されたバージョンが、それの可能性の縮小版ではありません。このように、ローカルデータセットから完全な回答を与えることに加えて、サーバは、他のデータセットへの紹介を与える可能性があります。これらの紹介は、効果的なクエリルーティングのために必要なコア機能です。サーバは、サーバからサーバにインデックスを渡すためにCIPを使用すると、彼らは投資のようなものを作ります。いくつかのリソースのコスト指標を送信して保存、作成するには、クエリのルーティングが可能となります。
Query Routing is the process of replicating and moving a query closer to datasets which can satisfy the query. In some distributed systems, widely distributed searches must be accomplished by replicating the query to all sub-datasets. This approach can be wasteful of resources both in the network, and on the servers, and is thus sometimes explicitly disabled. Using indexing in such a system opens the door to more efficient distributed searching.
クエリーのルーティングは、クエリを満たすことができるデータセットに近いクエリを複製し、移動するプロセスです。一部の分散システムでは、広く分布している検索は、すべてのサブデータセットにクエリーを複製することによって達成されなければなりません。このアプローチは、ネットワーク内、およびサーバーの両方のリソースを無駄にすること、そして時にはので、明示的に無効であることができます。このようなシステムでは、インデックスを使用することで、より効率的な分散検索への扉を開きます。
While CIP-equipped servers provide the referrals necessary to make query routing work, it is always the client's responsibility to collate, filter, and chase the referrals it receives. This gives the end-user (or agent, in the case that there's no human user involved in the search) greatest control over the query resolution process. The cost of the added client complexity is weighed against the benefits of total control over query resolution. In some cases, it may also be possible to decouple the referral chasing from the client by introducing a proxy, allowing existing simple clients to make use of query routing. Such a proxy would transparently resolve referrals into concrete results before returning them to the simple-minded client.
CIP-装備したサーバは、クエリルーティングを動作させるために必要な紹介を提供しているが、常に、フィルタを照合し、それが受け取る紹介を追跡するためのクライアントの責任です。これは、（検索に関わる人間のユーザ決してありませんした場合には、またはエージェント）クエリの解決プロセスを超える最大のコントロールをエンドユーザーに提供します。追加クライアントの複雑さのコストは、クエリの解決を完全にコントロールの利点と比較検討しています。いくつかのケースでは、また、既存の単純なクライアントは、クエリのルーティングを使用するようにできるように、プロキシを導入することにより、クライアントから追いかけ紹介を分離することが可能です。このようなプロキシは透過的にシンプル志向クライアントに戻す前に、具体的な結果に紹介を解決します。
As useful as indices seem, the fact remains that not all queries can benefit from the same type of index. For example, say the index consists of a simple list of keywords. With such an index, it is impossible to answer queries about whether two keywords were near one another, or if a keyword was present in a certain context (for instance, in the title).
インデックスは思えとして有用であるとして、事実はない、すべてのクエリがインデックスの同じタイプの恩恵を受けることができることに変わりはありません。たとえば、インデックスは、キーワードの単純なリストで構成されて言います。このようなインデックスを使用すると、二つのキーワードが互いの近くだったかどうか、またはキーワードは、（例えば、タイトルに）特定のコンテキスト内に存在した場合についての問い合わせに応答することは不可能です。
Because of the need for application domain specific indices, CIP index objects are abstract; they must be defined by a separate specification. The basic protocols for moving index objects are widely applicable, but the specific design of the index, and the structure of the mesh of servers which pass a particular type of index is dependent on the application domain. This document describes only the protocols for moving indices among servers. Companion documents describe initial index objects.
そのため、アプリケーションドメイン固有の指標を必要とするため、CIPインデックスオブジェクトは抽象的です。彼らは別の仕様で定義されなければなりません。インデックスオブジェクトを移動するための基本的なプロトコルが広く適用されているが、インデックス、およびインデックスの特定の型を渡すサーバのメッシュ構造の特定の設計は、アプリケーションドメインに依存しています。この文書では、サーバー間でインデックスを移動するための唯一のプロトコルについて説明します。コンパニオン文書は、最初のインデックスオブジェクトを記述する。
The requirements that index type specifications must address are specified in the [CIP-MIME] document.
インデックス型の仕様が対処しなければならない要件は[CIP-MIME]ドキュメントで指定されています。
CIP implements index passing, providing the forward knowledge necessary to generate the referrals used for query routing. The core of the protocol is the index object. In the following sections, the structure of the index objects themselves is presented. Next, how and why indices are passed from server to server is discussed. Finally, the circumstances under which a server may synthesize an index object based on incoming ones are discussed.
CIPは、クエリのルーティングに使用される参照を生成するために必要なフォワード知識を提供し、インデックス通過を実現します。プロトコルのコアは、インデックスオブジェクトです。次のセクションでは、インデックスの構造自体が提示されるオブジェクト。次に、どのように、なぜインデックスは、サーバからサーバに渡されることは議論されています。最後に、サーバは、着信ものに基づくインデックスオブジェクトを合成することができるれる状況が考察されています。
A CIP index object is composed of two parts, the header and the payload. The header contains metadata necessary to process and make use of the index object being transmitted. The actual index resides in the payload.
CIPインデックスオブジェクトは、2つの部分、ヘッダとペイロードから構成されています。ヘッダは、プロセスと送信され、インデックスオブジェクトを利用するために必要なメタデータを含みます。実際の指数は、ペイロードに存在します。
Three particular headers warrant specific mention at this point. The "type" of the index object selects one of many distinct CIP index object specifications which define exactly how the index blocks are to be created, parsed and used to facilitate query routing. Another header of note is the "DSI", or Dataset Identifier, which uniquely identifies the dataset from which the index was created. Another header that is crucial for generating referrals is the "Base-URI". The URI (or URI's) contained in this header form the basis of any referrals generated based on this index block. The URI is also used as input during the index aggregation process to constrain the kinds of aggregation possible, due to multiprotocol constraints. How that URI is used is defined by the aggregation algorithm. The exact syntax of these headers is specified in the CIP MIME specification document [CIP-MIME].
三の特定のヘッダは、この時点では特に言及に値します。インデックスオブジェクトの「タイプ」は、インデックス・ブロックは、作成され解析されたクエリのルーティングを容易にするために使用される正確にどのように定義する多くの異なるCIPインデックスオブジェクト仕様の1つを選択します。音符の別のヘッダは、一意のインデックスが作成されたデータセットを識別する「DSI」、またはデータセット識別子です。リフェラルを発生させるために重要である別のヘッダは、「ベース-URI」です。このヘッダに含まれるURI（またはURIの）は、このインデックス・ブロックに基づいて生成された照会の基礎を形成します。 URIはまた、マルチプロトコルの制約のために、可能な凝集の種類を制限するために、インデックス凝集プロセス中に入力として使用されます。どのようにURIが使用されていることは、集約アルゴリズムによって定義されます。これらのヘッダーの正確な構文は、CIP MIME仕様書[CIP-MIME]で指定されています。
The payload is opaque to CIP itself. It is defined exclusively by the index object specification associated with the object's MIME type. Specifications on how to parse and use the payload are published separately as "CIP index object specifications". This abstract definition of the index object forms the basis of CIP's applicability to indexing needs across multiple application domains.
ペイロードは、CIP自体に不透明です。これは、オブジェクトのMIMEタイプに関連付けられているインデックスオブジェクトの仕様によってのみ定義されます。解析し、ペイロードを使用する方法の仕様は、「CIPインデックスオブジェクト仕様」として別途公表されています。インデックスオブジェクトのこの抽象定義は、複数のアプリケーションドメイン間でインデックスのニーズにCIPの適用性の基礎を形成します。
A precise definition of the content and form of a CIP index block can be found in the Protocol document [CIP-MIME]
CIPインデックスブロックの内容と形式の正確な定義は、プロトコルドキュメント[CIP-MIME]に見出すことができます
Indices are transmitted among servers participating in a CIP mesh. By distributing this information in anticipation of a query, efficient, accurate query routing is possible at the time a query arrives.
インデックスは、CIPメッシュに参加するサーバー間で送信されます。クエリを見越してこの情報を配信することにより、効率的で、正確なクエリルーティングは、クエリが到着した時点で可能です。
A CIP mesh is a set of CIP servers which pass indices of the same type among themselves. Typically, a mesh is arranged in a hierarchical tree fashion, with servers nearer the root of the tree having larger and more comprehensive indices. See Figure 1. However, a CIP mesh is explicitly allowed to have lateral links in it, and there may be more than one part of the mesh that has the properties of a "root". Mesh administrators are encouraged to avoid loops in the system, but they are not obliged to maintain a strict tree structure. Clients wishing to completely resolve all referrals they receive should protect against referral loops while attempting to traverse the mesh to avoid wasting time and network resources. See the section on "Navigating the Mesh" for a discussion of this.
CIPメッシュは、それらの間で同じタイプのインデックスを渡すCIPサーバのセットです。典型的には、メッシュがより大きく、より包括的インデックスを有するツリーのルートに近いサーバと、階層ツリー状に配置されています。しかし、図1を参照してください、CIPメッシュは明示的に横のリンクを持つことが許可され、「根」の性質を有するメッシュの複数の部分があるかもしれません。メッシュ管理者は、システム内のループを回避することが奨励されているが、それらは、厳密なツリー構造を維持する義務はありません。時間とネットワーク資源の浪費を避けるために、メッシュを横断しようとしたときに完全に彼らが受け取るすべての参照を解決したいクライアントが紹介ループから保護すべきです。この議論については、「メッシュのナビゲート」のセクションを参照してください。
base level index index
directory servers servers
servers for for
base level lower-level
servers index servers
_______
| |
| A |__
|_______| \ _______
\---CIP----| |
_______ | D |__
| | /---CIP----|_______| \ ------
| B |__/ \--CIP------| |
|_______| | F |
/--CIP------|______|
/
_______ _______ /
| | | |-
| C |-------CIP----| E |
|_______| |_______|-
| \
r \
_______ e \ ______
| | f \--CIP-----| |
| G |-------CIP---------e------------------| H |
|_______| r |______|
\--referral---| r --referral-/
| a |
| |
| l |
| L |
\ 3 | 2 | 1
￥ ３ ｜ ２ ｜ １
\--------/
| |
｜ ｜
| client |
|クライアント|
| |
｜ ｜
--------
Figure 1: Sample layout of the Index Service mesh
図1：インデックスサービスのメッシュのサンプルレイアウト
All indices passed in a given mesh are assumed, as of this writing, to be of the same type (i.e. governed by the same CIP index object specification). It may be possible to create gateways between meshes carrying different index objects, but at this time that process is undefined and declared to be outside the scope of this specification.
所定のメッシュに通過したすべてのインデックス（すなわち、同じCIPインデックスオブジェクトの仕様によって決まる）と同じタイプであることが、これを書いているように、想定されます。異なるインデックスオブジェクトを搬送するメッシュとの間のゲートウェイを作成することも可能であるが、この時点で、そのプロセスは未定義、本明細書の範囲外であると宣言されます。
In the case where a CIP server receives an index of a type that it does not understand it _can_ pass that index forward untouched. In the case where a server implementation decides not to accept unknown indices it should return an appropriate error message to the server sending the index. This behavior is to allow mesh implementations to attempt heterogeneous meshes. As stated above heterogeneous meshes are considered to be ill defined and as such should be considered dangerous.
CIPサーバは、それがそのままそのインデックス往路_can_理解していないタイプのインデックスを受信した場合。サーバの実装は、未知のインデックスを受け入れる必要がないと判断した場合、それは、インデックスを送信するサーバに適切なエラーメッセージを返す必要があります。この動作は、メッシュの実装は、異種メッシュを試みることができるようにすることです。異種のメッシュ上に述べたように病気に定義されていると考えられるとのような危険な考慮すべきです。
Experience suggests that this index passing activity should take place among CIP servers as a parallel (and possibly lower-priority) job to their primary job of answering queries. Index objects travel among CIP servers by protocol exchanges explicitly defined in this document, not via the server's native protocol. This distinction is important, and bears repeating:
経験は、このインデックス通過活動がクエリに答えるの彼らの主な仕事と平行に（そしておそらく、優先度の低い）ジョブとしてCIPサーバ間で行われるべきであることを示唆しています。インデックスオブジェクトは、明示的ではない、サーバーのネイティブプロトコルを介して、この文書で定義されたプロトコル交換によってCIPサーバ間で移動します。この区別は重要であり、かつ繰り返しクマ：
Queries are answered (and referrals are sent) via the native data access protocol.
クエリは答えている（と紹介が送信されます）のネイティブデータアクセスプロトコルを介して。
Index objects are transferred via alternative means, as defined by this document.
この文書で定義されたインデックスのオブジェクトは、代替手段を介して転送されます。
When two servers cooperate to move indexing information, the pair are said to be in a "polling relationship". The server that holds the data of interest, and generates the index is called the "polled server". The other server, which is the one that collects the generated index, is the "polling server".
2台のサーバーがインデックス情報を移動するために協力すると、ペアは「ポーリングの関係」にあると言われています。興味のあるデータを保持し、インデックスを生成するサーバーは、「ポーリングサーバ」と呼ばれています。生成されたインデックスを集める一つであり、他のサーバーは、「ポーリングサーバ」です。
In a polling relationship, the polled server is responsible for notifying the polling server when it has a new index that the polling server might be interested in. In response, the polling server may immediately pick up the index object, or it may schedule a job to pick up a copy of the new index at a more convenient time. But, a polling server is not required to wait on the polled server to notify it of changes. The polling server can request a new index at any time.
ポーリングの関係では、ポーリングサーバは、ポーリングサーバが興味を持つかもしれない新しいインデックスを持っている場合、ポーリングサーバに通知する責任がある。それに応答して、ポーリングサーバは、すぐにインデックスオブジェクトを拾うことがあり、またはそれは、ジョブをスケジュールすることができますより便利な時に新しいインデックスのコピーをピックアップします。しかし、ポーリングサーバは、変更を、それを知らせるためにポーリングサーバ上で待機する必要はありません。ポーリングサーバは、いつでも新しいインデックスを要求することができます。
Independent of the symmetric polling relationship, there's another way that servers can pass indices using CIP. In an "index pushing" relationship, a CIP server simply sends the index to a peer whenever necessary, and allows the receiver to handle the index object as it chooses. The receiving server may refuse it, may accept it, then silently discard it, may accept only portions of it (by accepting it as is, then filtering it), or may accept it without question.
対称ポーリング関係の独立した、サーバはCIPを使用してインデックスを渡すことができます別の方法があります。 「インデックスプッシュ」関係で、CIPサーバは、単に、必要に応じてピアにインデックスを送信し、それが選択したように、受信機は、インデックスオブジェクトを処理することを可能にします。受信サーバは、次いで、静かに（あるとして、それを濾過、次いで、それを受け入れることにより）それの部分のみを受け入れることができる、または問題なしでそれを受け入れることができる、それを捨て、それを受け入れることができる、それを拒否することができます。
The index pushing relationship is intended for use by dumb leaf nodes which simply want to make their index available to the global mesh of servers, but have no interest in implementing the complete CIP transaction protocol. It lowers the barriers to entry for CIP leaf nodes. For more information on participating in a CIP mesh in this restricted manner, see the section below on "Protocol Conformance". CIP index passing operations take place across a reliable transport mechanisms, including both TCP connections, and Internet mail messages. The precise mechanisms are described in the Transport document [CIP-Transport].
インデックスプッシュ関係は、単にサーバのグローバルメッシュへのインデックスが利用できるようにしたいが、完全なCIPトランザクションプロトコルを実装するには関心を持っていないダムリーフノードが使用するためのものです。これは、CIPのリーフノードのための参入障壁を低下させます。 CIPは、この制限された方法で、メッシュに参加しての詳細については、「プロトコルコンフォーマンス」に、以下のセクションを参照してください。 CIPインデックス渡す操作は、TCP接続、およびインターネットメールメッセージの両方を含む、信頼性の高い輸送メカニズム全体に場所を取ります。正確なメカニズムは、トランスポート・ドキュメント[CIP-交通]に記載されています。
From the preceding discussion, it should be clear that indexing servers read and write index objects as they pass them around the mesh. However, a CIP server need not simply pass the in-bound indices through as the out-bound ones. While it is always permissible to pass an index object through to other servers, a server may choose to aggregate two or more of them, thereby reducing redundancy in the index, at the cost of longer referral chains.
前述の議論から、インデックスサーバーが読んで、彼らはメッシュの周りにそれらを渡すと、インデックスオブジェクトを作成することは明らかです。しかし、CIPサーバは、単純に結合するものなどを介して結合インデックスを渡す必要はありません。それは他のサーバに至るまで、インデックスオブジェクトを渡すことは常に許されますが、サーバが長い紹介チェーンのコストで、これにより、インデックスに冗長性を削減する、それらの2つ以上を集約することもできます。
A basic premise of index passing is that even while collapsing a body of data into an index by lossy compression methods, hints useful to routing queries will survive in the resulting index. Since the index is not a complete copy of the original dataset, it contains less information. Index objects can be passed along unchanged, but as more and more information collects in the resulting index object, redundancy will creep in again, and it may prove useful to apply the compression again, by aggregating two or more index objects into one.
インデックス通過の基本的な前提は、非可逆圧縮の方法によってインデックスにデータの本体を崩壊さえしながら、得られたインデックスに生き残るルーティングクエリに有用ヒントということです。インデックスは元のデータセットの完全なコピーではないので、それはあまり情報が含まれています。索引オブジェクトは変更されずに沿って通過することができるが、より多くの情報が得られた索引オブジェクトに集まるように、冗長性が再びクリープあろう、そしてそれは一つに二つ以上のインデックスオブジェクトを集約することにより、再び圧縮を適用することが有用であろう。
This kind of aggregation should be performed without compromising the ability to correctly route queries while avoiding excessive numbers of missed results. The acceptable likelihood of false negatives must be established on a per-application-domain basis, and is controlled by the granularity of the index and the aggregation rules defined for it by the particular specification.
凝集のこの種は逃した結果の過剰な数を回避しながら能力に正しくルーティングクエリを損なうことなく実行する必要があります。偽陰性の許容される可能性は、アプリケーションごとのドメインに基づいて確立されなければならない、特定の仕様で、定義された指標と集約ルールの粒度によって制御されます。
However, when CIP is used in a multi-protocol application domain, such as a Directory Service (with contenders including Whois++, LDAP, and Ph), things get significantly trickier. The fundamental problem is to avoid forcing a referral chain to pass through part of the mesh which does not support the protocol by which that client made the query. If this ever happens, the client loses access to any hits beyond that point in the referral chain, since it cannot resolve the referral in its native data access protocol. This is a failure of query routing, which should be avoided.
CIPは（Whoisの++、LDAP、およびpH値を含む候補と）、このようなディレクトリ・サービスとして、マルチプロトコルのアプリケーションドメインで使用されている場合しかし、物事はかなりトリッキー取得します。根本的な問題は、クライアントがクエリを作ったことでプロトコルをサポートしていないメッシュの一部を通過するように紹介チェーンを強制的に回避することです。これが今まで発生した場合、それがそのネイティブのデータ・アクセス・プロトコルで紹介を解決できないため、クライアントは、紹介チェーンにそのポイントを越えたヒットへのアクセスを失います。これは避けるべきでクエリルーティングの失敗、です。
In addition to multi-protocol considerations, server managers may choose not to allow index object aggregation for performance reasons. As referral chains lengthen, a client needs to perform more transactions to resolve a query. As the number of transactions increases, so do the user-perceived delays, the system loads, and the global bandwidth demands. In general, there's a tradeoff between aggressive aggregation (which leads to reductions in the indexing overhead) and aggressive referral chain optimization. This tradeoff, which is also sensitive to the particular application domain, needs to be explored more in actual operational situations.
マルチプロトコルの考慮に加えて、サーバ管理者は、パフォーマンス上の理由から、インデックスオブジェクトの集合を許可しないことを選んでもよいです。紹介鎖が長くように、クライアントは、クエリを解決するために、より多くのトランザクションを実行する必要があります。トランザクションの数が増加すると、そのユーザ知覚遅延、システム負荷、およびグローバルな帯域幅要求を行います。一般的には、（インデックスのオーバーヘッドの削減につながる）積極的な集約と積極的な紹介チェーンの最適化の間のトレードオフがあります。また、特定のアプリケーションドメインに敏感である。このトレードオフは、実際の運用状況でより探求する必要があります。
Conceptually, a CIP index server has several index objects on hand at any given time. If it holds data in addition to indexing information, the server has an index object formed from its own data, called the "local index". It may have one or more indices from remote servers which it has collected via the index passing mechanisms. These are called "in-bound indices".
概念的には、CIPインデックスサーバは、任意の時点で手元にいくつかのインデックスオブジェクトを持っています。それは情報をインデックスに加えて、データを保持している場合、サーバーは、独自のデータから形成されたインデックスオブジェクトを持って、「ローカル索引」と呼ばれます。それは、インデックス通過機構を介して収集されたリモートサーバから1つ以上のインデックスを有していてもよいです。これらは、「に結合指数」と呼ばれています。
Implementor's Note: It may not be necessary to keep all of these structures intact and distinct in the local database. It is also not required to keep the out-bound index (or indices) built and ready to distribute at all times. The previous paragraph merely introduces a useful model for expressing the aggregation rules. Implementors are free to model index objects internally however they see fit.
実装者注：これは、ローカルデータベース内にそのままと明確なこれらの構造のすべてを維持するために必要ではないかもしれません。また、構築され、すべての回で配布する準備ができて結合インデックス（またはインデックス）を維持するために必要とされていません。前の段落は、単に集計ルールを表現するための有用なモデルを紹介します。実装者は、彼らが合うしかし、内部的にインデックスオブジェクトをモデル化するのは自由です。
The following two rules control how a CIP server formulates its outgoing indices:
次の2つの規則は、CIPサーバが送信指標を策定方法を制御します。
1. An index server may pass any of the index objects in its local index and its in-bound indices through unchanged to polling servers.
1.インデックスサーバは、ポーリングサーバに変更せずにそのローカルインデックスとその中に結合インデックスにインデックスオブジェクトのいずれかを渡すことができます。
2. If and only if the following three conditions are true, an index server can aggregate two or more index objects into a single new index object, to be added to the set of out-bound indices.
2.以下の3つの条件が真である場合にのみ、インデックスサーバは、単一の新しい索引オブジェクトに二つ以上のインデックスオブジェクトを集約できる場合は、外結合インデックスの集合に追加されます。
a. Each index object to be aggregated covers exactly the same set of protocols, as defined by the scheme component of the Base-URI's in each index object.
A。各インデックスオブジェクト内のベースURIのスキームのコンポーネントによって定義されるように集約される各索引オブジェクトは、正確にプロトコルの同じセットをカバーします。
b. The index server supports every one of the data access protocols represented by the Base-URI's in the index objects to be aggregated.
B。インデックスサーバーは、ベースURIの索引オブジェクトに集約することがで表されるデータアクセスプロトコルの一人一人をサポートしています。
c. The specification for the index object type specified by the type header of the index objects explicitly defines the aggregation operation.
C。インデックスオブジェクトのタイプヘッダで指定されたインデックスのオブジェクトタイプの仕様は、明示的に集計演算を定義します。
The resulting index object must have Base-URI's characteristic of the local server for each protocol it supports. The outgoing objects should have the DSI of the local server.
結果のインデックスオブジェクトは、それがサポートするプロトコルごとにローカルサーバのベースURIの特性を持っている必要があります。送信オブジェクトは、ローカルサーバのDSIを持っている必要があります。
With the CIP infrastructure in place to manage index objects, the only problem remaining is how to successfully use the indexing information to do efficient searches. CIP facilitates query routing, which is essentially a client activity. A client connects to one server, which redirects the query to servers "closer to" the answer. This redirection message is called a referral.
インデックスオブジェクトを管理するための場所でのCIPインフラストラクチャを使用すると、残りの唯一の問題は、成功した効率的な検索を行うには、インデックス情報を使用する方法です。 CIPは、基本的にクライアントアクティビティでクエリルーティングを容易にします。クライアントは、サーバへのクエリ「に近い」答えをリダイレクトする一つのサーバに接続します。このリダイレクトメッセージは、紹介と呼ばれています。
The concept of a referral and the mechanism for deciding when they should be issued is described by CIP. However, the referral itself must be transferred to the client in the native protocol, so its syntax is not directly a CIP issue. The mechanism for deciding that a referral needs to be made and generating that referral resides in the CIP implementation in the server. The mechanism for sending the referral to the client resides in the server's native protocol implementation.
紹介の概念と、彼らが発行されるべきときを決定するためのメカニズムはCIPによって記述されています。その構文は直接CIPの問題ではありませんので、しかし、照会自体は、ネイティブプロトコルでクライアントに転送する必要があります。紹介が行われる必要があると判断し、その紹介を生成するためのメカニズムは、サーバ内のCIPの実装に存在します。クライアントへの紹介を送信するためのメカニズムは、サーバのネイティブプロトコルの実装に存在します。
A referral is made when a search against the index objects held by the server shows that there may be hits available in one of the datasets represented by those index objects. If more that one index object indicates that a referral must be generated to a given dataset, the server should generate only one referral to the given dataset, as the client may not be able to detect duplicates.
サーバの保持するインデックスオブジェクトに対する検索は、これらのインデックスオブジェクトによって表されるデータセットのいずれかで利用可能なヒットが存在し得ることを示しているときに紹介が行われます。つ以上のインデックスオブジェクトが参照が与えられたデータセットに生成されなければならないことを示している場合、クライアントは重複を検出することができないかもしれないと、サーバは、与えられたデータセットに一つだけの紹介を生成する必要があります。
Though the format of the referral is dependent on the native protocol(s) of the CIP server, the baseline contents of the referral are constant across all protocols. At the least, a DSI and a URI must be returned. The DSI is the DSI associated with the dataset which caused the hit. This must be presented to the client so that it can avoid referral loops. The Base-URI parameter which travels along with index objects is used to provide the other required part of a referral.
照会の形式は、CIPサーバのネイティブ・プロトコル（単数または複数）に依存するが、照会のベースラインの内容は、すべてのプロトコルにわたって一定です。少なくとも、DSIとURIを返却しなければなりません。 DSIは、ヒットを発生させたデータセットに関連付けられDSIです。それが紹介ループを避けることができるようにこれは、クライアントに提示する必要があります。インデックスオブジェクトと共に移動基地-URIパラメータは、照会の他の必要な部分を提供するために使用されます。
The additional information in the Base-URI may be necessary for the server receiving the referred query to correctly handle it. A good example of this is an LDAP server, which needs a base X.500 distinguished name from which to search. When an LDAP server sends a centroid-format index object up to a CIP indexing server, it sends a Base-URI along with the name of the X.500 subtree for which the index was made. When a referral is made, the Base-URI is passed back to the client so that it can pass it to the original LDAP server.
ベース-URIに追加情報は、それを正しく処理するために呼ばれたクエリを受信するサーバのために必要な場合があります。この良い例は、検索を開始するベースX.500識別名を必要とするLDAPサーバ、です。 LDAPサーバは、CIPインデックスサーバに重心形式のインデックスオブジェクトを送信するときに、インデックスが行われたためにX.500サブツリーの名前とともにベース-URIを送信します。紹介が行われたとき、それは、元のLDAPサーバーに渡すことができるように、基本-URIは、クライアントに戻されます。
As usual, in addition to sending the DSI, a DSI-Description header can be optionally sent. Because a client may attempt to check with the user before chasing the referral, and because this string is the friendliest representation of the DSI that CIP has to offer, it should be included in referrals when available (i.e. when it was sent along with the index object).
いつものように、DSIを送信することに加えて、DSI-説明ヘッダは、必要に応じて送信することができます。クライアントが紹介を追いかける前にユーザーに確認を試みる可能性があるので、この文字列はCIPを提供しているDSIの友好的な表現であるので、それを紹介に含まれるべきであるとき（利用可能すなわち、それは、インデックスと一緒に送られたとき、オブジェクト）。
Each data access protocol which uses CIP will need a clearly defined set of rules to map queries in the native protocol to searches against an index object. These rules will vary according to the data domain. In principle, this could create a bit of a scaling difficulty; for N protocols and M data domains, there would be N x M mappings required. In practice, this should not be the case, since some access protocols will be wholly unsuited to some data domains. Consider for example, a LDAP server trying to make a search in an index object composed from unorganized text based pages. What would the results be? How would the client make sense of the results?
CIPを使用して各データ・アクセス・プロトコルは、インデックスオブジェクトに対して検索にネイティブプロトコルでクエリをマッピングするためのルールの明確に定義されたセットが必要になります。これらのルールは、データドメインによって異なります。原則として、これはスケーリング難易度のビットを作成することができます。 NプロトコルおよびM個のデータドメインに対して、N X Mのマッピングが必要があるだろう。いくつかのアクセスプロトコルは、いくつかのデータ領域に完全に不向きとなりますので、実際には、これは、場合であってはなりません。例えば、未組織のテキストベースのページから成るインデックスオブジェクト内の検索をしようとしてLDAPサーバーを考えてみましょう。結果はどうでしょうか？どのようにクライアントが結果の意味をなすでしょうか？
However, as pre-existing protocols are connected to CIP, and as new ones are developed to work with CIP, this issue must be examined. In the case of Whois++ and the CENTROID index type, there is an extremely close mapping, since the two were designed together. When hooking LDAP to the CENTROID index type, it will be necessary to map the attribute names used in the LDAP system to attribute names which are already being used in the CENTROID mesh. It will also be necessary to tokenize the LDAP queries under the same rules as the CENTROID indexing policy, so that searches will take place correctly. These application- and protocol-specific actions must be specified in the index object specification, as discussed in the [CIP-MIME] document.
しかし、既存のプロトコルとしてCIPに接続されており、新しいものがCIPで動作するように開発されたとして、この問題を検討する必要があります。両者が一緒に設計されたので、フーイズの場合++重心インデックス型では、非常に近いマッピングがあります。 CENTROIDインデックス型にLDAPをフックすると、すでにCENTROIDメッシュに使用されている属性名をするためにLDAPシステムで使用される属性名をマッピングする必要があります。検索が正しく行われるように、また、重心インデックスポリシーと同じルールの下でLDAPクエリをトークン化することが必要になります。 [CIP-MIME]文書で説明したように、これらの用途向けプロトコル固有のアクションは、インデックスオブジェクトの仕様で指定されなければなりません。
From a client's point of view, CIP simply pushes all the "hard work" onto its shoulders. After all, it is the client which needs to track down the real data. While this is true, it is very misleading. Because the client has control over the query routing process, the client has significant control over the size of the result set, the speed with which the query progresses, and the depth of the search.
クライアントの観点からは、CIPは、単にその肩の上にすべての「ハードワーク」をプッシュします。結局のところ、それは本当のデータを追跡する必要があるクライアントです。これは事実ですが、それは非常に誤解を招きやすいです。クライアントは、クエリルーティングプロセスを制御しているので、クライアントは、結果セット、クエリが進行する速度、および検索の深さのサイズを大幅に制御しています。
The simplest client implementation provides referrals to the user in a raw, ready-to-reuse form, without attempting to follow them. For instance, one Whois++ client, which interacts with the user via a Web-based form, simply makes referrals into HTML hypertext links. Encoded in the link via the HTML forms interface GET encoding rules is the data of the referral: the hostname, port, and query. If a user chooses to follow the referral link, he executes a new search on the new host. A more savvy client might present the referrals to the user and ask which should be followed. And, assuming appropriate limits were placed on search time and bandwidth usage, it might be reasonable to program a client to follow all referrals automatically.
最も単純なクライアントの実装では、それらに従うことをしようとせず、生の、すぐに再利用の形でユーザーに紹介を提供します。たとえば、Webベースのフォームを介してユーザと対話する1つのWhois ++クライアントは、単にHTMLのハイパーテキストリンクに紹介します。 HTMLフォームインタフェースGETエンコーディング規則を経由してリンクで符号化された照会のデータである：ホスト名、ポート、およびクエリ。ユーザー参照リンクをたどることを選択した場合、彼は新しいホスト上で新しい検索を実行します。もっと精通したクライアントは、ユーザーへの紹介を提示し、従わなければならないどの頼むかもしれません。そして、適切な制限は、検索時間と帯域幅の使用状況に置かれたと仮定すると、自動的にすべての参照を追跡するために、クライアントをプログラムするのが妥当かもしれません。
When following all referrals, a client must show a bit of intelligence. Remember that the mesh is defined as an interconnected graph of CIP servers. This graph may have cycles, which could cause an infinite loop of referrals, wasting the servers' time and the client's too. When faced with the job of tacking down all referrals, a client must use some form of a mesh traversal algorithm. Such an algorithm has been documented for use with Whois++ in RFC-1914. The same algorithm can be easily used with this version of CIP. In Whois++ the equivalent of a DSI is called a handle. With this substitution, the Whois++ mesh traversal algorithm works unchanged with CIP.
すべての紹介を以下の場合は、クライアントは知性のビットを示さなければなりません。メッシュはCIPサーバの相互接続されたグラフのように定義されていることを覚えておいてください。このグラフは、サーバの時間を無駄に、紹介の無限ループを引き起こす可能性のサイクルを有していてもよいし、クライアントがあまりにもです。すべての紹介をダウンタックの仕事に直面したとき、クライアントは、メッシュトラバーサルアルゴリズムのいくつかのフォームを使用する必要があります。このようなアルゴリズムは、RFC-1914でのWhois ++で使用するために文書化されています。同じアルゴリズムを簡単にCIPのこのバージョンで使用することができます。 Whoisのでは++ DSIの同等は、ハンドルと呼ばれています。この置換によって、Whoisの++メッシュトラバーサルアルゴリズムは、CIPと変わらず動作します。
Finally, the mesh entry point (i.e. the first server queried) can have an impact on the success of the query. To avoid scaling issues, it is not acceptable to use a single "root" node, and force all clients to connect to it. Instead, clients should connect to a reasonably well connected (with respect to the CIP mesh, not the Internet infrastructure) local server. If no match can be made from this entry point, the client can expand the search by asking the original server who polls it. In general, those servers will have a better "vantage point" on the mesh, and will turn up answers that the initial search didn't. The mechanism for dynamically determining the mesh structure like this exists, but is not documented here for brevity. See RFC-1913 for more information on the POLLED-BY and POLLED-FOR commands.
最後に、メッシュ・エントリ・ポイント（すなわち、最初のサーバに照会）は、クエリの成功に影響を与えることができます。問題をスケーリング回避するためには、それに接続するために、単一の「ルート」ノードを使用し、すべてのクライアントを強制的に受け入れられません。代わりに、クライアントは、合理的にローカルサーバ（CIPメッシュではなく、インターネットインフラストラクチャに関して）接続に接続する必要があります。一致がこのエントリポイントから行うことができない場合、クライアントは誰ポーリングし、それを元のサーバーを尋ねることによって、検索を拡張することができます。一般的に、これらのサーバーは、メッシュ上の優れた「視点」を持つことになりますと、初期検索はしなかったという答えを上げます。動的にこのようなメッシュ構造を決定するためのメカニズムが存在しますが、簡潔にするためにここに記載されていません。ポーリング-BYの詳細については、RFC-1913を参照してくださいPOLLED-ためのコマンド。
It still should be noted that, while these mesh operations are important to optimizing the searches that a client should make, the client still speaks its native protocol. This information must be communicated to the client without causing the client to have to understand CIP.
まだこれらのメッシュの操作は、クライアントが行う必要があります検索を最適化するために重要であるが、クライアントはまだそのネイティブプロトコルを話すことに留意すべきです。この情報は、クライアントがCIPを理解する必要がありますさせることなく、クライアントに通知しなければなりません。
In this section, we discuss the security considerations necessary when making use of this specification. There are at least three levels at which security considerations come into play. Indexing information can leak undesirable amounts of proprietary information, unless carefully controlled. At a more fundamental level, the CIP protocol itself requires external security services to operate in a safe manner. Lastly, CIP itself can be used to propogate false information.
この仕様を利用する場合は、このセクションでは、必要なセキュリティの考慮事項について説明します。セキュリティ上の考慮事項が遊びに来た時に、少なくとも3つのレベルがあります。慎重に制御しない限り、インデックス情報は、専有情報の望ましくない量をリークすることができます。より基本的なレベルでは、CIPプロトコル自体は安全な方法で動作するように外部のセキュリティサービスを必要とします。最後に、CIP自体が虚偽の情報をpropogateするために使用することができます。
CIP is designed to index all kinds of data. Some of this data might be considered valuable, proprietary, or even highly sensitive by the data maintainer. Take, for example, a human resources database. Certain bits of data, in moderation, can be very helpful for a company to make public. However, the database in its entirety is a very valuable asset, which the company must protect. Much experience has been gained in the directory service community over the years as to how best to walk this fine line between completely revealing the database and making useful pieces of it available. There are also legal considerations regarding what data can be collected and shared.
CIPは、インデックスデータのすべての種類に設計されています。このデータの一部は、貴重なプロプライエタリ、またはデータのメンテナによっても、機密性の高いと考えられるかもしれません。例えば、人事データベースを取ります。データの特定のビットは、ほどほどに、公共作るために、会社のために非常に役立ちます。しかし、その全体のデータベースは、同社が保護しなければならない非常に貴重な資産です。多くの経験は完全にデータベースを明らかにし、それの有益な部分を利用可能にする間、この微妙な境界線を歩くする最善の方法に関して、長年にわたって、ディレクトリサービスのコミュニティで得られています。データを収集し、共有することができるかについての法的な考慮事項もあります。
Another example where security becomes a problem is for a data publisher who'd like to participate in a CIP mesh. The data that publisher creates and manages is the prime asset of the company. There is a financial incentive to participate in a CIP mesh, since exporting indices of the data will make it more likely that people will search your database. (Making profit off of the search activity is left as an exercise to the entrepreneur.) Once again, the index must be designed carefully to protect the database while providing a useful synopsis of the data.
セキュリティが問題となるもう一つの例は、CIPメッシュに参加したいデータの出版社のためです。出版社が作成して管理するデータは、同社の主要な資産です。データのエクスポート指標は、人々が自分のデータベースを検索れやすくなりますので、CIPメッシュに参加する金融インセンティブが、あります。 （検索活動のオフ作る利益は起業家への課題として残されている。）もう一度、インデックスは、データの便利な概要を提供しながら、データベースを保護するために慎重に設計する必要があります。
One of the basic premises of CIP is that data providers will be willing to provide indices of their data to peer indexing servers. Unless they are carefully constructed, these indices could constitute a threat to the security of the database. Thus, security of the data must be a prime consideration when developing a new index object type. The risk of reverse engineering a database based only on the index exported from it must be kept to a level consistent with the value of the data and the need for fine-grained indexing.
CIPの基本的な前提の一つは、データプロバイダは、インデックスサーバをピアに自分のデータのインデックスを提供することをいとわないだろうということです。彼らは慎重に構築されていない限り、これらのインデックスは、データベースのセキュリティに対する脅威を構成することができます。新しいインデックスオブジェクトタイプを開発する際にこのように、データのセキュリティはプライム考慮しなければなりません。リバースエンジニアリングのリスクはそれだけからエクスポートされたインデックスに基づいて、データベースは、データの値とファイングレインインデックスの必要性と一貫性のレベルに維持されなければなりません。
Lastly, mesh organizers should be aware that the insertion of false data into a mesh can be used as part of an attack. Depending on the type of mesh and aggregation algorithms, an index can selectivly prune parts of a mesh. Also, since CIP is used to discover information, it will be the target for the advertisement of false information. CIP does not provide a method for trusting the data that it contains.
最後に、メッシュの主催者はメッシュに虚偽のデータの挿入が攻撃の一部として使用できることに注意する必要があります。メッシュ凝集アルゴリズムのタイプに応じて、インデックスは、メッシュのプルーン部分をselectivlyことができます。 CIPは、情報を発見するために使用されるので、それは虚偽の情報を広告のターゲットになります。 CIPは、それが含まれているデータを信頼するための方法を提供していません。
Acknowledgments
謝辞
Thanks to the many helpful members of the FIND working group for discussions leading to this specification.
この仕様につながる議論のためのFINDワーキンググループの多くの有用なメンバーに感謝します。
Specific acknowledgment is given to Jeff Allen formerly of Bunyip Information Systems. His original version of these documents helped enormously in crystallizing the debate and consensus. Most of the actual text in this document was originally authored by Jeff. Jeff is no longer involved with the FIND Working Group or with editing this document. His authorship is preserved by a specific decision of the current editor.
具体的な確認は、以前バニップ情報システムのジェフ・アレンに与えられています。これらの文書の彼の元のバージョンは、議論とコンセンサスを結晶化に非常に役立ちました。この文書の実際のテキストのほとんどは、もともとジェフによって作成されました。ジェフはもはやFINDワーキンググループまたはこの文書を編集に関与していません。彼の著作は、現在のエディタの具体的な決定によって保存されます。
Authors' Addresses
著者のアドレス
Jeff R. Allen 246 Hawthorne St. Palo Alto, CA 94301
ジェフ・R.アレン246ホーソーンセントパロアルト、CA 94301
EMail: jeff.allen@acm.org
メールアドレス：jeff.allen@acm.org
Michael Mealling Network Solutions, Inc. 505 Huntmar Park Drive Herndon, VA 22070
マイケル・メオーリングネットワークソリューション株式会社505 Huntmarパークドライブハーンドン、VA 22070
Phone: (703) 742-0400 EMail: michael.mealling@RWhois.net
電話：（703）742-0400 Eメール：michael.mealling@RWhois.net
References
リファレンス
[RFC1913] Weider, C., Fullton, J. and S. Spero, "Architecture of the Whois++Index Service", RFC 1913, February 1996.
[RFC1913]ウイダー、C.、Fullton、J.とS.スペロ、 "Whoisの建築++インデックスサービス"、RFC 1913、1996年2月。
[RFC1914] Faltstrom, P., Schoultz, R. and C. Weider, "How to Interact with a Whois++ Mesh", RFC 1914, February 1996.
[RFC1914] Faltstrom、P.、Schoultz、R.とC.ウイダー、1996年2月、RFC 1914 "のWhois ++メッシュと対話する方法" を参照してください。
[CIP-MIME] Allen, J. and M. Mealling, "MIME Object Definitions for the Common Indexing Protocol (CIP)", RFC 2652, August 1999.
[CIP-MIME]アレン、J.とM. Mealling、 "共通インデックスプロトコルのMIMEオブジェクト定義（CIP）"、RFC 2652、1999年8月。
[CIP-TRANSPORT] Allen, J. and P. Leach, "CIP Transport Protocols", RFC 2653, August 1999.
[CIP-TRANSPORT]アレン、J.とP.リーチ、 "CIPトランスポートプロトコル"、RFC 2653、1999年8月。
Appendix A: Glossary
付録A：用語集
application domain: A problem domain to which CIP is applied which has indexing requirements which are not subsumed by any existing problem domain. Separate application domains require separate index object specifications, and potentially separate CIP meshes. See index object specification.
アプリケーションドメイン：CIPは、既存の問題領域に包含されていないインデックスの要件を有している適用された問題領域。別のアプリケーションドメインは、別のインデックスオブジェクトの仕様、および潜在的に別々のCIPメッシュを必要としています。インデックスオブジェクトの仕様を参照してください。
centroid: An index object type used with Whois++. In CIP versions before version 3, the index was not extensible, and could only take the form of a centroid. A centroid is a list of (template name, attribute name, token) tuples with duplicate removed.
重心：Whoisの++を使用したインデックスのオブジェクトタイプ。バージョン3の前にCIPのバージョンでは、インデックスは拡張可能ではなかった、とだけ重心の形を取ることができます。重心はのリストです（テンプレート名、属性名、トークン）を取り出し、重複してタプル。
dataset: A collection of data (real or virtual) over which an index is created. When a CIP server aggregates two or more indices, the resultant index represents the index from a "virtual dataset", spanning the previous two datasets.
データセット：インデックスが作成された上で（実際または仮想の）データの収集。 CIPサーバが二つ以上の指標を集約すると、得られる指数は、前の2つのデータセットにまたがる、「仮想データセット」からインデックスを表します。
Dataset Identifier: An identifier chosen from any part of the ISO/CCITT OID space which uniquely identifies a given dataset among all datasets indexed by CIP.
データセット識別子：一意CIPによってインデックス付けすべてのデータセットのうち指定されたデータセットを識別するISO / CCITT OID空間の任意の部分から選択された識別子。
DSI: See Dataset Identifier.
DSI：データセット識別子を参照してください。
DSI-description: A human readable string optionally carried along with DSI's to make them more user-friendly. See dataset Identifier.
DSI-説明：必要に応じてそれらをよりユーザーフレンドリーにするためにDSIのと一緒に運ば人間が読める文字列。データセット識別子を参照してください。
index: A summary or compressed form of a body of data. Examples include a unique list of words, a codified full text analysis, a set of keywords, etc.
インデックス：要約またはデータの本体の圧縮形式。例としては、などの言葉のユニークなリスト、成文化されたフルテキスト分析、キーワードのセットを含み、
index object: The embodiment of the indices passed by CIP. An index object consists of some control attributes and an opaque payload.
インデックスオブジェクト：CIPによって渡されるインデックスの実施形態。インデックスオブジェクトは、いくつかのコントロールの属性と不透明なペイロードで構成されています。
index object specification: A document describing an index object type for use with the CIP system described in this document. See index object and payload.
索引オブジェクトの仕様：この文書に記載さCIPシステムと共に使用するためのインデックスオブジェクトのタイプを記述する文書。インデックスオブジェクトとペイロードを参照してください。
index pushing: The act of presenting, unsolicited, an index to a peer CIP server.
インデックスはプッシュ：提示する行為、迷惑、ピアCIPサーバへのインデックスを。
MIME: see Multipurpose Internet Mail Extensions
MIME：多目的インターネットメール拡張を参照してください
Multipurpose Internet Mail Extensions: A set of rules for encoding Internet Mail messages that gives them richer structure. CIP uses MIME rules to simplify object encoding issues. MIME is specified in RFC-1521 and RFC-1522.
多目的インターネットメール拡張：それらをより豊かな構造を与えるインターネットメールメッセージをエンコードするためのルールのセット。 CIPは、オブジェクトエンコードの問題を単純化するためにMIMEルールを使用しています。 MIMEは、RFC-1521およびRFC-1522に指定されています。
payload: The application domain specific indexing information stored inside an index object. The format of the payload is specified externally to this document, and depends on the type of the containing index object.
ペイロード：索引オブジェクト内に格納されたアプリケーションドメイン固有のインデックス情報。ペイロードの形式は、この文書の外部に指定され、含有率オブジェクトの種類に依存します。
polled server: A CIP server which receives a request to generate and pass an index to a peer server.
ポーリングサーバ：ピア・サーバーへのインデックスを生成して通過する要求を受け取るCIPサーバ。
polling server: A CIP server which generates a request to a peer server for its index.
ポーリング・サーバ：インデックスのピアサーバへの要求を生成CIPサーバ。
referral chain: The set of referrals generated by the process of routing a query. See query routing.
紹介チェーン：クエリをルーティングするプロセスによって生成された照会のセット。クエリルーティングを参照してください。
query routing: Based on reference to indexing information, redirecting and replicating queries through a distributed database system towards the servers holding the actual results.
クエリルーティング：実際の結果を保持するサーバに向けて分散データベースシステムを介してクエリーをリダイレクトし、複製、インデックス情報の参照に基づい。
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。