[要約] RFC 2654は、Common Indexing Protocolで使用するためのタグ付きインデックスオブジェクトに関する要約と目的を提供しています。
Network Working Group R. Hedberg
Request for Comments: 2654 Catalogix
Category: Experimental B. Greenblatt
Directory Tools and Application Services, Inc.
R. Moats
AT&T
M. Wahl
Innosoft International, Inc.
August 1999
A Tagged Index Object for use in the Common Indexing Protocol
一般的なインデックス作成プロトコルで使用するタグ付きインデックスオブジェクト
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
Abstract
概要
This document defines a mechanism by which information servers can exchange indices of information from their databases by making use of the Common Indexing Protocol (CIP). This document defines the structure of the index information being exchanged, as well as the appropriate meanings for the headers that are defined in the Common Indexing Protocol. It is assumed that the structures defined here can be used by X.500 DSAs, LDAP servers, Whois++ servers, CSO Ph servers and many others.
このドキュメントでは、情報サーバーが一般的なインデックス作成プロトコル（CIP）を利用してデータベースから情報のインデックスを交換できるメカニズムを定義します。このドキュメントでは、交換されるインデックス情報の構造と、共通のインデックスプロトコルで定義されているヘッダーの適切な意味を定義します。ここで定義されている構造は、X.500 DSA、LDAPサーバー、WHOISサーバー、CSO PHサーバーなどで使用できると想定されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. The Tagged Index Object . . . . . . . . . . . . . . . . . . . . 5
4.1. The Agreement . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Content Type . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 Tagged Index BNF . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Header Descriptions . . . . . . . . . . . . . . . . . . . .10
4.3.2. Tokenization types . . . . . . . . . . . . . . . . . . . .11
4.3.3. Tag Conventions . . . . . . . . . . . . . . . . . . . . . .11
4.4. Incremental Indexing . . . . . . . . . . . . . . . . . . . .12
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .13
5.1 The original database . . . . . . . . . . . . . . . . . . . .13
5.1.1 "complete" consistency based full update . . . . . . . . . .14
5.1.2 "tag" consistency based full update . . . . . . . . . . . .14
5.1.3 "unique" consistency based full update . . . . . . . . . . .15
5.2 First update . . . . . . . . . . . . . . . . . . . . . . . . .16
5.2.1 "complete" consistency based incremental update . . . . . .16
5.2.2 "tag" consistency based incremental update . . . . . . . .17
5.2.3 "unique" consistency based incremental update . . . . . . .17
5.3 Second update . . . . . . . . . . . . . . . . . . . . . . . .18
5.3.1 "complete" consistency based incremental update . . . . . .18
5.3.2 "tag" consistency based incremental update . . . . . . . . .19
5.3.3 "unique" consistency based incremental update . . . . . . .20
6. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . .21
6.1 Aggregation of Tagged Index Objects . . . . . . . . . . . . .21
7. Security Considerations . . . . . . . . . . . . . . . . . . . .21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . .22
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .23
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .24
The Common Indexing Protocol (CIP) as defined in [1] proposes a mechanism for distributing searches across several instances of a single type of search engine to create a global directory. CIP provides a scalable, flexible scheme to tie individual databases into distributed data warehouses that can scale gracefully with the growth of the Internet. CIP provides a mechanism for meeting these goals that is independent of the access method that is used to access the data that underlies the indices. Separate from CIP is the definition of the Index Object that is used to contain the information that is exchanged among Index Servers. One such Index Object that has already been defined is the Centroid that is derived from the Whois++ protocol [2].
[1]で定義されている共通インデックスプロトコル（CIP）は、グローバルディレクトリを作成するために、単一のタイプの検索エンジンのいくつかのインスタンスに検索を配布するメカニズムを提案しています。CIPは、個々のデータベースをインターネットの成長に合わせて優雅にスケーリングできる分散データウェアハウスに結び付けるスケーラブルで柔軟なスキームを提供します。CIPは、インデックスの根底にあるデータにアクセスするために使用されるアクセス方法に依存しないこれらの目標を満たすメカニズムを提供します。CIPとは別に、インデックスサーバー間で交換される情報を含めるために使用されるインデックスオブジェクトの定義があります。すでに定義されているそのようなインデックスオブジェクトの1つは、WOISプロトコル[2]から派生した重心です。
The Centroid does not meet all the requirements for the exchange of index information amongst information servers. For example, it does not support the notion of incremental updates natively. For information servers that contain millions of records in their database, constant exchange of complete dredges of the database is bandwidth intensive. The Tagged Index Object is specifically designed to support the exchange of index update information. This design comes at the cost of an increase in the size of the index object being exchanged. The Centroid is also not tailored to always be able to give boolean answers to queries. In the Centroid Model, "an index server will take a query in standard Whois++ format, search its collections of centroids and other forward information, determine which servers hold records which may fill that query, and then notifies the user's client of the next servers to contact to submit the query." [2] Thus, the exchange of Centroids amongst index servers allows hints to be given about which information server actually contains the information. The Tagged Index Object labels the various pieces of information with identifiers that tie the individual object attributes back to an object as a whole. This "tagging" of information allows an index server to be more capable of directing a specific query to the appropriate information server. Again, this feature is added to the Tagged Index Object at the expense of an increase in the size of the index object.
Centroidは、情報サーバー間のインデックス情報交換のすべての要件を満たしていません。たとえば、インクリメンタル更新の概念をネイティブにサポートしていません。データベースに何百万ものレコードを含む情報サーバーの場合、データベースの完全なdrgeの絶え間ない交換は帯域幅の集中です。タグ付きインデックスオブジェクトは、インデックス更新情報の交換をサポートするように特別に設計されています。この設計は、交換されるインデックスオブジェクトのサイズが増加するための犠牲を払っています。Centroidは、クエリに対するブールの回答を常に提供できるように調整されていません。Centroidモデルでは、「インデックスサーバーは標準のWHOIS形式でクエリを取得し、Centroidsおよびその他のフォワード情報のコレクションを検索し、そのクエリを満たす可能性のあるレコードを保持するサーバーを決定し、次のサーバーのユーザーのクライアントに通知します。クエリを送信するために連絡してください。」[2]したがって、インデックスサーバー間の重心の交換により、どの情報サーバーが実際に情報を含むかについてのヒントを与えることができます。タグ付きインデックスオブジェクトは、個々のオブジェクト属性をすべてオブジェクト全体に戻す識別子を含むさまざまな情報をラベル付けします。情報のこの「タグ付け」により、インデックスサーバーは、適切な情報サーバーに特定のクエリを指示できるようになります。繰り返しますが、この機能は、インデックスオブジェクトのサイズの増加を犠牲にして、タグ付きインデックスオブジェクトに追加されます。
The Lightweight Directory Access Protocol (LDAP) is defined in [3], and it defines a mechanism for accessing a collection of information arranged hierarchically in such a way as to provide a globally distributed database which is normally called the Directory Information Tree (DIT). Some distinguishing characteristics of LDAP servers are that normally, several servers cooperate to manage a common subtree of the DIT. LDAP servers are expected to respond to requests that pertain to portions of the DIT for which they have data, as well as for those portions for which they have no information in their database. For example, the LDAP server for a portion of the DIT in the United States (c=US) must be able to provide a response to a Search operation that pertains to a portion of the DIT in Sweden (c=se). Normally, the response given will be a referral to another LDAP server that is expected to be more knowledgeable about the appropriate subtree. However, there is no mechanism that currently enables these LDAP servers to refer the LDAP client to the supposedly more knowledgeable server. Typically, an LDAP (v3) server is configured with the name of exactly one other LDAP server to which all LDAP clients are referred when their requests fall outside the subtree of the DIT for which that LDAP server has knowledge. This specification defines a mechanism whereby LDAP server can exchange index information that will allow referrals to point towards a clearly accurate destination.
軽量ディレクトリアクセスプロトコル（LDAP）は[3]で定義されており、通常はディレクトリ情報ツリー（DIT）と呼ばれるグローバルに分散したデータベースを提供するような方法で階層的に配置された情報のコレクションにアクセスするメカニズムを定義しています。。LDAPサーバーのいくつかの際立った特性は、通常、いくつかのサーバーが協力してDITの共通のサブツリーを管理することです。LDAPサーバーは、データがあるDITの一部に関係するリクエストと、データベースに情報がない部分に応答することが期待されています。たとえば、米国のDITの一部（C = US）のLDAPサーバーは、スウェーデンのDITの一部（C = SE）に関連する検索操作への応答を提供できる必要があります。通常、与えられた応答は、適切なサブツリーについてより知識があると予想される別のLDAPサーバーへの紹介となります。ただし、現在、これらのLDAPサーバーがLDAPクライアントをより知識豊富なサーバーに照会できるようにするメカニズムはありません。通常、LDAP（V3）サーバーは、他の1つのLDAPサーバーの名前で構成されています。これには、すべてのLDAPクライアントが、そのLDAPサーバーが知識を持っているDITのサブツリーの外側にリクエストが該当するときに参照されます。この仕様は、LDAPサーバーが紹介が明確に正確な宛先を指すことを可能にするインデックス情報を交換できるメカニズムを定義します。
The X.500 series of recommendations defines the Directory Information Shadowing Protocol (DISP) [4] which allows X.500 DSAs to exchange information in the DIT. Shadowing allows various information from various portions of the DIT to be replicated amongst participating DSAs. The design point of DISP is improved at the exchange of entire portions of the DIT, whereas the design point of CIP and the Tagged Index Object is optimized at the exchange of structural index information about the DIT, and improving the performance of tree navigation amongst various information servers. The Tagged Index Object is more appropriate for the exchange of index information than is DISP. DISP is more targeted at DIT distribution and fault tolerance. DISP is thus more appropriate for the exchange of the data in order to spread the load amongst several information servers. DISP is tailored specifically to X.500 (and other hierarchical directory systems), while the Tagged Index Object and CIP can be used in a wide variety of information server environments.
X.500の一連の推奨事項は、X.500 DSAがDITで情報を交換できるようにするディレクトリ情報シャドウイングプロトコル（Disp）[4]を定義しています。Shadowingは、DITのさまざまな部分からのさまざまな情報を、参加しているDSAの間で複製できるようにします。DISTの設計ポイントは、DITの全部分の交換で改善されますが、CIPとタグ付きインデックスオブジェクトの設計ポイントは、DITに関する構造インデックス情報の交換で最適化され、さまざまなさまざまなツリーナビゲーションのパフォーマンスの向上情報サーバー。タグ付きインデックスオブジェクトは、DISPよりもインデックス情報の交換により適しています。Dispは、DIT分布とフォールトトレランスをより標的としています。したがって、Dispは、いくつかの情報サーバー間に負荷を広めるために、データの交換により適しています。DispはX.500（およびその他の階層ディレクトリシステム）に特異的に調整されていますが、タグ付きインデックスオブジェクトとCIPは、さまざまな情報サーバー環境で使用できます。
While DISP allows an individual directory server to collect information about large parts of the DIT, it would require a huge database to collect all the replicas for a significant portion of the DIT. Furthermore, as X.525 states: "Before shadowing can occur, an agreement, covering the conditions under which shadowing may occur is required. Although such agreements may be established in a variety of ways, such as policy statements covering all DSAs within a given DMD ...", where a DMD is a Directory Management Domain. This is owing to the case that the data in the DIT is being exchanged amongst DSA rather than only the information required to maintain an Index. In many environments such an agreement is not appropriate, and to collect information for a meaningful portion of the DIT, many agreements may need to be arranged.
DISPでは、個々のディレクトリサーバーがDITの大部分に関する情報を収集することができますが、DITのかなりの部分についてすべてのレプリカを収集するには、巨大なデータベースが必要になります。さらに、X.525が次のように述べているように、「影が発生する前に、シャドウイングが発生する可能性のある条件をカバーする合意が必要です。ただし、そのような合意は、特定のすべてのDSAをカバーするポリシーステートメントなど、さまざまな方法で確立される場合があります。DMD ...」、DMDはディレクトリ管理ドメインです。これは、DITのデータがインデックスを維持するために必要な情報のみではなく、DSA間で交換されている場合です。多くの環境では、そのような合意は適切ではなく、DITの意味のある部分の情報を収集するには、多くの契約を手配する必要がある場合があります。
What is desired is to have an information server (or network of information servers) that can quickly respond to real world requests, like:
望ましいのは、以下のような現実世界の要求に迅速に対応できる情報サーバー（または情報サーバーのネットワーク）を持つことです。
- What is Tim Howes's email address? This is much harder than; What email address does Tim Howes at Netscape have ?
- ティム・ハウズのメールアドレスとは何ですか？これははるかに難しいです。NetscapeのTim Howesにはどのようなメールアドレスがありますか？
- What is the X.509 certificate for Fred Smith at compuserve.com? One certainly doesn't want to search CompuServe's entire directory tree to find out this one piece of information. I also don't want to have to shadow the entire CompuServe directory subtree onto my server. If this request is being made because Fred is trying to log into my server, I'd certainly want to be able to respond to the BIND in real time.
- Compuserve.comのFred SmithのX.509証明書は何ですか？確かに、Compuserveのディレクトリツリー全体を検索して、この1つの情報を見つけたくありません。また、Compuserve Directory Subtree全体をサーバーにシャドウ化する必要はありません。フレッドがサーバーにログインしようとしているためにこのリクエストが行われている場合、私は確かにリアルタイムでバインドに応答できるようにしたいと思います。
- Who are all the people at Novell that have a title of programmer?
- プログラマーの称号を持っているノベルのすべての人々は誰ですか？
all these requests can reasonably be translated into LDAP or Whois++, and other directory access protocol queries. They can also be serviced in a straightforward way by the users home information server if it has the appropriate reference information into the database that contains the source data. Here, the first server would be able to "chain" the request for the user. Alternatively, a precise referral could be returned. If the home information server wants to service (i.e chain) the request based on the index information that it has on hand, this servicing could be done several different means:
これらすべての要求は、LDAPまたはWHOIS、およびその他のディレクトリアクセスプロトコルクエリに合理的に翻訳できます。また、ソースデータを含むデータベースに適切な参照情報がある場合は、ユーザーホーム情報サーバーが簡単な方法でサービスを提供することもできます。ここで、最初のサーバーはユーザーのリクエストを「チェーン」することができます。あるいは、正確な紹介を返すことができます。Home Information Serverが手元にあるインデックス情報に基づいてリクエストを使用する（つまり、チェーン）場合、このサービスはいくつかの異なる手段を実行できます。
- issuing LDAP operations to the remote directory server
- LDAP操作をリモートディレクトリサーバーに発行します
- issuing DSP operations to the remote directory server
- DSP操作をリモートディレクトリサーバーに発行します
- issuing DAP operations to the remote directory server
- DAP操作をリモートディレクトリサーバーに発行します
- issuing Whois++ operations to the remote Whois++ server
- WHOIS操作をリモートWHOISサーバーに発行します
- ...
- ...
This section defines a Tagged Index Object that can be exchanged by Information Servers using CIP. While often it is acceptable for Information Servers to make use of the Centroid definition (from [2]) to exchange index information, the goals in defining a new construct are multi-pronged:
このセクションでは、CIPを使用して情報サーバーによって交換できるタグ付きインデックスオブジェクトを定義します。多くの場合、情報サーバーは重心定義（[2]から）を使用してインデックス情報を交換することができますが、新しいコンストラクトを定義する目標は多面化されています。
- When the Information Server receives a search request that warrants that a referral be returned, allow the server to return a referral that will point client to a server that is most likely able to answer the request correctly. False positive referrals (the search turns up hits in the index object that generate referrals to servers that don't hold the desired information) can be reduced, depending on the choice of attribute tokenization types that are used.
- 情報サーバーが紹介が返されることを保証する検索要求を受信した場合、クライアントにリクエストに正しく答えることができるサーバーに紹介を返すようにサーバーを許可します。False Positive紹介（検索により、使用されている情報を保持しないサーバーへの紹介を生成するインデックスオブジェクトのヒットが表示されます）は、使用される属性トークン化タイプの選択に応じて削減できます。
- Potentially allow incremental updates that will then consume substantially less bandwidth then if full updates always had to be used.
- 完全な更新を常に使用する必要がある場合、その後、大幅に少ない帯域幅を消費する増分更新を許可する可能性があります。
Before a Tagged Index Object can be exchanged, the organization that administers the object supplier and the organization that administers the object consumer must reach an agreement on how the servers will communicate. This agreement contains the following:
タグ付きインデックスオブジェクトを交換する前に、オブジェクトサプライヤーを管理する組織とオブジェクトの消費者を管理する組織が、サーバーの通信方法に関する合意に達する必要があります。この契約には次のものが含まれています。
- "index-type": This specification describes the index type "x-tagged-index-1"
- 「インデックスタイプ」：この仕様では、インデックスタイプ「X-Tagged-Index-1」について説明します
- "dsi": An OID that uniquely identifies the subtree and scope. This field is not explicitly necessary, as it may not provide information beyond what is contained in the "base-uri" below.
- 「DSI」：サブツリーとスコープを独自に識別するOID。このフィールドは、以下の「ベースURI」に含まれるものを超えて情報を提供しない可能性があるため、明示的に必要ではありません。
- "base-uri": One or more URI's that will form the base of any referrals created based on the index object that is governed by this agreement. For example, in the LDAP URL format [8] the base-uri would specify (among other items): the LDAP host, the base object to which this index object refers (e.g. c=SE), and the scope of the index object (e.g. single container).
- 「Base-URI」：本契約によって支配されているインデックスオブジェクトに基づいて作成された紹介のベースを形成する1つ以上のURI。たとえば、LDAP URL形式[8]では、ベースURIは（他の項目の中で）指定します。LDAPホスト、このインデックスオブジェクトが参照するベースオブジェクト（例：c = se）、およびインデックスオブジェクトの範囲（例：単一のコンテナ）。
- "supplier": The hostname and listening portnumber of the supplier server, as well as any alternative servers holding that same naming contexts, if the supplier is unavailable.
- 「サプライヤー」：サプライヤーサーバーのホスト名とリスニングポートナンバー、およびサプライヤーが利用できない場合、同じ命名コンテキストを保持している代替サーバー。
- "consumeraddr": This is a URI of the "mailto:" form, with the RFC 822 email address of the consumer server. Further versions of this draft allow other forms of URI, so that the consumer may retrieve the update via the WWW, FTP or CIP.
- 「ConsumerAddr」：これは、「Mailto：」フォームのURIであり、RFC 822消費者サーバーの電子メールアドレスがあります。このドラフトのさらなるバージョンにより、他の形式のURIが可能になり、消費者はwww、ftp、またはcipを介して更新を取得できます。
- "updateinterval": The maximum duration in seconds between occurances of the supplier server generating an update. If the consumer server has not received an update from the supplier server after waiting this long since the previous update, it is likely that the index information is now out of date. A typical value for a server with frequent updates would be 604800 seconds, or every week. Servers whose DITs are only modified annually could have a much longer update interval.
- 「UpdateInterval」：更新を生成するサプライヤーサーバーの発生間の数秒の最大期間。消費者サーバーが、前のアップデートからこの長い間待ってからサプライヤーサーバーから更新を受信していない場合、インデックス情報は現在古くなっている可能性があります。頻繁に更新されるサーバーの典型的な値は、604800秒、または毎週です。毎年ditが変更されているサーバーは、はるかに長い更新間隔を持つことができます。
- "attributeNamespace": Every set of index servers that together wants to support a specific usage of indeces, has to agree on which attributenames to use in the index objects. The participating directory servers also has to agree on the mapping from local attributenames to the attributenames used in the index. Since one specific index server might be involved in several such sets, it has to have some way to connect a update to the proper set of indexes. One possible solution to this would be to use different DSIs.
- 「AttributeNamesSpace」：特定のユーザーの使用をサポートしたいインデックスサーバーのすべてのセットは、インデックスオブジェクトで使用する属性に同意する必要があります。参加ディレクトリサーバーは、ローカルアトリビネーションからインデックスで使用される属性へのマッピングにも同意する必要があります。1つの特定のインデックスサーバーがそのようないくつかのセットに関与する可能性があるため、更新を適切なインデックスセットに接続する方法が必要です。これに対する可能な解決策の1つは、異なるDSIを使用することです。
- "consistencybase": How consistency of the index is maintained over incremental updates:
- 「一貫性ベース」：インデックスの更新上でインデックスの一貫性がどのように維持されるか：
"complete" - every change or delete concerning one object has to contain all tokens connected to that object. This method must be supported by any server who wants to comply with this standard.
「完了」 - 1つのオブジェクトに関するすべての変更または削除が、そのオブジェクトに接続されたすべてのトークンを含める必要があります。この方法は、この標準に準拠したいサーバーによってサポートされる必要があります。
"tag" - starting at a full update every incremental update refering back to this full updated has to maintain state-information regarding tags, such that a object within the original database is assigned the same tagnumber every time. This method is optional.
「タグ」 - 完全な更新から始まるこの完全な更新を参照するすべての増分アップデートは、タグに関する状態情報を維持する必要があります。これにより、元のデータベース内のオブジェクトが毎回同じTagnumberが割り当てられます。この方法はオプションです。
"unique" - every object in the Dataset has to have a unique value for a specific attribute in the index. A example of such a attribute could be the distinguishedName attribute. This method is also optional.
「一意」 - データセット内のすべてのオブジェクトには、インデックス内の特定の属性に対して一意の値が必要です。このような属性の例は、DistinguedName属性です。この方法もオプションです。
- "securityoption": Whether and how the supplier server should sign and encrypt the update before sending it to the consumer server. Options for this version of the specification are:
- 「SecurityOption」：サプライヤーサーバーが消費者サーバーに送信する前に、サプライヤーサーバーがアップデートに署名して暗号化するかどうか。仕様のこのバージョンのオプションは次のとおりです。
"none" - the update is sent in plaintext
「なし」 - アップデートはプレーンテキストで送信されます
"PGP/MIME": the update is digitally signed and encrypted using PGP [9]
「PGP/MIME」：更新はPGPを使用してデジタル署名および暗号化されています[9]
"S/MIME": the update is digitally signed and encrypted using S/MIME [10]
「S/MIME」：アップデートは、S/MIME [10]を使用してデジタル署名および暗号化されています
"SSLv3": the update is digitally signed and encrypted using an SSLv3 connection [11]
「SSLV3」：アップデートは、SSLV3接続を使用してデジタル署名および暗号化されています[11]
"Fortezza": the update is digitally signed and encrypted using Fortezza [5]
「Fortezza」：アップデートは、fortezza [5]を使用してデジタル署名および暗号化されています
It is recommended that the "PGP/MIME" option be used when exchanging sensitive information across public networks, and both the supplier and consumer have PGP keys. The "Fortezza" option is intended for use in environments where security protocols are based on Fortezza-compatible devices. The "S/MIME" option can be used with both the supplier and consumer have RSA keys and can make use of the PKCS protocols defined in the S/MIME specification. The "SSLv3" option can be used when both the supplier and consumer have access to SSL services, have server certificates, and can mutually authenticate each other.
パブリックネットワーク全体で機密情報を交換するときに「PGP/MIME」オプションを使用することをお勧めします。サプライヤーと消費者の両方がPGPキーを持っています。「Fortezza」オプションは、セキュリティプロトコルがFortezza互換デバイスに基づいている環境での使用を目的としています。「S/MIME」オプションは、サプライヤーの両方で使用でき、消費者はRSAキーを持ち、S/MIME仕様で定義されたPKCSプロトコルを使用できます。サプライヤーと消費者の両方がSSLサービスにアクセスし、サーバー証明書を持ち、相互に認証できる場合、「SSLV3」オプションを使用できます。
- Security Credentials: The long-term cryptographic credentials used for key exchange and authentication of the consumer and supplier servers, if a security option was selected. For "PGP/MIME," this will be the trusted public keys of both servers. For "Fortezza," this will be the certificate paths of both servers to a common point of trust. For "S/MIME" and "SSLv3" these will be the certificates of the supplier and consumer.
- セキュリティ資格情報：セキュリティオプションが選択された場合、消費者およびサプライヤーサーバーの主要な交換と認証に使用される長期的な暗号化資格情報。「PGP/MIME」の場合、これは両方のサーバーの信頼できるパブリックキーになります。「Fortezza」の場合、これは両方のサーバーの共通の信頼ポイントへの証明書パスになります。「s/mime」と「sslv3」の場合、これらはサプライヤーと消費者の証明書になります。
Note that if the index server maintains the information that would appear in the agreement in a directory according to the definitions in [7], then no real formal agreement between the two parties needs to be put in place, and the information that is required for communication between the two index servers is derived automatically from the directory.
インデックスサーバーが[7]の定義に従ってディレクトリに契約に表示される情報を維持している場合、2つの当事者間の実際の正式な合意を導入する必要はなく、必要な情報は必要な情報はありません。2つのインデックスサーバー間の通信は、ディレクトリから自動的に導出されます。
The update consists of a MIME object of type application/cip-index-object. The parameters are:
更新は、タイプアプリケーション/CIP-Index-ObjectのMIMEオブジェクトで構成されています。パラメーターは次のとおりです。
"type": this has value "application/index.obj.tagged".
「タイプ」：これには値「application/index.obj.tagged」があります。
"dsi": the DSI (if any) from the agreement.
「DSI」：契約からのDSI（もしあれば）。
"base-uri". A set of URIs, separated by spaces. In each URI, the hostname/portno must be distinct, and based on the "supplier" part of the agreement.
「ベースウリ」。スペースで区切られたウリスのセット。各URIでは、ホスト名/portnoは明確であり、契約の「サプライヤー」部分に基づいている必要があります。
The payload is mostly textual data but may include bytes with the high bit set. The originating information server should set the content-transfer-encoding as appropriate for the information included in the payload.
ペイロードはほとんどテキストデータですが、ハイビットセットのバイトが含まれる場合があります。発信元の情報サーバーは、ペイロードに含まれる情報に適したコンテンツ転送エンコードを設定する必要があります。
This object may be encapsulated in a wrapper content (such as multipart/signed) or be encrypted as part of the security procedures. The resulting content can the distributed, for example via electronic mail. For example,
このオブジェクトは、ラッパーコンテンツ（マルチパート/署名など）にカプセル化されるか、セキュリティ手順の一部として暗号化される場合があります。結果のコンテンツは、たとえば電子メールを介して分散することができます。例えば、
From: supplier@sup.com Date: Thu, 16 Jan 1997 13:50:37 -0500
Message-Id: <199701161850.NAA29295@sup.com>;
To: consumer@consumer.com <<-- from consumer server address
Reply-to: supplier-admin@sup.com
MIME-Version: 1.0
Content-Type: application/index.obj.tagged;
dsi=1.3.6.1.4.1.1466.85.85.1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16;
base-uri="ldap://sup.com/dc=sup,dc=com ldap://alt.com/dc=sup,dc=com"
The payload is series of CRLF-terminated lines. The payload is UTF-8. Some supplier servers may only be able to generate the printable US-ASCII subset of UTF-8, but all consumer servers must be able to handle the full range of Unicode characters when decoding the attribute values (in the "attr-value" field in the BNF below).
ペイロードは、一連のCRLF末端線です。ペイロードはUTF-8です。一部のサプライヤーサーバーは、UTF-8の印刷可能なUS-ASCIIサブセットのみを生成できる場合がありますが、すべての消費者サーバーは、属性値をデコードするときにユニコード文字の全範囲を処理できる必要があります（「attr-value」フィールドで以下のBNF）。
The Tagged Index object has the following grammar, expressed in modified BNF format:
タグ付きインデックスオブジェクトには、変更されたBNF形式で表される次の文法があります。
index-object = 0*(io-part SEP) io-part
io-part = header SEP schema-spec SEP index-info
header = version-spec SEP update-type SEP this-update SEP
last-update context-size name-space SEP
version-spec = "version:" *SPACE "x-tagged-index-1"
update-type = "updatetype:" *SPACE ( "total" |
( "incremental" [*SPACE "tagbased"|"uniqueIDbased" ] )
this-update = "thisupdate:" *SPACE TIMESTAMP
last-update = [ "lastupdate:" *SPACE TIMESTAMP SEP]
context-size = [ "contextsize:" *SPACE 1*DIGIT SEP]
schema-spec = "BEGIN IO-Schema" SEP 1*(schema-line SEP)
"END IO-Schema"
schema-line = attribute-name ":" token-type
token-type = "FULL" | "TOKEN" | "RFC822" | "UUCP" | "DNS"
index-info = full-index | incremental-index
full-index = "BEGIN Index-Info" SEP 1*(index-block SEP)
"END Index-Info"
incremental-index = 1*(add-block | delete-block | update-block)
add-block = "BEGIN Add Block" SEP 1*(index-block SEP)
"END Add Block"
delete-block = "BEGIN Delete Block" SEP 1*(index-block SEP)
"END Delete Block"
update-block = "BEGIN Update Block" SEP
0*(old-index-block SEP)
1*(new-index-block SEP)
"END Update Block"
old-index-block = "BEGIN Old" SEP 1*(index-block SEP)
"END Old"
new-index-block = "BEGIN New" SEP 1*(index-block SEP)
"END New"
index-block = first-line 0*(SEP cont-line)
first-line = attr-name ":" *SPACE taglist "/" attr-value
cont-line = "-" taglist "/" attr-value
taglist = tag 0*("," tag) | "*"
tag = 1*DIGIT ["-" 1*DIGIT]
attr-value = 1*(UTF8)
attr-name = 1*(NAMECHAR)
TIMESTAMP = 1*DIGIT
NAMECHAR = DIGIT | UPPER | LOWER | "-" | ";" | "."
SPACE = <ASCII space, %x20>;
SEP = (CR LF) | LF
CR = <ASCII CR, carriage return, %x0D>;
LF = <ASCII LF, line feed, %x0A>;
DIGIT = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
UPPER = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
"I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
"Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
"Y" | "Z"
LOWER = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
"i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
"q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
"y" | "z"
US-ASCII-SAFE = %x01-09 / %x0B-0C / %x0E-7F
;; US-ASCII except CR, LF, NUL
UTF8 = US-ASCII-SAFE / UTF8-1 / UTF8-2 / UTF8-3
/ UTF8-4 / UTF8-5
UTF8-CONT = %x80-BF
UTF8-1 = %xC0-DF UTF8-CONT
UTF8-2 = %xE0-EF 2UTF8-CONT
UTF8-3 = %xF0-F7 3UTF8-CONT
UTF8-4 = %xF8-FB 4UTF8-CONT
UTF8-5 = %xFC-FD 5UTF8-CONT
The set of characters allowed to appear in the attr-name field is limited to the set of characters used in LDAP and WHOIS++ attribute names. For other services that have attribute name character sets that are larger than these, those services should create a profile that maps the names onto object identifiers, and the sequence of digits and periods is used by those services in creating the attr-name fields for their Tagged Index Objects.
Attr-Nameフィールドに表示される文字のセットは、LDAPで使用される文字のセットとWHOIS属性名に限定されます。これらよりも大きい属性名の文字セットを持つ他のサービスの場合、それらのサービスは、名前をオブジェクト識別子にマッピングするプロファイルを作成する必要があり、それらのサービスのシーケンスと周期は、それらの属性フィールドを作成する際にそれらのサービスによって使用されます。タグ付きインデックスオブジェクト。
It is worth mentioning that updates to a index based in tagged index objects MUST be performed in the order specified by the tagged index object itself.
タグ付きインデックスオブジェクトのインデックスに基づいたインデックスの更新は、タグ付きインデックスオブジェクト自体によって指定された順序で実行する必要があることに言及する価値があります。
The header section consists of one or more "header lines". The following header lines are defined:
ヘッダーセクションは、1つ以上の「ヘッダーライン」で構成されています。次のヘッダーラインが定義されています。
"version": This line must always be present, and have the value "x-tagged-index-1" for this version of the specification.
「バージョン」：この行は常に存在し、このバージョンの仕様の値「x-tagged-index-1」を持っている必要があります。
"updatetype": This line must always be present. It takes as the value either "total" or "incremental". The first update sent by a supplier server to a consumer server for a DSI must be a "total" update.
「UpdateType」：この行は常に存在する必要があります。「合計」または「増分」のいずれかの値としてかかります。サプライヤーサーバーからDSIの消費者サーバーに送信された最初の更新は、「合計」アップデートである必要があります。
"thisupdate": This line must always be present. The value is the number of seconds from 00:00:00 UTC January 1, 1970 at which the supplier constructed this update.
「thisupdate」：この行は常に存在する必要があります。値は、1970年1月1日の00:00:00 UTCからの秒数で、サプライヤーがこのアップデートを構築しました。
"lastupdate": This line must be present if the "updatetype" list has the value "incremental". The value is the number of seconds from 00:00:00 UTC January 1, 1970 at which the supplier constructed the previous update sent to the consumer. This field allows the consumer to determine if a previous update was missed
「LastUpdate」：「updateType」リストに値が「増分」を持っている場合、この行を存在する必要があります。値は、1970年1月1日00:00:00 UTCからの秒数で、サプライヤーは消費者に送信された以前のアップデートを構築しました。このフィールドにより、消費者は以前の更新が見逃されたかどうかを判断できます
"contextsize": This line may be present at the supplier's option. The value is a number, which is the approximate total number of entries in the subtree. This information is provided for statistical purposes only.
「Contextsize」：この行は、サプライヤーのオプションに存在する場合があります。値は数であり、これはサブツリーのエントリのおおよその総数です。この情報は、統計的な目的でのみ提供されます。
The Tagged Index Object inherits the "TOKEN" scheme for tokenization as specified in [2]. In addition, there are several other tokenization schemes defined for the Tagged Index Object. The following table presents these schemes and what character(s) are used to delimit tokens.
タグ付きインデックスオブジェクトは、[2]で指定されているように、トークン化の「トークン」スキームを継承します。さらに、タグ付きインデックスオブジェクトに対して定義された他のいくつかのトークン化スキームがあります。次の表は、これらのスキームと、トークンを区切るために使用される文字を示しています。
Token Type Tokenization Characters FULL none TOKEN white space, "@" RFC822 white space, ".", "@" UUCP white space, "!" DNS any character note a number, letter, or "-"
トークンタイプトークン化キャラクターフルなしトークンホワイトスペース、 "@" rfc822ホワイトスペース "。"、 "@" uucpホワイトスペース、 "！"DNS任意の文字は、番号、文字、または「 - 」に注意してください
In the tag list, multiple consecutive tags may be shortened by using "#-#". For example, the list "3,4,5,6,7,8,9,10" may be shortened to "3-10". Tags are to be applied to the data on a per entry level. Thus, if two index lines in the same index object contain the same tag, then those two lines always refer to the same "record" in the directory. In LDAP terminology, the two lines would refer to the same directory object. Additionally if two index lines in the same index object contain different tags, then it is always the case that those two lines refer back to different records in the directory. The meaning of '*' in the tag position is that that specific token apears in every record in the directory.
タグリストでは、「＃ - ＃」を使用して複数の連続したタグを短縮できます。たとえば、「3,4,5,6,7,8,9,10」のリストは、「3-10」に短縮される場合があります。タグは、エントリあたりのレベルのデータに適用されます。したがって、同じインデックスオブジェクトの2つのインデックス行に同じタグが含まれている場合、これらの2つの行は常にディレクトリの同じ「録音」を参照します。LDAP用語では、2つの行は同じディレクトリオブジェクトを参照します。さらに、同じインデックスオブジェクトの2つのインデックス行に異なるタグが含まれている場合、これらの2つの行がディレクトリ内の異なるレコードを参照することが常に当てはまります。タグの位置における「*」の意味は、特定のトークンがディレクトリ内のすべてのレコードでApearsがApearseしていることです。
The tag applied to the same underlying record in two separate transmissions of a full-index may be different. Thus, receiving index servers should make no assumptions about the values of the tags across index object boundaries.
フルインデックスの2つの個別の送信で同じ基礎記録に適用されるタグは異なる場合があります。したがって、インデックスサーバーの受信は、インデックスオブジェクトの境界を越えたタグの値について仮定しないはずです。
The tagged index object format supports the ability of information servers to distribute only delta index data, rather than distributing total index information each time. This scenario, known as incremental indexing supports three basic types of operations: add, delete and replace. If the incremental updatetype is specified in the tagged index object, then the index object contains a snapshot of only the changes that have been made since the index object specified in the lastupdate header was distributed. If the receiving index server did not receive that index object, it should request a total index object. If the CIP protocol supports it, the index server may request the specific index object that it missed.
タグ付きインデックスオブジェクト形式は、毎回合計インデックス情報を配布するのではなく、情報サーバーがデルタインデックスデータのみを配布する機能をサポートします。インクリメンタルインデックス作成として知られるこのシナリオは、3つの基本的なタイプの操作をサポートしています：追加、削除、交換。タグ付きインデックスオブジェクトでインクリメンタルアップデートタイプが指定されている場合、インデックスオブジェクトには、LastUpDateヘッダーで指定されたインデックスオブジェクトが分散されて以降に行われた変更のみのスナップショットが含まれます。受信インデックスサーバーがそのインデックスオブジェクトを受信しなかった場合、合計インデックスオブジェクトを要求する必要があります。CIPプロトコルがサポートしている場合、インデックスサーバーは、見逃した特定のインデックスオブジェクトを要求する場合があります。
If the tagged index object contains an Add Block, then the lines in the Add Block refer to new records that were added to the information base of the transmitting index server. It can be guaranteed that those records did not exist in any previously received tagged index object, and the receiving index server can insert this index information in the index that it already maintains for the transmitting index server.
タグ付きインデックスオブジェクトに追加ブロックが含まれている場合、ADDブロックの行には、送信インデックスサーバーの情報ベースに追加された新しいレコードを参照します。これらのレコードが以前に受信したタグ付きインデックスオブジェクトに存在しなかったことを保証でき、受信インデックスサーバーは、送信インデックスサーバーのために既に維持しているインデックスにこのインデックス情報を挿入できます。
If the tagged index object contains a Delete Block, then the structure of the Delete Block depends on how the consistency is maintained;
タグ付きインデックスオブジェクトに削除ブロックが含まれている場合、削除ブロックの構造は一貫性の維持方法によって異なります。
- "completeRecord": all the tokens connected to the record to be deleted has to be included, the tag used to connect tokens in this message has no relation to tags used in previously sent tagged index objects.
- 「CompleterCord」：削除するレコードに接続されたすべてのトークンを含める必要があります。このメッセージのトークンを接続するために使用されるタグは、以前に送信されたタグ付きインデックスオブジェクトで使用されたタグとは関係ありません。
- "uniqueIDBased": only the unique identifier has to be defined.
- 「uniqueIdbased」：一意の識別子のみを定義する必要があります。
- "tagBased": all the tokens connected to the record has to be included but then preceded by the tag used for this specific record in the preceding set of the last full update and the there on following incremental updates.
- 「Tagbased」：レコードに接続されたすべてのトークンを含める必要がありますが、最後の完全な更新の前のセットでこの特定のレコードに使用されるタグと、以下の増分更新で前に使用する必要があります。
If the tagged index object contains an Update Block, then the lines in the Update Block refer to records that were changed in the information base of the transmitting index server. Again the specific content of the block depends on how the consistency is maintained.
タグ付きインデックスオブジェクトに更新ブロックが含まれている場合、更新ブロックの行は、送信インデックスサーバーの情報ベースに変更されたレコードを参照します。繰り返しますが、ブロックの特定のコンテンツは、一貫性の維持方法によって異なります。
- "completeRecord": All the tokens representing the old version of the record as well as the new ones has to be included.
- 「CompleterCord」：レコードの古いバージョンと新しいバージョンを表すすべてのトークンを含める必要があります。
- "uniqueIDBased": The unique ID has to be included together with the tokens that have changed.
- 「uniqueIdbased」：一意のIDは、変更されたトークンと一緒に含める必要があります。
- "tagBased": Only the changed tokens are included, but then both the old version, if there was one, as well as the new one, if there is one.
- 「タグベース」：変更されたトークンのみが含まれていますが、その後、古いバージョンがある場合は両方とも、新しいバージョンがある場合は、両方のバージョンがあります。
The Update Block also supports the idea of indexing new attributes that were not previously included in the tagged index object. For example, if the transmitting index server began including index information on postal addresses, then it could include an Update Block in the index object that included all the index information on postal addresses for all records in its information base, and indicate that nothing else has changed.
更新ブロックは、タグ付きインデックスオブジェクトに以前に含まれていなかった新しい属性をインデックス作成するというアイデアもサポートしています。たとえば、送信インデックスサーバーが郵便アドレスにインデックス情報を含め始めた場合、情報ベースのすべてのレコードの郵便アドレスに関するすべてのインデックス情報を含むインデックスオブジェクトに更新ブロックを含めることができ、他に何も持っていないことを示します。かわった。
In the following sections, for each different consistencybase type, the tagged index object is represented for the following scenario; The examples starts with one full update and following that a set of updates. The underlying information is presented in the LDIF [6] format.
次のセクションでは、異なる一貫性ベースタイプごとに、タグ付きインデックスオブジェクトが次のシナリオで表されます。例は、1つの完全な更新から始まり、その更新のセットに従います。基礎となる情報は、LDIF [6]形式で表示されます。
dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Barbara Jensen
cn: Barbara J Jensen
cn: Babs Jensen
sn: Jensen
uid: bjensen
dn: cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Bjorn Jensen
sn: Jensen
title: Accounting manager
dn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Gern Jensen
cn: Gern O Jensen
sn: Jensen
title: testpilot
dn: cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Horatio Jensen
cn: Horatio N Jensen
sn: Jensen
title: testpilot
version: x-tagged-index-1 updatetype: total thisupdate: 855938804 BEGIN IO-Schema cn: TOKEN sn: FULL title: TOKEN END IO-Schema BEGIN Index-Info cn: 1/Barbara -1/J -1/Babs -*/Jensen -2/Bjorn -3/Gern -3/O -4/Horatio -4/N sn: */Jensen title: 1/product -1-2/manager -1/accounting -3,4/testpilot END Index-Info
バージョン：x-tagged-index-1 updateType：合計thisupdate：8559388804 IO-schema CN：Token SN：フルタイトル：トークンエンドIOスキーマBegin Index-INFO CN：1/BARBARA -1/J -1/BABS--*/ジェンセン-2/bjorn -3/gern -3/o -4/horatio -4/n sn： */jensenタイトル：1/製品-1-2/マネージャー-1/accounting -3,4/testpilot endIndex-info
version: x-tagged-index-1 updatetype: total thisupdate: 855938804 BEGIN IO-Schema cn: TOKEN sn: FULL title: TOKEN END IO-Schema BEGIN Index-Info cn: 1/Barbara -1/J -1/Babs
バージョン：X-Tagged-Index-1 updateType：合計thisupdate：8559388804 Begin io-schema cn：Token SN：フルタイトル：トークンエンドIOスキーマBegin Index-INFO CN：1/BARBARA -1/J -1/BABS
-*/Jensen -2/Bjorn -3/Gern -3/O -4/Horatio -4/N sn: */Jensen
- */ジェンセン-2/bjorn -3/gern -3/o -4/horatio -4/n sn： */jensen
title: 1/product -1-2/manager -1/accounting -3,4/testpilot END Index-Info
タイトル：1/Product -1-2/Manager -1/Accounting -3,4/TestPilot End Index -INFO
version: x-tagged-index-1 updatetype: total thisupdate: 855938804 BEGIN IO-Schema dn: FULL cn: TOKEN sn: FULL title: TOKEN END IO-Schema BEGIN Index-Info dn: 1/cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US -2/cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US -3/cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US -4/cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=US cn: 1/Barbara -1/J -1/Babs -*/Jensen -2/Bjorn -3/Gern -3/O -4/Horatio -4/N sn: */Jensen title: 1/product -1-2/manager -1/accounting -3,4/testpilot END Index-Info
バージョン：X-Tagged-Index-1 updateType：合計thisupdate：8559388804 Begin io-schema dn：full cn：token sn：フルタイトル：トークンエンドIo-schema Begin index-info dn：1/cn = Barbara Jensen、ou = ou =製品開発、O = ACE産業、C = US -2/CN = Bjorn Jensen、OU = Accounting、O = ACE産業、C = US -3/CN = Gern Jensen、OU =製品テスト、O = ACE産業、C= US -4/CN = Horatio Jensen、OU =製品テスト、O = ACE産業、C = US CN：1/BARBARA -1/J -1/BABS - */JENSEN -2/BJORN -3/GERN -3/o -4/horatio -4/n sn： */ジェンセンタイトル：1/product -1-2/manager -1/accounting -3,4/testpilot end index -info
Gern Jensen's entry above changes to:
上記のガーンジェンセンのエントリ：
dn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Gern Jensen
cn: Gern O Jensen
sn: Jensen
title: chiefpilot
version: x-tagged-index-1 updatetype: incremental lastupdate: 855940000 thisupdate: 855938804 BEGIN IO-schema cn: TOKEN sn: FULL title: FULL END IO-Schema BEGIN Update Block BEGIN Old cn: 1/Gern cn: 1/O cn: 1/Jensen sn: 1/Jensen title: 1/testpilot END Old BEGIN New cn: 1/Gern cn: 1/O cn: 1/Jensen sn: 1/Jensen title: 1/chiefpilot END New END Update Block
バージョン：X-Tagged-Index-1 UpdateType：Incremental LastUpdate：855940000 thisupdate：855938804 Begin io-Schema CN：Token SN：フルタイトCN：1/ジェンセンSN：1/ジェンセンタイトル：1/testpilot end old begin new cn：1/gern cn：1/o cn：1/jensen SN：1/ジェンセンタイトル：1/チーフパイロットエンド新エンド更新ブロックブロック
version: x-tagged-index-1 updatetype: incremental lastupdate: 855940000 thisupdate: 855938804 BEGIN IO-schema cn: TOKEN sn: FULL title: FULL END IO-Schema BEGIN Update Block BEGIN Old title: 3/testpilot END Old BEGIN New title: 3/chiefpilot END New END Update Block
バージョン：X-Tagged-Index-1 UpdateType：Incremental LastUpdate：855940000 thisupdate：855938804 Begin Io-Schema CN：Token SN：Full Title：Full End Io-Schema Begin Update Block Old Title：3/TestPilot End Old Old New Title Begin New Title：3/CHAIFHPILOT END NEW END UPDATEブロック
version: x-tagged-index-1 updatetype: incremental lastupdate: 855940000 thisupdate: 855938804 BEGIN IO-schema cn: TOKEN sn: FULL title: FULL END IO-Schema BEGIN Update Block BEGIN Old dn: 1/cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US title: 1/testpilot END Old BEGIN New dn: 1/cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US title: 1/chiefpilot END New END Update Block
バージョン：X-Tagged-Index-1 UpdateType：Incremental LastUpdate：855940000 thisupdate：855938804 Begin Io-Schema CN：Token SN：Full Title：Full End Io-Schema Begin Update Block Old Dn：1/Cn = Gern Jensen、OU OU=製品テスト、O = ACE業界、C =米国タイトル：1/testPilot End Old Old begin new dn：1/cn = Gern Jensen、ou =製品テスト、O = ACE産業、C =米国のタイトル：1/ChaifhPilot End New更新ブロックを終了します
# Add a new entry
dn: cn=Bo Didley, ou=Marketing, o=Ace Industry, c=US
changetype: add
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Bo Didley
sn: Didley
title: Policy Maker
# Delete an existing entry
dn: cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US
changetype: delete
# Modify all other entries: adding an additional locality value
dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
changetype: modify
add: locality
locality: New Jersey
dn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
changetype: modify
add: locality
locality: New Orleans
dn: cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=US
changetype: modify
add: locality
locality: New Caledonia
version: x-tagged-index-1 updatetype: incremental lastupdate: 855938804 thisupdate: 855939525 BEGIN IO-schema cn: TOKEN sn: FULL title: FULL locality: TOKEN END IO-Schema BEGIN Add Block cn: 1/Bo -1/Didley sn: 1/Didley title: 1/Policy -1/maker locality: 1/New -1/York END Add Block BEGIN Delete Block cn: 1/Bjorn -1/Jensen sn: 1/Jensen title: 1/Accounting -1/Manager END Delete Block BEGIN Update Block BEGIN Old cn: 1/Barbara -1/J -1-3/Jensen -2/Gern -2/O -3/Horatio sn: 1-3/Jensen title: 1/Production -1/Manager -2/Testpilot -3/Chiefpilot END Old BEGIN New cn: 1/Barbara -1/J -1-3/Jensen -2/Gern -2/O -3/Horatio
バージョン：X-Tagged-Index-1 updateType：増分lastUpdate：8559388804 thisupdate：855939525 Begin io-schema cn：トークンSN：フルタイトル：フル地域：トークンエンドIo-schemaはブロックCN：1/bo -1/didleySN：1/Didleyタイトル：1/ポリシー-1/メーカーの局所性：1/new -1/York End Add Block削除ブロックCN：1/Bjorn -1/Jensen SN：1/Jensenタイトル：1/アカウンティング-1/マネージャーエンド削除ブロックBEGIN UPDATE BLOCK BEGIN OLD CN：1/BARBARA -1/J -1-3/JENSEN -2/GERN -2/O -3/HORATIO SN：1-3/Jensenタイトル：1/プロダクション - 1/Manager -2/testPilot -3/chaifhpilot end old begin new cn：1/barbara -1/j -1-3/jensen -2/gern -2/o -3/horatio
sn: 1-3/Jensen title: 1/Production -1/Manager -2/Testpilot -3/Chiefpilot locality: 1/Jersey -2/Orleans -3/Caledonia -1-3/New END New END Update Block
SN：1-3/ジェンセンタイトル：1/プロダクション-1/マネージャー-2/testPilot -3/chieffilot地域：1/ジャージー-2/オルレアン-3/カレドニア-1-3/新しいエンド新しいエンドアップデートブロックブロック
version: x-tagged-index-1 updatetype: incremental lastupdate: 855938804 thisupdate: 855939525 BEGIN IO-schema cn: TOKEN sn: FULL title: FULL locality: TOKEN END IO-Schema BEGIN Add Block cn: 5/Bo -5/Didley sn: 5/Didley title: 5/Policy -5/maker locality: 5/New -5/York END Add Block BEGIN Delete Block cn: 2/Bjorn -2/Jensen sn: 2/Jensen title: 2/Accounting -2/Manager END Delete Block BEGIN Update Block BEGIN New locality: 1/Jersey -2/Orleans -4/Caledonia -1,2,4/New END New END Update Block
バージョン：x-tagged-index-1 updateType：増分lastupdate：8559388804 thisupdate：855939525 Begin io-schema cn：トークンSN：フルタイトル：完全地域：トークンエンドIo-schemaはブロックCN：5/BO -5/DidleySN：5/DIDLEYタイトル：5/ポリシー-5/メーカーの地域：5/new -5/York End Add delete Block cn：2/bjorn -2/Jensen SN：2/Jensenタイトル：2/会計-2 -2/マネージャーのエンド削除ブロックBEGIN UPDATE BLOCK BEGIN NEW LOCALITY：1/JERSEY -2/ORLEANS -4/CALEDONIA -1,2,4/NEW END NEW ENDアップデートブロック
version: x-tagged-index-1 updatetype: incremental lastupdate: 855938804 thisupdate: 855939525 BEGIN IO-schema cn: TOKEN sn: FULL title: FULL locality: TOKEN END IO-Schema BEGIN Add Block dn: 1/cn=Bo Didley, ou=Marketing, o=Ace Industry, c=US cn: 1/Bo -1/Didley sn: 1/Didley title: 1/Policy
バージョン：X-Tagged-Index-1 updateType：増分lastUpdate：8559388804 thisupdate：855939525 Begin io-schema cn：トークンSN：フルタイトル：完全地域：トークンエンドIo-schema Begin block dn：1/cn = bo Didley、OU =マーケティング、O = ACE業界、C =米国CN：1/BO -1/Didley SN：1/Didleyタイトル：1/ポリシー
-1/maker
locality: 1/New
-1/York
END Add Block
BEGIN Delete Block
dn: 1/cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US
END Delete Block
BEGIN Update Block
BEGIN New
dn: 1/cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
-2/cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
-3/cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=US
locality: 1/Jersey
-2/Orleans
-3/Caledonia
-1-3/New
END New
END Update Block
Aggregation of two tagged index objects is done by merging the two lists of values and rewriting each tag list. The tag list rewriting process is done so that the resulting index object appears as if it came from a single source. An index server that aggregates tagged index objects for export MUST ensure that the export URL (i.e. the base-uri of the CIP object) for the aggregate index object will route all queries that have "hits" on the index object to that server (otherwise, query routing will not succeed).
2つのタグ付きインデックスオブジェクトの集約は、値の2つのリストをマージし、各タグリストを書き換えることによって行われます。タグリストの書き換えプロセスは、結果のインデックスオブジェクトが単一のソースから来たかのように表示されるように行われます。エクスポート用にタグ付きインデックスオブジェクトを集約するインデックスサーバーは、AggregateインデックスオブジェクトのエクスポートURL（つまり、CIPオブジェクトのベースURI）が、インデックスオブジェクトに「ヒット」があるすべてのクエリをそのサーバーにルーティングすることを確認する必要があります（それ以外、クエリルーティングは成功しません）。
This specification provides a protocol for transferring information between two servers. The information transferred may be protected by laws in many countries, so care must be taken in the methods used to tokenize the data to ensure that protected data may not be reconstructed in full by the receiving server. This protocol does not have any inherent protection against spoofing or eavesdropping. However, since this protocol is transported in MIME messages (as are all CIP index objects), it inherits all the security capabilities and liabilities of other MIME messages. Specifically, those wanting to prevent eavesdropping or spoofing may use some of the various techniques for signing and encrypting MIME messages.
この仕様は、2つのサーバー間で情報を転送するためのプロトコルを提供します。転送された情報は多くの国で法律によって保護される可能性があるため、データをトークン化するために使用される方法には注意が必要です。このプロトコルには、スプーフィングや盗聴に対する固有の保護はありません。ただし、このプロトコルはMIMEメッセージ（すべてCIPインデックスオブジェクトと同様）で輸送されるため、他のMIMEメッセージのすべてのセキュリティ機能と負債を継承します。具体的には、盗聴やスプーフィングを防ぎたい人は、MIMEメッセージの署名と暗号化のためにさまざまな手法のいくつかを使用する場合があります。
Information Server administrators must decide what portions of their databases are appropriate for inclusion in the Tagged Index Object.
情報サーバー管理者は、タグ付きインデックスオブジェクトに含めるのに適切なデータベースの部分を決定する必要があります。
For distribution of information outside the enterprise, information server developers are encouraged to allow for facilities that hide the organizational structure when generating the Tagged Index Object from the underlying information database. To allow for the secure transmission of Tagged Index Objects across the Internet, Index Servers should make use of SSL when completing the connection. In order to strongly verify the identity of the peer index server on the other side of the connection, SSL version 3 certificate exchange should be implemented, and the identity in the peer's certificate verify with the Public Key Infrastructure. If electronic mail is used to exchange the Tagged Index Objects, then a secure messaging facility, such as PGP/MIME or S/MIME should be used to sign or encrypt (or both) the information.
エンタープライズ以外の情報を配布するために、情報サーバー開発者は、基礎となる情報データベースからタグ付きインデックスオブジェクトを生成するときに組織構造を隠す機能を可能にすることをお勧めします。インターネット全体でタグ付きインデックスオブジェクトを安全に送信できるようにするには、インデックスサーバーが接続を完了するときにSSLを使用する必要があります。接続の反対側にあるピアインデックスサーバーのIDを強く検証するには、SSLバージョン3証明書交換を実装する必要があり、ピアの証明書のIDは公開キーインフラストラクチャで確認されます。電子メールを使用してタグ付きインデックスオブジェクトを交換する場合、PGP/MIMEやS/MIMEなどの安全なメッセージング機能を使用して、情報に署名または暗号化（またはその両方）を使用する必要があります。
[1] Allen, J. and M. Mealling, "The Architecture of the Common Indexing Protocol (CIP)," RFC 2651, August 1999.
[1] Allen、J。and M. Mealling、「共通インデックスプロトコルのアーキテクチャ（CIP）」、RFC 2651、1999年8月。
[2] Weider, C., Fullton, J. and S. Spero, "Architecture of the Whois++ Index Service", RFC 1913, February 1996.
[2] Weider、C.、Fullton、J。およびS. Spero、「Whois Index Serviceのアーキテクチャ」、RFC 1913、1996年2月。
[3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[3] Wahl、M.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年12月。
[4] ITU, "X.525 Information Technology - Open Systems Interconnection - The Directory: Replication", November 1993.
[4] ITU、「X.525情報技術 - オープンシステムの相互接続 - ディレクトリ：レプリケーション」、1993年11月。
[5] "FORTEZZA Application Implementors Guide for the FORTEZZA Crypto Card (Production Version)", Document #PD4002102-1.01, SPYRUS, 1995.
[5] 「Fortezza Cryptoカード用のFortezzaアプリケーションの実装者ガイド（生産版）」、ドキュメント＃PD4002102-1.01、Spyrus、1995。
[6] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", Work in Progress.
[6] Good、G。、「LDAPデータインターチェンジ形式（LDIF） - 技術仕様」、進行中の作業。
[7] Hedberg, R., "LDAPv2 Client vs. the Index Mesh", RFC 2657, August 1999.
[7] Hedberg、R。、「LDAPV2クライアント対インデックスメッシュ」、RFC 2657、1999年8月。
[8] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
[8] Howes、T。およびM. Smith、「LDAP URL形式」、RFC 2255、1997年12月。
[9] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
[9] Elkins、M。、「Pretty Good Privacy（PGP）のMime Security」、RFC 2015、1996年10月。
[10] Ramsdell, B., Editor, "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[10] Ramsdell、B.、編集者、「S/Mimeバージョン3メッセージ仕様」、RFC 2633、1999年6月。
[11] Allen, C. and T. Dierks, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[11] Allen、C。およびT. Dierks、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
Roland Hedberg Catalogix Dalsveien 53 0387 Oslo Norway
Roland Hedberg Catalogix Dalsveien 53 0387 Oslo Norway
EMail: roland@catalogix.ac.se
Bruce Greenblatt Directory Tools and Application Services, Inc. 6841 Heaton Moor Drive San Jose, CA 95119 USA
Bruce GreenblattディレクトリツールおよびApplication Services、Inc。6841 Heaton Moor Drive San Jose、CA 95119 USA
Phone: +1-408-224-5349
EMail: bgreenblatt@directory-applications.com
Ryan Moats AT&T 15621 Drexel Circle Omaha, NE 68135-2358 USA
ライアン・モートAT＆T 15621ドレクセルサークルオマハ、NE 68135-2358 USA
Phone: +1 402 894-9456
EMail: jayhawk@att.com
Mark Wahl Innosoft International, Inc. 8911 Capital of Texas Hwy, Suite 4140 Austin, TX 78759 USA
Mark Wahl Innosoft International、Inc。8911 Capital of Texas Hwy、スイート4140オースティン、テキサス78759 USA
Phone +1 626 919 3600 EMail Mark.Wahl@innosoft.com
電話1 626 919 3600電子メールMark.wahl@innosoft.com
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エディター機能の資金は現在、インターネット協会によって提供されています。