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.
著作権（C）インターネット協会（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.
単一の統合、グローバルホワイトページディレクトリサービスは、とらえどころのないまま。それにもかかわらず、大規模なディレクトリサービスで広く分散ディレクトリ・サーバ（すなわち、複数の組織間）の参加の増加の呼び出しがあります。これらのサービスは、全国のホワイトページサービスから、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-メッシュ]は、複数の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").
アプリケーション：これは、ユーザーの必要性（S）は、特定の（のセット）の解決策として、一般的な意味で意図されています。つまり、定義は（「アプリケーション・プログラム」のように）特定のソフトウェアに縛られていません。
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.
一つのサービスは、サービスを変更するアプリケーションの変更手段場所、アクセス制御、等を構成することによって変更することができます。
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]全国ホワイトページディレクトリサービスのニーズを満たすソフトウェアシステムを定義し、ちょうどそのような記述を含んでいます。ここでは、その特定のシステム・アーキテクチャにつながる一般的な原則のいくつかを概説し、原則は、他のコンテキストに適用できる方法を議論します。
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.
（[DAGEXP]で報告されたいくつかの経験で、[TISDAG]に詳細に記載されている）スウェーデンTISDAGプロジェクトは、特定の国家のディレクトリサービスの要件を満たすように設計されました。異なるベース要件を持つサービスが同じ利点の多くの恩恵を受けることができるように、統一されたインタフェース（クライアントアクセスポイント）を介してディレクトリサービスを提供するためのコンポーネントベースのシステムの開発の経験は、システム・アーキテクチャを拡張する可能性に貴重な洞察を提供しました。
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).
CAPの - 「クライアントアクセスポイント」 - 受け入れ、プログラムと設定された動作を通じて、着信要求に応答する責任 - いくつかのDAG-内部アクション（クエリ）のセットとレスポンスを扱う、フィルタリングおよび再結合に入ってくるクエリを変換しますサービスの範囲内で、クライアントの要求を満たすような方法でそれら。 TISDAGシステムでは、全てのキャップは、ホワイトページのクエリを処理する責任があるが、キャップが、彼らはクエリを受け取るたアプリケーションプロトコル（例えば、のLDAPv2、LDAPv3の、HTTPなど）によって区別されます。クライアントソフトウェアに、TISDAGシステムは、その特定のプロトコルのサーバーとして表示されます。より一般的なケースでは、キャップは、（例えば、非認証アクセス対認証）サービスのさまざまな側面を扱うように構成することができます。 TISDAGキャップ全てが簡単な制御構造を持っていたが、より一般的な場合も、別のクエリの種類を処理するために、DAGの異なるサブセットに描くのCAP（内部）のサーバを見るでしょう。 （以下のセクション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.
SAPは - 「サービスアクセスポイント」 - 指定されたサービスへの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システムでは、クエリに応答して、参照情報を提供するつの内部サーバがあります。
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
- マルチプロトコル環境では、N + M間のプロトコルマッピングではなく、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ベースのサービスの提供者は緩く（この場合はホワイトページディレクトリ・サービス・プロバイダ（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性質 - 分散、セキュリティ要件、等必要のCAPの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.定義サービス：キャップはクライアントソフトウェアにサービスを表すように、CAPモジュールは、他のサービスモジュールで必要なトランザクションを管理する限り
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選択スキーマとプロトコルマッピング2.定義 - に、いくつかDAG / IP表現のうち
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.配布コンポーネントHTTP、SMTP、Whoisの++、のLDAPv2 2.公的にアクセス可能なキャップ、およびWhoisの++、LDAPv2のとLDAPv3のWDSPsだけでなく、紹介クエリサービス4.基本的なトランザクション処理、均一にLDAPv3の3.紹介プロキシすべて大文字を横切って、ある： - 関連照会のためのRIをクエリ - 必要な場合、チェーンの紹介適切なプロトコルリターンのSAPを介して、ネイティブプロトコルで、残りのすべての紹介とデータ
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
CAPのLDAPv2 CAP SAP A紹介インデックス（RI）インタフェースサーバI紹介インデックス（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は、外部のサーバに対処するために設計されたプロキシコンポーネントのみに言及しました。紹介インデックスは、それ自体で実体と考えられていました。しかし、SAPのようなすべてのDAG / IP-サポートするサービスコンポーネントについての提案にTISDAG経験リードの概念を一般化、各サービスの機能の特定のタイプを実行するように設計されており、サーバーがDAGシステムに内部的に管理されているかどうか重要ではないではありません。
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.
「番号ポータビリティ」の場合を考える - 特定の電話番号の現在のサービス・プロバイダを決定することが必要です。基本的な前提は、電話番号がグローバルに一意であるために割り当てられているということですが、特定のサービスプロバイダに縛らどのような方法ではありません。したがって、現在の情報を取得することができる前に、所定の数の現在のサービス・プロバイダを決定する必要があります。私たちの説明のために、私たちは番号の管理は二段階であると仮定しましょう - （内部）システムの店舗を想定それぞれが最初にアクティブ化されたこれらのランダムな数字列と国との間のマッピングが、外部に依存しています（国固有の）サービスは、サービスプロバイダが、現在与えられた数を管理するについての更新情報を管理します。次に、サービスデータは、新しい番号が割り当てられているときに更新することのみが必要、または国のサービスは、アクセスポイントを変更します。
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ベースの要求によるサポートIPテレフォニー、WAP [WAP]介して無線デバイスを要求。
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.
システムアーキテクチャ：CAPを通じ1.公的にアクセス可能。コンポーネントが広く分布します。 2. HTTP、WAPのための1つに1つのCAPが必要です。 3.サポートサービスが含まれます：数字の文字列の検索のための内部サービス（数の起源の国を識別するために）、数字やサービスプロバイダの登録のための国家のサービスにアクセスするためのプロキシ、および詳細の取得のためのリモートサービスプロバイダのプロキシを番号に関する情報。名前検索のために、我々はまた、名前の上に紹介インデックス、およびホワイトページディレクトリを管理しているリモートどんなサーバーへのプロキシを必要とします。 4.次に、トランザクションの2つの異なるタイプが可能です：名前を検索、またはルックアップ数を。名検索の場合、CAPは、名前または名前の断片を受け取る内部紹介インデックスでそれを検索し、外部のホワイトページサービス（WDSPs）を介して関連付けられた番号を検索します。ルックアップするには数を、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.
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
CAP WAP CAP SAP A、B HTTPキャップCAP数カ国のルックアップ・インターフェース・サーバーの数i-国引きサーバー（どの国）SAPのB国のサービスルックアップSAP（どのようなサービスプロバイダ）SAPのCサービス番号情報の検索SAP（現在のサービスリモートWDSPsにクエリーを連鎖するための詳細）SAP D紹介インデックスインタフェースサーバJの紹介インデックスサービスのSAP Eプロキシ
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).
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 CAPタイプが必要とされているが、これらのインスタンスは、主要な医療機関で確立されます。 2.ワイヤレスアクセスをサポートするために、独自のプロトコル、1をサポートするために、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
CAP認証とACL検索インターフェースサーバーのI認証とACLルックアップサーバSAP BリモートサービスSAPのアクセスSAPローミングのための独自のプロトコルのためのCAP、セキュアなクライアントのキャップBのWAPのCAP、 - おそらくLDAPv3のSAP C紹介インデックスインタフェースサーバJの紹介インデックス
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-のCAP / SAPは、セマンティックな可能性の多様性を知っている必要はしたくないという事実に対することのバランスを取る必要があります。
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> <foo>の空間に、すべてを検索するために対立するものとして<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:
クエリの2種類、および結果セットの2種類をサポートSAPを持っている可能性がTISDAGとして知られているホワイトページ、アプリケーションサービス：
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.
フーイズ++ CAPは、それらがサービスのようなものを提供するものとして同定されているためのLDAPv2とLDAPv3のSAPを接触するように構成されることになる（すなわち、照会プロトコルは==のLDAPv2は、特定のサービスに接続する場合）。 Whois ++ CAPは、LDAPを理解しているため、NOT、それは定義されたクエリの種類の一つであるので - クエリのパラダイムは、フレーズ志向になります。
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のための要件は様々に議論されてきた提案テキストベースのディレクトリアクセスプロトコルとのラインに下落していることを私たちに見えました。上記のいくつかは、マイケル・メオーリングとパトリックFaltstromとそのプロトコルの議論から引き出されました:-)それが認識可能な形で存続するかどうか。
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
Leslie L. Daigle Thinking Cat Enterprises
レスリーL. Daigle氏猫の企業を考えます
EMail: leslie@thinkingcat.com
メールアドレス：leslie@thinkingcat.com
Thommy Eklof Hotsip AB
今トミEclof Hotsip
EMail: thommy.eklof@hotsip.com
メールアドレス：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.ヘドバーグ "スウェーデンのディレクトリアクセスゲートウェイのための技術基盤（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氏、 "広域ディレクトリの展開の経験"、RFC 2969、2000年9月。
[DAG-Mesh] Daigle, L. and T. Eklof, "Networking Multiple DAG servers: Meshes", RFC 2968, September 2000.
[DAG-メッシュ] Daigle氏、L.とT. Eklof、 "複数のDAGサーバネットワーク：メッシュ"、RFC 2968、2000年9月。
[NDD] Hedberg, R. and H. Alvestrand, "Technical Specification, The Norwegian Directory of Directories (NDD)", Work in Progress.
[NDD]ヘドバーグ、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.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。