[要約] 要約：RFC 2651は、Common Indexing Protocol（CIP）のアーキテクチャについて説明しています。 目的：CIPの設計と実装に関するガイドラインを提供し、情報検索システムの相互運用性を向上させることを目指しています。
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)
共通インデックスプロトコル（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.
Copyright（c）The Internet Society（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サーバーに渡されるChentroid Indexオブジェクトは、トークンベースのマッチングによって検索可能なテンプレートベースのデータベース用に特別に設計されています。代替インデックスオブジェクトを使用すると、インデックスパステクノロジーは、単にディレクトリサービスやテンプレートコレクションの形にキャストできるアプリケーションではなく、より多くのアプリケーションドメインに役立ちます。
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を設計する際の目標は、WHOISのインデックス部分を抽出しながら、インデックスオブジェクトを抽象化して情報検索にもっと広く適用することです。さらに、WHOISが使用するアドホックデータ表現を構造化されたインターネットメールのMIME仕様に基づいて構造に変換することにより、別の種類のテクノロジーの再利用が行われています。
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は、Centroidオブジェクトのバージョン番号フィールドを使用して、将来の成長を促進しました。初期バージョンは「1」でした。CIPのバージョン1（その後、WHOISに埋め込まれ、CIPと個別に言及されていない）は、ISO-8895-1文字のみ、およびCentroid Indexオブジェクトタイプのみをサポートしていました。
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 Centroidのバージョン2は、DiggerソフトウェアでBunyIP Information Systemsによって使用され、Centroidが追加の文字セット情報を運んでいることを受信者に通知しました。Diggerの重心は、ヘッダーのフィールドによって決定されるUTF-8エンコード16ビットユニコード文字、または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 Transport Protocols」[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は、そのようなインデックスプロトコルの1つです。
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).
インデックスと同じように有用であるように、すべてのクエリが同じタイプのインデックスから利益を得ることができるわけではないという事実は残っています。たとえば、インデックスはキーワードの簡単なリストで構成されているとします。このようなインデックスを使用すると、2つのキーワードが互いに近くにあるかどうか、または特定のコンテキスト（たとえば、タイトルに）にキーワードが存在しているかどうかについてのクエリに答えることは不可能です。
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].
3つの特定のヘッダーは、この時点で特定の言及を保証します。インデックスオブジェクトの「タイプ」は、インデックスブロックの作成方法、解析、およびクエリルーティングを容易にするために使用する方法を正確に定義する多くの異なるCIPインデックスオブジェクト仕様の1つを選択します。もう1つのメモのヘッダーは、「DSI」またはデータセット識別子です。これは、インデックスが作成されたデータセットを一意に識別します。紹介を生成するために重要なもう1つのヘッダーは、「ベース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 |
|a |
| l |
|l |
\ 3 | 2 | 1
\ 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サーバーが理解できないタイプのインデックスを受信した場合、そのインデックスはそのインデックスが触れられていないことを渡します。サーバーの実装が不明なインデックスを受け入れないことを決定した場合、インデックスを送信するサーバーに適切なエラーメッセージを返す必要があります。この動作は、メッシュの実装が不均一なメッシュを試みることを可能にすることです。上記のように、異質なメッシュは病気であると見なされているため、危険と見なされるべきである。
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-Transport]で説明されています。
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.
インデックスの合格の基本的な前提は、損失のある圧縮方法によってデータのボディをインデックスに崩壊させたとしても、ルーティングクエリに役立つヒントが結果のインデックスで生き残ることです。インデックスは元のデータセットの完全なコピーではないため、情報が少なくなります。インデックスオブジェクトは変更されずに渡すことができますが、結果のインデックスオブジェクトでより多くの情報が収集されると、冗長性が再び忍び寄り、2つ以上のインデックスオブジェクトを1つに集約することで再び圧縮を適用することが有用であることが証明される場合があります。
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つの条件がtrueの場合にのみ、インデックスサーバーは2つ以上のインデックスオブジェクトを単一の新しいインデックスオブジェクトに集約して、アウトバウンドインデックスのセットに追加できます。
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は、基本的にクライアントアクティビティであるクエリルーティングを容易にします。クライアントが1つのサーバーに接続し、クエリを「近く」のサーバーにリダイレクトします。このリダイレクトメッセージは紹介と呼ばれます。
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.
サーバーが保持しているインデックスオブジェクトに対する検索が、それらのインデックスオブジェクトで表されるデータセットの1つで利用可能なヒットがある可能性があることを示している場合、紹介が行われます。1つのインデックスオブジェクトが特定のデータセットに紹介を生成する必要があることを示している場合、クライアントは複製を検出できない可能性があるため、サーバーは特定のデータセットへの1つの紹介のみを生成する必要があります。
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.
基本-RIの追加情報は、参照されたクエリを受信するサーバーが正しく処理するために必要になる場合があります。これの良い例は、検索するためにベースx.500の著名な名前が必要です。LDAPサーバーがCentroid-FormatインデックスオブジェクトをCIPインデックスサーバーに送信すると、インデックスが作成されたX.500サブツリーの名前とともにベースURIを送信します。紹介が行われると、Base-URIがクライアントに渡され、元のLDAPサーバーに渡すことができます。
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で作業するために新しいプロトコルが開発されるため、この問題を調べる必要があります。WhoisとCentroid Indexタイプの場合、2つが一緒に設計されているため、非常に近いマッピングがあります。LDAPをCentroidインデックスタイプに引いた場合、LDAPシステムで使用されている属性名をマッピングして、既にCentroidメッシュで使用されている属性名をマッピングする必要があります。また、検索が正しく行われるように、Centroidインデックス作成ポリシーと同じルールで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.
最もシンプルなクライアントの実装は、それらに従うことを試みることなく、生のすぐにリリースできる形式でユーザーへの紹介を提供します。たとえば、WHOISクライアントは、Webベースのフォームを介してユーザーと対話するだけで、HTML HyperTextリンクを紹介するだけです。HTMLフォームインターフェイスを介してリンクでエンコードされているエンコードルールの取得は、紹介のデータです。ホスト名、ポート、クエリです。ユーザーが紹介リンクに従うことを選択した場合、新しいホストで新しい検索を実行します。より精通したクライアントは、ユーザーへの紹介を提示し、どちらに従うべきかを尋ねるかもしれません。また、検索時間と帯域幅の使用に適切な制限が配置されていると仮定すると、すべての紹介に自動的に従うようにクライアントをプログラムすることが合理的かもしれません。
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メッシュに関して）ローカルサーバーに接続された適度に接続されている必要があります。このエントリポイントから一致することができない場合、クライアントは、それを投票する元のサーバーに尋ねることで検索を拡張できます。一般に、これらのサーバーはメッシュ上のより良い「見晴らしの良い点」を持ち、最初の検索ではなかった答えを上げます。このようなメッシュ構造を動的に決定するメカニズムは存在しますが、ここでは簡潔に文書化されていません。Polled-byおよびPolled-for Commandsの詳細については、RFC-1913を参照してください。
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自体を使用して誤った情報を提案できます。
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の基本的な前提の1つは、データプロバイダーがピアインデックスサーバーにデータのインデックスを提供することをいとわないことです。それらが慎重に構築されない限り、これらのインデックスはデータベースのセキュリティに対する脅威を構成する可能性があります。したがって、新しいインデックスオブジェクトタイプを開発する際には、データのセキュリティが主要な考慮事項でなければなりません。リバースエンジニアリングのリスクデータベースからのみに基づいて、それからエクスポートされたインデックスに基づいていることは、データの値と微調整されたインデックスの必要性と一致するレベルに保つ必要があります。
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.
最後に、メッシュの主催者は、メッシュに誤ったデータを挿入することが攻撃の一部として使用できることに注意する必要があります。メッシュのタイプと集約アルゴリズムに応じて、インデックスはメッシュの部分を選択的にプルンすることができます。また、CIPは情報を発見するために使用されるため、虚偽の情報の広告のターゲットになります。CIPは、含まれるデータを信頼する方法を提供しません。
Acknowledgments
謝辞
Thanks to the many helpful members of the FIND working group for discussions leading to this specification.
この仕様につながる議論のために、発見ワーキンググループの多くの役立つメンバーに感謝します。
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.
以前はBunyIP情報システムのジェフ・アレンに具体的な謝辞が与えられています。これらの文書の彼の元のバージョンは、議論とコンセンサスを結晶化するのに非常に役立ちました。このドキュメントの実際のテキストのほとんどは、もともとJeffが作成しました。ジェフは、検索ワーキンググループやこのドキュメントの編集に関与しなくなりました。彼の著者は、現在の編集者の特定の決定によって保存されています。
Authors' Addresses
著者のアドレス
Jeff R. Allen 246 Hawthorne St. Palo Alto, CA 94301
ジェフ・R・アレン246ホーソーンセントパロアルト、カリフォルニア94301
EMail: jeff.allen@acm.org
Michael Mealling Network Solutions, Inc. 505 Huntmar Park Drive Herndon, VA 22070
Michael Mealling Network Solutions、Inc。505 Huntmar Park Drive Herndon、VA 22070
Phone: (703) 742-0400 EMail: michael.mealling@RWhois.net
電話：（703）742-0400メール：Michael.mealling@rwhois.net
References
参考文献
[RFC1913] Weider, C., Fullton, J. and S. Spero, "Architecture of the Whois++Index Service", RFC 1913, February 1996.
[RFC1913] Weider、C.、Fullton、J。およびS. Spero、「Whois Index Serviceのアーキテクチャ」、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. Weider、「Whois Meshとの対話方法」、RFC 1914、1996年2月。
[CIP-MIME] Allen, J. and M. Mealling, "MIME Object Definitions for the Common Indexing Protocol (CIP)", RFC 2652, August 1999.
[CIP-MIME] Allen、J。およびM. Mealling、「共通インデックスプロトコル（CIP）のMIMEオブジェクト定義」、RFC 2652、1999年8月。
[CIP-TRANSPORT] Allen, J. and P. Leach, "CIP Transport Protocols", RFC 2653, August 1999.
[CIP-Transport] Allen、J。およびP. Leach、「CIP Transport Protocols」、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.
Centroid：WHOISで使用されるインデックスオブジェクトタイプ。バージョン3の前のCIPバージョンでは、インデックスは拡張できず、Chentroidの形をとることができました。Centroidは、削除された複製を備えた（テンプレート名、属性名、トークン、トークン）タプルのリストです。
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つ以上のインデックスを集約すると、結果のインデックスは、以前の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-説明：Optionalは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 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.
MIME：多目的インターネットメールエクステンション多目的インターネットメールエクステンション：より豊富な構造を提供するインターネットメールメッセージをエンコードするための一連のルールを参照してください。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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。