[要約] RFC 3651は、Handle Systemの名前空間とサービスの定義に関するものであり、その目的は、グローバルな識別子システムの構築と管理を効率化することです。
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.
Copyright（c）The Internet Society（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アーキテクチャに識別子のIETFアーキテクチャにどのように適合するかについても指摘したいと考えています。URIの形式としてのハンドル、特にURNとしての議論がありましたが、これらのドキュメントは、名前空間と識別子がインターネット上でどのように機能するかについての代替ビューを説明し、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年にロバート・カーンとロバート・ウィレンスキー[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 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.
ドキュメント「ハンドルシステムの概要」[1]は、ハンドルシステムのアーキテクチャの概要と、DNS [2,3]やLDAP [4]などの他のインターネットサービスとの関係を提供します。このドキュメントは、ハンドルシステムの名前空間、そのデータとサービスモデル、およびその動作モデルの詳細な説明を提供します。概要ドキュメントで説明されているように、読者はハンドルシステムの基本概念に精通していると想定しています。
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文字 "/"（Octet 0x2f）によって区切られています。次の表は、ABNF [5]表記のハンドル構文定義を示します。
<Handle> = <NamingAuthority> "/" <LocalName>
<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 '/').
<LocalName> = *(%x00-FF)
; any octets that map to UTF-8 encoded
; Unicode 2.0 characters
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>は、Unicode 2.0標準[7]の任意の文字で構成されている場合があります。<NamingAuthority>は、ASCII文字 '/'（0x2F）を除き、Unicode 2.0標準の任意の文字を使用できます。<NamingAuthority>は、複数の非空白<Nasegeg>で構成され、それぞれがASCII文字 '。（Octet 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>）に対応するラベルが与えられます。親ノードは、親の命名機関を表します。命名当局は左から右に構築され、ツリーのルートから命名権限を表すノードにラベルを連結します。各ラベル（または<Nasegeg>）は、文字「」によって分離されています。（Octet 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文字が症例の鈍感として扱われるように名前空間を実装する場合があります。たとえば、Global Handle Registry（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-Payette」。これらの値の1つ（インデックス番号が1に設定されています）が詳細に示されています。（各フィールドの長さのエンコードは図3.1には示されていません。また、空の<参照>フィールドは、値がゼロの4バイト整数で構成されています。）
Handle "10.1045/may99-payette"
ハンドル「10.1045/May99-Payette」
| | V
||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-payette」とその値のセットを処理する
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です。<data>フィールドに記載されているURLデータは「http：//www.dlib.org/dlib ...」です。TTL（Time to Live）エントリは、バリューレコードを、再び相談する情報のソースの24時間以内にキャッシュされるべきであることを示唆しています。<commission>フィールドは、誰でも読む許可を与えますが、値を更新する管理者のみを付与します。<presecre>フィールドは空です。このハンドル値の資格情報として、他のハンドル値への参照のリストが含まれている場合があります。
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.
<Type>値レコードのデータ型を識別するUTF8-STRING。このドキュメント全体で、UTF8-STRINGは、UTF-8エンコードされた文字列が続く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.
<type>フィールドは、次の<データ>フィールドのデータの構文とセマンティクスを定義するデータ型を識別します。データ型は、潜在的な競合を回避するために、ハンドルシステムに登録できます。ハンドルシステムには、登録データ型のための予約命名権限「0.Type」があります。たとえば、「URL」（図3.1に示すように）は登録データ型です。ハンドル「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".
ハンドルシステムの下のデータ型は階層的である場合があります。階層の各レベルは、 '。（0x2e）文字。「。」文字は、階層レベル間の境界をマークするために使用されます。たとえば、ハンドルシステムのデータ型「A.B」は、「A」というタイプの下でサブタイプの「B」と見なされる場合があります。同様に、<type> "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].
任意のハンドル値については、<Type>フィールドのUTF8-STRINGは「。」で終了しない場合があります。キャラクター。言い換えれば、「キャラクター。しかし '。'文字は、ハンドルクエリの<type>パラメーターの最後に表示される場合があります。これは、一般的なタイプの階層の下ですべてのハンドル値をクエリするために使用されます。たとえば、<Type>パラメーターを「A.B.」に設定することにより、タイプ階層「A.B」（例：<type> "a.b.x"、 "a.b.y"、および "a.b.z"のハンドル値）の下のすべてのハンドル値をクエリすることができます。ここで、<type>パラメーターは「。」で終了することに注意してください。キャラクター。ハンドルクエリ操作の詳細は、ハンドルシステムプロトコル仕様[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.
<data>ハンドルによって識別されたリソースを記述するオクテットのシーケンス（4バイトの署名されていない整数のその長さが前にあります）。これらのオクテットの構文とセマンティクスは、<type>フィールドによって識別されます。
<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（0x02）は、誰でもハンドル値を読み取ることができるようにします。
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（0x08）_ authorive_read privilegeを使用して、ハンドル管理者がハンドル値を読み取ることを許可する許可。
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（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値（TTLタイプに続く32ビットの符号なし整数）が続きます。TTLタイプは、TTL値が絶対または相対であるかどうかを示します。絶対的なTTL値は、1970年1月1日、00:00:00 UTC以降の数秒の観点から生きる時間を定義します。任意のハンドルサーバー。
<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バイト（長い）整数。このフィールドには、1970年1月にミリ秒単位で00:00:00 UTC以降の経過時間が含まれています。ミリ秒の選択は、値を更新するときに潜在的な衝突を回避することです。
<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-Stringと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.
各ハンドル値は、ハンドルとその値インデックスの組み合わせによって一意に参照できます。既存の参照がハンドル値への参照を破壊する可能性があるため、値インデックスを変更するときは注意が必要です。たとえば、ハンドルx/yにインデックスが1の値を持っているとします。その値は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.
すべてのハンドル値には、<type>フィールドにデータ型が指定されている必要があります。ハンドルシステムは、組織がアプリケーションの新しいデータ型を登録できるようにするタイプ登録サービスを提供します。データ型は、命名機関「0.Type」の下でハンドルとして登録できます。たとえば、URLデータ型は、ハンドル「0.Type/URL」としてハンドルシステムの下に登録されています。ハンドルには、URLの構文とセマンティクスを定義するIETF標準ドキュメントであるRFC1738 [9]を指すハンドル値がある場合があります。
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_管理値が必要です。各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値は、<Type>フィールドがHS_ADMINであり、<Data>フィールドが次のエントリで構成されているハンドル値です。
<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>ハンドル値への参照。リファレンスは、ハンドル名（UTF8ストリング）で構成され、その後にハンドル値インデックスに4バイトの符号なし整数が続きます。ハンドル値は、ハンドルの管理者のセットを識別します。
<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>エントリには、<type>フィールドがdss_with_des_cbc_shaであり、<data>フィールドには、暗号ブロックチェーン（CBC）動作モードで使用するためのsecretキー[11]が含まれているハンドル管理者リファレンスを含めることができます[11]12、13]。シークレットキーは、ハンドルサーバーがハンドル管理者を認証するために使用できます。より強力な暗号化アルゴリズムの場合、ハンドル管理者の参照にはトリプルデスキーのセット[23]が含まれ、<type>を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である場合があり、その<Data>フィールドには、他のハンドル値への参照のリストが含まれています。これらのハンドル値はそれぞれ、ハンドル管理者の参照を定義します。HS_VLIST値は、管理者グループを定義します。HS_VLISTからの各ハンドル管理者リファレンスは、管理者グループのメンバーです。各ハンドル値の参照は、<handle>：<index>ペアの観点から定義されます。管理者グループには、メンバーとして他の管理者グループが含まれる場合があります。これにより、管理者グループを階層的に定義できます。ただし、管理者または管理者グループの周期的な定義を避けるために、注意が必要です。効率が不足しているため、複数のレベルの管理者グループを避ける必要がありますが、エラーとして信号はありません。クライアントソフトウェアは、存在しないハンドル値を指す管理者または<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人の管理者がいる場合がありますが、そのうちの1人は命名当局の下で新しいハンドルを作成する許可を持つことがありますが、もう1つは新しいサブネーミング当局を作成する許可を持っている場合があります（例：、「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（0x0002）この許可により、命名当局管理者は、特定の命名機関の下でハンドルを削除できます。
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）この許可は、管理者read-accessを処理して、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値の<data>フィールドの<datas>エントリでエンコードされます。各許可は、少しフラグとしてエンコードされます。フラグが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":3に基づいて認証できます。これは、命名機関に割り当てられたハンドル値「0.NA/10」であり、インデックスが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"
図3.2.1：命名機関のハンドル「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値は、ハンドルサーバーによって使用され、管理者のリクエストを満たす前にハンドル管理者を認証します。サーバーは、クライアントがハンドル管理者の参照のいずれかに一致するシークレットキー（またはプライベートキー）を所有しているかどうかを確認することにより、クライアントを認証します。認証は、このドキュメントの後半で説明されているように、ハンドルシステム認証プロトコルを介して実行されます。
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値は、<Type>フィールドがHS_SITEであり、<Data>フィールドが次のエントリで構成されているハンドル値です。
<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ビットマスク。Octetの最初のビットは<MultiPrimary>ビットです。ハンドルサービスに複数のプライマリサイトがあるかどうかを示します。オクテットの2番目のビットは<primarySite>ビットです。HS_SITE値がプライマリサイトであるかどうかを示します。主要なサイトは、ハンドルの管理運用をサポートするサイトです。値がゼロの<MultiPrimary>エントリは、ハンドルサービスに単一のプライマリサイトがあり、すべてのハンドル管理をそのサイトで行う必要があることを示します。ゼロ以外の<multiprimary>エントリは、ハンドルサービスに複数のプライマリサイトがあることを示します。各プライマリサイトは、ハンドルサービスの下で管理されているハンドルを管理するために使用できます。このようなサービスで管理されているハンドルは、セクション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（0x01）、またはhash_by_handle（0x02）が含まれます。これらのオプションは、ハッシュ操作をハンドルの命名機関の部分にのみ適用するか、ハンドルのローカル名部分、またはハンドル全体にのみ適用する必要があるかどうかを示します。標準の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.
<AttributeList> 4バイトの整数に続いて、UTF8ストリングペアのリストが続きます。整数は、続くUTF8ストリングペアの数を示します。各utf8-stringペアは<属性>：<value>ペアです。それらは、サービスサイトの文字通りの説明を追加するために使用されます。たとえば、<属性>が「組織」の場合、<value>にはサービスサイトをホストする組織の説明を含める必要があります。他の<属性>は、サービスサイトを互いに区別するのに役立つように定義される場合があります。
<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> sのリストが続きます。各<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>.
<serverId>サービスサイトの下でサーバープロセスを一意に識別する4バイトの符号なし整数。<serverId> s 1から始める必要はなく、連続した数字はありません。これらは、サービスサイトの下のサーバーを互いに区別するために使用されます。任意のコンピューターに複数のサーバーが存在する可能性があり、それぞれが異なる<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]アドレス。任意のIPv4アドレスは、:::::: Ffff：xxxx：xxxx（xxxx：xxxxが4バイトのIPv4アドレスになることができる）として表示する必要があります。
<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バイトの整数に続いて、サーバーの公開キーを含むバイトアレイが続きます。整数は、バイトアレイのサイズを指定します。バイトアレイ（PublicKey用）は、3つの部分で構成されています。キータイプを説明するUTF8ストリング、将来の使用のために予約された2バイトオプションフィールド、および公開鍵自体を含むバイトアレイです。たとえば、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」にハンドルにマッピングされます。ハンドルには、公開鍵またはその証明書の構文とセマンティクスを説明する情報が含まれている場合があります。追加のキータイプを（「0.Type」の下のハンドルとして）登録して、さまざまな種類のX.509証明書をさらに区別することもできます。たとえば、「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
4バイトの整数に続いて、<ServiceType、TransmissionProtocol、PortNumber>で構成されるトリプレットの配列が続きます。4バイトの整数は、トリプレットの数を指定します。各トリプレットは、ハンドルサーバーが提供するサービスインターフェイスをリストします。各トリプレットについて、<ServiceType>は、インターフェイスがハンドル解像度（0x01）、ハンドル管理（0x02）、またはその両方であるかどうかを指定するオクテット（ビットマスクとして）です。<sransmissionProtocol>は、伝送プロトコルを指定するオクテット（ビットマスクとして）でもあります。可能な伝送プロトコルには、TCP（0x01）、UDP（0x02）、およびHTTP（0x04）が含まれます。
<PortNumber> is a 4-byte unsigned integer that specifies the port number used by the interface. The default port number is 2641.
<portnumber>は、インターフェイスで使用されるポート番号を指定する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」に基づくすべてのハンドルのハンドル解像度と管理サービスを提供します。最初のサーバーレコード（ServerID 0）には、2つのサービスインターフェイスが表示されます。1つはハンドル解像度用、もう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.
サービスサイト内の各サーバーは、ハンドルサービスが管理するハンドルのサブセットを担当します。クライアントは、共通のハッシュオペレーションを実行することにより、責任あるサーバーを見つけることができます。ハッシュオペレーションは、最初にハンドル内のすべてのASCII文字を上限に変換します。次に、変換されたハンドル文字列の部分にmd5ハッシュを適用します（<hashoption>エントリに従って）。結果は16バイトの整数です。整数の絶対値は、サーバーの数（<numofserver>エントリで指定）で分割されます。残りは、hs_site値にリストされている<serverRecord>のシーケンス番号（ゼロから始まる）です。<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値のセットは、「foo.bar.baz」などの「foo.bar」の子命名権限の子どもの命名権限のサービス情報が、命名機関のハンドル「0.na/foo.bar」を照会することで見つけることができることを示しています.baz "LHSから。
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値は、<Type>フィールドがHS_SERVであり、<Data>フィールドにサービスハンドルへの参照が含まれているハンドル値です。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.
サービスハンドルを使用すると、複数の命名当局間でサービス情報を共有できます。また、関係するすべての命名機関のハンドルではなく、サービス構成（新しいサイトの追加）の変更を1つの場所で作成することもできます。このメカニズムは、何らかの理由であるハンドルサービスから別のハンドルサービスへのサービス紹介をサポートするためにも使用できます。
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".
同様に、命名権限「A.B.C」の下でハンドルを管理するハンドルサービスのサービス情報をホストするために、「0.Serv/A.B.C」のサービスハンドル「0.Serv/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値は、<Type>フィールドがHS_ALIASであり、<data>フィールドに別のハンドルへの参照が含まれているハンドル値です。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つは、名前付きリソースの所有権の転送をサポートすることです。ハンドルによって識別されたリソースがある組織から別の組織に識別されると、リソースの新しいハンドルが作成される場合があります。矛盾と壊れた参照を回避するために、所有権転送の前に使用されるハンドルをエイリアスハンドルに変更し、その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値は、<type>フィールドがHS_PRIMARYであり、<data>フィールドにHS_SITE値への参照のリストが含まれているハンドル値です。これらの各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.
せいぜい各ハンドルに割り当てられたHS_Primary値が1つあります。それ以外の場合はエラーです。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値は、<type>がHS_VLISTであり、<data>が4バイトの符号なし整数で構成されているハンドル値で、その後の他のハンドル値への参照のリストがあります。整数は、リスト内の参照数を指定します。参照は、他のハンドルの同じハンドルまたはハンドル値の下のハンドル値を指す場合があります。各参照は、UTF8-STRINGとしてエンコードされ、その後、参照されたハンドルとその値インデックスを識別する4バイトの符号なし整数が続きます。
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は、最新のアップデートのルートハンドルを依然として照会できるようにするように維持する必要があります。
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：GHRサービス情報
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は、複数の命名当局の本拠地である可能性があります。一方、命名当局は1つの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」の命名権限ハンドルに割り当てられます。これは、これらのHS_SITE値で指定されたLHSで命名権限「10」が「ホーム」されていることを示唆しています。クライアントは、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>（Live to Live）フィールドが含まれています。ゼロ値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/ <handle>」として構築できます。ここで、<handle>はハンドルシステムから任意のハンドルにすることができます。たとえば、ハンドル「ncstrl.vatech_cs/tr-93-35」は、http url "http://hdl.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]は、そのようなコンポーネントの1つです。リゾルバーは、「HDL：」という点でハンドルを直接解決できるように、Webブラウザー（NetscapeやMicrosoft Internet Explorerなど）を拡張します。Python [19]で開発された自由にダウンロードできるソフトウェアであるGrail Webブラウザ[18]は、「HDL：」URIスキームをサポートし、それに応じてハンドルを解決します。たとえば、ハンドル「10.1045/7月9日」は、ハンドルURIを「HDL：10.1045/7月95アーム」としてこれらのリゾルバー対応ブラウザのいずれかに入力することにより解決できます。ハンドル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 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.
図5.1では、クライアントは、ハンドルサービスのGHRと通信するように構成されています。この場合、クライアントは最初にGHRを照会して、ハンドルの命名機関のホームサービスを見つけます。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.
たとえば、クライアントがハンドルサーバーにリクエストを送信して、新しいハンドル値を追加するとします。サーバーは、クライアントをハンドル管理者の1人として認証するために、クライアントに課題を発行します。クライアントが管理者の秘密鍵を所有している場合、彼女はそれを使用してサーバーの課題に署名し、チャレンジ応答の一部として署名を返すことができます。サーバーは、クライアントを認証するために署名を検証します。検証が失敗した場合、クライアントに通知されます。それ以外の場合、サーバーは、管理者がハンドル値を追加する許可を持っているかどうかをさらに確認します。その場合、サーバーはハンドル値を追加し、クライアントに成功を報告します。それ以外の場合、許可が除外されたメッセージが返されます。
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.
公開キーを使用すると、クライアントからのチャレンジ応答には、サーバーの課題に対するデジタル署名が含まれています。サーバーは、管理者の公開キーに基づいてデジタル署名を確認することにより、クライアントを認証できます。Secretキーが使用される場合、クライアントからの課題反応には、Secretキーを使用して生成されたメッセージAuthenticate Code（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
図5.3：2番目のハンドルサーバーからの検証が必要な認証プロセス
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.
セカンドハンドルサーバー、つまりキーサーバーを介したシークレットキーベースの認証は、異なるハンドルサーバーによって管理されているハンドル間で共通のシークレットキー（パスフレーズなど）を共有する便利な方法を提供します。ただし、高感度のハンドルを管理したり、データを処理したりするために使用しないでください。認証プロセス自体は高価であり、適切な操作のために、サードパーティ、つまりキーサーバーに依存しています。さらに、secretキー自体は辞書攻撃の対象となります。キーサーバーは、検証要求が正当なハンドルサーバーから来ているかどうかを判断できないためです。ハンドルサービスは、ハンドルサーバー（クライアントリクエストを受信）もキーサーバーである場合にのみ、シークレットキーベースの認証を実行できるようにローカルポリシーを設定する場合があります。
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.
ローカルハンドルサービスは、認証および/または認証のための追加のローカルポリシーを定義する場合があります。ハンドルシステムサービスコンポーネントは、Kerberos [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.
この作業は、ハンドルシステムの実装の以前のバージョンから派生しています。ハンドルシステムを含む全体的なデジタルオブジェクトアーキテクチャは、1995年にRobert KahnとRobert Wilensky [22]による論文で説明されました。助成金番号MDA-972- 92-J-1029およびMDA-972-99-1-0018に基づくプロジェクト局（DARPA）。デザインのアイデアは、デビッドイーリー、チャールズオース、アリソンユー、ショーンライリー、ジェーンオイラー、キャサリンレイ、ステファニーヌグエン、ジェイソンペトローン、ヘレンSHなど、ハンドルシステム開発チーム内で議論されているものに基づいています。この作業への彼らの貢献は感謝されています。
The authors also thank Russ Housley (housley@vigilsec.com), Ted Hardie (hardie@qualcomm.com), and Mark Baugher (mbaugher@cisco.com) for their extensive review and comments, as well as recommendations received from other members of the IETF/IRTF community.
著者はまた、Russ Housley（housley@vigilsec.com）、Ted Hardie（hardie@qualcomm.com）、およびMark Baugher（mbaugher@cisco.com）、および大規模なレビューとコメント、および他のメンバーから受け取った推奨事項に感謝します。IETF/IRTFコミュニティ。
[1] Sun, S. and L. Lannom, "Handle System Overview", RFC 3650, November 2003.
[1] Sun、S。and 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] Wahl、M.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年12月。
[5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[5] Crocker、D.、ed。および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。、「UTF-8、UnicodeおよびISO10646の変換形式」、RFC 2279、1998年1月。
[7] The Unicode Consortium, "The Unicode Standard, Version 2.0", Addison-Wesley Developers Press, 1996. ISBN 0-201-48345-9
[7] Unicode Consortium、「Unicode Standard、バージョン2.0」、Addison-Wesley Developers Press、1996。ISBN0-201-48345-9
[8] Sun, S., Reilly, S. and L. Lannom, "Handle System Protocol (ver 2.1) Specification", RFC 3652, November 2003.
[8] Sun、S.、Reilly、S。、およびL. Lannom、「Handle System Protocol（Ver 2.1）仕様」、RFC 3652、2003年11月。
[9] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[9] Berners-Lee、T.、Masinter、L。およびM. McCahill、「Uniform Resource Locators（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.、Polk、W。Ford、W。and D. Solo、「Internet 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日の再確認（Supersedes Fips Pub 46、1977年1月15日）。
[12] Federal Information Processing Standards Publication (FIPS PUB) 81, DES Modes of Operation, 1980 December 2.
[12] 連邦情報処理標準出版（FIPS Pub）81、DES Modes of Operation、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] Rivest、R。、「The Md5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[15] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
[15] Deering、S。and 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。and S. Deering、「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] Grail Browserのホームページ、http：//grail.sourceforge.net/
[19] Python language website, http://www.python.org/
[19] Python言語Webサイト、http：//www.python.org/
[20] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[20] Kohl、J。およびC. Neuman、「The Kerberos Network Authentication Service（V5）」、RFC 1510、1993年9月。
[21] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[21] Dierks、T。およびC. Allen、「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. Kahn、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
Sam X. Sun Corporation for National Research Initiatives（CNRI）1895 Preston White Dr.、Suite 100 Reston、VA 20191
Phone: 703-262-5316 EMail: ssun@cnri.reston.va.us
電話：703-262-5316メール：ssun@cnri.reston.va.us
Sean Reilly Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
Sean Reilly Corporation for National Research Initiatives（CNRI）1895 Preston White Dr.、Suite 100 Reston、VA 20191
Phone: 703-620-8990 EMail: sreilly@cnri.reston.va.us
電話：703-620-8990メール：sreilly@cnri.reston.va.us
Larry Lannom Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
Larry Lannom Corporation for National Research Initiatives（CNRI）1895 Preston White Dr.、Suite 100 Reston、VA 20191
Phone: 703-620-8990 EMail: llannom@cnri.reston.va.us
電話：703-620-8990メール：llannom@cnri.reston.va.us
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。