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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（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は別には、インデックスサーバ間で交換される情報を含むために使用されるインデックスオブジェクトの定義です。すでに定義されている一つのそのような索引オブジェクトは、フーイズ++プロトコル[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.
重心は、情報サーバ間でのインデックス情報を交換するためのすべての要件を満たしていません。例えば、それはネイティブに差分更新の概念をサポートしていません。そのデータベース内のレコードの数百万人が含まれている情報サーバの場合、データベースの完全な浚渫機の定数交換は、帯域幅集約的です。タグ付きのインデックスオブジェクトは、具体的には、インデックスの更新情報の交換をサポートするように設計されています。この設計は、交換されているインデックスオブジェクトのサイズの増大を犠牲にしています。重心は、常にクエリにブール答えを与えることができるように調整されていません。重心モデルでは、「インデックスサーバは、標準のWhois ++形式でクエリを取る重心や他の転送情報のそのコレクションを検索、サーバはそのクエリを埋めることがレコードを保持するかを決定し、その後に、次のサーバーのユーザーのクライアントに通知しますクエリを提出するお問い合わせください。」 [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の部分に関連する要求に応答することが期待されます。たとえば、米国（C = US）でDITの部分のためのLDAPサーバは、スウェーデンのDITの一部（= SE C）に関連する検索操作への応答を提供できなければなりません。通常、与えられた応答は、適切なサブツリーの詳細知識が豊富であることが予想され、他のLDAPサーバへの紹介になります。しかし、現在、おそらくより多くの知識のあるサーバーにLDAPクライアントを参照するために、これらのLDAPサーバを有効メカニズムはありません。一般的に、LDAP（V3）のサーバは、その要求がそのLDAPサーバが知識を持っているDITのサブツリーから外れたときに、すべてのLDAPクライアントが参照されているに他の1台のLDAPサーバーの名前で構成されています。この仕様は、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シリーズ[4] X.500のDSAはDIT内の情報を交換することを可能にするディレクトリ情報シャドウイングプロトコル（DISP）を定義します。シャドウイングは、DITの様々な部分からの様々な情報が参加のDSA間で複製されることを可能にします。 DISPの設計点は、CIPおよびタグ付きインデックスオブジェクトの設計点に対しDITに関する構造索引情報の交換に最適化され、各種の中ツリーナビゲーションの性能を向上して、DITの全体部分の交換で改善されています情報サーバ。タグ付きのインデックスオブジェクトは、DISPよりも、インデックス情報を交換するためのより適切です。 DISPは、より多くのDIT分布とフォールトトレランスを対象としています。 DISPは、このようにいくつかの情報をサーバ間で負荷を分散するために、データを交換するためのより適切です。タグ付きインデックスオブジェクトとCIPを情報サーバ環境の広範囲で使用することができるがDISPは、X.500（および他の階層ディレクトリシステム）に特異的に調整されます。
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 ?
- ティム・ハウズのメールアドレスとは何ですか？これは、よりはるかに困難です。ネットスケープのティム・ハウズは何のメールアドレスを持っていますか？
- 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のフレッド・スミスのためのX.509証明書とは何ですか？一つは、確かに情報のこの一枚を見つけるためにCompuServeのディレクトリツリー全体を検索する必要はありません。私も自分のサーバー上に全体のCompuServeディレクトリサブツリーをシャドウする必要がありますする必要はありません。フレッドは私のサーバーにログインしようとしているため、この要求が行われている場合は、私は確かに、リアルタイムでBINDに応えることができるようにしたいと思います。
- Who are all the people at Novell that have a title of programmer?
- プログラマのタイトルを持っているNovellのすべての人は誰ですか？
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の++、およびその他のディレクトリアクセスプロトコルクエリに変換することができます。それは、ソースデータが含まれているデータベースに適切な参照情報を持っているなら、彼らはまた、ユーザーホームサーバにより直接的な方法でサービスを提供することができます。ここでは、最初のサーバは、「チェーン」のユーザーの要求にできるようになります。また、正確な紹介を返すことができます。ホームサーバは、（すなわちチェーン）、それは手に持っているインデックス情報に基づいて要求を処理したい場合は、このサービスは、いくつかの異なる手段を行うことができます。
- 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.
- インフォメーションサーバーが照会が返されることを保証する検索要求を受信すると、サーバは最も可能性の高い要求を正しく答えることができているサーバーにクライアントを指します紹介を返すことができます。偽陽性の紹介は、（検索が必要な情報を保持していないサーバーへの紹介を生成するインデックスオブジェクトでヒットをアップになります）使用されている属性のトークン化の種類の選択に応じて、減少させることができます。
- 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-タグ付けされたインデックス-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).
- 「ベース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」：コンシューマサーバのRFC 822電子メールアドレスと、フォーム：これは「のmailto」のURIです。消費者は、WWW、FTPまたはCIP経由でアップデートを取得できるように、この草案の更なるバージョンは、URIの他の形態を可能にします。
- "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」：更新を生成サプライヤサーバのoccurances間の秒の最大継続時間。コンシューマサーバが長い前回の更新以降、これを待ってサプライヤサーバから更新を受信していない場合は、インデックス情報が古くなって、今である可能性があります。頻繁に更新してサーバーの典型的な値は604800秒、または毎週でしょう。そのディレクトリ情報ツリーだけで毎年変更されているサーバーは、はるかに長い更新間隔を持つことができます。
- "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.
- 「attributeNamespace」：一緒にindecesの特定の使用をサポートしたいインデックスサーバーのすべてのセットは、索引オブジェクトで使用するattributenamesた上で同意する必要があります。参加ディレクトリサーバーは、インデックスで使用attributenamesへのローカルattributenamesからのマッピングに同意する必要があります。一つの特定のインデックスサーバーは、いくつかのようなセットに関与しているかもしれないので、それはインデックスの適切なセットに更新を接続するためのいくつかの方法を持っている必要があります。これに対する一つの可能な解決策は、異なるDSISを使用することです。
- "consistencybase": How consistency of the index is maintained over incremental updates:
- 「consistencybase」：インデックスの整合性を増分更新にわたって維持される方法：
"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.
"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.
「ユニーク」 - データセット内のすべてのオブジェクトは、インデックス内の特定の属性に一意の値を持っている必要があります。そのような属性の例としては、distinguishedName属性である可能性があります。この方法はまた、任意です。
- "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]
「フォルテッツァ」：更新をデジタルフォルテッツァを使用して署名し、暗号化されている[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鍵を持っています。 「フォルテッツァ」オプションは、セキュリティプロトコルは、フォルテッツァ・互換性のあるデバイスに基づいている環境での使用を目的としています。 「S / MIME」オプションは、RSAキーサプライヤーと消費者の両方に持って使用することができ、S / MIMEの仕様で定義されたPKCSプロトコルを利用することができます。 「のSSLv3」オプションはサプライヤーと消費者の両方が、SSLサービスへのアクセスを持っているサーバ証明書を持っているときに使用することができ、かつ相互に認証することができます。
- 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、」これは、両方のサーバーの信頼された公開鍵となります。 「フォルテッツァ、」これは信頼の共通点に両方のサーバーの証明書のパスになります。 「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.
The update consists of a MIME object of type application/cip-index-object. The parameters are:
更新は、タイプapplication / CIPインデックスオブジェクトのMIMEオブジェクトで構成されています。パラメータは次のとおりです。
"type": this has value "application/index.obj.tagged".
「タイプ」：これは値「アプリケーション/ 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」。スペースで区切られたURIのセット。各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
投稿者：supplier@sup.com日：木、1997年1月16日午前13時50分37秒-0500メッセージ-ID：<199701161850.NAA29295@sup.com>。 << consumer@consumer.com - コンシューマサーバのアドレスから：へ
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-値」フィールドに（Unicode文字の完全な範囲を扱うことができなければなりません以下の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"
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"
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 = "" | "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
US-ASCII-SAFE =％x01-09 /％X0B-0C /％x0E-7F ;; CR、LF、除くUS-ASCII 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 ++属性名に使用される文字セットに制限されています。これらよりも大きい名前の文字セットを属性を持つ他のサービスでは、これらのサービスは、オブジェクト識別子に名前をマップし、数字とピリオドのシーケンスは、そのためのattr-名前のフィールドを作成する際に、これらのサービスで使用されるプロファイルを作成する必要がありますタグ付けされた索引オブジェクト。
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-タグ付けされたインデックス-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の」：この行は常に存在している必要があります。値は、供給者がこの更新プログラムを構築した時00:00:00 1970年1月1日からの秒数です。
"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
「最終更新日」：「UPDATETYPE」リストに値「増分」を持っている場合は、この行が存在しなければなりません。値は、サプライヤが、消費者に送信された以前の更新を構築した時00:00:00 1970年1月1日からの秒数です。このフィールドは、前回の更新が失われた場合、消費者が決定することができます
"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 "-"
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ということです。
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.
フルインデックスの二つの別々の送信において同じ基本レコードに適用されるタグは異なっていてもよいです。このように、受信したインデックスサーバーは、インデックスオブジェクトの境界を越えてタグの値についての仮定を行うべきではありません。
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つの基本タイプをサポートしています。増分UPDATETYPEがタグ付けされたインデックスオブジェクトに指定されている場合、索引オブジェクトは、最終更新日ヘッダーで指定されたインデックスオブジェクトが配布された以降に行われた変更のみのスナップショットを含んでいます。受信側インデックスサーバーは、そのインデックスオブジェクトを受信しなかった場合は、総インデックスオブジェクトを要求すべきです。 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.
タグ付けされたインデックスオブジェクトがブロックを追加含まれている場合は、[追加ブロック内の行は、送信インデックスサーバの情報ベースに追加された新しいレコードを参照してください。これらのレコードは、以前に受信したタグ付きのインデックスオブジェクトには存在しなかったことを保証することができ、受信インデックスサーバは、それがすでに送信インデックスサーバーの維持インデックスで、このインデックス情報を挿入することができます。
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.
- 「completeRecord」：レコードに接続されているすべてのトークンが含まれなければならない削除する、このメッセージにトークンを接続するために使用されるタグは、以前に送信されたタグ付けされたインデックスのオブジェクトに使用されるタグとは関係を持ちません。
- "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.
- 「completeRecord」：すべてのレコードの古いバージョンを表すトークンだけでなく、新しいものが含まれることがあります。
- "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.
- 「tagBased」：のみ変更トークンが含まれているが、その後1と同様に、新しいものがあった場合は、両方の古いバージョンでは、1つがあります。
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.
以下のセクションでは、それぞれ異なるconsistencybaseタイプについて、タグ付けされた索引オブジェクトは、次のシナリオで表されます。例は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
DN：CN =バーバラ・ジェンセン、OU =製品開発、O =エース産業、C = USオブジェクトクラス：トップオブジェクトクラス：人物オブジェクトクラス：organizationalPersonをCN：バーバラ・ジェンセンCN：バーバラJジェンセンCN：バブスジェンセンSN：ジェンセンのUID：bjensenのDN： CN =ビョルン・ジェンセン、OU =会計、O =エース産業、C = USオブジェクトクラス：トップオブジェクトクラス：人物オブジェクトクラス：organizationalPersonをCN：ビョルン・ジェンセンSN：ジェンセンタイトル：経理マネージャーのDN：CN = Gernジェンセン、OU =製品テスト、O =エース産業、C = USオブジェクトクラス：トップオブジェクトクラス：人物オブジェクトクラス：organizationalPersonをCN：GernジェンセンCN：Gern OジェンセンSN：ジェンセン・タイトル：testpilotます。dn：CN =ホレイショ・ジェンセン、OU =製品テスト、O =エース産業、C =米国のオブジェクトクラス：トップオブジェクトクラス：人物オブジェクトクラス：organizationalPersonをCN：ホレイショジェンセンCN：ホレイショNジェンセンSN：ジェンセン・タイトル：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タグインデックス-1 UPDATETYPE：総thisUpdateの：855938804は、IO-スキーマCNをBEGIN：TOKENのSN：FULLタイトル：1 /バーバラ-1 / J -1 /バブス - ：TOKEN END IO-スキーマ索引情報CNをBEGIN * /ジェンセン-2 /ビヨン-3 / Gern -3 / O -4 /ホレイショ-4 / NのSN：* /ジェンセンタイトル：1 /製品-1-2 /マネージャ-1 / -3,4 / testpilot ENDを占め索引情報
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タグインデックス-1 UPDATETYPE：総thisUpdateの：855938804は、IO-スキーマCNをBEGIN：TOKENのSN：FULLタイトル：1 /バーバラ-1 / J -1 /バブス：TOKEN END IO-スキーマ索引情報CNをBEGIN
-*/Jensen -2/Bjorn -3/Gern -3/O -4/Horatio -4/N sn: */Jensen
- * /ジェンセン-2 /ビヨン-3 / -3 Gern / O -4 / -4ホレイショ/ N SN * /イェンセン
title: 1/product -1-2/manager -1/accounting -3,4/testpilot END Index-Info
タイトル：1 /製品-1-2 /マネージャー-1 / -3,4 / testpilot END索引情報を占めます
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タグインデックス-1 UPDATETYPE：総thisUpdateのトークンSNを：FULL CN：855938804は、IO-スキーマDNをBEGIN FULLタイトル：TOKEN END IO-スキーマ索引情報DNをBEGIN：1 / CN =バーバラ・ジェンセン、OU =製品開発、O =エース産業、C = US -2 / CN =ビヨンジェンセン、OU =会計、O =エース産業、C = US -3 / CN = Gernジェンセン、OU =製品テスト、O =エース産業、C = US -4 / CN =ホレイショジェンセン、OU =製品テスト、O =エース産業、C = US CN：1 /バーバラ-1 / J -1 /バブス - * /ジェンセン-2 /ビヨン-3 / Gern -3 / O -4 / -4ホレイショ/ N SN：* /ジェンセン・タイトル：1 /製品-1-2 /マネージャー-1 /占め-3,4- / testpilot ENDの索引情報
Gern Jensen's entry above changes to:
への変更上記Gern Jensenのエントリ：
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
DN：CN = Gernジェンセン、OU =製品テスト、O =エース産業、C = USオブジェクトクラス：トップオブジェクトクラス：personオブジェクト・クラス：organizationalPersonをCN：GernジェンセンCN：Gern OジェンセンSN：ジェンセン・タイトル：チーフパイロット
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-タグ付けされたインデックス-1 UPDATETYPE：インクリメンタル最終更新日：855940000 thisUpdateの：855938804はBEGIN IO-スキーマCN：TOKEN SN：FULLタイトル：1 / Gern CN：FULL END IO-スキーマは、更新ブロックは、旧CN BEGIN BEGIN 1 / O CN：1 /ジェンセンSN：1 /ジェンセンタイトル：1 END旧BEGIN新CN testpilot /：1 / Gern CN：1 / O CN：1 /ジェンセンSN：1 /ジェンセンタイトル：1 / chiefpilot END新END更新ブロック
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-タグ付けされたインデックス-1 UPDATETYPE：インクリメンタル最終更新日：855940000 thisUpdateの：855938804はBEGIN IO-スキーマCN：TOKEN SN：FULLタイトル：3 / END旧testpilot新しいタイトルをBEGIN：FULL END IO-スキーマが更新ブロックが古いタイトルをBEGIN BEGIN ：3 / chiefpilot END新END更新ブロック
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タグインデックス-1 UPDATETYPE：インクリメンタル最終更新日：855940000 thisUpdateの：855938804開始IO-スキーマCN：TOKEN SN：FULLタイトル：FULL END IO-スキーマ更新ブロックはBEGIN BEGIN DN旧：1 / CN = Gernジェンセン、OU =製品テスト、O =エース産業、C = USのタイトル：testpilot 1 / END旧BEGIN新しいDN：1 / CN = Gernジェンセン、OU =製品テスト、O =エース産業、C = USのタイトル：1 / chiefpilot END新END更新ブロック
# 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
CN =ボーDidley、OU =マーケティング、O =エース産業、C = USの変更タイプ：オブジェクトクラスを追加：トップオブジェクトクラス：人のオブジェクトクラス：organizationalPersonをCN：ボーDidley SN：Didleyタイトル：ポリシーメーカーは、＃削除＃新しいエントリのDNを追加します。既存のエントリのDN：CN =ビョルン・ジェンセン、OU =会計、O =エース産業、C = USの変更タイプ：＃変更に他のすべてのエントリを削除：追加の地域値dnを追加します。cn =バーバラ・ジェンセンが、OU =製品開発、O =エース産業、C = USの変更タイプ：アドオンを変更します。地域の地域：ニュージャージー州のDN：CN = Gernジェンセン、OU =製品テスト、O =エース産業、C = USの変更タイプ：地域の地域：ニューオーリンズのDN：CN =ホレイショアドオンを変更ジェンセン、OU =製品テスト、O =エース産業、C = USの変更タイプ：地域の地域：ニューカレドニアアドオンを変更
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
バージョン：X-タグ付けされたインデックス-1 UPDATETYPE：インクリメンタル最終更新日：855938804 thisUpdateの：855939525はBEGIN IO-スキーマCN：TOKEN SN：FULLタイトル：FULL地域：1 /ボー-1 / Didley：TOKEN END IO-スキーマがブロックCNを追加BEGIN SN：1 / Didleyタイトル：1 /ポリシー-1 /メーカー産地：1 /新-1 /ニューヨーク
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
END追加ブロックは、ブロックのcnを削除BEGIN：1 /ビョルン・-1 /ジェンセンSN：1 /ジェンセン・タイトル：1 /バーバラ-1 / J -1-3：1 /経理-1 /マネージャーENDブロックが更新ブロックは、旧CN BEGIN BEGIN削除/ジェンセン-2 / Gern -2 / O -3 /ホレイショSN：1-3 /ジェンセンタイトル：1 /生産-1 /マネージャー-2 / Testpilot -3 / Chiefpilot END旧新CN BEGIN：1 /バーバラ-1 / J -1-3 /イェンセン-2 / Gern -2 / O -3 /ホレイショ
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 / -3 Testpilot / Chiefpilot産地：1 /ジャージー-2 / -3オーリンズ/カレドニア-1-3 /新END新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 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タグインデックス-1 UPDATETYPE：インクリメンタル最終更新日：855938804 thisUpdateの：855939525開始IO-スキーマCN：TOKEN SN：FULLタイトル：FULLローカリティ：5 /ボー-5 / Didley：TOKEN END IO-スキーマブロックCNを追加BEGIN SN：5 / Didleyタイトル：5 /ポリシー-5 /メーカー産地：5 /新-5 /ニューヨークENDはブロックを追加ブロックCN削除BEGIN：2 /ビョルン-2 /イェンセンSN：2 /ジェンセン・タイトル：2 /会計-2 1 /ジャージー-2 / -4オーリンズ/カレドニア-1,2,4 /新END新END更新ブロック：/マネージャーENDはブロックが更新ブロックが新しい局所性をBEGIN BEGIN削除します
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-タグ付けされたインデックス-1 UPDATETYPE：インクリメンタル最終更新日：855938804 thisUpdateの：TOKENのSN：855939525は、IO-スキーマCNをBEGIN FULLタイトル：FULL地域：TOKEN END IO-スキーマがブロックDN追加BEGIN：1 / CN =ボーDidleyを、 OU =マーケティング、O =エース産業、C = US CN：1 /ボー-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
-1 /メーカー産地：1 /新-1 /ニューヨークENDがブロックを追加ブロックDNを削除BEGIN：1 / CN =ビョルン・ジェンセン、OU =会計は、エース産業= O、C = US ENDはブロックが更新ブロックは、新しいDNをBEGIN BEGIN削除します。 1 / CN =バーバラ・ジェンセン、OU =製品開発、O =エース産業、C = US -2 / CN = Gernジェンセン、OU =製品テスト、O =エース産業、C = US -3 / CN =ホレイショジェンセン、OU =製品テスト、O =エース産業、C = USの地域：1 /ジャージー-2 / -3オーリンズ/カレドニア-1-3 /新END新END更新ブロック
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つのタグ付けされたインデックスオブジェクトの集合は、値の二つのリストをマージし、各タグリストを書き換えることによって行われます。それは単一のソースから来たかのように結果のインデックスオブジェクトが表示されるように、タグリスト書き換え処理が行われます。輸出用のタグ付けされた索引オブジェクトを集約インデックスサーバーは確保しなければならないことを集約インデックスオブジェクトのための意志ルートそのサーバーにインデックスオブジェクトの「ヒット」を持っているすべてのクエリが（そうでない場合（ベースURI CIPオブジェクトのIE）輸出URL 、クエリルーティング）は成功しません。
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つのサーバー間で情報を転送するためのプロトコルを提供します。ケアは、保護されたデータは、受信サーバでフルに再構築することがないことを保証するために、データをトークン化するために使用される方法に注意する必要がありますので、転送された情報は、多くの国の法律によって保護されていてもよいです。このプロトコルは、なりすましや盗聴に対する任意の固有の保護を持っていません。 （すべてのCIPインデックスオブジェクトであるとして）このプロトコルは、MIMEメッセージで搬送されているのでしかし、それはすべてのセキュリティ機能と他の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の使用をしなければなりません。強く、接続の反対側のピアインデックスサーバーの身元を確認するために、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]アレン、J.とM. Mealling、 "共通インデックスプロトコル（CIP）のアーキテクチャ、" RFC 2651年8月1999年。
[2] Weider, C., Fullton, J. and S. Spero, "Architecture of the Whois++ Index Service", RFC 1913, February 1996.
[2]ウイダー、C.、Fullton、J.とS.スペロ、 "Whoisの建築++インデックスサービス"、RFC 1913、1996年2月。
[3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[3]ワール、M.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル（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暗号カード（生産版）FORTEZZAアプリケーションの実装者ガイド"、ドキュメント＃PD4002102-1.01、SPYRUS、1995。
[6] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", Work in Progress.
[6]グッド、G.、 "LDAPデータ交換フォーマット（LDIF） - 技術仕様" が進行中で働いています。
[7] Hedberg, R., "LDAPv2 Client vs. the Index Mesh", RFC 2657, August 1999.
[7]ヘドバーグ、R.、 "インデックスメッシュ対のLDAPv2クライアント"、RFC 2657、1999年8月。
[8] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
[8]ハウズ、T.およびM.スミス、 "LDAPのURLの形式"、RFC 2255、1997年12月。
[9] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
[9]エルキンズ、M.、 "プリティグッドプライバシーとMIMEセキュリティ（PGP）"、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]アレン、C.およびT.ダークス、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
Roland Hedberg Catalogix Dalsveien 53 0387 Oslo Norway
ローランドヘドバーグCatalogix Dalsveien 53 0387オスロノルウェー
EMail: roland@catalogix.ac.se
メールアドレス：roland@catalogix.ac.se
Bruce Greenblatt Directory Tools and Application Services, Inc. 6841 Heaton Moor Drive San Jose, CA 95119 USA
ブルース・グリーンブラットDirectoryツールおよびアプリケーション・サービス株式会社6841ヒートンムーアドライブサンノゼ、CA 95119 USA
Phone: +1-408-224-5349 EMail: bgreenblatt@directory-applications.com
電話：+ 1-408-224-5349 Eメール：bgreenblatt@directory-applications.com
Ryan Moats AT&T 15621 Drexel Circle Omaha, NE 68135-2358 USA
ライアン・モーツAT＆T 15621ドレクセルサークルオマハ、ネブラスカ68135から2358 USA
Phone: +1 402 894-9456 EMail: jayhawk@att.com
電話：+1 402 894-9456 Eメール：jayhawk@att.com
Mark Wahl Innosoft International, Inc. 8911 Capital of Texas Hwy, Suite 4140 Austin, TX 78759 USA
マーク・ワールInnosoftの国際株式会社8911テキサス州ハイウェイの首都、スイート4140オースティン、TX 78759 USA
Phone +1 626 919 3600 EMail Mark.Wahl@innosoft.com
電話+1 626 919 3600 EメールMark.Wahl@innosoft.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。