RFC2651 日本語訳
2651 The Architecture of the Common Indexing Protocol (CIP). J. Allen,M. Mealling. August 1999. (Format: TXT=41933 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Allen
Request for Comments: 2651 WebTV Networks
Category: Standards Track M. Mealling
Network Solutions, Inc.
August 1999
コメントを求めるワーキンググループJ.アレンの要求をネットワークでつないでください: 2651年のWebTV Networksカテゴリ: ネットワークソリューションズ社1999年8月に食事する標準化過程M.
The Architecture of the Common Indexing Protocol (CIP)
一般的なインデックスプロトコルのアーキテクチャ(CIP)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
Common Indexingプロトコル(CIP)は、質問ルーティングを容易にするためにサーバからサーバまで情報に索引をつけながら通るのに使用されます。 質問ルーティングは望み通りの成果を保持しながら分散データベースシステムを通してサーバに向かって質問を向け直して、模写するプロセスです。 このドキュメントはアーキテクチャとインデックスリストを交換するプロトコル詳細を含むCIPフレームワークについて説明します。
1. Introduction
1. 序論
1.1. History and Motivation
1.1. 歴史と動機
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.
Common Indexingプロトコル(CIP)は、概念が最初にWhois++ディレクトリサービス[RFC1913、RFC1914]で導入した分配されたインデックスの発展と気品です。 質問ルーティングを促進するためにそのシステムで役に立つと立証されて、索引をつけている間、Whois++サーバの中で渡される図心インデックスオブジェクトはトークンベースのマッチングで探せるテンプレートベースのデータベースのために明確に設計されています。 代替索引オブジェクトで、インデックスが一時的な技術はテンプレート収集のフォームに投げかけることができる単にディレクトリサービスにそれらのアプリケーションではなくずっと多くのアプリケーションドメインに有用であることが分かるでしょう。
Allen & Mealling Standards Track [Page 1] RFC 2651 The CIP Architecture August 1999
アレンとCIPアーキテクチャ1999年8月に標準化過程[1ページ]RFC2651を荒びきにすること。
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++のインデックス部分を抽出することです。 さらに、もう1種類の技術再利用は、+ 構造への+が構造化されたインターネット・メールのための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(次に、+ +の、そして、別々にCIPとして参照されなかったWhoisに埋め込まれている)のバージョン1には、ISO-8895-1キャラクタだけ、および図心インデックスオブジェクト・タイプだけのサポートがありました。
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はDiggerソフトウェアでBunyip情報システムによって使用されて、図心が付加的な文字集合情報を運んだことを受取人に通知しました。 坑夫の図心はコード化された16ビットのユニコード文字、またはISO-8859-1キャラクタの、そして、ヘッダーの分野のそばで断固としたUTF-8を運ぶことができます。
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.
不明瞭な用語について、読者はAppendix Aの用語集を参照されます。
1.2 CIP's place in the Information Retrieval world
1.2 情報Retrieval世界のCIPの場所
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と共に使用されるデータアクセス・プロトコルは紹介の形に制御情報への何らかの支給を持たなければなりません。 この仕様の範囲の外にこれらの紹介の構文と意味論があります。
Allen & Mealling Standards Track [Page 2] RFC 2651 The CIP Architecture August 1999
アレンとCIPアーキテクチャ1999年8月に標準化過程[2ページ]RFC2651を荒びきにすること。
2. Related Documents
2. 関連ドキュメント
This document is one of three documents. This document describes the fundamental concepts and framework of CIP.
このドキュメントは3通のドキュメントの1つです。 このドキュメントは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番目の1セットのドキュメントは特定のインデックスタイプのために様々な仕様を説明します。
3. Architecture
3. アーキテクチャ
3.1 CIP in the Information Retrieval World
3.1 情報検索世界のCIP
3.1.1 Information Retrieval in the Abstract
3.1.1 要約の情報検索
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を含んでいます。
3.1.2 Indexing Information Facilitates Query Routing
3.1.2 情報に索引をつけると、質問ルート設定は容易にされます。
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
上の記述が索引をつけることのないどんなサーバもサーバいかなる他のInに関するいくつかのケースも知らない世界を反映する、(X.500紹介、およびHTTP、向け直す、)、回答の一部として、質問を決議することの途中にサーバは別のサーバを含意するでしょう。 しかしながら、それらのサーバは唯一それらの局所的知識に基づく回答を生成します。 いつに関して、情報に索引をつけるのはサーバのローカルのデータベースに取り入れられて、サーバは、今、答えだけを基づかせたのを知らないか。
Allen & Mealling Standards Track [Page 3] RFC 2651 The CIP Architecture August 1999
アレンとCIPアーキテクチャ1999年8月に標準化過程[3ページ]RFC2651を荒びきにすること。
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.
しかし、ローカルのデータセット、外部のインデックスリストに基づく答えも。 これらのインデックスリストは同輩サーバからインデックスプロトコルで来ます。 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によって備えられているサーバは質問ルーティングを働かせるのに必要な紹介を提供しますが、いつもそれが受ける紹介を照合して、フィルターにかけて、追いかけるのは、クライアントの責任です。 これはエンドユーザ(エージェント、人間が全くいないで、ユーザは中で検索にかかわった)に質問解決プロセスの最も大きい支配力を与えます。 加えられたクライアントの複雑さの費用は質問解決の総コントロールの恩恵に比較考量されます。 また、いくつかの場合、プロキシを紹介することによってクライアントからの紹介追跡の衝撃を吸収するのも可能であるかもしれません、既存の純真なクライアントが質問ルーティングを利用するのを許容して。 純真なクライアントにそれらを返す前に、そのようなプロキシは透過的に紹介に具体的な結果に変えるでしょう。
3.1.3 Abstracting the CIP index object
3.1.3 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
アプリケーションのドメインの特定のインデックスリストの必要性のために、CIPインデックスオブジェクトは抽象的です。 別々の仕様でそれらを定義しなければなりません。 そしてインデックス物体を動かすための基本プロトコルが広く適切であり、唯一の詳細がインデックスのデザインである。
Allen & Mealling Standards Track [Page 4] RFC 2651 The CIP Architecture August 1999
アレンとCIPアーキテクチャ1999年8月に標準化過程[4ページ]RFC2651を荒びきにすること。
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.
特定のタイプのインデックスを通過するサーバのメッシュの構造はアプリケーションドメインに依存しています。 このドキュメントはサーバの中の感動的なインデックスリストのためにプロトコルだけについて説明します。 仲間ドキュメントは初期のインデックスオブジェクトについて説明します。
The requirements that index type specifications must address are specified in the [CIP-MIME] document.
インデックスタイプ仕様が扱わなければならない要件は[CIP-MIME]ドキュメントで指定されます。
3.2 Architectural Details
3.2 建築詳細
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はインデックス通過を実装します。 プロトコルのコアはインデックスオブジェクトです。 以下のセクションでは、インデックスオブジェクト自体の構造は提示されます。 次に、インデックスリスト変化されるどのように、理由に、サーバへのサーバについて議論するか。 最終的に、サーバが入って来るものに基づくインデックスオブジェクトを統合するかもしれない事情について議論します。
3.2.1 The CIP Index Object
3.2.1 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つを選択します。 注意の別のヘッダーは、"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の適用性の基礎を形成します。
Allen & Mealling Standards Track [Page 5] RFC 2651 The CIP Architecture August 1999
アレンとCIPアーキテクチャ1999年8月に標準化過程[5ページ]RFC2651を荒びきにすること。
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]
3.2.2 Moving Index Objects: How to Build a Mesh
3.2.2 動くインデックスオブジェクト: メッシュを組立てる方法
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メッシュは同じタイプのインデックスリストを自分たちに渡す1セットのCIPサーバです。 通常、メッシュは階層木ファッションでアレンジされます、より大きくて、より包括的なインデックスリストを持っている木のより多くの根におけるサーバで。 図1を参照してください。 しかしながら、CIPメッシュは「根」の特性を持っているメッシュの一部より明らかにあるかもしれない側部のリンクを持つことができます。 メッシュ管理者がシステムで輪を避けるよう奨励されますが、彼らが厳しい木構造を維持するのが強いられません。 時間とネットワーク資源を浪費するのを避けるためにメッシュを横断するのを試みている間、それらが受けるすべての紹介を完全に決議したがっているクライアントは紹介輪から守るべきです。 この議論のための「メッシュにナビゲートします」のセクションを見てください。
Allen & Mealling Standards Track [Page 6] RFC 2651 The CIP Architecture August 1999
アレンとCIPアーキテクチャ1999年8月に標準化過程[6ページ]RFC2651を荒びきにすること。
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|__ |_______| \ _______ \---CIP----| | _______ | D|__ | | /---CIP----|_______| \ ------ | B|__/、\--、CIP------| | |_______| | F| /--CIP------|______| / _______ _______ / | | | |- | C|-------CIP----| E| |_______| |_______|- | \r\_______ e\______ | | f\--CIP-----| | | G|-------CIP---------e------------------| H| |_______| r|______| \--紹介---| r--紹介/
| a |
| a|
| l |
| l|
\ 3 | 2 | 1
\ 3 | 2 | 1
\--------/
\--------/
| |
| |
| client |
| クライアント|
| |
| |
--------
--------
Figure 1: Sample layout of the Index Service mesh
図1: Index Serviceメッシュのサンプルレイアウト
Allen & Mealling Standards Track [Page 7] RFC 2651 The CIP Architecture August 1999
アレンとCIPアーキテクチャ1999年8月に標準化過程[7ページ]RFC2651を荒びきにすること。
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
左右対称の世論調査関係から独立していて、サーバがCIPを使用するインデックスリストを通過できる別の方法があります。 「インデックスの押す」関係では、CIPサーバは、必要であるときはいつも、単にインデックスを同輩に送って、受信機がそれとしてインデックスオブジェクトを扱うのを許容します。
Allen & Mealling Standards Track [Page 8] RFC 2651 The CIP Architecture August 1999
アレンとCIPアーキテクチャ1999年8月に標準化過程[8ページ]RFC2651を荒びきにすること。
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.
選びます。 次に、受信サーバは、それを拒否して、それを受け入れて、静かにそれを捨てるか、それ(それがそのままであると受け入れて、次に、それをフィルターにかけるのによる)の唯一の部分を受け入れるか、または確かにそれを受け入れるかもしれません。
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接続とインターネットメール・メッセージの両方を含む信頼できる移送機構の向こう側に行われます。 正確なメカニズムはTransportドキュメント[CIP-輸送]で説明されます。
3.2.3 Index Object Synthesis
3.2.3 インデックスオブジェクト統合
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.
非可逆圧縮メソッド(質問が結果として起こるインデックスで乗り切るルーティングの役に立つヒント)でデータのボディーをインデックスまで潰しさえする間、インデックス通過の根本的な前提はそれです。 インデックスが完全な謄本データセットでないので、それは、より少ない情報を含んでいます。 ますます多くの情報が結果として起こるインデックスオブジェクトに集まるとき、冗長は再びこっそり入るでしょう、そして、変わりがない状態でインデックスオブジェクトを回すことができますが、再び圧縮を適用するのが役に立つと判明するかもしれません、1つへの2個以上のインデックスオブジェクトに集めることによって。
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.
過度の数の逃された結果を避けている間に正しく質問を発送する能力に感染しないで、この種類の集合は実行されるべきです。 aでアプリケーションドメイン単位で有病誤診の許容できる見込みを確立しなければならない、基礎、それのために特記仕様書で定義されたインデックスと集合規則の粒状で、制御されます。
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
しかしながら、CIPがディレクトリサービスなどのマルチプロトコルアプリケーションドメインで使用されるとき(競争者がWhois++、LDAP、およびPhを入れていて)、いろいろなことはかなり扱いにくくなります。 基本的な問題は紹介チェーンにそのクライアントが質問をしたプロトコルをサポートしないメッシュの一部を通り抜けさせるのを避けることです。 これが起こるなら、クライアントはどんなヒットにもアクセスを失います。
Allen & Mealling Standards Track [Page 9] RFC 2651 The CIP Architecture August 1999
アレンとCIPアーキテクチャ1999年8月に標準化過程[9ページ]RFC2651を荒びきにすること。
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.
ネイティブのデータ・アクセスにおける紹介を決議できないので、紹介チェーンのそのポイントを超えたところまで、議定書を作ってください。 これは質問ルーティングの失敗です。(それは、避けられるべきです)。
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つの条件が本当である場合にだけ、インデックスサーバは、出かける行きのインデックスリストのセットに追加されるために単一の新しいインデックスオブジェクトへの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のものによって表された、集められたデータアクセス・プロトコルの皆をサポートします。
Allen & Mealling Standards Track [Page 10] RFC 2651 The CIP Architecture August 1999
アレンとCIPアーキテクチャ1999年8月に標準化過程[10ページ]RFC2651を荒びきにすること。
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があるはずです。
4. Navigating the mesh
4. メッシュにナビゲートします。
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つのサーバに接続する、「」 答えについて、より近く。 このリダイレクションメッセージは紹介と呼ばれます。
4.1 The Referral
4.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
基地URIにおける追加情報が正しくそれを扱うために参照された質問を受けるサーバに必要であるかもしれません。 この好例はLDAPサーバです。(そのサーバは探すベースX.500分類名を必要とします)。 LDAPサーバがaを送るとき
Allen & Mealling Standards Track [Page 11] RFC 2651 The CIP Architecture August 1999
アレンとCIPアーキテクチャ1999年8月に標準化過程[11ページ]RFC2651を荒びきにすること。
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.
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の最も好意的な説明であるので、利用可能であるときに(すなわち、いつインデックスオブジェクトと共にそれを送りましたか)、それは紹介に含まれるべきです。
4.2 Cross-protocol Mappings
4.2 交差しているプロトコルマッピング
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インデックスがタイプするWhoisの場合には、非常に近いマッピングがあります、2が一緒に設計されたので。 CENTROIDインデックスタイプにLDAPを接続するとき、CENTROIDメッシュで既に使用されている名前を結果と考えるのにLDAPシステムで使用される属性名を写像するのが必要でしょう。 また、CENTROIDインデックス方針と同じ規則の下でLDAP質問をtokenizeするのも必要でしょう、検索が正しく行われるように。 [CIP-MIME]ドキュメントで議論するようにインデックスオブジェクト仕様でこれらのアプリケーションとプロトコル特有の動作を指定しなければなりません。
4.3 Moving through the mesh
4.3 メッシュを通して移行すること。
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は肩にすべての「きつい仕事」を単に押します。 結局、それはクライアントです(本当のデータを捜し出す必要があります)。 これは本当ですが、それは非常に紛らわしいです。 クライアントが質問ルーティングプロセスを管理するので、クライアントには、結果セットのサイズ、質問が進歩をする速度、および検索の深さの重要なコントロールがあります。
Allen & Mealling Standards Track [Page 12] RFC 2651 The CIP Architecture August 1999
アレンとCIPアーキテクチャ1999年8月に標準化過程[12ページ]RFC2651を荒びきにすること。
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.
それらに続くのを試みない、最も簡単なクライアント実装は生の、そして、再利用するのにおいて準備ができるフォームでのユーザに紹介を提供します。 例えば、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サーバのインタコネクトされたグラフと定義されたのを覚えていてください。 このグラフには、サイクルがあるかもしれません、また、サーバの時間とクライアントのものを浪費して。(サイクルは紹介の無限ループを引き起こす場合がありました)。 すべての紹介を取り付ける仕事が直面されていると、クライアントはメッシュ縦断アルゴリズムの何らかのフォームを使用しなければなりません。 そのようなアルゴリズムは使用のためにWhois++でRFC-1914に記録されました。 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コマンドの詳しい情報に関して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を理解しなければならないことを引き起こさない、この情報をクライアントに伝えなければなりません。
Allen & Mealling Standards Track [Page 13] RFC 2651 The CIP Architecture August 1999
アレンとCIPアーキテクチャ1999年8月に標準化過程[13ページ]RFC2651を荒びきにすること。
5. Security Considerations
5. セキュリティ問題
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自身を使用できます。
5.1 Secure Indexing
5.1 安全なインデックス
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
最後に、メッシュオーガナイザーは攻撃の一部としてメッシュへの誤ったデータの挿入を使用できるのを意識しているべきです。 メッシュと集合アルゴリズムのタイプに頼っていて、インデックスはメッシュのプルーンの部分をselectivlyすることができます。 また、CIPは発見するのにおいて使用されています。
Allen & Mealling Standards Track [Page 14] RFC 2651 The CIP Architecture August 1999
アレンとCIPアーキテクチャ1999年8月に標準化過程[14ページ]RFC2651を荒びきにすること。
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はそれが含むデータを信じるためのメソッドを提供しません。
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.
特定の承認は以前、Bunyip情報システムをジェフ・アレンに与えます。彼のこれらのドキュメントのオリジナルバージョンは、討論とコンセンサスを結晶させるのを途方もないほど手伝いました。 実際のテキストの大部分は元々、ジェフによって本書では書かれました。 ジェフはもうFIND作業部会かこのドキュメントを編集するのにかかわりません。 彼の著述業は現在のエディタの特定の決定で保存されます。
Authors' Addresses
作者のアドレス
Jeff R. Allen 246 Hawthorne St. Palo Alto, CA 94301
聖パロアルト、ジェフ・R.アレン246・Hawthorneカリフォルニア 94301
EMail: jeff.allen@acm.org
メール: jeff.allen@acm.org
Michael Mealling Network Solutions, Inc. 505 Huntmar Park Drive Herndon, VA 22070
ネットワークソリューションズ社505Huntmar公園Driveハーンドン、ヴァージニア 22070を荒びきにするマイケル
Phone: (703) 742-0400 EMail: michael.mealling@RWhois.net
以下に電話をしてください。 (703) 742-0400 メールしてください: michael.mealling@RWhois.net
Allen & Mealling Standards Track [Page 15] RFC 2651 The CIP Architecture August 1999
アレンとCIPアーキテクチャ1999年8月に標準化過程[15ページ]RFC2651を荒びきにすること。
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++インデックスサービスのアーキテクチャ」、RFC1913、1996年2月。
[RFC1914] Faltstrom, P., Schoultz, R. and C. Weider, "How to
Interact with a Whois++ Mesh", RFC 1914, February
1996.
1996年2月の[RFC1914]FaltstromとP.とSchoultz、R.とC.ワイダー、「どうWhois++メッシュと対話する」RFC1914。
[CIP-MIME] Allen, J. and M. Mealling, "MIME Object Definitions
for the Common Indexing Protocol (CIP)", RFC 2652,
August 1999.
[CIP-MIME] アレンとJ.とM.食事、「一般的なインデックスプロトコル(CIP)のためのMIMEオブジェクト定義」、RFC2652、1999年8月。
[CIP-TRANSPORT] Allen, J. and P. Leach, "CIP Transport Protocols",
RFC 2653, August 1999.
[CIP-輸送] アレンとJ.とP.リーチ、「CIPトランスポート・プロトコル」、RFC2653、1999年8月。
Allen & Mealling Standards Track [Page 16] RFC 2651 The CIP Architecture August 1999
アレンとCIPアーキテクチャ1999年8月に標準化過程[16ページ]RFC2651を荒びきにすること。
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バージョンでは、インデックスは、広げることができないで、図心の形を取るだけであるかもしれません。 図心は写しがあるtuplesが取り除いた(テンプレート名、属性名、トークン)のリストです。
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.
データセット識別子: すべてのデータセットの中で唯一与えられたデータセットを特定するISO/CCITT OIDスペースのどんな地域からも選ばれた識別子はCIPで索引をつけました。
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のものと共に任意に運ばれました。 データセットIdentifierを見てください。
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.
以下に索引をつけてください。 データのボディーの概要か圧縮形。 例は単語のユニークなリスト、成文化された全文分析、1セットのキーワードなどを含んでいます。
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.
押すことに索引をつけてください: 提示の行為であり、求められていなくて、インデックスはaとしてじっと見ます。CIPサーバ。
MIME: see Multipurpose Internet Mail Extensions
MIME: マルチパーパスインターネットメールエクステンションを見てください。
Allen & Mealling Standards Track [Page 17] RFC 2651 The CIP Architecture August 1999
アレンとCIPアーキテクチャ1999年8月に標準化過程[17ページ]RFC2651を荒びきにすること。
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.
マルチパーパスインターネットメールエクステンション: インターネットメールメッセージをコード化するための、より豊かな構造をそれらに与える1セットの規則。 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.
ルーティングについて質問してください: 実際の結果を保持しながら、分散データベースシステムを通してサーバに向かって質問を情報に索引をつけることの参照に基づいて向け直して、模写します。
Allen & Mealling Standards Track [Page 18] RFC 2651 The CIP Architecture August 1999
アレンとCIPアーキテクチャ1999年8月に標準化過程[18ページ]RFC2651を荒びきにすること。
6. Full Copyright Statement
6. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Allen & Mealling Standards Track [Page 19]
アレンと標準化過程を荒びきにすること。[19ページ]
一覧
スポンサーリンク
