Network Working Group S. Sun
Request for Comments: 3651 S. Reilly
Category: Informational L. Lannom
CNRI
November 2003
Handle System Namespace and Service Definition
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 it 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内のいくつかのグループが、識別子の既存のシステムにハンドルシステムとITの関係を議論してきました。 IESGは、これらの議論は説明ハンドルシステム上でも、それは識別子のIETFアーキテクチャに適合かもしれない方法についてIETFコンセンサスが得られていないことを指摘したいです。特にURNとして、URIの形式として、ハンドルの議論がなされているが、これらの文書は、名前空間と識別子は、インターネット上で動作し、IETFコンセンサスビューと一致しない場合があり、既存のシステムの特徴付けを含めるかもしれない方法の別のビューを記述する。
Abstract
抽象
The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document provides a detailed description of the Handle System namespace, and its data, service, and operation models. The namespace definition specifies the handle syntax and its semantic structure. The data model defines the data structures used by the Handle System protocol and any pre-defined data types for carrying out the handle service. The service model provides definitions of various Handle System components and explains how they work together over the network. Finally, the Handle System operation model describes its service operation in terms of messages transmitted between client and server, and the client authentication process based on the Handle System authentication protocol.
ハンドルシステムは、公共のインターネット上で安全な名前解決と管理を可能にする汎用的なグローバルネームサービスです。この文書では、ハンドルシステムの名前空間の詳細な説明を提供し、そのデータ、サービス、および運用モデル。名前空間定義は、ハンドルの構文とその意味構造を指定します。データモデルは、ハンドル・システム・プロトコルとハンドルサービスを実行するための任意の事前定義されたデータタイプによって使用されるデータ構造を定義します。サービスモデルは、さまざまなハンドルシステムコンポーネントの定義を提供し、それらがネットワーク上でどのように連携するかを説明します。最後に、ハンドルシステムの動作モデルは、クライアントとサーバー、およびハンドルシステムの認証プロトコルに基づいてクライアントの認証プロセスとの間で送信されるメッセージの面でそのサービスの動作を説明します。
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Handle System Namespace. . . . . . . . . . . . . . . . . . . . 3
3. Handle System Data Model . . . . . . . . . . . . . . . . . . . 4
3.1. Handle Value Set . . . . . . . . . . . . . . . . . . . . 4
3.2. Pre-defined Handle Data Types. . . . . . . . . . . . . . 9
3.2.1. Handle Administrator: HS_ADMIN . . . . . . . . . 10
3.2.2. Service Site Information: HS_SITE. . . . . . . . 14
3.2.3. Naming Authority Delegation Service:
HS_NA_DELEGATE . . . . . . . . . . . . . . . . . 19
3.2.4. Service Handle: HS_SERV. . . . . . . . . . . . . 20
3.2.5. Alias Handle: HS_ALIAS . . . . . . . . . . . . . 21
3.2.6. Primary Site: HS_PRIMARY . . . . . . . . . . . . 21
3.2.7. Handle Value List: HS_VLIST. . . . . . . . . . . 22
4. Handle System Service Model. . . . . . . . . . . . . . . . . . 22
4.1. Handle System Service Components . . . . . . . . . . . . 23
4.1.1. Global Handle Registry (GHR) . . . . . . . . . . 23
4.1.2. Local Handle Service (LHS) . . . . . . . . . . . 26
4.2. Handle System Middle-Ware Components . . . . . . . . . . 27
4.2.1. Handle System Caching Service. . . . . . . . . . 27
4.2.2. Handle System Proxy Server . . . . . . . . . . . 28
4.3. Handle System Client Components. . . . . . . . . . . . . 28
5. Handle System Operation Model. . . . . . . . . . . . . . . . . 29
5.1. Handle System Service Request and Response . . . . . . . 30
5.2. Handle System Authentication Protocol. . . . . . . . . . 32
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 37
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
8. References and Bibliography. . . . . . . . . . . . . . . . . . 38
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 41
The Handle System manages handles as globally unique names for Internet resources. It was originally conceived and described in a paper by Robert Kahn and Robert Wilensky [22] in 1995. The Handle System provides a general-purpose global name service that allows handles to be resolved and administrated securely over the public Internet. The Handle System categorizes its service into two categories: the handle resolution service and the handle administration service. Clients use handle resolution service to resolve handles into their values. The handle administration service deals with client requests to manage these handles, including adding and deleting handles, and updating handle values.
ハンドルシステムは、インターネットリソースのグローバルな一意の名前としてハンドルを管理します。もともとはハンドルシステムハンドルが解決され、公共のインターネット上で安全に投与することを可能にする汎用的なグローバル・ネーム・サービスを提供して1995年にロバート・カーン、ロバート・Wilensky [22]の論文に考案され、説明されました。ハンドル解決サービスとハンドル管理サービス：ハンドルシステムは、2つのカテゴリにそのサービスを分類します。クライアントは、それらの値にハンドルを解決するためにハンドル解決サービスを使用します。追加と削除ハンドルを、ハンドル値を更新するなど、これらのハンドルを管理するためのクライアントの要求とハンドル管理サービスを扱っています。
The document "Handle System Overview" [1] provides an architectural overview of the Handle System, and its relationship to other Internet services such as DNS [2,3] and LDAP[4]. This document provides a
文書[1]ハンドル・システムのアーキテクチャの概要を提供し、「システムの概要ハンドル」は、DNS [2,3]やLDAPなどの他のインターネットサービスとの関係[4]。このドキュメントが提供します
detailed description of the Handle System namespace, its data and service model, and its operation model. It assumes that readers are familiar with the basic concepts of the Handle System as described in the overview document.
ハンドルSystem名前空間、そのデータとサービスモデル、およびその動作モデルの詳細な説明。それは概要の文書で説明したように、読者はハンドルシステムの基本的な概念を理解していることを前提としています。
The namespace definition specifies the handle syntax and its semantic structure. The data model defines the data structures used by the Handle System protocol and any pre-defined data types for carrying out the handle service. The service model provides definitions of various Handle System components and explains how they work together over the network. Finally, the Handle System operation model describes its service operation in terms of messages transmitted between client and server, and the client authentication process based on the Handle System authentication protocol.
名前空間定義は、ハンドルの構文とその意味構造を指定します。データモデルは、ハンドル・システム・プロトコルとハンドルサービスを実行するための任意の事前定義されたデータタイプによって使用されるデータ構造を定義します。サービスモデルは、さまざまなハンドルシステムコンポーネントの定義を提供し、それらがネットワーク上でどのように連携するかを説明します。最後に、ハンドルシステムの動作モデルは、クライアントとサーバー、およびハンドルシステムの認証プロトコルに基づいてクライアントの認証プロセスとの間で送信されるメッセージの面でそのサービスの動作を説明します。
Handles are character strings that may consist of a wide range of characters. Every handle in the Handle System consists of two parts: its naming authority, followed by a unique local name under the naming authority. The naming authority and the local name are separated by the ASCII character "/" (octet 0x2F). The following table provides the handle syntax definition in ABNF [5] notation:
ハンドルは、文字の広い範囲で構成することができる文字列です。その命名権威、命名機関の下で一意のローカル名が続き：ハンドルシステム内のすべてのハンドルは、2つの部分からなります。命名機関とローカル名は、ASCII文字「/」（オクテット0x2F）で区切られます。以下の表は、ABNF [5]表記のハンドル構文の定義を提供します。
<Handle> = <NamingAuthority> "/" <LocalName>
<ハンドル> = <NamingAuthority> "/" <たLocalName>
<NamingAuthority> = *(<NamingAuthority> ".") <NAsegment>
<NamingAuthority> =（<NamingAuthority> ""）<NAsegment>
<NAsegment> = 1*(%x00-2D / %x30-3F / %x41-FF ) ; any octets that map to UTF-8 encoded ; Unicode 2.0 characters except ; octets '0x2E' and '0x2F' (which ; correspond to the ASCII characters '.', ; and '/').
<NAsegment> = 1 *（％x00-2D /％x30-3F /％X41-FF）。 UTF-8エンコードにマッピング任意のオクテット。ユニコード2.0文字を除きます。 （; ASCII文字に対応し、 '';と '/'）オクテット '0x2E' と '0x2F'。
<LocalName> = *(%x00-FF) ; any octets that map to UTF-8 encoded ; Unicode 2.0 characters
<たLocalName> = *（％のX00-FF）。 UTF-8エンコードにマッピング任意のオクテット。ユニコード2.0文字
Table 2.1: Handle syntax
表2.1：構文をハンドル
As shown in Table 2.1, both <NamingAuthority> and <LocalName> are UTF-8 [6] encoded character strings. The Handle System protocol mandates UTF-8 encoding for handles transferred over the wire. The <LocalName> may consist of any characters from the Unicode 2.0 standard [7]. The <NamingAuthority> may use any characters from the Unicode 2.0 standard except the ASCII character '/' (0x2F), which is reserved to separate the <NamingAuthority> from the <LocalName>. A <NamingAuthority> may consist of multiple non-empty <NAsegment>s, each of which separated by the ASCII character '.' (octet 0x2E).
表2.1に示すように、両方の<NamingAuthority>及び<たLocalName>は、UTF-8 [6]エンコードされた文字列です。ハンドル・システム・プロトコルは、ワイヤを介して転送ハンドル用のUTF-8エンコーディングを義務付け。 <たLocalName>ユニコード2.0標準から任意の文字からなることができる[7]。 <NamingAuthority> <たLocalName>から<NamingAuthority>を分離するために予約されているASCII文字「/」（0x2F）以外のUnicode 2.0標準の文字を使用することができます。 <NamingAuthority> ASCII文字で区切られたそれぞれが、複数の非空の<NAsegment> Sからなることができます「」 （オクテット0x2E）。
Naming authorities 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 (<NAsegment>). The parent node represents the parent naming authority. 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 (or its <NAsegment>) is separated by the character '.' (octet 0x2E). For example, the naming authority for the Digital Object Identifier (DOI) project is "10". It is a root-level naming authority as it has no parent naming authority for itself. It can, however, have many child naming authorities. For example, "10.1045" is a child naming authority of "10" for the D-Lib Magazine.
命名当局は、ツリー構造に似た階層的に定義されています。ツリーの各ノードとリーフの命名機関セグメントに対応するラベルが付与されている（<NAsegment>）。親ノードは、親の命名権限を表します。命名当局は、命名機関を表すノードに、ツリーのルートからラベルを連結し、右に左に構築されています。各ラベル（またはその<NAsegment>）は、文字で区切られています「」 （オクテット0x2E）。例えば、デジタルオブジェクト識別子（DOI）プロジェクトの命名機関は「10」です。それは自身のために権威を命名親を持たないように、それはルートレベルの命名機関です。それは、しかし、多くの子供が当局に名前を付けることができます。たとえば、「10.1045」はD-Libのマガジンのための「10」の権威を命名子です。
By default, handles are case sensitive. However, a handle service, global or local, may implement its namespace so that ASCII characters under the namespace are treated as case insensitive. For example, the global handle service, formally known as the Global Handle Registry (GHR), is implemented such that ASCII characters are treated as case insensitive. Since the GHR manages all handles for naming authorities, ASCII characters in naming authorities are treated as case insensitive.
デフォルトでは、ハンドルは、大文字と小文字が区別されます。名前空間の下にASCII文字は大文字小文字を区別しないとして扱われるように、しかし、ハンドルサービスは、グローバルまたはローカル、その名前空間を実装することができます。例えば、正式にグローバルハンドルレジストリ（GHR）として知られているグローバルハンドルサービスは、ASCII文字は大文字と小文字を区別しないとして扱われるように実装されています。 GHRは当局に名前を付けるためにすべてのハンドルを管理しているため、当局の命名でのASCII文字は大文字と小文字を区別として扱われます。
The Handle System provides a name-to-value binding service over the public Internet. Each handle may have a set of values assigned to it. The Handle System maintains the value set of each handle and will return it in response to any handle resolution request. The Handle System data model defines the conceptual data structure for these values. The data model used by the protocol may not be the exact physical data model used for storage in any specific implementation. Rather, it is the data model followed by the Handle System protocol as specified in the "Handle System Protocol Specification" [8].
ハンドルシステムは、公共のインターネット上で、名前と値バインディングサービスを提供しています。各ハンドルは、それに割り当てられた値のセットを有することができます。ハンドルシステムは、各ハンドルの設定値を維持し、任意のハンドル解決要求に応じて、それを返します。ハンドル・システム・データ・モデルは、これらの値の概念的なデータ構造を定義します。プロトコルによって使用されるデータモデルは、任意の特定の実装に格納するために使用される正確な物理データ・モデルではないかもしれません。むしろ、それは「ハンドルシステムプロトコル仕様」に指定されたように、ハンドル・システム・プロトコルに続いて、データ・モデルである[8]。
Each handle may have a set of values assigned to it. These handle values use a common data structure for its data. For example, each handle value has a unique index number that distinguishes it from other values in the value set. It also has a specific data type that defines the syntax and semantics of the data in its data field. Besides these, each handle value contains a set of administrative information such as TTL and permissions. Figure 3.1 shows the handle
各ハンドルは、それに割り当てられた値のセットを有することができます。これらのハンドル値は、そのデータのための共通のデータ構造を使用します。例えば、各ハンドル値は、値のセット内の他の値からそれを区別する一意のインデックス番号を有します。また、そのデータフィールド内のデータの構文とセマンティクスを定義する特定のデータ型を持っています。これらに加えて、各ハンドル値は、TTLおよび権限などの管理情報のセットを含みます。図3.1は、ハンドルを示し
"10.1045/may99-payette" with a set of three handle values. One of these values (with index number set to 1) is shown in detail. (Note that the encoding of the length for each field is not shown in Figure 3.1. Also, the empty <reference> field consists of a 4-byte integer whose value is zero.)
3つのハンドル値のセットで、「10.1045 / may99-ペイエット」。 （1に設定されたインデックス番号を持つ）これらの値のいずれかが詳細に示されています。 （各フィールドの長さの符号化は、図3.1に示されていないことに留意されたい。また、<参照>空のフィールドは、その値がゼロである4バイトの整数から構成されています。）
Handle "10.1045/may99-payette"
"10.1045 / may99-ペイエットの" ハンドル
|
|
V
-------------------------------------------------------------
| <index>: 3 |
------------------------------------------------------------- |
| <index>: 2 | |
------------------------------------------------------------- | |
| | | |
| <index>: 1 | | |
| <type>: URL | | |
| <data>: http://www.dlib.org/dlib... | | |
| <TTL>: {Relative: 24 hours} | | |
| <permission>: PUBLIC_READ, ADMIN_WRITE | | |
| <timestamp>: 927314334000 | | |
| <reference>: {empty} | |-
| |-
-------------------------------------------------------------
Figure 3.1: Handle "10.1045/may99-payette" and its set of values
図3.1：「10.1045 / may99-ペイエットを」ハンドルと値のセット
In Figure 3.1, it shows a handle value whose its index is set to 1. The data type for the handle value is URL. The URL data as stated in the <data> field is "http://www.dlib.org/dlib...". The TTL (time to live) entry suggests that the value record should be cached no more than 24 hours before the source of the information to be consulted again. The <permission> field grants anyone permission to read, but only the administrator to update the value. The <reference> field is empty. It may contain a list of references to other handle values as credentials for this handle value.
図3.1には、そのインデックスが1に設定されたハンドル値のデータ型がURLであるハンドル値を示しています。 URLデータ<データ>で述べたように、フィールドには、「HTTP：//www.dlib.org/dlib ...」です。 TTL（生存時間）のエントリーは、値のレコードが時間は24時間以内再び協議する情報源の前にキャッシュされるべきであることを示唆しています。 <許可>フィールドの助成金の誰の許可を読むには、しかし、唯一の管理者が値を更新します。 <参照>フィールドが空です。これは、このハンドル値のための資格情報などの他のハンドル値への参照のリストが含まれていてもよいです。
Thus a handle value may be thought of as a record that consists of a group of data fields. Each of these data fields is defined as follows:
したがってハンドル値は、データフィールドのグループから成るレコードと考えることができます。次のようにこれらのデータフィールドのそれぞれに定義されます。
<index> An unsigned 32-bit integer that uniquely identifies a handle value from other handle values.
<インデックス>一意に他のハンドル値からハンドル値を識別する符号なし32ビット整数。
<type> A UTF8-string that identifies the data type for the value record. Note that throughout this document, a UTF8-string is defined as a data structure that consists of a 4-byte unsigned integer followed by an UTF-8 encoded character string. The integer specifies the number of octets in the character string.
<タイプ>値レコードのデータ・タイプを識別するUTF8文字列。この文書全体を通して、UTF8文字列をUTF8エンコードされた文字列に続く4バイトの符号なし整数から成るデータ構造として定義されていることに留意されたいです。整数、文字列内のオクテットの数を指定します。
The <type> field identifies the data type that defines the syntax and semantics of data in the next <data> field. The data type may be registered with the Handle System to avoid potential conflicts. The Handle System has a reserved naming authority "0.TYPE" for registered data types. For example, "URL" (as shown in Figure 3.1) is a registered data type. It is registered as the handle "0.TYPE/URL". The handle may have a value that explains the syntax and semantics of the data type.
<タイプ>フィールドは、次の<データ>フィールド内のデータの構文およびセマンティクスを定義するデータタイプを識別する。データ型は、潜在的な競合を避けるためにハンドルシステムに登録することができます。ハンドルシステムは、登録されたデータ型の予約命名機関「0.TYPE」を持っています。例えば、（図3.1に示されるように）「URL」が登録されたデータ型です。これは、ハンドル「0.TYPE / URL」として登録されています。ハンドルは、データ型の構文と意味を説明した値を有することができます。
Data types under the Handle System may be hierarchical. Each level of the hierarchy may be named in terms of a UTF8-String with no '.' (0x2E) characters. The '.' character is used to mark the boundary between hierarchy levels. For example, the Handle System data type "a.b" may be considered as a sub-type "b" under the type "a". Similarly, handle values of <type> "a.b.x", "a.b.y" and "a.b.z" may be considered as handle values under the common type hierarchy "a.b".
ハンドルシステムの下でのデータ・タイプは、階層的かもしれません。階層の各レベルには無いとUTF8-文字列の観点で命名することができます「」 （0x2E）文字。 「」文字は、階層レベルとの間の境界をマークするために使用されます。例えば、「a.b」ハンドル・システムのデータ・タイプは、タイプ「A」のサブタイプ「B」と考えることができます。同様に、ハンドル<タイプ>「a.b.x」、「a.b.y」の値と「a.b.zは、」一般的なタイプの階層「a.b」の下のハンドル値とみなすことができます。
For any handle values, the UTF8-string in the <type> field may not end with the '.' character. In other words, no Handle System data type should end with the '.' character. However, the '.' character may appear in the end of the <type> parameter in a handle query. This is used to query for all handle values under a common type hierarchy. For example, one may query for all handle values under the type hierarchy "a.b" (e.g., handle values of <type> "a.b.x", "a.b.y" and "a.b.z") by setting the <type> parameter to "a.b.". Note here that the <type> parameter ends with the '.' character. Details of the handle query operation can be found in the Handle System protocol specification [8].
任意のハンドル値については、<種類>フィールドのUTF8文字列がで終わってないかもしれません「」キャラクター。言い換えれば、ハンドルシステムのデータ型はで終わるべきではありません「」キャラクター。しかし '。'文字は、ハンドルのクエリで<タイプ>パラメータの最後に表示される場合があります。これは、一般的なタイプの階層の下にあるすべてのハンドル値を照会するために使用されます。例えば、一つの型階層「a.b」の下にあるすべてのハンドル値を問い合わせることができる（例えば、の値を処理<タイプ>「a.b.x」、「a.b.y」および「a.b.z」）「A.B.」に<タイプ>パラメータを設定することにより。 <タイプ>パラメータは、で終わることに、ここで注意してください「」キャラクター。ハンドルクエリ動作の詳細は、ハンドル・システムプロトコル仕様[8]に見出すことができます。
<data> A sequence of octets (preceded by its length in a 4-byte unsigned integer) that describes the resource identified by the handle. The syntax and semantics of these octets are identified by the <type> field.
<データ>ハンドルによって識別されるリソースを記述するオクテット列（4バイトの符号なし整数で、その長さが先行します）。これらのオクテットの構文とセマンティクスは、<種類>フィールドによって識別されます。
<permission> An eight-bit bit-mask for access control of the handle value. Access control is defined in terms of read, write, and execute permissions, applicable to either general public or handle administrator(s). Each handle value can have its permission field specified as any combination of the following bits:
<許可>ハンドル値のアクセス制御のための8ビットのビットマスク。アクセス制御は、書き込み、読み取りの面で定義され、一般市民やハンドルの管理者（複数可）のいずれかに該当する権限を、実行されます。各ハンドル値は以下のビットのいずれかの組み合わせとして指定し、その許可のフィールドを持つことができます。
PUBLIC_WRITE (0x01) permission that allows anyone to modify or delete the handle value.
PUBLIC_WRITE誰もがハンドル値を変更または削除することができます（0x01の）許可。
PUBLIC_READ (0x02) permission that allows anyone to read the handle value.
誰もがハンドル値を読み取ることができますPUBLIC_READ（0×02）許可。
ADMIN_WRITE (0x04) permission that allows any handle administrator to update or delete the handle value.
任意の取手管理者が更新またはハンドル値を削除することができますADMIN_WRITE（0x04を）許可。
ADMIN_READ (0x08)_ permission that allows the handle value to be read by any handle administrator with AUTHORITIVE_READ privilege.
ADMIN_READハンドル値がAUTHORITIVE_READ権限を持つ任意のハンドルの管理者で読み取ることを可能にする（0x08の）_許可。
PUBLIC_EXECUTE (0x10) permission that allows anyone to execute the program identified by the handle value on the handle host as anonymous user. Because of the security risks this may have brought up, implementations may choose not to support such permission, or provide options so that it can be disabled at deployment.
誰でも匿名ユーザーとしてハンドルホスト上のハンドル値によって識別されるプログラムを実行することができますPUBLIC_EXECUTE（0x10の）許可。セキュリティリスクのこれが育てている可能性があるため、実装は、そのような権限をサポートしないことを選択すること、またはそれは、展開時に無効にすることができるようにオプションを提供します。
ADMIN_EXECUTE (0x20) permission that allows handle administrator(s) to run the program identified by the handle value on the handle server. The handle server must authenticate the handle administrator before executing the program. The handle administrator must have an established account on the handle server. The execution of the handle value should assume the same privilege as the one given to the account for the handle administrator. Because of the security risks this may have brought up, implementations may choose not to support such permission, or provide options so that it can be disabled at deployment.
ADMIN_EXECUTEハンドルの管理者（s）がハンドルサーバ上のハンドル値によって識別されるプログラムを実行することができます（0x20の）許可。ハンドルサーバプログラムを実行する前に、ハンドルの管理者を認証する必要があります。ハンドルの管理者は、ハンドルサーバ上で設定された口座を持っている必要があります。ハンドル値の実行は、ハンドルの管理者用アカウントに与えられたものと同じ権限を想定する必要があります。セキュリティリスクのこれが育てている可能性があるため、実装は、そのような権限をサポートしないことを選択すること、またはそれは、展開時に無効にすることができるようにオプションを提供します。
Note that a handle value with no PUBLIC_READ nor ADMIN_READ permission can not leave the handle server. It may be used, for example, to store secret keys for authentication purposes. A handle value with neither PUBLIC_WRITE nor ADMIN_WRITE permission makes the handle value immutable and cannot be deleted by any handle administrator (via the Handle System protocol).
無PUBLIC_READもADMIN_READ権限を持つハンドル値は、ハンドルサーバーを離れることができないことに注意してください。認証目的のために秘密鍵を格納するために、例えば、使用することができます。 PUBLIC_WRITEもADMIN_WRITE権限もないとハンドル値は、ハンドル値が不変になり、（ハンドルシステムのプロトコルを経由して）任意のハンドル管理者が削除することはできません。
The administrator for a given handle must specify the permission for each handle value. Implementations may choose PUBLIC_READ and ADMIN_WRITE as the default permission for each handle value. Handle servers must check permissions before fulfilling any client request.
与えられたハンドルのための管理者は、各ハンドル値の許可を指定する必要があります。実装は各ハンドル値のデフォルトの権限としてPUBLIC_READとADMIN_WRITEを選択することができます。ハンドルサーバは、任意のクライアントの要求を満たす、あらかじめアクセス許可を確認する必要があります。
<TTL> An octet followed by a 4-byte integer that specifies the Time-To-Live of the value record. It is used to describe how long the value record can be cached before the source of the information should again be consulted. A zero value for a TTL indicates that the value record should only be used for the transaction in progress and should not be cached. Any non-zero TTL is defined in terms of a TTL type (specified in the first octet), followed by the TTL value (the 32-bit unsigned integer that follows the TTL type). The TTL type indicates whether the TTL value is absolute or relative. The absolute TTL value defines the time to live in terms of seconds since 00:00:00 UTC, January 1st 1970. A relative TTL specifies the time to live in terms of the number of seconds elapsed since the value was obtained by the client from any handle server.
<TTL>値レコードの生存時間を指定する4バイトの整数が続くオクテットを。情報のソースが再度相談する必要があります前に、値レコードをキャッシュすることができますどのくらい記述するために使用されます。 TTLのゼロ値は、値のレコードがのみ進行中のトランザクションを使用する必要があり、キャッシュされるべきではないことを示しています。ゼロ以外のTTLはTTL値（TTL方式を以下32ビットの符号なし整数）、続いて（最初のオクテットで指定）TTL方式の観点で定義されています。 TTL方式は、TTL値が絶対的または相対的であるかどうかを示します。絶対TTL値が00:00:00からの秒の面で生活する時間を定義し、1月1日1970相対TTL値がクライアントからによって得られたから経過した秒数の面で生活する時間を指定します任意のハンドルサーバ。
<timestamp> An 8-byte (long) integer that records the last time the value was updated at the server. The field contains elapsed time since 00:00:00 UTC, January 1970 in milliseconds. The choice of milliseconds is to avoid potential collision when updating the value.
<タイムスタンプ>値は、サーバで更新された最後の時間を記録し、8バイト（ロング）整数。フィールド00:00:00 UTC、ミリ秒単位で1970年1月からの経過時間が含まれています。ミリ秒単位の選択は、値を更新する際に潜在的な衝突を避けるためです。
<reference> A 4-byte integer followed by a list of references to other handle values. The integer specifies the number of references in the list. Each reference in the list refers to another handle value in terms of a UTF8-string and a 4-byte integer (where the UTF8- string is the handle name and the integer is the value index). References are generally used to add credentials to the current handle value. For example, a handle value may make itself more trust-worthy by referring to a digital signature issued by a commonly trusted entity.
<基準> 4バイト整数は、他のハンドル値への参照のリストが続きます。整数は、リスト内の参照の数を指定します。リスト内の各参照は、UTF8文字列の点で別のハンドル値と4バイトの整数を指す（UTF8-ストリングは、ハンドル名であり、整数値の指数です）。参照は、一般的に、現在のハンドル値に資格情報を追加するために使用されています。例えば、ハンドル値自体は、より信頼に値する一般的に、信頼できるエンティティによって発行されたデジタル署名を参照することにより行うことができます。
By default, the Handle System returns all the handle values with public-read permission in response of any resolution request. It is possible for a client to ask for a subset of those values with specific data type (e.g., all URLs assigned to the handle). The client may also ask for a specific handle value based on a specific value index.
デフォルトでは、ハンドルシステムは、任意の解決要求の応答における公共読み込み許可を得て、すべてのハンドル値を返します。クライアントが特定のデータ型（例えば、ハンドルに割り当てられたすべてのURL）で、これらの値のサブセットをお願いすることが可能です。また、クライアントは、特定の値の指標に基づいて特定のハンドル値を求めることができます。
Each handle value can be uniquely referenced by the combination of the handle and its value index. Care must be taken when changing the value index as it may break an existing reference to the handle value. For example, suppose the handle X/Y has a value whose index is 1. That value may be referred to as X/Y:1. If the handle administrator changes the value index from 1 to 2, the reference to X/Y:1 will become obsolete. Any reference to the handle value will have to change to X/Y:2.
各ハンドル値は、一意のハンドルと、その値のインデックスの組み合わせによって参照することができます。それはハンドル値への既存の参照を壊すこととして値インデックスを変更する場合は注意が必要です。 1：例えば、ハンドルX / Yは、その指標値がX / Yと呼ぶことができること1.値を有すると仮定する。ハンドル管理者が1から2に値のインデックスを変更した場合、X / Yを参照するには：1時代遅れになるだろう。ハンドル値への参照は、X / Yに変更する必要があります：2。
Value records assigned to any handle may or may not have continuous index numbers. Nor can it be assumed that the index will start with 0 or 1. A handle administrator may assign a handle value with any index as long as each index is unique within the value set.
任意のハンドルに割り当てられた値のレコードは、または連続インデックス番号を持っていない可能性があります。またインデックスが0または1で開始すると仮定することができる各インデックスが値セット内で一意である限り、任意のインデックスを持つハンドル値を割り当てることができるハンドル管理者。
A handle value may be "privatized" or "disabled" by setting its <permission> field as "authorized-read". This limits read-access to the handle administrator only. The "privatized" value can then be used to keep any historical data (on behalf of the handle administrator) without exposing it to public. Such approach may also be used to keep any obsolete handle or naming authority from being reused accidentally.
ハンドル値は「民営化」または「許可読み」としての<許可>フィールドを設定することで「無効」にすることができます。これは、ハンドルの管理者への読み取りアクセスを制限します。 「民営化」値は、公衆にそれをさらすことなく（ハンドル管理者に代わって）すべての履歴データを保持するために使用することができます。このようなアプローチはまた、誤って再利用されることから廃止されたハンドルまたは命名権威を維持するために使用することができます。
Every handle value must have a data type specified in its <type> field. The Handle System provides a type registration service that allows organizations to register new data types for their applications. Data types can be registered as handles under the naming authority "0.TYPE". For example, the URL data type is registered under the Handle System as the handle "0.TYPE/URL". The handle may have a handle value that refers to RFC1738 [9], an IETF standard document that defines the syntax and semantics of URL.
すべてのハンドル値は、その<タイプ>フィールドで指定したデータ型を持っている必要があります。ハンドルシステムは、組織がそのアプリケーション用の新しいデータ型を登録することができますタイプの登録サービスを提供します。データ型は、命名機関「0.TYPE」の下の取っ手として登録することができます。例えば、URLのデータ・タイプは、ハンドル「0.TYPE / URL」などのハンドルシステムの下で登録されています。ハンドルは、RFC1738を指すハンドル値[9]、URLの構文およびセマンティクスを定義するIETF標準文書を有していてもよいです。
The Handle System pre-defines a set of data types to carry out the handle service. For example, HS_ADMIN is a pre-defined data type used to describe handle administrators or administrator groups. HS_SITE is a pre-defined data type to describe the service interface of any Handle System service component. The following sections provide detailed descriptions of these pre-defined data types under the Handle System.
ハンドルシステムは、ハンドルのサービスを行うためのデータタイプのセットをあらかじめ定義しています。例えば、HS_ADMINハンドル管理者または管理者グループを記述するために使用される事前に定義されたデータ型です。 HS_SITEは、任意のハンドル・システム・サービス・コンポーネントのサービスインタフェースを記述するために事前に定義されたデータ型です。以下のセクションでは、ハンドル・システムの下で、これらの事前定義されたデータ型の詳細な説明を提供します。
Each handle has one or more administrators. Any administrative operation (e.g., add, delete or modify handle values) can only be performed by the handle administrator with adequate privilege. Handle administrators are defined in terms of HS_ADMIN values. Every handle must have at least one HS_ ADMIN value that defines its administrator. Each HS_ADMIN value can be used to define a set of handle administrators sharing the same administration privilege. Handles with multiple administrators of different privileges may have multiple HS_ADMIN values. HS_ADMIN values are used by the Handle System to authenticate handle administrators before fulfilling any handle administration request.
各ハンドルは、1人以上の管理者を持っています。任意の管理操作（例えば、追加、削除したり、ハンドルの値を変更）だけで十分な権限を持つハンドル管理者が実行することができます。ハンドルの管理者は、HS_ADMIN値で定義されています。すべてのハンドルは、その管理者を定義する少なくとも1つのHS_ ADMIN値を持っている必要があります。各HS_ADMIN値は、同じ管理権限を共有するハンドル管理者の集合を定義するために使用することができます。異なる権限の複数の管理者が複数のHS_ADMIN値を有することができるで処理します。 HS_ADMIN値は、任意のハンドル管理要求を満たす前に、ハンドルの管理者を認証するためにハンドルシステムで使用されています。
Naming authorities, as described above, are themselves registered as handles under the reserved naming authority "0.NA". These handles are referred to as naming authority handles. Administrators for any naming authority are defined as the administrators of the corresponding naming authority handle. For example, "0.NA/10" is the naming authority handle for the naming authority "10". Hence any administrator for the naming authority handle "0.NA/10" is also the administrator for the naming authority "10". Naming authority administrators are the only ones who can create handles or sub-naming authorities under the naming authority. A sub-naming authority may define its own set of administrators to create handles or further levels of sub-naming authorities. For example, the naming authority "10.1045" may have a totally different group of administrators from its parent naming authority "10".
上記のように命名当局は、予約済みの命名機関「0.NA」の下にハンドルとして自身が登録されています。これらのハンドルは、命名機関がハンドルと呼ばれています。任意の命名機関の管理者は、対応する命名機関ハンドルの管理者として定義されています。たとえば、「0.NA/10は、」命名機関「10」の命名権ハンドルです。したがって、命名機関ハンドル「0.NA/10」のいずれかの管理者は、命名機関「10」の管理者です。命名権限管理者は、命名機関の下にハンドルまたはサブ命名当局を作成することができる唯一のものです。サブ命名権威はハンドルまたはサブ命名当局の更なるレベルを作成するために、管理者の独自のセットを定義することができます。例えば、命名機関は「10.1045」は、親命名機関「10」から管理者の全く異なる基を有していてもよいです。
An HS_ADMIN value is a handle value whose <type> field is HS_ADMIN and whose <data> field consists of the following entries:
：HS_ADMIN値は、その<タイプ>フィールドはHS_ADMINあり、その<データ>フィールド次のエントリで構成されたハンドル値であり、
<AdminRef> A reference to a handle value. The reference consists of the handle name (a UTF8-string) followed by a 4-byte unsigned integer for the handle value index. The handle value identifies the set of administrators for the handle.
<AdminRef>ハンドル値を参照します。レファレンスハンドル値インデックスの4バイトの符号なし整数続いハンドルネーム（UTF8文字列）からなります。ハンドル値は、ハンドルのため、管理者のセットを識別する。
<AdminPermission> A 16-bit bit-mask that defines the administration privilege of the set of handle administrators identified by the HS_ADMIN value.
<AdminPermission> HS_ADMIN値によって識別ハンドル管理者のセットの管理権限を定義する16ビットのビットマスク。
The <AdminRef> entry refers to a handle value that can be used to authenticate the handle administrator. Such handle value is called the handle administrator reference. The handle administrator reference may contain the secret key, public key, or X.509 certificate [10] provided by the handle administrator. For example, the <AdminRef> entry may contain a handle administrator reference whose <type> field is DSS_WITH_DES_CBC_SHA and whose <data> field contains a DES secret key [11], for use in the Cipher Block Chaining (CBC) mode of operation [12, 13]. The secret key can be used by the handle server to authenticate the handle administrator. For stronger cryptographic algorithm, the handle administrator reference may contain a set of Triple-DES keys [23] and set its <type> to be DES-EDE3-WITH-CBC.
<AdminRef>エントリは、ハンドルの管理者を認証するために使用することができますハンドル値を参照します。このようなハンドル値は、ハンドルの管理者リファレンスと呼ばれています。ハンドル管理者の参照は、ハンドルの管理者から提供された秘密鍵、公開鍵、またはX.509証明書[10]を含んでいてもよいです。例えば、<AdminRef>エントリは、その<タイプ>フィールドを持つ<データ> DSS_WITH_DES_CBC_SHAとなるフィールドが操作の暗号ブロック連鎖（CBC）モードで使用するためのDES秘密鍵[11]、[含まれているハンドルの管理者リファレンスを含んでいてもよいです12、13]。秘密鍵は、ハンドルの管理者を認証するためにハンドルサーバで使用することができます。より強力な暗号化アルゴリズムのために、ハンドル管理基準はトリプルDES鍵[23]のセットを含み、DES-EDE3-WITH-CBCであるために、その<タイプ>を設定してもよいです。
A single handle may be assigned with both the HS_ADMIN value and the handle administrator reference. In other words, the <AdminRef> entry may refer to a handle value assigned to the same handle that has the HS_ADMIN value. In this case, authentication of the handle administrator does not rely on any other handles. Alternatively, the handle administrator reference may be a handle value under a different handle. Thus HS_ADMIN values from different handles may share a common handle administrator reference. This feature allows sharing of handle administrators among different handles. The handle administrator reference contains the secret key, public key, or X.509 certificate provided by the administrator of these handles.
単一のハンドルはHS_ADMIN値とハンドル管理者基準の両方に割り当てることができます。換言すれば、<AdminRef>エントリがHS_ADMIN値が同じハンドルに割り当てられたハンドル値を参照することができます。この場合、ハンドルの管理者の認証は、他のハンドルに依存しません。代替的に、ハンドル管理者参照は異なるハンドル下ハンドル値であってもよいです。したがって、異なるハンドルからHS_ADMIN値は、共通のハンドル管理者リファレンスを共有することができます。この機能は、異なるハンドルの間でハンドル管理者の共有を可能にします。ハンドル管理者の参照は、秘密鍵、公開鍵、またはこれらのハンドルの管理者から提供されたX.509証明書が含まれています。
Handle administrator reference may be of type HS_VLIST and has its <data> field contain a list of references to other handle values. Each of these handle values defines a handle administrator reference. The HS_VLIST value defines an administrator group. Each handle administrator reference from the HS_VLIST is a member of the administrator group. Each handle value reference is defined in terms of a <handle>:<index> pair. An administrator group may also contain other administrator groups as its members. This allows administrator groups to be defined in a hierarchical fashion. Care must be taken, however, to avoid cyclic definition of administrators or administrator groups. Multiple levels of administrator groups should be avoided due to their lack of efficiency, but will not be signaled as an error. Client software should be prepared to detect any potential cyclic definition of administrators or <AdminRef> entries that point to non-existent handle values and treat them as an error.
管理者の参照はタイプHS_VLISTのものであってもよいし、その<データ>フィールドは、他のハンドル値への参照のリストが含まれていたハンドル。これらのハンドル値のそれぞれは、ハンドルの管理者リファレンスを定義します。 HS_VLIST値は、管理者グループを定義します。 HS_VLISTから各ハンドルの管理者リファレンスは、管理者グループのメンバーです。 <インデックス>ペア：各ハンドル値の参照は、<ハンドル>で定義されています。管理者グループもそのメンバーとして、他の管理者グループが含まれていてもよいです。これは、管理者グループは階層的に定義することができます。ケアは、管理者または管理者グループの巡回定義を避けるために、しかし、注意しなければなりません。管理者グループの複数レベルが原因効率の欠如に避ける必要がありますが、エラーとして通知されることはありません。クライアントソフトウェアは、任意の潜在的な巡回管理者の定義または存在しないハンドル値を指す<AdminRef>エントリを検出し、エラーとして扱うように準備されるべきです。
A handle can have multiple HS_ADMIN values, each of which defines a different handle administrator. Different administrators can play different roles or be granted different permissions. For example, the naming authority handle "0.NA/10" may have two administrators, one of which may only have permission to create new handles under the naming authority, while the other may have permission to create new sub-naming authorities (e.g., "10.1045"). The set of possible permissions for a handle administrator is defined as follows:
ハンドルは、異なるハンドル管理者を定義し、それぞれが複数のHS_ADMIN値を有することができます。別の管理者が異なる役割を再生することができ、または異なるアクセス権を付与します。例えば、命名機関ハンドル「0.NA/10は、」他の新しいサブ命名当局を作成する権限を持っているかもしれないが唯一、命名機関の下に新しいハンドルを作成する権限を有していてもよくそのうちの一つ、2つの管理者、（例えばを有することができます、 "10.1045"）。次のようにハンドルの管理者のための可能なアクセス権のセットが定義されます。
Add_Handle (0x0001) This permission allows naming authority administrator to create new handles under a given naming authority.
Add_Handle（0x0001に）この許可は与えられた命名機関の下に新しいハンドルを作成する権限を管理者に名前を付けることができます。
Delete_Handle (0x0002) This permission allows naming authority administrator to delete handles under a given naming authority.
Delete_Handle（0×0002）この許可は与えられた命名権限の下でハンドルを削除する権限を管理者に名前を付けることができます。
Add_NA (0x0004) This permission allows the naming authority administrator to create new sub-naming authorities.
Add_NAは（0x0004は）この許可は、命名機関の管理者は、新しいサブ命名当局を作成することができます。
Delete_NA (0x0008) This permission allows naming authority administrator to delete an existing sub-naming authority.
Delete_NA（0x0008で）この許可は、既存のサブ命名権限を削除する権限を管理者に名前を付けることができます。
Modify_Value (0x0010) This permission allows handle administrator to modify any handle values other than HS_ADMIN values. HS_ADMIN values are used to define handle administrators and are managed by a different set of permissions.
Modify_Value（0x0010）この許可は、ハンドルの管理者がHS_ADMIN値以外のハンドル値を変更することができます。 HS_ADMIN値は、ハンドルの管理者を定義するために使用されており、権限の異なるセットによって管理されています。
Delete_Value (0x0020) This permission allows handle administrator to delete any handle value other than the HS_ADMIN values.
DELETE_VALUE（0x0020に）この許可は、ハンドルの管理者がHS_ADMIN値以外のハンドル値を削除することができます。
Add_Value (0x0040) This permission allows handle administrator to add handle values other than the HS_ADMIN values.
Add_Value（0x0040が）この許可は、ハンドルの管理者がHS_ADMIN値以外のハンドル値を追加することができます。
Modify_Admin (0x0080) This permission allows handle administrator to modify HS_ADMIN values.
Modify_Admin（0x0080）この許可は、ハンドルの管理者がHS_ADMIN値を変更することができます。
Remove_Admin (0x0100) This permission allows handle administrator to remove HS_ADMIN values.
Remove_Admin（は0x0100）この許可はHS_ADMIN値を削除するには、管理者を扱うことができます。
Add_Admin (0x0200) This permission allows handle administrator to add new HS_ADMIN values.
Add_Admin（0x0200）この許可は、ハンドル管理者が新しいHS_ADMIN値を追加することができます。
Authorized_Read (0x0400) This permission grants handle administrator read-access to handle values with the ADMIN_READ permission. Administrators without this permission will not have access to handle values that require authentication for read access.
Authorized_Read（0x0400）この権限付与ハンドルの管理者は、読み取りアクセスをADMIN_READの許可を得て値を処理します。この権限のない管理者は、読み取りアクセスのための認証が必要な値を処理するためにアクセスすることができません。
LIST_Handle (0x0800) This permission allows naming authority administrator to list handles under a given naming authority.
LIST_Handle（0x0800で）この許可は与えられた命名権限の下でハンドルを一覧表示する権限を管理者に名前を付けることができます。
LIST_NA (0x1000) This permission allows naming authority administrator to list immediate sub-naming authorities under a given naming authority.
LIST_NA（0x1000番地）この許可は与えられた命名権限の下で即時サブ命名当局の一覧を表示する権限を管理者に名前を付けることができます。
Administrator permissions are encoded in the <AdminPermission> entry in the <data> field of any HS_ADMIN value. Each permission is encoded as a bit flag. The permission is granted if the flag is set to 1, otherwise it is set to 0.
管理者権限は、任意HS_ADMIN値の<データ>フィールド内の<AdminPermission>エントリに符号化されます。各許可は、ビットフラグとして符号化されます。フラグが1に設定されている場合、許可がそれ以外の場合は0に設定され、付与されます。
Figure 3.2.1 shows an example of HS_ADMIN value that defines an administrator for the naming authority handle "0.NA/10". In figure 3.2.1, a naming authority administrator is identified by an HS_ADMIN value assigned to the naming authority handle "0.NA/10". The administrator can be authenticated based on the handle value "0.NA/10":3, which is the handle value assigned to the naming authority handle "0.NA/10" and has its index set to 3. The handle value "0.NA/10":3 may contain the secret or public key used by the administrator. The administrator is granted permission to add, delete, or modify sub-naming authorities under "10", and add or delete handles directly under the naming authority. The administrator may also add, delete, or modify any handle values assigned to the naming authority handle except those HS_ADMIN values. In other words, the administrator is not allowed to add, delete, or modify any administrators for the naming authority.
図3.2.1は、命名機関ハンドル「0.NA/10」の管理者を定義するHS_ADMIN値の一例を示しています。図3.2.1では、命名機関の管理者は、命名機関ハンドル「0.NA/10」に割り当てられたHS_ADMIN値によって識別されます。管理者は、0.NA/10「命名権威ハンドルに割り当てられたハンドル値である0.NA/10":3、 『』とそのインデックスはハンドル値3に設定されている」ハンドル値に基づいて認証することができます0.NA/10":3は、管理者によって使用される秘密または公開鍵が含まれていてもよいです。管理者は、追加、削除、または「10」の下にサブ命名当局を変更して、直接命名機関の下にハンドルを追加または削除する権限を付与されます。管理者は、追加、削除、またはそれらのHS_ADMIN値以外命名機関ハンドルに割り当てられた任意のハンドル値を変更することがあります。言い換えれば、管理者は、命名機関のための任意の管理者を追加、削除、または変更することはできません。
-------------------------------------------------------------
------------------------------------------------------------- |
------------------------------------------------------------- | |
| | | |
| <index>: 2 | | |
| <type>: HS_ADMIN | | |
| <data>: | | |
| <AdminRef>: "0.NA/10": 3 | | |
| <AdminPerm>: Add_NA, Delete_NA, | | |
| Add Handle, Delete_Handle, | | |
| Add_Value, Delete_Value, Modify_Value, | | |
| Authorized_Read, List_Handle, List_NA | | |
| | | |
| <TTL>: 24 hours | | |
| <permission>: PUBLIC_READ, ADMIN_WRITE | | |
| <reference>: {empty} | |-
| |-
-------------------------------------------------------------
Figure 3.2.1: Administrator for the naming authority
handle "0.NA/10"
HS_ADMIN values are used by handle servers to authenticate the handle administrator before fulfilling any administrative requests. The server authenticates a client by checking whether the client has possession of the secret key (or the private key) that matches the one in any of the handle administrator references. The authentication is carried out via the Handle System authentication protocol as described later in this document.
HS_ADMIN値は、任意の管理要求を満たす前に、ハンドルの管理者を認証するためにハンドルサーバによって使用されています。サーバーは、クライアントがハンドル管理者の参照のいずれかに1と一致する秘密鍵（または秘密鍵）の所有権を持っているかどうかを確認することでクライアントを認証します。本書で後述するように、認証は、ハンドル・システム認証プロトコルを介して行われます。
HS_ADMIN values may require authentication for read access in order to prevent public exposure of the data. Additionally, the handle administrator reference that contains the administrator's secret key should have neither PUBLIC_READ nor ADMIN_READ permission to prevent the key from leaving the server.
HS_ADMIN値は、データの公開露出を防ぐために、読み取りアクセスのための認証が必要な場合があります。また、管理者の秘密鍵が含まれているハンドルの管理者リファレンスは、サーバを残してからキーを防ぐためにもないPUBLIC_READもADMIN_READ権限を持っている必要があります。
The Handle System consists of a single distributed global handle service, also known as the Global Handle Registry (GHR), and unlimited number of Local Handle Services (LHSs). Each handle service, global or local, may be replicated into multiple service sites. Each service site may consist of multiple server computers. Service requests targeted at any handle service can be distributed into different service sites, and into different server computers within any service site. Such architecture assures that each handle service could have the capacity to manage any large number of handles and handle requests. It also provides ways for each handle service to avoid any single point of failure.
ハンドルシステムはまた、グローバルハンドルレジストリ（GHR）、およびローカルハンドルサービス（LHSS）の無制限の数として知られている単一の分散グローバルハンドルサービス、から構成されています。グローバルまたはローカルの各ハンドルサービスは、複数のサービスサイトに複製することができます。各サービスサイトでは、複数のサーバコンピュータで構成することができます。任意のハンドルサービスを対象としたサービス要求は異なるサービスサイトへの、および任意のサービスサイト内の異なるサーバーコンピュータに配布することができます。このようなアーキテクチャでは、各ハンドルサービスがハンドルの任意の多数を管理し、要求を処理する能力を持つことができることを保証します。また、単一障害点を回避するために、各ハンドルサービスのための方法を提供しています。
Each handle service, global or local, may provide the same set of functions for resolving and administering its collection of handles. Handle services differ primarily in that each service is responsible for a distinct set of handles. They are also likely to differ in the selection, number, and configuration of their components such as the servers used to provide handle resolution and administration. Different handle services may be created and managed by different organizations. Each of them may have their own goals and policies.
各ハンドルサービスは、グローバルまたはローカル、ハンドルのコレクションを解決し、管理するための機能の同じセットを提供することができます。ハンドルのサービスは、各サービスがハンドルの明確なセットのために責任があるということで主に異なります。彼らは、このようなハンドルの解像度と管理を提供するために使用するサーバとしても、その部品の選択、数、および設定が異なる可能性があります。異なるハンドルサービスは、異なる組織によって作成および管理することができます。それらのそれぞれが、自分の目標や方針を有していても良いです。
A service site typically consists of a cluster of server computers residing within a local Internet domain. These computers work together to distribute the data storage and processing load at the site. It is possible, although not recommended, to compose a site from servers at widely different locations. Further, it is even possible to compose two different sites from the same set of servers.
サービスサイトは、通常、ローカルインターネットドメイン内に存在するサーバコンピュータのクラスタで構成されています。これらのコンピュータは、サイトのデータストレージおよび処理負荷を分散するために一緒に働きます。これは、広く異なる場所でのサーバーからサイトを構成するために、推奨されていないが、可能です。さらに、サーバの同じセットから、2つの異なるサイトを構成することも可能です。
Each service site is defined by an HS_SITE value. HS_SITE is a pre-defined Handle System data type. An HS_SITE value defines a service site by identifying the server computers (e.g., IP addresses) that comprise the site along with their service configurations (e.g., port numbers). HS_SITE values are typically assigned to naming authority handles. The set of HS_SITE values assigned to a naming authority handle is called the service information for the naming authority.
各サービスサイトはHS_SITE値によって定義されます。 HS_SITEは、事前定義されたハンドルシステムのデータ型です。 HS_SITE値は、それらのサービスの構成（例えば、ポート番号）と一緒にサイトを含むサーバーコンピュータ（例えば、IPアドレス）を識別することによって、サービスサイトを定義します。 HS_SITE値は、一般的に権威のハンドルを命名に割り当てられます。命名機関ハンドルに割り当てられたHS_SITE値のセットは、命名機関のためのサービス情報と呼ばれています。
The service information is managed by the naming authority administrator. It must reflect the configuration of the handle service for the naming authority. Note that an additional layer of indirection, called a service handle, can be used to allow multiple naming authorities to reference a single set of HS_SITE values, as described later in this document (see section 3.2.3). Clients of the Handle System depend on the service information to locate the responsible handle server before they can send their service requests. The service information can also be used by clients to authenticate any service response from the handle server.
サービス情報は、命名機関の管理者によって管理されています。これは、命名機関のためのハンドルサービスの構成を反映する必要があります。本書で後述するように間接の追加の層が、サービス・ハンドルと呼ばれることに注意し、複数の命名当局はHS_SITE値の単一のセットを参照することを可能にするために使用することができる（セクション3.2.3を参照）。ハンドルシステムのクライアントは、彼らが彼らのサービス要求を送信することができます前に、責任ハンドルサーバーを見つけるために、サービス情報に依存します。サービス情報はまた、ハンドルサーバから任意のサービス応答を認証するためにクライアントが使用することができます。
An HS_SITE value is a handle value whose <type> field is HS_SITE and whose <data> field consists of the following entries:
：HS_SITE値は、その<タイプ>フィールド<データ>フィールド次のエントリで構成さHS_SITEとあるハンドル値であります
<Version> A 2-byte value that identifies the version number of the HS_SITE. The version number identifies the data format used by the HS_SITE value. It is defined to allow backward compatibility over time. This document defines the HS_SITE with version number 0.
<バージョン> HS_SITEのバージョン番号を識別する2バイトの値。バージョン番号はHS_SITE値によって使用されるデータ形式を識別する。時間をかけて、下位互換性を許可するように定義されています。このドキュメントでは、バージョン番号が0でHS_SITEを定義します。
<ProtocolVersion> A 2-byte integer value that identifies the handle protocol version. The higher byte of the value identifies the major version and the lower byte the minor version. Details of the Handle System protocol is specified in [8].
<はprotocolVersion>ハンドル・プロトコル・バージョンを識別する2バイトの整数値。値の上位バイトはメジャーバージョンと下位バイトのマイナーバージョンを識別します。ハンドル・システム・プロトコルの詳細は、[8]で指定されています。
<SerialNumber> A 2-byte integer value that increases by 1 (and may wrap around through 0) each time the HS_SITE value gets changed. It is used in the Handle System protocol to synchronize the HS_SITE values between client and server.
<のSerialNumber> HS_SITE値が変更されますたびに1ずつ増加する（0を介してラップアラウンドしてもよい）、2バイトの整数値。クライアントとサーバの間HS_SITE値を同期させるためにハンドルシステムのプロトコルで使用されています。
<PrimaryMask> An 8-bit mask that identifies the primary site(s) of the handle service. The first bit of the octet is the <MultiPrimary> bit. It indicates whether the handle service has multiple primary sites. The second bit of the octet is the <PrimarySite> bit. It indicates whether the HS_SITE value is a primary site. A primary site is the one that supports administrative operations for its handles. A <MultiPrimary> entry with zero value indicates that the handle service has a single primary site and all handle administration has to be done at that site. A non-zero <MultiPrimary> entry indicates that the handle service has multiple primary sites. Each primary site may be used to administrate handles managed under the handle service. Handles managed by such service may identify its primary sites using an HS_PRIMARY value, as described in section 3.2.5.
<PrimaryMask>ハンドルサービスの主要部位（単数または複数）を識別する8ビットのマスク。オクテットの最初のビットは<多>ビットです。これは、ハンドルサービスが複数のプライマリサイトを持っているかどうかを示します。オクテットの第2ビットは、<PrimarySite>ビットです。それはHS_SITE値がプライマリサイトであるかどうかを示します。プライマリサイトは、そのハンドルのための管理操作をサポートするものです。ゼロの値を持つ<多>エントリは、ハンドルサービスは、単一のプライマリ・サイトを持っており、すべてのハンドルの投与は、そのサイトで行わなければならないことを示しています。非ゼロ<多>エントリは、ハンドルサービスが複数のプライマリサイトを持っていることを示しています。各プライマリサイトは、ハンドルのサービスで管理ハンドルを管理するために使用することができます。セクション3.2.5に記載したように、このようなサービスによって管理されるハンドルは、HS_PRIMARY値を使用して、プライマリサイトを識別することができます。
<HashOption> An 8-bit octet that identifies the hash option used by the service site to distribute handles among its servers. Valid options include HASH_BY_NA (0x00), HASH_BY_LOCAL (0x01), or HASH_BY_HANDLE (0x02). These options indicate whether the hash operation should only be applied to the naming authority portion of the handle, or only the local name portion of the handle, or the entire handle, respectively. The standard MD5 hashing algorithm [14] is used by each service site to distribute handles among its servers.
<HashOption>そのサーバ間でハンドルを配布するサービスサイトで使用されるハッシュオプションを識別する8ビットのオクテット。有効なオプションはHASH_BY_NA（0x00の）、HASH_BY_LOCAL（0×01）、又はHASH_BY_HANDLE（0×02）を含みます。これらのオプションは、ハッシュ操作のみをそれぞれ、ハンドルの命名機関の一部、または唯一のハンドルのローカル名部分、またはハンドル全体に適用されるべきかどうかを示します。標準のMD5ハッシュアルゴリズム[14]は、そのサーバ間でハンドルを配布するために、各サービスサイトで使用されています。
<HashFilter> An UTF8-string entry reserved for future use.
将来の使用のために予約<HashFilter> UTF8文字列エントリ。
<AttributeList> A 4-byte integer followed by a list of UTF8-string pairs. The integer indicates the number of UTF8-string pairs that follow. Each UTF8-string pair is an <attribute>:<value> pair. They are used to add literal explanations of the service site. For example, if the <attribute> is "Organization", the <value> should contain a description of the organization hosting the service site. Other <attribute>s may be defined to help distinguish the service sites from each other.
UTF8文字列ペアのリストが続く<たAttributeList> 4バイト整数。整数が続くUTF8文字列のペアの数を示します。各UTF8文字列のペアは<属性>：<値>のペア。彼らは、サービスサイトの文字通りの説明を追加するために使用されています。たとえば、<属性>は、「組織」、<value>はサービスサイトをホスティングしている組織の記述が含まれている必要があります。その他の<属性> sが互いにサービスサイトを区別しやすくするために定義することができます。
<NumOfServer> A 4-byte integer that defines the number of servers in the service site. The entry is followed by a list of <ServerRecord>s. Each <ServerRecord> defines a handle server that is part of the service site. Each <ServerRecord> consists of the following data fields:
<NumOfServer>サービスサイト内のサーバーの数を定義する4バイトの整数。エントリは、<ServerRecord>のリストが続いています。各<ServerRecord>は、サービスサイトの一部であるハンドルサーバを定義します。各<ServerRecord>は、次のデータフィールドで構成されています。
<ServerRecord> ::= <ServerID>
<Address> <PublicKeyRecord> <ServiceInterface>
where each field is defined as follows:
次のように各フィールドが定義されます：
<ServerID>
A 4-byte unsigned integer that uniquely identifies a server
process under the service site. <ServerID>s do not have to
begin with 1 and they don't have be consecutive numbers. They
are used to distinguish servers under a service site from each
other. Note that there can be multiple servers residing on any
given computer, each with a different <ServerID>.
<Address> The 16-byte IPv6 [15, 16] address of the handle server. Any IPv4 address should be presented as :::::FFFF:xxxx:xxxx (where xxxx:xxxx can be any 4-byte IPv4 address).
<住所> 16バイトのIPv6 [15、16]ハンドルサーバのアドレス。 XXXX：XXXX（XXXX：XXXXができる任意の4バイトのIPv4アドレス）任意のIPv4アドレスとして::::: FFFF提示されるべきです。
<PublicKeyRecord> A 4-byte integer followed by a byte-array that contains the server's public key. The integer specifies the size of the byte-array. The byte-array (for the publickey) consists of three parts: a UTF8-string that describes the key type, a two-byte option field reserved for future use, and a byte-array that contains the public key itself. For example, the UTF8- String "DSA_PUB_KEY" indicates that the <PublicKeyRecord> contains a DSA public key. The storage format of the DSA key in the byte-array could then be found from the handle "0.type/DSA_PUB_KEY". Public key in the <PublicKeyRecord> can be used to authenticate any service response from the handle server.
<PublicKeyRecord> 4バイトの整数は、サーバの公開鍵を含むバイト配列が続きます。整数は、バイト配列のサイズを指定します。キータイプ、将来の使用のために予約2バイトのオプションフィールド、および公開鍵自体が含まれているバイト配列を説明するUTF8文字列：（公開用）バイト配列は、3つの部分から構成されています。例えば、UTF8-文字列「DSA_PUB_KEYは、」<PublicKeyRecord>は、DSA公開鍵が含まれていることを示しています。バイト配列でDSAキーの保存形式は、ハンドル「0.type / DSA_PUB_KEY」から見つけることができます。 <PublicKeyRecord>での公開鍵は、ハンドルサーバから任意のサービス応答を認証するために使用することができます。
The <PublicKeyRecord> may also contain an X.509 certificate. This happens if the key type field contains the UTF8-String "CERT.X509". In this case, "CERT.X509" will map to the handle "0.TYPE/CERT.X509". The handle may contain information that describes the syntax and semantics of the public key or its certificate. Additional key type may also be registered (as handles under "0.TYPE") to further distinguish different kinds of X.509 certificates. For example, "CERT.X509.DSA" may be used to denote X.509 certificates that contain DSA public keys. If the key type field of a <PublicKeyRecord> declares "CERT.X509.DSA", the <PublicKeyRecord> must contain a X.509 certificate with a DSA public key in it."
<PublicKeyRecord>また、X.509証明書が含まれていてもよいです。キータイプフィールドはUTF8-文字列「CERT.X509」が含まれている場合に発生します。この場合は、「CERT.X509」ハンドル「0.TYPE / CERT.X509」にマップされます。ハンドルは、公開鍵や証明書の構文と意味を説明する情報が含まれていてもよいです。追加のキータイプは、また、X.509証明書の種類を区別するために（「0.TYPE」のハンドルとして）登録されていてもよいです。たとえば、「CERT.X509.DSA」DSA公開鍵が含まれているX.509証明書を示すために使用することができます。 <PublicKeyRecord>のキータイプフィールドが「CERT.X509.DSA」を宣言した場合は、<PublicKeyRecord>その中のDSA公開鍵とX.509証明書が含まれている必要があります。」
<ServiceInterface> ::= <InterfaceCounter>
* [ <ServiceType>
<TransmissionProtocol>
<PortNumber> ]
A 4-byte integer followed by an array of triplets consisting of <ServiceType, TransmissionProtocol, PortNumber>. The 4-byte integer specifies the number of triplets. Each triplet lists a service interface provided by the handle server. For each triplet, the <ServiceType> is an octet (as a bit mask) that specifies whether the interface is for handle resolution (0x01), handle administration (0x02), or both. The <TransmissionProtocol> is also an octet (as a bit mask) that specifies the transmission protocol. Possible transmission protocols include TCP (0x01), UDP (0x02), and HTTP (0x04). The
<サービス種別、TransmissionProtocol、ポート番号>からなるトリプレットの配列が続く4バイトの整数。 4バイト整数は、トリプレットの数を指定します。各トリプレットは、ハンドルサーバが提供するサービス・インターフェースを示しています。各トリプレットは、<サービス種別>インターフェイスは、ハンドル解像度（0×01）のためのものであるかどうかを指定する（ビットマスクとして）オクテットであり、投与（0×02）、またはその両方を扱います。 <TransmissionProtocol>は、伝送プロトコルを指定（ビットマスクとして）オクテットです。可能な伝送プロトコルは、TCP（0×01）、UDP（0×02）、およびHTTP（0x04を）が含まれます。ザ・
<PortNumber> is a 4-byte unsigned integer that specifies the port number used by the interface. The default port number is 2641.
<ポート番号>インターフェイスが使用するポート番号を指定する4バイトの符号なし整数です。デフォルトのポート番号は2641です。
Figure 3.2.2 shows an example of handle service site in terms of a HS_SITE value. The HS_SITE value is assigned to the naming authority handle "0.NA/10". The <PrimaryMask> indicates that it is the only primary site of the handle service. The site consists of three handle servers, as indicated in the <NumOfServer>. These servers provide handle resolution and administration service for every handle under the naming authority "10". The first server record (ServerID 0) shows two service interfaces, one for handle resolution and the other for handle administration. Each interface has its own port.
図3.2.2は、HS_SITE値の面でハンドルサービスサイトの一例を示しています。 HS_SITE値が命名機関ハンドル「0.NA/10」に割り当てられています。 <PrimaryMask>は、それがハンドルサービスの唯一の主要なサイトであることを示しています。 <NumOfServer>に示すように、サイトには、3台のハンドルサーバで構成されています。これらのサーバは、命名機関「10」の下のすべてのハンドル用ハンドル解像度および管理サービスを提供しています。最初のサーバーレコード（サーバID 0）は、2つのサービス・インターフェース、ハンドル投与用ハンドル解像度のための1つおよび他を示しています。各インターフェイスには、独自のポートを持っています。
Each server within a service site is responsible for a subset of handles managed by the handle service. Clients can find the responsible server by performing a common hash-operation. The hash-operation will first convert all ASCII characters in the handle into upper-case. It then applies the MD5 hashing upon the portion of the converted handle string (according to the <HashOption> entry). The result is a 16-byte integer. The absolute value of the integer will be divided by the number of servers (specified in the <NumOfServer> entry). The remainder is the sequence number (starting with zero) of the <ServerRecord> listed in the HS_SITE value. From the <ServerRecord>, clients can find the IP address of the handle server for their handle requests.
サービスサイト内の各サーバーは、ハンドルサービスによって管理ハンドルのサブセットを担当しています。クライアントは、共通のハッシュ演算を実行することによって、責任あるサーバーを見つけることができます。ハッシュ動作は、第1大文字にハンドル内のすべてのASCII文字を変換します。次に、（<HashOption>エントリに従って）変換ハンドル文字列の一部にハッシュMD5を適用します。結果は、16バイトの整数です。整数の絶対値が（<NumOfServer>エントリーで指定された）サーバーの数によって分割されます。残りは<ServerRecord> HS_SITE値に記載されているの（ゼロから始まる）配列番号です。 <ServerRecord>からは、クライアントが自分のハンドルを要求用のハンドルサーバのIPアドレスを見つけることができます。
------------------------------------------------------------
------------------------------------------------------------ |
----------------------------------------------------------- | |
| | | |
| <index>: 2 | | |
| <type>: HS_SITE | | |
| <data>: | | |
| Version: 0 | | |
| ProtocolVersion: 2.1 | | |
| SerialNumber: 1 | | |
| PrimaryMask: | | |
| MultiPrimary: FALSE | | |
| PrimarySite: TRUE | | |
| HashOption: HASH_BY_HANDLE | | |
| HashFilter: {empty UTF8-String} | | |
| AttributeList: 0 {followed by no attributes} | | |
| NumOfServer: 3 | | |
| {followed by a list of <ServerRecord>} | | |
| | | |
| ----------------------------------------- | | |
| ------------------------------------------ | | | |
| ------------------------------------------ || | | |
| | ServerID: 1 ||| | | |
| | Address: :FFFF:132.151.1.155 ||| | | |
| | PublicKeyRecord: HS_DSAKEY, iQCuR2R... ||| | | |
| | ServiceInterface ||| | | |
| | ServiceType: Resolution_Only ||| | | |
| | TransmissionProtocol: TCP & UDP ||| | | |
| | PortNumber: 2641 ||| | | |
| | ||| | | |
| | ServiceType: Admin only ||| | | |
| | TransmissionProtocol: TCP || | | |
| | PortNumber: 2642 | | | |
| ------------------------------------------ | | |
| | | |
| <TTL>: 24 hours | | |
| <permission>: PUBLIC_READ, ADMIN_WRITE | | |
| <reference>: {empty} | |-
| |-
-----------------------------------------------------------
Fig. 3.2.2: The primary service site for the naming authority "10"
図3.2.2：命名機関「10」の主なサービスサイト
The HS_NA_DELEGATE is a pre-defined Handle System data type. It has the exact same format as the HS_SITE value. Like HS_SITE values, HS_NA_DELEGATE values are used to describe service sites of a LHS.
HS_NA_DELEGATEは、事前定義されたハンドル・システム・データ・タイプです。それはHS_SITE値とまったく同じ形式です。 HS_SITE値と同様に、HS_NA_DELEGATE値がLHSのサービスサイトを記述するために使用されています。
HS_NA_DELEGATE values may be assigned to naming authority handles to designate naming authority administration to a LHS. A naming authority handle with a set of HS_NA_DELEGATE values indicates that all child naming authorities of the naming authority are managed by the LHS described by the HS_NA_DELEGATE values.
HS_NA_DELEGATE値がLHSに権限管理を命名指定する権限ハンドル命名に割り当てることができます。 HS_NA_DELEGATE値のセットと命名機関ハンドルは、命名機関の当局命名すべての子がHS_NA_DELEGATE値によって記述さLHSによって管理されていることを示しています。
For example, suppose the naming authority "foo.bar" decides to have its child naming authorities delegated to a LHS. To achieve this, one may assign the naming authority handle "0.NA/foo.bar" with a set of HS_NA_DELEGATE values that describes the LHS. The set of HS_NA_DELEGATE values indicate that the service information of any child naming authority of the "foo.bar", such as "foo.bar.baz", can be found by querying the naming authority handle "0.NA/foo.bar.baz" from the LHS.
例えば、命名機関「foo.bar」がその子の命名当局がLHSに委任したことを決定とします。これを達成するためには、LHSを説明HS_NA_DELEGATE値のセットと命名機関ハンドル「0.NA/foo.bar」を割り当てることができます。 HS_NA_DELEGATE値のセットは、命名機関ハンドル「0.NA/foo.barを照会することによって見つけることができる、そのような「foo.bar.baz」として、任意の子のサービス情報が「foo.bar」の権威を命名することを示していますLHSから.baz」。
Any handle service, global or local, can be defined in terms of a set of HS_SITE values. These HS_SITE values may be assigned directly to the relevant naming authority handle, or an additional level of indirection may be introduced through the use of service handles. A service handle may be thought of as a name for a handle service. It may be used to maintain the HS_SITE values for the handle service and referenced from a naming authority handle via a HS_SERV value. A HS_SERV value is a handle value whose <type> field is HS_SERV and whose <data> field contains the reference to the service handle. HS_SERV values are typically assigned to naming authority handles to refer clients to the responsible handle service.
グローバルまたはローカルの任意のハンドルサービスは、HS_SITE値のセットの観点から定義することができます。これらのHS_SITE値は、関連する命名機関ハンドルに直接割り当てることも、あるいは間接の追加レベルは、サービスハンドルを使用して導入することができます。サービス・ハンドルは、ハンドルのサービスの名前と考えることができます。ハンドルサービスのHS_SITE値を維持するために使用し、HS_SERV値を経由して命名機関ハンドルから参照することができます。 HS_SERV値は、その<タイプ>フィールドは<データ>フィールドは、サービス・ハンドルへの参照が含まHS_SERVとなるハンドル値です。 HS_SERV値は、一般的に責任を負うハンドルサービスにクライアントを参照する権限ハンドル命名に割り当てられます。
Use of service handle allows sharing of service information among multiple naming authorities. It also allows changes to service configuration (e.g., adding a new site) to be made in one place rather than in every naming authority handle involved. The mechanism may also be used to support service referral from one handle service to another for whatever reason.
サービス・ハンドルを使用すると、複数のネーミングの当局間のサービス情報の共有を可能にします。また、一箇所ではなく、すべての命名権威関与扱うになされるべき（新しいサイトを追加するなど、）サービス構成を変更することができます。メカニズムは、何らかの理由で別のハンドルサービスからサービスの紹介をサポートするために使用することができます。
A naming authority handle may have no more than one HS_SERV value assigned to it, otherwise it is an error. If a naming authority handle has both a list of HS_SITE values and an HS_SERV value, the HS_SITE values should be used as the service information for the naming authority.
命名機関ハンドルは、それ以外の場合はエラーになり、それに割り当てられていない以上1以下HS_SERV値を有することができます。命名機関ハンドルがHS_SITE値のリストとHS_SERV値の両方を持っている場合は、HS_SITE値は、命名機関のためのサービス情報として使用する必要があります。
Service handles can be registered under the reserved naming authority "0.SERV". Handles under "0.SERV" are managed by the GHR. For example, the service handle "0.SERV/123" may be created to maintain the service information for the handle service that manages handles under the naming authority "123" and any of its sub-naming authorities.
サービスのハンドルは、予約命名機関「0.SERV」の下に登録することができます。 「0.SERV」の下のハンドルは、GHRによって管理されています。例えば、サービス・ハンドル「0.SERV / 123」命名機関「123」とそのサブ命名当局のいずれかにハンドルを管理してハンドルサービスに関するサービス情報を維持するために作成することができます。
Similarly, a service handle "0.SERV/a.b.c" may be created to host the service information for the handle service that manages handles under the naming authority "a.b.c".
同様に、サービス・ハンドル「0.SERV / A.B.Cは、」命名機関「A.B.C」の下にハンドルを管理してハンドルサービスに関するサービス情報をホストするために作成することができます。
The use of service handles raises several special considerations. Multiple levels of service handle redirection should be avoided due to their lack of efficiency, but are not signaled as an error. Looped reference of service handles or HS_SERV values that point to non-existent service handles should be caught and error conditions passed back to the user.
サービスのハンドルの使用には、いくつかの特別な考慮事項が発生します。サービス・ハンドルのリダイレクトの複数レベルが原因効率の欠如に避けるべきであるが、エラーとして通知されていません。サービスのハンドルまたは存在しないサービスのハンドルを指すHS_SERV値のループ状の参照をキャッチしなければならないとエラー条件は、ユーザーに返し。
In practice, it is very possible that a digital object may have multiple names that will identify the object. The Handle System supports such feature via the pre-defined data type HS_ALIAS. An HS_ALIAS value is a handle value whose <type> field is HS_ALIAS and whose <data> field contains a reference to another handle. A handle with a HS_ALIAS value is an alias handle to the handle referenced in the HS_ALIAS value. An alias handle should not have any additional handle values other than HS_ALIAS or HS_ADMIN (for administration) values. This is necessary to prevent any inconsistency between a handle and its aliases.
実際には、デジタルオブジェクトは、オブジェクトを識別します複数の名前を持つことが非常に可能性があります。ハンドルシステムは、事前定義されたデータ型HS_ALIASを経由して、このような機能をサポートしています。 HS_ALIAS値は、その<タイプ>フィールドHS_ALIASであり、その<データ>フィールドは別のハンドルへの参照を含むハンドル値です。 HS_ALIAS値のハンドルはHS_ALIAS値で参照されるハンドルへのエイリアスハンドルです。エイリアスハンドルはHS_ALIASまたは値（投与用）HS_ADMIN以外の任意の追加のハンドル値を持つべきではありません。これは、ハンドルとその別名との間に矛盾がないようにする必要があります。
During a handle resolution, a client may get back an HS_ALIAS value. This indicates that the handle in question is an alias handle. The client may then retry the query against the handle specified in the HS_ALIAS value until final results are obtained.
ハンドル解像度の間に、クライアントはHS_ALIAS値を取り戻すことがあります。これは、問題のハンドルがエイリアスハンドルであることを示しています。最終的な結果が得られるまで、クライアントは、HS_ALIAS値で指定されたハンドルに対してクエリを再試行することがあります。
The use of alias handle introduces a number of special considerations. For example, multiple levels of aliases should be avoided for the sake of efficiency, but are not signaled as an error. Alias loops and aliases that point to non-existent handles should be caught and error conditions passed back to the user.
エイリアスハンドルの使用は、特別な考慮事項の数を導入しています。例えば、エイリアスの複数のレベルは、効率のために避けるべきであるが、エラーとしてシグナリングされません。エイリアスは、ループと、存在しないハンドルを指す別名がキャッチされなければならないとエラー条件がユーザーに戻され。
One potential use of alias handle would be to support the transfer of ownership of any named resource. When a resource identified by a handle transfers from one organization to another, a new handle for the resource may be created. To avoid inconsistency and any broken reference, the handle used before the ownership transfer may be changed into an alias handle and point its HS_ALIAS value to the newly created handle.
エイリアスハンドルの1つの潜在的な使用は、任意の名前付きリソースの所有権の移転を支援することです。リソースは、1つの組織から別の組織のハンドル転送で識別すると、リソースのための新しいハンドルが作成されることがあります。矛盾と壊れ参照を避けるために、所有権の移転の前に使用されるハンドルは、エイリアスハンドルに変更し、新たに作成されたハンドルにそのHS_ALIAS値を指すことができます。
HS_PRIMARY is a pre-defined data type used to designate the primary service sites for any given handle. A handle service with multiple primary service sites is called a multi-primary service. Otherwise it is called a single-primary service. Each handle managed by a multi-primary handle service may specify its primary service sites in terms of an HS_PRIMARY value. A HS_PRIMARY value is a handle value whose <type> field is HS_PRIMARY and whose <data> field contains a list of references to HS_SITE values. Each of these HS_SITE defines a primary service site for the handle.
HS_PRIMARYは、任意のハンドルのプライマリサービスサイトを指定するために使用される事前に定義されたデータ型です。複数のプライマリサービスサイトとハンドルサービスは、マルチプライマリサービスと呼ばれています。それ以外の場合は、シングルプライマリサービスと呼ばれています。それぞれHS_PRIMARY値の面で、その主要サービスサイトを指定することも多原色ハンドルサービスによって管理されるハンドル。 HS_PRIMARY値は、その<タイプ>フィールドは<データ>フィールドはHS_SITE値への参照のリストが含まれていHS_PRIMARYしているハンドル値です。これらHS_SITEのそれぞれは、ハンドルの主なサービスサイトを定義します。
There can be at most one HS_PRIMARY value assigned to each handle. Otherwise it is an error. A handle with no HS_PRIMARY value but managed by a multi-primary handle service is not an error. In this case, every primary service site of the handle service will also be the primary site for the handle. Handles managed by a single-primary handle service do not need any HS_PRIMARY values and any such values should be ignored.
各ハンドルに割り当てられた最大1つのHS_PRIMARY値が存在する場合があります。それ以外の場合はエラーです。多原色ハンドルサービスによって管理されていないHS_PRIMARY値を持つハンドルがなく、エラーではありません。この場合、ハンドルサービスのすべての主要サービスサイトはまた、ハンドルのための主要なサイトになります。シングルのプライマリハンドルサービスによって管理されるハンドルは、任意のHS_PRIMARY値を必要としないし、そのような値が無視されるべきです。
HS_VLIST is a pre-defined data type that allows a handle value to be used as a reference to a list of other handle values. An HS_VLIST value is a handle value whose <type> is HS_VLIST and whose <data> consists of a 4-byte unsigned integer followed by a list of references to other handle values. The integer specifies the number of references in the list. The references may refer to handle values under the same handle or handle values from any other handles. Each reference is encoded as an UTF8-string followed by a 4-byte unsigned integer that identifies the referenced handle and its value index.
HS_VLISTハンドル値が他のハンドル値のリストへの参照として使用することを可能にする事前定義されたデータ型です。 HS_VLIST値は、その<タイプ> HS_VLISTであり、その<データ>他のハンドル値への参照のリストに続く4バイトの符号なし整数で構成されたハンドル値です。整数は、リスト内の参照の数を指定します。参照は、同じハンドルの下に値を処理または任意の他のハンドルの値を処理するために参照することができます。各参照は、参照のハンドルと、その値のインデックスを特定する4バイトの符号なし整数続いUTF8文字列として符号化されます。
HS_VLIST values may be used to define administrator groups for handles. In this case, each reference in the HS_VLIST defines a member of the administrator group and the HS_VLIST value identifies the group as a whole. Client software must be careful, however, to avoid cyclic definition of value references.
HS_VLIST値はハンドルの管理者グループを定義するために使用することができます。この場合、HS_VLISTの各参照は、管理者グループのメンバーを定義しHS_VLIST値は、全体としてグループを識別する。クライアントソフトウェアは、値参照の巡回定義を避けるために、しかし、注意しなければなりません。
The Handle System is a distributed global name service. It consists of a single distributed Global Handle Registry (GHR) and unlimited number of Local Handle Services (LHS). These service components provide the name service (both resolution and administration) on behalf of Handle System client components. Handle System client components may also choose to use Handle System middle-ware components (e.g., the Handle System caching service) for efficiency. This section describes these components and their relationships to each other.
ハンドルシステムは、分散グローバルネームサービスです。これは、単一の分散グローバルハンドルレジストリ（GHR）とローカルハンドルサービス（LHS）の数は無制限で構成されています。これらのサービスコンポーネントは、ハンドルシステムのクライアントコンポーネントの代わりに、ネームサービス（解像度および投与の両方）を提供します。また、効率のためにハンドル・システムミドルウェアコンポーネント（例えば、ハンドル・システム・キャッシングサービス）を使用することを選択することができるシステムのクライアントコンポーネントを扱います。このセクションでは、これらのコンポーネントとそれらの相互関係を説明しています。
The Handle System defines a hierarchical service model. At the top level is the single distributed global handle service, also known as the Global Handle Registry (GHR). Underneath the GHR, there can be any number of Local Handle Services (LHSs). Each LHS must be registered with the GHR to manage handles under a distinct set of naming authorities. Naming authorities are managed by the GHR via naming authority handles (i.e., handles under the naming authority "0.NA"). A naming authority handle can also be used to locate the service information (in terms of HS_SITE values) that describes the handle service responsible for handles under the naming authority. From the service information, clients can choose a service site and locate the responsible server for their handle requests.
ハンドルシステムは、階層的なサービスモデルを定義します。トップレベルで、グローバルハンドルレジストリ（GHR）として知られている単分散グローバルハンドルサービス、です。 GHRの下に、ローカルハンドルサービス（LHSS）の数に制限はありません。各LHSは命名当局の明確なセットの下でハンドルを管理するために、GHRに登録する必要があります。命名当局は命名権威ハンドル（すなわち、命名機関「0.NA」の下にハンドル）を介してGHRによって管理されています。命名機関ハンドルはまた、命名機関の下にハンドルを担当するハンドルサービスを記述する（HS_SITE値の点で）サービス情報を見つけるために使用することができます。サービス情報から、クライアントは、サービスサイトを選択し、そのハンドルのリクエストを担当するサーバーを見つけることができます。
Handle System service components are scalable and extensible to accommodate any large amount of service load. A handle service, global or local, may consist of multiple service sites, replicating each other. Each service site may also consist of a cluster of computers working together to serve its respective namespace. Having multiple service sites avoids any single point of failure and allows load balancing among these service sites. Using multiple servers at any service site distributes the service load into multiple server processes and allows less powerful computers to be utilized for the name service.
ハンドルシステムサービスコンポーネントは、サービスの負荷の任意の多量を収容するためにスケーラブルで拡張可能です。グローバルまたはローカルハンドルサービスは、お互いを複製、複数のサービスサイトから構成されてもよいです。各サービスサイトでは、それぞれの名前空間を提供するために一緒に働くコンピュータのクラスタで構成することができます。複数のサービスサイトを持つことは、単一障害点を回避し、これらのサービスサイト間で負荷分散を可能にします。任意のサービスサイトに複数のサーバーを使用すると、複数のサーバプロセスにサービスの負荷を分散し、あまり強力なコンピュータは、ネームサービスのために利用することができます。
The Global Handle Registry (GHR) is mainly used to manage naming authority handles and to provide service information for every naming authority under the Handle System. The GHR may also be used to manage and provide resolution and administration service to non-naming-authority handles. Unlike any LHS, which mostly manages handles under a few naming authorities, the GHR is primarily used to register naming authorities and provide service information for every LHS. In other words, the GHR is the single root service that registers every LHS and provides their service information via the use of naming authority handle(s). Every naming authority under the Handle System must be registered under the GHR as a naming authority handle. The naming authority handle provides the service information of the handle service that manages all the handles under the naming authority. The service information may be provided in terms of a set of HS_SITE values, or an HS_SERV value that refers to a service handle, as described earlier.
グローバルハンドルレジストリ（GHR）は、主に命名権限ハンドルを管理し、ハンドルシステムの下で、すべての命名権限のためのサービス情報を提供するために使用されます。 GHRも管理し、非命名-権限ハンドルに解決し、管理サービスを提供するために使用することができます。主にいくつかの命名当局の下にハンドルを管理して任意のLHSとは異なり、GHRは主に命名当局に登録し、すべてのLHSのためのサービス情報を提供するために使用されます。言い換えれば、GHRは、すべてのLHSを登録し、権限ハンドル（複数可）の命名を使用することによって彼らのサービス情報を提供する単一のルートサービスです。ハンドルシステムの下ですべての命名権限は、命名機関ハンドルとしてGHRの下に登録する必要があります。命名機関ハンドルは、命名機関の下にすべてのハンドルを管理ハンドルサービスのサービス情報を提供します。前述したように、サービス情報は、HS_SITE値のセット、またはサービス・ハンドルを指すHS_SERV値の観点で提供されてもよいです。
The GHR may consist of multiple service sites, each described in a HS_SITE value. These HS_SITE values are assigned to the designated naming authority handle "0.NA/0.NA", also called the root handle. The root handle is the naming authority handle that maintains the service information for GHR. Top level naming authorities can only be created by administrators of the root handle.
GHRは、複数のサービスサイト、HS_SITE値に記載それぞれから成ることができます。これらのHS_SITE値もルートハンドルと呼ばれ、指定された命名権威ハンドル「0.NA/0.NA」に割り当てられています。ルートハンドルは、GHRのためのサービス情報を保持命名機関ハンドルです。トップレベルの命名当局は唯一のルートハンドルの管理者が作成することができます。
In order to communicate with the GHR, client software needs the GHR service information beforehand. The service information may be distributed initially with the client software, or obtained from some other secure sources (e.g., postal mail, secure web site, etc.). Client software may keep the service information to communicate with the GHR until the service information becomes expired (according to its TTL). The GHR must update its service information (assigned to the root handle) every time it changes its configuration. Client software with out-dated service information will be notified of the update every time it communicates with the GHR. The GHR must be maintained in such a way that any client software with out-dated GHR service information can still query the root handle for the latest update.
GHRと通信するためには、クライアント・ソフトウェアは、事前にGHRサービス情報を必要とします。サービス情報は、クライアントソフトウェアを最初に配布さ、または他の安全な情報源（例えば、郵便、セキュアなWebサイトなど）から得ることができます。サービス情報が期限切れになるまで、クライアントソフトウェアは、（そのTTLに従って）GHRと通信するためのサービス情報を保持することができます。 GHRは（ルートハンドルに割り当てられた）そのサービス情報がその構成を変更するたびに更新する必要があります。時代遅れのサービス情報とクライアントソフトウェアは、アップデートのそれはGHRと通信するたびに通知されます。 GHRは時代遅れGHRサービス情報を持つ任意のクライアントソフトウェアがまだ最新の更新のためのルートハンドルを照会できるように維持しなければなりません。
Fig. 4.1.1 shows the GHR service information in terms of a set of HS_SITE values. The GHR may consist of a number of service sites, each described in a HS_SITE value. The figure shows a GHR service site located in US East Coast, as indicated in the <AttributeList>.
図4.1.1は、HS_SITE値の組の点におけるGHRサービス情報を示しています。 GHRは、それぞれHS_SITE値に記載され、サービスサイトの数から構成されてもよいです。図には、<のAttributeList>に示したように、米国の東海岸に位置GHRサービスサイトを示しています。
------------------------------------------------------------
------------------------------------------------------------ |
----------------------------------------------------------- | |
| | | |
| <index>: 3 | | |
| <type>: HS_SITE | | |
| <data>: | | |
| Version: 1 | | |
| ProtocolVersion: 2.1 | | |
| SerialNumber: 1 | | |
| PrimaryMask: | | |
| MultiPrimary: TRUE | | |
| PrimarySite: TRUE | | |
| HashOption: HASH_BY_HANDLE | | |
| HashFilter: {empty UTF8-String} | | |
| AttributeList: 1 | | |
| Description: Service site at US East Coast | | |
| NumOfServer: 3 | | |
| | | |
| ------------------------------------------ | | |
| ------------------------------------------ | | | |
| ------------------------------------------ || | | |
| | ServerID: 1 ||| | | |
| | Address: :FFFF:132.151.2.150 ||| | | |
| | PublicKeyRecord: HS_DSAKEY, iQCuR2Rnw... ||| | | |
| | ServiceInterface ||| | | |
| | ServiceType: Resolution & Admin ||| | | |
| | TransmissionProtocol: TCP & UDP || | | |
| | PortNumber: 2641 | | | |
| ------------------------------------------ | | |
| | | |
| <TTL>: 24 hours | | |
| <permission>: PUBLIC_READ, ADMIN_WRITE | | |
| <reference>: {empty} | |-
| |-
-----------------------------------------------------------
Figure 4.1.1: GHR service information
図4.1.1：ホームサービス情報
The GHR and its service information provide an entry point for any client software to communicate with the Handle System. For any given handle, client software can query the GHR for its naming authority handle. This will return the service information of the LHS that manages every handle under the naming authority. The service information will direct the client software to the handle server within the LHS that manages the handle.
GHRとそのサービス情報は、ハンドルシステムと通信するために、任意のクライアントソフトウェアのエントリポイントを提供します。任意のハンドルの場合、クライアントソフトウェアは、その命名機関ハンドルのGHRを照会することができます。これは、命名機関の下にすべてのハンドルを管理LHSのサービス情報を返します。サービス情報は、ハンドルを管理LHS内のハンドルサーバにクライアントソフトウェアを指示します。
A Local Handle Services (LHS) manages handles under given sets of naming authorities. Each naming authority defines a "local" namespace that consists of all of the handles under the naming authority. Note that a LHS is not a "local" service in terms of any network topology. It is called a "Local" Handle Service because it typically manages a restricted (local) namespace.
ローカルハンドルサービス（LHS）が命名当局の特定のセットの下にハンドルを管理します。各命名機関は、命名機関の下にハンドルのすべてで構成され、「ローカル」の名前空間を定義します。 LHSは、任意のネットワークトポロジーの観点から「ローカル」サービスではないことに注意してください。それは一般的に制限された（ローカル）名前空間を管理しますので、それは「ローカル」ハンドル・サービスと呼ばれています。
A naming authority is "homed" at a LHS if all handles under the naming authority are managed by the LHS. A LHS may be home to multiple naming authorities. On the other hand, a naming authority may only be "homed" at one LHS. Note that a naming authority may also be homed at the GHR.
命名機関の下のすべてのハンドルがLHSによって管理されている場合は命名権威はLHSで、「ホーム」されます。 LHSは、複数の命名当局に家かもしれません。一方、命名機関は、唯一のLHSで「ホーム」することができます。命名機関もGHRでホームにすることができることに注意してください。
------------------------------------------------------------
------------------------------------------------------------ |
----------------------------------------------------------- | |
| <index>: 3 | | |
| <type>: HS_SITE | | |
| <data>: | | |
| Version: 1 | | |
| ProtocolVersion: 2.1 | | |
| SerialNumber: 1 | | |
| PrimaryMask: | | |
| MultiPrimary: FALSE | | |
| PrimarySite: TRUE | | |
| HashOption: HASH_BY_LOCALNAME | | |
| HashFilter: {empty UTF8-String} | | |
| AttributeList: 1 | | |
| Description: Local Service for "10" | | |
| NumOfServer: 2 | | |
| ----------------------------------------- | | |
| ----------------------------------------- | | | |
| | ServerID: 1 || | | |
| | Address: :FFFF:132.151.3.150 || | | |
| | PublicKeyRecord: HS_DSAKEY, iQCuR2R... || | | |
| | ServiceInteface: || | | |
| | ServiceType: Resolution & Admin || | | |
| | TransmissionProtocol: TCP & UDP || | | |
| | PortNumber: 2641 |' | | |
| -----------------------------------------' | | |
| <TTL>: 24 hours | | |
| <permission>: PUBLIC_READ, ADMIN_WRITE | |-
| <reference>: {empty} |-
-----------------------------------------------------------
Figure 4.1.2: LHS service information
図4.1.2：LHSサービス情報
Like the GHR, a LHS may also consist of many service sites with each site described by an HS_SITE value. The set of HS_SITE values for any LHS may be assigned to a service handle or to the relevant naming authority handle(s). Fig. 4.1.2 shows an example of HS_SITE values for a LHS. These HS_SITE values are assigned to the naming authority handle "0.NA/10". This suggests that the naming authority "10" is "homed" at the LHS specified in these HS_SITE values. Clients may query the GHR to obtain the service information in order to communicate with the LHS. Administrators of the naming authority handle are responsible for maintaining the service information and keeping it up to date.
GHRと同じように、LHSもHS_SITE値によって記述されている各サイトでの多くのサービスサイトから構成されてもよいです。任意のLHSのためHS_SITE値のセットは、サービス・ハンドルに関連するか、命名機関ハンドル（複数可）に割り当てることができます。図4.1.2は、LHS用HS_SITE値の一例を示しています。これらのHS_SITE値は、命名機関ハンドル「0.NA/10」に割り当てられています。これは、命名機関「10」はこれらHS_SITE値で指定されたLHSで「ホーム」されることを示唆しています。クライアントは、LHSと通信するためにサービス情報を取得するためにGHRを問い合わせることができます。命名機関ハンドルの管理者は、サービス情報を維持し、これまでにそれを維持する責任があります。
Note that a LHS may refer its clients to another LHS in response to a service request. This allows the LHS to further distribute its service in a hierarchical fashion.
LHSは、サービス要求に応じて、別のLHSに顧客を参照することがあります。これはLHSはさらに階層的にそのサービスを配布することができます。
Handle System middle-ware components currently include Handle System caching servers and Handle System proxy servers. These Handle System middle-ware components are clients to Handle System service components, but servers to Handle System client software. Handle System middle-ware components are used to provide additional interfaces to the basic handle service. For example, a Handle System caching server may be used to share resolution results within a local community. Additionally, a Handle System proxy server can be used to bypass any organizational firewall via HTTP tunneling.
システムミドルウェアコンポーネントは、現在ハンドルシステムのキャッシュサーバが含まれており、システムのプロキシサーバをハンドルハンドル。これらのハンドルシステムミドルウェア・コンポーネントは、システムのクライアントソフトウェアを処理するために、システムのサービス・コンポーネントを処理するために、クライアントが、サーバです。ハンドルシステムミドルウェアコンポーネントは、基本的なハンドルサービスに追加のインターフェイスを提供するために使用されます。例えば、ハンドル・システム・キャッシング・サーバは、地域内の分解能結果を共有するために使用されてもよいです。また、ハンドルシステムプロキシサーバーは、HTTPトンネリングを経由して任意の組織のファイアウォールをバイパスするために使用することができます。
Handle System caching service can be used to reduce the network traffic between Handle System clients and servers. Caching handle data, including the service information of any LHS, allows re-use of information obtained from earlier queries.
ハンドルシステムのキャッシングサービスは、ハンドルシステムのクライアントとサーバー間のネットワークトラフィックを軽減するために使用することができます。任意LHSのサービス情報を含むキャッシュ・ハンドルデータは、以前のクエリから取得した情報の再利用を可能にします。
Each handle value contains a <TTL> (Time to Live) field that tells a caching service how long the cached value may be regarded as valid. A zero-value TTL indicates that the value can only be used for the transaction in progress and should not be cached. A caching service may obtain its data directly from a handle service, or from another caching service that eventually gets its data from the handle service.
各ハンドル値は、キャッシュされた値が有効であるとみなすことができるどのくらいのキャッシングサービスを告げる<TTL>（生存時間）フィールドが含まれています。ゼロ値のTTL値のみ進行中のトランザクションのために使用することができ、キャッシュされるべきでないことを示しています。キャッシングサービスは、ハンドルサービスから、または最終的にハンドルサービスからデータを取得する別のキャッシングサービスから直接データを取得してもよいです。
A caching service may be defined in terms of an HS_SITE value and may consist of multiple caching servers. For any given handle, clients can find the responsible caching server within the caching service by using the same hashing algorithm as used in locating the handle server within any handle service.
キャッシングサービスはHS_SITE値の観点で定義されてもよいし、複数のキャッシュサーバから構成されてもよいです。任意のハンドルのために、クライアントは任意のハンドルサービス内でハンドル・サーバーの位置で使用したのと同じハッシュアルゴリズムを使用してキャッシングサービス内で責任をキャッシュサーバを見つけることができます。
Caching services are not part of any Handle System administration or authentication hierarchy. The Handle System protocol does not authenticate any response from a caching service. Clients are responsible to set up their trust relationship with the caching service that they select. They will also rely on the caching service to properly authenticate any response from any handle server.
キャッシングサービスは、任意のハンドルシステムの管理や認証階層の一部ではありません。ハンドルシステムのプロトコルは、キャッシングサービスからの応答を認証しません。クライアントは、彼らが選択するキャッシングサービスとの信頼関係を設定する責任があります。彼らはまた、適切に任意のハンドルサーバからの応答を認証するためにキャッシングサービスに依存しています。
Handle System proxy servers can be used to enable handle resolution via other Internet protocols. For example, CNRI has built and made available a Handle System HTTP Proxy Server that will process any handle resolution in terms of HTTP protocol. The current DNS address for the proxy server is at "hdl.handle.net". The proxy server allows any handle to be resolved via a HTTP URL. The URL can be constructed as "http://hdl.handle.net/<handle>", where <handle> can be any handle from the Handle System. For example, the handle "ncstrl.vatech_cs/tr-93-35" can be resolved via the HTTP URL "http://hdl.handle.net/ncstrl.vatech_cs/tr-93-35" from any web browser. In this case, the URL is sent to the proxy server in terms of a HTTP request. The proxy server will query the Handle System for the handle data and return the results in terms of HTTP response.
ハンドルシステムプロキシサーバーは、他のインターネット・プロトコルを経由してハンドルの解像度を有効にするために使用することができます。例えば、CNRIは構築されており、HTTPプロトコルの観点から任意のハンドルの解像度を処理するハンドルシステムHTTPプロキシサーバ利用できるようにしました。プロキシサーバの現在のDNSアドレスは「hdl.handle.net」です。プロキシサーバーは、任意のハンドルがHTTPのURLを経由して解決することができます。 URLは「http://hdl.handle.net/ <ハンドル>」、ここで<ハンドル>として構成することができるハンドルシステムから任意のハンドルすることができます。例えば、ハンドル「ncstrl.vatech_cs / TR-93から35には、」任意のWebブラウザからのHTTP URL「http://hdl.handle.net/ncstrl.vatech_cs/tr-93-35」を介して解決することができます。この場合、URLはHTTPリクエストの面でプロキシサーバに送信されます。プロキシサーバーはハンドルデータ用ハンドルシステムを照会し、HTTPレスポンスの面で結果を返します。
Using HTTP URLs allows handles to be resolved from standard web browsers without any additional client software. However, such reference to the handle also ties itself to the proxy server. If the proxy server changes its DNS name or otherwise becomes invalid, the reference (i.e., the HTTP URL) to the handle will break. Thus the selection or use of proxy server should be carefully evaluated.
HTTP URLを使用すると、ハンドルは、追加のクライアントソフトウェアを使用せず、標準のWebブラウザから解決することができます。しかし、ハンドルに、このような言及はまた、プロキシサーバーに自分自身を結びつけます。プロキシサーバがそのDNS名を変更するか、そうでない場合は無効になると、ハンドルへの参照（すなわち、HTTPのURL）が解除されます。このように選択またはプロキシサーバーの使用は慎重に評価する必要があります。
Proxy servers are not part of any Handle System administration or authentication hierarchy. The Handle System protocol does not authenticate any response from a proxy server. Clients are responsible to set up their trust relationship with the proxy server that they select. They will also rely on the proxy server to properly authenticate any response from any handle server.
プロキシサーバーは、任意のハンドルシステムの管理や認証階層の一部ではありません。ハンドルシステムのプロトコルは、プロキシサーバーからの応答を認証しません。クライアントは、彼らが選択したプロキシサーバとの信頼関係を設定する責任があります。彼らはまた、適切に任意のハンドルサーバからの応答を認証するために、プロキシサーバーに依存しています。
Handle System client components are client software that communicates with the Handle System service components. Client software may speak the Handle System protocol and send its request directly to a service component. The response from the service component may be the final answer to the request, or a referral to another service component. The client software will have to follow the referral in order to complete the transaction.
ハンドルシステムのクライアントコンポーネントは、ハンドルシステムサービスコンポーネントと通信するクライアントソフトウェアです。クライアントソフトウェアは、ハンドルシステムのプロトコルを話し、サービス・コンポーネントに直接その要求を送信することができます。サービスコンポーネントからの応答は、要求に最終的な答え、または別のサービス・コンポーネントへの参照であってもよいです。クライアントソフトウェアは、トランザクションを完了するために、紹介を追跡する必要があります。
Client software may also be configured to tunnel its request via a middle-ware component. The middle-ware component will thus be responsible for obtaining the final result and returning it to the client. Unlike service components, middle-ware components will only return final results of client's request. No service referral will be returned from middle-ware components.
クライアントソフトウェアは、ミドルウェアコンポーネントを介してトンネルその要求に構成されてもよいです。ミドルウェア・コンポーネントは、最終的な結果を得て、それをクライアントに返すための責任を負うことになります。サービスコンポーネントとは異なり、ミドルウェアコンポーネントは、クライアントの要求の最終結果を返します。いいえ、サービスの紹介は、ミドルウェアコンポーネントから返されません。
Various Handle System client components may be developed for various applications. The CNRI Handle System Resolver [17] is one such component. The resolver extends web browsers (e.g., Netscape or Microsoft Internet Explorer) in such a way that handles can be resolved directly in terms of "hdl:" Uniform Resource Identifiers (URIs). The Grail web browser [18], a freely downloadable software developed in Python [19], also supports the "hdl:" URI scheme and will resolve handles accordingly. For example, the handle "10.1045/july95-arms" may be resolved by entering its handle URI as "hdl:10.1045/july95-arms" into any of these resolver-enabled browsers. Details of the handle URI syntax will be specified in a separate document.
さまざまなハンドルシステムのクライアントコンポーネントは、様々な用途のために開発することができます。 CNRIはシステムリゾルバハンドル[17]そのような構成要素です。ユニフォームリソース識別子（URI）：リゾルバは、ハンドルは、「HDL」の用語で直接解決することができるような方法でWebブラウザ（例えば、NetscapeまたはMicrosoft Internet Explorerを）拡張します。グレイルのWebブラウザ[18]、Pythonの[19]で開発され、自由にダウンロード可能なソフトウェアは、また、「HDL：」サポートURIスキームをし、それに応じてハンドルを解決します。これらのリゾルバ対応ブラウザのいずれかに：例えば、ハンドル「10.1045 / july95-アームは」「10.1045 / july95-腕HDL」として、そのハンドルURIを入力することによって解決することができます。ハンドルURI構文の詳細は、別の文書で指定されます。
Handle System operations can be categorized into resolution and administration. Clients use the handle resolution service to query for any handle values. Handle administration allows clients to manage handles, including adding and deleting handles, and updating their values. It also deals with naming authority administration via naming authority handles. This section explains how various Handle System components work together to accomplish these service operations.
ハンドルシステムの操作は、解像度や管理に分類することができます。クライアントは、任意のハンドル値を照会するためにハンドル解決サービスを使用します。ハンドルの政権は、クライアントが追加とハンドルを削除し、その値を更新するなど、ハンドルを、管理することができます。また、権限のハンドルを命名経由して権限管理を命名を扱います。このセクションでは、さまざまなハンドルシステムのコンポーネントは、これらのサービスの動作を実行するために、どのように連携するかを説明します。
Both resolution and administration may require authentication of the client. The authentication can be done via the Handle System authentication protocol described later in this section. Whether authentication is required or not depends on the kind of operation involved and the permissions assigned to the relevant handle value, and policies deployed by the relevant service components.
解像度と管理の両方がクライアントの認証が必要な場合があります。認証は、このセクションで後述するハンドル・システム認証プロトコルを介して行うことができます。認証が必要とされるかどうかは、関連するサービスコンポーネントによって展開関わる操作の種類と関連するハンドル値に割り当てられている権限、およびポリシーに依存します。
The Handle System protocol specifies the syntax and semantics of each message exchanged between Handle System clients and its server components. This section provides a high level overview of the protocol used to accomplish any service operation. The exact programmatic detail of each message (i.e., their byte layout or syntax) is specified in a separate document [8].
ハンドルシステムのプロトコルは、ハンドルシステムのクライアントとそのサーバーコンポーネント間で交換される各メッセージの構文とセマンティクスを指定します。このセクションでは、任意のサービスの動作を達成するために使用されるプロトコルのハイレベルの概要を提供します。各メッセージ（すなわち、それらのバイトのレイアウトや構文）の正確なプログラム詳細は別の文書で指定されている[8]。
The Handle System provides its service in response to client requests. A client may send a request to any handle server to provoke a response. The response either provides an answer to the request, or a status code with associated information that either refers the request to another service component, asks for client authentication, or signals some error status.
ハンドルシステムは、クライアントの要求に応答して、そのサービスを提供しています。クライアントは応答を誘発するために、任意のハンドルサーバに要求を送信することができます。応答は、いずれかの他のサービス・コンポーネントへの要求を意味することを要求に対する回答、または関連情報をステータス・コードを提供するクライアント認証を要求し、またはいくつかのエラー状態を知らせるのいずれか。
Each handle under the Handle System is managed by its home service. The naming authority handle provides the service information (in terms of HS_SERV or HS_SITE values) of the handle service that manages all handles under the naming authority. Any handle request must be directed to the home service of the handle in question. Clients may find the home service by querying the corresponding naming authority handle against the GHR. Alternatively, this information may be found in a local cache or even be part of a local client configuration. Given the service information, clients may select a service site and locate the responsible handle server within the site.
ハンドルシステムの下でそれぞれのハンドルは、そのホームサービスによって管理されています。命名機関ハンドルは、命名機関の下にすべてのハンドルを管理ハンドルサービスの（HS_SERVまたはHS_SITE値の点で）サービス情報を提供します。任意のハンドル要求は、問題のハンドルのホームサービスに向けなければなりません。クライアントは、GHRに対する対応する命名機関ハンドルを照会することにより、ホームサービスを見つけることができます。また、この情報はローカルキャッシュに見ることができる、あるいはローカルクライアント構成の一部です。サービス情報を考えると、クライアントは、サービスサイトを選択することができ、サイト内の責任ハンドルサーバを探します。
To resolve the handle "ncstrl.vatech_cs/te-93-35", for example, client software needs to know the home service for the naming authority "ncstrl.vatech_cs". The home service can be obtained by querying the naming authority handle "0.NA/ncstrl.vatech_cs" against the GHR. The GHR will return the service information in terms of the HS_SITE values assigned to the naming authority handle. From the service information, clients can pick a service site, find the responsible handle server within the site, and send the resolution request to the handle server.
ハンドル「ncstrl.vatech_cs / TE-93から35を」解決するには、例えば、クライアントソフトウェアが命名機関「ncstrl.vatech_cs」のためのホームサービスを知っている必要があります。ホームサービスは、GHRに対する命名機関ハンドル「0.NA/ncstrl.vatech_cs」を照会することによって取得することができます。 GHRは、命名機関のハンドルに割り当てられたHS_SITE値の観点からサービス情報を返します。サービス情報から、クライアントは、サービスサイトを選んでサイト内の責任ハンドルサーバを見つけて、ハンドルサーバへの解決要求を送信することができます。
Clients may require digital signatures from a handle server in order to authenticate any response from the server. The signature can be generated using the server's private key. Clients may verify the signature using the public key available from the service information (refer to the <PublicKeyRecord> entry discussed in 3.2.2).
クライアントは、サーバーからの応答を認証するためにハンドルサーバからのデジタル署名が必要な場合があります。署名は、サーバの秘密鍵を使用して生成することができます。クライアントは、サービス情報（3.2.2で説明した<PublicKeyRecord>エントリを参照）から入手可能な公開鍵を用いて署名を検証することができます。
A communication session may also be established between any client and handle server. Each session is identified by a unique session ID managed by the server. A session may be used to manage requests that require multiple interactions. It may also be used to share any TCP connection or authentication information among multiple service transactions. Each session may establish a session key and use it to authenticate any message exchanged within the session. It may also be used to encrypt any message between the client and the server to achieve data confidentiality.
通信セッションはまた、任意のクライアントとハンドルサーバの間で確立することができます。各セッションは、サーバーで管理される一意のセッションIDによって識別されます。セッションは、複数の相互作用を必要とする要求を管理するために使用することができます。また、複数のサービス取引の中で任意のTCP接続または認証情報を共有するために使用することができます。各セッションは、セッションキーを確立し、セッション内で交換されるメッセージを認証するためにそれを使用することができます。また、クライアントとデータの機密性を達成するために、サーバー間のすべてのメッセージを暗号化するために使用することができます。
The following diagram shows a handle resolution process in terms of messages exchanged between client software and Handle System service components. In this case, the client is trying to resolve the handle "ncstrl.vatech_cs/tr-93-35". It assumes that the client has yet obtained the service information of the LHS "homed" by the naming authority "ncstrl.vatech.cs". The client has to get the service information from the naming authority handle managed by the GHR. The service information allows the client to locate the responsible LHS and query for the handle value.
次の図は、メッセージの面でハンドル解決プロセスは、クライアント・ソフトウェアおよびシステムサービス部品の取り扱いの間でやり取りを示しています。この場合、クライアントは、ハンドル「ncstrl.vatech_cs / TR-93から35を」解決しようとしています。これは、クライアントがまだ命名機関「ncstrl.vatech.cs」で「ホーム」LHSのサービス情報を取得していることを前提としています。クライアントは、GHRによって管理命名機関ハンドルからサービス情報を取得する必要があります。サービス情報は、クライアントがハンドル値のために責任をLHSとクエリを見つけることができます。
[HS Client] ----------------------------> [Global Handle Registry]
1. ask for the service
information from the
naming authority handle
"0.NA/ncstrl.vatech_cs"
[HS Client] <---------------------------- [Global Handle Registry]
2. service information for
the naming authority
"ncstrl.vatech_cs"
[HS Client] ----------------------------> [Local Handle Service]
3. query the handle
"ncstrl.vatech_cs/tr-93-35"
against the responsible
handle server
\... ...
￥。。。 。。。
(optional client authentication, depending on the service request)
（オプションのクライアント認証、サービス要求に応じて）
\... ...
￥。。。 。。。
[HS Client] <---------------------------- [Local Handle Service]
4. query result from the handle
server + (optional) server
signature
Figure 5.1: Handle resolution example
図5.1：解像度例をハンドル
In Figure 5.1, the client is configured to communicate with the GHR for any handle service. In this case, the client first queries the GHR to find the home service for the handle's naming authority. The
図5.1において、クライアントは、任意のハンドルサービスのGHRと通信するように構成されています。この場合、クライアントは、第1のハンドルの命名機関のためのホームサービスを見つけるために、GHRを照会します。ザ・
GHR returns the service information of the LHS that manages every handle under the naming authority. From the service information, the client can find the responsible handle server and query the server for the handle. The server may set up a session to authenticate the client if any of the handle value requires authentication. Otherwise, the server will simply return the handle value to the client. The server may send a digital signature as part of its response if required by the client.
GHRは、命名機関の下にすべてのハンドルを管理LHSのサービス情報を返します。サービス情報から、クライアントは、責任ハンドルサーバを見つけることができますし、ハンドルをサーバーに問い合わせます。サーバーは、ハンドル値のいずれかで認証が必要な場合は、クライアントを認証するようにセッションを設定することもできます。そうしないと、サーバは単にクライアントにハンドル値を返します。クライアントによって要求された場合、サーバは、その応答の一部としてデジタル署名を送信することができます。
The above procedure assumes that the client software already has the GHR service information. That information was likely obtained from the client software distribution. The GHR will notify the client software if it learns that the service information used by the client software is out of date. Client software may retrieve the latest service information from the root handle "0.NA/0.NA". The root handle also maintains the public key that may be used to authenticate the service information.
上記の手順は、クライアントソフトウェアがすでにGHRサービス情報を持っていることを前提としています。この情報は、可能性の高いクライアント・ソフトウェア・ディストリビューションから入手しました。それはクライアントソフトウェアによって使用されるサービス情報が古くなっていることを知った場合GHRは、クライアントソフトウェアを通知します。クライアントソフトウェアは、ルートハンドル「0.NA/0.NA」から最新のサービス情報を検索することができます。ルートハンドルは、サービス情報を認証するために使用することができる公開鍵を保持しています。
Note that a client may cache the service information of any naming authority so that subsequent queries for handles under the same naming authority may reuse the service information and bypass the first two steps shown in Figure 5.1. Client software may also be configured to query a caching or proxy server directly for any handle. In this case, the caching or proxy server will act as the [HS Client] in Figure 5.1 before returning the query result to the client.
同じ命名権限下ハンドルのための後続のクエリは、サービス情報を再利用し、図5.1に示されている最初の2つのステップをバイパスすることができるように、クライアントは、任意の命名権限のサービス情報をキャッシュしてもよいことに留意されたいです。クライアントソフトウェアは、任意のハンドルに直接キャッシュやプロキシサーバーを照会するように構成することができます。この場合、キャッシュまたはプロキシサーバがクライアントにクエリ結果を返す前に、図5.1の[HSクライアント]として動作します。
Client software under certain organization may also elect to bypass the GHR and communicate directly with a LHS managed by the organization. Doing so may achieve quicker response for handles managed under the LHS. The client software will be referred to the GHR for handles not managed by the LHS.
特定の組織の下で、クライアントソフトウェアは、GHRをバイパスし、組織によって管理さLHSと直接通信することを選ぶことができます。そうすることLHSで管理ハンドルのための迅速な応答を達成することができます。クライアントソフトウェアは、LHSで管理していないハンドルのためにGHRと呼ぶことにします。
The Handle System supports handle administration over the public Internet. Access controls can be defined on each handle value. The Handle System authentication protocol is the protocol used by any handle server to authenticate handle administrator upon any administration request. The authentication is also necessary when clients query for handle values that are read-only by the handle administrator. Handle administration include adding, deleting or modifying handle values, and adding or deleting handles. Naming authority administrations are carried out as handle administrations over the corresponding naming authority handles.
ハンドルシステムは、公共のインターネット上でのハンドルの管理をサポートしています。アクセス制御は、各ハンドル値で定義することができます。ハンドルシステムの認証プロトコルは、任意の投与要求に応じてハンドルの管理者を認証するために任意のハンドル・サーバによって使用されるプロトコルです。クライアントが読み取り専用であるハンドル管理者がハンドル値を照会する際の認証も必要です。ハンドル投与は、追加、削除または変更ハンドル値、及びハンドルを追加または削除が含まれます。命名権威の投与は、対応する命名権威ハンドルの上にハンドル行政として行われています。
The Handle System authentication protocol does not perform any server authentication. However, a client may authenticate any server response by asking the server to sign its response with digital signature.
ハンドルシステムの認証プロトコルは、任意のサーバー認証を行いません。ただし、クライアントは、デジタル署名付きの応答に署名するサーバーを尋ねることによって、任意のサーバの応答を認証することができます。
By default, the Handle System authenticates clients via a challenge-response protocol. That is, after receiving a client's request, the server issues a challenge to the client if authentication is necessary. To be authenticated as the administrator, the client has to return a challenge-response, a message that demonstrates procession of the administrator's secret. The secret may be the private key or the secret key of the administrator. This challenge-response allows the server to authenticate the client as the handle administrator. Upon successful authentication, the server will fulfill the client's request if the administrator is given sufficient permission.
デフォルトでは、ハンドルシステムは、チャレンジ・レスポンスプロトコルを介してクライアントを認証します。これは、認証が必要な場合は、クライアントの要求を受信した後、サーバはクライアントにチャレンジを発行、です。管理者として認証されるために、クライアントは、チャレンジ・レスポンス、管理者の秘密の行列を示しているメッセージを返すことがあります。秘密は、秘密鍵または管理者の秘密鍵かもしれません。このチャレンジ・レスポンスは、サーバは、ハンドル管理者としてクライアントを認証することができます。管理者が十分な権限を与えられている場合は認証に成功すると、サーバーはクライアントの要求を満たすだろう。
For example, suppose a client sends a request to the handle server to add a new handle value. The server will issue a challenge to the client in order to authenticate the client as one of the handle administrators. If the client possesses the private key of the administrator, she can use it to sign the server's challenge and return the signature as part of her challenge-response. The server will validate the signature in order to authenticate the client. The client will be notified if the validation fails. Otherwise, the server will further check if the administrator has the permission to add the handle value. If so, the server will add the handle value and report success to the client. Otherwise, a permission-denied message will be returned.
たとえば、クライアントが新しいハンドル値を追加するためのハンドルサーバに要求を送信したとします。サーバーは、ハンドルの管理者の一人として、クライアントを認証するためにクライアントにチャレンジを発行します。クライアントは、管理者の秘密鍵を所有している場合は、彼女は、サーバーの挑戦に署名し、彼女のチャレンジ・レスポンスの一環として、署名を返すためにそれを使用することができます。サーバがクライアントを認証するために、署名を検証します。検証が失敗した場合、クライアントに通知されます。管理者がハンドル値を追加する権限を持っている場合はそれ以外の場合は、サーバーをさらにチェックします。その場合、サーバーは、ハンドル値を追加し、クライアントに成功を報告します。それ以外の場合は、許可拒否メッセージが返されます。
The following diagram shows a typical authentication process in terms of the messages exchanged between the client and the handle server.
次の図は、クライアントとハンドルサーバ間で交換されるメッセージの観点から、一般的な認証プロセスを示しています。
[Client] --------------------------------> [Handle Server]
1. client request
+ (optional) client credential
[Client] <-------------------------------- [Handle Server]
2. server's challenge to client
+ (i.e., nonce + MD5 of client request)
[Client] -------------------------------> [Handle Server]
3. reference to handle administrator
+ challenge-response from client
[Client] <------------------------------- [Handle Server]
4. server acknowledgement
Figure 5.2: Handle System authentication process
図5.2：システムの認証プロセスを処理
In Figure 5.2, the client sends an administration request to the handle server (along with optional credential discussed later). The server decides that client authentication is required and issues a challenge to the client. The client identifies itself as a handle administrator and returns the challenge-response to the server. The server authenticates the client as the administrator based on the challenge-response. It also checks to see if the administrator is authorized for the administration request. If so, the server will fulfill the request and acknowledge the client.
図5.2において、クライアントは、（後述するオプションクレデンシャルと共に）ハンドルサーバに管理要求を送信します。サーバーは、クライアント認証が必要であると判断し、クライアントにチャレンジを発行します。クライアントは、ハンドルの管理者として自分自身を識別し、サーバへのチャレンジレスポンスを返します。サーバーは、チャレンジ・レスポンスに基づいて管理者としてクライアントを認証します。また、管理者がシステム管理要求のために許可されているかどうかを確認します。その場合、サーバーは要求を満たすと、クライアントを確認します。
Handle servers must authenticate the client before fulfilling any request that requires administrator privilege. The exact authentication process varies depending on whether public key or secret key is used by the administrator. It also depends on whether the handle used to store the administrator's key is managed by the same handle server or not.
ハンドルサーバは、管理者権限を必要とするすべての要求を満たす前にクライアントを認証する必要があります。正確な認証プロセスは、公開鍵や秘密鍵が管理者によって使用されているかどうかによって異なります。また、管理者の鍵を格納するために使用されるハンドルが同じハンドルサーバかによって管理されているかどうかに依存します。
When public key is used, the challenge-response from the client contains its digital signature over the server's challenge. The server can authenticate the client by verifying the digital signature based on the administrator's public key. If secret key is used, the challenge-response from the client carries the Message Authenticate Code (MAC) generated using the secret key. The server may authenticate the client by generating the same MAC using the administrator's secret key and comparing it against the challenge-response.
公開鍵を使用する場合は、クライアントからのチャレンジ・レスポンスは、サーバーの挑戦の上にそのデジタル署名が含まれています。サーバーは、管理者の公開鍵に基づいてデジタル署名を検証することにより、クライアントを認証することができます。秘密鍵を使用する場合は、クライアントからのチャレンジ・レスポンスは、メッセージ認証コード（MAC）は、秘密鍵を使用して生成運びます。サーバーは、管理者の秘密鍵を使用して同じMACを生成し、チャレンジ・レスポンスに対してそれを比較することによって、クライアントを認証します。
The reference to handle administrator in Fig 5.2 is also called a key-reference. It refers to a handle value that contains the key used by the administrator. If the key-reference is managed by the same handle server (e.g., a handle value assigned to the same handle), the server may use the key directly to do the authentication. If the key-reference is managed by some other handle server (whether or not within the same handle service), the server will have to send a verification-request to this other handle server, call it the key-server, in order to authenticate the client. The verification-request to the key-server carries both the server's challenge and the client's challenge-response. The key-server will return a verification-response, signed using the key-server's private key. The content of the verification-response will depend on the handle value referenced by the key-reference. If the key-reference refers to a public key used by the administrator, the verification-response will contain the public key of the administrator. Otherwise, the key-server will verify the challenge-response on behalf of the requesting server and return the result in the verification-response. The following diagram shows the control flow of the authentication process where the key-reference refers to a handle value that contains the administrator's public (or secret) key and the key-server is some other handle server.
図5.2に管理者を処理するための基準は、キー・リファレンスと呼ばれています。これは、管理者が使用するキーが含まれているハンドル値を参照します。鍵参照が同じハンドルサーバによって管理されている場合（例えば、同一のハンドルに割り当てられたハンドル値）は、サーバーが認証を行うために直接キーを使用してもよいです。キー参照が他のいくつかのハンドルサーバ（同じハンドルサービス内かどうか）によって管理されている場合、サーバが認証するために、キーサーバーを呼び出し、この他のハンドルサーバに認証要求を送信する必要がありますクライアント。キーサーバーへの認証要求は、サーバのチャレンジとクライアントのチャレンジレスポンスの両方を運びます。キーサーバは、検証応答を返すキーサーバの秘密鍵を使って署名されます。検証応答の内容は、キー参照によって参照されるハンドル値に依存するであろう。キー参照は、管理者が使用した公開鍵を参照している場合、検証応答は、管理者の公開鍵が含まれています。それ以外の場合は、キーサーバーは、要求元のサーバに代わってチャレンジ応答を検証し、検証応答して結果を返します。次の図は、キー参照は、管理者の公開（又は秘密）キーを含み、キーサーバが他のハンドルサーバであるハンドル値を意味する認証処理の制御フローを示します。
-------- -------------
| | 1. client request. | |
| | -------------------------------> | |
| | | |
| | 2. session ID | |
| | + server's challenge | |
| Handle | <------------------------------- | Handle |
| System | | server |
| client | 3. session ID | receiving |
| | + response to the challenge | client |
| | + administrator reference | request |
| | --------------------------------> | |
| | | |
| | 6. server acknowledgement | |
| | <------------------------------- | |
-------- -------------
| ^
4. Verification | | 5. verifi-
request | | cation
| | response
| | (signed)
V |
--------------------------
| The handle server (the |
| key-server) that manages |
| the key referenced by |
| the key-reference |
--------------------------
Figure 5.3: Authentication process requiring verification
from a second handle server
Secret key based authentication via a second handle server, i.e., the key server, provides a convenient way to share a common secret key (e.g., pass phrase) among handles managed by different handle servers. However, it should not be used to manage highly sensitive handles or handle data. The authentication process itself is expensive and relies on a third party, i.e., the key-server, for proper operation. Additionally, the secret key itself is subject to dictionary attack since the key-server cannot determine whether the verification-request comes from a legitimate handle server. A handle service may set its local policy so that secret key based authentication can only be carried out if the handle server (receiving the client request) is also the key-server.
第2のハンドルサーバを経由して、秘密鍵による認証、すなわち、鍵サーバは、異なるハンドル・サーバによって管理されるハンドルの間で共通の秘密鍵を（例えば、パスフレーズ）を共有するための便利な方法を提供します。しかし、非常に敏感ハンドルを管理したり、データを処理するために使用すべきではありません。認証プロセス自体が高価であり、適切な動作のために、第三者、すなわち、キーサーバーに依存しています。キーサーバが認証要求が正当なハンドルサーバから来ているかどうかを判断することはできませんので、また、秘密鍵自体は、辞書攻撃の対象となります。 （クライアント要求を受けた）ハンドルサーバは、キー・サーバーである場合、秘密鍵による認証のみが行うことができるように、ハンドルのサービスは、ローカルポリシーを設定することができます。
Local handle services may define additional local policies for authentication and/or authorization. Handle System service components may also choose to use other Internet authentication mechanisms such as Kerberos [20] or some Transport Layer Security protocol [21]. Details of these will be addressed in a separate document.
ローカルハンドルサービスは、認証および/または認可のための追加のローカルポリシーを定義することができます。システムサービスコンポーネントはまた、ケルベロス[20]や、いくつかのトランスポート層セキュリティプロトコル[21]など、他のインターネット認証メカニズムを使用することもできますハンドル。これらの詳細は、別の文書で対処されることになります。
Handle System security considerations are discussed in the "Handle System Overview" [1] and that discussion applies equally to this document.
ハンドルシステムのセキュリティの考慮事項は、「ハンドルシステムの概要」で説明されている[1]とその議論は、この文書にも同様に適用されます。
The Handle System delegates handle administration to each handle administrator who may or may not be the server administrator. Handle administrators are allowed to choose their own public/secret keys used for authentication. The security of Handle System authentication depends on the proper key selection and its maintenance by the handle administrator. Handle administrators must choose and protect their authentication keys carefully in order to protect the handle data. Handle server implementations may deploy policies that regulate the selection of public/secret keys used for authentication. For example, a handle server may require that any authentication key must be no less than certain number of bits. It may also prohibit the use of secret keys because of the potential dictionary attack.
ハンドルシステムの代表者は、またはサーバーの管理者であってもなくてもよい、各ハンドルの管理者に投与することを取り扱います。ハンドルの管理者は、認証に使用する、独自の公開/秘密鍵を選択することが許可されています。ハンドルシステム認証のセキュリティは、ハンドル管理者が適切なキーを選択し、そのメンテナンスに依存します。ハンドルの管理者が選択し、ハンドルデータを保護するために慎重に認証キーを保護する必要があります。認証に使用される公開/秘密鍵の選択を制御するポリシーを展開するサーバーの実装を扱います。例えば、ハンドルサーバは、どの認証鍵はビットの特定の数よりも少なくてはならないことを要求することができます。また、潜在的な理由は、辞書攻撃の秘密鍵の使用を禁止することができます。
The Handle System data model supports execution permission (PUBLIC_EXECUTE, ADMIN_EXECUTE) for each handle value. While this allows better sharing of network resources, it also raises many security considerations. Execution privilege should be restricted within the permissions of certain user account (corresponding to the handle administrator) on the server to prevent system-wide disruption. Switching between computing platforms for the server should also be careful to avoid any unexpected behavior. Implementations may choose not to support the execution permission, or provide options so that it can be disabled.
ハンドルシステムのデータモデルは、各ハンドル値の実行権限（PUBLIC_EXECUTE、ADMIN_EXECUTE）をサポートしています。これは、ネットワークリソースのより良い共有することができますが、それはまた、多くのセキュリティ上の考慮事項が発生します。実行権限は、システム全体の混乱を防ぐために、サーバー上で（ハンドルの管理者に相当）は、特定のユーザーアカウントの権限内に制限されなければなりません。サーバーのためのコンピューティング・プラットフォームの切り替えはまた、任意の予期しない動作を避けるために注意しなければなりません。実装は、実行権限をサポートしないことを選択、またはそれを無効にすることができるようにオプションを提供することができます。
To protect against any irresponsible use of system resource, handle servers may implement quota control. The quota control can be used to put limits on the number of handles under a naming authority, the number of handle values allowed for any given handle, the maximum size of any handle value, and the number of sub-naming authorities under a naming authority. Handle servers must report error if the result of a handle administration violates any of these limits.
システムリソースのいずれかの無責任な使用から保護するために、ハンドルサーバは、クォータ制御を実施することができます。クォータ制御を命名権限の下でハンドルの数に制限を置くために使用することができ、任意のハンドル、任意のハンドル値の最大サイズに許可ハンドル値の数、及び命名権限下サブ命名当局の数。ハンドル投与の結果は、これらの制限のいずれかに違反した場合、サーバがエラーを報告しなければならないハンドル。
This work is derived from the earlier versions of the Handle System implementation. The overall digital object architecture, including the Handle System, was described in a paper by Robert Kahn and Robert Wilensky [22] 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. 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.
この作品は、ハンドルシステムの実装の以前のバージョンから導出されます。ハンドルシステムを含む総合的なデジタル・オブジェクト・アーキテクチャは、ロバート・カーン、ロバート・Wilenskyの論文に記載された[22] 1995年に開発が国防高等によって資金を供給、コンピュータサイエンステクニカルレポート（CSTR）プロジェクトの一環として、CNRIで継続認可番号MDA-972- 92-J-1029およびMDA-972-99-1-0018下に計画庁（DARPA）。デザインのアイデアは、デビッド・イーリー、チャールズ・オース、アリソンゆう、ショーン・ライリー、ジェーン・オイラー、キャサリン・レイ、ステファニー・グエン、ジェイソン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] Sun, S. and L. Lannom, "Handle System Overview", RFC 3650, November 2003.
[1]日、S.とL. Lannomは、RFC 3650、2003年11月 "システムの概要をハンドル"。
[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] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[4]ワール、M.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）"、RFC 2251、1997年12月。
[5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[5]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[6] Yergeau, F., "UTF-8, A Transform Format for Unicode and ISO10646", RFC 2279, January 1998.
[6] Yergeau、F.は、RFC 2279、1998年1月、 "UTF-8は、Aは、UnicodeとISO10646のためのフォーマットを変換します"。
[7] The Unicode Consortium, "The Unicode Standard, Version 2.0", Addison-Wesley Developers Press, 1996. ISBN 0-201-48345-9
[7]ユニコードコンソーシアム、 "Unicode規格、バージョン2.0"、アディソン - ウェズリー開発プレス、1996年ISBN 0-201-48345-9
[8] Sun, S., Reilly, S. and L. Lannom, "Handle System Protocol (ver 2.1) Specification", RFC 3652, November 2003.
[8]日、S.、ライリー、S.とL. Lannomを、RFC 3652、2003年11月 "システムプロトコル（版2.1）仕様ハンドル"。
[9] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[9]バーナーズ=リー、T.、Masinter、LとM. McCahill、 "ユニフォームリソースロケータ（URL）"、RFC 1738、1994年12月。
[10] Housley, R., Polk, W. Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[10] Housley氏、R.、ポーク、W.フォード、W.およびD.ソロ、 "インターネットX.509公開鍵基盤 - 証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[11] Federal Information Processing Standards Publication (FIPS PUB) 46-1, Data Encryption Standard, Reaffirmed 1988 January 22 (supersedes FIPS PUB 46, 1977 January 15).
[11]連邦情報処理規格出版（FIPS PUBの）46-1、データ暗号化規格、1988年1月22日（1977年1月15日、FIPS PUBの46に取って代わる）を再確認しました。
[12] Federal Information Processing Standards Publication (FIPS PUB) 81, DES Modes of Operation, 1980 December 2.
[12]連邦情報処理規格出版（FIPS PUBの）81、オペレーションのDESモード、1980年12月2日。
[13] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, February 1993.
[13] Balenson、D.、 "インターネット電子メールのためのプライバシー増進：パートIII：アルゴリズム、モード、および識別子"、RFC 1423、1993年2月。
[14] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[14]リベスト、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[15] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
[15]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 1883、1995年12月。
[16] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[16] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[17] CNRI Handle System Resolver, http://www.handle.net/resolver
[17] CNRIシステムリゾルバハンドル、http://www.handle.net/resolver
[18] Grail browser home page, http://grail.sourceforge.net/
[18]杯のブラウザのホームページ、http://grail.sourceforge.net/
[19] Python language website, http://www.python.org/
[19] Python言語のウェブサイト、http://www.python.org/
[20] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[20]コールズ、J.及びC.ノイマン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 1510、1993年9月。
[21] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[21]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[22] R. Kahn, R. Wilensky, "A Framework for Distributed Digital Object Services, May 1995, http://www.cnri.reston.va.us/k-w.html
[22] R.カーン、R. Wilensky、「分散型デジタルオブジェクトサービスのためのフレームワーク、1995年5月、http://www.cnri.reston.va.us/k-w.html
[23] American National Standards Institute. ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation. 1998.
[23]米国規格協会。 ANSI X9.52-1998、オペレーションのトリプルデータ暗号化アルゴリズムモード。 1998。
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
Sean Reilly Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
国立研究イニシアチブのためのショーン・ライリー・コーポレーション（CNRI）1895プレストン・ホワイト博士は、スイート100レストン、バージニア州20191
Phone: 703-620-8990 EMail: sreilly@cnri.reston.va.us
電話：703-620-8990 Eメール：sreilly@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
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機能のための基金は現在、インターネット協会によって提供されます。