RFC3650 日本語訳
3650 Handle System Overview. S. Sun, L. Lannom, B. Boesch. November 2003. (Format: TXT=54927 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Sun
Request for Comments: 3650 L. Lannom
Category: Informational B. Boesch
CNRI
November 2003
コメントを求めるワーキンググループS.Sun要求をネットワークでつないでください: 3650年のL.Lannomカテゴリ: 情報のB.Boesch CNRI2003年11月
Handle System Overview
システム概要を扱ってください。
Status of this Memo
この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)インターネット協会(2003)。 All rights reserved。
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の中のいくつかのグループが識別子の既存のシステムとのHandle Systemとその関係について議論しました。 IESGは、これらの議論が説明されたHandle Systemと、それがどう識別子のための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や、URNsなどの他のインターネットのサービスにHandle Systemの概要を提供します。 Handle Systemはインターネットなどのネットワークの上に機密保護している名前解決と管理を許容する汎用グローバル名サービスです。 Handle Systemはハンドル、どれがデジタルオブジェクトのためのユニークな名前であるか、そして、および他のインターネット資料を管理します。
Sun, et al. Informational [Page 1] RFC 3650 Handle System Overview November 2003
Sun、他 情報[1ページ]のRFC3650はシステム概要2003年11月を扱います。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 動機。 . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. 名前空間. . . . . . . . . . . . . . . . . . . . . . . 7 4を扱ってください。 システム構築. . . . . . . . . . . . . . . . . . 8 5を扱ってください。 システムセキュリティ. . . . . . . . . . . . . . . . . . . . 11 6を扱ってください。 Handle Systemと他のインターネットのサービス。 . . . . . . . . 12 6.1. ドメイン名サービス(DNS)。 . . . . . . . . . . . . . . . 13 6.2. ディレクトリサービス(X.500/LDAP)。 . . . . . . . . . . . . 13 6.3. Uniform Resource Identifierの(URI)/ユニフォームリソース名(つぼ)。 . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 15 7.1. 総合証券は練習されます。 . . . . . . . . . . . . . . . 15 7.2. プライバシー保護. . . . . . . . . . . . . . . . . . . 16 7.3。 キャッシュとProxyサーバ。 . . . . . . . . . . . . . . . 16 7.4. 映します。 . . . . . . . . . . . . . . . . . . . . . . . 17 7.5. サービス妨害(DoS)。 . . . . . . . . . . . . . . . . 17 8. ハンドルシステム. . . . . . . . . . . . . . . . . 18 9の歴史。 承認. . . . . . . . . . . . . . . . . . . . . . . 18 10。 参照と図書目録。 . . . . . . . . . . . . . . . . . 19 11. 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 20 12。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 21
1. Introduction
1. 序論
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.
このドキュメントはHandle System(インターネットなどのネットワークにおける使用のための効率的で、広げることができて、機密保護しているグローバル名サービスを提供するように設計された分配された情報システム)の概要を提供します。 Handle Systemはプロトコルのオープン・プロトコル、名前空間、および参照実装を含んでいます。 プロトコルは、分散コンピュータシステムが場所を見つけて、アクセスして、そうでなければ、リソースに利用するためにデジタルリソースの名前、またはハンドルを保存して、それらのハンドルに必要情報に変えるのを可能にします。 ハンドルを変えないで特定されたリソースの現状を反映するために必要に応じてこれらの関連値を変えることができます。 これで、項目の名前は位置と他の現状情報の変化の上で持続します。 各ハンドルには、それ自身の管理者がいるかもしれません、そして、分散環境で管理ができます。 サポートが固定したHandle Systemは解決を扱います。 クライアント要求のときにデータの機密性や、データ保全や、非拒否などのセキュリティー・サービスを提供します。
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
Handle Systemはどんな既存の地方の名前空間も権威を命名するユニークなHandle Systemを入手することによってグローバルなハンドル名前空間を接合できる盟約された名前サービスを提供します。 Handle Systemを接合した後に、地方名と彼らの値結合は元の状態のままになります。 地方の名前空間へのどんなハンドル要求も処理されるかもしれません。
Sun, et al. Informational [Page 2] RFC 3650 Handle System Overview November 2003
Sun、他 情報[2ページ]のRFC3650はシステム概要2003年11月を扱います。
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.
サービスで、Handle Systemが議定書の中で述べる話しを連結してください。 ユニークな命名権威に結合されていて、どんな地方名もグローバルなハンドル名前空間の下でユニークな状態で保証されます。
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アドレスにmappableで、ネットワークの異なったホストで使用可能であるような方法、プロトコルファミリー、インターネット、および管理編成でリソースを命名するのにメカニズムを提供する」[3]です。 インターネットの成長は様々な拡大の要求をDNSに上げました。 汎用リソース命名システムとしてDNSを使用する試みもあります。 しかしながら、基本的なネットワークルーティングにおける、DNSの重要性は汎用リソース命名のためにどんなDNSも拡大であると実装するか、またはDNSを積みすぎる際に十分な注意につながりました。 一般的な目的名前付けサービスとしてDNSを使用しないように論争する追加要素はDNS管理モデルです。 DNS名はDNSゾーンレベルにおけるネットワーク管理者によって通常管理されます。 ネットワーク管理者以外の人々のためのどんな施設もDNS名を1名前あたりの運営機構が管理しますが、作成しないか、または管理しないように、支給は全くありません。 これは、ドメイン名管理に適切ですが、汎用リソース命名の割にはそうではありません。
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.
Handle Systemは汎用名前付けサービスとして始めからサーブまで設計されています。 それは、非常に多くの実体を収容して、公共のインターネットの上に分散型管理を許容するように設計されています。 Handle Systemデータモデルは与えられたハンドルに関連づけられたそれぞれのデータ値のレベルでアクセスコントロールを定義させます。 各ハンドルはさらにそれ自身のネットワークから独立している管理者かホスト管理者のセットを定義できます。
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
伝統的なURL(Uniform Resource Locator) [4] あるインターネット資料はDNS名と地方名の組み合わせとして命名させられてください。 地方名は、ローカルファイル経路、または何らかのローカル・サービスの参照であるかもしれません(例えば、cgi-binスクリプト)。 DNS名と地方名のこの組み合わせは個々のインターネット資料を命名して、管理するのにフレキシブルな管理モデルを提供します。 しかしながら、URL習慣には、また、いくつかの主要な制限があります。 ほとんどのURL体系(例えば、http)が解決だけのために定義されます。 ローカル・ホストにおいて、または、NFSなどのある他のネットワーク・サービスでどんなURL管理もしなければなりません。 名前としてURLを使用すると、インターネット資料は現在のネットワークの位置に通常つながれます。 ファイル経路がURLの一部であるときに、例えば、URLはローカルファイル経路に結ばれるでしょう。 リソースがいかなる理由でも1つの位置からもう1つの位置まで移行すると、URLは壊れます。 問題に取りかかるのは特に難しいです。
Sun, et al. Informational [Page 3] RFC 3650 Handle System Overview November 2003
Sun、他 情報[3ページ]のRFC3650はシステム概要2003年11月を扱います。
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.
位置の変化の理由であるときに、この問題は資産の所有権の移転です、所有権が一般にドメイン名に反映されるとき。
The Handle System is designed to overcome these limitations and to add significant functionality. Specifically, the Handle System is designed with the following objectives:
Handle Systemは、これらの限界を克服して、重要な機能性を加えるように設計されています。 明確に、Handle Systemは以下の目的で設計されています:
- Uniqueness: Every handle is globally unique within the Handle
System.
- ユニークさ: あらゆるハンドルが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.
- 固執: ハンドルはインターネット資料に永続的な識別子として使用されるかもしれません。 それが命名する実体からハンドルを得る必要はありません。 既存の名前、またはニーモニックさえ便宜のためのハンドルに含まれるかもしれませんが、ハンドルとそれが命名する実体との唯一の運用接続がHandle Systemの中で維持されます。 これはもちろん固執を保証しません。(それは、管理注意の機能です)。 しかし、それで、同じ名前は位置、所有権、および他の州の状態の変化の上で持続します。 命名されたリソースが1つの位置からもう1つの位置まで移行するとき、例えば、ハンドルは、新しい位置を反映するためにHandle Systemで値をアップデートすることによって、有効に保たれるかもしれません。
- 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.
- 広げることができる名前空間: 既存の地方の名前空間は、権威を命名するユニークなハンドルを入手することによって、ハンドル名前空間を接合するかもしれません。 これは、既存の名前空間との闘争を避けている間、地方の名前空間が世界状況に取り入れられるのを許容します。 また、命名当局の使用はサービスの委譲、解決と管理の両方を地方のハンドルサービスに許容します。
Sun, et al. Informational [Page 4] RFC 3650 Handle System Overview November 2003
Sun、他 情報[4ページ]のRFC3650はシステム概要2003年11月を扱います。
- 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.
- 国際支援: ハンドル名前空間はキャラクタの大部分が現在世界中で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.)
- 分配されたサービスモデル: Handle Systemは、対応する地方のハンドルサービス、グローバルなサービス、または両方でどんな地方のハンドル名前空間も修理できるように階層的なサービスモデルを定義します。 原因となる地方のハンドルサービスにどんなハンドルサービスのリクエストも派遣するのにGlobal Handle Registryとして知られているグローバルなサービスは利用できます。 複数のサービスサイトに対するサービスを考えて、分配されたサービスモデルはいずれの模写を許容します、そして、それぞれのサービスサイトはさらに個々のサーバのクラスタにサービスを広げるかもしれません。 (ここでのそんなにローカルの注意は名前空間と管理関心だけについて言及します。 地方のハンドルサービスで、事実上、インターネットの向こう側に多くのサービスサイトを配布するかもしれません。)
- 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.
- 機密保護している名前サービス: Handle Systemは公共のインターネットの上に機密保護している名前解決と管理を許容します。 Handle Systemプロトコルはクライアントとサーバ証明とサービス承認の両方のために標準のメカニズムを定義します。 また、それは、データ保全と秘密性を保証するためにセキュリティオプションを提供します。
- 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.
- 分散型管理サービス: 各ハンドルはそれ自身の管理者か管理者グループを定義するかもしれません。 それぞれのハンドルの所有権は管理者か管理者グループで定義されます。 Handle System認証プロトコルに結合したこれは、どんなハンドルも公衆通信回線の上でどんなネットワークの位置の管理者によってもしっかりと管理されるのを許容します。
- 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.
- 効率的な解決サービス: ハンドルプロトコルは、高能率的な名前解決性能を許容するように設計されています。 計算上高価な管理サービスで影響を受ける解決を避けるために、ハンドルネーム解決と管理のための別々のサービスインタフェース(すなわち、サーバプロセスとそれらの関連COMポート)はどんなハンドルサービスでも定義されるかもしれません。
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
このドキュメントはハンドル名前空間とサービスアーキテクチャの概要を提供します。 また、それは他の既存のインターネットのサービス、プロトコル、および仕様(例えば、DNS[2、3]、URL[4]、X.500/LDAP[6、7、8]、およびURN[9、10])とHandle Systemを比べます。 ハンドルシステムデータとサービスモデルの細部、およびその通信プロトコルは別々のドキュメントで指定されます。 それら
Sun, et al. Informational [Page 5] RFC 3650 Handle System Overview November 2003
Sun、他 情報[5ページ]のRFC3650はシステム概要2003年11月を扱います。
can be found under the Handle System website at http://www.handle.net.
http://www.handle.net のHandle Systemウェブサイトの下で見つけることができます。
2. Motivations
2. 動機
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.
あるので、多くの名前がインターネットコミュニティでプロジェクトを関係づけて、私たちが、ちょうどどこでHandle Systemが合うと信じているかを定義する価値があります。 残念ながら、他のプライマリ命名体系が抽象的なサービスアプローチ(例えば、URI/URN)、または基本的なデータベースの信頼できますが、分配された管理において、自己充足的なフレームワークで欠けている名前解決へのアプローチ(例えば、DNS)を取るので、それは特に困難です。 これで、Handle Systemを分類するのは難しくなります。
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.
Handle 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.
しっかりと分散データベースを作成して、アップデートして、維持して、アクセスするために特定のプロトコルによる名前属性の拘束力があるサービスであるとHandle Systemをみなすのはたぶん最も良いです。 それは、機密保護している情報のための可能なサービスと公共のインターネットなどのネットワークの上のリソース・シェアリングになるように設計されています。 Handle Systemのアプリケーションはデジタル刊行物のためのメタデータサービス、仮想のアイデンティティのためのアイデンティティ経営指導、またはグローバルにユニークな識別子を解決、そして/または、管理に要求するいかなる他のアプリケーションも含むかもしれません。
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.
探検の精神では、Handle Systemは、名前解決のための高性能を持って、分配されたアクセスコントロールと管理の境界を押すように設計されています。 比較的少ない数の広く権限を与えられた管理者がいるように設計されているほとんどの従来のシステム(分散システムさえ)と異なって、Handle Systemは運営管理コントロールの非常にすばらしい粒状を許容します。 それは、システム管理者からそれぞれのハンドルの所有権の衝撃を吸収するユニークな自己充足的な管理フレームワークを持って、アクセスコントロールがそれぞれのハンドル値のために定義されるのを許容します。
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.
それは有名であるべきであり、Handle Systemはすべての実システムのように多くの技術的で実用的な関心の間の感染です。 また、IETFの中にHandle Systemが他の既存のインターネット名前サービスと関連して合うところに関する異なった意見があります。 概念、アプローチ、特定の決定、見返り、および結果により広い共同体を暴露するという目標のために、私たちはこのRFCに書いています。
Sun, et al. Informational [Page 6] RFC 3650 Handle System Overview November 2003
Sun、他 情報[6ページ]のRFC3650はシステム概要2003年11月を扱います。
3. Handle Namespace
3. 名前空間を扱ってください。
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文字によって切り離され」/、」 命名権威の下における地方名の収集はそれのための権威を命名する地方のハンドル名前空間を定義します。 どんな地方名も地方の名前空間の下でユニークであるに違いありません。 命名権威とその権威の下における地方名のユニークさはどんなハンドルも確実にHandle Systemの文脈の中でグローバルにユニークになるようにします。
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-リブ雑誌[12]で発表された記事のためのハンドルです。 命名権威が「10.1045インチとその地方名は"january99-bearman"です」です。 多くの地方の名前空間のスーパーセットであるとハンドル名前空間を考えることができます、Handle Systemの下にユニークな命名権威を持っているそれぞれの地方の名前空間で。 必ず関連ハンドルの管理を続けているというわけではありませんが、命名権威は作成の行政単位を特定します。 それぞれの命名権威は、Handle Systemの中でグローバルに特有になるように保証されます。 どんな既存の地方の名前空間も、上に示されるように命名権威と地方名の組み合わせとして名前空間の下におけるどんな地方名にもグローバルに参照をつけることができるようにユニークな命名権威を得ることによって、グローバルなハンドル名前空間を接合できます。
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".
Handle Systemの下の命名当局は木構造に類似している階級的なファッションで定義されます。 命名権威セグメントに対応するラベルを木の各ノードと葉に与えます。 親ノードは子供の権威をノードと命名する親に通知します。 DNSと異なって、ハンドル命名当局は左で右に組み立てられます、木の根から命名権威を表すノードまでラベルを連結して。 「各ラベルはASCII文字に使用される八重奏で分離される」、」 (0x2E。) 例えば、議会図書館("loc")のNational Digital図書館Program("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
それぞれの命名権威で、下部に多くの子供命名当局を登録するかもしれません。 登録された後に親は権威を命名するどんな子供も登録できるだけです。 しかしながら、当局を任命する親子によって表された名前空間の間のどんな本質的な管理関係もありません。 親名前空間とその子供
Sun, et al. Informational [Page 7] RFC 3650 Handle System Overview November 2003
Sun、他 情報[7ページ]のRFC3650はシステム概要2003年11月を扱います。
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].
ハンドルはユニコードv3.0[17]によって定義された正確な文字集合であるISO/IEC10646のUniversal文字コード(UCS-2)からのどんな印刷可能なキャラクタからも成るかもしれません。 UCS-2文字集合は今日書かれているあらゆる主要な言語で使用されるほとんどのキャラクタを取り囲みます。 既存のシステムの大部分との互換性を許容して、異なったencodingsの中であいまいさを防ぐために、Handle Systemプロトコルは、UTF-8がハンドルに使用される唯一のコード化であることを強制します。 どんなジャムASCIIもコード化するUTF-8は、命名闘争を引き起こさないで既存のシステムとの最大の互換性を許容するために名前をコード化しました。 [13]でグローバルな名前空間の上のいくつかのコード化問題とUTF-8コード化の選択について議論します。
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文字は大文字と小文字を区別しないです。
4. Handle System Architecture
4. システム構築を扱ってください。
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).
Handle Systemは階層的なサービスモデルを定義します。 トップレベルはGlobal Handle Registry(GHR)として知られているただ一つのハンドルサービスから成ります。 下のレベルはLocal Handle Services(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.
どんなハンドル名前空間も管理するのにGlobal Handle Registryを使用できます。 それは、単に当局を任命する管理するのに利用されたサービス(それのすべてがハンドルとして管理される)を提供するので、ハンドルサービスの中でユニークです。 命名権威ハンドルはクライアントが命名権威の下でハンドルのための地方のハンドルサービスにアクセスして、利用するのに使用できる情報を提供します。
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.
地方のHandle Servicesはハンドルのために確信している命名当局の下で行政責任で組織によって接待されることを意図します。 Local Handle Serviceはいろいろな地方のハンドル名前空間に責任があるかもしれません、とそれぞれがユニークな命名権威で特定しました。 Local Handle Serviceとその責任があるセットの地方のハンドル名前空間を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
Handle Systemの1つの重要な一面が分配されたアーキテクチャです。 Handle Systemは多くの個々のハンドルサービスから全体で成ります。 それぞれのこれらのサービスは1つ以上のサービスサイトから成るかもしれません。 それぞれのサービスサイトはハンドル解決によるサービスで、他のあらゆるサイトの完全な模写です。 それぞれのサービスサイトは1つ以上のハンドルサーバから成るかもしれません。 ハンドル、およびしたがって、すべてのハンドル要求が与えられたサービスサイトで指示したすべてがこれらのハンドルの向こう側に均等に分配されるでしょう。
Sun, et al. Informational [Page 8] RFC 3650 Handle System Overview November 2003
Sun、他 情報[8ページ]のRFC3650はシステム概要2003年11月を扱います。
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.
サーバ。 全体でHandle Systemはいろいろなハンドルサービスから成るかもしれません。 ハンドルサービスの数の上、または、各サービスを作るサイトの数の上に設計限界が全くありません、そして、どんな限界も各サイトを作るサーバの数にありません。 どんなサービスサイトの中の模写は、各サイトが同じ数のサーバを含むのを必要としません。 言い換えれば、各サイトが同じ模写されたセットのハンドルを持つ間、各サイトは異なった数のサーバの向こう側にそのセットのハンドルを割り当てるかもしれません。 この分散型アプローチは、スケーラビリティを支援して、操作で大規模ないずれも収容して、ただ一つのポイント失敗の問題を緩和することを意図します。
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つは米国の西海岸での米国の東海岸ともう片方で場所を見つけられました。 東海岸サービスサイトは4台のサーバー・コンピュータから成ります。 より強力なコンピュータが配布されている状態で、西海岸サービスサイトは、2つのサーバが十分であると決めます。 ダイナミックにサービス要件によって、どんなハンドルサービスのためのサービスサイトの数、およびどんなサービスサイトによっても使用されるサーバの数も加えるか、または取り除くかもしれません。
------------------------- ------------------
| --------- --------- | | ----- ----- |
| | | | | | | | S | | S | |
| | server1 | | server2 | | | | E | | E | |
| | | | | | | | R | | R | |
| --------- --------- | | | V | | V | |
| --------- --------- | | | E | | E | |
| | | | | | | | R | | R | |
| | Server3 | | Server4 | | | | | | | |
| | | | | | | | 1 | | 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
それぞれのハンドルサービスはHandle Systemの下で異なったサブ名前空間を管理します。 異なったハンドルサービスの下における名前空間は重ならないかもしれません。 サブ名前空間は多くの命名当局の下でハンドルから通常成ります。 ハンドルサービスは、当局を任命するこれらの「ホーム」サービスと呼ばれて、当局を任命するこれらの下のハンドルに解決と管理サービスを供給する唯一無二です。 ハンドルを決議する前に、クライアントは問題のハンドルの「ホーム」サービスを決定しなければなりません。 それぞれのハンドルの「ホーム」サービスは、命名権威の「ホーム」サービスであり、あります。
Sun, et al. Informational [Page 9] RFC 3650 Handle System Overview November 2003
Sun、他 情報[9ページ]のRFC3650はシステム概要2003年11月を扱います。
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 Registryでは、登録されています。 クライアントは、「ホーム」が各ハンドルのためのサービスであることを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.
Global Handle Registryは権威が扱う命名を維持します。 それぞれの命名権威ハンドルは命名権威の「ホーム」サービスについて説明するサービス情報を保守します。 サービス情報は与えられたハンドルサービスのサービス場所を記載します、各サイトの中のそれぞれのハンドルサーバへのインタフェースと同様に。 「ホーム」がどんなハンドルのためのサービスであることもわかるために、クライアントは対応する命名権威ハンドルに関連しているサービス情報のためにGlobal Handle Registryについて質問できます。 クライアントが「ホーム」サービスで交信するように、サービス情報は必要事項を提供します。
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は典型的なハンドル解決プロセスに関する例を示しています。 この場合、「ホーム」サービスはLocal Handle Serviceです。 クライアントは、ハンドル「10.1045/july95-兵器」を決議しようとしていて、Global Handle Registryから「ホーム」がサービスであることがわからなければなりません。 命名権威ハンドルのために質問をGlobal Handle Registryに「10.1045インチ」送ることによって、「ホーム」サービスを見つけることができます。 Global Handle Registryは命名権威の下でハンドルに「10.1045インチ」責任感が強いLocal Handle Serviceのサービス情報を返します。 サービス情報で、クライアントは、「10.1045/july95は軍備する」ハンドルを決議するためにLocal Handle Serviceとコミュニケートできます。
Sun, et al. Informational [Page 10] RFC 3650 Handle System Overview November 2003
Sun、他 情報[10ページ]のRFC3650はシステム概要2003年11月を扱います。
------------------------
| | 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 | | |
| | ----------------------
---------------
------------------------ | | 4. クライアント要求の結果| グローバルであるのをもっているクライアント| <-------------------------------. | サービス情報| | | | ----------------------------. | ------------------------ 3. 責任があることへの要求| | | ^地方のハンドルサービス| | 1. クライアント| | | | 質問| | | | 命名| | 2. サービス情報| | 権威| | 「10.1045インチV」| "10.1045" | | ---------------------- | | | | V| | 地方のハンドルサービス| --------------- | 責任がある| | | | 権威を命名します。| | グローバルなハンドル| | "10.1045" | | 登録| | | | | ---------------------- ---------------
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.
解決性能を向上させるために、どんなクライアントも、Global Handle Registryから返されたサービス情報をキャッシュして、その後の質問にそれを使用するのを選ぶかもしれません。 Aはハンドルキャッシュサーバを切り離します、スタンドアロンであるか、またはまた、メカニズムをキャッシュする司令官の1つの断片として、地方の共同体の中の共有されたキャッシュを提供するのに使用されるかもしれません。 どんなハンドルサービスにも連絡しないで、キャッシュされた解決結果を考えて、同じハンドルのその後の質問は局所的に答えられるかもしれません。 Global Handle Registryに連絡しないで、キャッシュされたサービス情報を考えて、クライアントは直接正しいLocal Handle Serviceに彼らの要求を送ることができます。
5. Handle System Security
5. システムセキュリティを扱ってください。
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.
Handle Systemはハンドル解決と管理サービスオーバーに公共のインターネットなどのネットワークを提供します。 1セットの値を各ハンドルに割り当てることができます。 クライアントは、どんなハンドルにも値のセットに変えるのにハンドル解決サービスを使用します。 各値には、データ型とユニークな価値指数があります。 クライアントは特定のハンドルのためにデータ型に基づく値か価値指数について質問できます。
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.
ハンドル管理サービスは、ハンドルを管理するためにクライアントから要求に答えます。 ハンドルを削除するか、またはそれらの値をアップデートして、これらは、ハンドルを加えるのを含んでいます。 また、権威をハンドルと命名することを通してそれは命名当局を経営します。 各ハンドルはそれ自身の管理者を持つことができます、そして、各管理者のある許容は承諾できます。
Sun, et al. Informational [Page 11] RFC 3650 Handle System Overview November 2003
Sun、他 情報[11ページ]のRFC3650はシステム概要2003年11月を扱います。
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.
Handle Systemはクライアントやサーバ証明などのセキュリティー・サービス、データの機密性、保全、および非拒否を提供します。 デフォルトで、ハンドル決議は少しのクライアント認証も必要としません。 決議は、どんなハンドル(管理者による)にも割り当てられた秘密のデータのためにしかしながら、どんな管理要求(例えば、ハンドル値を加えるか、または削除する)と同様に適切な承認のためにクライアントの認証を必要とするよう要求します。 サーバは決めるでしょう、承認プロセスの間、クライアントに、それらの秘密のハンドル値にアクセスする許可を持っているか、または加えるか、ハンドルをアップデートして、または値を扱う許可があることにかかわらず。 認証が必要であるときに、クライアントの要求を行う前に、ハンドルサーバは要求しているクライアントへの挑戦を発行するでしょう。 認証要件を満たすために、クライアントは名乗る適任の管理者である正しい応答は返送しなければなりません。 ハンドルサーバはクライアントのうまくいっている認証の後にだけ初期の要求に応じるでしょう。 ハンドルクライアントは、認証に秘密鍵か公開鍵暗号のどちらかを使用するのを選ぶかもしれません。 また、第三者認証サービスでハンドルSystem認証を行うことができます。 データ保全、クライアントはどんなハンドルサーバからもデジタルに署名している応答を要求するかもしれません。また、いずれも情報交換したようにハンドルサーバとの機密保護しているコミュニケーションセッションをセットアップするかもしれないのを保証するのがセッションキーを使用することで暗号化できます(データの機密性のための)。 また、ハンドルサーバは、それをクライアントに送る前にハンドルデータを暗号化することによって、秘密性を提供できます。
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.
Handle Systemは機密保護している情報交換のためのサービスオプションをクライアントとサーバの間に提供します。これはもちろんハンドル値の正直さを保証しません。 管理者によってどんなハンドルにも割り当てられた不正確な値はクライアントを非常によくミスリードするかもしれません。 他方では、ハンドル値は、追加資格証明書を提供するために他のハンドル値に参照を含むかもしれません。 例えば、ハンドル値R(例えば、クレーム)は次に、署名がハンドル値Rを信じるかもしれないと信じる値のR.Clientsにデジタル署名(立派なソースからの)を含むある他のハンドル値の参照を含むかもしれません。
6. The Handle System and other Internet Services
6. Handle Systemと他のインターネットのサービス
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.
デザインか意図でHandle Systemのために提案された機能性のいくつかをカバーする多くの存在と提案されたインターネット識別子サービスか仕様があります。 このセクションはHandle Systemとの関係で簡潔にそれらを見直します。
Sun, et al. Informational [Page 12] RFC 3650 Handle System Overview November 2003
Sun、他 情報[12ページ]のRFC3650はシステム概要2003年11月を扱います。
6.1. Domain Name Service (DNS)
6.1. ドメイン名サービス(DNS)
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.
Domain Name Service、またはDNSが、元々、設計されて、ネットワークルーティング目的のためにIP Addressesにドメイン名を写像するのに大いに使用されます。 RFC1034[2]とRFC1035[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ゾーンレベルにおけるネットワーク管理者によって通常管理されます。 1名前あたり1つの運営機構への支給が全くありません。 ネットワーク管理者以外のだれでも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.
Handle Systemはセキュリティ機能と同様にその分散型管理とサービスモデルでDNSと異なっています。 ハンドルシステムプロトコルは、データ伝送の間、秘密性と保全を保証するためにセキュリティオプションを含んでいます。 各ハンドルはそれ自身のサーバアドミニストレータから独立している管理者を持つことができます。 ハンドルシステムプロトコルで、どんなハンドル管理者も公衆通信回線の上でしっかりとその人のハンドルを管理できます。 さらに、Handle Systemサービスモデルは収容するサーバのクラスタの中のサービス分配がサービスのリクエストを増強したのをサービスサイトのいずれもダイナミックに構成させます。 また、これは、より少ない強力なコンピュータが任意に多くのハンドルを支えるのに一緒に使用されるのを許容します。
6.2. Directory Services (X.500/LDAP)
6.2. ディレクトリサービス(X.500/LDAP)
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
X.500[6]はISOとITUによって定義されたOSIディレクトリStandardです。 それは、「電話番号かX.400のどちらかを返すホワイトページサービスに人々のO/Rアドレスを提供する」ように設計されていて、「主にオープン・システム・インターコネクション(OSI)アプリケーションのためのネームサーバサービスを提供するのに関係があるので」[7]です。 X.500は、グローバル名ルックアップを許容して、探すために1セットのプロトコルで階層データと情報モデルを定義します。 しかしながら、プロトコルは実装するのが難しいと判明しました、そして、「存在すると統合されたクライアントアクセス」を得ることにおける苦労がありました。
Sun, et al. Informational [Page 13] RFC 3650 Handle System Overview November 2003
Sun、他 情報[13ページ]のRFC3650はシステム概要2003年11月を扱います。
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.
「製品。」[14] プロトコルを実装するのをより簡単でより簡単にすることによって、LDAP(ライトウェイト・ディレクトリ・アクセス・プロトコル)[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.
Handle Systemなどの名前解決サービスと、LDAPなどのディレクトリサービスの基本的な違いは検索能力です。 ディレクトリサービスを捜すことができる付記された機能性は、必ずそれと共に加えられた複雑さを運んで、その結果、効率に影響します。 機能を扱わないで、Handle Systemなどの純粋な名前サービスは唯一知られている項目の効率的な解決の周りで設計される場合があります、そして、データ構造が不完全な評価基準に基づく未知の項目の発見に必要です。
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]などのディレクトリサービスは、Handle Systemと提携して逆のルックアップサービスを提供するのに使用されるかもしれません。 例えば、既存の法人のディレクトリサービスは両方のサービスにインタフェースを提供するかもしれません。 Handle Systemインタフェースは高能率的な名前解決サービスを提供するでしょう。 ディレクトリサービスインタフェースは拡張検索能力を提供するでしょう。 また、LDAPサービス紹介にハンドルを使用できました。 例えば、LDAPサービスはハンドルとして参照をつけられるかもしれません。 そうするのは位置の変化の如何にかかわらず永続的な時間外を参照するでしょう。
6.3. Uniform Resource Identifier (URI)/Uniform Resource Name(URN)
6.3. Uniform Resource Identifierの(URI)/ユニフォームリソース名(つぼ)
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.
Uniform Resource Identifier(URI)[23]は、インターネット資料を特定するためにウェブアプリケーションで一定の、そして、しかし、広げることができる命名メカニズムを定義します。 一定のResource Name(URN)[11](URIの部分集合)は永続的な名前空間のためにURIの下で名前空間登録メカニズムを定義します。 URI/URNはサービスというウェブアプリケーションで使用されるインターネット名の大部分を表します。 このセクションはURI/URNとアプリケーションがURI/URN文脈の中でどうHandle Systemを利用するかもしれないかにHandle Systemの関係について論じます。
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.
Handle Systemはインターネットのための汎用名前サービスを提供します。 DNSやX.500ディレクトリサービスのように、Handle Systemはどんな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.
Handle Systemは永続的な名前サービスを必要とするアプリケーションに使用されるかもしれません。 Handle Systemは、永続的な名前がハンドルとして登録されるのを許容するために必要なメカニズムを提供します。
Sun, et al. Informational [Page 14] RFC 3650 Handle System Overview November 2003
Sun、他 情報[14ページ]のRFC3650はシステム概要2003年11月を扱います。
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.
特定の命名当局は、永続的になるように設計されたそれらのハンドルを接待するために定義されるかもしれません。 しかしながら、ハンドルの固執は技術自体より施政方針によります。 そのような方針はこのセットのドキュメントで説明されるようにHandle Systemサービスを超えています。
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.
他方では、また、永続的な名前は必要でないアプリケーションにHandle Systemを使用できます。 そのようなハンドルには、短い寿命があるかもしれません、そして、また、それらは、いろいろな時間に異なったオブジェクトを特定するのに使用されるかもしれません。
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.
異なったウェブアプリケーションは、サービスという基本的な名前としてHandle Systemを使用することで開発されるかもしれません。 それぞれのこれらのアプリケーションはアプリケーションの必要性のためにそれ自身のURI/URN名前空間を定義するかもしれません。 例えば、アプリケーションFOOは、URI名前空間が「以下をfooすること」を持っているかもしれません。 ウェブにおけるどんなFOOサービスも特定するために、登録されます。 その間に、アプリケーションBARは、永続的な名前を必要とするどんなバーオブジェクトも特定するためにURN名前空間「つぼ: バー」を登録させるかもしれません。 FOOとBARアプリケーションの両方がサービス、そして/または、オブジェクトへの命名と決議にハンドル(彼らのそれぞれの命名権威の下における)を使用するかもしれません。 これはDNSで同様です、DNSサービスをすべて利用して。(そこに、異なったアプリケーションのために定義された異なったURI体系(例えば、「telnet」、"ftp"、"mailto"など)があります)。
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関連の仕事の分野でHandle Systemについて議論しました。 Handle Systemが特定のURIかURN名前空間に収まるかどうかに関する異なった意見があります。 また、関心がHandle Systemがインターネットにおける他の既存の名前サービスと関連して合うところにあります。 このドキュメントの範囲の外にそのような議論があります。
7. Security Considerations
7. セキュリティ問題
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.
このセクションはHandle Systemのセキュリティ限界について人々に知らせることになっています、アプリケーション開発者、サービスプロバイダー、およびHandle Systemクライアントによって払われるべきである注意と同様に。 そのHandle Systemプロトコル[21]、データ、およびサービスモデル[22]に関する特定のセキュリティ問題は別々のドキュメントで扱われます。
7.1. General Security Practice
7.1. 総合証券習慣
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
Handle Systemのセキュリティはクライアントと至る所にトランザクションにおけるサーバー・ホストセキュリティの両方によります。 それは、クライアントホストがいじられていないと仮定します、そして、そのクライアントソフトウェアは受信データをクライアントに確かに伝えるでしょう。 また、どんなハンドルサービスのクライアントも、サーバがかかわったどんなハンドルも感染されていないと仮定しなければなりません。 Global Handle Registryがいると信じるために
Sun, et al. Informational [Page 15] RFC 3650 Handle System Overview November 2003
Sun、他 情報[15ページ]のRFC3650はシステム概要2003年11月を扱います。
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.
Global Handle Registryが正しく責任があるLocal Handle Serviceにクライアント要求を向けると信じてください。 Local Handle Serviceを信じるのは、Local Handle Serviceが正しく管理者によってハンドルに割り当てられたデータを返すと信じることです。 Local Handle Serviceは当局を任命するセットを通常支えます。 その結果、Local Handle Serviceが当局を任命するものを信じながら含意すると信じます。
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.
Handle Systemの保全は大いにグローバルなサービス情報の保全によります。 無効のグローバルなサービス情報は不適当なLocal Handle Servicesにクライアントをミスリードするかもしれません。 また、それで、攻撃者はサーバ署名を鍛造できるかもしれません。 Global Handle Registryはグローバルなサービス情報を保護しながら、極端な警告を中に入れなければなりません、そして、公開鍵組は以前はよくグローバルなサービス情報に署名していました。 クライアントアプリケーションはGlobal Handle Registryからグローバルなサービス情報を受け入れるだけであるべきです。 彼らは各アップデートのときに保全をチェックするべきです。
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.
効率理由で、ハンドルサーバは、あらゆるサービス応答のためのデジタル署名を生成もしませんし、返しもしないでしょう、クライアントによって明確に要求されない場合。 データ保全を保証するために、クライアントは、デジタル署名を返すように明らかにサーバに頼まなければなりません。 クライアントは、暴露から極秘データを保護するために、サーバとのコミュニケーションセッションを確立して、セッションキーを使用することであらゆるデータを暗号化するようにサーバに頼むかもしれません。
7.2. Privacy Protection
7.2. プライバシー保護
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.
デフォルトで、別の方法でハンドル管理者によって指定されない場合、Handle Systemに保存されたほとんどのハンドルデータが公的にアクセス可能です。 個人情報を含むハンドル値を加えるとき、ハンドル管理者は注意を向けなければなりません。 暗号化されるとしてこれらを保存するために、値を扱って、彼らが、ハンドル管理者だけでこれらのハンドル値が読み込み可能であるとマークするのを選ぶかもしれませんか、または制御聴衆の中でこれらの値は読むことができるだけです。
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.
ハンドルサーバによって生成されたログファイルはクライアントプライバシーは攻撃されているかもしれない別の損傷を受けやすい箇所です。 ハンドルサーバのオペレータは慎重にそのような情報を保護しなければなりません。
7.3. Caching and Proxy Servers
7.3. キャッシュとProxyサーバ
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
性能向上と他の付加価値が付いたサービス以外に、プロキシとキャッシュサーバの両方が、中央の男性として出向いて、そういうものとして介入者攻撃に被害を受け易いです。 プロキシとキャッシュサーバがどんなハンドルサービスの一部でないことも知るのは重要です。 彼らはHandle Systemのクライアントです。 Handleを通してプロキシからのサービス応答とキャッシュサーバを認証できません。
Sun, et al. Informational [Page 16] RFC 3650 Handle System Overview November 2003
Sun、他 情報[16ページ]のRFC3650はシステム概要2003年11月を扱います。
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.
プロキシとキャッシュサーバを使用することによって、クライアントは、サーバがコンテンツのいずれも誤って扱わないで彼らの要求を提出して、Handle Systemからどんな応答もリレーすると仮定します。 また、彼らは、サーバがそれらの利益に関するどんな機密情報も保護すると仮定します。
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.
キャッシュの内容が悪意がある攻略のための魅力的な目標を表すので、キャッシュサーバは追加潜在的脆弱性を提供します。 キャッシュへの起こり得るかもしれない攻撃がハンドルユーザのために個人的なデータを明らかにすることができますか、またはユーザが、ネットワークからそれらを取り除いてあると信じた後に情報はまだ保たれていました。 したがって、キャッシュコンテンツは機密情報として保護されるべきです。
7.4. Mirroring
7.4. ミラーリング
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.
ハンドルSystemクライアントはミラーリングサイトの中の満足している模写の可能な遅れを意識しているべきです。 彼らは、どんな時間極秘データのためにも彼らの要求を一次業務サイトに送ると考えるべきです。 サービス管理者によるミラーリングサイトの品揃えは慎重に完了していなければなりません。 それぞれのミラーリングサイトは、データ保全を確実にするために同じセキュリティ手順に従わなければなりません。 ソフトウェアツールは、ミラーリングサイトの中でデータの一貫性を確実にするために適用されるかもしれません。
7.5. Denial of Service (DoS)
7.5. サービス妨害(DoS)
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
どんな社会奉仕のようにも、Handle Systemはサービス不能攻撃を受けることがあります。 どんな一般解も、今日の技術でそのような攻撃から守るために利用可能ではありません。 彼らが起こるとき、サーバ実装は、そのような攻撃を意識していて、管理者に通知するために開発されるかもしれません。 状態がないクッキー[19、20]は認証、保全、および暗号化サービスを実行するホストへのDoS攻撃の効果のいくつかを緩和する1つの手段です。 サーバ
Sun, et al. Informational [Page 17] RFC 3650 Handle System Overview November 2003
Sun、他 情報[17ページ]のRFC3650はシステム概要2003年11月を扱います。
implementations, moreover, need to be upgradeable to take advantage of new security technologies, including anti-DoS technologies as these become available.
そのうえ、これらが利用可能になるので反DoS技術を含んで、実装は、新しいセキュリティー技術を利用するためにアップグレード可能である必要があります。
8. History of the Handle System
8. ハンドルシステムの歴史
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.
Handle Systemは総合的なデジタル目的アーキテクチャの一部として元々、発想されて、CNRIで開発されました。 最初の公共の実装はデヴィッド・イーリーによって導かれた取り組みにおける1994年秋にCNRIに作成されました。 Handle Systemを含む総合的なデジタル目的アーキテクチャは1995年に後で論文でロバート・カーンとロバート・ウィレンスキー[1]によって説明されました。 開発はグラントNumber MDA972-92-J-1029とMDA-972-99-1-0018の下でDefense Advanced Projects Agency(DARPA)によって資金を供給されたコンピュータScience Technical Reports(CSTR)プロジェクトの一部としてCNRIで続きました。 また、NetworkedコンピュータScience Technical Reference図書館(NCSTRL)[18]と関連活動の発展で重要な要因であったこの早めのデジタルライブラリプロジェクトの1つの局面はデジタルライブラリの基本的なインフラストラクチャのためにフレームワークを開発することでした。
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.
Handle Systemの初期採用者は議会図書館、国防技術情報センター(DTIC)、および国際DOI財団(IDF)を入れました。 NCSTRLと同様にこれらの組織からのフィードバック、他のデジタルライブラリプロジェクト、および以上のようの関連するIETF取り組みはHandle Systemの発展にすべて貢献しました。 クライアントとサーバの両方のために、 http://www.handle.net で現在の状態と利用可能なソフトウェアを見つけることができます。
9. Acknowledgements
9. 承認
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.
Handle System実装の以前のバージョンからこの仕事を得ます。 デザイン考えはHandle System開発チームの中で議論したものに基づいています、デヴィッド・イーリー、シャルル・オルト、アリソン・ユー、ショーン・ライリー、ジェーン・オイラー、キャサリン・レイ、ステファニーNguyen、ジェイソンPetrone、およびヘレンSheを含んでいて。 この仕事への彼らの貢献は感謝して承諾されます。
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共同体の他のメンバーから受けられた推薦と同様に。
Sun, et al. Informational [Page 18] RFC 3650 Handle System Overview November 2003
Sun、他 情報[18ページ]のRFC3650はシステム概観2003年11月を扱います。
10. References and Bibliography
10. 参照と図書目録
[1] Kahn, R. and R. Wilensky, "A Framework for Distributed Digital
Object Services", D-Lib Magazine, 1995.
[1] カーンとR.とR.ウィレンスキー、「分配されたデジタル物のサービスのための枠組み」、D-リブ雑誌、1995
[2] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, November 1987.
[2]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[3] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[3]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
Locators (URL)", RFC 1738, December 1994.
[4] バーナーズ・リーとT.とMasinterとL.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[5] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
10646", RFC 2044, October 1996.
[5]Yergeau、1996年10月のF.、「UTF-8、ユニコードとISO10646の変化形式」RFC2044。
[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] ウォールとM.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。
[9] Sollins, K. and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994.
[9]SollinsとK.とL.Masinter、「一定のリソース名のための機能条件書」、RFC1737、1994年12月。
[10] Sollins, K. "Architectural Principles of Uniform Resource Name
Resolution", RFC 2276, January 1998.
1998年1月の[10]Sollins、K.「一定のリソース名前解決の建築プリンシプルズ」RFC2276。
[11] IETF Uniform Resource Names (URN) Working Group, April 1998.
[11] IETFの一定のリソースは(つぼ)作業部会、1998年4月を命名します。
[12] D-Lib Magazine, http://www.dlib.org
[12] D-リブ雑誌、 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.Sun、「ハンドルシステムの国際化--しつこいグローバル名は」 第12国際ユニコードコンファレンスを続かせる4月1998を修理します。
[14] D. Goodman, C. Robbins, "Understanding LDAP & X.500", August
1997.
C.ロビンス、「理解LDAP&X.500」1997年8月の[14]D.グッドマン。
[15] Deutsch P., Schoultz R., Faltstrom P. and C. Weider,
"Architecture of the WHOIS++ service", RFC 1835, August 1995.
[15] ドイツ語P.とSchoultz R.とFaltstrom P.とC.ワイダー、「WHOIS++サービスの構造」、RFC1835、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++インデックスサービスの構造」、RFC1913、1996年2月。
Sun, et al. Informational [Page 19] RFC 3650 Handle System Overview November 2003
Sun、他 情報[19ページ]のRFC3650はシステム概観2003年11月を扱います。
[17] The Unicode Consortium, "The Unicode Standard, Version v3.0",
Addison-Wesley Pub Co; ISBN: 0201616335.
[17] ユニコードConsortium、「ユニコードStandard、バージョンv3.0"、アディソン-ウエスリー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.、およびW.シンプソン、「Photuris:」 「セッションKey Managementプロトコル」、RFC2522、1999年3月。
[20] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[20] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[21] Sun, S., Reilly, S. and L. Lannom, "Handle System Namespace and
Service Definition", RFC 3651, November 2003.
[21] Sun、S.、ライリー、S.、およびL.Lannomが「システム名前空間とサービス定義を扱う」、RFC3651、11月2003日
[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、「ハンドルシステムプロトコル(ver2.1)仕様」、RFC3652、2003年11月Sun。
[23] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[23]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。
11. Authors' Addresses
11. 作者のアドレス
Sam X. Sun Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
国家の研究イニシアチブ(CNRI)1895プレストンホワイト博士、100レストン、Suiteヴァージニア 20191へのサムX.Sun社
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
国家の研究イニシアチブ(CNRI)1895プレストンホワイト博士、100レストン、Suiteヴァージニア 20191へのラリーLannom社
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レストン、Suiteヴァージニア 20191へのブライアンBoesch社
Phone: 703-262-5316 EMail: bboesch@cnri.reston.va.us
以下に電話をしてください。 703-262-5316 メールしてください: bboesch@cnri.reston.va.us
Sun, et al. Informational [Page 20] RFC 3650 Handle System Overview November 2003
Sun、他 情報[20ページ]のRFC3650はシステム概観2003年11月を扱います。
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Sun, et al. Informational [Page 21]
Sun、他 情報[21ページ]
一覧
スポンサーリンク
