[要約] 要約：RFC 2970は、統合ディレクトリサービスのアーキテクチャに関する情報を提供します。 目的：TISDAGの結果をまとめ、統合ディレクトリサービスの設計と実装に役立つガイドラインを提供します。
Network Working Group L. Daigle
Request for Comments: 2970 T. Eklof
Category: Informational October 2000
Architecture for Integrated Directory Services - Result from TISDAG
統合ディレクトリサービスのアーキテクチャ - 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
概要
A single, unified, global whitepages directory service remains elusive. Nonetheless, there is increasing call for participation of widely-dispersed directory servers (i.e., across multiple organizations) in large-scale directory services. These services range from national whitepages services, to multi-national indexes of WWW resources, and beyond. Drawing from experiences with the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) ([TISDAG]) project, this document outlines an approach to providing the necessary infrastructure for integrating such widely-scattered servers into a single service, rather than attempting to mandate a single protocol and schema set for all participating servers to use.
単一の統一されたグローバルホワイトページディレクトリサービスは、とらえどころのないままです。それにもかかわらず、大規模なディレクトリサービスに広く分類されているディレクトリサーバー（つまり、複数の組織にまたがる）の参加が増えています。これらのサービスは、National Whitepages Servicesから、WWWリソースの多国籍インデックス、およびそれ以降にまで及びます。TISDAG（スウェーデンのディレクトリアクセスゲートウェイの技術インフラストラクチャ）（[TISDAG]）プロジェクトの経験からの描画では、このドキュメントは、このような広く散乱したサーバーを単一のサービスに統合するために必要なインフラストラクチャを提供するために必要なインフラストラクチャを提供するためのアプローチを概説しています。すべての参加サーバーが使用する単一のプロトコルとスキーマが設定されています。
The TISDAG project addressed the issue of providing centralized access to distributed information for whitepages information on a national scale. The specification of the eventual system is presented in [TISDAG], and [DAGEXP] outlines some of the practical experience already gained in implementing a system of this scale and nature. [DAG-Mesh] considers the issues and possibilities of networking multiple DAG services. Following on from those, this document attempts to describe some of the architectural underpinnings of the system, and propose directions in which the approach can be generalized, within the bounds of applicability.
TISDAGプロジェクトは、全国規模でホワイトページ情報の分散情報への集中アクセスを提供するという問題に対処しました。最終的なシステムの仕様は[TisDag]で提示されており、[Dagexp]は、このスケールと性質のシステムを実装する際にすでに得られた実践的な経験のいくつかを概説しています。[Dag-Mesh]は、複数のDAGサービスをネットワークする問題と可能性を考慮しています。それらに続いて、このドキュメントは、システムのアーキテクチャの基盤の一部を説明し、アプローチを適用可能性の範囲内で一般化できる指示を提案しようとします。
The proposed architecture inserts a coordinated set of modules between the client access software and participating servers. While the client software interacts with the service at a single entry point, the remaining modules are called upon (behind the scenes) to provide the necessary application support. This may come in the form of modules that provide query proxying, schema translation, lookups, referrals, security infrastructure, etc.
提案されたアーキテクチャは、クライアントアクセスソフトウェアと参加サーバーの間にモジュールの調整されたセットを挿入します。クライアントソフトウェアは単一のエントリポイントでサービスと対話しますが、残りのモジュールは（舞台裏で）呼び出され、必要なアプリケーションサポートを提供します。これは、プロキシ、スキーマの翻訳、ルックアップ、紹介、セキュリティインフラストラクチャなどを提供するモジュールの形で提供される場合があります。
Part of this architecture is an "internal protocol" -- called the "DAG/IP" in the TISDAG project. This document also outlines the perceived requirements for this protocol in the extended DAG.
このアーキテクチャの一部は、TISDAGプロジェクトの「DAG/IP」と呼ばれる「内部プロトコル」です。このドキュメントは、拡張DAGにおけるこのプロトコルの知覚要件の概要も概説しています。
Terms used in this document are compliant with those set out in [ALVE]. For the purposes of this document, important distinctions and relationships are defined between applications, services, servers and systems. These are defined as follows:
このドキュメントで使用される用語は、[alve]に設定されたものに準拠しています。このドキュメントの目的のために、アプリケーション、サービス、サーバー、システムの間で重要な区別と関係が定義されます。これらは次のように定義されています。
Application: this is meant in the general sense, as a solution to a particular (set of) user need(s). That is, the definition is not tied to a particular piece of software (as in "application program").
アプリケーション：これは、特定の（セットの）ユーザーニーズの解決策として、一般的な意味で意味されます。つまり、定義は特定のソフトウェアに関連付けられていません（「アプリケーションプログラム」のように）。
The definition of an application includes the type(s) of information to be exchanged, expected behavior, etc. Thus, a whitepages (search) application may expect to receive a name as input to a query engine, and will return all information associated with the name. By contrast, a specific security application might use the same input name to verify access controls.
アプリケーションの定義には、交換される情報の種類、予想される動作などが含まれます。したがって、ホワイトページ（検索）アプリケーションはクエリエンジンへの入力として名前を受信することを期待する場合があり、関連するすべての情報を返します名前。対照的に、特定のセキュリティアプリケーションは、同じ入力名を使用してアクセスコントロールを確認する場合があります。
Service: an operational system providing (controlled) access to fulfill a particular application's needs.
サービス：特定のアプリケーションのニーズを満たすために（制御された）アクセスを提供する運用システム。
One service may be changed by configuring location, access controls, etc. Changing application means changing the service.
場所、アクセスコントロールなどを構成することにより、1つのサービスを変更できます。アプリケーションの変更とは、サービスを変更することを意味します。
Server: a single component offering access through a dedicated protocol, without regard to a specific service (or services) it may be supporting in a given configuration. Typically programmed for a particular application.
サーバー：特定のサービス（またはサービス）に関係なく、専用のプロトコルを介したアクセスを提供する単一のコンポーネントが、特定の構成でサポートされている可能性があります。通常、特定のアプリケーション用にプログラムされています。
System: a set of components with established interconnections.
システム：確立された相互接続を備えたコンポーネントのセット。
Thus, a service can be split between several servers. A collection of services (independently, or interrelated through specified agreements) act as an implementation of an application. A system is composed of one or more servers and services.
したがって、サービスはいくつかのサーバー間で分割できます。サービスのコレクション（特定の契約を通じて独立して、または相互に関連している）は、アプリケーションの実装として機能します。システムは、1つ以上のサーバーとサービスで構成されています。
A "system architecture" identifies specific software components, their behavior, communication channels and messages needed to fulfill a particular service's needs. The TISDAG specification [TISDAG] includes just such a description, defining a software system that will meet the needs of a national whitepages directory service. Here, we outline some of the general principles which lead to that specific system architecture and discuss ways in which the principles can be applied in other contexts.
「システムアーキテクチャ」は、特定のサービスのニーズを満たすために必要な特定のソフトウェアコンポーネント、その動作、通信チャネル、およびメッセージを識別します。TISDAG仕様[TISDAG]には、このような説明が含まれており、National Whitepagesディレクトリサービスのニーズを満たすソフトウェアシステムを定義します。ここでは、その特定のシステムアーキテクチャにつながる一般原則のいくつかを概説し、他のコンテキストで原則を適用できる方法を議論します。
Looking at this bigger picture, we present a "service architecture", or a framework for assembling components into systems that meet the needs of a wider variety of services. This is not a question of developing one or more new protocols for services, but rather to examine a useful framework of interoperating components. The goal is to reduce the overall number of (specialized) protocols that are developed requiring incorporation of some very general concepts that are common to all protocols.
この全体像を見ると、「サービスアーキテクチャ」、またはより広範なサービスのニーズを満たすシステムにコンポーネントを組み立てるためのフレームワークを紹介します。これは、サービス用の1つまたは複数の新しいプロトコルを開発するという問題ではなく、むしろ緩和コンポーネントの有用なフレームワークを調べることです。目標は、すべてのプロトコルに共通するいくつかの非常に一般的な概念の組み込みを必要とする開発された（専門的な）プロトコルの総数を減らすことです。
The Swedish TISDAG project (described in detail in [TISDAG], with some experiences reported in [DAGEXP]) was designed to fulfill the requirements of a particular national directory service. The experience of developing component-based system for providing a directory service through a uniform interface (client access point) provided valuable insight into the possibilities of extending the system architecture so that services with different base requirements can benefit from many of the same advantages.
スウェーデンのTISDAGプロジェクト（[TISDAG]で詳細に説明されており、[Dagexp]でいくつかの経験が報告されている）は、特定の全国ディレクトリサービスの要件を満たすように設計されています。均一なインターフェイス（クライアントアクセスポイント）を介してディレクトリサービスを提供するためのコンポーネントベースのシステムを開発する経験は、システムアーキテクチャを拡張する可能性についての貴重な洞察を提供し、異なる基本要件を持つサービスが同じ利点の多くから利益を得ることができます。
In retrospect, we can describe the TISDAG system architecture in terms of 3 key requirements and 4 basic design principles:
振り返ってみると、3つの重要な要件と4つの基本設計原則に関して、TISDAGシステムアーキテクチャを説明できます。
R1. The service had to function with (several) existing client and server software for the white pages application.
R1。このサービスは、ホワイトページアプリケーション用の（複数の）既存のクライアントおよびサーバーソフトウェアで機能する必要がありました。
R2. It had to be possible to extend the service to accommodate new client and server protocols if and when they became relevant.
R2。新しいクライアントとサーバーのプロトコルが関連する場合、新しいクライアントとサーバーのプロトコルに対応するためにサービスを拡張することができなければなりませんでした。
R3. The service had to be easily reconfigurable -- to accommodate more machines (load-sharing), etc.
R3。サービスは、より多くのマシン（負荷共有）などに対応するために、簡単に再構成できなければなりませんでした。
D1. As a design principle, it was important to consider the possibility that queries and information templates (schema) other than the originally-defined set might eventually be supported.
D1。設計の原則として、元々定義されたセット以外のクエリと情報テンプレート（スキーマ）が最終的にサポートされる可能性を考慮することが重要でした。
D2. As the architecture was already modular and geared towards extensibility, it seemed important to keep in mind that the same (or a similar) system could be applied to other (non-white pages) applications.
D2。アーキテクチャはすでにモジュール式であり、拡張性に向けられているため、同じ（または同様の）システムを他の（非白人ページ）アプリケーションに適用できることに留意することが重要だと思われます。
D3. There is an "inside" and an "outside" to the service -- distinguishing between components that are accessible to the world at large and those that are open only to other components of the system.
D3。サービスには「内部」と「外側」があります。世界全体にアクセスできるコンポーネントと、システムの他のコンポーネントのみに開いているコンポーネントを区別します。
D4. Internally, there is a single protocol framework for all communications -- this facilitates service support functions (e.g., security of transmission), ensures distributability, and provides the base mechanism for allowing/ascertaining interoperability of components.
D4。内部的には、すべての通信に単一のプロトコルフレームワークがあります。これにより、サービスサポート機能（たとえば、送信のセキュリティ）が容易になり、分布性が保証され、コンポーネントの相互運用性を確保/確認するためのベースメカニズムが提供されます。
The resulting system architecture featured modular component (types) to fulfill a small number of functional roles, interconnected by a generic query-response language. The functional roles were defined as:
結果のシステムアーキテクチャは、一般的なクエリ応答言語によって相互接続された少数の機能的役割を満たすためのモジュラーコンポーネント（タイプ）を備えていました。機能的な役割は、次のように定義されていました。
CAPs -- "client access points" -- responsible for accepting and responding to incoming requests through programmed and configured behavior -- to translate the incoming query into some set of DAG-internal actions (queries) and dealing with the responses, filtering and recombining them in such a way as to fulfill the client request within the scope of the service. In the TISDAG system, all CAPs are responsible for handling whitepages queries, but the CAPs are distinguished by the application protocol in which they will receive queries (e.g., LDAPv2, LDAPv3, HTTP, etc). To the client software, the TISDAG system appears as a server of that particular protocol. In the more general case, CAPs may be configured to handle different aspects of a service (e.g., authenticated vs. non-authenticated access). While the TISDAG CAPs all had a simple control structure, the more general case would also see CAPs drawing on different subsets of DAG (internal) servers in order to handle different query types. (See the "Operator Service" example, in section 5.2 below).
キャップ - 「クライアントアクセスポイント」 - プログラムされた構成の動作を通じて着信要求を受け入れて応答する責任 - 着信クエリを一連のDAGインターナルアクション（クエリ）に変換し、応答、フィルタリング、および再結合に扱う彼らは、サービスの範囲内でクライアント要求を満たすような方法で。TISDAGシステムでは、すべてのキャップがホワイトページクエリの処理を担当しますが、キャップはクエリを受け取るアプリケーションプロトコル（例：LDAPV2、LDAPV3、HTTPなど）によって区別されます。クライアントソフトウェアに対して、TISDAGシステムはその特定のプロトコルのサーバーとして表示されます。より一般的なケースでは、サービスのさまざまな側面を処理するようにCAPSを構成することができます（例：認証されたものと非認証アクセス）。TISDAGキャップにはすべて単純な制御構造がありましたが、より一般的なケースでは、さまざまなクエリタイプを処理するために、DAG（内部）サーバーのさまざまなサブセットにキャップが描かれています。（以下のセクション5.2の「オペレーターサービス」の例を参照）。
SAPs -- "service access points" -- responsible for proxying DAG-internal queries to specified services. These are resources drawn upon by other components within the system. Through programmed and configured behavior, they translate queries in the internal protocol into actions against (typically external) servers, taking care of any necessary overhead or differences in interaction style, and converting the responses back into the internal protocol. In the TISDAG system, all SAPs are responsible for handling whitepages queries, but they are distinguished by the application protocol in which they will access remote services. Further distinctions could be made based on the (remote service's) schema mappings they handle, and other service differentiators.
SAPS-「Service Access Points」 - 指定されたサービスにDAG内部クエリをプロキシする責任があります。これらは、システム内の他のコンポーネントによって引き出されるリソースです。プログラムされた構成の動作と構成された動作により、内部プロトコルのクエリを（通常は外部）サーバーに対するアクションに翻訳し、必要なオーバーヘッドまたは相互作用スタイルの違いを処理し、応答を内部プロトコルに変換します。TISDAGシステムでは、すべてのSAPがホワイトページクエリの処理を担当しますが、リモートサービスにアクセスするアプリケーションプロトコルによって区別されます。それらが処理する（リモートサービスの）スキーママッピングやその他のサービス差別化要因に基づいて、さらなる区別を作成できます。
Internal Servers respond to queries in the internal protocol and provide specific types of information. In the TISDAG system, there is one internal server which provides referral information in response to queries.
内部サーバーは、内部プロトコルのクエリに応答し、特定の種類の情報を提供します。TISDAGシステムには、クエリに応じて紹介情報を提供する1つの内部サーバーがあります。
Note that all these components are defined by the functional roles they play in the system, not the particular protocols they handle, or even the aspect of the service they are meant to support. That is, a client access point is responsible for handling client traffic, whether its for searching, establishing security credentials, or some other task.
これらのすべてのコンポーネントは、それらが処理する特定のプロトコル、またはサポートすることを意図したサービスの側面でさえではなく、システムで果たす機能的な役割によって定義されることに注意してください。つまり、クライアントのアクセスポイントは、検索、セキュリティの資格情報の確立、またはその他のタスクの場合、クライアントトラフィックの処理を担当します。
The Requirements and Design principles outlined above are not particular to a national whitepages service. They are equally applicable in any application based on a query-response model, in services where multiple protocols need to be supported, and/or when the service requires specialized behavior "behind the scenes". In the TISDAG project, this last was inherent in the way the service first looks for referrals, then makes queries as appropriate. For protocols that don't handle the referral concept natively, the TISDAG system proxies the queries.
上記の要件と設計の原則は、国立ホワイトページサービスに特有のものではありません。これらは、クエリ応答モデルに基づくあらゆるアプリケーション、複数のプロトコルをサポートする必要があるサービス、および/またはサービスが「舞台裏」の専門的な動作を必要とする場合に等しく適用できます。TISDAGプロジェクトでは、この最後は、サービスが最初に紹介を検索する方法に固有のものであり、次にクエリを必要に応じて作成しました。紹介の概念をネイティブに処理しないプロトコルの場合、TISDAGシステムはクエリをプロキシします。
Because of its particular application to query-response situations, the term "Directory Access Gateway", or "DAG" still fits as a label for this type of system architecture.
クエリ応答の状況への特定のアプリケーションのため、「ディレクトリアクセスゲートウェイ」という用語または「DAG」という用語は、このタイプのシステムアーキテクチャのラベルとして依然として適合しています。
Internet applications are evolving, and require more sophisticated features (e.g., security mechanisms, accounting mechanisms, integration of historical session data). Continuing to develop a dedicated protocol per application type results in encumbered and unwieldy protocols, as each must implement coverage of all of these common aspects. But creating a single multi-application protocol seems unlikely at best. The implicit proposal here is that, rather than overloading protocols to support multiple aspects of a service, those aspects can be managed by breaking the service into multiple supporting components to carry out the specialized tasks of authentication, etc.
インターネットアプリケーションは進化しており、より洗練された機能（セキュリティメカニズム、会計メカニズム、履歴セッションデータの統合など）が必要です。アプリケーションタイプごとの専用プロトコルの開発を継続すると、それぞれがこれらの一般的な側面のすべてのカバレッジを実装する必要があるため、邪魔された扱いにくいプロトコルが発生します。しかし、単一のマルチアプリケーションプロトコルを作成することは、せいぜいありそうもないようです。ここでの暗黙の提案は、サービスの複数の側面をサポートするためにプロトコルを過負荷にするのではなく、これらの側面を複数のサポートコンポーネントに分割して認証の特殊なタスクを実行することで管理できることです。
In the TISDAG project, the choice was made to use a single "internal protocol" (DAG/IP). The particular protocol used is not relevant to the architecture, but the principle is important. By selecting a single query-response transaction protocol, the needs of the particular application could be mapped onto it in terms of queries and data particular to the application. This makes the internal communications more flexible for configuration to other environments (services, applications).
TISDAGプロジェクトでは、単一の「内部プロトコル」（DAG/IP）を使用するように選択されました。使用される特定のプロトコルはアーキテクチャには関係ありませんが、原則は重要です。単一のクエリ応答トランザクションプロトコルを選択することにより、特定のアプリケーションのニーズを、アプリケーションに特有のクエリとデータの観点からマッピングできます。これにより、内部通信は、他の環境（サービス、アプリケーション）への構成に対してより柔軟になります。
It is common today to select an existing, widely deployed protocol for transferring commands and data between client and server -- e.g., HTTP. However, apart from any issues of the appropriateness (or inappropriateness) of extending HTTP to this use, the work would have remained to define all the transaction types and data types over that protocol -- the specification of the interaction semantics and syntax.
今日、クライアントとサーバーの間でコマンドとデータを転送するための既存の広く展開されているプロトコルを選択することが一般的です。たとえば、http。ただし、HTTPをこの使用に拡張することの適切性（または不適切さ）の問題は別として、そのプロトコル（相互作用セマンティクスと構文の指定）上のすべてのトランザクションタイプとデータ型を定義するための作業が残っていました。
Apart from the potential to divide and conquer service aspects, as described above, this approach has many perceived benefits:
上記のように、サービスの側面を分割および征服する可能性は別として、このアプローチには多くの利点があります。
- For multi-protocol environments, it requires on the order of N+M inter-protocol mappings, not NxM. - distribution of development - distribution of operation - eventual possibilities of hooking together different systems (of different backgrounds) - separation of - architectural principles - implementation to a specific application - configuration for a given service
- マルチプロトコル環境の場合、NXMではなくN M間のプロトコルマッピングのオーダーで必要です。 - 開発の分布 - 操作の分布 - 異なるシステムを（異なる背景の）まとめる最終的な可能性 - 建築原則の分離 - 特定のアプリケーションへの実装 - 特定のサービスの構成
It is not the goal to say that a standardized system architecture can be made so that single components can be built for all possible applications. However, this approach in general permits the decoupling of access protocols from specific applications, and facilitates the integration of necessary infrastructure independently of access protocol (e.g., referrals, security, lookup services, distribution etc).
標準化されたシステムアーキテクチャを作成して、すべての可能なアプリケーションのために単一のコンポーネントを構築できるようにすることは目標ではありません。ただし、このアプローチは一般に、特定のアプリケーションからのアクセスプロトコルのデカップリングを可能にし、アクセスプロトコルとは無関係に必要なインフラストラクチャの統合を促進します（例：紹介、セキュリティ、ルックアップサービス、配布など）。
Pictorially, the DAG architecture is as follows:
絵には、DAGアーキテクチャは次のとおりです。
+-------------------------------------------+
"a" | | +--------+ |
<-----> CAP a | | SAP A | |
| | | | |
|---------+ +-+------+---+ |
| |(Internal)| |
| "DAG/IP" | Server i | |
| +----------+ |
| |
| |
| +--------+ | "B"
| | SAP B <-------------->
| | | |
| +--------+ |
| |
+-------------------------------------------+
Note that the bounding box is conceptual -- all components may or may not reside on one server, or a set of servers governed by the provider of the service.
境界ボックスは概念的であることに注意してください。すべてのコンポーネントが1つのサーバーに存在する場合と、サービスのプロバイダーが管理するサーバーのセットに存在する場合とそうでない場合があります。
As we saw in the TISDAG project, the provider of this DAG-based service may be only loosely affiliated with the remote services that are used (Whitepages Directory Service Providers (WDSPs) in this case).
TISDAGプロジェクトで見たように、このDAGベースのサービスのプロバイダーは、使用されているリモートサービス（この場合はWhitepages Directory Service Providers（WDSPS））とのみゆるく提携することができます。
Building a service on this architecture requires:
このアーキテクチャにサービスを構築するには、次のことが必要です。
Service implementation: 1. definition of the overall application to be supported by the system -- whitepages, web resource indexing, medical information 2. requirements 3. expected behavior
サービスの実装：1。システムによってサポートされる全体的なアプリケーションの定義 - ホワイトページ、Webリソースインデックス、医療情報2.要件3.予想される行動
System architecture: 1. nature of deployment -- distributed, security requirements, etc. 2. identification of necessary CAPs -- in terms of access protocols to be supported, different service levels to be provided (e.g., secure and unsecure connections)
システムアーキテクチャ：1。展開の性質 - 分散、セキュリティ要件など。2。必要なキャップの識別 - サポートされるアクセスプロトコルの識別、提供されるさまざまなサービスレベル（たとえば、セキュアと安全な接続）
3. identification of necessary services -- e.g., proxying to remote information search services, lookup services, "AAA[A]" (Authentication, Authorization, Accounting, [and Access]) servers, etc 4. definition of the transaction process for the service: insofar as the CAPs represent the service to client software, CAP modules manage the necessary transactions with other service modules
3. 必要なサービスの識別 - 例：リモート情報検索サービス、ルックアップサービス、「AAA [a]」（認証、承認、会計、[およびアクセス]）などへのプロキシング4.サービスのトランザクションプロセスの定義：キャップがクライアントソフトウェアへのサービスを表す限り、キャップモジュールは他のサービスモジュールとの必要なトランザクションを管理します
Data architecture:
データアーキテクチャ：
1. selection of schemas to be used (in each protocol) 2. definition of schema and protocol mappings -- into and out of some DAG/IP representation
1. 使用するスキーマの選択
Consider the TISDAG project in the light of the above definitions.
上記の定義に照らして、TISDAGプロジェクトを検討してください。
Service implementation: 1. A national-scale subset of Whitepages lookups, with specific query types supported: only certain schema attributes were permitted in queries, and the expected behavior was limited in scope. 2. Requirements: the service had to support multiple query protocols (from clients and for servers), and be capable of searching the entire space of data without centralizing the storage of records. 3. Given a query of accepted type, provide referrals to whitepages servers that might have information to fulfill the query; if necessary, proxy the referrals (chain) to retrieve the information for the client.
サービスの実装：1。特定のクエリタイプがサポートされているホワイトページルックアップの全国規模のサブセット：特定のスキーマ属性のみがクエリで許可され、予想される動作は範囲が制限されていました。2.要件：サービスは、複数のクエリプロトコル（クライアントおよびサーバー向け）をサポートし、レコードの保存を集中化せずにデータのスペースを検索することができました。3.受け入れられているタイプのクエリが与えられた場合、クエリを満たすための情報がある可能性のあるホワイトページサーバーへの紹介を提供します。必要に応じて、クライアントの情報を取得するために紹介（チェーン）を紹介します。
System architecture: 1. distributable components 2. publicly accessible CAPs in HTTP, SMTP, Whois++, LDAPv2, and LDAPv3 3. referral proxies to Whois++, LDAPv2 and LDAPv3 WDSPs, as well as a referral query service 4. the basic transaction process, uniform across all CAPs, is: - query the RI for relevant referrals - where necessary, chain referrals through SAPs of appropriate protocol return, in the native protocol, all remaining referrals and data
システムアーキテクチャ：1。分散コンポーネント2. HTTP、SMTP、WHOIS、LDAPV2、およびLDAPV3の公開されたキャップ3. WHOIS、LDAPV2およびLDAPV3 WDSPへの紹介プロキシ、および紹介クエリサービス4.基本的なトランザクションプロセス、均一すべてのキャップで、次のとおりです。-関連する紹介のRIをクエリします - 必要に応じて、ネイティブプロトコルの適切なプロトコルリターンのSAPSによるチェーン紹介、すべての残りの紹介とデータ
Data architecture: see the spec.
データアーキテクチャ：仕様を参照してください。
In the TISDAG project, the above diagram could be mapped as follows:
TISDAGプロジェクトでは、上記の図を次のようにマッピングできます。
CAP a LDAPv2 CAP
SAP A the Referral Index (RI) interface
Server i the Referral Index (RI)
SAP B LDAPv3 SAP
Note that, in the TISDAG project specification, the designation SAP referred exclusively to proxy components designed to deal with external servers. The Referral Index was considered an entity in its own right. However, generalizing the concepts of the TISDAG experience lead to the proposal of regarding all DAG/IP-supporting service components as SAPs, each designed to carry out a particular type of service functionality, and whether the server is managed internally to the DAG system or not is immaterial.
TISDAGプロジェクトの仕様では、指定SAPは、外部サーバーを扱うように設計されたプロキシコンポーネントのみを参照していることに注意してください。紹介インデックスは、それ自体がエンティティと見なされました。ただし、TISDAGエクスペリエンスの概念を一般化すると、すべてのDAG/IPサポートサービスコンポーネントをSAPと見なす提案につながります。それぞれが特定のタイプのサービス機能を実行するように設計されています。重要ではありません。
Consider the case of "number portability" -- wherein it is necessary to determine the current service provider of a specific phone number. The basic assumption is that phone numbers are assigned to be globally unique, but are not in any way tied to a specific service provider. Therefore, it is necessary to determine the current service provider for the given number before being able to retrieve current information. For the sake of our illustration, let us assume that the management of numbers is two-tiered -- suppose the system stores (internally) the mapping between these random digit strings and the country in which each was originally activated, but relies on external (country-specific) services to manage the updated information about which service provider currently manages a given number. Then, the service data need only be updated when new numbers are assigned, or national services change their access points.
「番号の移植性」の場合を考えてみましょう。特定の電話番号の現在のサービスプロバイダーを決定する必要があります。基本的な仮定は、電話番号がグローバルに一意に割り当てられているが、特定のサービスプロバイダーに結び付けられていないことです。したがって、現在の情報を取得する前に、指定された番号の現在のサービスプロバイダーを決定する必要があります。私たちのイラストのために、数字の管理が2層であると仮定しましょう。これらのランダムな数字文字列とそれぞれが最初にアクティブ化された国との間のマッピング（内部的に）が（内部的に）と仮定します（外部に依存しています（）国固有の）サービスプロバイダーが現在特定の番号を管理しているかについての更新された情報を管理するサービス。次に、サービスデータは、新しい番号が割り当てられたときにのみ更新する必要があります。または、国家サービスがアクセスポイントを変更する必要があります。
We can look at a grossly-simplified version of the problem as an illustration of some of the concepts proposed in this service architecture. We couple it with the "name search" facet of the TISDAG example, to underscore that a single service ("operator") may in fact be supported by several disjunct underlying activities.
このサービスアーキテクチャで提案されているいくつかの概念の説明として、問題の重大な単純化されたバージョンを見ることができます。TISDAGの例の「名前検索」ファセットと組み合わせて、単一のサービス（「オペレーター」）が実際にいくつかの分離された基礎となる活動によってサポートされる可能性があることを強調します。
Service implementation: 1. Retrieving service information for a particular (unstructured) phone number digit sequence, or searching for numbers associated with a particular name (or fragment thereof). 2. Requirements: support IP-telephony through HTTP-based requests, wireless device requests through WAP [WAP].
サービスの実装：1。特定の（構造化されていない）電話番号の桁のシーケンスのサービス情報を取得するか、特定の名前（またはそのフラグメント）に関連付けられた数値を検索します。2.要件：HTTPベースの要求、WAP [WAP]を介したワイヤレスデバイスリクエストを介してIP-Telephonyをサポートします。
3. Expected behavior: given a name (fragment), return a list of names and numbers to match the fragment; given a phone number, return appropriately-structured information re. the current service mapping for that number.
3. 予想される動作：名前（フラグメント）が与えられた場合、フラグメントに一致するように名前と数字のリストを返します。電話番号が与えられた場合、適切に構築された情報を返します。その番号の現在のサービスマッピング。
System architecture: 1. Publicly accessible through CAPs; components widely distributed. 2. Need one CAP for HTTP, one for WAP. 3. Support services include: an internal service for lookup of number strings (to identify nation of origin of the number), a proxy to access national services for registration of numbers and service providers, and a proxy for remote service provider for retrieval of detailed information regarding numbers. For the name searching, we also need a referral index over the names, and a proxy to whatever remote servers are managing the whitepages directories. 4. Now, 2 different types of transaction are possible: search for name, or look-up a number. In the name search case, the CAP receives a name or name fragment, looks it up in the internal referral index, and finds associated numbers through external whitepages services (WDSPs). To look-up a number, the CAP first uses the internal look-up service to determine the country of origin of the number, and then uses a SAP to access that nation's number-service provider directory, and finally uses a different SAP to access the current service provider to determine the information required to make the call.
システムアーキテクチャ：1。キャップを通じて公開されます。コンポーネントが広く分布しています。2. HTTPには1つのキャップ、WAP用のキャップが1つ必要です。3.サポートサービスには、数字の文字列の検索のための内部サービス（数の原産国の国家を識別するため）、数字とサービスプロバイダーの登録のための全国サービスにアクセスするためのプロキシ、および詳細の検索のリモートサービスプロバイダーのプロキシ数に関する情報。名前の検索には、名前を介した紹介インデックスと、ホワイトページディレクトリを管理しているリモートサーバーのプロキシも必要です。4.ここで、2種類のトランザクションが可能です。名前を検索するか、数字を検索します。名前検索ケースでは、CAPは名前または名前のフラグメントを受け取り、内部紹介インデックスでそれを調べ、外部ホワイトページサービス（WDSP）を介して関連する数値を見つけます。数字をルックアップするために、CAPは最初に内部ルックアップサービスを使用して数の原産国を決定し、次にSAPを使用してその国のナンバーサービスプロバイダーディレクトリにアクセスし、最後に別のSAPを使用してアクセスします。通話を行うために必要な情報を決定するための現在のサービスプロバイダー。
Data architecture: [Out of scope for the purposes of this illustration]
データアーキテクチャ：[この図の目的のための範囲外]
Note that some elements of the system architecture are deliberately vague. Per the requirements, no structure is expected in the number string, and therefore the lookup server must maintain an index of number-to-country mappings and relies on an external number-to-service mapping service (in each country). However, were there any structure to the numbers, the lookup server could make use of that structure in the indexing, or in distribution of the index itself. This would have no effect on the CAPs, which have no inherent reliance on how the lookup server performs its task.
システムアーキテクチャの一部の要素は意図的に曖昧であることに注意してください。要件ごとに、数字の文字列には構造が予想されないため、ルックアップサーバーは、国数マッピングのインデックスを維持し、外部番号からサービスへのマッピングサービス（各国）に依存する必要があります。ただし、数値に構造があれば、ルックアップサーバーは、インデックス作成またはインデックス自体の分布でその構造を利用できます。これは、Lookup Serverがタスクを実行する方法に固有の依存を持たないキャップに影響を与えません。
Pictorially, the example can be rendered as follows:
絵には、この例は次のようにレンダリングできます。
+-------------------------------------------+
"a" | | +--------+ |
<-----> CAP a | | SAP A | |
| | | | |
|---------+ +-+------+---+ |
| |(Internal)| |
| "DAG/IP" | Server i | |
| +----------+ |
| |
| +--------+ | "B"
| | SAP B <-------------->
| | | |
| +--------+ |
| |
| +--------+ | "C"
|---------+ | SAP C <-------------->
"b" | | | | |
<-----> CAP b | +--------+ |
| | |
|---------+ +--------+ |
| | SAP D | |
| | | |
| +-+------+---+ |
| |(Internal)| |
| | Server j | |
| +----------+ |
| |
| +--------+ | "E"
| | SAP E <-------------->
| | | |
| +--------+ |
+-------------------------------------------+
where
ただし
CAP a HTTP CAP
CAP b WAP CAP
SAP A the number-nation lookup interface
Server i number-nation lookup server (what country)
SAP B nation-service lookup SAP (what service provider)
SAP C service-number information lookup SAP (current
service details)
SAP D referral index interface
Server j referral index service
SAP E proxy for chaining queries to remote WDSPs
The service architecture is useful for applications outside the scope of "telecoms". In another hypothetical illustration, consider the case of medical information -- records about patients that may be created and stored at a variety of institutions which they visit. It is not unusual to need to access all information concerning a patient, whether or not the person can recollect (or communicate) conditions that were treated, procedures that were performed, or medical institutions visited. The data may include everything from prescriptions, to X-rays and other images, to incident reports and other elements of medical history, etc. Typically, the information is stored where it is collected (or by an agency authorized by that institution) -- not in a central repository. Any service that looks to provide complete answers to queries must deal with these realities, and clearly must function with a strong security model.
サービスアーキテクチャは、「テレコム」の範囲外のアプリケーションに役立ちます。別の仮想的なイラストでは、医療情報のケース、つまり訪問するさまざまな機関に作成および保存される患者に関する記録を考慮してください。患者に関するすべての情報にアクセスする必要はありません。その人が治療された状態を思い出す（または通信）、実行された手順、または訪問した医療機関が訪問したかどうか。データには、処方箋からX線やその他の画像、インシデントレポートや病歴のその他の要素まで、すべてが含まれる場合があります。通常、情報は、収集された場所（またはその機関によって許可された機関によって）保存されます。中央リポジトリにはありません。クエリへの完全な回答を提供するように見えるサービスは、これらの現実に対処する必要があり、強力なセキュリティモデルで明らかに機能する必要があります。
Service implementation: 1. Retrieving all medical information for a particular person. 2. Requirements: must retrieve, or at least locate, all available information, regardless of its storage location; cannot require central repository of information; must implement authorization and access controls. Must support a proprietary protocol for secure connections within hospitals, wireless access for personnel in emergency vehicles (not considered secure access). 3. Expected behavior: given a patient's national ID, and authorized access by medical personnel in secure locations, determine what kinds of records are available, and where; given a request for a specific type of record, retrieve the record. Given a patient's national ID, and authorized access from a wireless device, provide information re. any known medical flags (e.g., medicine allergies, conditions, etc).
サービスの実装：1。特定の人のすべての医療情報を取得します。2.要件：ストレージの場所に関係なく、利用可能なすべての情報を取得、または少なくとも特定する必要があります。情報の中央リポジトリを要求することはできません。承認とアクセスコントロールを実装する必要があります。病院内の安全な接続のための独自のプロトコル、緊急車両内の人員のワイヤレスアクセス（安全なアクセスとは見なされない）をサポートする必要があります。3.予想される行動：患者の全国IDを与えられ、安全な場所で医療従事者による承認されたアクセスが与えられた場合、どのような種類の記録が利用できるか、どこで説明しますか。特定のタイプのレコードのリクエストが与えられた場合、レコードを取得します。患者の全国IDが与えられ、ワイヤレスデバイスからの許可されたアクセスは、情報を提供します。既知の医療旗（薬物アレルギー、状態など）。
System architecture: 1. Only 2 CAP types are needed, but instances of these will be established at major medical institutions. 2. Need one CAP to support the proprietary protocol, one to support wireless access. 3. Support services include: an internal server to support security authentication and access control determination; an internal server to act as referral index for finding information pertinent to a particular patient, and one or more proxies for accessing remote data storage servers. 4. The basic transaction requires that the first step be to authenticate the end-user and determine access privileges. In the case of wireless access, this last will not involve a specific lookup, but rather will be set to allow the user to see the list of publicized medical conditions. Depending on the query type, the next step will be to contact the referral index to determine what records exist, and then track down information at the remote sources.
システムアーキテクチャ：1。2つのキャップタイプのみが必要ですが、これらのインスタンスは主要な医療機関で確立されます。2.独自のプロトコルをサポートするには、ワイヤレスアクセスをサポートするために1つのキャップが必要です。3.サポートサービスには以下が含まれます。セキュリティ認証とアクセス制御の決定をサポートする内部サーバー。特定の患者に関連する情報を見つけるための紹介インデックスとして機能する内部サーバー、およびリモートデータストレージサーバーにアクセスするための1つ以上のプロキシ。4.基本的なトランザクションでは、最初のステップでは、エンドユーザーを認証し、アクセス権限を決定することが必要です。ワイヤレスアクセスの場合、この最後は特定の検索を伴うものではなく、ユーザーが公開された病状のリストを表示できるように設定されます。クエリタイプに応じて、次のステップは紹介インデックスに連絡してレコードが存在するものを決定し、リモートソースの情報を追跡することです。
Data architecture: [Out of scope for the purposes of this illustration]
データアーキテクチャ：[この図の目的のための範囲外]
Pictorially, the example can be rendered as follows:
絵には、この例は次のようにレンダリングできます。
+-------------------------------------------+
"a" | | +--------+ |
<-----> CAP a | | SAP A | |
| | | | |
|---------+ +-+------+---+ |
| |(Internal)| |
| "DAG/IP" | Server i | |
| +----------+ |
| |
| |
| +--------+ | "B"
|---------+ | SAP B <-------------->
"b" | | | | |
<-----> CAP b | +--------+ |
| | |
|---------+ +--------+ |
| | SAP C | |
| | | |
| +-+------+---+ |
| |(Internal)| |
| | Server j | |
| +----------+ |
+-------------------------------------------+
where
ただし
CAP a CAP for proprietary protocol, secure clients
CAP b WAP CAP, for roaming access
SAP A authentication and ACL lookup interface
Server i authentication and ACL lookup server
SAP B remote service SAP -- probably LDAPv3
SAP C Referral Index interface
Server j Referral Index
The role of the DAG/IP is less as a query protocol, and more as a framework or structure for carrying basic query-response transactions of different (configurable) types.
DAG/IPの役割は、クエリプロトコルとしては少なく、異なる（構成可能な）タイプの基本的なクエリ応答トランザクションを運ぶためのフレームワークまたは構造としてより少ない。
Whatever the syntax or grammar, the basic requirements for the DAG/IP include that it be:
構文や文法が何であれ、DAG/IPの基本要件には次のものが含まれます。
- lightweight; CAPs, SAPs should be able to be quite small - flexible enough to carry queries of different paradigms, results of different types - able to support authentication, authorization, accounting and audit mechanisms -- not necessarily native to the protocol - able to support encryption and end-to-end security within the DAG system - sophisticated enough to allow negotiation of capabilities -- querying & identifying application type supported (e.g., whitepages vs. service location vs. URN resolution), query types supported, results types supported
- 軽量;キャップ、SAPは、異なるパラダイム、さまざまなタイプのクエリを運ぶのに十分な柔軟性を持つことができるはずです。DAGシステム内のエンドツーエンドのセキュリティ - 機能の交渉を許可するのに十分洗練されています - サポートされているアプリケーションタイプのクエリと識別（例：ホワイトページ対サービスの場所対URN解像度）、クエリタイプサポート、サポートされている結果タイプサポート
This also means:
これも意味します：
Better support for query-passing/other query semantics (need to balance that against the fact that you don't want DAG-CAPs/SAPs to have to know a multiplicity of semantic possibilities.
クエリパス/その他のクエリセマンティクスのより良いサポート（Dag-Caps/Sapsが多数のセマンティックの可能性を知る必要がないという事実とのバランスをとる必要があります。
Security infrastructure -- ability to establish security credentials, maintain a secure transaction, and propagate the security information forward in the transaction (don't want to reinvent the wheel, just want to be able to use it!).
セキュリティインフラストラクチャ - セキュリティ資格情報を確立し、安全なトランザクションを維持し、トランザクションでセキュリティ情報を前方に伝播する機能（ホイールを再発明したくない、それを使用できるようにするだけです！）。
Ability to do lookups, instead of searches -- might mean connecting to different services than the RI and/or presenting things in a slightly different light -- e.g., lookup <blat> in the <foo> space, as opposed to search for all things concerning <blat>.
検索の代わりにルックアップを行う能力は、RIとは異なるサービスに接続したり、わずかに異なる光で物事を提示することを意味する場合があります。<blat>に関するもの。
Ability to access other services -- e.g., Norwegian Directory of Directories [NDD] -- beyond just for specific characteristics of the service (e.g., security).
他のサービス（たとえば、ノルウェーのディレクトリのディレクトリ[NDD]）にアクセスする能力は、サービスの特定の特性（セキュリティなど）だけを超えています。
In short, the model that seems to stand out from these requirements one of a protocol framework that looks after establishing secure and authenticated (authorized, accountable, auditable...) connections, with transaction negotiation facilities. Within that framework, it must be possible to identify transaction types, provide suitable input information (negotiation?) for those transactions, and accept transaction result objects back.
要するに、これらの要件から際立っていると思われるモデルは、取引交渉施設を備えた安全で認証された（承認された、説明責任、監査可能...）接続を確立した後に見えるプロトコルフレームワークの1つです。そのフレームワーク内で、トランザクションタイプを特定し、それらのトランザクションに適切な入力情報（ネゴシエーション？）を提供し、トランザクション結果オブジェクトを受け入れることができなければなりません。
In the light of the above proposals, we can revisit the way the TISDAG CAPs would be defined.
上記の提案に照らして、TISDAGキャップの定義方法を再訪することができます。
The whitepages-application service known as TISDAG could have SAPs that supported 2 types of query, and 2 types of result sets:
TISDAGとして知られるホワイトページアプリケーションサービスには、2種類のクエリをサポートするSAPSと2種類の結果セットがあります。
query types: . token-based . phrase-based
クエリタイプ：。トークンベース。フレーズベース
result types: . result data . referrals
結果タイプ：。結果データ。紹介
The Whois++ CAP would be configured to contact LDAPv2 and LDAPv3 SAPs because they are identified as providing that kind of service (i.e., if referral protocol == LDAPv2 connect to a particular service). The query paradigm will be phrase-oriented -- NOT because the Whois++ CAP understands LDAP, but because that is one of the defined query types.
WHOISキャップは、LDAPV2およびLDAPV3 SAPSに連絡するように構成されます。これは、その種のサービスを提供するものとして識別されるためです（つまり、紹介プロトコル== LDAPV2が特定のサービスに接続する場合）。クエリパラダイムは、フレーズ指向になります - WHOISキャップがLDAPを理解しているためではなく、それが定義されたクエリタイプの1つであるためです。
As it stands, this type of service architecture is limited to query-response type transactions. This does account for a broad range of applications and services, although it would be interesting to consider broadening the concept to make it applicable to tunneling other protocols (e.g., to connect a call through a SAP, in the number portability example above).
現状では、このタイプのサービスアーキテクチャは、クエリ応答タイプのトランザクションに限定されています。これは、幅広いアプリケーションとサービスを説明しますが、他のプロトコルのトンネルに適用できるように概念を拡大することを検討することは興味深いでしょう（たとえば、上記の数字の例でSAPを介してコールを接続するため）。
This document takes a high-level perspective on service architecture, and as such it neither introduces nor addresses security concerns at an implementation level.
このドキュメントは、サービスアーキテクチャに関する高レベルの視点をとっているため、実装レベルでセキュリティの懸念を導入したり、対処したりしません。
A distributed service built following this approach must address issues of authentication of users, authorization for access to material/components of the system, and encryption of links between them, as befits the nature of the information and service provided.
このアプローチに従って構築された分散サービスは、ユーザーの認証の問題、システムの材料/コンポーネントへのアクセスの許可、およびそれらの間のリンクの暗号化に対処する必要があります。
In discussing this perspective on the evolution of DAG/IP, it seemed to us that the requirements for DAG/IP are falling into line with the proposed text-based directory access protocol that has variously been discussed. Whether it survives in a recognizable form or not :-) some of the above has been drawn from discussions of that protocol with Michael Mealling and Patrik Faltstrom.
DAG/IPの進化に関するこの視点を議論する際に、DAG/IPの要件は、さまざまに議論されている提案されたテキストベースのディレクトリアクセスプロトコルと一致しているように思われました。それが認識可能な形で生き残るかどうか:-)上記のいくつかは、マイケル・ミーリングとパトリック・ファルトストロームとのそのプロトコルの議論から引き出されました。
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）およびインターネットドラフトドキュメントは、多数のミラーサイトから入手できます。
[ALVE] Alvestrand, H., "Definitions for Talking about Directories", Work in Progress.
[Alve] Alvestrand、H。、「ディレクトリについて話すための定義」、進行中の作業。
[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, September 2000.
[Dagexp] Eklof、T。およびL. Daigle、「Wide Area Directory Deployment Experiences」、RFC 2969、2000年9月。
[DAG-Mesh] Daigle, L. and T. Eklof, "Networking Multiple DAG servers: Meshes", RFC 2968, September 2000.
[Dag-Mesh] Daigle、L。およびT. Eklof、「複数のDAGサーバーネットワーク：Meshes」、RFC 2968、2000年9月。
[NDD] Hedberg, R. and H. Alvestrand, "Technical Specification, The Norwegian Directory of Directories (NDD)", Work in Progress.
[NDD] Hedberg、R。およびH. Alvestrand、「技術仕様、ディレクトリのノルウェーディレクトリ（NDD）」、進行中の作業。
[WAP] The Wireless Application Protocol, http://www.wapforum.org
[WAP]ワイヤレスアプリケーションプロトコル、http：//www.wapforum.org
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エディター機能の資金は現在、インターネット協会によって提供されています。