[要約] RFC 3650は、Handleシステムの概要と目的を説明しています。Handleシステムは、グローバルな識別子を提供し、デジタルリソースの管理とアクセスを容易にすることを目的としています。このRFCは、Handleシステムの基本的な機能と利点を要約しています。
Network Working Group S. Sun
Request for Comments: 3650 L. Lannom
Category: Informational B. Boesch
CNRI
November 2003
Handle System Overview
システムの概要を処理します
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 (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
IESG Note
IESGノート
Several groups within the IETF and IRTF have discussed the Handle System and its relationship to existing systems of identifiers. The IESG wishes to point out that these discussions have not resulted in IETF consensus on the described Handle System, nor on how it might fit into the IETF architecture for identifiers. Though there has been discussion of handles as a form of URI, specifically as a URN, these documents describe an alternate view of how namespaces and identifiers might work on the Internet and include characterizations of existing systems which may not match the IETF consensus view.
IETFおよびIRTF内のいくつかのグループは、ハンドルシステムと既存の識別子システムとの関係について説明しました。IESGは、これらの議論が説明されているハンドルシステムのIETFコンセンサスや、識別子のIETFアーキテクチャにどのように適合するかについてのIETFコンセンサスをもたらさなかったことを指摘したいと考えています。URIの形式としてのハンドル、特にURNとしての議論がありましたが、これらのドキュメントは、名前空間と識別子がインターネット上でどのように機能するかについての代替ビューを説明し、IETFコンセンサスビューと一致しない既存のシステムの特性評価を含む方法を説明しています。
Abstract
概要
This document provides an overview of the Handle System in terms of its namespace and service architecture, as well as its relationship to other Internet services such as DNS, LDAP/X.500, and URNs. The Handle System is a general-purpose global name service that allows secured name resolution and administration over networks such as the Internet. The Handle System manages handles, which are unique names for digital objects and other Internet resources.
このドキュメントでは、名前空間とサービスアーキテクチャの観点から、ハンドルシステムの概要、およびDNS、LDAP/X.500、URNなどの他のインターネットサービスとの関係を提供します。ハンドルシステムは、インターネットなどのネットワークを介したセキュリティで保護された名前解像度と管理を可能にする汎用グローバルネームサービスです。ハンドルシステムは、デジタルオブジェクトやその他のインターネットリソースのユニークな名前であるハンドルを管理します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Motivations. . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Handle Namespace . . . . . . . . . . . . . . . . . . . . . . . 7
4. Handle System Architecture . . . . . . . . . . . . . . . . . . 8
5. Handle System Security . . . . . . . . . . . . . . . . . . . . 11
6. The Handle System and other Internet Services. . . . . . . . . 12
6.1. Domain Name Service (DNS). . . . . . . . . . . . . . . . 13
6.2. Directory Services (X.500/LDAP). . . . . . . . . . . . . 13
6.3. Uniform Resource Identifier (URI)/Uniform Resource Name
(URN). . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 15
7.1. General Security Practice. . . . . . . . . . . . . . . . 15
7.2. Privacy Protection . . . . . . . . . . . . . . . . . . . 16
7.3. Caching and Proxy Servers. . . . . . . . . . . . . . . . 16
7.4. Mirroring. . . . . . . . . . . . . . . . . . . . . . . . 17
7.5. Denial of Service (DoS). . . . . . . . . . . . . . . . . 17
8. History of the Handle System . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. References and Bibliography. . . . . . . . . . . . . . . . . . 19
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 21
This document provides an overview of the Handle System, a distributed information system designed to provide an efficient, extensible, and secured global name service for use on networks such as the Internet. The Handle System includes an open protocol, a namespace, and a reference implementation of the protocol. The protocol enables a distributed computer system to store names, or handles, of digital resources and resolve those handles into the information necessary to locate, access, and otherwise make use of the resources. These associated values can be changed as needed to reflect the current state of the identified resource without changing the handle. This allows the name of the item to persist over changes of location and other current state information. Each handle may have its own administrator(s) and administration can be done in a distributed environment. The Handle System supports secured handle resolution. Security services such as data confidentiality, data integrity, and non-repudiation are provided upon client request.
このドキュメントは、インターネットなどのネットワークで使用するための効率的で拡張可能な、保護されたグローバル名サービスを提供するように設計された分散情報システムであるハンドルシステムの概要を提供します。ハンドルシステムには、オープンプロトコル、名前空間、およびプロトコルの参照実装が含まれます。このプロトコルにより、分散コンピューターシステムがデジタルリソースの名前またはハンドルを保存し、それらのハンドルをリソースを見つけ、アクセスし、その他の方法で使用するために必要な情報に解決できます。これらの関連する値は、ハンドルを変更せずに特定されたリソースの現在の状態を反映するために必要に応じて変更できます。これにより、アイテムの名前は、場所やその他の現在の状態情報の変更を維持できます。各ハンドルには独自の管理者があり、管理は分散環境で実行できます。ハンドルシステムは、保護されたハンドル解像度をサポートします。データの機密性、データの整合性、非繰り返しなどのセキュリティサービスは、クライアントのリクエストに応じて提供されます。
The Handle System provides a confederated name service that allows any existing local namespace to join the global handle namespace by obtaining a unique Handle System naming authority. Local names and their value-binding(s) remains intact after joining the Handle System. Any handle request to the local namespace may be processed by a service interface speaking the Handle System protocol. Combined with the unique naming authority, any local name is guaranteed unique under the global handle namespace.
ハンドルシステムは、一意のハンドルシステム命名機関を取得することにより、既存のローカルネームスペースがグローバルハンドルネームスペースに参加できるようにする南軍の名前サービスを提供します。ハンドルシステムに参加した後、ローカル名とその価値結合はそのままです。ローカルネームスペースへのハンドル要求は、ハンドルシステムプロトコルを話すサービスインターフェイスによって処理される場合があります。一意の命名権限と組み合わせることで、ローカル名はグローバルハンドル名の下で一意に保証されています。
There are several services used today to provide name service for Internet resources. Among these, the Domain Name System (DNS) [2,3] is the most widely used. DNS is designed "to provide a mechanism for naming resources in such a way that the names are mappable into IP addresses and are usable in different hosts, networks, protocol families, internets, and administrative organizations" [3]. The growth of the Internet has raised demands for various extensions to DNS. There are also attempts to use DNS as a general-purpose resource naming system. However, the importance of DNS in basic network routing has led to great caution in implementing any DNS extension or overloading the DNS for general-purpose resource naming. An additional factor which argues against using DNS as a general-purpose naming service is the DNS administrative model. DNS names are typically managed by the network administrator(s) at the DNS zone level. There is no provision for per-name administrative structure and no facilities for anyone other than the network administrator to create or manage DNS names. This is appropriate for domain name administration, but less so for general-purpose resource naming.
インターネットリソースに名前サービスを提供するために、今日使用されているサービスがいくつかあります。これらの中で、ドメイン名システム（DNS）[2,3]が最も広く使用されています。DNSは、「名前がIPアドレスにマッピングできるようにリソースを命名するためのメカニズムを提供するために設計されており、さまざまなホスト、ネットワーク、プロトコルファミリ、インターネット、および管理組織で使用可能です」[3]。インターネットの成長により、DNSへのさまざまな拡張の需要が高まりました。また、DNSを汎用リソースネーミングシステムとして使用する試みもあります。ただし、基本的なネットワークルーティングにおけるDNSの重要性は、DNS拡張機能を実装したり、汎用リソース命名のDNSを過負荷にすることに大きな注意を払っています。DNSを汎用命名サービスとして使用することに反対する追加要因は、DNS管理モデルです。DNS名は通常、DNSゾーンレベルでネットワーク管理者によって管理されます。NAMEあたりの管理構造の規定はなく、ネットワーク管理者以外の人がDNS名を作成または管理する施設はありません。これはドメイン名の管理に適していますが、汎用リソースの命名にはあまり適していません。
The Handle System has been designed from the start to serve as a general-purpose naming service. It is designed to accommodate very large numbers of entities and to allow distributed administration over the public Internet. The Handle System data model allows access control to be defined at the level of each of the data values associated with a given handle. Each handle can further define its own set of administrators that are independent from the network or host administrator.
ハンドルシステムは、一般的な命名命名サービスとして機能するために、最初から設計されています。非常に多くのエンティティに対応し、公開インターネットを介して分散管理を許可するように設計されています。ハンドルシステムデータモデルにより、特定のハンドルに関連付けられた各データ値のレベルでアクセス制御を定義できます。各ハンドルは、ネットワークまたはホスト管理者から独立した独自の管理者セットをさらに定義できます。
Traditional URLs (Uniform Resource Locators) [4] allow certain Internet resources to be named as a combination of a DNS name and local name. The local name may be a local file path, or a reference to some local service (e.g., a cgi-bin script). This combination of a DNS name and a local name provides a flexible administrative model for naming and managing individual Internet resources. However, the URL practice also has some key limitations. Most URL schemes (e.g., http) are defined for resolution only. Any URL administration has to be done either at the local host, or via some other network service such as NFS. Using a URL as a name typically ties the Internet resource to its current network location. For example, a URL will be tied to its local file path when the file path is part of the URL. When the resource moves from one location to another for whatever reason, the URL breaks. It is especially difficult to work around this problem when the reason for the location change is change in ownership of an asset, as ownership is generally reflected in the domain name.
従来のURL（ユニフォームリソースロケーター）[4]は、特定のインターネットリソースをDNS名とローカル名の組み合わせとして名前を付けることができます。ローカル名は、ローカルファイルパス、またはいくつかのローカルサービスへの参照（CGI-Binスクリプトなど）です。DNS名とローカル名のこの組み合わせは、個々のインターネットリソースを命名および管理するための柔軟な管理モデルを提供します。ただし、URLプラクティスにはいくつかの重要な制限もあります。ほとんどのURLスキーム（HTTPなど）は、解像度のみで定義されます。すべてのURL管理は、ローカルホストで、またはNFSなどの他のネットワークサービスを介して行う必要があります。URLを名前として使用すると、通常、インターネットリソースを現在のネットワークの場所に結び付けます。たとえば、ファイルパスがURLの一部である場合、URLはローカルファイルパスに関連付けられます。何らかの理由でリソースがある場所から別の場所に移動すると、URLは壊れます。所有権は一般にドメイン名に反映されているため、場所の変更の理由が資産の所有権の変更である場合、この問題を回避することは特に困難です。
The Handle System is designed to overcome these limitations and to add significant functionality. Specifically, the Handle System is designed with the following objectives:
ハンドルシステムは、これらの制限を克服し、重要な機能を追加するように設計されています。具体的には、ハンドルシステムは次の目的で設計されています。
- Uniqueness: Every handle is globally unique within the Handle System.
- 一意性：すべてのハンドルは、ハンドルシステム内でグローバルにユニークです。
- Persistence: Handles may be used as persistent identifiers for Internet resources. A handle does not have to be derived from the entity that it names. While an existing name, or even a mnemonic, may be included in a handle for convenience, the only operational connection between a handle and the entity it names is maintained within the Handle System. This of course does not guarantee persistence, which is a function of administrative care. But it does allow the same name to persist over changes of location, ownership, and other state conditions. For example, when a named resource moves from one location to another, the handle may be kept valid by updating its value in the Handle System to reflect the new location.
- 永続性：ハンドルは、インターネットリソースの永続的な識別子として使用できます。ハンドルは、名前のエンティティから派生する必要はありません。既存の名前、またはニーモニックでさえも、利便性のためにハンドルに含まれる場合がありますが、ハンドルと名前のエンティティとの間の唯一の運用上の接続は、ハンドルシステム内で維持されます。これはもちろん、管理ケアの関数である持続性を保証するものではありません。しかし、同じ名前が場所、所有権、その他の状態の条件の変更を維持することができます。たとえば、名前付きのリソースがある場所から別の場所に移動する場合、ハンドルシステムの値を更新して新しい場所を反映することにより、ハンドルを有効に保つことができます。
- Multiple Instances: A single handle can refer to multiple instances of a resource, at different and possibly changing locations in a network. Applications can take advantage of this to increase performance and reliability. For example, a network service may define multiple entry points for its service with a single handle so as to distribute the service load.
- 複数のインスタンス：単一のハンドルは、ネットワーク内のさまざまな変化する場所で、リソースの複数のインスタンスを参照できます。アプリケーションはこれを利用して、パフォーマンスと信頼性を高めることができます。たとえば、ネットワークサービスは、サービスの負荷を配布するために、単一のハンドルでサービスの複数のエントリポイントを定義できます。
- Multiple Attributes: A single handle can refer to multiple attributes of a resource, including associated services, available through any method at different and possibly changing network locations. Handles can thus be used as persistent entry points into an evolving world of services associated with identified resources.
- 複数の属性：単一のハンドルは、異なる変更されたネットワークロケーションでの任意の方法で利用可能な関連サービスを含むリソースの複数の属性を参照できます。したがって、ハンドルは、特定されたリソースに関連するサービスの進化する世界への永続的なエントリポイントとして使用できます。
- Extensible Namespace: Existing local namespaces may join the handle namespace by acquiring a unique handle naming authority. This allows local namespaces to be introduced into a global context while avoiding conflict with existing namespaces. Use of naming authorities also allows delegation of service, both resolution and administration, to a local handle service.
- 拡張可能な名前空間：既存のローカルネームスペースは、一意のハンドル命名機関を取得することにより、ハンドル名空間に参加できます。これにより、既存の名前空間との対立を避けながら、ローカルの名前空間をグローバルなコンテキストに導入できます。命名当局を使用することで、地元のハンドルサービスに、解決と管理の両方のサービスの委任が可能になります。
- International Support: The handle namespace is based on Unicode 3.0 [17], which includes most of the characters currently used around the world. This allows handles to be used in any native environment. The handle protocol mandates UTF-8 [5] as the encoding used for handles.
- 国際的なサポート：ハンドルネームスペースは、現在世界中で使用されているほとんどのキャラクターを含むUnicode 3.0 [17]に基づいています。これにより、どのネイティブ環境でもハンドルを使用できます。ハンドルプロトコルは、ハンドルに使用されるエンコーディングとしてUTF-8 [5]を義務付けています。
- Distributed Service Model: The Handle System defines a hierarchical service model such that any local handle namespace may be serviced by a corresponding local handle service, by the global service, or by both. The global service, known as the Global Handle Registry, can be used to dispatch any handle service request to the responsible local handle service. The distributed service model allows replication of any given service into multiple service sites, and each service site may further distribute its service into a cluster of individual servers. (Note that local here refers only to namespace and administrative concerns. A local handle service could in fact have many service sites distributed across the Internet.)
- 分散サービスモデル：ハンドルシステムは、任意のローカルハンドルネームスペースが、対応するローカルハンドルサービス、グローバルサービス、またはその両方でサービスを受けることができるように、階層サービスモデルを定義します。グローバルハンドルレジストリとして知られるグローバルサービスを使用して、責任あるローカルハンドルサービスにハンドルサービスリクエストを派遣できます。分散サービスモデルにより、特定のサービスを複数のサービスサイトに複製することができ、各サービスサイトはさらにサービスを個々のサーバーのクラスターに分配できます。（ここのローカルは、名前空間と管理上の懸念のみを指します。実際、ローカルハンドルサービスは、インターネット全体に多くのサービスサイトを配布する可能性があります。）
- Secured Name Service: The Handle System allows secured name resolution and administration over the public Internet. The Handle System protocol defines standard mechanisms for both client and server authentication, as well as service authorization. It also provides security options to assure data integrity and confidentiality.
- セキュリティ済みの名前サービス：ハンドルシステムにより、パブリックインターネット上のセキュリティで保護された名前解像度と管理が可能になります。ハンドルシステムプロトコルは、クライアントとサーバー認証の両方の標準メカニズム、ならびにサービス承認を定義します。また、データの整合性と機密性を保証するためのセキュリティオプションも提供します。
- Distributed Administration Service: Each handle may define its own administrator(s) or administrator group(s). Ownership of each handle is defined in terms of its administrator or administrator groups. This, combined with the Handle System authentication protocol, allows any handle to be managed securely over the public network by its administrator at any network location.
- 分散管理サービス：各ハンドルは、独自の管理者または管理者グループを定義できます。各ハンドルの所有権は、管理者グループまたは管理者グループの観点から定義されます。これは、ハンドルシステム認証プロトコルと組み合わせることで、任意のネットワークの場所で管理者がハンドルをパブリックネットワーク上で安全に管理できるようにします。
- Efficient Resolution Service: The handle protocol is designed to allow highly efficient name resolution performance. To avoid resolution being affected by computationally costly administration service, separate service interfaces (i.e., server processes and their associated communication ports) for handle name resolution and administration may be defined by any handle service.
- 効率的な解像度サービス：ハンドルプロトコルは、非常に効率的な名前解像度パフォーマンスを可能にするように設計されています。解像度が計算的に費用のかかる管理サービスの影響を受けることを避けるために、ハンドル名の解決と管理のための個別のサービスインターフェイス（つまり、サーバープロセスと関連する通信ポート）は、任意のハンドルサービスによって定義される場合があります。
This document provides an overview of the handle namespace and service architecture. It also compares the Handle System with other existing Internet services, protocols, and specifications (e.g., DNS [2, 3], URLs [4], X.500/LDAP [6,7,8], and URN [9,10]). Details of the handle system data and service model, as well as its communication protocol, are specified in separate documents. They can be found under the Handle System website at http://www.handle.net.
このドキュメントでは、ハンドル名の概要とサービスアーキテクチャを提供します。また、ハンドルシステムを他の既存のインターネットサービス、プロトコル、および仕様と比較します（例：DNS [2、3]、URLS [4]、X.500/LDAP [6,7,8]、およびURN [9,10]）。ハンドルシステムデータとサービスモデルの詳細、およびその通信プロトコルは、個別のドキュメントで指定されています。それらは、http://www.handle.netのハンドルシステムWebサイトの下にあります。
Since there are a number of name related projects in the Internet community, it is worth defining exactly where we believe the Handle System fits. Unfortunately, that is particularly hard because the other primary naming schemes either take an abstract services approach (e.g., URI/URN), or an approach to name resolution absent of a self-contained framework for reliable yet distributed administration of the underlying databases (e.g., DNS). This makes categorizing the Handle System difficult.
インターネットコミュニティには多くの名前関連プロジェクトがあるため、ハンドルシステムが適合していると思われる場所を正確に定義する価値があります。残念ながら、他の主要な命名スキームは、抽象サービスアプローチ（URI/URNなど）を取るか、基礎となるデータベースの信頼できるが分散している管理のための自己完結型フレームワークを除いて、名前解像度のアプローチ（例：、DNS）。これにより、ハンドルシステムの分類が困難になります。
The Handle System crosses boundaries. Looked at as a name resolution system, it might be compared to DNS. If used to implement a URI/URN namespace, it could be used with any URI/URN scheme. If used for distributed information updates and administration, it could be considered a simplified-version of a distributed database system.
ハンドルシステムは境界を越えます。名前解像度システムと見なされると、DNSと比較される可能性があります。URI/URNネームスペースの実装に使用すると、任意のURI/URNスキームで使用できます。分散情報の更新と管理に使用される場合、分散データベースシステムの単純化されたバージョンと見なされる可能性があります。
It is probably best to view the Handle System as a name-attribute binding service with a specific protocol for securely creating, updating, maintaining, and accessing a distributed database. It is designed to be an enabling service for secured information and resource sharing over networks such as the public Internet. Applications of the Handle System could include meta-data services for digital publications, identity management services for virtual identities, or any other applications that require resolution and/or administration of globally unique identifiers.
おそらく、ハンドルシステムを、分散データベースを安全に作成、更新、維持、およびアクセスするための特定のプロトコルを使用して、名前アトリビングバインディングサービスとして表示することをお勧めします。パブリックインターネットなどのネットワークを介した安全な情報とリソース共有のための有効化サービスとなるように設計されています。ハンドルシステムのアプリケーションには、デジタル出版物向けのメタデータサービス、仮想アイデンティティのアイデンティティ管理サービス、またはグローバルに一意の識別子の解決および/または管理を必要とするその他のアプリケーションが含まれます。
In the spirit of exploration, the Handle System has been designed to have high performance for name resolution and to push the boundaries of distributed access control and administration. Unlike most conventional systems (even distributed systems) that are designed to have a relatively small number of broadly empowered administrators, the Handle System allows extremely fine granularity of administrative control. It has a unique self-contained administrative framework that de-couples the ownership of each handle from the system administrators and allows access control to be defined for each handle value.
探索の精神では、ハンドルシステムは、名前の解決のために高性能を持ち、分散アクセス制御と管理の境界を押し広げるように設計されています。比較的少数の広範なエンパワーメント管理者を持つように設計されたほとんどの従来のシステム（分散システムも）とは異なり、ハンドルシステムは、管理制御の非常に細かい粒度を可能にします。システム管理者からの各ハンドルの所有権を削除し、各ハンドル値に対してアクセス制御を定義できるユニークな自己完結型管理フレームワークを備えています。
It should be noted, that as with all real systems, the Handle System is a compromise between a number of technical and practical concerns. There are also different opinions within the IETF on where the Handle System fits in relation to other existing Internet name services. It is with the goal of exposing a broader community to the concepts, approach, specific decisions, tradeoffs and results that we are writing this RFC.
すべての実際のシステムと同様に、ハンドルシステムは多くの技術的および実際的な懸念の間の妥協点であることに注意する必要があります。また、IETFには、他の既存のインターネット名サービスに関連して、ハンドルシステムが適合する場所についてさまざまな意見があります。このRFCを書いているのは、より広範なコミュニティを概念、アプローチ、特定の決定、トレードオフ、結果にさらすことを目標としています。
Every handle consists of two parts: its naming authority, otherwise known as its prefix, and a unique local name under the naming authority, otherwise known as its suffix:
すべてのハンドルは2つの部分で構成されています。その命名権限、その接頭辞としても知られています。また、命名権限の下でのユニークなローカル名、その接尾辞としても知られています。
<Handle> ::= <Handle Naming Authority> "/" <Handle Local Name>
The naming authority and local name are separated by the ASCII character "/". The collection of local names under a naming authority defines the local handle namespace for that naming authority. Any local name must be unique under its local namespace. The uniqueness of a naming authority and a local name under that authority ensures that any handle is globally unique within the context of the Handle System.
命名当局とローカル名は、ASCII文字「/」によって区切られています。命名当局の下での地元の名前のコレクションは、その命名当局のローカルハンドル名空間を定義しています。ローカル名は、ローカルネームスペースの下で一意でなければなりません。命名当局の独自性とその権限の下でのローカル名は、ハンドルシステムのコンテキスト内でどのハンドルがグローバルにユニークであることを保証します。
For example, "10.1045/january99-bearman" is a handle for an article published in D-Lib magazine [12]. Its naming authority is "10.1045" and its local name is "january99-bearman". The handle namespace can be considered a superset of many local namespaces, with each local namespace having a unique naming authority under the Handle System. The naming authority identifies the administrative unit of creation, although not necessarily continuing administration, of the associated handles. Each naming authority is guaranteed to be globally unique within the Handle System. Any existing local namespace can join the global handle namespace by obtaining a unique naming authority so that any local name under the namespace can be globally referenced as a combination of the naming authority and the local name as shown above.
たとえば、「10.1045/1月99年 - ベアマン」は、D-LIB雑誌[12]に掲載された記事のハンドルです。その命名当局は「10.1045」であり、そのローカル名は「99年1月 - ベアマン」です。ハンドルネームスペースは、多くのローカルネームスペースのスーパーセットと見なすことができ、各ローカルネームスペースにはハンドルシステムの下に一意の命名権限があります。命名当局は、関連するハンドルの管理の管理単位を必ずしも継続的な管理ではありませんが、継続的な管理ユニットを特定します。各命名機関は、ハンドルシステム内でグローバルにユニークであることが保証されています。既存のローカルネームスペースは、一意の命名機関を取得することにより、グローバルハンドルネームスペースに参加でき、名前空間の下のローカル名を上記のように命名機関とローカル名の組み合わせとしてグローバルに参照できるようにします。
Naming authorities under the Handle System are defined in a hierarchical fashion resembling a tree structure. Each node and leaf of the tree is given a label that corresponds to a naming authority segment. The parent node notifies the parent naming authority of its child nodes. Unlike DNS, handle naming authorities are constructed left to right, concatenating the labels from the root of the tree to the node that represents the naming authority. Each label is separated by the octet used for ASCII character "." (0x2E). For example, a naming authority for the National Digital Library Program ("ndlp") at the Library of Congress ("loc") is defined as "loc.ndlp".
ハンドルシステムの下での命名当局は、木の構造に似た階層的な方法で定義されています。ツリーの各ノードと葉には、命名権限セグメントに対応するラベルが与えられます。親ノードは、子ノードの親命名機関に通知します。DNSとは異なり、ハンドルの命名当局は左から右に構築され、ツリーのルートから命名権限を表すノードにラベルを連結します。各ラベルは、ASCII文字「」に使用されるオクテットによって区切られています。（0x2e）。たとえば、議会図書館（「loc」）の国家デジタル図書館プログラム（「NDLP」）の命名当局は、「loc.ndlp」と定義されています。
Each naming authority may have many child naming authorities registered underneath. Any child naming authority can only be registered by its parent after its parent naming authority has been registered. However, there is no intrinsic administrative relationship between the namespaces represented by the parent and child naming authorities. The parent namespace and its child namespaces may be served by different handle services, and they may or may not share any administration privileges.
各命名当局には、下に登録されている多くの子どもの命名当局がいるかもしれません。児童命名機関は、親の命名当局が登録された後にのみ、親によって登録できます。ただし、親と子の命名当局によって表される名前空間の間に本質的な管理関係はありません。親ネームスペースとその子ネームスペースは、異なるハンドルサービスが提供する場合があり、管理特権を共有する場合と共有しない場合があります。
Handles may consist of any printable characters from the Universal Character Set (UCS-2) of ISO/IEC 10646, which is the exact character set defined by Unicode v3.0 [17]. The UCS-2 character set encompasses most characters used in every major language written today. To allow compatibility with most of the existing systems and to prevent ambiguity among different encodings, the Handle System protocol mandates UTF-8 to be the only encoding used for handles. The UTF-8 encoding preserves any ASCII encoded names so as to allow maximum compatibility with existing systems without causing naming conflict. Some encoding issues over the global namespace and the choice of UTF-8 encoding are discussed in [13].
ハンドルは、ISO/IEC 10646のユニバーサル文字セット（UCS-2）の印刷可能な文字で構成されている場合があります。これは、Unicode v3.0 [17]で定義された正確な文字セットです。UCS-2文字セットには、今日書かれたすべての主要言語で使用されるほとんどの文字が含まれます。既存のシステムのほとんどと互換性を可能にし、異なるエンコーディング間のあいまいさを防ぐために、ハンドルシステムプロトコルはUTF-8がハンドルに使用される唯一のエンコードであることを義務付けています。UTF-8エンコーディングは、ASCIIエンコードされた名前を維持して、命名競合を引き起こすことなく既存のシステムとの最大の互換性を可能にします。グローバルネームスペースとUTF-8エンコードの選択に関するいくつかのエンコードの問題については、[13]で説明しています。
By default, handles are case sensitive. However, any individual handle service may define its namespace such that ASCII characters within any handle under that namespace are case insensitive.
デフォルトでは、ハンドルはケースに敏感です。ただし、個々のハンドルサービスは、その名前空間の下の任意のハンドル内のASCII文字が鈍感であるように、その名前空間を定義することができます。
The Handle System defines a hierarchical service model. The top level consists of a single handle service, known as the Global Handle Registry (GHR). The lower level consists of all other handle services, generically known as Local Handle Services (LHS).
ハンドルシステムは、階層サービスモデルを定義します。トップレベルは、グローバルハンドルレジストリ（GHR）として知られる単一のハンドルサービスで構成されています。低いレベルは、一般的にローカルハンドルサービス（LHS）として知られている他のすべてのハンドルサービスで構成されています。
The Global Handle Registry can be used to manage any handle namespace. It is unique among handle services only in that it provides the service used to manage naming authorities, all of which are managed as handles. The naming authority handle provides information that clients can use to access and utilize the local handle service for handles under the naming authority.
グローバルハンドルレジストリを使用して、任意のハンドルネームスペースを管理できます。命名当局の管理に使用されるサービスを提供するという点でのみ、ハンドルサービスの間でユニークです。これらはすべてハンドルとして管理されています。命名機関のハンドルは、クライアントが命名当局の下でハンドルのためにローカルハンドルサービスにアクセスして利用できる情報を提供します。
Local Handle Services are intended to be hosted by organizations with administrative responsibility for handles under certain naming authorities. A Local Handle Service may be responsible for any number of local handle namespaces, each identified by a unique naming authority. The Local Handle Service and its responsible set of local handle namespaces must be registered with the Global Handle Registry.
ローカルハンドルサービスは、特定の命名当局に基づくハンドルの管理責任を持つ組織によってホストされることを目的としています。ローカルハンドルサービスは、それぞれが一意の命名機関によって識別される、任意の数のローカルハンドル名の責任を負う場合があります。ローカルハンドルサービスとその責任あるローカルハンドルネームスペースは、グローバルハンドルレジストリに登録する必要があります。
One important aspect of the Handle System is its distributed architecture. The Handle System as a whole consists of a number of individual handle services. Each of these services may consist of one or more service sites. Each service site is a complete replication of every other site in the service in terms of handle resolution. Each service site may consist of one or more handle servers. All handles, and hence all handle requests, directed at a given service site will be evenly distributed across these handle servers. The Handle System as a whole may consist of any number of handle services. There are no design limits on the number of handle services or on the number of sites which make up each service, nor are there any limits on the number of servers that make up each site. Replication among any service site does not require that each site contain the same number of servers. In other words, while each site will have the same replicated set of handles, each site may allocate that set of handles across a different number of servers. This distributed approach is intended to aid scalability, accommodate any large-scale of operation, and mitigate problems of single point failure.
ハンドルシステムの重要な側面の1つは、その分散アーキテクチャです。ハンドルシステム全体は、多くの個別のハンドルサービスで構成されています。これらの各サービスは、1つ以上のサービスサイトで構成されている場合があります。各サービスサイトは、ハンドル解像度の観点から、サービス内の他のすべてのサイトの完全な複製です。各サービスサイトは、1つ以上のハンドルサーバーで構成されている場合があります。特定のサービスサイトに向けられたすべてのハンドル、したがって、すべてのハンドルリクエストは、これらのハンドルサーバー全体に均等に配布されます。ハンドルシステム全体は、任意の数のハンドルサービスで構成されている場合があります。ハンドルサービスの数や、各サービスを構成するサイトの数には設計制限はありません。また、各サイトを構成するサーバーの数に制限はありません。サービスサイト間のレプリケーションでは、各サイトに同じ数のサーバーが含まれる必要はありません。言い換えれば、各サイトには同じ複製されたハンドルセットがありますが、各サイトは異なる数のサーバーでそのハンドルのセットを割り当てる場合があります。この分散アプローチは、スケーラビリティを支援し、大規模な動作に対応し、単一点障害の問題を軽減することを目的としています。
Figure 3.1 illustrates a potential handle service that consists of two service sites: one located on the U.S. east coast and the other on the U.S. west coast. The east coast service site consists of four server computers. The west coast service site, with more powerful computers deployed, decides two servers will suffice. The number of service sites for any handle service, as well as the number of servers that are used by any service site, may be added or removed dynamically depending on the service requirement.
図3.1は、2つのサービスサイトで構成される潜在的なハンドルサービスを示しています。1つは米国東海岸にあり、もう1つは米国西海岸にあります。東海岸のサービスサイトは、4つのサーバーコンピューターで構成されています。より強力なコンピューターが展開された西海岸のサービスサイトでは、2つのサーバーで十分であると判断します。ハンドルサービスのサービスサイトの数と、任意のサービスサイトで使用されるサーバーの数は、サービス要件に応じて動的に追加または削除できます。
------------------------- ------------------
| --------- --------- | | ----- ----- |
| | | | | | | | S | | S | |
| | server1 | | server2 | | | | E | | E | |
| | | | | | | | R | | R | |
| --------- --------- | | | V | | V | |
| --------- --------- | | | E | | E | |
| | | | | | | | R | | R | |
| | Server3 | | Server4 | | | | | | | |
| | | | | | | | 1 | | 2 | |
| --------- --------- | | ----- ----- |
------------------------- ------------------
Handle Service Site 1 Handle Service Site 2 (US East Coast) (US West Coast)
ハンドルサービスサイト1ハンドルサービスサイト2（米国東海岸）（米国西海岸）
Figure 3.1: Handle service configured with two service sites
図3.1：2つのサービスサイトで構成されたハンドルサービス
Each handle service manages a distinct sub-namespace under the Handle System. Namespaces under different handle services may not overlap. The sub-namespace typically consists of handles under a number of naming authorities. The handle service is called the "home" service of these naming authorities and is the only one that provides resolution and administration service for handles under these naming authorities. Before resolving a handle, a client has to determine the "home" service of the handle in question. The "home" service of each handle is the "home" service of its naming authority and is registered at the Global Handle Registry. Clients can find the "home" service for each handle by querying the naming authority handle at the Global Handle Registry.
各ハンドルサービスは、ハンドルシステムの下で個別のサブネームスペースを管理します。異なるハンドルサービスの下の名前空間は重複しない場合があります。サブネームスペースは通常、多くの命名当局の下でのハンドルで構成されています。ハンドルサービスは、これらの命名当局の「ホーム」サービスと呼ばれ、これらの命名当局の下でハンドルに解決と管理サービスを提供する唯一のものです。ハンドルを解決する前に、クライアントは問題のハンドルの「ホーム」サービスを決定する必要があります。各ハンドルの「ホーム」サービスは、命名権限の「ホーム」サービスであり、Global Handleレジストリに登録されています。クライアントは、グローバルハンドルレジストリで命名機関のハンドルを照会することにより、各ハンドルの「ホーム」サービスを見つけることができます。
The Global Handle Registry maintains naming authority handles. Each naming authority handle maintains the service information that describes the "home" service of the naming authority. The service information lists the service sites of the given handle service, as well as the interface to each handle server within each site. To find the "home" service for any handle, a client can query the Global Handle Registry for the service information associated with the corresponding naming authority handle. The service information provides the necessary information for clients to communicate with the "home" service.
グローバルハンドルレジストリは、命名権限ハンドルを維持しています。各命名機関のハンドルは、命名権限の「ホーム」サービスを説明するサービス情報を維持しています。サービス情報には、指定されたハンドルサービスのサービスサイトと、各サイト内の各ハンドルサーバーへのインターフェイスがリストされています。ハンドルの「ホーム」サービスを見つけるために、クライアントは、対応する命名機関のハンドルに関連付けられたサービス情報のグローバルハンドルレジストリを照会できます。サービス情報は、クライアントが「ホーム」サービスと通信するために必要な情報を提供します。
Figure 3.2 shows an example of a typical handle resolution process. In this case, the "home" service is a Local Handle Service. The client is trying to resolve the handle "10.1045/july95-arms" and has to find its "home" service from the Global Handle Registry. The "home" service can be found by sending a query to the Global Handle Registry for the naming authority handle for "10.1045". The Global Handle Registry returns the service information of the Local Handle Service that is responsible for handles under the naming authority "10.1045". The service information allows the client to communicate with the Local Handle Service to resolve the handle "10.1045/july95- arms".
図3.2は、典型的なハンドル解像度プロセスの例を示しています。この場合、「ホーム」サービスはローカルハンドルサービスです。クライアントは、ハンドル「10.1045/7月95アーム」を解決しようとしており、グローバルハンドルレジストリから「ホーム」サービスを見つけなければなりません。「ホーム」サービスは、「10.1045」の命名機関ハンドルのグローバルハンドルレジストリにクエリを送信することで見つけることができます。グローバルハンドルレジストリは、命名権限「10.1045」に基づくハンドルを担当するローカルハンドルサービスのサービス情報を返します。サービス情報により、クライアントはローカルハンドルサービスと通信して、ハンドル「10.1045/7月95アーム」を解決できます。
------------------------
| | 4. Result of client request
| Client with global | <-------------------------------.
| service information | |
| | ----------------------------. |
------------------------ 3. Request to responsible | |
| ^ Local Handle Service | |
1. Client | | | |
query for | | | |
naming | | 2. Service information | |
authority | | for "10.1045" V |
"10.1045" | | ----------------------
| | | |
V | | Local Handle Service |
--------------- | responsible for the |
| | | naming authority |
| Global Handle | | "10.1045" |
| Registry | | |
| | ----------------------
---------------
Figure 3.2: Handle resolution starting with global
図3.2：グローバルから始まる解像度を処理します
To improve resolution performance, any client may choose to cache the service information returned from the Global Handle Registry and use it for subsequent queries. A separate handle caching server, either stand-alone or as a piece of a general caching mechanism, may also be used to provide shared caching within a local community. Given a cached resolution result, subsequent queries of the same handle may be answered locally without contacting any handle service. Given cached service information, clients can send their requests directly to the correct Local Handle Service without contacting the Global Handle Registry.
解像度のパフォーマンスを改善するために、クライアントは、グローバルハンドルレジストリから返されたサービス情報をキャッシュし、それを後続のクエリに使用することを選択できます。スタンドアロンまたは一般的なキャッシュメカニズムの一部として、独立したハンドルキャッシュサーバーも、地域コミュニティ内で共有キャッシュを提供するために使用できます。キャッシュされた解像度の結果を考えると、同じハンドルのその後のクエリには、ハンドルサービスに連絡することなくローカルに回答できます。キャッシュされたサービス情報を考えると、クライアントはグローバルハンドルレジストリに連絡することなく、正しいローカルハンドルサービスにリクエストを直接送信できます。
The Handle System provides handle resolution and administration service over networks such as the public Internet. Each handle can be assigned a set of values. Clients use the handle resolution service to resolve any handle into its set of values. Each value has a data type and a unique value index. Clients can query for specific handle values based on data type or value index.
ハンドルシステムは、パブリックインターネットなどのネットワーク上のハンドル解像度と管理サービスを提供します。各ハンドルには、値のセットを割り当てることができます。クライアントは、ハンドル解像度サービスを使用して、ハンドルをその値のセットに解決します。各値には、データ型と一意の値インデックスがあります。クライアントは、データ型または値インデックスに基づいて、特定のハンドル値をクエリできます。
The handle administration service answers requests from clients to manage handles. These include adding handles, deleting handles or updating their values. It also manages naming authorities via naming authority handles. Each handle can have its own administrator(s), and each administrator can be granted a certain set of permissions.
ハンドル管理サービスは、ハンドルを管理するためのクライアントからのリクエストに応答します。これらには、ハンドルの追加、ハンドルの削除、またはその値の更新が含まれます。また、命名当局ハンドルを介して命名当局を管理しています。各ハンドルには独自の管理者を持つことができ、各管理者に特定の許可セットを付与できます。
The handle system authentication protocol authenticates the handle administrator before fulfilling any administrative request.
ハンドルシステム認証プロトコルは、管理リクエストを満たす前にハンドル管理者を認証します。
The Handle System provides security services such as client and server authentication, data confidentiality and integrity, and non-repudiation. By default, handle resolution does not require any client authentication. However, resolution requests for confidential data assigned to any handle (by its administrator), as well as any administration requests (e.g., adding or deleting handle values) require authentication of the client for proper authorization. The server will decide, during the authorization process, whether or not the client has permission to access those confidential handle values, or has permission to add or update handles and handle values. When authentication is required, the handle server will issue a challenge to the requesting client before carrying out the client's request. To satisfy the authentication requirement, the client must send back the correct response identifying itself as a qualified administrator. The handle server will respond to the initial request only after successful authentication of the client. Handle clients may choose to use either secret key or public key cryptography for authentication. Handle System authentication can also be carried out via third party authentication services. To ensure data integrity, clients may request digitally signed responses from any handle server. They may also set up secured communication sessions with handle servers so that any exchanged information can be encrypted (for data confidentiality) using a session key. Handle servers can also provide confidentiality by encrypting the handle data before sending it to the client.
ハンドルシステムは、クライアントおよびサーバーの認証、データの機密性と整合性、非和解などのセキュリティサービスを提供します。デフォルトでは、ハンドル解像度ではクライアント認証は必要ありません。ただし、ハンドル（その管理者によって）に割り当てられた機密データの解決要求、および管理要求（たとえば、ハンドル値の追加または削除）には、適切な承認のためにクライアントの認証が必要です。サーバーは、承認プロセス中に、クライアントがこれらの機密のハンドル値にアクセスする許可を持っているか、ハンドルを追加または更新して値を処理する許可を持っているかどうかを決定します。認証が必要な場合、ハンドルサーバーは、クライアントのリクエストを実行する前に、クライアントの要求に課題を発行します。認証要件を満たすには、クライアントは、資格のある管理者として自分自身を識別する正しい応答を返送する必要があります。ハンドルサーバーは、クライアントの認証が成功した後にのみ、初期リクエストに応答します。ハンドルクライアントは、認証のためにシークレットキーまたは公開キーの暗号化のいずれかを使用することを選択できます。ハンドルシステム認証は、サードパーティの認証サービスを介して実行することもできます。データの整合性を確保するために、クライアントは任意のハンドルサーバーからデジタル署名された応答を要求する場合があります。また、セッションキーを使用して、交換された情報を（データの機密性のために）暗号化できるように、ハンドルサーバーを使用したセキュリティでの通信セッションをセットアップすることもできます。ハンドルサーバーは、クライアントに送信する前にハンドルデータを暗号化することにより、機密性を提供することもできます。
The Handle System provides service options for secured information exchange between the client and server. This does not, of course, guarantee the truthfulness of handle values. Incorrect values assigned to any handle by its administrator may very well mislead clients. On the other hand, a handle value may contain references to other handle values to provide additional credentials. For example, a handle value R (e.g., a claim) may contain a reference to some other handle value that contains the digital signature (from a creditable source) upon the value R. Clients who trust the signature could then trust the handle value R.
ハンドルシステムは、クライアントとサーバー間の安全な情報交換のためのサービスオプションを提供します。もちろん、これはハンドル値の真実性を保証するものではありません。管理者によってハンドルに割り当てられた誤った値は、クライアントを非常に誤解させる可能性があります。一方、ハンドル値には、追加の資格情報を提供するために、他のハンドル値への参照が含まれている場合があります。たとえば、ハンドル値R（例：クレーム）には、値Rにデジタル署名（クレジットソースから）を含む他のハンドル値への参照が含まれている場合があります。。
There are a number of existing and proposed Internet identifier services or specifications that, by design or intent, cover some of the functionalities proposed for the Handle System. This section briefly reviews them in relationship to the Handle System.
デザインまたは意図により、ハンドルシステムに提案されている機能の一部をカバーする既存および提案されているインターネット識別子サービスまたは仕様がいくつかあります。このセクションでは、ハンドルシステムとの関係で簡単にレビューします。
The Domain Name Service, or DNS, was originally designed and is heavily used for mapping domain names into IP Addresses for network routing purposes. RFC 1034 [2] and RFC 1035 [3] provide detailed descriptions of its design and implementation. The growth of the Internet has increased demands for various extensions to DNS, even its possible use as a general purpose resource naming system. However, any such use has the potential to slow down the network address translation and/or affect its effectiveness in network routing. DNS implementations typically do not scale well when a large amount of data is associated with any particular DNS name. It is therefore generally considered inappropriate to use DNS as a general-purpose naming service.
ドメイン名サービス（DNS）は元々設計されており、ネットワークルーティングの目的でドメイン名をIPアドレスにマッピングするために非常に使用されています。RFC 1034 [2]およびRFC 1035 [3]は、その設計と実装の詳細な説明を提供します。インターネットの成長は、DNSへのさまざまな拡張に対する需要を増加させており、汎用リソース命名システムとしての使用の可能性さえあります。ただし、このような用途は、ネットワークアドレスの変換を遅くしたり、ネットワークルーティングにおけるその有効性に影響を与える可能性があります。通常、DNSの実装は、大量のデータが特定のDNS名に関連付けられている場合、十分にスケーリングしません。したがって、一般に、DNSを汎用命名サービスとして使用することは不適切であると考えられています。
An additional factor that argues against using DNS as a general-purpose naming service is the DNS administrative model. DNS names are typically managed by the network administrator(s) at the DNS zone level. There is no provision for a per-name administrative structure. No facilities are provided for anyone other than network administrators to create or manage DNS names. This is appropriate for domain name administration but less so for general-purpose name administration.
DNSを汎用命名サービスとして使用することに反対する追加要因は、DNS管理モデルです。DNS名は通常、DNSゾーンレベルでネットワーク管理者によって管理されます。名前ごとの管理構造の規定はありません。ネットワーク管理者以外の人がDNS名を作成または管理する施設は提供されていません。これはドメイン名の管理に適していますが、汎用名の管理にはあまり適していません。
The Handle System differs from DNS in its distributed administration and service model, as well as its security features. The handle system protocol includes security options to assure confidentiality and integrity during data transmission. Each handle can have its own administrator, independent from the server administrator. The handle system protocol allows any handle administrator to manage his or her handles securely over the public network. Additionally, the Handle System service model allows any of its service sites to dynamically configure its service distribution among a cluster of servers to accommodate increased service requests. This also allows less powerful computers to be used together to support any arbitrarily large number of handles.
ハンドルシステムは、分散型管理およびサービスモデル、およびセキュリティ機能のDNSとは異なります。ハンドルシステムプロトコルには、データ送信中に機密性と整合性を保証するセキュリティオプションが含まれています。各ハンドルには、サーバー管理者から独立した独自の管理者を持つことができます。ハンドルシステムプロトコルにより、ハンドル管理者はパブリックネットワーク上でハンドルを安全に管理できます。さらに、ハンドルシステムサービスモデルにより、サービスサイトのいずれかがサーバーのクラスター間でサービス分布を動的に構成して、サービスリクエストの増加に対応できます。これにより、あまり強力なコンピューターを一緒に使用して、任意に多数のハンドルをサポートすることができます。
X.500 [6] is the OSI Directory Standard defined by the ISO and the ITU. It is designed "to provide a white pages service that would return either the telephone numbers or X.400 O/R addresses of people", and is "concerned mainly with providing the name server service for Open Systems Interconnection (OSI) applications" [7]. X.500 defines a hierarchical data and information model with a set of protocols to allow global name lookup and search. The protocol, however, has proved difficult to implement and there has been difficulty in getting "client access integrated into existing products" [14]. LDAP (Lightweight Directory Access Protocol) [8] has overcome many of these difficulties by making the protocol simpler and easier to implement. Some concern remains, however, that as LDAP is emerging from a local directory access protocol (LDAP v2) into a distributed service protocol (LDAP v3), it faces many issues not addressed in its original design, resulting in new complications.
X.500 [6]は、ISOとITUによって定義されたOSIディレクトリ標準です。「電話番号またはX.400 O/Rアドレスのいずれかを返すホワイトページサービスを提供するように設計されており、「主にOpen Systems Interconnection（OSI）アプリケーションの名前サーバーサービスを提供することに関係しています」[7]。X.500は、グローバル名の検索と検索を可能にする一連のプロトコルを備えた階層データと情報モデルを定義します。しかし、このプロトコルは実装が困難であることが判明しており、「既存の製品にクライアントアクセスを統合する」ことが困難でした[14]。LDAP（LightWeight Directory Access Protocol）[8]は、プロトコルをよりシンプルかつ簡単に実装できるようにすることで、これらの困難の多くを克服しました。ただし、LDAPがローカルディレクトリアクセスプロトコル（LDAP V2）から分散サービスプロトコル（LDAP V3）に出現しているため、元の設計では対処されていない多くの問題に直面して、新しい複雑さをもたらすという懸念が残っています。
The fundamental difference between a name resolution service such as the Handle System, and a directory service such as LDAP, is search capability. The added functionality of being able to search a directory service necessarily carries with it added complexity, thus affects its efficiency. A pure name service, such as the Handle System, can be designed solely around efficient resolution of known items without addressing functions and data structures required for discovery of unknown items based on incomplete criteria.
ハンドルシステムなどの名前解像度サービスとLDAPなどのディレクトリサービスの根本的な違いは、検索機能です。ディレクトリサービスを検索できるという追加の機能は、必然的に複雑さが追加されるため、その効率に影響します。ハンドルシステムなどの純粋な名前サービスは、不完全な基準に基づいて不明なアイテムの発見に必要な機能やデータ構造に対処することなく、既知のアイテムの効率的な解像度のみを中心に設計できます。
Directory services, such as LDAP or WHOIS++ [15,16], may be used in tandem with the Handle System to provide reverse lookup service. Existing corporate directory services, for example, could provide interfaces to both services. The Handle System interface would provide a highly efficient name resolution service. The directory service interface would provide extended search capability. Handles could also be used in LDAP service referral. For example, an LDAP service may be referenced as a handle. Doing so will make the reference persistent overtime, independent of location change.
LDAPやWHOIS [15,16]などのディレクトリサービスは、ハンドルシステムとタンデムで使用して、リバースルックアップサービスを提供できます。たとえば、既存のコーポレートディレクトリサービスは、両方のサービスにインターフェイスを提供できます。ハンドルシステムインターフェイスは、非常に効率的な名前解像度サービスを提供します。ディレクトリサービスインターフェイスは、拡張検索機能を提供します。ハンドルは、LDAPサービス紹介でも使用できます。たとえば、LDAPサービスはハンドルとして参照される場合があります。そうすることで、場所の変更とは無関係に、参照が残業を永続的に持続させることができます。
Uniform Resource Identifier (URI) [23] defines a uniform, yet extensible naming mechanism for identifying Internet resources in web applications. Uniform Resource Name (URN) [11], a subset of URI, defines a namespace registration mechanism for persistent namespaces under URI. URI/URN represents most of the Internet name services used in web applications. This section discusses the relationship of the Handle System to URI/URN and how applications may utilize the Handle System within the URI/URN context.
均一なリソース識別子（URI）[23]は、Webアプリケーションでインターネットリソースを識別するための均一でありながら拡張可能な命名メカニズムを定義します。URIのサブセットであるユニフォームリソース名（URN）[11]は、URIの下の永続的な名前空間の名前空間登録メカニズムを定義しています。URI/URNは、Webアプリケーションで使用されるインターネット名サービスのほとんどを表します。このセクションでは、ハンドルシステムとURI/URNとの関係と、アプリケーションがURI/URNコンテキスト内でハンドルシステムを利用する方法について説明します。
The Handle System provides a general-purpose name service for the Internet. Like DNS or X.500 directory service, the Handle System defines its namespace outside of any URI/URN namespace. Handles can be transcribed and resolved directly, without any URI/URN scheme as a prefix. For example, a library application may resolve the handle "10.1045/july95-arms" directly into its set of handle values. No URI/URN scheme will be needed in this case.
ハンドルシステムは、インターネットに汎用名サービスを提供します。DNSやX.500ディレクトリサービスと同様に、ハンドルシステムはURI/URNネームスペースの外側の名前空間を定義します。ハンドルは、プレフィックスとしてURI/URNスキームを使用することなく、直接転写および解決できます。たとえば、ライブラリアプリケーションは、ハンドル「10.1045/7月95アーム」をハンドルの値のセットに直接解決する場合があります。この場合、URI/URNスキームは必要ありません。
The Handle System may be used for applications that require a persistent name service. The Handle System provides the necessary mechanisms to allow persistent names to be registered as handles.
ハンドルシステムは、永続的な名前サービスを必要とするアプリケーションに使用できます。ハンドルシステムは、永続的な名前をハンドルとして登録できるようにするために必要なメカニズムを提供します。
Specific naming authorities may be defined to host those handles designed to be persistent. However, the persistence of handles depends more on administrative policies than the technology itself. Such policies are beyond the Handle System service, as described in this set of documents.
特定の命名当局は、永続的になるように設計されたハンドルをホストするために定義される場合があります。ただし、ハンドルの持続性は、テクノロジー自体よりも管理ポリシーに大きく依存します。このようなポリシーは、この一連のドキュメントで説明されているように、ハンドルシステムサービスを超えています。
On the other hand, the Handle System can also be used for applications where persistent names are not required. Such handles may have a short life-time and they may also be used to identify different objects at different times.
一方、ハンドルシステムは、永続的な名前が不要なアプリケーションにも使用できます。このようなハンドルには短い寿命があり、異なる時間に異なるオブジェクトを識別するためにも使用される場合があります。
Different web applications may be developed using the Handle System as the underlying name service. Each of these applications may define its own URI/URN namespace for its application needs. For example, application FOO may have a URI namespace "foo:" registered to identify any FOO services on the web. In the mean time, application BAR may have a URN namespace "URN:BAR" registered to identify any BAR object that needs a persistent name. Both FOO and BAR applications may use handles (under their respective naming authority) in naming and resolving to services and/or objects. This is similar in DNS, where there are different URI schemes (e.g., "telnet", "ftp", "mailto", etc.) defined for different applications, all using the DNS service.
基礎となる名前サービスとして、ハンドルシステムを使用してさまざまなWebアプリケーションを開発できます。これらの各アプリケーションは、アプリケーションのニーズに合わせて独自のURI/URNネームスペースを定義する場合があります。たとえば、アプリケーションFOOには、Web上のFOOサービスを識別するために登録されているURI名空間「FOO：」があります。それまでの間、アプリケーションバーには、永続的な名前が必要なバーオブジェクトを識別するために登録されたurn名空間「urn：bar」がある場合があります。Fooアプリケーションとバーアプリケーションの両方が、サービスおよび/またはオブジェクトへの命名および解決において、ハンドル（それぞれの命名当局の下）を使用する場合があります。これは、異なるアプリケーションで定義された異なるURIスキーム（「Telnet」、「FTP」、「MailTo」など）が異なる異なるURIスキーム（例：すべてDNSサービスを使用しています）で類似しています。
The IETF and IRTF have discussed the Handle System in the realm of URI-related work. There are different opinions on whether the Handle System will fit into a specific URI or URN namespace. There are also concerns on where the Handle System fits in relation to other existing name services on the Internet. Such discussions are out of the scope of this document.
IETFとIRTFは、URI関連作業の領域でハンドルシステムについて議論しました。ハンドルシステムが特定のURI名前空間に適合するかどうかについては、さまざまな意見があります。インターネット上の他の既存の名前サービスに関連して、ハンドルシステムがどこに適合するかについての懸念もあります。このような議論は、このドキュメントの範囲外です。
This section is meant to inform people of security limitations of the Handle System, as well as precautions that should be taken by application developers, service providers, and Handle System clients. Specific security considerations regarding the Handle System protocol [21], as well as its data and service model [22], are addressed in separate documents.
このセクションは、ハンドルシステムのセキュリティの制限、およびアプリケーション開発者、サービスプロバイダー、およびハンドルシステムクライアントが取るべき予防策を人々に通知することを目的としています。ハンドルシステムプロトコル[21]、およびそのデータおよびサービスモデル[22]に関する具体的なセキュリティ上の考慮事項は、個別のドキュメントで対処されています。
The security of the Handle System depends on both client and server host security at every step in the transaction. It assumes the client host has not been tampered with and that client software will reliably convey the received data to the client. The client of any handle service must also assume that any handle servers involved have not been compromised. To trust the Global Handle Registry is to believe that the Global Handle Registry will correctly direct the client request to the responsible Local Handle Service. To trust a Local Handle Service is to believe that the Local Handle Service will correctly return the data that was assigned to the handle by its administrator. A Local Handle Service typically supports a set of naming authorities. Thus, trusting a Local Handle Service would imply trusting those naming authorities.
ハンドルシステムのセキュリティは、トランザクションのすべてのステップでクライアントとサーバーホストのセキュリティの両方に依存します。クライアントのホストが改ざんされていないと想定しており、クライアントソフトウェアが受信したデータをクライアントに確実に伝えることを想定しています。また、ハンドルサービスのクライアントは、関係するハンドルサーバーが損なわれていないと仮定する必要があります。グローバルハンドルレジストリを信頼することは、グローバルハンドルレジストリがクライアントリクエストを責任あるローカルハンドルサービスに正しく指示すると信じることです。ローカルハンドルサービスを信頼することは、ローカルハンドルサービスが管理者によってハンドルに割り当てられたデータを正しく返すと信じることです。ローカルハンドルサービスは通常、一連の命名当局をサポートします。したがって、地元のハンドルサービスを信頼することは、それらの命名当局を信頼することを意味します。
The integrity of the Handle System depends heavily on the integrity of the global service information. Invalid global service information may mislead clients into inappropriate Local Handle Services. It may also allow attackers to forge server signatures. The Global Handle Registry must take extreme caution in protecting the global service information and the public key pair used to sign the global service information. Client applications should only accept the global service information from the Global Handle Registry. They should check its integrity upon each update.
ハンドルシステムの整合性は、グローバルサービス情報の整合性に大きく依存します。無効なグローバルサービス情報は、クライアントを不適切なローカルハンドルサービスに誤解させる可能性があります。また、攻撃者がサーバーの署名を偽造できるようにする場合があります。グローバルハンドルレジストリは、グローバルサービス情報とグローバルサービス情報の署名に使用される公開キーペアを保護する際に非常に注意する必要があります。クライアントアプリケーションは、グローバルハンドルレジストリからのグローバルサービス情報のみを受け入れる必要があります。各更新時にその完全性を確認する必要があります。
For efficiency reasons, handle servers will not generate or return a digital signature for every service response, unless specifically requested by clients. To assure data integrity, clients must explicitly ask the server to return the digital signature. To protect sensitive data from exposure, clients may establish a communication session with the server and ask the server to encrypt any data using the session key.
効率的な理由で、ハンドルサーバーは、クライアントから特別に要求されない限り、すべてのサービス応答に対してデジタル署名を生成または返すことはありません。データの整合性を保証するために、クライアントはサーバーにデジタル署名を返すようにサーバーに明示的に依頼する必要があります。機密データを露出から保護するために、クライアントはサーバーとの通信セッションを確立し、セッションキーを使用してデータを暗号化するようサーバーに要求する場合があります。
By default, most handle data stored in the Handle System is publicly accessible, unless otherwise specified by the handle administrator. Handle administrators must pay attention when adding handle values that contain private information. They may choose to mark these handle values readable only by the handle administrator(s), or to store these as encrypted handle values, so that these values can only be read within a controlled audience.
デフォルトでは、ハンドル管理者が特に指定しない限り、ハンドルシステムに保存されているほとんどのハンドルデータは公開されます。ハンドル管理者は、個人情報を含むハンドル値を追加するときに注意を払う必要があります。これらのハンドル管理者のみが読み取ることができるこれらのハンドル値をマークするか、これらを暗号化されたハンドル値として保存することを選択して、これらの値は制御されたオーディエンス内でのみ読み取ることができます。
Log files generated by the handle server are another vulnerable point where client privacy may be under attack. Operators of handle servers must protect such information carefully.
ハンドルサーバーによって生成されたログファイルは、クライアントのプライバシーが攻撃を受けている可能性のあるもう1つの脆弱なポイントです。ハンドルサーバーのオペレーターは、そのような情報を慎重に保護する必要があります。
Besides performance gains and other value-added services, both proxy and caching servers present themselves as men-in-the-middle, and as such are vulnerable to man-in-the-middle attacks. It is important to know that proxy and caching servers are not part of any handle service. They are clients of the Handle System. Service responses from proxy and caching servers cannot be authenticated via the Handle System protocol. The trust between the client and its immediate proxy/caching server has to be setup independently, regardless of the number of proxy/caching servers that are in the middle of the communication path.
パフォーマンスの向上とその他の付加価値サービスに加えて、プロキシとキャッシュサーバーの両方が中間の男性として自分自身を示しているため、中間の攻撃に対して脆弱です。プロキシとキャッシュサーバーがハンドルサービスの一部ではないことを知ることが重要です。彼らはハンドルシステムのクライアントです。プロキシおよびキャッシュサーバーからのサービス応答は、ハンドルシステムプロトコルを介して認証することはできません。クライアントとその即時のプロキシ/キャッシュサーバーの間の信頼は、通信パスの中央にあるプロキシ/キャッシュサーバーの数に関係なく、独立してセットアップする必要があります。
By using proxy and caching servers, clients assume that the servers will submit their requests and relay any responses from the Handle System without mishandling any of the contents. They also assume that the servers will protect any sensitive information on their behalf.
プロキシとキャッシュサーバーを使用することにより、クライアントは、サーバーがリクエストを送信し、コンテンツを誤って扱うことなくハンドルシステムから応答を中継すると想定します。また、サーバーが彼らに代わって機密情報を保護すると想定しています。
Proxy and caching server operators should protect the systems on which such servers are running as they would protect any system that contains or transports sensitive information. In particular, log information gathered at proxies often contain highly sensitive personal information, and/or information about organizations. Such information should be carefully guarded, and appropriate guidelines for their use developed and followed.
プロキシおよびキャッシュサーバーオペレーターは、機密情報を含むまたは輸送するシステムを保護するため、そのようなサーバーが実行されているシステムを保護する必要があります。特に、プロキシで収集されたログ情報には、非常に機密性の高い個人情報や組織に関する情報が含まれています。そのような情報は慎重に守られ、使用された適切なガイドラインが開発され、従う必要があります。
Caching servers provide additional potential vulnerabilities because the contents of the cache represent an attractive target for malicious exploitation. Potential attacks on the cache can reveal private data for a handle user, or information still kept after a user believes that they have been removed from the network. Therefore, cache contents should be protected as sensitive information.
キャッシュサーバーは、キャッシュの内容が悪意のある搾取の魅力的なターゲットを表しているため、追加の潜在的な脆弱性を提供します。キャッシュに対する潜在的な攻撃は、ハンドルユーザーのプライベートデータを明らかにすることができます。または、ユーザーがネットワークから削除されたと考えた後も保持されています。したがって、キャッシュの内容は機密情報として保護する必要があります。
Handle System clients should be aware of possible delays in content replication among mirroring sites. They should consider sending their request to the primary service site for any time-sensitive data. Selection of mirroring sites by service administrators must be done carefully. Each mirroring site must follow the same security procedures in order to ensure data integrity. Software tools may be applied to ensure data consistency among mirroring sites.
ハンドルシステムクライアントは、ミラーリングサイト間のコンテンツレプリケーションの遅延の可能性を認識する必要があります。彼らは、時間に敏感なデータのために、プライマリサービスサイトにリクエストを送信することを検討する必要があります。サービス管理者によるミラーリングサイトの選択は慎重に行う必要があります。各ミラーリングサイトは、データの整合性を確保するために、同じセキュリティ手順に従う必要があります。ソフトウェアツールを適用して、ミラーリングサイト間のデータの一貫性を確保することができます。
As with any public service, the Handle System is subject to denial of service attacks. No general solutions are available to protect against such attacks in today's technology. Server implementations may be developed to be aware of such attacks and notify administrators when they happen. Stateless cookies [19, 20] are one means of mitigating some of the effects of DoS attacks on hosts that perform authentication, integrity, and encryption services. Server implementations, moreover, need to be upgradeable to take advantage of new security technologies, including anti-DoS technologies as these become available.
他の公共サービスと同様に、ハンドルシステムはサービス攻撃の拒否の対象となります。今日のテクノロジーでのこのような攻撃から保護する一般的なソリューションはありません。サーバーの実装は、そのような攻撃を認識し、管理者が発生したときに通知するために開発される場合があります。ステートレスCookie [19、20]は、認証、整合性、暗号化サービスを実行するホストに対するDOS攻撃の効果の一部を緩和する1つの手段です。さらに、サーバーの実装は、これらが利用可能になるにつれてアンチドステクノロジーを含む新しいセキュリティテクノロジーを活用するためにアップグレード可能である必要があります。
The Handle System was originally conceived and developed at CNRI as part of an overall digital object architecture. The first public implementation was created at CNRI in the fall of 1994 in an effort led by David Ely. The overall digital object architecture, including the Handle System, was later described in a paper by Robert Kahn and Robert Wilensky [1] in 1995. Development continued at CNRI as part of the Computer Science Technical Reports (CSTR) project, funded by the Defense Advanced Projects Agency (DARPA) under Grant Number MDA-972-92-J-1029 and MDA-972-99-1-0018. One aspect of this early digital library project, which was also a major factor in the evolution of the Networked Computer Science Technical Reference Library (NCSTRL) [18] and related activities, was to develop a framework for the underlying infrastructure of digital libraries.
ハンドルシステムは、もともと全体的なデジタルオブジェクトアーキテクチャの一部としてCNRIで構想および開発されました。最初の公開実施は、1994年の秋にCNRIで作成され、David Elyが率いる努力をしました。ハンドルシステムを含む全体的なデジタルオブジェクトアーキテクチャは、1995年にRobert KahnとRobert Wilensky [1]による論文で後に説明されました。助成金番号MDA-972-92-J-1029およびMDA-972-99-1-0018に基づくAdvanced Projects Agency（DARPA）。この初期のデジタルライブラリプロジェクトの1つの側面は、ネットワーク化されたコンピューターサイエンステクニカルリファレンスライブラリ（NCSTRL）[18]の進化の主要な要因でもあり、デジタルライブラリの基礎となるインフラストラクチャのフレームワークを開発することでした。
Early adopters of the Handle System included the Library of Congress, the Defense Technical Information Center (DTIC), and the International DOI Foundation (IDF). Feedback from these organizations as well as NCSTRL, other digital library projects, and related IETF efforts as mentioned above, have all contributed to the evolution of the Handle System. The current status and available software, for both client and server, can be found at http://www.handle.net.
ハンドルシステムの早期採用者には、議会図書館、防衛技術情報センター（DTIC）、および国際DOI財団（IDF）が含まれます。これらの組織からのフィードバック、およびNCSTRL、その他のデジタルライブラリプロジェクト、および上記の関連するIETFの取り組みは、すべてハンドルシステムの進化に貢献しています。クライアントとサーバーの両方で現在のステータスと利用可能なソフトウェアは、http：//www.handle.netで見つけることができます。
This work is derived from the earlier versions of the Handle System implementation. Design ideas are based on those discussed within the Handle System development team, including David Ely, Charles Orth, Allison Yu, Sean Reilly, Jane Euler, Catherine Rey, Stephanie Nguyen, Jason Petrone, and Helen She. Their contributions to this work are gratefully acknowledged.
この作業は、ハンドルシステムの実装の以前のバージョンから派生しています。デザインのアイデアは、デビッドイーリー、チャールズオース、アリソンユー、ショーンライリー、ジェーンオイラー、キャサリンレイ、ステファニーヌグエン、ジェイソンペトローン、ヘレンSHなど、ハンドルシステム開発チーム内で議論されているものに基づいています。この作業への彼らの貢献は感謝されています。
The authors also thank Russ Housley (housley@vigilsec.com), Ted Hardie (hardie@qualcomm.com), and Mark Baugher (mbaugher@cisco.com) for their extensive review and comments, as well as recommendations received from other members of the IETF/IRTF community.
著者はまた、Russ Housley（housley@vigilsec.com）、Ted Hardie（hardie@qualcomm.com）、およびMark Baugher（mbaugher@cisco.com）、および大規模なレビューとコメント、および他のメンバーから受け取った推奨事項に感謝します。IETF/IRTFコミュニティ。
[1] Kahn, R. and R. Wilensky, "A Framework for Distributed Digital Object Services", D-Lib Magazine, 1995.
[1] Kahn、R。およびR. Wilensky、「分散デジタルオブジェクトサービスのフレームワーク」、D-Lib Magazine、1995。
[2] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[2] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[3] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[3] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[4] Berners-Lee、T.、Masinter、L。およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[5] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.
[5] Yergeau、F。、「UTF-8、UnicodeおよびISO 10646の変換形式」、RFC 2044、1996年10月。
[6] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models, and Services", 1993.
[6] itu-t rec。X.500、「ディレクトリ：概念、モデル、およびサービスの概要」、1993。
[7] D. W. Chadwick, "Understanding X.500 - The Directory", Chapman & Hall ISBN: 0-412-43020-7.
[7] D. W.チャドウィック、「X.500の理解」、チャップマン＆ホールISBN：0-412-43020-7。
[8] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[8] Wahl、M.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年12月。
[9] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994.
[9] Sollins、K。およびL. Masinter、「制服名の機能要件」、RFC 1737、1994年12月。
[10] Sollins, K. "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998.
[10] Sollins、K。「均一なリソース名の解決の建築原理」、RFC 2276、1998年1月。
[11] IETF Uniform Resource Names (URN) Working Group, April 1998.
[11] IETFユニフォームリソース名（URN）ワーキンググループ、1998年4月。
[12] D-Lib Magazine, http://www.dlib.org
[12] D-Lib Magazine、http：//www.dlib.org
[13] Sam X. Sun, "Internationalization of the Handle System - A Persistent Global Name Service", Proceeding of 12th International Unicode Conference, April 1998.
[13] Sam X. Sun、「ハンドルシステムの国際化 - 永続的なグローバル名サービス」、1998年4月、第12回国際ユニコード会議の進行。
[14] D. Goodman, C. Robbins, "Understanding LDAP & X.500", August 1997.
[14] D.グッドマン、C。ロビンズ、「LDAPの理解＆X.500」、1997年8月。
[15] Deutsch P., Schoultz R., Faltstrom P. and C. Weider, "Architecture of the WHOIS++ service", RFC 1835, August 1995.
[15] Deutsch P.、Schoultz R.、Faltstrom P.およびC. Weider、「Whoisサービスの建築」、RFC 1835、1995年8月。
[16] Weider, C., Fullton, J. and S. Spero, "Architecture of the Whois++ Index Service", RFC 1913, February 1996.
[16] Weider、C.、Fullton、J。およびS. Spero、「Whois Index Serviceのアーキテクチャ」、RFC 1913、1996年2月。
[17] The Unicode Consortium, "The Unicode Standard, Version v3.0", Addison-Wesley Pub Co; ISBN: 0201616335.
[17] Unicode Consortium、「Unicode Standard、バージョンv3.0」、Addison-Wesley Pub Co;ISBN：0201616335。
[18] The Networked Computer Science Technical Reports Library (NCSTRL), http://www.ncstrl.org/
[18] ネットワーク化されたコンピューターサイエンステクニカルレポートライブラリ（NCSTRL）、http：//www.ncstrl.org/
[19] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[19] Karn、P。and W. Simpson、「Phyuris：Session-Key Management Protocol」、RFC 2522、1999年3月。
[20] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[20] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[21] Sun, S., Reilly, S. and L. Lannom, "Handle System Namespace and Service Definition", RFC 3651, November 2003.
[21] Sun、S.、Reilly、S。、およびL. Lannom、「Handle System Namespace and Service Definition」、RFC 3651、2003年11月。
[22] Sun, S., Reilly, S., Lannom, L. and J. Petrone, "Handle System Protocol (ver 2.1) Specification", RFC 3652, November 2003.
[22] Sun、S.、Reilly、S.、Lannom、L。and J. Petrone、「Handle System Protocol（Ver 2.1）仕様」、RFC 3652、2003年11月。
[23] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[23] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。
Sam X. Sun Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
Sam X. Sun Corporation for National Research Initiatives（CNRI）1895 Preston White Dr.、Suite 100 Reston、VA 20191
Phone: 703-262-5316 EMail: ssun@cnri.reston.va.us
電話：703-262-5316メール：ssun@cnri.reston.va.us
Larry Lannom Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
Larry Lannom Corporation for National Research Initiatives（CNRI）1895 Preston White Dr.、Suite 100 Reston、VA 20191
Phone: 703-620-8990 EMail: llannom@cnri.reston.va.us
電話：703-620-8990メール：llannom@cnri.reston.va.us
Brian Boesch Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
ブライアン・ボーシュ・コーポレーション・フォー・ナショナル・リサーチ・イニシアチブ（CNRI）1895プレストン・ホワイト博士、スイート100レストン、バージニア州20191
Phone: 703-262-5316 EMail: bboesch@cnri.reston.va.us
電話：703-262-5316メール：bboesch@cnri.reston.va.us
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
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 assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
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エディター機能の資金は現在、インターネット協会によって提供されています。