RFC2654 日本語訳
2654 A Tagged Index Object for use in the Common Indexing Protocol. R.Hedberg, B. Greenblatt, R. Moats, M. Wahl. August 1999. (Format: TXT=46739 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループR.ヘドバーグの要求をネットワークでつないでください: 2654年のCatalogixカテゴリ: Inc.1999年8月の国際の実験的なB.グリーンブラットディレクトリツールとアプリケーション・サービスInc.のR.堀のAT&T M.ウォールInnosoft
A Tagged Index Object for use in the Common Indexing Protocol
Common Indexingプロトコルにおける使用のためのTagged Index Object
Status of this Memo
この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.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
このドキュメントは情報サーバがそれらのデータベースからCommon Indexingプロトコル(CIP)を利用することによって情報のインデックスリストを交換できるメカニズムを定義します。 このドキュメントは交換されるインデックス情報の構造を定義します、Common Indexingプロトコルで定義されるヘッダーのための適切な意味と同様に。 + + X.500 DSAs、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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 オブジェクト. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4。 タグ付けをされたインデックスオブジェクト. . . . . . . . . . . . . . . . . . . . 5 4.1。 協定. . . . . . . . . . . . . . . . . . . . . . . . 5 4.2。 content type. . . . . . . . . . . . . . . . . . . . . . . . 8 4.3はインデックスBNF. . . . . . . . . . . . . . . . . . . . . . . 9 4.3.1にタグ付けをしました。 ヘッダ記述. . . . . . . . . . . . . . . . . . . .10 4.3.2。 トークン化は.3に.4.3をタイプします。 コンベンション. . . . . . . . . . . . . . . . . . . . . .11 4.4にタグ付けをしてください。 増加のインデックス… .12
Hedberg, et al. Experimental [Page 1] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[1ページ]RFC2654Tagged Index Object
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
5. 例. . . . . . . . . . . . . . . . . . . . . . . . . . .13 5.1のオリジナルのデータベースの.5.1.1「完全な」一貫性に基づいている完全な最新版. . . . . . . . . .14 5.1の.2「タグ」一貫性ベースの完全なアップデート. . . . . . . . . . . .14 5.1.3の「ユニークな」一貫性ベースの完全なアップデート. . . . . . . . . . .15 5.2Firstアップデート. . . . . . . . . . . . . . . . . . . . . . . . .16 5.2.1の「完全な」一貫性はアップデート増加を基礎づけました; . . . . .16 5.2.2 「タグ」の一貫性はアップデート増加の「ユニークな」一貫性ベースのアップデート増加. . . . . . .17 5.3Second.5.2.3アップデート. . . . . . . . . . . . . . . . . . . . . . . .18 5.3.1の「完全な」一貫性一貫性が基礎づけたベースのアップデート増加. . . . . .18 5.3.2「タグ」アップデート増加. . . . . . . . .19 5.3.3の「ユニークな」一貫性に基づいているアップデート増加. . . . . . .20 6を基礎づけました。 タグ付けをされたインデックスオブジェクト. . . . . . . . . . . . .21 7の集合. . . . . . . . . . . . . . . . . . . . . . . . . .21 6.1集合。 セキュリティ問題. . . . . . . . . . . . . . . . . . . .21 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . .22 9。 作者のアドレス… .23の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . .24
1. Introduction
1. 序論
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]で定義されるCommon Indexingプロトコル(CIP)は、グローバルなディレクトリを作成するために単独のタイプのサーチエンジンのいくつかのインスタンスの向こう側に検索を広げるためにメカニズムを提案します。 CIPは、インターネットの成長で優雅に比例できる分散データ倉庫に個々のデータベースを結び付けるためにスケーラブルで、フレキシブルな体系を提供します。 CIPはこれらの目標を達成するためのインデックスリストの基礎となるデータにアクセスするのに使用されるアクセス法から独立しているメカニズムを提供します。 CIPから別々であるのは、Index Serversの中で交換される情報を含むのに使用されるIndex Objectの定義です。 既に定義されたそのようなIndex Objectの1つはWhois++プロトコル[2]から得られるCentroidです。
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
Centroidは情報サーバの中でインデックス情報の交換のためのすべての必要条件を満たすというわけではありません。 例えば、それはアップデート増加ネイティブの概念をサポートしません。 それが完全な状態でそれらのデータベース、一定の交換における何百万もの記録を含む情報サーバ、浚渫、データベースは帯域幅徹底的です。 Tagged Index Objectは、インデックスアップデート情報の交換をサポートするように明確に設計されています。 このデザインは交換されるインデックスオブジェクトのサイズの増加の費用で来ます。 また、Centroidは、いつも質問の論理演算子答えを与えることができるように仕立てられません。 Centroid Modelでは、「インデックスサーバは標準のWhois++形式で質問を取って、図心と他の前進の情報の収集を捜してください、そして、どのサーバがその質問をいっぱいにするかもしれない記録を保持するか、そして、その時を決定してください」
Hedberg, et al. Experimental [Page 2] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[2ページ]RFC2654Tagged Index Object
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.
「ユーザの連絡する次のサーバのクライアントが質問を提出するように通知します。」 [2] その結果、インデックスサーバの中のCentroidsの交換は、どの情報サーバが実際に情報を含むかに関してヒントが与えられているのを許容します。 Tagged Index Objectは個々のオブジェクト属性を全体でオブジェクトに結んで戻す識別子で様々な情報をラベルします。 インデックスサーバは情報のこの「タグ付け」で適切な情報サーバに特定の質問をより向けることができます。一方、この特徴はインデックスオブジェクトのサイズの増加を犠牲にしてTagged Index Objectに言い足されます。
2. Background
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]で定義されます、そして、それは階層的にaをグローバルに提供するほどそのような方法で配置された情報の収集にアクセスするためにメカニズムを定義します。通常、ディレクトリ情報Tree(DIT)と呼ばれる分散データベース。 LDAPサーバのいくつかの区別の特性は通常、いくつかのサーバが協力して、DITの一般的な下位木を管理するということです。 LDAPサーバがそれらにはデータがあるDITの一部に関係する要求に応じると予想されます、よくそれらがそれらのデータベースの情報を全く持っていないそれらの部分のように。 例えば、合衆国(cは米国と等しい)のDITの一部へのLDAPサーバはスウェーデン(c=se)でDITの一部に関係する検索操作への応答を提供できなければなりません。 通常、与えられた応答は適切な下位木に関して、より博識であると予想される別の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
推薦のX.500シリーズはX.500 DSAsがDITで情報交換できるディレクトリ情報Shadowingプロトコル(DISP)[4]を定義します。 シャドウイングは、DITの様々な部分からの様々な情報が参加DSAsの中で模写されるのを許容します。 DISPのデザイン先はDITの全体の部分の交換のときに改良されます、CIPとTagged Index Objectのデザイン先は、DITの構造指標情報の交換のときに最適化されて、様々な情報サーバの中で木のナビゲーションの性能を向上させていますが。 インデックス情報の交換には、Tagged Index ObjectはDISPより適切です。 DISPはDIT分配と欠点でさらに狙います。
Hedberg, et al. Experimental [Page 3] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[3ページ]RFC2654Tagged Index Object
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.
寛容。 その結果、データの交換には、DISPは、いくつかの情報サーバに負荷を広げるために、より適切です。 DISPは特にX.500(そして、他の階層化ディレクトリシステム)に仕立てられます、さまざまな情報サーバ環境でTagged Index Objectと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は以下を述べます。 「協定でありシャドウイングが起こることができる前にシャドウイングが起こるかもしれない状態をカバーするのが必要です。」 「そのような協定は与えられたDMDの中のすべてのDSAsをカバーする施政方針などのさまざまな方法で確立されるかもしれませんが」…, DMDがディレクトリManagement Domainであるところ。 これはDITのデータが交換されている情報だけよりむしろDSAがIndexを維持するのを必要としたケースのためにあります。 多くの環境で、そのような協定は適切ではありません、そして、DITの重要な部分のための情報を集めるために、多くの協定がアレンジされる必要があるかもしれません。
3. Object
3. オブジェクト
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 ?
- ティム・ハウズのEメールアドレスは何ですか? これがはるかに困難である、。 Netscapeにおけるティム・ハウズはどんなEメールアドレスを持っていますか?
- 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証明書は何ですか? 確かに、人は、1つの情報を見つけるためにコンピュ・サーブの全ディレクトリ木を捜したがっていません。 また、私は、全体のコンピュサーブディレクトリ下位木を私のサーバに影でおおわなければならなくて欲しいと思いません。フレッドが私のサーバにログインしようとしているのでこの要求をしているなら、確かに、リアルタイムでBINDに応じることができるようになりたいでしょう。
- 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
合理的にLDAPかWhoisの+ +の、そして、他のディレクトリアクセス・プロトコル質問にこれらのすべての要求を翻訳できます。 また、ソースデータを含むデータベースに適切な参考情報を持っているなら、ユーザホーム情報サーバは簡単な方法でそれらを修理できます。 ここで、最初のサーバはユーザを求める要求を「チェーニングできるでしょう」。 あるいはまた、正確な紹介を返すことができました。 ホーム情報サーバが要求がインデックスに基礎づけた(i.eチェーン)を修理したいなら
Hedberg, et al. Experimental [Page 4] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[4ページ]RFC2654Tagged Index Object
information that it has on hand, this servicing could be done several different means:
それが手、この整備点検のときに持っている情報にいくつかの異なった手段ができました:
- 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に発行します。
- ...
- ...
4. The Tagged Index Object
4. タグ付けをされたインデックスオブジェクト
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:
このセクションは情報ServersがCIPを使用することで交換できるTagged Index Objectを定義します。 しばしば、情報ServersがCentroid定義を利用するのは、許容できます。(インデックス情報を交換する[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.
- 情報Serverが紹介が返されるのを保証する検索要求を受け取ったら、サーバにたぶん正しく要求に答えることができるサーバにクライアントを向ける紹介を返させてください。 無病誤診紹介(検索はインデックスオブジェクトの必要な情報を保持しないサーバに紹介を生成するヒットを捜しあてる)を抑えることができます、使用された属性トークン化タイプの選択によって。
- Potentially allow incremental updates that will then consume
substantially less bandwidth then if full updates always had to
be used.
- 潜在的に次に完全なアップデートがいつも使用されなければならなかったならその時実質的により少ない帯域幅を消費するアップデート増加を許容してください。
4.1. The Agreement
4.1. 協定
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:
Tagged Index Objectを交換できる前に、オブジェクト供給者を管理する組織とオブジェクト消費者を管理する組織はサーバがどう交信するかに関する合意に達しなければなりません。 この協定は以下を含んでいます:
- "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」に含まれていることを超えて情報を提供しないかもしれないので、この分野は明らかに必要ではありません。
Hedberg, et al. Experimental [Page 5] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[5ページ]RFC2654Tagged Index Object
- "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.
- 「供給者」: ホスト名と供給者が入手できないなら文脈を命名しながらその同じことを保持するどんな代替のサーバと同様に供給者サーバのportnumberを聴くこと。
- "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": これがURIである、「mailto:」 消費者サーバのRFC822Eメールアドレスで形成してください。この草稿の今後のバージョンは他のフォームの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": アップデートを生成する供給者サーバのoccurancesの間の秒の最大の持続時間。 長い間これを待った後に前のアップデート以来消費者サーバが供給者サーバからアップデートを受けていないなら、インデックス情報が現在時代遅れであることは、ありそうです。 頻繁なアップデートがあるサーバのための典型的な値は604800秒、または毎週、そうでしょう。 DITsが毎年変更されるだけであるサーバははるかに長いアップデート間隔を過すかもしれません。
- "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までマッピングに同意しなければなりません。 1つの特定のインデックスサーバがそのような数セットにかかわるかもしれないので、それには、適切なセットのインデックスにアップデートを関連づける何らかの方法がなければなりません。 これへの1つの可能なソリューションは異なった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.
「タグ」--アップデートして、あらゆるアップデート増加が完全なアップデートのときにこれにいっぱいにreferingして戻られ始めると、タグの州の情報は保守されなければなりません、同じtagnumberが毎回オリジナルのデータベースの中のオブジェクトに割り当てられるように。 このメソッドは任意です。
Hedberg, et al. Experimental [Page 6] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[6ページ]RFC2654Tagged Index Object
"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.
「ユニーク」--Datasetのあらゆるオブジェクトには、インデックスの特定の属性のためのユニークな値がなければなりません。 そのような属性に関する例は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]
"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"、これらが供給者と消費者の証明書になる、」
Hedberg, et al. Experimental [Page 7] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[7ページ]RFC2654Tagged Index Object
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つのインデックスサーバのコミュニケーションに必要である情報がディレクトリから自動的に得られることに注意してください。
4.2. Content Type
4.2. content type
The update consists of a MIME object of type application/cip-index- object. The parameters are:
アップデートはタイプ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。」 空間によって切り離された1セットの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
From: supplier@sup.com 日付: 木曜日、1997年1月16日の13:50:37 -0500メッセージイド: <199701161850.NAA29295@sup.com>。 To: consumer@consumer.com 、lt;、消費者サーバアドレスからの<。
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"
reply-to supplier-admin@sup.com MIMEバージョン: 1.0コンテントタイプ: アプリケーション/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。 ベース-uriは「ldap://sup.com/dcが一口と等しく、dc=com ldap://alt.com/dcは一口、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の印刷可能な米国ASCII部分集合を生成することができるだけであるかもしれませんが、属性値(以下のBNFの「attr-値」分野の)を解読するとき、すべての消費者サーバが最大限の範囲のユニコード文字を扱うことができなければなりません。
Hedberg, et al. Experimental [Page 8] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[8ページ]RFC2654Tagged Index Object
4.3. Tagged Index BNF
4.3. タグ付けをされたインデックスBNF
The Tagged Index object has the following grammar, expressed in modified BNF format:
Tagged Indexオブジェクトには、変更された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>;
インデックスオブジェクト=0*(io-部分9月)io-部分のio-一部=ヘッダー9月図式仕様9月インデックスインフォメーションヘッダー=バージョン仕様9月のアップデートタイプ9月、これ、-、アップデート、9月のアップデート文脈サイズ名前空間9月のバージョン仕様=、「バージョン:」 *SPACE、「xのインデックスの1インチのタグ付けをされた最新版のタイプ=は「以下を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-naスペース..値..系列..値..タグ付け..タグ..タグ..ケタ..ケタ..値..命名..タイムスタンプ..ケタ..ケタ..覚醒剤..下ろす..スペース..等しい..ASCII..スペース..等しい..等しい..ASCII..復帰..等しい..ASCII..改行
Hedberg, et al. Experimental [Page 9] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[9ページ]RFC2654Tagged Index Object
DIGIT = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
ケタ=「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"
上側の=「A」| 「B」| 「C」| 「D」| 「E」| 「F」| 「G」| 「H」| 「私」| 「J」| 「K」| 「L」| 「M」| 「N」| 「○」| 「P」| 「Q」| 「R」| 「S」| 「T」| 「U」| 「V」| 「W」| 「X」| 「Y」| 「Z」下側の=“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
米国ASCII金庫=%のx01-09/%のx0B-0C/%のx0E-7F。 CRを除いて、米国のASCIIです、LF、NUL UTF8=米国ASCII金庫/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-名前欄に現れることができたキャラクタのセットは+ + 属性が命名するLDAPとWHOISで使用されるキャラクタのセットに制限されます。 これらより大きい属性名前文字集合を持っている他のサービスのために、それらのサービスはオブジェクト識別子に名前を写像するプロフィールを作成するべきです、そして、ケタと期間の系列はそれらのTagged Index Objectsのために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.
タグ付けをされたインデックスオブジェクト自体によって指定されたオーダーでタグ付けをされたインデックスオブジェクトに基づくインデックスへのアップデートを実行しなければならないと言及する価値があります。
4.3.1. Header Descriptions
4.3.1. ヘッダ記述
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のために供給者サーバによって消費者サーバに送られた最初のアップデートは「総」アップデートであるに違いありません。
Hedberg, et al. Experimental [Page 10] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[10ページ]RFC2654Tagged Index Object
"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日協定世界時0時0分0秒からの秒数です。
"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日協定世界時0時0分0秒からの秒数です。 この分野で、消費者は、前のアップデートが逃されたかどうかと決心できます。
"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する"です: この系列は供給者の選択で存在しているかもしれません。 値は数です。(その数は下位木で、大体の総数のエントリーです)。 この情報を統計的な目的だけに提供します。
4.3.2. Tokenization Types
4.3.2. トークン化タイプ
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.
Tagged Index Objectは[2]の指定されるとしてのトークン化の「トークン」体系を引き継ぎます。 さらに、Tagged Index Objectのために定義された他のいくつかのトークン化体系があります。 以下のテーブルは、これらに体系を提示して、キャラクタが区切るのに使用されることにトークンを提示します。
Token Type Tokenization Characters
FULL none
TOKEN white space, "@"
RFC822 white space, ".", "@"
UUCP white space, "!"
DNS any character note a number, letter, or "-"
「TOKEN白いなにも区切らないトークンType TokenizationキャラクターFULL、「@」 RFC822余白」。」、"@"UUCPはスペース、“!"を空白にします。 DNSは数、文字、または「-」というあらゆるキャラクタ注意です。
4.3.3. Tag Conventions
4.3.3. タグコンベンション
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インチが短くされるかもしれない、「310インチ、」 タグはエントリーレベルあたりのaに関するデータに適用されることになっています。 したがって、同じインデックスオブジェクトの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.
完全なインデックスの2つの別々の送信における同じ基本的な記録に適用されたタグは異なっているかもしれません。 したがって、インデックスサーバを受け取ると、タグの値に関する仮定は全くインデックスオブジェクト限界の向こう側にされるべきではありません。
Hedberg, et al. Experimental [Page 11] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[11ページ]RFC2654Tagged Index Object
4.4. Incremental Indexing
4.4. 増加のインデックス
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がタグ付けをされたインデックスオブジェクトで指定されるなら、インデックスオブジェクトは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 Blockを含んでいるなら、Add Blockの系列は伝わっているインデックスサーバの情報ベースに加えられた新しい記録を示します。それらの記録がどんな以前に容認されたタグ付けをされたインデックスオブジェクトにも存在しなかったのを保証できて、受信インデックスサーバはそれが伝わっているインデックスサーバのために既に維持するインデックスにこのインデックス情報を挿入できます。
If the tagged index object contains a Delete Block, then the structure of the Delete Block depends on how the consistency is maintained;
タグ付けをされたインデックスオブジェクトがDelete Blockを含んでいるなら、Delete Blockの構造を一貫性がどう維持されるかに依存します。
- "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.
タグ付けをされたインデックスオブジェクトがUpdate Blockを含んでいるなら、Update Blockの系列は伝わっているインデックスサーバの情報ベースの中で変えられた記録を呼びます。一方、ブロックの特定の内容は一貫性がどう維持されるかによります。
- "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は変化したトークンと共に含まれなければなりません。
Hedberg, et al. Experimental [Page 12] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[12ページ]RFC2654Tagged Index Object
- "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.
また、Update Blockは以前にタグ付けをされたインデックスオブジェクトに含まれていなかった新しい属性に索引をつけるという考えをサポートします。 例えば、伝わっているインデックスサーバが郵便の宛先のインデックス情報を含み始めるなら、それは、情報ベースの中のすべての記録のための郵便の宛先のすべてのインデックス情報を含んでいたインデックスオブジェクトにUpdate Blockを含んで、他に何もが変化しなかったのを示すかもしれないでしょうに。
5. Examples
5. 例
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]形式で提示されます。
5.1 The original database
5.1 オリジナルのデータベース
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
dn: cnはバーバラ・ジェンセンと等しく、ouは製品Developmentと等しく、oはエースIndustry、c=米国objectclassと等しいです: 最高objectclass: 人のobjectclass: organizationalPerson cn: バーバラジェンセンcn: バーバラJジェンセンcn: バブスジェンセンsn: ジェンセンuid: bjensen dn: cnはビヨン・ジェンセンと等しく、ouは会計と等しく、oはエースIndustry、c=米国objectclassと等しいです: 最高objectclass: 人のobjectclass: organizationalPerson cn: ビヨンジェンセンsn: ジェンセンタイトル: 経理担当重役dn: cn=Gernジェンセン、製品ou=Testing、oはエースIndustry、c=米国objectclassと等しいです: 最高objectclass: 人のobjectclass: organizationalPerson cn: Gernジェンセンcn: Gern Oジェンセンsn: ジェンセンタイトル: testpilot dn: cnはホレイショー・ジェンセンと等しく、ouは製品Testingと等しく、oはエースIndustry、c=米国objectclassと等しいです: トップ
Hedberg, et al. Experimental [Page 13] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[13ページ]RFC2654Tagged Index Object
objectclass: person objectclass: organizationalPerson cn: Horatio Jensen cn: Horatio N Jensen sn: Jensen title: testpilot
objectclass: 人のobjectclass: organizationalPerson cn: ホレイショージェンセンcn: ホレイショーNジェンセンsn: ジェンセンタイトル: testpilot
5.1.1 "Complete" consistency based full update
5.1.1 「完全な」一貫性は完全なアップデートを基礎づけました。
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タグ付けをされたインデックス1updatetype: thisupdateを合計してください: 855938804 BEGIN IO-図式cn: TOKEN sn: FULLタイトル: TOKEN END IO-図式BEGIN Index-インフォメーションcn: 1/バーバラ-1/J-1/バブス-*/ジェンセン-2/ビヨン-3/Gern-3/O-4/ホレイショー-4/N sn: */ジェンセンタイトル: 1/製品-1-2/マネージャ-1/会計-3、4/testpilot終わりのインデックスインフォメーション
5.1.2 "tag" consistency based full update
5.1.2 「タグ」の一貫性は完全なアップデートを基礎づけました。
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タグ付けをされたインデックス1updatetype: thisupdateを合計してください: 855938804 BEGIN IO-図式cn: TOKEN sn: FULLタイトル: TOKEN END IO-図式BEGIN Index-インフォメーションcn: 1/バーバラ-1/J-1/バブス
Hedberg, et al. Experimental [Page 14] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[14ページ]RFC2654Tagged Index Object
-*/Jensen -2/Bjorn -3/Gern -3/O -4/Horatio -4/N sn: */Jensen
-*/ジェンセン-2/ビヨン-3/Gern-3/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終わりのインデックスインフォメーション
5.1.3 "unique" consistency based full update
5.1.3 「ユニークな」一貫性は完全なアップデートを基礎づけました。
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タグ付けをされたインデックス1updatetype: thisupdateを合計してください: 855938804 BEGIN IO-図式dn: FULL cn: TOKEN sn: FULLタイトル: TOKEN END IO-図式BEGIN Index-インフォメーションdn: 1/cn=バーバラ・ジェンセン、ouは製品Developmentと等しいです、o=エースIndustry、ビヨン・c=米国-2/cn=ジェンセン、ou=会計、o=エースIndustry、米国の-3/cn=Gern c=ジェンセン、製品ou=Testing、o=エースIndustry、ホレイショー・c=米国-4/cn=ジェンセン、製品ou=Testing、o=エースIndustry、米国c=cn: 1/バーバラ-1/J-1/バブス-*/ジェンセン-2/ビヨン-3/Gern-3/O-4/ホレイショー-4/N sn: */ジェンセンタイトル: 1/製品-1-2/マネージャ-1/会計-3、4/testpilot終わりのインデックスインフォメーション
Hedberg, et al. Experimental [Page 15] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[15ページ]RFC2654Tagged Index Object
5.2 First update
5.2/1アップデート
Gern Jensen's entry above changes to:
Gernジェンセンの上のエントリーは以下のことのために変化します。
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=Testing、oはエースIndustry、c=米国objectclassと等しいです: 最高objectclass: 人のobjectclass: organizationalPerson cn: Gernジェンセンcn: Gern Oジェンセンsn: ジェンセンタイトル: chiefpilot
5.2.1 First update using "complete"
5.2.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 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タグ付けをされたインデックス1updatetype: 増加のlastupdate: 855940000thisupdate: 855938804 BEGIN IO-図式cn: TOKEN sn: FULLタイトル: FULL END IO-図式BEGIN Update Block BEGIN Old cn: 1/Gern cn: 1/O cn: 1/ジェンセンsn: 1/ジェンセンタイトル: 1/testpilot END Old BEGIN New cn: 1/Gern cn: 1/O cn: 1/ジェンセンsn: 1/ジェンセンタイトル: 1/chiefpilot端の新しい端のアップデートブロック
Hedberg, et al. Experimental [Page 16] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[16ページ]RFC2654Tagged Index Object
5.2.2 First update using "tag" consistency
5.2.2 「タグ」の一貫性を使用する最初のアップデート
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タグ付けをされたインデックス1updatetype: 増加のlastupdate: 855940000thisupdate: 855938804 BEGIN IO-図式cn: TOKEN sn: FULLタイトル: FULL END IO-図式BEGIN Update Block BEGIN Oldタイトル: 3/testpilot END Old BEGIN Newタイトル: 3/chiefpilot端の新しい端のアップデートブロック
5.2.3 First update using "unique" ID's
5.2.3 「ユニークな」IDのものを使用する最初のアップデート
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タグ付けをされたインデックス1updatetype: 増加のlastupdate: 855940000thisupdate: 855938804 BEGIN IO-図式cn: TOKEN sn: FULLタイトル: FULL END IO-図式BEGIN Update Block BEGIN Old dn: 1/cn=Gernジェンセン、製品ou=Testing、oはエースIndustry、c=米国タイトルと等しいです: 1/testpilot END Old BEGIN New dn: 1/cn=Gernジェンセン、製品ou=Testing、oはエースIndustry、c=米国タイトルと等しいです: 1/chiefpilot端の新しい端のアップデートブロック
Hedberg, et al. Experimental [Page 17] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[17ページ]RFC2654Tagged Index Object
5.3 Second update
5.3 2番目のアップデート
# 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
# 新しいエントリーdnを加えてください: cnは棒Didleyと等しく、ouはマーケティングと等しく、oはエースIndustry、c=米国changetypeと等しいです: objectclassを加えてください: 最高objectclass: 人のobjectclass: organizationalPerson cn: ボーDidley sn: Didleyタイトル: 既存のエントリーがdnする方針Maker#Delete: cnはビヨン・ジェンセンと等しく、ouは会計と等しく、oはエースIndustry、c=米国changetypeと等しいです: #Modifyを削除してください、他のすべてのエントリー: 追加場所値のdnを加えます: cnはバーバラ・ジェンセンと等しく、ouは製品Developmentと等しく、oはエースIndustry、c=米国changetypeと等しいです: 変更、加えます: 場所場所: ニュージャージーdn: cn=Gernジェンセン、製品ou=Testing、oはエースIndustry、c=米国changetypeと等しいです: 変更、加えます: 場所場所: ニューオリンズdn: cnはホレイショー・ジェンセンと等しく、ouは製品Testingと等しく、oはエースIndustry、c=米国changetypeと等しいです: 変更、加えます: 場所場所: ニューカレドニア
5.3.1 "complete"
5.3.1 「完全です」。
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タグ付けをされたインデックス1updatetype: 増加のlastupdate: 855938804thisupdate: 855939525 BEGIN IO-図式cn: TOKEN sn: FULLタイトル: FULL場所: TOKEN END IO-図式BEGIN Add Block cn: 1/ボー-1/Didley sn: 1/Didleyタイトル: 1/方針-1/メーカー場所: 1/新しい-1/ヨーク
Hedberg, et al. Experimental [Page 18] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[18ページ]RFC2654Tagged Index Object
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 Add Block BEGIN Delete Block cn: 1/ビヨン-1/ジェンセンsn: 1/ジェンセンタイトル: 1/会計-1/マネージャEND Delete Block BEGIN Update Block BEGIN Old cn: 1/バーバラ-1/J-1-3/ジェンセン-2/Gern-2/O-3/ホレイショーsn: 1-3/ジェンセンタイトル: 1/生産-1/マネージャ-2/Testpilot-3/Chiefpilot END Old BEGIN New cn: 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/Testpilot-3/Chiefpilot場所: 1/ジャージー新しい終わりの-2/オルレアン-3/カレドニア-1-3/新しい端のアップデートブロック
5.3.2 "tag"
5.3.2 「タグ」
version: x-tagged-index-1 updatetype: incremental lastupdate: 855938804 thisupdate: 855939525 BEGIN IO-schema
バージョン: xタグ付けをされたインデックス1updatetype: 増加のlastupdate: 855938804thisupdate: 855939525はIO-図式を始めます。
Hedberg, et al. Experimental [Page 19] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[19ページ]RFC2654Tagged Index Object
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
cn: TOKEN sn: FULLタイトル: FULL場所: TOKEN END IO-図式BEGIN Add Block cn: 5/ボー-5/Didley sn: 5/Didleyタイトル: 5/方針-5/メーカー場所: 5/新しい-5/ヨークEND Add Block BEGIN Delete Block cn: 2/ビヨン-2/ジェンセンsn: 2/ジェンセンタイトル: 2/会計-2/マネージャEND Delete Block BEGIN Update Block BEGIN New場所: -2/オルレアン1/ジャージー新しい終わりの-1、2、4歳の-4/カレドニア/新しい端のアップデートブロック
5.3.3 "unique"
5.3.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 dn: 1/cn=Bo Didley, ou=Marketing, o=Ace Industry, c=US cn: 1/Bo -1/Didley sn: 1/Didley title: 1/Policy
バージョン: xタグ付けをされたインデックス1updatetype: 増加のlastupdate: 855938804thisupdate: 855939525 BEGIN IO-図式cn: TOKEN sn: FULLタイトル: FULL場所: TOKEN END IO-図式BEGIN Add Block dn: 1/cn=棒Didley、ou=マーケティング、oはエースIndustry、c=米国cnと等しいです: 1/ボー-1/Didley sn: 1/Didleyタイトル: 1/方針
Hedberg, et al. Experimental [Page 20] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[20ページ]RFC2654Tagged Index Object
-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 Add Block BEGIN Delete Block dn: 1/cn=エース会計、ビヨン・ジェンセン、ou=o=Industry、c=米国END Delete Block BEGIN Update Block BEGIN New dn: 1/cn=バーバラ・ジェンセン、ouは製品Developmentと等しいです、o=エースIndustry、米国の-2/cn=Gern c=ジェンセン、製品ou=Testing、o=エースIndustry、ホレイショー・c=米国-3/cn=ジェンセン、製品ou=Testing、o=エースIndustry、米国c=場所: 1/ジャージー新しい終わりの-2/オルレアン-3/カレドニア-1-3/新しい端のアップデートブロック
6. Aggregation
6. 集合
6.1. Aggregation of Tagged Index Objects
6.1. タグ付けをされたインデックスオブジェクトの集合
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個のタグ付けをされたインデックスオブジェクトの集合をします。 結果として起こるインデックスオブジェクトがまるで単独のソースから来るかのように見えるように、プロセスを書き直すタグリストをします。 輸出のためにタグ付けをされたインデックスオブジェクトに集められるインデックスサーバは、集合インデックスオブジェクトのための輸出URL(すなわち、CIPについてuriを基礎づけオブジェクト)がインデックスオブジェクトの上に「ヒット」をそのサーバに持っているすべての質問を発送するのを確実にしなければなりません(さもなければ、質問ルーティングは成功しないでしょう)。
7. Security Considerations
7. セキュリティ問題
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つのサーバの間に情報を移すのにプロトコルを提供します。 移された情報が多くの国に法で保護されるかもしれないので、メソッドで保護されたデータが受信サーバによってすべて再建されないかもしれないのを保証するためにデータをtokenizeするのにおいて使用されていた状態で注意しなければなりません。このプロトコルは少しの固有の保護もスプーフィングか盗聴に抱きません。 しかしながら、このプロトコルがMIMEメッセージ(すべてのCIPインデックスオブジェクトのような)で輸送されるので、それは他のMIMEメッセージのすべてのセキュリティ能力と負債を引き継ぎます。 明確に、盗み聞くか、またはだますのを防ぎたがっている人は、MIMEメッセージに署名して、暗号化するのに様々なテクニックのいくつかを使用するかもしれません。
Information Server administrators must decide what portions of their databases are appropriate for inclusion in the Tagged Index Object.
情報Server管理者は、Tagged Index Objectでの包含に、それらのデータベースのどんな部分が適切であるかを決めなければなりません。
Hedberg, et al. Experimental [Page 21] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[21ページ]RFC2654Tagged 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.
企業の外での情報の流通において、情報サーバ開発者が基本的な情報データベースからTagged Index Objectを生成するとき組織体制を隠す施設を考慮するよう奨励されます。 接続を終了するとき、インターネットの向こう側にTagged Index Objectsの安全なトランスミッションを考慮するために、Index ServersはSSLを利用するはずです。 強くアイデンティティについて確かめるには、接続の反対側の上の同輩インデックスサーバ、交換が実装されるべきであるSSLバージョン3証明書、および同輩の証明書のアイデンティティでは、Publicと共にKey Infrastructureについて確かめてください。 電子メールがTagged Index Objectsを交換するのに使用されるなら、PGP/MIMEかS/MIMEなどの安全なメッセージング施設は、情報を署名するか、または暗号化すること(ともに)に使用されるべきです。
8. References
8. 参照
[1] Allen, J. and M. Mealling, "The Architecture of the Common
Indexing Protocol (CIP)," RFC 2651, August 1999.
[1] アレンとJ.とM.食事、「一般的なインデックスプロトコル(CIP)のアーキテクチャ」、RFC2651、1999年8月。
[2] Weider, C., Fullton, J. and S. Spero, "Architecture of the
Whois++ Index Service", RFC 1913, February 1996.
[2] ワイダーとC.とFulltonとJ.とS.スペロウ、「Whois++インデックスサービスのアーキテクチャ」、RFC1913、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)」、RFC2251 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.
「LDAPデータは形式(LDIF)を交換します--技術的な仕様。」[6] いいぞ、G.、仕事進行中です。
[7] Hedberg, R., "LDAPv2 Client vs. the Index Mesh", RFC 2657,
August 1999.
[7] ヘドバーグ、R.、「LDAPv2クライアント対インデックスメッシュ」、RFC2657、1999年8月。
[8] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
December 1997.
[8] ハウズとT.とM.スミス、「LDAP URL形式」、RFC2255、1997年12月。
[9] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC
2015, October 1996.
[9] エルキンズ、M.、「プリティ・グッド・プライバシ(PGP)があるMIMEセキュリティ」、RFC2015、1996年10月。
[10] Ramsdell, B., Editor, "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.
[10]Ramsdell、B.、エディタ、「S/MIMEバージョン3メッセージ仕様」、RFC2633、1999年6月。
Hedberg, et al. Experimental [Page 22] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[22ページ]RFC2654Tagged Index Object
[11] Allen, C. and T. Dierks, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[11] アレン、C.、およびT.Dierks、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
9. Authors' Addresses
9. 作者のアドレス
Roland Hedberg Catalogix Dalsveien 53 0387 Oslo Norway
ローランドヘドバーグCatalogix Dalsveien53 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
ブルースグリーンブラットディレクトリツールとアプリケーション・サービスInc.6841ヒートン・荒野Driveサンノゼ(カリフォルニア)95119米国
Phone: +1-408-224-5349 EMail: bgreenblatt@directory-applications.com
以下に電話をしてください。 +1-408-224-5349 メールしてください: bgreenblatt@directory-applications.com
Ryan Moats AT&T 15621 Drexel Circle Omaha, NE 68135-2358 USA
ライアン・モウツAT&T15621ドレクセル・円のNE68135-2358オマハ(米国)
Phone: +1 402 894-9456 EMail: jayhawk@att.com
以下に電話をしてください。 +1 402 894-9456 メールしてください: jayhawk@att.com
Mark Wahl Innosoft International, Inc. 8911 Capital of Texas Hwy, Suite 4140 Austin, TX 78759 USA
Hwy、4140年のテキサススイートテキサス78759オースチン(米国)のマークウォールInnosoftの国際Inc.8911Capital
Phone +1 626 919 3600 EMail Mark.Wahl@innosoft.com
+1 3600年の626 919メール Mark.Wahl@innosoft.com に電話をしてください。
Hedberg, et al. Experimental [Page 23] RFC 2654 Tagged Index Object for use in CIP August 1999
ヘドバーグ、他 CIP1999年8月の使用のための実験的な[23ページ]RFC2654Tagged Index Object
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Hedberg, et al. Experimental [Page 24]
ヘドバーグ、他 実験的[24ページ]
一覧
スポンサーリンク
