[要約] 要約：RFC 2968は、複数のDAGサーバーのメッシュ構造に関する結果をまとめたものです。 目的：TISDAGの結果を共有し、複数のDAGサーバーのメッシュ構造の実装と運用に関するガイドラインを提供することです。
Network Working Group L. Daigle
Request for Comments: 2968 T. Eklof
Category: Informational October 2000
Mesh of Multiple DAG servers - Results from TISDAG
複数のDAGサーバーのメッシュ - TISDAGの結果
Status of this 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）The Internet Society（2000）。無断転載を禁じます。
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.
共通のインデックス作成プロトコル（[CIP1]）は、クエリ紹介インデックスだけでなく、（ゆるく）関連する紹介インデックスのメッシュの作成を促進するように設計されています。このようなサーバーのメッシュの目的は、異なるサーバー全体でインデックス作成および/または検索タスクのある種の分散共有を実装することです。これまでのところ、TISDAG（スウェーデンのディレクトリアクセスゲートウェイの技術インフラストラクチャ）プロジェクト（[TISDAG]、[DageXP]）は、単一の紹介インデックスの作成に焦点を当てています。明らかな次のステップは、それをより大きな相互運用サービスのセットに統合することです。
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 untouched, or a referral index server's contents could be aggregated into a new index object, generating referrals back to that server.
CIPドキュメント（[[CIP1]）で概説されているように、複数の紹介サーバーを介してインデックスを作成するメカニズムには多くの可能性があります。新しいインデックスオブジェクト、そのサーバーへの紹介を生成します。
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層深いものとして実行できますが、単にフォワードインデックスオブジェクトを通過しない重要な理由（凝集）は、個々のサービスがさまざまなアクセスプロトコルをサポートし、特定のセキュリティ要件などを持っている可能性があることです。DAGシステムで使用される標準的なシステム、またはリモートシステムの特定のセマンティクス（他のクエリタイプなど）をサポートするために確立された新しいシステムのいずれかのキャップまたはキャップに向けられる必要があります。特定のDAGシステム内で、これらのリモートサーバーへの紹介は他の紹介と同じように見えますが、特定のSAPまたはSAPを確立してクエリの履行を提供することができます（繰り返しますが、サービスのバリエーション間の翻訳を有効にして、関係が安全なアクセスを可能にします。サービスの間には制限されています）。
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.
メッシュトラバーサルの次のシナリオでは、議論の主要なサービス（シナリオ1の国、シナリオ2の国B）はDAGベースのサービスであると仮定しています。シナリオは、DAGサービスの相互運用に照らして提示されますが、ほとんどの場合、リモートサービスが他のサービスアーキテクチャによって提供された場合、等しく適用できます。繰り返しますが、あらゆる種類のメッシュを確立するための重要な要素は、内部システムアーキテクチャではなく、CIPインデックスオブジェクトの交換です。
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のWDSPのインデックスオブジェクトに対して、一定数のヒットが作成されます。国Bの集合インデックスにもヒットがあります。これは、これを処理する必要がある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とカントリーBは、サポートされているプロトコル、クエリ、およびスキーマの観点から、本質的に同じサービスを実行しています。この場合、国Bのサービスでサポートされているプロトコルごとに1つの紹介を生成する必要があります。紹介は、そのプロトコルが紹介をサポートしている場合、クライアントまで渡すことができます。あるいは、キャップは、通常の方法で、適切なSAPを介して紹介をチェーンすることができます。言い換えれば、国Bのサービスの上限は、国Aのサービスに対するWDSPとして機能します。
Consider the following illustration (only relevant CAPs, SAPs, etc, are shown; others suppressed for lack of room):
次の図を考えてみましょう（関連するキャップ、SAPなどのみが示されています。その他は部屋の不足のために抑制されています）：
+-----------------+
(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 |
+-----------------+ +-------+
[...]
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)
ここで、prot [i]はいくつかの特定のクエリプロトコルRI-aがすべてのA-WDSP [i]にインデックスを持っており、RI-B RI-BはすべてのB-WDSP [i]（1）を介してインデックスを持っています。RI-B（2）のインデックスオブジェクトに基づいて紹介を生成するDAGシステムは、紹介（3）がその紹介の解決であり、クライアントが国B DAGシステムに直接取る（どの紹介システム）、もしあれば、b-wdsp [i]は関連情報を持っています）
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と国Bは、同じサービスタイプ（例：ホワイトページ）に対処するが、プロトコルの同一のコレクション、許可クエリ、またはスキーマを使用していないサービスを実行しています。国Bが国AのDAGサービスに送信したインデックスオブジェクトは、インデックスオブジェクトに対して適切なヒットを生成するために（つまり、国Bのサービスへの紹介の場合）、国Aのサービスに関して構築する必要があります。ただし、紹介を解決するには、さらにプロトコル/スキーマ/クエリマッピングを行う必要があります。これは、国Aのサービス内に設立された特別なSAPによって行うことができます。これは、国Aのサービスを公開されたカントリーBのサービスにマッピングすることができます。その後、国Aの1つのアクセスプロトコルのみをサポートすることを選択でき、指定されたSAPは常に1つに連絡します国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は、カントリーAのサービスからマッピングを行う特定のキャップを、サービスの内部構造に対して最も適切なものに確立することができます。この場合、Country Aの紹介は、国Bのサービスの特別なキャップになります（これも、国のWDSPのように見えます）。実際、紹介はクライアントソフトウェアによって直接処理される場合があります。2つの可能なアプローチの違いは、2つのサービスタイプ間の関係を管理する責任にあります。一方で、国はそのサービスと国の公開されたアクセスを知っている場合、それを処理することができました。他方では、国Bがそれに接続したいすべての国の上限を確立する責任があります。後者は、場合によっては、実行できる内部最適化の量と、国Aのサービスのオーバーヘッドを削減するため（クライアントソフトウェアに直接紹介を渡すことができます）、正当化することができます。
Consider the following illustration (only relevant CAPs, SAPs, etc, are shown; others suppressed for lack of room):
次の図を考えてみましょう（関連するキャップ、SAPなどのみが示されています。その他は部屋の不足のために抑制されています）：
+-----------------+
(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 |
+-----------------+ +-------+
[...]
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
ここで、prot [i]はいくつかの特定のクエリプロトコルRI-aがすべてのA-WDSP [i]にインデックスを持っており、RI-B RI-BはすべてのB-WDSP [i]（1）を介してインデックスを持っています。RI-B（2）からのインデックスオブジェクトに基づいて紹介を生成する国のDAGシステムは、紹介（3）がその紹介の解像度であり、クライアントは国B DAGシステムに直接取るが、キャップこれは、Country Aのサービスからのプロトコルに対応するように特別に設計されており、カントリーBのサービスにマッピングされます。おそらく、すべての国の紹介は、国のために連鎖します。
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番目の可能性は、実際、最初のものの洗練です。国Aと国Bがデータ（WDSPをカバー）を除いてあらゆる方法で同一のサービスを実行している場合、Country BのWDSPインデックスオブジェクトを集約せず、Country Aのサーバーにコピーすることは理にかなっています。次に、上記の最初の例のように、カントリーAのCAPSには、リモートサービスで直接チェーンを実行するために、Country BのSAPにアクセスできるようになります。答えはテクノロジーからのものではありません - それは、国Aと国Bのサービスの間に確立できる関係の性質に完全に依存します。
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.
上記のシナリオは、国Aのサーバーが国Bのサーバーからインデックスオブジェクトを受信したことを暗黙的に想定しています。これは、カントリー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).
ただし、サーバーネットワークに階層的な、または少なくとも完全に接続されていないモデルが使用されている場合、階層の上部以外のレベルで、または階層の特定のブランチで実行されるクエリは実際には一致しませんすべてのインデックスオブジェクトに対して。したがって、完全なスペースを検索する必要がある場合、クエリを指示する他のサーバーがある場合があります。たとえば、上記の例では、国Bが実際に階層で国Aよりも低いとしましょう。カントリーBのサービスにクエリを送信するユーザーは、その国の情報のクエリの範囲を制限するために満足している可能性があります（これは真ですこの階層的な関係が、クエリをスコープするための効果的なメカニズムになり、すべてのサーバーのすべてのデータのすべてのデータの完全なコピーを維持する必要があることを避けるための効果的なメカニズムになります。
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コンポーネントが作用できるように制御構造を提供します。キャップは、「ポーリングバイ」システムコマンドを使用して、メッシュ内の他のサーバーがより高いレベルで存在するものを確立する場合があります（したがって、検索の範囲を増やす場合は連絡する価値があります）。
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:
上記の例では、国BのシステムのCAPは、国Aのサービスが国Bを投票していることを判断することができ、したがって、クエリの範囲を拡大するための論理的なターゲットになります。より多くの経験（主にサーバーメッシュトポロジを使用した）が、これらの機能を最適に使用する方法を明確にする前に必要です。
. 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
。キャップは常にスコープを広げる必要がありますか？地元の紹介がない場合のみ？ユーザーの指示の下？。キャップは地元の樹液を使用してリモートサービスのキャップに連絡する必要がありますか？。サーバーのメッシュを完全に接続するか、何らかの階層を生成する方が良いでしょうか？。等
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).
メッシュが確立されるコンテキスト（たとえば、全国のホワイトページサービス、または企業組織の異なるユニットなどの間）に応じて、個々のWDSPがデータを含める意思があるかどうかを示すことが役立つ場合があります。DAGシステムの集約されたインデックスオブジェクト（つまり、DAGシステムがメッシュ内の他のシステムから紹介を受信できるようにする）。
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.
このドキュメントでは、情報サービス間で情報を共有するためのさまざまな構成について説明します。特定のディレクトリサービスアクセスプロトコルに付随する（および対処された）人々を超えてセキュリティ上の考慮事項を導入しません。
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 Larsson bjorn.x.larsson@era.ericsson.se
Leslie L. Daigle Thinking Cat Enterprises
レスリーL.デイグル思考猫企業
EMail: leslie@thinkingcat.com
Thommy Eklof Hotsip AB
Thommy Eklof Hotsip AB
EMail: thommy.eklof@hotsip.com
Request For Comments (RFC) and Internet Draft documents are available from numerous mirror sites.
コメントのリクエスト（RFC）およびインターネットドラフトドキュメントは、多数のミラーサイトから入手できます。
[CIP1] Allen, J. and M. Mealling, "The Architecture of the Common Indexing Protocol (CIP)", RFC 2651, August 1999.
[CIP1] Allen、J。およびM. Mealling、「共通インデックスプロトコル（CIP）のアーキテクチャ」、RFC 2651、1999年8月。
[TISDAG] Daigle, L. and R. Hedberg "Technical Infrastructure for Swedish Directory Access Gateways (TISDAG)," RFC 2967, October 2000.
[TisDag] Daigle、L。およびR. Hedberg「スウェーデンのディレクトリアクセスゲートウェイの技術インフラストラクチャ（TISDAG）」、RFC 2967、2000年10月。
[DAGEXP] Eklof, T. and L. Daigle, "Wide Area Directory Deployment Experiences", RFC 2969, October 2000.
[Dagexp] Eklof、T。およびL. Daigle、「Wide Area Directory Deployment Experiences」、RFC 2969、2000年10月。
[NDD] Hedberg, R. and H. Alvestrand, "Technical Specification, The Norwegian Directory of Directories (NDD)", Work in Progress.
[NDD] Hedberg、R。およびH. Alvestrand、「技術仕様、ディレクトリのノルウェーディレクトリ（NDD）」、進行中の作業。
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。