RFC2968 日本語訳
2968 Mesh of Multiple DAG servers - Results from TISDAG. L. Daigle, T.Eklof. October 2000. (Format: TXT=19306 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Daigle Request for Comments: 2968 T. Eklof Category: Informational October 2000
Daigleがコメントのために要求するワーキンググループL.をネットワークでつないでください: 2968年のT.Eklofカテゴリ: 情報の2000年10月
Mesh of Multiple DAG servers - Results from TISDAG
Multiple DAGサーバのメッシュ--TISDAGからの結果
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
The Common Indexing Protocol ([CIP1]) is designed to facilitate the creation not only of query referral indexes, but also of meshes of (loosely) affiliated referral indexes. The purpose of such a mesh of servers is to implement some kind of distributed sharing of indexing and/or searching tasks across different servers. So far, the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) project ([TISDAG], [DAGEXP]) has focused on creating a single referral index; the obvious next step is to integrate that into a larger set of interoperating services.
Common Indexingプロトコル([CIP1])は、質問紹介インデックスだけではなく、(緩く)合併された紹介インデックスのメッシュについて作成を容易にするように設計されています。 サーバのそのようなメッシュの目的は異なったサーバの向こう側にタスクを索引をつける、そして/または、捜すある種の分配された共有を実装することです。 今までのところ、TISDAG(スウェーデンのディレクトリAccess Gatewaysのための技術的なInfrastructure)は[TISDAG]を予測して、[DAGEXP)は、ただ一つの紹介インデックスを作成するのは焦点を合わせました。 次の明白なステップはサービスを共同利用するより大きいセットとそれを統合することです。
1. Introduction
1. 序論
1.1 Overview of mesh possibilities
1.1 メッシュの可能性の概要
Two different possibilities are possible for extending the TISDAG service to a mesh model (or some combination of both). First, it should be possible to create a mesh of DAG-based services. Or, it might be interesting to use the mesh architecture to incorporate access to other types of services (e.g., the Norwegian Directory of Directories). In either case, the basic principle for establishing a mesh is that interoperating services should exchange index objects, according to the architecture of the mesh (e.g., hierarchical, or graph-like, preferably without loops!).
メッシュモデル(または、両方の何らかの組み合わせ)に対するTISDAGサービスを広げるのに、2つの異なった可能性が可能です。 まず最初に、DAGベースのサービスのメッシュを作成するのは可能であるべきです。 または、他のタイプのサービス(例えば、ディレクトリのノルウェーのディレクトリ)へのアクセスを取り入れるのにメッシュアーキテクチャを使用するのはおもしろいかもしれません。 どちらかの場合では、メッシュを設立するための基本原理はサービスを共同利用するとインデックスオブジェクトが交換されるべきであるということです、メッシュのアーキテクチャによると(例えば、階層的であるか、グラフのようで!、望ましくは、輪なしで)
As is outlined in the CIP documentation ([CIP1]), many possibilities exist for mechanisms for creating indexes over multiple referral servers -- for example, WDSP index objects could be passed along
CIPドキュメンテーション([CIP1])に概説されているように、多くの可能性が複数の紹介サーバの上にインデックスを作成するためのメカニズムのために存在しています--例えば、WDSPインデックスオブジェクトを回すことができました。
Daigle & Eklof Informational [Page 1] RFC 2968 Mesh of Multiple DAG servers October 2000
Multiple DAGサーバ2000年10月のDaigle&Eklof Informational[1ページ]RFC2968Mesh
untouched, or a referral index server's contents could be aggregated into a new index object, generating referrals back to that server.
触れなさ、紹介インデックスサーバのコンテンツは新しいインデックスオブジェクトに集められて、そのサーバに紹介を生成して戻すのをそうすることができました。
The proposal is that the mesh should be constructed using index objects aggregated over participating services' servers. That is, referrals will be generated to other recognized services, not their individual participants. This can be done as a hierarchy or a level mesh one-layer deep, but the important reason for not simply passing forward index objects (unaggregated) is that individual services may support different ranges of access protocols, have particular security requirements, etc. Referrals should be directed to a CAP or CAPs -- either the standard ones used by the DAG system, or new ones established to support particular semantics of remote systems (e.g., other query types, etc). Within a given DAG system, referrals to these remote servers will look just like any other referral, although a particular SAP or SAPs may be established to provide query fulfillment (again, to enable translations between variations of service, to allow secure access if the relationship between the services is restricted, etc).
提案はメッシュが参加サービスのサーバの上で集められたインデックスオブジェクトを使用することで組み立てられるべきであるということです。 すなわち、紹介は彼らの個々の関係者ではなく、他の認識されたサービスに生成されるでしょう。 階層構造か平らなメッシュとして1層であることの形でこれが深くできますが、インデックスオブジェクト(「非-集合」であった)を絶対に前方へパスしない重要な理由は個々のサービスが異なった範囲のアクセス・プロトコルをサポートして、特定のセキュリティ要件を持っているかもしれないのなどということです。 紹介はCAPかCAPsに向けられるべきです--DAGシステムによって使用される標準のものかリモートシステムの特定の意味論をサポートするために確立された新しいもの(例えば、他の質問タイプなど)のどちらか。 与えられたDAGシステムの中では、これらのリモートサーバへの紹介はまさしくいかなる他の紹介にも似るでしょう、特定のSAPかSAPsが質問遂行を供給するために設立されるかもしれませんが(一方、サービスの変化の間の翻訳を可能にするために、サービスの間の関係であるなら安全なアクセスを許すのは制限されますなど)。
In the following scenarios of mesh traversal, the assumption is that the primary service in discussion (Country A in Scenario 1, Country B in Scenario 2) is a DAG-based service. The scenarios are presented in the light of interoperating DAG services, but in most cases it would be equally applicable if the remote service was provided by some other service architecture. Again, the key element for establishing a mesh of any sort is the exchange of the CIP index object, not internal system architecture.
メッシュ縦断の以下のシナリオでは、仮定は議論(Scenario1の国A、Scenario2のCountry B)における一次業務がDAGベースのサービスであるということです。 DAGサービスを共同利用することの見地からシナリオは提示されますが、ある他のサービスアーキテクチャでリモートサービスを提供するなら、多くの場合、等しく適切でしょうに。 一方、どんな種類のメッシュも設立するための主要な要素は内部のシステム構築ではなく、CIPインデックスオブジェクトの交換です。
1.1.1 Scenario 1: Top Down
1.1.1 シナリオ1: トップダウン
Suppose 2 countries tie their services together. A user makes a query in Country A. A certain number of hits are made against the index objects of A's WDSPs. There is also a hit in the aggregate index of Country B. There are 3 possible cases under which this must be handled:
2つの国が彼らのサービスを結びつけると仮定してください。 ユーザはAのWDSPsのインデックスオブジェクトに対して命中した数をするのを確信しているCountry A.Aで質問をします。 また、Country B.の集合インデックスにはヒットがあります。Thereはこれを扱わなければならない3つの可能な場合です:
Case 1:
ケース1:
Country A and Country B are running services that are essentially the same -- in terms of protocols, queries, and schema that are supported. In this case, one referral should be generated per protocol supported by Country B's service. The referral can be passed back as far as the client, if its protocol supports referrals. Alternatively, the CAP may chain the referral through an appropriate SAP, in the usual fashion. In other words, the CAPs of Country B's service act as WDSPs to Country A's service.
国AとCountry Bはサポートされるプロトコル、質問、および図式で本質的には同じサービスを実行しています。 この場合紹介がCountryビーズのサービスでサポートされたプロトコル単位で生成されるべきであるもの。 プロトコルが紹介をサポートするなら、クライアントと同じくらい遠くに紹介を戻すことができます。 あるいはまた、CAPは適切なSAPを通して普通のファッションで紹介をチェーニングするかもしれません。 言い換えれば、CountryビーズのサービスのCAPsはWDSPsとしてCountry Aのサービスに機能します。
Daigle & Eklof Informational [Page 2] RFC 2968 Mesh of Multiple DAG servers October 2000
Multiple DAGサーバ2000年10月のDaigle&Eklof Informational[2ページ]RFC2968Mesh
Consider the following illustration (only relevant CAPs, SAPs, etc, are shown; others suppressed for lack of room):
↓これがイラストであると考えてください。(関連CAPs、SAPsだけなどが示されます; 余地の不足によって抑圧された他のもの):
+-----------------+
(1) |-----+ Country A | +-------+
------>|Prot1| DAG | |A-WSDP1|
<------| CAP | +-----| | Prot1 |
(2) |-----+ |Prot1| +-------+
| | SAP |
----+ | +-----| +-------+
(3)| | +-------+ | |A-WDSP2|
| | | RI-A | | | Prot1 |
| +-----------------+ +-------+
|
| +-------+
| |A-WDSP3|
| | Prot2 |
+----------------+ +-------+
| [...]
|
| +-----------------+
| |-----+ Country B | +-------+
+-------->|Prot1| DAG | |B-WSDP1|
| CAP | +-----| | Prot2 |
|-----+ |Prot1| +-------+
| | SAP |
| +-----| +-------+
| +-------+ | |B-WDSP2|
| | RI-B | | | Prot1 |
+-----------------+ +-------+
[...]
+-----------------+ (1) |-----+ 国A| +-------+ ------>|Prot1| 縁飾り| |1WSDP1です。| <、-、-、-、-、--、| 上限| +-----| | Prot1| (2) |-----+ |Prot1| +-------+ | | SAP| ----+ | +-----| +-------+ (3)| | +-------+ | |1WDSP2です。| | | | ロードアイランド-A| | | Prot1| | +-----------------+ +-------+ | | +-------+ | |1WDSP3です。| | | Prot2| +----------------+ +-------+ | [...] | | +-----------------+ | |-----+ 国B| +-------+ +-------->|Prot1| 縁飾り| |B-WSDP1| | 上限| +-----| | Prot2| |-----+ |Prot1| +-------+ | | SAP| | +-----| +-------+ | +-------+ | |B-WDSP2| | | ロードアイランド-B| | | Prot1| +-----------------+ +-------+ [...]
where
Prot[i] is some particular query protocol
RI-A has an index over all A-WDSP[i] and RI-B
RI-B has an index over all B-WDSP[i]
(1) is the query to the Country A DAG system, which
yields a referral based on the index object from RI-B
(2) is that referral
(3) is the resolution of that referral, which the client takes
to the Country B DAG system directly (to find out which, if
any, B-WDSP[i] have relevant information)
ロードアイランド-AはすべてのA-WDSP[i]の上にProt[i]が何らかの特定の質問プロトコルであるところにインデックスを持っています、そして、ロードアイランド-Bロードアイランド-Bはインデックスを家に迎えます。すべてのB-WDSP[i](1)がCountry A DAGシステムへの質問である、紹介がどの利回りをロードアイランド-B(2)からインデックスオブジェクトに基礎づけたかによる紹介(3)がその紹介の解決であるということである、クライアントは直接Country B DAGシステムに取ります。(もしあればどれを見つけるかために、B-WDSP[i]には、関連情報があります)
Daigle & Eklof Informational [Page 3] RFC 2968 Mesh of Multiple DAG servers October 2000
Multiple DAGサーバ2000年10月のDaigle&Eklof Informational[3ページ]RFC2968Mesh
Case 2:
ケース2:
Country A and Country B are running services that address the same service type (e.g., whitepages), but are not using an identical collection of protocols, allowed queries, or schema. The index object that Country B sent to Country A's DAG service must be constructed in terms of Country A's service, in order for appropriate hits to be generated against the index object (i.e. for referrals to Country B's service). However, to resolve the referral, it will be necessary to do some further protocol/schema/query mapping. This can be done by a special SAP established within Country A's service, that maps Country A's service into the published service of Country B. Country A may then elect to support only one of Country B's access protocols, and the designated SAP will always contact one type of CAP at Country B.
国AとCountry Bは同じサービスタイプが(例えば、whitepages)であると扱いますが、質問が許されたプロトコルの同じ収集を使用していないサービスを実行するか、図式です。 Country AのサービスでCountry BがCountry AのDAGサービスに送ったインデックスオブジェクトを組み立てなければなりません、適切なヒットがインデックスオブジェクト(すなわち、Countryビーズのサービスへの紹介のための)に対して生成されるために。 しかしながら、紹介を決議するために、何らかのさらなるプロトコル/図式/質問マッピングをするのが必要でしょう。 Country Aのサービスの中に設立された特別なSAPはこれができます、そして、それはサポートする次にCountry AがCountryビーズアクセス・プロトコルの1つだけを選ぶかもしれないCountry B.の発行されたサービスにCountry Aのサービスを写像します、そして、指定されたSAPはいつもCAPの1つのタイプにCountry Bへ連絡するでしょう。
Alternatively, Country B can establish a particular CAP that does the mapping from Country A's service into something that is most appropriate against the internal structure of its service. In this case, Country A's referral will be to a special CAP in Country B's service (which, again, will look like a WDSP to the Country A service); in fact, the referral may be handled directly by the client software. The difference between the two possible approaches lies in the responsibility of managing the relationship between the 2 service types. On the one hand, Country A could handle it if it knows its service as well as the published access to Country B. On the other, Country B could be responsible for establishing a CAP for every country that may want to connect to it. The latter can, in some cases, be justified by the amount of internal optimization that can be done, and because it reduces the overhead for Country A's service (can pass the referral directly back to the client software).
あるいはまた、Country Bは内部のサービスの構造に対して最も適切な何かにCountry Aのサービスからのマッピングを翻訳する特定のCAPを設立できます。 この場合、Countryビーズのサービス(再びCountry AサービスにWDSPに似る)には特別なCAPにはCountry Aの紹介があるでしょう。 事実上、紹介は直接クライアントソフトウェアによって扱われるかもしれません。 2つのサービスタイプの間の関係を管理する責任には2つの可能なアプローチの違いがあります。 一方では、他のCountry B.OnのCountry Bへの発行されたアクセスと同様にサービスがそれに接続したがっているかもしれないあらゆる国にCAPを設立するのに原因となるかもしれないのを知っているなら、Country Aはそれを扱うかもしれません。 して、それがCountry Aのサービス(直接クライアントソフトウェアに紹介を戻すことができる)のためにオーバーヘッドを下げるので、いくつかの場合、それが内部の最適化であることができることの量は後者を正当化できます。
Consider the following illustration (only relevant CAPs, SAPs, etc, are shown; others suppressed for lack of room):
↓これがイラストであると考えてください。(関連CAPs、SAPsだけなどが示されます; 余地の不足によって抑圧された他のもの):
Daigle & Eklof Informational [Page 4] RFC 2968 Mesh of Multiple DAG servers October 2000
Multiple DAGサーバ2000年10月のDaigle&Eklof Informational[4ページ]RFC2968Mesh
+-----------------+
(1) |-----+ Country A | +-------+
------>|Prot1| DAG | |A-WSDP1|
<------| CAP | +-----| | Prot1 |
(2) |-----+ |Prot1| +-------+
| | SAP |
----+ | +-----| +-------+
(3)| | +-------+ | |A-WDSP2|
| | | RI-A | | | Prot1 |
| +-----------------+ +-------+
|
| +-------+
| |A-WDSP3|
| | Prot2 |
+----------------+ +-------+
| [...]
|
| +-----------------+
| |-----+ Country B | +-------+
| |Prot3| DAG | |B-WSDP1|
| | CAP | +-----| | Prot3 |
| |-----+ |Prot3| +-------+
| |---------+ | SAP |
| |Country A| +-----|
+-------->|CAP:Prot1| |
|---------+ | +-------+
| +-------+ | |B-WDSP2|
| | RI-B | | | Prot3 |
+-----------------+ +-------+
[...]
+-----------------+ (1) |-----+ 国A| +-------+ ------>|Prot1| 縁飾り| |1WSDP1です。| <、-、-、-、-、--、| 上限| +-----| | Prot1| (2) |-----+ |Prot1| +-------+ | | SAP| ----+ | +-----| +-------+ (3)| | +-------+ | |1WDSP2です。| | | | ロードアイランド-A| | | Prot1| | +-----------------+ +-------+ | | +-------+ | |1WDSP3です。| | | Prot2| +----------------+ +-------+ | [...] | | +-----------------+ | |-----+ 国B| +-------+ | |Prot3| 縁飾り| |B-WSDP1| | | 上限| +-----| | Prot3| | |-----+ |Prot3| +-------+ | |---------+ | SAP| | |国A| +-----| +-------->|上限: Prot1| | |---------+ | +-------+ | +-------+ | |B-WDSP2| | | ロードアイランド-B| | | Prot3| +-----------------+ +-------+ [...]
where
Prot[i] is some particular query protocol
RI-A has an index over all A-WDSP[i] and RI-B
RI-B has an index over all B-WDSP[i]
(1) is the query to the Country A DAG system, which
yields a referral based on the index object from RI-B
(2) is that referral
(3) is the resolution of that referral, which the client takes
to the Country B DAG system directly, but to a CAP that
is specifically designed to accommodate protocols from
Country A's service, and map it (and schema) into Country
B's service. Likely, all Country B referrals will be
chained for the Country A client
ロードアイランド-AはすべてのA-WDSP[i]の上にProt[i]が何らかの特定の質問プロトコルであるところにインデックスを持っています、そして、ロードアイランド-Bロードアイランド-Bはインデックスを家に迎えます。すべてのB-WDSP[i](1)がCountry A DAGシステムへの質問である、紹介がどの利回りをロードアイランド-B(2)からインデックスオブジェクトに基礎づけたかによる紹介(3)がクライアントが直接Country B DAGシステムに取るその紹介の解決であるのにもかかわらずの、Country Aのサービスからプロトコルに対応して、それ(そして、図式)をCountryビーズのサービスに写像するように明確に設計されているCAPに解決するということです。 おそらく、すべてのCountry B紹介がCountry Aクライアントのためにチェーニングされるでしょう。
Daigle & Eklof Informational [Page 5] RFC 2968 Mesh of Multiple DAG servers October 2000
Multiple DAGサーバ2000年10月のDaigle&Eklof Informational[5ページ]RFC2968Mesh
Case 3:
ケース3:
The third possibility is, in fact, a refinement of the first. If Country A and Country B are running services that are every way identical except for the data (WDSPs covered), then it may make sense to NOT aggregate Country B's WDSP index objects, but to copy them to Country A's server. Then, Country A's CAPs might be given access to the SAPs of Country B in order to carry out chaining directly at the remote service (instead of implicating Country A's SAPs and Country B's CAPs, as in the first example above). The answer does not come from technology -- it depends entirely on the nature of the relationship that can be established between Country A and Country B's services.
事実上、3番目の可能性は1つの番目ものの気品です。 Country AとCountry Bがその時データ(カバーされたWDSPs)(それが集合CountryビーズWDSPインデックスオブジェクトではなく、コピーであってそれらを感じるのをCountry Aのサーバにするかもしれないその時)を除いて、同じあらゆる道であるサービスを実行しているなら、直接リモートサービス(上記の最初の例のようにCountry AのSAPsとCountryビーズCAPsを巻き込むことの代わりに)のときに推論を行うためにCountry BのSAPsへのアクセスをCountry AのCAPsに与えるかもしれません。 答えは技術から来ません--それは完全なCountry AとCountryビーズのサービスの間で確立できる関係の本質によります。
1.1.2 Scenario 2: Working Up
1.1.2 シナリオ2: 興奮します。
The above scenario implicitly assumes that Country A's server had received index objects from Country B's server. This will be the case if Country A's server is higher in the levels of a hierarchy of services (established by agreements between the service operators), or if the network is comprised of servers that share their index objects with all others, for example. In the latter case, searching at any one of the servers in the service yields the full range of results -- referrals will be made to any other server that might have data that fulfills the user's query. The sharing of the index objects is a mechanism to allow each server to manage local data, while enabling distributed load-sharing on the basic query handling.
上のシナリオは、Country AのサーバがCountryビーズサーバからインデックスオブジェクトを受けたとそれとなく仮定します。サービス(サービスオペレータの間の協定で、設立される)の階層構造のレベルでは、Country Aのサーバが、より高いか、またはネットワークが例えば、すべての他のものとそれらのインデックスオブジェクトを共有するサーバから成るなら、これはそうになるでしょう。 後者の場合では、サービスにおけるサーバのどれかで探すのは最大限の範囲の結果をもたらします--紹介をユーザの質問を実現させるデータを持っているかもしれないいかなる他のサーバにもするでしょう。 基本的な質問取り扱いのときに分配された負荷分割法を可能にする間、インデックスオブジェクトの共有は各サーバがローカルのデータを管理するのを許容するメカニズムです。
However, if a hierarchical, or at least not-completely-connected model is used for the server network, queries carried out at a level other than the top of the hierarchy, or in one particular branch of the hierarchy, will not actually be matched against all index objects. Therefore, there may be other servers to which the query should be directed if the full space needs to be searched. Suppose, for example, that in the above example Country B is in fact lower in the hierarchy than Country A. A user sending a query to Country B's service may be content to limit the scope of the query to that country's information (this is true in enough real-life situations that this hierarchical relationship becomes an effective mechanism for scoping queries and avoiding having to flood the entire network with every single query or keep full copies of all data in every server).
しかしながら、階層的であるか、少なくとも完全に接続されるというわけではないモデルがサーバネットワークに使用されると、階層構造の最上部、または階層構造の1つの特定の部門でレベルで行われた質問は実際にすべてのインデックスオブジェクトに取り組まされないでしょう。 したがって、満杯が、捜される必要があるなら質問が向けられるべきである他のサーバがあるかもしれません。 例えば、事実上、階層構造で上の例のCountry BのそれがCountryビーズのサービスに質問を送るCountry A.Aユーザが質問の範囲をその国の情報に制限して、満足しているかもしれないより(これは質問を見て、あらゆる質問のときに全体のネットワークをあふれさせなければならないか、またはあらゆるサーバですべてのデータの完全な写しを取っておかなければならないのを避けながらこの上下関係が有効なメカニズムになる十分な現実の状況で本当です)低いと仮定してください。
Still in theoretical stages, the DAG/IP provides control constructs to allow DAG components to act according to the topology of the mesh. A CAP might use the "polled-by" system command to establish what other servers in the mesh exist in higher levels (and therefore would be worth contacting if the scope of the search is to be increased).
まだ理論上の段階に、DAG/IPはメッシュのトポロジーに従ってDAGの部品が作動するのを許容するコントロール構造物を供給します。 CAPは、メッシュのどんな他のサーバが、より高いレベル(そして、したがって、検索の範囲が増強されるつもりであるなら、連絡する価値がある)に存在するかを証明するのに「投票されて」システム・コマンドを使用するかもしれません。
Daigle & Eklof Informational [Page 6] RFC 2968 Mesh of Multiple DAG servers October 2000
Multiple DAGサーバ2000年10月のDaigle&Eklof Informational[6ページ]RFC2968Mesh
In the example above, a CAP in Country B's system could determine that Country A's service was polling Country B, and therefore make it a logical target for expanding the scope of the query. More experience (primarily with server mesh topologies) is necessary before it will be clear how to best make use of these capabilities:
例では、CountryビーズシステムのCAPは上では、Country Aのサービスが世論調査Country Bであったことを決定して、したがって、それを質問の範囲を広げるための論理的な目標にすることができました。 どのようにこれらの能力を最もよく利用するかが明確になる前により多くの経験(主としてサーバメッシュtopologiesと)が必要です:
. should the CAP always broaden the scope? only if there are no
local referrals? under user direction?
. should the CAP use a local SAP to contact the remote service's
CAP?
. is it better to completely connect the mesh of servers, or
produce some kind of hierarchy?
. etc
. どんな地方の紹介もない場合にだけ、CAPはユーザ方向の下で範囲をいつも広くするはずですか? . CAPは、リモートサービスのCAPに連絡するのに地方のSAPを使用するはずですか? . サーバのメッシュを完全に接続するか、またはある種の階層構造を作成するのが、より良いですか? . など
2. Other considerations
2. 他の問題
Depending on the context in which a mesh is established (e.g., between national white pages services, or different units of a corporate organization, etc), it may be useful to allow individual WDSPs to indicate whether they are willing to have their data included in a DAG system's aggregated index object (i.e., allowing the DAG system to receive referrals from other systems in the mesh).
メッシュが設立される(例えば、国家のホワイトページサービス、または異なったユニットの会社組織などの間で)文脈によって、個々のWDSPsが、彼らが、DAGシステムの集められたインデックスオブジェクト(すなわち、DAGシステムがメッシュの他のシステムから紹介を受けるのを許容する)に彼らのデータを含んだとしても構わないと思っているかどうかを示すのを許容するのは役に立つかもしれません。
3. Security Considerations
3. セキュリティ問題
This document describes different configurations for sharing information between information services. It introduces no security considerations beyond those attendant in (and addressed by) particular directory service access protocols.
このドキュメントは情報サービスの間の情報交換のための異なった構成について説明します。 それは特定のディレクトリサービス中で付き添いのそれら(そして、扱われる)アクセス・プロトコルを超えてセキュリティ問題を全く紹介しません。
4. Acknowledgements
4. 承認
The work described in this document was carried out as part of an on- going project of Ericsson. For further information regarding that project, contact:
仕事がこのドキュメントが部分として運ばれたコネについて説明した、オンである、突出しにエリクソンについて行くこと。 そのプロジェクトに関する詳細に関しては、以下に連絡してください。
Bjorn Larsson
bjorn.x.larsson@era.ericsson.se
ビヨンラーソン bjorn.x.larsson@era.ericsson.se
Daigle & Eklof Informational [Page 7] RFC 2968 Mesh of Multiple DAG servers October 2000
Multiple DAGサーバ2000年10月のDaigle&Eklof Informational[7ページ]RFC2968Mesh
5. Authors' Addresses
5. 作者のアドレス
Leslie L. Daigle Thinking Cat Enterprises
猫計画を考えるレスリーL.Daigle
EMail: leslie@thinkingcat.com
メール: leslie@thinkingcat.com
Thommy Eklof Hotsip AB
Thommy Eklof Hotsip AB
EMail: thommy.eklof@hotsip.com
メール: thommy.eklof@hotsip.com
6. References
6. 参照
Request For Comments (RFC) and Internet Draft documents are available from numerous mirror sites.
For Comments(RFC)とインターネットDraftドキュメントが多数のミラーサイトから利用可能であるよう要求してください。
[CIP1] Allen, J. and M. Mealling, "The Architecture of the Common
Indexing Protocol (CIP)", RFC 2651, August 1999.
[CIP1] アレンとJ.とM.食事、「一般的なインデックスプロトコル(CIP)のアーキテクチャ」、RFC2651、1999年8月。
[TISDAG] Daigle, L. and R. Hedberg "Technical Infrastructure for
Swedish Directory Access Gateways (TISDAG)," RFC 2967,
October 2000.
[TISDAG]Daigle、L.、およびR.ヘドバーグ、「スウェーデンのディレクトリアクセスゲートウェイ(TISDAG)への技術インフラ」、RFC2967、10月2000日
[DAGEXP] Eklof, T. and L. Daigle, "Wide Area Directory Deployment
Experiences", RFC 2969, October 2000.
[DAGEXP] EklofとT.とL.Daigle、「広い領域ディレクトリ展開経験」、RFC2969、2000年10月。
[NDD] Hedberg, R. and H. Alvestrand, "Technical Specification, The
Norwegian Directory of Directories (NDD)", Work in Progress.
[NDD] 「技術的な仕様、ディレクトリ(NDD)のノルウェーのディレクトリ」というヘドバーグ、R.、およびH.Alvestrandは進行中で働いています。
Daigle & Eklof Informational [Page 8] RFC 2968 Mesh of Multiple DAG servers October 2000
Multiple DAGサーバ2000年10月のDaigle&Eklof Informational[8ページ]RFC2968Mesh
7. Full Copyright Statement
7. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。
Daigle & Eklof Informational [Page 9]
Daigle&Eklof情報です。[9ページ]
一覧
スポンサーリンク
