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.
著作権（C）インターネット協会（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コンセンサスが得られていないことを指摘したいです。特にURNとして、URIの形式として、ハンドルの議論がなされているが、これらの文書は、名前空間と識別子は、インターネット上で動作し、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.
ハンドルシステムは、既存のローカル名前空間は独特のハンドルシステムの命名権を取得することにより、グローバルなハンドルネームスペースに参加することができますconfederatedネームサービスを提供します。ローカル名とその値結合（複数可）ハンドルシステムに参加した後にそのまま残ります。ローカル名前空間へのすべてのハンドル要求は、ハンドルシステムのプロトコルを話すサービス・インターフェースによって処理することができます。ユニークな命名機関と組み合わせることで、任意のローカル名は、グローバルハンドルネームスペースの下に独自の保証されています。
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は、[3]「名前がIPアドレスにマッピング可能であり、異なるホスト、ネットワーク、プロトコル・ファミリー、インターネットの、そして行政機関で使用できるようにリソースを命名するためのメカニズムを提供する」ように設計されています。インターネットの成長は、DNSへの様々な拡張のための需要が高まっています。また、汎用リソースネーミングシステムとしてDNSを使用しようとしています。しかし、基本的なネットワークルーティングにおけるDNSの重要性は、任意のDNSの拡張機能を実装するか、汎用リソースの命名のためのDNSへの過負荷に細心の注意をもたらしています。汎用ネームサービスとしてDNSを使用しないことを主張している追加の要因は、DNS管理モデルです。 DNS名は、通常のDNSゾーンレベルのネットワーク管理者（複数可）によって管理されています。ごとの名前行政構造のための準備と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.
- 永続性：ハンドルは、インターネットリソースの永続的な識別子として使用することができます。ハンドルは、名前のITエンティティから派生する必要はありません。既存の名前、あるいはニーモニックは、利便性のためのハンドルに含めてもよいが、ハンドルとエンティティそれ名の間のみ動作可能な接続は、ハンドルシステム内に維持されます。もちろん、これは行政のケアの関数である持続性を保証するものではありません。しかし、それは同じ名前の場所の変更、所有権、および他の状態の条件の上に持続することができません。名前のリソースがある場所から別の場所に移動した場合たとえば、ハンドルは、新しい場所を反映するように、ハンドルシステムでその値を更新することにより、有効に維持することができます。
- 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]、URLの[4]、X.500 / LDAP [6,7,8]、およびURN [9,10を比較します]）。ハンドル・システム・データおよびサービス・モデル、ならびにその通信プロトコルの詳細は、別の文書で指定されています。彼らはhttp://www.handle.netのハンドルシステムのウェブサイトで見つけることができます。
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 / january99-bearman" はD-Libの雑誌に掲載された記事[12]のためのハンドルです。その命名権威は「10.1045」であり、そのローカル名は「january99-bearman」です。ハンドルネームスペースは、各ローカル名前空間はハンドルシステムの下で独自の命名権限を有するとともに、多くのローカル名前空間のスーパーセットと考えることができます。命名機関は、関連するハンドルの、必ずしも管理を継続していないが、創造の行政単位を識別します。各命名権限はハンドルシステム内でグローバルに一意であることが保証されます。上記のように、名前空間の下で任意のローカル名をグローバルに命名機関の組み合わせとローカル名として参照できるように、既存のローカル名前空間には、独自の命名権を取得することにより、グローバルなハンドルネームスペースに参加することができます。
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].
ハンドルは、Unicode V3.0 [17]によって定義された正確な文字セットであるISO / IEC 10646のユニバーサル文字セット（UCS-2）から任意の印刷可能な文字から構成されてもよいです。 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つまたは複数のサービスサイトから構成されてもよいです。各サービスサイトは、ハンドル解像度の点では、サービス内の他のすべてのサイトの完全な複製です。各サービスサイトは、一台の以上のハンドルサーバで構成することができます。したがって、すべてのハンドル、および特定のサービスサイトに向け、すべてのハンドル要求は、均等にこれらのハンドルサーバーに分散されます。全体としてハンドルシステムは、ハンドルサービスの任意の数から構成されてもよいです。ハンドルサービスの数に各サービスを構成する、また各サイトを構成するサーバーの数のいずれかの制限があるサイトの数には、設計制限はありません。任意のサービスサイト間レプリケーションは、各サイトは、サーバの同じ番号が含まれている必要はありません。換言すれば、各サイトは、ハンドルの同じ複製セットを有することになるが、各サイトは、サーバの異なる数を横切ってハンドルのセットを割り当てることができます。この分散アプローチは、スケーラビリティを支援する操作のいずれか大規模に対応し、単一点障害の問題を緩和することを意図しています。
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つのサービスサイトで構成可能ハンドルサービスを示しています。東海岸のサービスサイトには、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.
各ハンドルサービスは、ハンドルシステムの下で個別のサブ名前空間を管理します。異なるハンドルサービスの下の名前空間が重複しない場合があります。サブ名前空間は、通常の命名当局の番号の下にハンドルから構成されています。ハンドルサービスは、これらの命名当局の「ホーム」サービスと呼ばれ、これらの命名当局の下でのハンドルのための解像度や行政サービスを提供する唯一のものです。ハンドルを解決する前に、クライアントは、問題のハンドルの「ホーム」サービスを決定しなければなりません。各ハンドルの「ホーム」サービスは、その命名機関の「ホーム」サービスで、グローバルハンドルレジストリに登録されています。クライアントは、グローバルハンドルレジストリで命名機関ハンドルを照会することによって、各ハンドルの「ホーム」サービスを見つけることができます。
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 / july95-腕」を解決しようとすると、グローバルハンドルレジストリからその「ホーム」のサービスを見つけることがあります。 「ホーム」サービスは、「10.1045」の命名権ハンドルのグローバルハンドルレジストリにクエリーを送信することにより、見つけることができます。グローバルハンドルレジストリは「10.1045」命名権限の下でハンドルを担当してローカルハンドルサービスのサービス情報を返します。サービス情報は、クライアントが「10.1045 / july95-腕を」ハンドルを解決するためのローカルハンドルサービスと通信することができます。
------------------------
| | 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を信頼することができ信頼値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アドレスのどちらかを返すホワイトページサービスを提供するために」設計されており、「開放型システム間相互接続（OSI）アプリケーション用のネームサーバのサービスを提供して主に懸念」です7]。 X.500は、グローバル名前検索と検索を可能にするためのプロトコルのセットで階層データおよび情報モデルを定義します。プロトコルは、しかし、実装が困難であることが分かっていると、「既存の製品に統合されたクライアントアクセス」を得ることの難しさがあった[14]。 LDAP（Lightweight Directory Access Protocol）にある[8]を実装するプロトコルは、簡単かつ容易に行うことによって、これらの困難の多くを克服しました。いくつかの懸念は、LDAPは、分散型サービスプロトコル（LDAP v3の）にローカルディレクトリアクセスプロトコル（LDAP v2の）から浮上しているとして、それが新たな合併症が生じ、元の設計で扱われていない多くの問題に直面していること、しかし、残っています。
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アプリケーションでインターネットリソースを識別するための均一な、まだ拡張可能ネーミングメカニズムを定義します。ユニフォーム・リソース・ネーム（URN）[11]、URIのサブセットは、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 / july95-腕を」ハンドルを解決することができます。いいえ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サービスを識別するために登録：たとえば、アプリケーションFOOは、URI名前空間「foo」を持っていることがあります。永続的な名前を必要とする任意のBARオブジェクトを識別するために登録：平均時間では、アプリケーションのBARは、URN名前空間「BAR URN」を有していてもよいです。どちらもFOOとBARのアプリケーションは、ネーミングおよびサービスおよび/またはオブジェクトに解決するには（それぞれの命名権限の下で）ハンドルを使用することができます。これは、（例えば、「テルネット」、「FTP」、「MAILTO」など）は、異なるアプリケーションのために定義されたが、すべてはDNSサービスを使用して、異なる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またはURN名前空間に収まるかどうかについてさまざまな意見があります。ハンドルシステムは、インターネット上の他の既存のネームサービスに関連し合う場所に懸念もあります。このような議論は、この文書の範囲外です。
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.
それ以外の場合はハンドル管理者が指定しない限り、デフォルトでは、ハンドルシステムに保存されているほとんどのハンドルデータは、公的にアクセス可能です。個人情報が含まれているハンドル値を追加する際にハンドルの管理者は注意を払う必要があります。彼らは、これらの値は唯一の制御聴衆の中に読み取ることができるように、ハンドルのみの管理者（S）で読み込み可能なこれらのハンドル値をマークする、または暗号化されたハンドル値としてこれらを保存することもできます。
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.
ハンドルサーバによって生成されるログファイルは、クライアントのプライバシーが攻撃下にあってもよい別の脆弱点です。ハンドルサーバのオペレータは、慎重にそのような情報を保護しなければなりません。
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
パフォーマンスの向上およびその他の付加価値サービスのほかに、両方のプロキシおよびキャッシュサーバは、男性・イン・ザ・ミドルとしての自分自身を提示し、そのようにman-in-the-middle攻撃に対して脆弱です。プロキシとキャッシュサーバは任意のハンドルサービスの一部ではないことを知っておくことが重要です。彼らは、ハンドルシステムのクライアントです。プロキシとキャッシュサーバからサービス応答はハンドルを介して認証することはできません
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.
すべての公共サービスと同様に、ハンドルシステムは、サービス拒否攻撃の対象となります。いいえ、一般的なソリューションは、今日の技術では、このような攻撃から保護するために用意されていません。サーバ実装は、このような攻撃を認識すると、彼らが発生したときに管理者に通知するために開発されてもよいです。ステートレスクッキー[19、20]は、認証、整合性、および暗号化サービスを実行するホスト上のDoS攻撃の影響の一部を緩和する一つの手段です。サーバ実装は、さらに、これらが利用可能になるとアンチのDoS技術を含む新しいセキュリティ技術、を利用するためにアップグレードする必要があります。
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で作成されました。ハンドルシステムを含む総合的なデジタル・オブジェクト・アーキテクチャは、後にロバート・カーン、ロバート・Wilenskyの論文に記載された[1] 1995年に開発が防衛によって資金を供給、コンピュータサイエンステクニカルレポート（CSTR）プロジェクトの一環として、CNRIで継続高度な計画庁（DARPA）認可番号MDA-972から92-J-1029およびMDA-972-99-1-0018下。また、ネットワークコンピュータサイエンステクニカルリファレンスライブラリ（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.
この作品は、ハンドルシステムの実装の以前のバージョンから導出されます。デザインのアイデアは、デビッド・イーリー、チャールズ・オース、アリソンゆう、ショーン・ライリー、ジェーン・オイラー、キャサリン・レイ、ステファニー・グエン、ジェイソンPetrone、とヘレン彼女を含めハンドルシステム開発チーム内で検討したものに基づいています。この作品への貢献は深く感謝しています。
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.
著者はまた、彼らの豊富なレビューとコメントをラスHousley（housley@vigilsec.com）、テッドハーディー（hardie@qualcomm.com）、およびマーク・Baugher（mbaugher@cisco.comを）感謝、などの他のメンバーから受信した勧告IETF / IRTFのコミュニティ。
[1] Kahn, R. and R. Wilensky, "A Framework for Distributed Digital Object Services", D-Lib Magazine, 1995.
[1]カーン、R.とR. Wilensky、D-Libのマガジン、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]バーナーズ=リー、T.、Masinter、LとM. McCahill、 "ユニフォームリソースロケータ（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勧告。 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]ワール、M.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル（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のマガジン、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]サムX.日、「ハンドルシステムの国際化 - 永続的なグローバルネームサービス」、第12回国際ユニコード会議、1998年4月の議事録。
[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]ドイツ語P.、R. Schoultz、折りたたみパワーP.とさらにC.、 "WHOIS ++サービスのアーキテクチャ"、RFC 1835、1995年8月。
[16] Weider, C., Fullton, J. and S. Spero, "Architecture of the Whois++ Index Service", RFC 1913, February 1996.
[16]ウイダー、C.、Fullton、J.とS.スペロ、 "Whoisの建築++インデックスサービス"、RFC 1913、1996年2月。
[17] The Unicode Consortium, "The Unicode Standard, Version v3.0", Addison-Wesley Pub Co; ISBN: 0201616335.
[17]ユニコードコンソーシアム、 "Unicode規格、バージョンV3.0"、アディソン・ウェズリーパブの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]カーン、P.とW.シンプソン、 "Photuris：セッション鍵管理プロトコル"、RFC 2522、1999年3月。
[20] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[20]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[21] Sun, S., Reilly, S. and L. Lannom, "Handle System Namespace and Service Definition", RFC 3651, November 2003.
[21]日、S.、ライリー、S.とL. Lannom、 "System名前空間とサービス定義のハンドル"、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]サン、S.、ライリー、S.、Lannom、L.及びJ. Petrone、 "ハンドル・システム・プロトコル（版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]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
Sam X. Sun Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
国立研究イニシアチブのためのサムX.日株式会社（CNRI）1895プレストン・ホワイト博士は、スイート100レストン、バージニア州20191
Phone: 703-262-5316 EMail: ssun@cnri.reston.va.us
電話：703-262-5316 Eメール：ssun@cnri.reston.va.us
Larry Lannom Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
国立研究イニシアチブのためのラリーLannomコーポレーション（CNRI）1895プレストン・ホワイト博士は、スイート100レストン、バージニア州20191
Phone: 703-620-8990 EMail: llannom@cnri.reston.va.us
電話：703-620-8990 Eメール：llannom@cnri.reston.va.us
Brian Boesch Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
国家研究イニシアティブブライアンBoeschコーポレーション（CNRI）1895プレストン・ホワイト博士は、スイート100レストン、バージニア州20191
Phone: 703-262-5316 EMail: bboesch@cnri.reston.va.us
電話：703-262-5316 Eメール：bboesch@cnri.reston.va.us
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。