RFC3651 日本語訳
3651 Handle System Namespace and Service Definition. S. Sun, S.Reilly, L. Lannom. November 2003. (Format: TXT=104479 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Sun
Request for Comments: 3651 S. Reilly
Category: Informational L. Lannom
CNRI
November 2003
コメントを求めるワーキンググループS.Sun要求をネットワークでつないでください: 3651秒間ライリーCategory: 情報のL.Lannom CNRI2003年11月
Handle System Namespace and Service Definition
システム名前空間とサービス定義を扱ってください。
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
IESG Note
IESG注意
Several groups within the IETF and IRTF have discussed the Handle System and 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の中のいくつかのグループがHandle Systemとそれについて議論しました。識別子の存在システムとの関係。 IESGは、これらの議論が説明されたHandle Systemとそれがどう識別子のための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.
Handle Systemは公共のインターネットの上に機密保護している名前解決と管理を許容する汎用グローバル名サービスです。 このドキュメントはHandle System名前空間、データ、サービス、およびオペレーション・モデルの詳述を提供します。 名前空間定義はハンドル構文とその意味構造を指定します。 データモデルはハンドルサービスを提供するのにHandle Systemプロトコルとどんな事前に定義されたデータ型によっても使用されるデータ構造を定義します。 サービスモデルは、様々なHandle Systemの部品の定義を提供して、それらがネットワークよりどう一緒にやり直すかを説明します。 最終的に、Handle Systemオペレーション・モデルはクライアントとサーバの間に送られたメッセージ、およびHandle System認証プロトコルに基づくクライアント認証過程に関してサービス操作について説明します。
Sun, et al. Informational [Page 1] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[1ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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
目次1。 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 システム名前空間を扱ってください。 . . . . . . . . . . . . . . . . . . . 3 3. システムデータモデル. . . . . . . . . . . . . . . . . . . 4 3.1を扱ってください。 選択値群. . . . . . . . . . . . . . . . . . . . 4 3.2を扱ってください。 ハンドルデータ型を事前に定義しました。 . . . . . . . . . . . . . 9 3.2.1. 管理者を扱ってください: HS_アドミン. . . . . . . . . 10 3.2.2。 サイト情報を修理してください: HS_サイト。 . . . . . . . 14 3.2.3. 命名権威委譲サービス: HS_Na_代表. . . . . . . . . . . . . . . . . 19 3.2.4。 ハンドルを調整してください: HS_SERV。 . . . . . . . . . . . . 20 3.2.5. アリアは以下を扱います。 HS_別名. . . . . . . . . . . . . 21 3.2.6。 原発部位: HS_予備選挙. . . . . . . . . . . . 21 3.2.7。 値のリストを扱ってください: HS_VLIST… 22 4。 システムサービスモデルを扱ってください。 . . . . . . . . . . . . . . . . . 22 4.1. システムサービスの部品. . . . . . . . . . . . 23 4.1.1を扱ってください。 グローバルなハンドル登録(GHR). . . . . . . . . . 23 4.1.2。 地方のハンドルサービス(左手。). . . . . . . . . . . 26 4.2 システムミドルウェアの部品. . . . . . . . . . 27 4.2.1を扱ってください。 サービスをキャッシュするシステムを扱ってください。 . . . . . . . . . 27 4.2.2. システムProxyサーバ. . . . . . . . . . . 28 4.3を扱ってください。 システムクライアントの部品を扱ってください。 . . . . . . . . . . . . 28 5. システムオペレーション・モデルを扱ってください。 . . . . . . . . . . . . . . . . 29 5.1. システムサービスのリクエストと応答. . . . . . . 30 5.2を扱ってください。 システム認証プロトコルを扱ってください。 . . . . . . . . . 32 6. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 37 7. 承認. . . . . . . . . . . . . . . . . . . . . . . 38 8。 参照と図書目録。 . . . . . . . . . . . . . . . . . 38 9. 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 40 10。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 41
1. Introduction
1. 序論
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.
Handle Systemはインターネット資料のためのグローバルにユニークな名前としてハンドルを管理します。 それは、1995年のロバート・カーンとロバート・ウィレンスキー[22]によって元々、発想されて、論文で説明されました。 Handle Systemはハンドルが公共のインターネットの上でしっかりと決議されていて、管理されるのを許容する汎用グローバル名サービスを、提供します。 Handle Systemはサービスを2つのカテゴリに分類します: ハンドル解決サービスとハンドル管理サービス。 クライアント使用は、それらの値にハンドルに変えるために解決サービスを扱います。 ハンドル管理サービスはこれらのハンドルを管理するというクライアント要求に対処します、ハンドルを加えて、削除して、ハンドル値をアップデートするのを含んでいて。
The document "Handle System Overview" [1] provides an architectural overview of the Handle System, and its relationship to other Internet services such as DNS [2,3] and LDAP[4]. This document provides a
ドキュメント「ハンドルシステム概要」[1]はHandle Systemの建築概要、およびDNS[2、3]やLDAP[4]などの他のインターネットのサービスとのその関係を提供します。 このドキュメントはaを提供します。
Sun, et al. Informational [Page 2] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[2ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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.
Handle System名前空間の詳述、データ、サービスモデル、およびその操作はモデル化されます。 それは、読者が概要ドキュメントで説明されるようにHandle Systemに関する基本概念に詳しいと仮定します。
The namespace definition specifies the handle syntax and its semantic structure. The data model defines the data structures used by the Handle System protocol and any pre-defined data types for carrying out the handle service. The service model provides definitions of various Handle System components and explains how they work together over the network. Finally, the Handle System operation model describes its service operation in terms of messages transmitted between client and server, and the client authentication process based on the Handle System authentication protocol.
名前空間定義はハンドル構文とその意味構造を指定します。 データモデルはハンドルサービスを提供するのにHandle Systemプロトコルとどんな事前に定義されたデータ型によっても使用されるデータ構造を定義します。 サービスモデルは、様々なHandle Systemの部品の定義を提供して、それらがネットワークよりどう一緒にやり直すかを説明します。 最終的に、Handle Systemオペレーション・モデルはクライアントとサーバの間に送られたメッセージ、およびHandle System認証プロトコルに基づくクライアント認証過程に関してサービス操作について説明します。
2. Handle System Namespace
2. システム名前空間を扱ってください。
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:
ハンドルはさまざまなキャラクタから成るかもしれない文字列です。 Handle Systemのあらゆるハンドルが2つの部品から成ります: 命名権威の下で権威を命名します、続いて、ユニークな地方名を命名します。 」 「命名権威と地方名はASCII文字によって切り離され」/(八重奏0x2F。) 以下のテーブルはABNF[5]記法とのハンドル構文定義を提供します:
<Handle> = <NamingAuthority> "/" <LocalName>
」 「<ハンドル>は<NamingAuthority>と等しく」/<LocalName>。
<NamingAuthority> = *(<NamingAuthority> ".") <NAsegment>
「<NamingAuthority>が*と等しい、(<NamingAuthority>、」、」、)、<NAsegment>。
<NAsegment> = 1*(%x00-2D / %x30-3F / %x41-FF )
; any octets that map to UTF-8 encoded
; Unicode 2.0 characters except
; octets '0x2E' and '0x2F' (which
; correspond to the ASCII characters '.',
; and '/').
<NAsegment>=1*(%%x30x00-2D/3F/%x41-ff)。 UTF-8への地図がコード化したどんな八重奏も。 キャラクタが除くユニコード2.0。 '八重奏の'0x2E'と'0x2F'、(どれ、;、ASCII文字に文通してください '. ''/'、)
<LocalName> = *(%x00-FF)
; any octets that map to UTF-8 encoded
; Unicode 2.0 characters
<LocalName>は*(%x00ff)と等しいです。 UTF-8への地図がコード化したどんな八重奏も。 ユニコード2.0キャラクタ
Table 2.1: Handle syntax
テーブル2.1: 構文を扱ってください。
As shown in Table 2.1, both <NamingAuthority> and <LocalName> are UTF-8 [6] encoded character strings. The Handle System protocol mandates UTF-8 encoding for handles transferred over the wire. The <LocalName> may consist of any characters from the Unicode 2.0 standard [7]. The <NamingAuthority> may use any characters from the Unicode 2.0 standard except the ASCII character '/' (0x2F), which is
Table2.1に示されるように、<NamingAuthority>と<LocalName>の両方がコード化されたキャラクタが結ぶUTF-8[6]です。 Handle SystemはハンドルのためのUTF-8コード化がワイヤの上に移した命令について議定書の中で述べます。 <LocalName>はユニコード2.0規格[7]からのどんなキャラクタからも成るかもしれません。 '<NamingAuthority>は何かユニコードからのキャラクタにASCII文字以外の2.0規格を使用するかもしれない'/'(0x2F)、どれがありますか?
Sun, et al. Informational [Page 3] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[3ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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).
<LocalName>と<NamingAuthority>を切り離すために、予約されます。 '<NamingAuthority>は複数の非空の<NAsegment>sから成るかもしれません。それはASCII文字でそれぞれ'.'(八重奏0x2E)を切り離します。
Naming authorities are defined in a hierarchical fashion resembling a tree structure. Each node and leaf of the tree is given a label that corresponds to a naming authority segment (<NAsegment>). The parent node represents the parent naming authority. Naming authorities are constructed left to right, concatenating the labels from the root of the tree to the node that represents the naming authority. Each label (or its <NAsegment>) is separated by the character '.' (octet 0x2E). For example, the naming authority for the Digital Object Identifier (DOI) project is "10". It is a root-level naming authority as it has no parent naming authority for itself. It can, however, have many child naming authorities. For example, "10.1045" is a child naming authority of "10" for the D-Lib Magazine.
命名当局は木構造に類似している階級的なファッションで定義されます。 命名権威セグメント(<NAsegment>)に対応するラベルを木の各ノードと葉に与えます。 親ノードは権威を命名する親の代理をします。 命名当局は左で右に組み立てられます、木の根から命名権威を表すノードまでラベルを連結して。 '各ラベル(または、<NAsegment>)は'.'キャラクタ(八重奏0x2E)によって分離されます。 例えば、Digital Object Identifier(DOI)プロジェクトのための命名権威は「10インチ」です。 それはどんな親もそれで権威をそれ自体にちなんで命名しないので権威を命名する根レベルです。 しかしながら、それは多くの子供命名当局を持つことができます。 例えば、「10.1045インチは「D-リブ雑誌のための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文字は大文字と小文字を区別しないとして扱われます。
3. Handle System Data Model
3. ハンドルシステムデータモデル
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].
Handle Systemは名前から値への拘束力があるサービスオーバーに公共のインターネットを提供します。 各ハンドルで、1セットの値をそれに割り当てるかもしれません。 Handle Systemはそれぞれのハンドルの選択値群を維持して、どんなハンドル解決要求に対応してそれを返すでしょう。 Handle Systemデータモデルはこれらの値のために概念的なデータ構造を定義します。 プロトコルによって使用されるデータモデルはどんな特定の実装でもストレージに使用される正確な物理的なデータモデルでないかもしれません。 むしろ、それは「ハンドルシステムプロトコル仕様」[8]の指定されるとしてのHandle Systemプロトコルがいうことになったデータモデルです。
3.1. Handle Value Set
3.1. 選択値群を扱ってください。
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
各ハンドルで、1セットの値をそれに割り当てるかもしれません。 これらのハンドル値はデータに一般的なデータ構造を使用します。 例えば、それぞれのハンドル値には、他の値と選択値群でそれを区別するユニークな指数があります。 また、それには、データ・フィールドでデータの構文と意味論を定義する特定のデータ型があります。 これら以外に、それぞれのハンドル値は1セットのTTLや許容などの管理情報を含んでいます。 図3.1はハンドルを示しています。
Sun, et al. Informational [Page 4] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[4ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
"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} | |-
| |-
-------------------------------------------------------------
------------------------------------------------------------- | <インデックス>: 3 | ------------------------------------------------------------- | | <インデックス>: 2 | | ------------------------------------------------------------- | | | | | | | <インデックス>: 1 | | | | <タイプ>: URL| | | | <データ>: http://www.dlib.org/dlib.. 。 | | | | <TTL>: 親類:24時間| | | | <許可>: アドミン_は、公共の_が読んだと書きます。| | | | <タイムスタンプ>: 927314334000 | | | | <参照>: 空になってください。| |- | |- -------------------------------------------------------------
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です。 <データ>分野の述べられるとしてのURLデータは" http://www.dlib.org/dlib.. "です。 TTL(生きる時間)エントリーは、値の記録が再び相談されるために情報の源の24時間未満前でキャッシュされるべきであると示唆します。 読む許可をだれにも与えますが、<許可>分野はアップデートする管理者だけに値を与えます。 <参照>分野は人影がありません。 これのための資格証明書が値を扱うとき、それは他のハンドル値に参考文献一覧を含むかもしれません。
Thus a handle value may be thought of as a record that consists of a group of data fields. Each of these data fields is defined as follows:
したがって、ハンドル値はデータ・フィールドのグループから成る記録として考えられるかもしれません。 それぞれのこれらのデータ・フィールドは以下の通り定義されます:
<index>
An unsigned 32-bit integer that uniquely identifies a handle value
from other handle values.
他のハンドル値からハンドル値を唯一特定する<インデックス>An未署名の32ビットの整数。
Sun, et al. Informational [Page 5] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[5ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
<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.
値の記録のためのデータ型を特定する<タイプ>A UTF8-ストリング。 UTF-8によって続かれた4バイトの符号のない整数から成るデータ構造が文字列をコード化したので、このドキュメント中では、UTF8-ストリングが定義されることに注意してください。 整数は文字列における、八重奏の数を指定します。
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.
<タイプ>分野は次の<データ>分野でデータの構文と意味論を定義するデータ型を特定します。 データ型は、潜在的闘争を避けるためにHandle Systemに登録されるかもしれません。 Handle Systemには、登録されたデータ型のための予約された命名権威"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".
Handle Systemの下のデータ型は階層的であるかもしれません。 '階層構造の各レベルは'.'(0x2E)キャラクタなしでUTF8-ストリングで命名されるかもしれません。 '、'.'キャラクタは、階層構造レベルの間の境界をマークするのに使用されます。 例えば、「a.b」というHandle Systemデータ型はタイプ“a"の下におけるサブタイプ「b」であるとみなされるかもしれません。 同様に、<タイプ>「a.b.x」、「a.b.y」、および「a.b.z」のハンドル値は普通形階層構造「a.b」の下のハンドル値であるとみなされるかもしれません。
For any handle values, the UTF8-string in the <type> field may not
end with the '.' character. In other words, no Handle System data
type should end with the '.' character. However, the '.'
character may appear in the end of the <type> parameter in a
handle query. This is used to query for all handle values under a
common type hierarchy. For example, one may query for all handle
values under the type hierarchy "a.b" (e.g., handle values of
<type> "a.b.x", "a.b.y" and "a.b.z") by setting the <type>
parameter to "a.b.". Note here that the <type> parameter ends
with the '.' character. Details of the handle query operation can
be found in the Handle System protocol specification [8].
'いずれも>分野が終わらないかもしれない<タイプで値、UTF8-ストリングを扱う、'.'キャラクタ。 '、言い換えれば、どんなHandle Systemデータ型も終わるべきでない、'.'キャラクタ。 'しかしながら、'.'キャラクタはハンドル質問における<タイプ>パラメタの終わりに現れるかもしれません。 これはすべてのハンドル値のために普通形階層構造の下で質問するのにおいて使用されています。 例えば、すべてのハンドルのためにタイプ階層構造「a.b」(例えば、<タイプ>「a.b.x」、「a.b.y」、および「a.b.z」の値を扱う)の下で「a.b.」に<タイプ>パラメタを設定することによって、値について質問するかもしれません。 'ここで<がパラメタが終わる>をタイプすることに注意してください、'.'キャラクタ。 Handle Systemプロトコル仕様[8]でハンドル質問操作の詳細を見つけることができます。
<data>
A sequence of octets (preceded by its length in a 4-byte unsigned
integer) that describes the resource identified by the handle. The
syntax and semantics of these octets are identified by the <type>
field.
ハンドルによって特定されたリソースについて説明する八重奏(4バイトの符号のない整数における長さは先行する)の<データ>A系列。 これらの八重奏の構文と意味論は<タイプ>分野によって特定されます。
<permission>
An eight-bit bit-mask for access control of the handle value.
Access control is defined in terms of read, write, and execute
ハンドル価値のアクセスコントロールのための<の許可の>のAnの8ビットのビットマスク。 コントロールが定義されるアクセスが読まれて、書いてください、実行
Sun, et al. Informational [Page 6] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[6ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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:
一般かハンドル管理者のどちらかに適切な許容。 それぞれのハンドル値で、以下のビットのどんな組み合わせとしても許可分野を指定できます:
PUBLIC_WRITE (0x01) permission that allows anyone to
modify or delete the handle value.
だれでもハンドル値を変更するか、または削除するPUBLIC_WRITE(0×01)許可。
PUBLIC_READ (0x02) permission that allows anyone to read
the handle value.
だれでもハンドル値を読むことができるPUBLIC_READ(0×02)許可。
ADMIN_WRITE (0x04) permission that allows any handle
administrator to update or delete the
handle value.
どんなハンドル管理者もハンドル値をアップデートするか、または削除するADMIN_WRITE(0×04)許可。
ADMIN_READ (0x08)_ permission that allows the handle
value to be read by any handle
administrator with AUTHORITIVE_READ
privilege.
ハンドル値がAUTHORITIVE_READ特権をもっているどんなハンドル管理者によっても読まれるのを許容するADMIN_READ(0×08)_許可。
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(0×10)許可。 これが持って来たかもしれないセキュリティ危険のために、実装は、展開でそれを無効にすることができるようにそのような許可をサポートしないのを選ぶか、またはオプションを前提とするかもしれません。
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(0×20)許可。 ハンドル管理者はハンドルサーバに確立したアカウントを持たなければなりません。ハンドル価値の実行は、ものと同じ特権がハンドル管理者のためにアカウントに与えられていると仮定するべきです。 これが持って来たかもしれないセキュリティ危険のために、実装は、展開でそれを無効にすることができるようにそのような許可をサポートしないのを選ぶか、またはオプションを前提とするかもしれません。
Sun, et al. Informational [Page 7] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[7ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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なしでそのaハンドル価値に注意してください。そうすれば、休暇ではなく、ADMIN_READ許可缶がハンドルサーバに注意します。例えば、それは、認証目的のために秘密鍵を保存するのに使用されるかもしれません。 どちらもPUBLIC_WRITEかADMIN_WRITE許可があるハンドル値を、ハンドル値を不変にして、どんなハンドル管理者も削除できません(Handle Systemプロトコルで)。
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.
Timeを指定する4バイトの整数に従って<TTL>An八重奏が続いた、-、-値の記録を住ませてください。 それは、情報の源が再び参照されるべき前にどれくらい長い間値の記録をキャッシュできるかを説明するのに使用されます。 値の記録をそうあるだけであるべきであるTTLのための値が示すゼロを、進行中のトランザクションに使用して、キャッシュするべきではありません。 TTL値(TTLタイプに従う32ビットの符号のない整数)があとに続いたTTLタイプ(最初の八重奏では、指定される)でどんな非ゼロTTLも定義されます。 TTLタイプは、TTL値が絶対である、または相対的であるかを示します。 絶対TTL値は協定世界時0時0分0秒、1970年1月1日以来秒に関して生きる時間を定義します。 値以来秒数に関して生きるのが経過したときTTLが指定する親類はクライアントによってどんなハンドルサーバからも得られました。
<timestamp>
An 8-byte (long) integer that records the last time the value was
updated at the server. The field contains elapsed time since
00:00:00 UTC, January 1970 in milliseconds. The choice of
milliseconds is to avoid potential collision when updating the
value.
サーバで最後の時間値を記録する<のタイムスタンプの>のAnの8バイト(長い)の整数をアップデートしました。分野は協定世界時0時0分0秒以来の経過時間を含んでいます、ミリセカンドで表現される1970年1月。 ミリセカンドの選択は値をアップデートするとき、潜在的衝突を避けることです。
<reference>
A 4-byte integer followed by a list of references to other handle
values. The integer specifies the number of references in the
list. Each reference in the list refers to another handle value
in terms of a UTF8-string and a 4-byte integer (where the UTF8-
string is the handle name and the integer is the value index).
References are generally used to add credentials to the current
handle value. For example, a handle value may make itself more
trust-worthy by referring to a digital signature issued by a
commonly trusted entity.
<の参照の>のA4バイトの整数は他のハンドル値への参考文献一覧で続きました。 整数はリストの参照の数を指定します。 リストにおける各参照はUTF8-ストリングと4バイトの整数(UTF8ストリングがハンドルネームであり、整数が価値指数であるところ)に関して別のハンドル値について言及します。 一般に、参照は、現在のハンドル値に資格証明書を加えるのに使用されます。 例えば、ハンドル値で、それ自体は、一般的に信じられた実体によって発行されたデジタル署名について言及することによって、より信頼できるようになるかもしれません。
Sun, et al. Informational [Page 8] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[8ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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.
デフォルトで、Handle Systemはどんな解決の応答における公衆によって読まれた許可がある値も要求するすべてのハンドルを返します。 クライアントが特定のデータ型(ハンドルに割り当てられた例えばすべての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.
ハンドル値は、「-認可されて、読んでください」として<許可>分野を設定することによって、「民営化される」か、または「無効にされるかもしれません」。 これはアクセスをハンドルに読み込んでいる管理者だけを制限します。 そして、公衆にそれを暴露しないでどんな史料(ハンドル管理者を代表した)も保つのに「民営化された」値を使用できます。 また、そのようなアプローチは、どんな時代遅れのハンドルか権威を命名するも偶然再利用されるのを妨げるのに使用されるかもしれません。
3.2. Pre-defined Handle Data Types
3.2. 事前に定義されたハンドルデータ型
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.
あらゆるハンドル値で、<タイプ>分野でデータ型を指定しなければなりません。 Handle Systemは組織が彼らのアプリケーションのための新しいデータ型を登録できるタイプ登録サービスを提供します。 ハンドルとして命名権威"0.TYPE"の下でデータ型を登録できます。 例えば、URLデータ型はハンドル「0.TYPE/URL」としてHandle Systemの下に登録されます。 ハンドルには、RFC1738[9](URLの構文と意味論を定義するIETFの標準のドキュメント)について言及するハンドル値があるかもしれません。
The Handle System pre-defines a set of data types to carry out the handle service. For example, HS_ADMIN is a pre-defined data type used to describe handle administrators or administrator groups. HS_SITE is a pre-defined data type to describe the service interface of any Handle System service component. The following sections provide detailed descriptions of these pre-defined data types under the Handle System.
Handle Systemは、ハンドルサービスを提供するために1セットのデータ型を事前に定義します。 例えば、HS_ADMINはハンドル管理者か管理者グループについて説明するのに使用される事前に定義されたデータ型です。 HS_SITEはどんなHandle Systemサービスの部品のサービスインタフェースについても説明する事前に定義されたデータ型です。 以下のセクションはこれらの事前に定義されたデータ型の詳述をHandle Systemの下に供給します。
Sun, et al. Informational [Page 9] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[9ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
3.2.1. Handle Administrator: HS_ADMIN
3.2.1. 管理者を扱ってください: HS_アドミン
Each handle has one or more administrators. Any administrative operation (e.g., add, delete or modify handle values) can only be performed by the handle administrator with adequate privilege. Handle administrators are defined in terms of HS_ADMIN values. Every handle must have at least one HS_ ADMIN value that defines its administrator. Each HS_ADMIN value can be used to define a set of handle administrators sharing the same administration privilege. Handles with multiple administrators of different privileges may have multiple HS_ADMIN values. HS_ADMIN values are used by the Handle System to authenticate handle administrators before fulfilling any handle administration request.
各ハンドルには、1人以上の管理者がいます。 ハンドル管理者は適切な特権でどんな管理操作(例えば、ハンドル値を加えるか、削除するか、または変更する)も実行できるだけです。 ハンドル管理者はHS_ADMIN値で定義されます。 あらゆるハンドルには、管理者を定義する少なくとも1つのHS_ADMIN値がなければなりません。 同じ管理特権を共有している1セットのハンドル管理者を定義するのにそれぞれのHS_ADMIN値を使用できます。 異なった特権の複数の管理者がいるハンドルには、複数のHS_ADMIN値があるかもしれません。 HS_ADMIN値は、どんなハンドル管理要求も実現させる前にハンドル管理者を認証するのにHandle Systemによって使用されます。
Naming authorities, as described above, are themselves registered as handles under the reserved naming authority "0.NA". These handles are referred to as naming authority handles. Administrators for any naming authority are defined as the administrators of the corresponding naming authority handle. For example, "0.NA/10" is the naming authority handle for the naming authority "10". Hence any administrator for the naming authority handle "0.NA/10" is also the administrator for the naming authority "10". Naming authority administrators are the only ones who can create handles or sub- naming authorities under the naming authority. A sub-naming authority may define its own set of administrators to create handles or further levels of sub-naming authorities. For example, the naming authority "10.1045" may have a totally different group of administrators from its parent naming authority "10".
上で説明される命名当局は予約された命名権威"0.NA"の下でハンドルの登録が済んでいます。 これらのハンドルは権威をハンドルと命名すると呼ばれます。 どんな命名権威のための管理者も対応する命名権威ハンドルの管理者と定義されます。 例えば、「0.NA/10インチは命名権威「10インチ」命名権威ハンドルです。 したがって、命名権威ハンドルのためのどんな管理者、も「また、0.NA/10インチは命名権威「10インチ」管理者です。 命名権威管理者は命名権威の下でハンドルかサブ命名当局を創設できる唯一の人です。 サブ命名権威は、ハンドルかさらなるレベルのサブ命名当局を創設するためにそれ自身の管理者のセットを定義するかもしれません。 例えば、命名権威、「10.1045インチには、「10インチ」と権威を命名する親からの管理者の完全に異なったグループがあるかもしれません。
An HS_ADMIN value is a handle value whose <type> field is HS_ADMIN and whose <data> field consists of the following entries:
HS_ADMIN値は<タイプ>分野がHS_ADMINであり、<データ>分野が以下のエントリーから成るハンドル値です:
<AdminRef>
A reference to a handle value. The reference consists of the
handle name (a UTF8-string) followed by a 4-byte unsigned integer
for the handle value index. The handle value identifies the set
of administrators for the handle.
ハンドル値の<AdminRef>A参照。 参照は4バイトの符号のない整数がハンドル価値指数のためにあとに続いたハンドルネーム(UTF8-ストリング)から成ります。 ハンドル値はハンドルのために管理者のセットを特定します。
<AdminPermission>
A 16-bit bit-mask that defines the administration privilege of the
set of handle administrators identified by the HS_ADMIN value.
HS_ADMIN値によって特定されたハンドル管理者のセットの管理特権を定義する<のAdminPermissionの>のA16ビットのビットマスク。
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
<AdminRef>エントリーはハンドル管理者を認証するのに使用できるハンドル値について言及します。 そのようなハンドル値はハンドル管理者参照と呼ばれます。 ハンドル管理者参照はハンドル管理者によって提供された秘密鍵、公開鍵、またはX.509証明書[10]を含むかもしれません。 例えば、<AdminRef>エントリーはハンドル管理者参照を含むかもしれません。
Sun, et al. Informational [Page 10] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[10ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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.
<タイプ>分野がDSS_WITH_DES_CBC_SHAであり、<データ>分野はCipher Block Chaining(CBC)運転モード[12、13]における使用のためのDES秘密鍵[11]を含んでいます。 秘密鍵はハンドルサーバによって使用されて、ハンドル管理者を認証できます。 より強い暗号アルゴリズムのために、ハンドル管理者参照は、1セットのTriple-DESキー[23]を含んでいて、<タイプ>にデスEDE3-WITH-CBCであるように設定するかもしれません。
A single handle may be assigned with both the HS_ADMIN value and the handle administrator reference. In other words, the <AdminRef> entry may refer to a handle value assigned to the same handle that has the HS_ADMIN value. In this case, authentication of the handle administrator does not rely on any other handles. Alternatively, the handle administrator reference may be a handle value under a different handle. Thus HS_ADMIN values from different handles may share a common handle administrator reference. This feature allows sharing of handle administrators among different handles. The handle administrator reference contains the secret key, public key, or X.509 certificate provided by the administrator of these handles.
単一のハンドルはHS_ADMIN価値とハンドル管理者参照の両方で割り当てられるかもしれません。 言い換えれば、<AdminRef>エントリーはHS_ADMIN値を持っているのと同じハンドルに割り当てられたハンドル値について言及するかもしれません。 この場合、ハンドル管理者の認証はいかなる他のハンドルも当てにしません。 あるいはまた、ハンドル管理者参照は異なったハンドルの下のハンドル値であるかもしれません。 したがって、異なったハンドルからのHS_ADMIN値は一般的なハンドル管理者参照を共有するかもしれません。 この特徴は、異なったハンドルの中でハンドル管理者と共有するのを許容します。 ハンドル管理者参照はこれらのハンドルの管理者によって提供された秘密鍵、公開鍵、またはX.509証明書を含んでいます。
Handle administrator reference may be of type HS_VLIST and has its <data> field contain a list of references to other handle values. Each of these handle values defines a handle administrator reference. The HS_VLIST value defines an administrator group. Each handle administrator reference from the HS_VLIST is a member of the administrator group. Each handle value reference is defined in terms of a <handle>:<index> pair. An administrator group may also contain other administrator groups as its members. This allows administrator groups to be defined in a hierarchical fashion. Care must be taken, however, to avoid cyclic definition of administrators or administrator groups. Multiple levels of administrator groups should be avoided due to their lack of efficiency, but will not be signaled as an error. Client software should be prepared to detect any potential cyclic definition of administrators or <AdminRef> entries that point to non-existent handle values and treat them as an error.
ハンドル管理者参照で、他のハンドル値にタイプHS_VLISTにはあるかもしれなくて、<データ>分野は参考文献一覧を含みます。 それぞれのこれらのハンドル値はハンドル管理者参照を定義します。 HS_VLIST値は管理者グループを定義します。 HS_VLISTからのそれぞれのハンドル管理者参照は管理者グループのメンバーです。 それぞれのハンドル値の参照は<ハンドル>に関して定義されます: <インデックス>組。 また、管理者グループはメンバーとして他の管理者グループを含むかもしれません。 これは、管理者グループが階級的なファッションで定義されるのを許容します。 しかしながら、管理者か管理者グループの周期的な定義を避けるために注意しなければなりません。 複数のレベルの管理者グループは、それらの効率の不足のため避けられるべきですが、誤りとして合図されないでしょう。 クライアントソフトウェアは管理者か実在しないハンドル値を示して、誤りとしてそれらを扱う<AdminRef>エントリーのあらゆる潜在的周期的な定義を検出するように準備されるべきです。
A handle can have multiple HS_ADMIN values, each of which defines a different handle administrator. Different administrators can play different roles or be granted different permissions. For example, the naming authority handle "0.NA/10" may have two administrators, one of which may only have permission to create new handles under the naming authority, while the other may have permission to create new sub-naming authorities (e.g., "10.1045"). The set of possible permissions for a handle administrator is defined as follows:
ハンドルは複数のHS_ADMIN値を持つことができます。それはそれぞれ異なったハンドル管理者を定義します。 異なった管理者は、異なる役割をプレーするか、または異なった許容を承諾できます。 例えば、命名権威ハンドル、「0.NA/10インチには、2人の管理者がいるかもしれません、命名権威の下で新しいハンドルを作成する許可を持っているだけであるかもしれないものの1つ、もう片方に新しいサブ命名当局を創設する許可があるかもしれませんが(例えば、「10.1045インチ)、」 ハンドル管理者にとって、可能な許容のセットは以下の通り定義されます:
Add_Handle (0x0001)
This permission allows naming authority administrator to create new
handles under a given naming authority.
与えられた命名権威の下で新しいハンドルを作成するために権威を管理者に任命して、_この許可が許容するHandle(0×0001)を加えてください。
Sun, et al. Informational [Page 11] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[11ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
Delete_Handle (0x0002)
This permission allows naming authority administrator to delete
handles under a given naming authority.
与えられた命名権威の下でハンドルを削除するために権威を管理者に任命して、_この許可が許容するHandle(0×0002)を削除してください。
Add_NA (0x0004)
This permission allows the naming authority administrator to create
new sub-naming authorities.
_この許可で新しいサブ命名当局を命名権威管理者を創設するNA(0×0004)を加えてください。
Delete_NA (0x0008)
This permission allows naming authority administrator to delete an
existing sub-naming authority.
既存のサブ命名権威を削除するために権威を管理者に任命して、_この許可が許容するNA(0×0008)を削除してください。
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.
_この許可でHS_ADMIN値以外のどんなハンドル値もハンドル管理者を変更するValue(0×0010)を変更してください。 HS_ADMIN値は、ハンドル管理者を定義するのに使用されて、異なった許容で管理されます。
Delete_Value (0x0020)
This permission allows handle administrator to delete any handle
value other than the HS_ADMIN values.
_この許可でHS_ADMIN値以外のどんなハンドル値もハンドル管理者を削除するValue(0×0020)を削除してください。
Add_Value (0x0040)
This permission allows handle administrator to add handle values
other than the HS_ADMIN values.
_ハンドル管理者がこの許可で加えることができるValue(0×0040)がHS_ADMIN値以外の値を扱うと言い足してください。
Modify_Admin (0x0080)
This permission allows handle administrator to modify HS_ADMIN
values.
_この許可でHS_ADMIN値をハンドル管理者を変更するAdmin(0×0080)を変更してください。
Remove_Admin (0x0100)
This permission allows handle administrator to remove HS_ADMIN
values.
_この許可でHS_ADMIN値をハンドル管理者を取り除くAdmin(0×0100)を取り外してください。
Add_Admin (0x0200)
This permission allows handle administrator to add new HS_ADMIN
values.
_この許可が許容するAdmin(0×0200)が新しい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.
_認可されて、この許可が与えるRead(0×0400)はADMIN_READと共にハンドル値にアクセスを読み込んでいる管理者許可を扱います。 これのない許可には認証を必要とする値を扱うアクセスがない管理者はアクセサリーを読みます。
LIST_Handle (0x0800)
This permission allows naming authority administrator to list
handles under a given naming authority.
与えられた命名権威の下でハンドルを記載するために権威を管理者に任命するこの許可が許容するLIST_Handle(0×0800)。
Sun, et al. Informational [Page 12] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[12ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
LIST_NA (0x1000)
This permission allows naming authority administrator to list
immediate sub-naming authorities under a given naming authority.
与えられた命名権威の下で即座のサブ命名当局を記載するために権威を管理者に任命するこの許可が許容するLIST_NA(0×1000)。
Administrator permissions are encoded in the <AdminPermission> entry in the <data> field of any HS_ADMIN value. Each permission is encoded as a bit flag. The permission is granted if the flag is set to 1, otherwise it is set to 0.
管理者許容はどんなHS_ADMIN価値の<データ>分野での<AdminPermission>エントリーでもコード化されます。 少し弛むとき、各許可はコード化されます。 1に旗を設定するなら、許可を与えます。さもなければ、0にそれを設定します。
Figure 3.2.1 shows an example of HS_ADMIN value that defines an administrator for the naming authority handle "0.NA/10". In figure 3.2.1, a naming authority administrator is identified by an HS_ADMIN value assigned to the naming authority handle "0.NA/10". The administrator can be authenticated based on the handle value "0.NA/10":3, which is the handle value assigned to the naming authority handle "0.NA/10" and has its index set to 3. The handle value "0.NA/10":3 may contain the secret or public key used by the administrator. The administrator is granted permission to add, delete, or modify sub-naming authorities under "10", and add or delete handles directly under the naming authority. The administrator may also add, delete, or modify any handle values assigned to the naming authority handle except those HS_ADMIN values. In other words, the administrator is not allowed to add, delete, or modify any administrators for the naming authority.
評価する.1がHS_ADMINに関する例にそれを示す図3.2が管理者を命名権威ハンドル「0.NA/10インチ」定義します。 図では、3.2に、.1、命名権威管理者は命名権威ハンドル「0.NA/10インチ」に割り当てられたHS_ADMIN値によって特定されます。 ハンドル値に基づいて管理者を認証できる、「0.NA/10インチ: 3、「0.NA/10インチ、インデックスセットを3まで持っている、」。3は命名権威ハンドルに割り当てられたハンドル値です。 値を扱ってください。「0.NA/10インチ: 3は管理者によって使用された秘密か公開鍵を含むかもしれません」。 サブ命名当局を加えるか、削除するか、または変更する許可を管理者に与える、「10インチ、命名権威の直接下でハンドルを加えるか、または削除してください、」 また、管理者は、それらのHS_ADMIN値を除いて、命名権威ハンドルに割り当てられたどんなハンドル値も、加えるか、削除するか、または変更するかもしれません。 言い換えれば、命名権威のためにどんな管理者も加えることができないか、削除できないか、管理者は変更できません。
-------------------------------------------------------------
------------------------------------------------------------- |
------------------------------------------------------------- | |
| | | |
| <index>: 2 | | |
| <type>: HS_ADMIN | | |
| <data>: | | |
| <AdminRef>: "0.NA/10": 3 | | |
| <AdminPerm>: Add_NA, Delete_NA, | | |
| Add Handle, Delete_Handle, | | |
| Add_Value, Delete_Value, Modify_Value, | | |
| Authorized_Read, List_Handle, List_NA | | |
| | | |
| <TTL>: 24 hours | | |
| <permission>: PUBLIC_READ, ADMIN_WRITE | | |
| <reference>: {empty} | |-
| |-
-------------------------------------------------------------
------------------------------------------------------------- ------------------------------------------------------------- | ------------------------------------------------------------- | | | | | | | <インデックス>: 2 | | | | <タイプ>: HS_アドミン| | | | <データ>: | | | | <AdminRef>: 「0.NA/10インチ:」 3 | | | | <AdminPerm>: _Naを加えてください、そして、_Naを削除してください。| | | | ハンドルを加えてください、そして、_ハンドルを削除してください。| | | | _価値を高めてください、そして、_値を削除してください、そして、_値を変更してください。| | | | 読まれた、認可された_、リスト_ハンドルは_Naを記載します。| | | | | | | | <TTL>: 24時間| | | | <許可>: アドミン_は、公共の_が読んだと書きます。| | | | <参照>: 空になってください。| |- | |- -------------------------------------------------------------
Figure 3.2.1: Administrator for the naming authority
handle "0.NA/10"
図3.2.1: 命名権威ハンドル「0.NA/10インチ」管理者
Sun, et al. Informational [Page 13] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[13ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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値はハンドルサーバによって使用されて、どんな管理要求も実現させる前に、ハンドル管理者を認証します。 クライアントにはハンドル管理者参照のどれかにおけるものに合っている秘密鍵(または、秘密鍵)の所持があるかどうかチェックすることによって、サーバはクライアントを認証します。 認証がHandle System認証プロトコルで後述のように本書では行われます。
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.
_ADMIN値が認証を必要とするかもしれないHSは、データの公共の暴露を防ぐためにアクセスを読みます。 さらに、アドミニストレータの秘密鍵を含むハンドル管理者参照はPUBLIC_READもキーがサーバを残すのを防ぐADMIN_READ許可も持つべきではありません。
3.2.2. Service Site Information: HS_SITE
3.2.2. サイト情報を修理してください: HS_サイト
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.
Handle Systemはまた、Global Handle Registryとして知られている、ただ一つの分配されたグローバルなハンドルサービス(GHR)、およびLocal Handle Servicesの無制限な数(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.,
それぞれのサービスサイトはHS_SITE値によって定義されます。 HS_SITEは事前に定義されたHandle Systemデータ型です。 HS_SITE値がそれらのサービス構成に伴うサイトを包括するサーバー・コンピュータ(例えば、IPアドレス)を特定することによってサービスサイトを定義する、(例えば。
Sun, et al. Informational [Page 14] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[14ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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値のセットは命名権威のためのサービス情報と呼ばれます。
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を見てください)。 Handle Systemのクライアントは、彼らが自分達のサービスのリクエストを送ることができる前に原因となるハンドルサーバの場所を見つけるようにサービス情報を当てにします。 また、クライアントは、ハンドルサーバからどんなサービス応答も認証するのにサービス情報を使用できます。
An HS_SITE value is a handle value whose <type> field is HS_SITE and whose <data> field consists of the following entries:
HS_SITE値は<タイプ>分野がHS_SITEであり、<データ>分野が以下のエントリーから成るハンドル値です:
<Version>
A 2-byte value that identifies the version number of the HS_SITE.
The version number identifies the data format used by the HS_SITE
value. It is defined to allow backward compatibility over time.
This document defines the HS_SITE with version number 0.
HS_SITEのバージョン番号を特定する<のバージョンの>のA2バイトの価値。 バージョン番号はHS_SITE値によって使用されるデータの形式を特定します。 それは、時間がたつにつれて後方の互換性を許容するために定義されます。 このドキュメントはバージョンNo.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の>のA2バイトの整数価値。 価値の、より高いバイトは主要なバージョンを特定します、そして、下位バイトは小さい方のバージョンを特定します。 Handle Systemプロトコルの詳細は[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.
HS_SITE値が得る(そして、0を通して巻きつけるかもしれません)毎回を1つ増強する<のSerialNumberの>のA2バイトの整数価値が変化しました。 それは、クライアントとサーバの間のHS_SITE値を同期させるのにHandle Systemプロトコルに使用されます。
<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
ハンドルサービスの原発部位を特定する<のPrimaryMaskの>のAnの8ビットのマスク。 八重奏の最初のビットは<MultiPrimary>ビットです。 それは、ハンドルサービスには複数の原発部位があるかどうかを示します。 八重奏の2番目のビットは<PrimarySite>ビットです。 それは、HS_SITE値が原発部位であるかどうかを示します。 原発部位はハンドルのために管理操作をサポートするものです。 値がない<MultiPrimary>エントリーは、ハンドルサービスにはただ一つの原発部位があるのを示します、そして、すべてのハンドル管理がそのサイトで終わらなければなりません。 非ゼロ<MultiPrimary>エントリーは、ハンドルサービスには複数の原発部位があるのを示します。 各予備選挙
Sun, et al. Informational [Page 15] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[15ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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.
サイトは、ハンドルサービスで管理されたハンドルを管理するのに使用されるかもしれません。 そのようなサービスで管理されたハンドルは、セクション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>An8ビット・オクテット。 妥当な選択肢はHASH_BY_NA(0×00)、HASH_BY_LOCAL(0×01)、またはHASH_BY_HANDLE(0×02)を含んでいます。 これらのオプションは、ハッシュ操作がハンドル、または全体のハンドルでハンドルの命名権威一部、または地方名部分だけに付けられるだけであるべきであるかどうかをそれぞれ示します。 アルゴリズム[14]を論じ尽くす標準のMD5はそれぞれのサービスサイトによって使用されて、サーバにハンドルを分配します。
<HashFilter>
An UTF8-string entry reserved for future use.
今後の使用のために控えられた<HashFilter>An 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の>のA4バイトの整数はUTF8-ストリング組のリストで続きました。 整数は続くUTF8-ストリング組の数を示します。 それぞれのUTF8-ストリング組は<属性>です: <値の>組。 それらは、サービスサイトの文字通りの説明を加えるのに使用されます。 例えば、<属性>が「組織」であるなら、<値の>はサービスサイトをホスティングする組織の記述を含むはずです。 他の<属性>sは、互いとサービスサイトを区別するのを助けるために定義されるかもしれません。
<NumOfServer>
A 4-byte integer that defines the number of servers in the service
site. The entry is followed by a list of <ServerRecord>s. Each
<ServerRecord> defines a handle server that is part of the service
site. Each <ServerRecord> consists of the following data fields:
サービスサイトのサーバの数を定義する<のNumOfServerの>のA4バイトの整数。 <ServerRecord>sのリストはエントリーのあとに続いています。 それぞれの<ServerRecord>はサービスサイトの一部であるハンドルサーバを定義します。 それぞれの<ServerRecord>は以下のデータ・フィールドから成ります:
<ServerRecord> ::= <ServerID>
<Address> <PublicKeyRecord> <ServiceInterface>
<ServerRecord>:、:= <ServerID><アドレス><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>A、サービスサイトの下で唯一サーバプロセスを特定する4バイトの符号のない整数。 >sがする<ServerIDは初めに、持っていません。1と彼らは、一連番号であることを持っていません。 それらは、互いとサービスサイトの下におけるサーバを区別するのに使用されます。 それぞれ異なった<ServerID>でどんな与えられたコンピュータでもある複数のサーバがあることができることに注意してください。
Sun, et al. Informational [Page 16] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[16ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
<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の>のA4バイトの整数はサーバの公開鍵を含むバイト配列で続きました。 整数はバイト配列のサイズを指定します。 バイト配列(パブリックキーのための)は3つの部品から成ります: 主要なタイプについて説明するUTF8-ストリング、2バイトのオプション・フィールドは未来に使用、および公開鍵自体を含むバイト配列を控えました。 例えば、UTF8ストリング「DSA_パブ_キー」は、<PublicKeyRecord>がDSA公開鍵を含むのを示します。 そして、ハンドル「0.type/DSA_パブ_キー」からバイト配列で主要なDSAのストレージ形式を見つけることができました。 ハンドルサーバからどんなサービス応答も認証するのに<PublicKeyRecord>の公開鍵を使用できます。
The <PublicKeyRecord> may also contain an X.509 certificate.
This happens if the key type field contains the UTF8-String
"CERT.X509". In this case, "CERT.X509" will map to the handle
"0.TYPE/CERT.X509". The handle may contain information that
describes the syntax and semantics of the public key or its
certificate. Additional key type may also be registered (as
handles under "0.TYPE") to further distinguish different kinds
of X.509 certificates. For example, "CERT.X509.DSA" may be
used to denote X.509 certificates that contain DSA public keys.
If the key type field of a <PublicKeyRecord> declares
"CERT.X509.DSA", the <PublicKeyRecord> must contain a X.509
certificate with a DSA public key in it."
また、<PublicKeyRecord>はX.509証明書を含むかもしれません。 主要なタイプ分野がUTF8-ストリング"CERT.X509"を含んでいるなら、これは起こります。 この場合、"CERT.X509"は"0.TYPE/CERT.X509"をハンドルに写像するでしょう。 ハンドルは公開鍵かその証明書の構文と意味論について説明する情報を含むかもしれません。 また、追加主要なタイプは、さらに異種のX.509証明書を区別するために示されるかもしれません("0.TYPE"の下のハンドルとして)。 例えば、"CERT.X509.DSA"は、DSA公開鍵を含むX.509証明書を指示するのに使用されるかもしれません。 「<PublicKeyRecord>の主要なタイプ分野が"CERT.X509.DSA"を宣言するなら、<PublicKeyRecord>はDSA公開鍵がそれにあるX.509証明書を含まなければなりません。」
<ServiceInterface> ::= <InterfaceCounter>
* [ <ServiceType>
<TransmissionProtocol>
<PortNumber> ]
<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>はインタフェースがハンドル解決(0×01)、ハンドル管理(0×02)、または両方のためのものであるかを指定する八重奏(しばらくマスクとしての)です。 また、<TransmissionProtocol>はトランスミッションプロトコルを指定する八重奏(しばらくマスクとしての)です。 可能なトランスミッションプロトコルはTCP(0×01)、UDP(0×02)、およびHTTP(0×04)を含んでいます。 The
Sun, et al. Informational [Page 17] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[17ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
<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インチ」の下でハンドル解決と管理サービスをあらゆるハンドルに供給します。 最初のサーバ記録(ServerID0)は2つのサービスインタフェース、ハンドル解決のための1つとハンドル管理のためのもう片方を示しています。 各インタフェースには、それ自身のポートがあります。
Each server within a service site is responsible for a subset of handles managed by the handle service. Clients can find the responsible server by performing a common hash-operation. The hash- operation will first convert all ASCII characters in the handle into upper-case. It then applies the MD5 hashing upon the portion of the converted handle string (according to the <HashOption> entry). The result is a 16-byte integer. The absolute value of the integer will be divided by the number of servers (specified in the <NumOfServer> entry). The remainder is the sequence number (starting with zero) of the <ServerRecord> listed in the HS_SITE value. From the <ServerRecord>, clients can find the IP address of the handle server for their handle requests.
サービスサイトの中のそれぞれのサーバはハンドルサービスで管理されたハンドルの部分集合に原因となります。 クライアントは、一般的なハッシュ操作を実行することによって、原因となるサーバを見つけることができます。 ハッシュ操作は最初に、ハンドルのすべてのASCII文字を大文字に変換するでしょう。 そして、それは変換されたハンドルストリングの一部にMD5の論じ尽くすことを付けます(<HashOption>エントリーに従って)。 結果は16バイトの整数です。 サーバ(<NumOfServer>エントリーでは、指定される)の数は整数の絶対値に割られるでしょう。 残りはHS_SITE値で記載された<ServerRecord>の一連番号(ゼロから始まる)です。 <ServerRecord>から、クライアントは彼らのハンドル要求のためのハンドルサーバのIPアドレスを見つけることができます。
Sun, et al. Informational [Page 18] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[18ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
------------------------------------------------------------
------------------------------------------------------------ |
----------------------------------------------------------- | |
| | | |
| <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} | |-
| |-
-----------------------------------------------------------
------------------------------------------------------------ ------------------------------------------------------------ | ----------------------------------------------------------- | | | | | | | <インデックス>: 2 | | | | <タイプ>: HS_サイト| | | | <データ>: | | | | バージョン: 0 | | | | ProtocolVersion: 2.1 | | | | SerialNumber: 1 | | | | PrimaryMask: | | | | MultiPrimary: 誤る| | | | PrimarySite: 本当| | | | HashOption: _ハンドルによるハッシュ_| | | | HashFilter: 空のUTF8-ストリング| | | | AttributeList: 0はどんな属性でも続きませんでした。| | | | NumOfServer: 3 | | | | <ServerRecord>のリストはあとに続いています。| | | | | | | | ----------------------------------------- | | | | ------------------------------------------ | | | | | ------------------------------------------ || | | | | | ServerID: 1 ||| | | | | | アドレス: :FFFF: 132.151 .1、.155||| | | | | | PublicKeyRecord: HS_DSAKEY、iQCuR2R.。 ||| | | | | | ServiceInterface||| | | | | | ServiceType: 解決だけ||| | | | | | TransmissionProtocol: TCP&UDP||| | | | | | PortNumber: 2641 ||| | | | | | ||| | | | | | ServiceType: アドミン専用||| | | | | | TransmissionProtocol: TCP|| | | | | | PortNumber: 2642 | | | | | ------------------------------------------ | | | | | | | | <TTL>: 24時間| | | | <許可>: アドミン_は、公共の_が読んだと書きます。| | | | <参照>: 空になってください。| |- | |- -----------------------------------------------------------
Fig. 3.2.2: The primary service site for the naming authority "10"
図3.2.2: 命名権威「10インチ」一次業務サイト
3.2.3. Naming Authority Delegation Service: HS_NA_DELEGATE
3.2.3. 命名権威委譲サービス: HS_Na_代表
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は事前に定義されたHandle Systemデータ型です。 それには、HS_SITE値と全く同じ形式があります。 HS_SITE値のように、HS_NA_DELEGATE値は、LHSのサービスサイトについて説明するのに使用されます。
Sun, et al. Informational [Page 19] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[19ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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への管理と権威を命名しながら、指定するハンドルと権威を命名するのに割り当てられるかもしれません。 1セットの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について説明する1セットのHS_NA_DELEGATE値で命名権威ハンドル"0.NA/foo.bar"を割り当てるかもしれません。 "foo.bar.baz"などのようにLHSから命名権威ハンドル"0.NA/foo.bar.baz"について質問することによって"foo.bar"のどんな子供命名権威のサービス情報も見つけることができるDELEGATE値が示すHS_NA_のセット。
3.2.4. Service Handle: HS_SERV
3.2.4. ハンドルを調整してください: HS_SERV
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.
1セットのHS_SITE値でどんなグローバルであるか、または地方であることのハンドルサービスも、定義できます。 これらのHS_SITE値を直接関連命名権威ハンドルに割り当てるかもしれませんか、またはサービスハンドルの使用で追加レベルの間接指定を導入するかもしれません。 サービスハンドルはハンドルサービスのための名前として考えられるかもしれません。 それは、ハンドルサービスのためにHS_SITE値を維持するのに使用されて、HS_SERV値で命名権威ハンドルから参照をつけられるかもしれません。 HS_SERV値は<タイプ>分野がHS_SERVであり、<データ>分野がサービスハンドルの参照を含むハンドル値です。 HS_SERV値は原因となるハンドルサービスにクライアントを差し向けるために権威をハンドルと命名するのに通常割り当てられます。
Use of service handle allows sharing of service information among multiple naming authorities. It also allows changes to service configuration (e.g., adding a new site) to be made in one place rather than in every naming authority handle involved. The mechanism may also be used to support service referral from one handle service to another for whatever reason.
サービスハンドルの使用で、複数の命名当局でサービス情報を共有します。 また、それは、サービス構成(例えば、新しいサイトを加える)への変更が権威ハンドルがかかわったあらゆる命名でというよりむしろ1つの場所で行われるのを許容します。 また、メカニズムは、いかなる理由でも別のものに対する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」とサブ命名当局のどれかを扱うと主張するために作成されるかもしれません。
Sun, et al. Informational [Page 20] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[20ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
Similarly, a service handle "0.SERV/a.b.c" may be created to host the service information for the handle service that manages handles under the naming authority "a.b.c".
同様に、サービスハンドル「0.SERV/a.b.c」は、命名権威「a.b.c」の下でハンドルを管理するハンドルサービスのためのサービス情報をホスティングするために作成されるかもしれません。
The use of service handles raises several special considerations. Multiple levels of service handle redirection should be avoided due to their lack of efficiency, but are not signaled as an error. Looped reference of service handles or HS_SERV values that point to non-existent service handles should be caught and error conditions passed back to the user.
サービスハンドルの使用はいくつかの特別な問題を提起します。 サービスハンドルリダイレクションの複数のレベルは、それらの効率の不足のため避けられるべきですが、誤りとして合図されません。 実在しないサービスハンドルを示すサービスハンドルかHS_SERV値の輪にされた参照は捕らえられるべきでした、そして、エラー条件はユーザに終わって戻りました。
3.2.5. Alias Handle: HS_ALIAS
3.2.5. アリアは以下を扱います。 HS_アリア
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.
実際には、デジタルオブジェクトにはオブジェクトを特定する複数の名前があるのは、非常に可能です。 Handle Systemは事前に定義されたデータ型を通したそのような特徴にHS_アリアをサポートします。 HS_アリア値は<タイプ>分野がHS_アリアであり、<データ>分野が別のハンドルの参照を含むハンドル値です。 HS_アリア値があるハンドルはHS_アリア値で参照をつけられるハンドルへの別名ハンドルです。 別名ハンドルには、HS_アリア以外のどんな追加ハンドル値か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_アリア値を取り戻すかもしれません。 これは、問題のハンドルが別名ハンドルであることを示します。 そして、クライアントはHS_アリア値で最終的な結果を得るまで指定されたハンドルに対して質問を再試行するかもしれません。
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_アリア値を新たに作成されたハンドルに向けるかもしれません。
3.2.6. Primary Site: HS_PRIMARY
3.2.6. 原発部位: HS_予備選挙
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
HS_PRIMARYはどんな与えられたハンドルのためにも一次業務サイトを指定するのに使用される事前に定義されたデータ型です。 複数の一次業務サイトによるハンドルサービスはマルチ一次業務と呼ばれます。 そうではありません
Sun, et al. Informational [Page 21] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[21ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
it is called a single-primary service. Each handle managed by a multi-primary handle service may specify its primary service sites in terms of an HS_PRIMARY value. A HS_PRIMARY value is a handle value whose <type> field is HS_PRIMARY and whose <data> field contains a list of references to HS_SITE values. Each of these HS_SITE defines a primary service site for the handle.
それはただ一つの一次業務と呼ばれます。 マルチプライマリのハンドルサービスで管理された各ハンドルはHS_PRIMARY値に関して一次業務サイトを指定するかもしれません。 HS_PRIMARY値は<タイプ>分野がHS_PRIMARYであり、<データ>分野がHS_SITE値に参考文献一覧を含むハンドル値です。 それぞれのこれらのHS_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値も必要としません、そして、どんなそのような値も無視されるべきです。
3.2.7. Handle Value List: HS_VLIST
3.2.7. 値のリストを扱ってください: HS_VLIST
HS_VLIST is a pre-defined data type that allows a handle value to be used as a reference to a list of other handle values. An HS_VLIST value is a handle value whose <type> is HS_VLIST and whose <data> consists of a 4-byte unsigned integer followed by a list of references to other handle values. The integer specifies the number of references in the list. The references may refer to handle values under the same handle or handle values from any other handles. Each reference is encoded as an UTF8-string followed by a 4-byte unsigned integer that identifies the referenced handle and its value index.
HS_VLISTはハンドル値が他のハンドル値のリストの参照として使用されるのを許容する事前に定義されたデータ型です。 HS_VLIST値は<タイプ>がHS_VLISTであり、<データ>が参考文献一覧が他のハンドル値にあとに続いた4バイトの符号のない整数から成るハンドル値です。 整数はリストの参照の数を指定します。 参照は、同じハンドルの下で値を扱うか、またはいかなる他のハンドルからも値を扱うのに参照されるかもしれません。 参照をつけられたハンドルとその価値指数を特定する4バイトの符号のない整数に従ってUTF8-ストリングが続いて、各参照はコード化されます。
HS_VLIST values may be used to define administrator groups for handles. In this case, each reference in the HS_VLIST defines a member of the administrator group and the HS_VLIST value identifies the group as a whole. Client software must be careful, however, to avoid cyclic definition of value references.
HS_VLIST値は、ハンドルのために管理者グループを定義するのに使用されるかもしれません。 この場合、HS_VLISTでの各参照は管理者グループのメンバーを定義します、そして、HS_VLIST値はグループ全体を特定します。 しかしながら、クライアントソフトウェアは値の参照の周期的な定義を避けるのに慎重であるに違いありません。
4. Handle System Service Model
4. ハンドルシステムサービスモデル
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.
Handle Systemは分配されたグローバル名サービスです。 それはLocal Handle Services(LHS)の独身の分配されたGlobal Handle Registry(GHR)と無制限な数から成ります。 これらのサービスコンポーネントはHandle Systemクライアントの部品を代表して名前サービス(解決と管理の両方)を提供します。 また、ハンドルSystemクライアントの部品は、効率に、Handle Systemミドルウェアの部品(例えば、サービスをキャッシュするHandle System)を使用するのを選ぶかもしれません。 このセクションはこれらのコンポーネントと互いとのそれらの関係について説明します。
Sun, et al. Informational [Page 22] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[22ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
4.1. Handle System Service Components
4.1. システムサービスの部品を扱ってください。
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.
Handle Systemは階層的なサービスモデルを定義します。 トップレベルに、また、Global Handle Registry(GHR)として知られているただ一つの分配されたグローバルなハンドルサービスがあります。 GHRの下に、いろいろなLocal Handle Services(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.
ハンドルSystemサービスの部品は、どんな多量の使用荷重も収容するのにおいてスケーラブルであって、広げることができます。 互いを模写して、グローバルであるか、または地方であることのハンドルサービスは、複数のサービスサイトから成るかもしれません。 また、それぞれのサービスサイトはそれぞれの名前空間に役立つように一緒に動作するコンピュータのクラスタから成るかもしれません。 複数のサービスサイトを持っていると、任意な単一の点の失敗が避けられて、ロードバランシングはこれらのサービスサイトの中に許容されます。 どんなサービスサイトの複数のサーバも使用するのは、複数のサーバプロセスに使用荷重を分配して、より少ない強力なコンピュータがサービスという名前に利用されるのを許容します。
4.1.1. Global Handle Registry (GHR)
4.1.1. グローバルなハンドル登録(GHR)
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.
Global Handle Registry(GHR)は権威をハンドルと命名しながら管理して、Handle Systemの下のあらゆる命名権威のためのサービス情報を提供するのにおいて主に使用されています。 また、GHRは、解決と命名権威の非ハンドルに対する管理サービスを管理して、提供するのに使用されるかもしれません。 どんなLHSと異なって、GHRは、命名当局を登録して、あらゆるLHSのためのサービス情報を提供するのに主として使用されます。LHSはいくつかの命名当局の下でハンドルをほとんど管理します。 言い換えれば、GHRは権威をハンドルと命名することの使用であらゆるLHSを登録して、彼らのサービス情報を提供するただ一つの根のサービスです。 命名権威ハンドルとしてGHRの下にHandle Systemの下のあらゆる命名権威を登録しなければなりません。 命名権威ハンドルは命名権威の下ですべてのハンドルを管理するハンドルサービスのサービス情報を提供します。 1セットの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
それぞれが、HS_SITE値でGHRが複数のサービスサイトから成るかもしれないと説明しました。 これらのHS_SITE値は、指定された命名権威ハンドル"0.NA/0.NA"に割り当てられて、また、根のハンドルと呼ばれます。 The
Sun, et al. Informational [Page 23] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[23ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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のためのサービス情報を保守する命名権威ハンドルです。 根のハンドルの管理者は当局を任命するトップレベルを作成できるだけです。
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サービス情報を必要とします。 サービス情報を初めはクライアントソフトウェアで分配するか、またはある他の安全なソースから得るかもしれません(例えば、郵便、安全なウェブサイトなど)。 クライアントソフトウェアは、サービス情報が満期に(TTLによると)なるまでGHRとコミュニケートするためにサービス情報を保つかもしれません。 構成を変えるときはいつも、GHRはサービス情報(根のハンドルに割り当てられる)をアップデートしなければなりません。 GHRとコミュニケートするときはいつも、時代遅れのサービス情報があるクライアントソフトウェアはアップデートについて通知されるでしょう。 時代遅れのGHRサービス情報があるどんなクライアントソフトウェアもまだ最新のアップデートのための根のハンドルについて質問できるような方法でGHRを維持しなければなりません。
Fig. 4.1.1 shows the GHR service information in terms of a set of HS_SITE values. The GHR may consist of a number of service sites, each described in a HS_SITE value. The figure shows a GHR service site located in US East Coast, as indicated in the <AttributeList>.
図4.1 .1 1セットのHS_SITE値に関してGHRサービス情報を示しています。 それぞれが、HS_SITE値でGHRが多くのサービスサイトから成るかもしれないと説明しました。 図は、GHRサービスサイトが<AttributeList>にみられるように東海岸米国で場所を見つけられたのを示します。
Sun, et al. Informational [Page 24] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[24ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
------------------------------------------------------------
------------------------------------------------------------ |
----------------------------------------------------------- | |
| | | |
| <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} | |-
| |-
-----------------------------------------------------------
------------------------------------------------------------ ------------------------------------------------------------ | ----------------------------------------------------------- | | | | | | | <インデックス>: 3 | | | | <タイプ>: HS_サイト| | | | <データ>: | | | | バージョン: 1 | | | | ProtocolVersion: 2.1 | | | | SerialNumber: 1 | | | | PrimaryMask: | | | | MultiPrimary: 本当| | | | PrimarySite: 本当| | | | HashOption: _ハンドルによるハッシュ_| | | | HashFilter: 空のUTF8-ストリング| | | | AttributeList: 1 | | | | 記述: 東海岸米国のサービスサイト| | | | NumOfServer: 3 | | | | | | | | ------------------------------------------ | | | | ------------------------------------------ | | | | | ------------------------------------------ || | | | | | ServerID: 1 ||| | | | | | アドレス: :FFFF: 132.151 .2、.150||| | | | | | PublicKeyRecord: HS_DSAKEY、iQCuR2Rnw… ||| | | | | | ServiceInterface||| | | | | | ServiceType: 解決とアドミン||| | | | | | TransmissionProtocol: TCP&UDP|| | | | | | PortNumber: 2641 | | | | | ------------------------------------------ | | | | | | | | <TTL>: 24時間| | | | <許可>: アドミン_は、公共の_が読んだと書きます。| | | | <参照>: 空になってください。| |- | |- -----------------------------------------------------------
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.
どんなクライアントソフトウェアもHandle Systemとコミュニケートするように、GHRとそのサービス情報はエントリー・ポイントを提供します。 どんな与えられたハンドルに関してはも、クライアントソフトウェアは命名権威ハンドルのためにGHRについて質問できます。 これは命名権威の下であらゆるハンドルを管理するLHSのサービス情報を返すでしょう。 サービス情報はハンドルを管理するLHSの中のハンドルサーバにクライアントソフトウェアを向けるでしょう。
Sun, et al. Informational [Page 25] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[25ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
4.1.2. Local Handle Service (LHS)
4.1.2. 地方のハンドルサービス(左手)
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.
Local Handle Services(LHS)は当局を任命する与えられたセットの下でハンドルを管理します。 それぞれの命名権威は命名権威の下でハンドルのすべてから成る「地方」の名前空間を定義します。 LHSがどんなネットワーク形態に関する「地方」のサービスでないことにも注意してください。 それは、制限された(地方の)名前空間を通常管理するので、「地方」のHandle Serviceと呼ばれます。
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は複数の命名当局へのホームであるかもしれません。 他方では、命名権威は1LHSの「家へ帰り」であっただけであるかもしれません。 また、命名権威があるかもしれないというメモは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} |-
-----------------------------------------------------------
------------------------------------------------------------ ------------------------------------------------------------ | ----------------------------------------------------------- | | | <インデックス>: 3 | | | | <タイプ>: HS_サイト| | | | <データ>: | | | | バージョン: 1 | | | | ProtocolVersion: 2.1 | | | | SerialNumber: 1 | | | | PrimaryMask: | | | | MultiPrimary: 誤る| | | | PrimarySite: 本当| | | | HashOption: _LOCALNAMEによるハッシュ_| | | | HashFilter: 空のUTF8-ストリング| | | | AttributeList: 1 | | | | 記述: 「10インチ」のための地方のサービス| | | | NumOfServer: 2 | | | | ----------------------------------------- | | | | ----------------------------------------- | | | | | | ServerID: 1 || | | | | | アドレス: :FFFF: 132.151 .3、.150|| | | | | | PublicKeyRecord: HS_DSAKEY、iQCuR2R.。 || | | | | | ServiceInteface: || | | | | | ServiceType: 解決とアドミン|| | | | | | TransmissionProtocol: TCP&UDP|| | | | | | PortNumber: 2641 |' | | | | -----------------------------------------' | | | | <TTL>: 24時間| | | | <許可>: アドミン_は、公共の_が読んだと書きます。| |- | <参照>: 空になってください。|- -----------------------------------------------------------
Figure 4.1.2: LHS service information
図4.1.2: LHSサービス情報
Sun, et al. Informational [Page 26] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[26ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
Like the GHR, a LHS may also consist of many service sites with each site described by an HS_SITE value. The set of HS_SITE values for any LHS may be assigned to a service handle or to the relevant naming authority handle(s). Fig. 4.1.2 shows an example of HS_SITE values for a LHS. These HS_SITE values are assigned to the naming authority handle "0.NA/10". This suggests that the naming authority "10" is "homed" at the LHS specified in these HS_SITE values. Clients may query the GHR to obtain the service information in order to communicate with the LHS. Administrators of the naming authority handle are responsible for maintaining the service information and keeping it up to date.
また、GHRのように、LHSは各サイトがHS_SITE値によって説明されている多くのサービスサイトから成るかもしれません。 どんなLHSのためのHS_SITE値のセットもサービスハンドル、または、関連命名権威ハンドルに割り当てられるかもしれません。 図4.1 .2 LHSのためにHS_SITE値に関する例を示しています。 これらのHS_SITE値は命名権威ハンドル「0.NA/10インチ」に割り当てられます。 これがそれを示す、「10インチはこれらのHS_敷地価額で指定された左手の「家へ帰り」でした」と権威を命名します。 クライアントは、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は階級的なファッションでサービスをさらに広げることができます。
4.2. Handle System Middle-Ware Components
4.2. システムミドルウェアの部品を扱ってください。
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.
ハンドルSystemミドルウェアの部品は現在、Handle SystemキャッシュサーバとHandle Systemプロキシサーバを含んでいます。 これらのHandle Systemミドルウェアの部品はHandle Systemサービスの部品へのクライアントですが、Handle Systemへのサーバはクライアントソフトウェアです。 ハンドルSystemミドルウェアの部品は、基本的なハンドルサービスに追加インタフェースを提供するのに使用されます。 例えば、Handle Systemキャッシュサーバは、地方の共同体の中で解決結果を共有するのに使用されるかもしれません。 さらに、HTTPトンネリングでどんな組織的なファイアウォールも迂回させるのにHandle Systemプロキシサーバを使用できます。
4.2.1. Handle System Caching Service
4.2.1. サービスをキャッシュするシステムを扱ってください。
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.
Handle Systemクライアントとサーバの間のネットワークトラフィックを減少させるのにサービスをキャッシュするハンドルSystemは使用できます。 どんな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への時間)分野を含んでいます。 無価値のTTLは、値が進行中のトランザクションに使用できるだけであって、キャッシュされるべきでないのを示します。 データがキャッシュサービスによって直接ハンドルサービスから得られるかもしれませんか、またはそんなに結局サービスをキャッシュすると、別のものから、データはハンドルサービスから得られます。
Sun, et al. Informational [Page 27] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[27ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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管理や認証階層構造の一部ではありません。 Handle Systemプロトコルはキャッシュサービスから少しの応答も認証しません。 クライアントは彼らが選択するキャッシュサービスとの彼らの信頼関係をセットアップするのにおいて責任があります。 また、彼らは、どんなハンドルサーバからもどんな応答も適切に認証するためにキャッシュサービスに依存するでしょう。
4.2.2. Handle System Proxy Server
4.2.2. システムProxyサーバを扱ってください。
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.
他のインターネットプロトコルでハンドル解決を可能にするのにハンドルSystemプロキシサーバを使用できます。 例えば、CNRIはHTTPプロトコルでどんなハンドル解決も処理するHandle System HTTP Proxyサーバを、利用可能に築き上げて、しました。 プロキシサーバのための現在のDNSアドレスが"hdl.handle.net"にあります。 プロキシサーバは、どんなハンドルもHTTP URLで決議されるのを許容します。 「 http://hdl.handle.net/ <ハンドル>」としてURLを構成できます。そこでは、<ハンドル>がHandle Systemからのどんなハンドルであるかもしれません。 例えば、ハンドル、「tr93が何35インチもncstrl.vatech_Cs/そうすることができる、どんなウェブブラウザからのHTTP URL" http://hdl.handle.net/ncstrl.vatech_cs/tr-93-35 "を通しても決議されてください、」 この場合、HTTP要求でURLをプロキシサーバに送ります。 プロキシサーバは、ハンドルデータのためにHandle Systemについて質問して、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を使用するのは、ハンドルが標準のウェブブラウザから少しも追加クライアントソフトウェアなしで決議されるのを許容します。 しかしながら、また、ハンドルのそのような参照はそれ自体をプロキシサーバに結びます。プロキシサーバが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.
ProxyサーバはどんなHandle System管理や認証階層構造の一部ではありません。 Handle Systemプロトコルはプロキシサーバから少しの応答も認証しません。クライアントは彼らが選択するプロキシサーバとの彼らの信頼関係をセットアップするのにおいて責任があります。 また、彼らは、どんなハンドルサーバからもどんな応答も適切に認証するためにプロキシサーバを当てにするでしょう。
4.3. Handle System Client Components
4.3. システムクライアントの部品を扱ってください。
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
ハンドルSystemクライアントの部品はHandle Systemサービスの部品で交信するクライアントソフトウェアです。 クライアントソフトウェアは、Handle Systemプロトコルを話して、直接サービスに要求を送るかもしれません。
Sun, et al. Informational [Page 28] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[28ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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.
様々なHandle Systemクライアントの部品は様々なアプリケーションのために開発されるかもしれません。 CNRI Handle System Resolver[17]はそのようなコンポーネントの1つです。 レゾルバが直接ハンドルを決議できるような方法でウェブブラウザ(例えば、NetscapeかMicrosoft Internet Explorer)を広げている、「hdl:」 Uniform Resource Identifier(URI)。 また、聖杯ウェブブラウザ[18](パイソン[19]で開発された自由にダウンローダブルなソフトウェア)がサポートする、「hdl:」 URIは、計画して、それに従って、ハンドルを決議するでしょう。 例えば、ハンドル「10.1045/july95-兵器」は、「hdl: 10.1045/july95-兵器」としてこれらのレゾルバによって可能にされたブラウザのどれかにハンドルURIを入れることによって、決議されるかもしれません。 ハンドルURI構文の詳細は別々のドキュメントで指定されるでしょう。
5. Handle System Operation Model
5. システムオペレーション・モデルを扱ってください。
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.
ハンドルSystem操作を解決と管理に分類できます。 クライアントはどんなハンドル値のためにも質問するハンドル解決サービスを使用します。 ハンドル管理で、ハンドルを加えて、削除するのを含んで、それらの値をアップデートして、クライアントはハンドルを管理できます。 また、権威をハンドルと命名することを通してそれは命名権威機関と取り引きします。 このセクションは様々なHandle Systemの部品がこれらの戦務活動を実行するためにどう一緒に機能するかを説明します。
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.
解決と管理の両方がクライアントの認証を必要とするかもしれません。 後でこのセクションで説明されたHandle System認証プロトコルで認証できます。 認証が必要であるかどうかを操作のかかわった種類と関連ハンドル値に割り当てられた許容に依存しました、そして、方針は関連サービスコンポーネントで展開しました。
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
Handle SystemプロトコルはHandle Systemクライアントの間で交換された各メッセージとそのサーバコンポーネントの構文と意味論を指定します。 このセクションは高い平らな概要を提供します。
Sun, et al. Informational [Page 29] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[29ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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]で指定されます。
5.1. Handle System Service Request and Response
5.1. システムサービスのリクエストと応答を扱ってください。
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.
Handle Systemはクライアント要求に対応してサービスを提供します。 クライアントは、応答を引き起こすためにどんなハンドルサーバにも要求を送るかもしれません。 応答はどちらかが別のサービスコンポーネントを要求を参照するか、クライアント認証を求めるか、または何らかのエラー状況に合図するという関連情報に要求、またはステータスコードの答えを提供します。
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.
Handle Systemの下の各ハンドルは在宅サービスで管理されます。 命名権威ハンドルは命名権威の下ですべてのハンドルを管理するハンドルサービスのサービス情報(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/、Te93、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).
クライアントは、サーバからどんな応答も認証するためにハンドルサーバからデジタル署名を必要とするかもしれません。サーバの秘密鍵を使用することで署名は生成することができます。 クライアントがサービス情報から利用可能な公開鍵を使用することで署名について確かめるかもしれない、(中で議論した<PublicKeyRecord>エントリーを参照してください、3.2、.2、)
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
また、コミュニケーションセッションはどんなクライアントとハンドルサーバの間でも確立されるかもしれません。各セッションはサーバによって管理されたユニークなセッションIDによって特定されます。セッションは、複数の相互作用を必要とする要求を管理するのに使用されるかもしれません。 また、それは、複数のサービス取引の中のどんなTCP接続や認証情報も共有するのに使用されるかもしれません。 セッションがセッションキーを設立して、それを使用するかもしれないそれぞれ
Sun, et al. Informational [Page 30] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[30ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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.
セッション中に交換されたあらゆるメッセージを認証してください。 また、それは、データの機密性を達成するクライアントとサーバの間のどんなメッセージも暗号化するのに使用されるかもしれません。
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.
以下のダイヤグラムはクライアントソフトウェアとHandle Systemサービスの部品の間で交換されたメッセージに関してハンドル解決プロセスを示しています。 この場合、クライアントは「93を何35インチもncstrl.vatech_Cs/trしていた」状態でハンドルを決議しようとしています。 それは、クライアントがまだ「家へ帰ること」ごとの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クライアント]---------------------------->[グローバルなHandle Registry]1は命名権威ハンドル「0.NA/ncstrl.vatech_Cs」からサービス情報を求めます。
[HS Client] <---------------------------- [Global Handle Registry]
2. service information for
the naming authority
"ncstrl.vatech_cs"
[HSクライアント] <。---------------------------- [グローバルなHandle Registry] 2 命名権威「ncstrl.vatech_Cs」のためのサービス情報
[HS Client] ----------------------------> [Local Handle Service]
3. query the handle
"ncstrl.vatech_cs/tr-93-35"
against the responsible
handle server
[HSクライアント]---------------------------->[地方のHandle Service]3がハンドルについて質問する、「ncstrl.vatech_Cs/、tr、93、35インチ、原因となるハンドルサーバ、」
\... ...
\... ...
(optional client authentication, depending on the service request)
(任意のクライアント認証サービスのリクエストによって、
\... ...
\... ...
[HS Client] <---------------------------- [Local Handle Service]
4. query result from the handle
server + (optional) server
signature
[HSクライアント] <。---------------------------- [地方のHandle Service] 4 ハンドルサーバ+(任意)のサーバ署名から結果について質問してください。
Figure 5.1: Handle resolution example
図5.1: 解決の例を扱ってください。
In Figure 5.1, the client is configured to communicate with the GHR for any handle service. In this case, the client first queries the GHR to find the home service for the handle's naming authority. The
図5.1では、クライアントは、どんなハンドルサービスのためにもGHRとコミュニケートするために構成されます。 この場合、クライアントは、最初に、ホームがハンドルが権威を命名するためのサービスであることがわかるためにGHRについて質問します。 The
Sun, et al. Informational [Page 31] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[31ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
GHR returns the service information of the LHS that manages every handle under the naming authority. From the service information, the client can find the responsible handle server and query the server for the handle. The server may set up a session to authenticate the client if any of the handle value requires authentication. Otherwise, the server will simply return the handle value to the client. The server may send a digital signature as part of its response if required by the client.
GHRは命名権威の下であらゆるハンドルを管理するLHSのサービス情報を返します。 サービス情報から、クライアントは、原因となるハンドルサーバを見つけて、ハンドルのためにサーバについて質問できます。 ハンドル価値のどれかが認証を必要とするなら、サーバは、クライアントを認証するためにセッションをセットアップするかもしれません。 さもなければ、サーバは単にハンドル値をクライアントに返すでしょう。 サーバは必要ならクライアントによる応答の一部としてデジタル署名を送るかもしれません。
The above procedure assumes that the client software already has the GHR service information. That information was likely obtained from the client software distribution. The GHR will notify the client software if it learns that the service information used by the client software is out of date. Client software may retrieve the latest service information from the root handle "0.NA/0.NA". The root handle also maintains the public key that may be used to authenticate the service information.
上の手順は、クライアントソフトウェアにはGHRサービス情報が既にあると仮定します。 クライアントソフトウェア配布からその情報をおそらく得ました。 クライアントソフトウェアによって使用されるサービス情報が時代遅れであることを学ぶと、GHRはクライアントソフトウェアに通知するでしょう。 クライアントソフトウェアは根のハンドル"0.NA/0.NA"からの最新のサービス情報を検索するかもしれません。 また、根のハンドルはサービス情報を認証するのに使用されるかもしれない公開鍵を維持します。
Note that a client may cache the service information of any naming authority so that subsequent queries for handles under the same naming authority may reuse the service information and bypass the first two steps shown in Figure 5.1. Client software may also be configured to query a caching or proxy server directly for any handle. In this case, the caching or proxy server will act as the [HS Client] in Figure 5.1 before returning the query result to the client.
権威を命名する同じくらい下のハンドルのためのその後の質問がサービス情報を再利用して、図5.1に示された最初の2ステップを迂回させることができるようにクライアントがどんな命名権威のサービス情報もキャッシュするかもしれないことに注意してください。 また、クライアントソフトウェアは、直接どんなハンドルのためにもキャッシュかプロキシサーバについて質問するために構成されるかもしれません。 この場合、質問結果をクライアントに返す前に、キャッシュかプロキシサーバが[HS Client]として図5.1で機能するでしょう。
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の下で管理されたハンドルのための、より迅速な応答を達成するかもしれません。 GHRはクライアントソフトウェアがLHSによって管理されなかったハンドルの参照になるでしょう。
5.2. Handle System Authentication Protocol
5.2. システム認証プロトコルを扱ってください。
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.
Handle Systemは公共のインターネットの上でハンドル管理をサポートします。 それぞれのハンドル値でアクセス制御を定義できます。 Handle System認証プロトコルはどんなハンドルサーバによっても使用される、どんな管理要求のときにもハンドル管理者を認証するプロトコルです。 また、クライアントがハンドルのためにハンドル管理者による書き込み禁止である値について質問するとき、認証も必要です。 ハンドル管理は、ハンドルをハンドル値を加えるか、削除するか、または変更して、加えるか、または削除するのを含んでいます。 命名権威運営がハンドル政権として権威が扱う対応する命名の上に行われます。
Sun, et al. Informational [Page 32] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[32ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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.
Handle System認証プロトコルはどんなサーバ証明も実行しません。 しかしながら、デジタル署名を応答と契約するようにサーバに頼むことによって、クライアントはどんなサーバ応答も認証するかもしれません。
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.
デフォルトで、Handle Systemは挑戦応答プロトコルでクライアントを認証します。 すなわち、クライアントの要求を受け取った後に、認証が必要であるなら、サーバはクライアントへの挑戦を発行します。 管理者として認証されるために、クライアントはチャレンジレスポンス(アドミニストレータの秘密の行列のデモをするメッセージ)を返さなければなりません。 秘密は、管理者の秘密鍵か秘密鍵であるかもしれません。 この挑戦応答で、サーバはハンドル管理者としてクライアントを認証できます。 うまくいっている認証のときに、十分な許可を管理者に与えると、サーバはクライアントの要求を実現させるでしょう。
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.
例えば、クライアントが新しいハンドル価値を高めるためにハンドルサーバに要求を送ると仮定してください。 サーバは、ハンドル管理者のひとりとしてクライアントを認証するためにクライアントへの挑戦を発行するでしょう。 クライアントに管理者の秘密鍵があるなら、彼女は、サーバの挑戦に署名して、彼女のチャレンジレスポンスの一部として署名を返すのにそれを使用できます。 サーバは、クライアントを認証するために署名を有効にするでしょう。 合法化が失敗すると、クライアントは通知されるでしょう。 さもなければ、サーバは、管理者にハンドル価値を高める許可があるかどうかさらにチェックするでしょう。 そうだとすれば、サーバはハンドル価値とレポート成功をクライアントに高めるでしょう。 さもなければ、許可で否定されたメッセージを返すでしょう。
Sun, et al. Informational [Page 33] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[33ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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
[クライアント]--------------------------------1つの>[Serverを扱う]のクライアント要求+(任意)のクライアント資格証明書
[Client] <-------------------------------- [Handle Server]
2. server's challenge to client
+ (i.e., nonce + MD5 of client request)
[クライアント] <。-------------------------------- [Serverを扱います] クライアント+への2サーバの挑戦(すなわち、クライアント要求の一回だけ+MD5)
[Client] -------------------------------> [Handle Server]
3. reference to handle administrator
+ challenge-response from client
[クライアント]-------------------------------クライアントから管理者+チャレンジレスポンスを扱う>[Serverを扱う]3参照
[Client] <------------------------------- [Handle Server]
4. server acknowledgement
[クライアント] <。------------------------------- [Serverを扱います] 4サーバ承認
Figure 5.2: Handle System authentication process
図5.2: ハンドルSystem認証プロセス
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.
公開鍵が使用されているとき、クライアントからのチャレンジレスポンスはサーバの挑戦の上のデジタル署名を含んでいます。 サーバは、アドミニストレータの公開鍵に基づくデジタル署名について確かめることによって、クライアントを認証できます。 秘密鍵が使用されているなら、クライアントからのチャレンジレスポンスは秘密鍵を使用することで生成されたMessage Authenticate Code(MAC)を運びます。 サーバは、アドミニストレータの秘密鍵を使用することで同じMACを生成して、挑戦応答に対してそれを比較することによって、クライアントを認証するかもしれません。
Sun, et al. Informational [Page 34] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[34ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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で管理者を扱う参照は主要な参照と呼ばれます。 それは管理者によって使用されたキーを含むハンドル値について言及します。 同じハンドルサーバ(例えば同じハンドルに割り当てられたハンドル値)によって主要な参照が管理されるなら、サーバは、認証するのに直接キーを使用するかもしれません。 主要な参照がある他のハンドルサーバによって管理されると(同じくらい中でサービスを扱ってくださいか否かに関係なく)、サーバはこの他のハンドルサーバに検証要求を送らなければならなくて、それを主要なサーバと呼んでください、クライアントを認証するために。 主要なサーバへの検証要求はサーバの挑戦とクライアントのチャレンジレスポンスの両方を運びます。 主要なサーバは主要なサーバの秘密鍵を使用することで署名される検証応答を返すでしょう。 検証応答の内容は主要な参照で参照をつけられるハンドル値に依存するでしょう。 主要な参照が管理者によって使用された公開鍵について言及すると、検証応答は管理者の公開鍵を含むでしょう。 さもなければ、主要なサーバは、要求サーバを代表してチャレンジレスポンスを確かめて、検証応答で結果を返すでしょう。 以下のダイヤグラムは、主要な参照がアドミニストレータの公共の、そして、(秘密)のキーと主要なサーバを含むハンドル値をどこと呼ぶかが、ある他のハンドルサーバであることを認証過程のコントロール流動に示します。
Sun, et al. Informational [Page 35] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[35ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
-------- -------------
| | 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 |
--------------------------
-------- ------------- | | 1. クライアント要求。 | | | | ------------------------------->|、|、|、|、|、|、|、| 2. セッションID| | | | + サーバの挑戦| | | ハンドル| <------------------------------- | ハンドル| | システム| | サーバ| | クライアント| 3. セッションID| 受信します。| | | + 挑戦への応答| クライアント| | | + 管理者参照| 要求| | | -------------------------------->|、|、|、|、|、|、|、| 6. サーバ承認| | | | <------------------------------- | | -------- ------------- | ^ 4. 検証| | 5. verifi要求| | 陽イオン| | 応答| | (署名されます) V| -------------------------- | ハンドルサーバ、(| | 主要なサーバ) それは管理されます。| | 参照をつけられるキー| | 主要な参照| --------------------------
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.
2番目のハンドルサーバを通した秘密の主要なベースの認証(すなわち、主要なサーバ)は異なったハンドルサーバによって管理されたハンドルの中で一般的な秘密鍵(例えば、句を通過する)を共有する便利な方法を提供します。 しかしながら、非常に敏感なハンドルを管理するか、またはデータを扱うのにそれを使用するべきではありません。 認証過程自体は、高価であり、第三者、適切な操作のためのすなわち、主要なサーバを当てにします。 さらに、主要なサーバが、検証要求が正統のハンドルサーバから来るかどうか決定できないので、秘密鍵自体は辞書攻撃をなることがあります。ハンドルサービスは、また、ハンドルサーバ(クライアント要求を受け取る)が主要なサーバである場合にだけ秘密の主要なベースの認証を行うことができるようにローカルの方針を設定するかもしれません。
Sun, et al. Informational [Page 36] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[36ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
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.
地方のハンドルサービスは認証、そして/または、承認のために追加ローカルの方針を定義するかもしれません。 また、ハンドルSystemサービスの部品は、ケルベロス[20]か何らかのTransport Layer Securityプロトコル[21]などの他のインターネット認証機構を使用するのを選ぶかもしれません。 これらの詳細は別々のドキュメントで扱われるでしょう。
6. Security Considerations
6. セキュリティ問題
Handle System security considerations are discussed in the "Handle System Overview" [1] and that discussion applies equally to this document.
「ハンドルシステム概要」[1]でハンドルSystemセキュリティ問題について議論します、そして、その議論は等しくこのドキュメントに適用されます。
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.
Handle System代表はサーバアドミニストレータであるかもしれないそれぞれのハンドル管理者に管理を扱います。 ハンドル管理者は認証に使用されるそれら自身の公共の、または、秘密のキーを選ぶことができます。 Handle System認証のセキュリティは適切な主要な選択とハンドル管理者によるそのメインテナンスによります。 ハンドル管理者は、ハンドルデータを保護するために慎重に彼らの認証キーを選んで、保護しなければなりません。 ハンドルサーバ実装は認証に使用される公共の、または、秘密のキーの品揃えを規制する方針を配布するかもしれません。 例えば、ハンドルサーバは、どんな認証キーも少なくともある数のビットでなければならないことを必要とするかもしれません。 また、それは潜在的辞書攻撃のために秘密鍵の使用を禁止するかもしれません。
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.
Handle Systemデータモデルは、それぞれのハンドル値のために実行が許可(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.
システム資源のどんな無責任な使用からも守るために、ハンドルサーバは割当てコントロールを実装するかもしれません。 命名権威の下でハンドルの数に限界を置くのに割当てコントロールを使用できます、とハンドル値の数はどんな与えられたハンドル、どんなハンドル価値の最大サイズ、およびサブ命名当局の数のためにも命名権威の下で許容しました。 ハンドル管理の結果がこれらの限界のどれかに違反するなら、ハンドルサーバは誤りを報告しなければなりません。
Sun, et al. Informational [Page 37] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[37ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
7. Acknowledgements
7. 承認
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.
Handle System実装の以前のバージョンからこの仕事を得ます。 Handle Systemを含む総合的なデジタル目的アーキテクチャは1995年に論文でロバート・カーンとロバート・ウィレンスキー[22]によって説明されました。 開発はグラントNumber MDA-972- 92-J-1029とMDA-972-99-1-0018の下でDefense Advanced Projects Agency(DARPA)によって資金を供給されたコンピュータScience Technical Reports(CSTR)プロジェクトの一部としてCNRIで続きました。 デザイン考えはHandle System開発チームの中で議論したものに基づいています、デヴィッド・イーリー、シャルル・オルト、アリソン・ユー、ショーン・ライリー、ジェーン・オイラー、キャサリン・レイ、ステファニーNguyen、ジェイソンPetrone、およびヘレンSheを含んでいて。 この仕事への彼らの貢献は感謝して承諾されます。
The authors also thank Russ Housley (housley@vigilsec.com), Ted Hardie (hardie@qualcomm.com), and Mark Baugher (mbaugher@cisco.com) for their extensive review and comments, as well as recommendations received from other members of the IETF/IRTF community.
また、作者は彼らの大量のレビューとコメントについてラスHousley( housley@vigilsec.com )、テッド・ハーディー( hardie@qualcomm.com )、およびマークBaugher( mbaugher@cisco.com )に感謝します、IETF/IRTF共同体の他のメンバーから受けられた推薦と同様に。
8. References and Bibliography
8. 参照と図書目録
[1] Sun, S. and L. Lannom, "Handle System Overview", RFC 3650,
November 2003.
[1] S.とL.Lannom、「ハンドルシステム概要」、RFC3650、2003年11月Sun。
[2] Mockapetris, P., "Domain Names - Concepts and Facilities," STD
13, RFC 1034, November 1987.
[2]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[3] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[3]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[4] ウォールとM.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。
[5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[5] エドクロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[6] Yergeau, F., "UTF-8, A Transform Format for Unicode and
ISO10646", RFC 2279, January 1998.
[6]Yergeau、1998年1月のF.、「UTF-8、ユニコードとISO10646のための変換形式」RFC2279。
[7] The Unicode Consortium, "The Unicode Standard, Version 2.0",
Addison-Wesley Developers Press, 1996. ISBN 0-201-48345-9
[7] ユニコード共同体、「ユニコード規格、バージョン2インチ、アディソン-ウエスリー開発者プレス、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] S.とライリーとS.とL.Lannom、「ハンドルシステムプロトコル(ver2.1)仕様」、RFC3652、2003年11月Sun。
[9] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
Locators (URL)", RFC 1738, December 1994.
[9] バーナーズ・リーとT.とMasinterとL.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
Sun, et al. Informational [Page 38] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[38ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
[10] Housley, R., Polk, W. Ford, W. and D. Solo, "Internet X.509
Public Key Infrastructure - Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[10]Housley、R.、ポーク、W.フォード、W.、D.独奏、「インターネットX.509公開鍵基盤--取消しリスト(CRL)プロフィールを証明して、証明する」RFC3280(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パブ)46-1(データ暗号化規格)は1月22日(1月15日にFIPSパブ46、1977に取って代わる)に1988を再び断言しました。
[12] Federal Information Processing Standards Publication (FIPS PUB)
81, DES Modes of Operation, 1980 December 2.
[12] 1980年のDES運転モード、12月2連邦政府の情報処理規格公表(FIPSパブ)81、日。
[13] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
Part III: Algorithms, Modes, and Identifiers", RFC 1423,
February 1993.
[13]Balenson、D.、「インターネット電子メールのためのプライバシー増進:」 パートIII: 「アルゴリズム、モード、および識別子」、RFC1423、2月1993日
[14] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[14] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
[15] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 1883, December 1995.
[15] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC1883、12月1995日
[16] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[16]HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[17] CNRI Handle System Resolver, http://www.handle.net/resolver
[17] CNRIはシステムレゾルバ、 http://www.handle.net/resolver を扱います。
[18] Grail browser home page, http://grail.sourceforge.net/
[18] 聖杯ブラウザホームページ、 http://grail.sourceforge.net/
[19] Python language website, http://www.python.org/
[19] ニシキヘビ言語ウェブサイト、 http://www.python.org/
[20] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.
[20] コールとJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。
[21] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[21] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[22] R. Kahn, R. Wilensky, "A Framework for Distributed Digital
Object Services, May 1995, http://www.cnri.reston.va.us/k-w.html
[22] R.カーン、R.ウィレンスキー、「分配されたデジタルオブジェクトサービスのためのフレームワーク、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] American National Standards Institut。 ANSI X9.52-1998、データ暗号化アルゴリズム運転モードを3倍にしてください。 1998.
Sun, et al. Informational [Page 39] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[39ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
9. Authors' Addresses
9. 作者のアドレス
Sam X. Sun Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
国家の研究イニシアチブ(CNRI)1895プレストンホワイト博士、100レストン、Suiteヴァージニア 20191へのサムX.Sun社
Phone: 703-262-5316 EMail: ssun@cnri.reston.va.us
以下に電話をしてください。 703-262-5316 メールしてください: ssun@cnri.reston.va.us
Sean Reilly Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
国家の研究イニシアチブ(CNRI)1895プレストンホワイト博士、100レストン、Suiteヴァージニア 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
国家の研究イニシアチブ(CNRI)1895プレストンホワイト博士、100レストン、Suiteヴァージニア 20191へのラリーLannom社
Phone: 703-620-8990 EMail: llannom@cnri.reston.va.us
以下に電話をしてください。 703-620-8990 メールしてください: llannom@cnri.reston.va.us
Sun, et al. Informational [Page 40] RFC 3651 Handle System Service Definition November 2003
Sun、他 情報[40ページ]のRFC3651は定義2003年11月にシステムサービスを扱います。
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Sun, et al. Informational [Page 41]
Sun、他 情報[41ページ]
一覧
スポンサーリンク
