[要約] RFC 2276は、Uniform Resource Name（URN）の解決に関するアーキテクチャルな原則を提供するものであり、URNの一貫性と持続性を確保することを目的としています。
Network Working Group K. Sollins
Request for Comments: 2276 MIT/LCS
Category: Informational January 1998
Architectural Principles of Uniform Resource Name Resolution
ユニフォームリソースの名前解決のアーキテクチャの原則
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This document addresses the issues of the discovery of URN (Uniform Resource Name) resolver services that in turn will directly translate URNs into URLs (Uniform Resource Locators) and URCs (Uniform Resource Characteristics). The document falls into three major parts, the assumptions underlying the work, the guidelines in order to be a viable Resolver Discovery Service or RDS, and a framework for designing RDSs. The guidelines fall into three principle areas: evolvability, usability, and security and privacy. An RDS that is compliant with the framework will not necessarily be compliant with the guidelines. Compliance with the guidelines will need to be validated separately.
このドキュメントは、URN（Uniform Resource Name）リゾルバーサービスの発見の問題に対処し、URNを直接URL（Uniform Resource Locator）とURC（Uniform Resource Characteristics）に変換します。このドキュメントは、3つの主要な部分、作業の基礎となる前提、実行可能なResolver Discovery ServiceまたはRDSになるためのガイドライン、およびRDSを設計するためのフレームワークに分類されます。ガイドラインは、進化性、使いやすさ、セキュリティとプライバシーの3つの主要分野に分類されます。フレームワークに準拠しているRDSは、必ずしもガイドラインに準拠しているとは限りません。ガイドラインへの準拠は、個別に検証する必要があります。
Table of Contents
目次
1. Introduction..................................................2
2. Assumptions...................................................5
3. Guidelines....................................................7
3.1 Evolution.....................................................7
3.2 Usability....................................................10
3.2.1 The Publisher................................................11
3.2.2 The Client...................................................12
3.2.3 The Management...............................................13
3.3 Security and Privacy.........................................14
4. The Framework................................................18
5. Acknowledgements.............................................23
6. References...................................................23
7. Author's Address.............................................23
8. Full Copyright Statement.....................................24
The purpose of this document is to lay out the engineering criteria for what we will call here a Resolver Discovery Service (RDS), a service to help in the learning about URN (Uniform Resource Name) resolvers. The term "resolver" is used in this document to indicate a service that translates URNs to URLs (Uniform Resource Locators) or URCs (Uniform Resource Characteristics). Some resolvers may provide direct access to resources as well. An RDS helps in finding a resolver to contact for further resolution. It is worth noting that some RDS designs may also incorporate resolver functionality. This function of URN resolution is a component of the realization of an information infrastructure. In the case of this work, that infrastructure is to be available, "in the Internet" or globally, and hence the solutions to the problems we are addressing must be globally scalable. In this document, we are focussing specifically on the design of RDS schemes.
このドキュメントの目的は、URN（Uniform Resource Name）リゾルバーについて学習するのに役立つサービスであるResolver Discovery Service（RDS）と呼ばれるもののエンジニアリング基準を説明することです。このドキュメントでは、「リゾルバ」という用語は、URNをURL（Uniform Resource Locator）またはURC（Uniform Resource Characteristics）に変換するサービスを示すために使用されています。一部のリゾルバーは、リソースへの直接アクセスも提供する場合があります。 RDSは、解決のために連絡するリゾルバを見つけるのに役立ちます。一部のRDS設計にはリゾルバー機能も組み込まれている場合があることに注意してください。 URN解決のこの機能は、情報インフラストラクチャの実現のコンポーネントです。この作業の場合、そのインフラストラクチャは「インターネット」またはグローバルで利用できるため、私たちが取り組む問題の解決策はグローバルにスケーラブルでなければなりません。このドキュメントでは、RDSスキームの設計に特に焦点を当てています。
The Uniform Resource Identifier Working Group defined a naming architecture, as demonstrated in a series of three RFCs 1736 [1], 1737 [2], and 1738 [3]. Although several further documents are needed to complete the description of that architecture, it incorporates three core functions often associated with "naming": identification, location, and mnemonics or semantics. By location, we mean fully-qualified Domain Names or IP addresses, possibly extended with TCP ports and/or local identifiers, such as pathnames. Names may provide the ability to distinguish one resource from another, by distinguishing their "names". Names may help to provide access to a resource by including "location" information. In addition, names may have other semantic or mnemonic information that either helps human users remember or figure out the names, or includes other semantic information about the resource being named. The URI working group concluded that there was need for persistent, globally unique identifiers, distinct from location or other semantic information; these were called URNs. These "names" provide identity, in that if two of them are "the same" (under some simple rule of canonicalization), they identify the same resource. Furthermore, the group decided that these "names" were generally to be for machine, rather than human, consumption. Finally, with these guidelines for RDS's, this group has recognized the value of the separation of name assignment management from name resolution management.
一連の3つのRFC 1736 [1]、1737 [2]、および1738 [3]で示されているように、Uniform Resource Identifierワーキンググループは命名アーキテクチャを定義しました。そのアーキテクチャの説明を完了するには、さらにいくつかのドキュメントが必要ですが、「命名」に関連することが多い3つのコア機能（識別、場所、ニーモニックまたはセマンティクス）が組み込まれています。ロケーションとは、完全修飾ドメイン名またはIPアドレスを意味し、TCPポートやパス名などのローカル識別子で拡張されている可能性があります。名前は、「名前」を区別することにより、あるリソースを別のリソースから区別する機能を提供します。名前は、「場所」情報を含めることにより、リソースへのアクセスを提供するのに役立ちます。さらに、名前には、人間のユーザーが名前を覚えたり理解したりするのに役立つ、または名前が付けられているリソースに関する他の意味情報が含まれている、他の意味情報またはニーモニック情報が含まれている場合があります。 URIワーキンググループは、場所や他の意味情報とは異なり、永続的でグローバルに一意の識別子が必要であると結論付けました。これらはURNと呼ばれていました。これらの「名前」はIDを提供します。それらの2つが（同じ正規化のいくつかの単純なルールの下で）「同じ」である場合、それらは同じリソースを識別します。さらに、グループは、これらの「名前」は一般に人間ではなく機械の消費のためのものであると決定しました。最後に、RDSのこれらのガイドラインにより、このグループは、名前割り当て管理を名前解決管理から分離することの価値を認識しました。
In contrast to URNs, one can imagine a variety human-friendly naming (HFN) schemes supporting different suites of applications and user communities. These will need to provide mappings to URNs in tighter or looser couplings, depending on the namespace. It is these HFNs that will be mnemonic, content-full, and perhaps mutable, to track changes in use and semantics. They may provide nicknaming and other aliasing, relative or short names, context sensitive names, descriptive names, etc. Their definition is not part of this effort, but will clearly play an important role in the long run.
URNとは対照的に、さまざまな一連のアプリケーションとユーザーコミュニティをサポートする、人にやさしいさまざまな名前付け（HFN）スキームを想像できます。これらは、名前空間に応じて、密結合または疎結合でURNへのマッピングを提供する必要があります。使用法とセマンティクスの変更を追跡するのは、これらのHFNがニーモニックで、コンテンツがいっぱいで、おそらく変更可能です。ニックネームやその他のエイリアス、相対名または短縮名、状況依存の名前、わかりやすい名前などを提供します。それらの定義はこの取り組みの一部ではありませんが、長期的には重要な役割を果たすことは明らかです。
URNs as described in RFC 1737 are defined globally; they are ubiquitous in that a URN anywhere in any context identifies the same resource. Given this requirement on URNs, one must ask about its implication for an RDS. Does ubiquity imply a guarantee of RDS resolution everywhere? Does ubiquity imply resolution to the same information about resolution everywhere? In both cases the answer is probably not. One cannot make global, systemic guarantees, except at an expense beyond reason. In addition there may be policy as well as technical reasons for not resolving in the same way everywhere. It is quite possible that the resolution of a URN to an instance of a resource may reach different instances or copies under different conditions. Thus, although a URN anywhere refers to the same resource, in some environments under some conditions, and at different times, due to either the vagaries of network conditions or policy controls a URN may sometimes be resolvable and other times or places not. Ubiquitous resolution cannot be assumed simply because naming is ubiquitous. On the other hand wide deployment and usage will be an important feature of any RDS design.
RFC 1737に記載されているURNはグローバルに定義されています。 URNはあらゆるコンテキストのどこにでも同じリソースを識別するという点でユビキタスです。 URNに関するこの要件を考えると、RDSへの影響について質問する必要があります。ユビキタスはどこでもRDS解決の保証を意味しますか？ユビキタスは、どこでも解決に関する同じ情報への解決を意味しますか？どちらの場合も、答えはおそらく違います。理由を超えた費用を除いて、人はグローバルで体系的な保証をすることはできません。加えて、どこでも同じ方法で解決しないことには、ポリシー上および技術上の理由があるかもしれません。リソースのインスタンスへのURNの解決が、異なる条件下で異なるインスタンスまたはコピーに到達する可能性は十分にあります。したがって、URNはどこでも同じリソースを参照しますが、一部の環境と特定の状況では、ネットワーク状況の変動またはポリシー制御により、URNは解決できる場合と解決できない場合があります。ネーミングがユビキタスだからといって、ユビキタスな解決を前提とすることはできません。一方、幅広い展開と使用は、RDS設計の重要な機能です。
Within the URI community there has been a concept used frequently that for lack of a better term we will call a _hint_. A hint is something that helps in the resolution of a URN; in theory we map URNs to hints as an interim stage in accessing a resource. In practice, an RDS may map a URN directly into the resource itself if it chooses to. It is very likely that there will be hints that are applicable to large sets of URNs, for example, a hint that indicates that all URNs with a certain prefix or suffix can be resolved by a particular resolver. A hint may also have meta-information associated with it, such as an expiration time or certification of authenticity. We expect that these will stay with a hint rather than being managed elsewhere. We will assume in all further discussion of hints that they include any necessary meta-information as well as the hint information itself. Examples of hints are: 1) the URN of a resolver service that may further resolve the URN, 2) the address of such a service, 3) a location at which the resource was previously found. The defining feature of hints is that they are only hints; they may be out of date, temporarily invalid, or only applicable within a specific locality. They do not provide a guarantee of access, but they probably will help in the resolution process. By whatever means available, a set of hints may be discovered. Some combination of software and human choice will determine which hints will be tried and in what order.
URIコミュニティ内では、より良い用語がないために_hint_と呼ぶ概念が頻繁に使用されています。ヒントは、URNの解決に役立つものです。理論的には、リソースへのアクセスの暫定段階として、URNをヒントにマッピングします。実際には、RDSは、必要に応じて、URNをリソース自体に直接マッピングできます。たとえば、特定のプレフィックスまたはサフィックスを持つすべてのURNが特定のリゾルバーによって解決できることを示すヒントなど、URNの大きなセットに適用できるヒントがある可能性が非常に高いです。ヒントには、有効期限や信頼性の証明など、メタ情報が関連付けられている場合もあります。これらは、他の場所で管理されるのではなく、ヒントとともに残ることを期待しています。ヒントに関するこれ以降のすべての説明では、ヒント情報自体だけでなく、必要なメタ情報も含まれていると想定します。ヒントの例は、1）URNをさらに解決できるリゾルバーサービスのURN、2）そのようなサービスのアドレス、3）以前にリソースが見つかった場所です。ヒントの特徴は、ヒントにすぎないことです。古くなっている、一時的に無効である、または特定の地域内でのみ適用される可能性があります。アクセスを保証するものではありませんが、おそらく解決プロセスに役立ちます。利用可能な手段によって、一連のヒントが見つかる場合があります。ソフトウェアと人間の選択の組み合わせによって、試行されるヒントとその順序が決まります。
We must assume that most resolutions of URNs will be provided by the use of locally stored hints, because maintaining a database of globally available, completely up-to-date location information is infeasible for performance reasons. There are a number of circumstances in which one can imagine that hints become invalid, either because a resource has moved or because a different URN resolver service has taken over the responsibility for resolution of the URN. Hints may be found in a variety of places. It is generally assumed that a well engineered system will maintain or cache a set of hints for each URN at each location where that URN is found. These may have been acquired from the owner of the resources, a recommendation of the resource, or one of many other sources. In addition, for those situations in which those hints found locally fail, a well engineered system will provide a fall-back mechanism for discovering further hints. It is this fall-back mechanism, an RDS, that is being addressed in this document. As with all hints, there can never be a guarantee that access to a resource will be available to all clients, even if the resource is accessible to some. However, an RDS is expected to work with reasonably high reliability, and, hence, may result in increased response time.
パフォーマンス上の理由から、グローバルに利用可能な完全に最新の位置情報のデータベースを維持することは不可能であるため、URNのほとんどの解決はローカルに保存されたヒントを使用して提供されると想定する必要があります。リソースが移動したため、または別のURNリゾルバーサービスがURNの解決の責任を引き継いだために、ヒントが無効になることを想像できる多くの状況があります。ヒントはさまざまな場所にあります。一般に、適切に設計されたシステムは、そのURNが見つかった各場所で各URNのヒントのセットを維持またはキャッシュすると想定されています。これらは、リソースの所有者、リソースの推奨、または他の多くのソースの1つから取得された可能性があります。さらに、ローカルで見つかったヒントが失敗する状況では、適切に設計されたシステムが、さらなるヒントを発見するためのフォールバックメカニズムを提供します。このドキュメントで取り上げられているのは、このフォールバックメカニズムであるRDSです。すべてのヒントと同様に、たとえリソースがアクセス可能であっても、リソースへのアクセスがすべてのクライアントで利用できるという保証はありません。ただし、RDSはかなり高い信頼性で動作することが期待されているため、応答時間が長くなる可能性があります。
The remainder of this document falls into three sections. The first identifies several sets of assumptions underlying this work. There are three general assumptions:
このドキュメントの残りの部分は、3つのセクションに分かれています。 1つ目は、この作業の基礎となるいくつかの仮定のセットを識別します。 3つの一般的な仮定があります。
* URNs are persistent; * URN assignment can be delegated; * Decisions can be made independently, enabling isolation from decisions of one's peers.
* URNは永続的です。 * URN割り当ては委任できます。 *意思決定を個別に行うことができるため、同僚の意思決定から分離することができます。
The next section lays out three central principles Resolver Discovery Service design. For each of these, we have identified a number of more specific guidelines that further define and refine the general principle. This section is probably the most critical of the document, because one must hold any proposed RDS scheme up against these principles and corollary guidelines to learn whether or not it is adequate. The three central principles can be summarized as:
次のセクションでは、Resolver Discovery Service設計の3つの中心的な原則を説明します。これらのそれぞれについて、一般的な原則をさらに定義および改良する、より具体的なガイドラインをいくつか特定しました。このセクションはおそらく、ドキュメントの最も重要な部分です。提案されたRDSスキームをこれらの原則および必然的なガイドラインに逆らって、適切かどうかを学習する必要があるためです。 3つの中心的な原則は、次のように要約できます。
1) An RDS must allow for evolution and evolvability;
2) Usability of an RDS with regard to each of the sets of
constituents involved in the identification and location or
resources is paramount;
3) It is centrally important that the security and privacy needs
of all constituents be feasibly supported, to the degree
possible.
Each of the three major subsections of the guidelines section begins with a summary list of the more detailed guidelines identified in that section.
ガイドラインセクションの3つの主要なサブセクションはそれぞれ、そのセクションで特定されたより詳細なガイドラインの要約リストから始まります。
The final section of the document lays out a framework for such RDSs. The purpose of this last section is to bound the search space for RDS schemes. The RDS designer should be aware that meeting the guidelines is of primary importance; it is possible to meet them without conforming to the framework. As will be discussed further in this last section, designing within the framework does not guarantee compliance, so compliance evaluation must also be part of the process of evaluation of a scheme.
ドキュメントの最後のセクションでは、そのようなRDSのフレームワークを説明します。この最後のセクションの目的は、RDSスキームの検索スペースを制限することです。 RDS設計者は、ガイドラインを満たすことが最も重要であることを認識しておく必要があります。フレームワークに準拠せずにそれらを満たすことが可能です。この最後のセクションでさらに説明するように、フレームワーク内の設計はコンプライアンスを保証するものではないため、コンプライアンス評価もスキームの評価プロセスの一部である必要があります。
Based on previous internet drafts and discussion in both the URN BOFs and on the URN WG mailing list, three major areas of assumptions are apparent: longevity, delegation, and independence. Each will be discussed separately.
以前のインターネットドラフトおよびURN BOFとURN WGメーリングリストの両方での議論に基づいて、長寿、委任、および独立性という3つの主要な想定領域が明らかです。それぞれについて個別に説明します。
The URN requirements [2] state that a URN is to be a "persistent identifier". It is probably the case that nothing will last forever, but in the time frame of resources, users of those resources, and the systems to support the resources, the identifier should be considered to be persistent or have a longer lifetime than those other entities. There are two assumptions that are implied by longevity of URNs: mobility and evolution. Mobility will occur because resources may move from one machine to another, owners of resources may move among organizations, or the organizations themselves may merge, partition, or otherwise transforms themselves. The Internet is continually evolving; protocols are being revised, new ones created, while security policies and mechanisms evolve as well. These are only examples. In general, we must assume that almost any piece of the supporting infrastructure of URN resolution will evolve. In order to deal with both the mobility and evolution assumptions that derive from the assumption of longevity, we must assume that users and their applications can remain independent of these mutating details of the supporting infrastructure.
URNの要件[2]では、URNは「永続的な識別子」であると規定されています。おそらく何も永遠に続くことはないかもしれませんが、リソース、それらのリソースのユーザー、およびリソースをサポートするシステムの時間枠では、識別子は永続的であるか、他のエンティティよりも寿命が長いと見なされます。 URNの寿命によって暗示される2つの仮定：移動性と進化。リソースが1つのマシンから別のマシンに移動したり、リソースの所有者が組織間を移動したり、組織自体がマージ、パーティション化、またはその他の方法で変換したりするため、モビリティが発生します。インターネットは絶えず進化しています。プロトコルは改訂され、新しいプロトコルが作成されていますが、セキュリティポリシーとメカニズムも進化しています。これらは単なる例です。一般に、URN解決のサポートインフラストラクチャのほぼすべての部分が進化すると想定する必要があります。寿命の仮定から派生するモビリティと進化の両方の仮定に対処するために、ユーザーとそのアプリケーションは、サポートするインフラストラクチャのこれらの変化する詳細から独立したままでいることができると仮定する必要があります。
The second assumption is that naming and resolution authorities may delegate some of their authority or responsibility; in both cases, the delegation of such authority is the only known method of allowing for the kind of scaling expected. It is important to note that a significant feature of this work is the potential to separate name assignment, the job of labelling a resource with a URN, from name resolution, the job of discovering the resource given the URN. In both cases, we expect multi-tiered delegation. There may be RDS schemes that merge these two sets of responsibilities and delegation relationships; by doing so, they bind together or overload two distinctly different activities, thus probably impeding growth.
2番目の前提は、命名および解決の権限が権限または責任の一部を委任する可能性があることです。どちらの場合でも、そのような権限の委任は、期待される種類のスケーリングを可能にする唯一の既知の方法です。この作業の重要な特徴は、名前の割り当て（URNでリソースにラベルを付ける作業）と名前解決（URNで指定されたリソースを発見する作業）を区別できる可能性があることです。どちらの場合も、多層の委任を想定しています。これらの2つのセットの責任と委任関係をマージするRDSスキームが存在する場合があります。そうすることで、2つの明確に異なるアクティビティを結合またはオーバーロードし、おそらく成長を妨げます。
The third assumption is independence or isolation of one authority from another and, at least to some extent, from its parent. When one authority delegates some of its rights and responsibilities to another authority, the delegatee can operate in that domain independently of its peers and within bounds specified by the delegation, independently of the delegator. This isolation is critically important in order to allow for independence of policy and mechanism.
3番目の仮定は、ある権限を別の権限から、少なくともある程度はその親から独立または分離することです。ある機関がその権限と責任の一部を別の機関に委任する場合、被委任者は、そのピアとは無関係に、委任者によって指定された範囲内で、委任者とは無関係に、そのドメインで操作できます。この分離は、ポリシーとメカニズムの独立を可能にするために非常に重要です。
This third assumption has several corollaries. First, we assume that the publisher of a resource can choose resolver services, independently of choices made by others. At any given time, the owner of a namespace may choose a particular URN resolver service for that delegated namespace. Such a URN resolver service may be outside the RDS service model, and only identified or located by the RDS service. Second, it must be possible to make a choice among RDS services. The existence of multiple RDS services may arise from the evolution of an RDS service, or development of new ones. Although at any given time there is likely to be only one or a small set of such services, the number is likely to increase during a transition period from one architecture to another. Thus, it must be assumed that clients can make a choice among a probably very small set of RDSs. Third, there must be independence in the choice about levels and models of security and authenticity required. This choice may be made by the owner of a naming subspace, in controlling who can modify hints in that subspace. A naming authority may delegate this choice to the owners of the resources named by the names it has assigned. There may be limitations on this freedom of choice in order to allow other participants to have the level of security and authenticity they require, for example, in order to maintain the integrity of the RDS infrastructure as a whole. Fourth, there is an assumption of independence of choice of the rule of canonicalization of URNs within a namespace, limited by any restrictions or constraints that may have been set by its parent namespace. This is a choice held by naming authorities over their own subnamespaces. Rules for canonicalization will be discussed further in the framework section below. Thus, there are assumptions of independence and isolation to allow for delegated, independent authority in a variety of domains.
この3番目の仮定には、いくつかの帰結があります。まず、リソースのパブリッシャーは、他のユーザーが行った選択とは関係なく、リゾルバーサービスを選択できると想定します。いつでも、名前空間の所有者は、その委任された名前空間に対して特定のURNリゾルバサービスを選択できます。このようなURNリゾルバーサービスは、RDSサービスモデルの外部にある場合があり、RDSサービスによってのみ識別または特定されます。第2に、RDSサービスから選択できるようにする必要があります。複数のRDSサービスの存在は、RDSサービスの進化、または新しいサービスの開発から生じる可能性があります。このようなサービスは常に1つまたは少数のセットしかない可能性がありますが、その数は、あるアーキテクチャから別のアーキテクチャへの移行期間中に増加する可能性があります。したがって、クライアントはおそらく非常に小さいRDSのセットから選択できると想定する必要があります。第三に、必要なセキュリティと信頼性のレベルとモデルに関する選択には独立性が必要です。この選択は、名前付けサブスペースの所有者が、そのサブスペースのヒントを変更できるユーザーを制御するときに行うことができます。命名機関は、この選択を、割り当てた名前で名前が付けられたリソースの所有者に委任する場合があります。たとえばRDSインフラストラクチャ全体の整合性を維持するために、他の参加者が必要とするセキュリティと信頼性のレベルを持つことができるようにするには、この選択の自由に制限がある場合があります。第4に、ネームスペース内のURNの正規化のルールの選択の独立性は、親ネームスペースによって設定された可能性のある制限または制約によって制限されるという仮定があります。これは、独自のサブネームスペースに対する命名機関が保持する選択です。正規化のルールについては、以下のフレームワークセクションでさらに説明します。したがって、さまざまなドメインで委任された独立した権限を許可するための独立性と分離の前提条件があります。
The modularity assumptions of delegation and isolation imply independence of decision and implementation, leading to a decentralization that provides a certain degree of safety from denial of service. Based on these these assumptions in conjunction with that of longevity and those for URLs and URNs as detailed in RFCs 1736 and 1737, we can now turn to the guidelines for an RDS.
委任と分離のモジュール性の仮定は、意思決定と実装の独立性を意味し、サービス拒否からある程度の安全性を提供する分散化につながります。 RFC 1736と1737に詳述されているように、これらの前提条件と、寿命およびURLおよびURNの前提条件に基づいて、RDSのガイドラインに目を向けることができます。
The guidelines applying to an RDS center around three important design principles in the areas of evolvability, usability, and security and privacy. At its core the function of an RDS is to provide hints for accessing a resource given a URN for it. These hints may range in applicability from local to global, and from short-lived to long-lived. They also may vary in their degree of verifiable authenticity. While it may be neither feasible nor necessary that initial implementations support every guideline, every implementation must support evolution to systems that do support the guidelines more fully.
RDSに適用されるガイドラインは、進化性、使いやすさ、セキュリティとプライバシーの領域における3つの重要な設計原則を中心にしています。 RDSの中心的な機能は、URNが指定されたリソースにアクセスするためのヒントを提供することです。これらのヒントの適用範囲は、ローカルからグローバル、および短命から長命までさまざまです。また、検証可能な信頼性の程度も異なります。初期実装がすべてのガイドラインをサポートすることは実現可能でも必要でもないかもしれませんが、すべての実装は、ガイドラインをより完全にサポートするシステムへの進化をサポートする必要があります。
It is important to note that there are requirements, not applicable specifically to an RDS that must also be met. A whole URN system will consist of names in namespaces, the resolution information for them, and the mapping from names in the namespaces to resolution information (or hints). URNs themselves must meet the requirements of RFC 1737. In addition, namespaces themselves must meet certain requirements as described by the URN Working Group [4]. Although all these requirements and guidelines are not described here, they must be supported to provide an acceptable system.
要件があり、満たす必要があるRDSには特に適用できないことに注意してください。 URNシステム全体は、名前空間の名前、それらの解決情報、および名前空間の名前から解決情報（またはヒント）へのマッピングで構成されます。 URN自体はRFC 1737の要件を満たす必要があります。さらに、URNワーキンググループ[4]で説明されているように、名前空間自体も特定の要件を満たす必要があります。これらの要件とガイドラインのすべてはここでは説明されていませんが、許容できるシステムを提供するためにサポートする必要があります。
Each section below begins with a summary of the points made in that section. There is some degree of overlap among the areas, such as in allowing for the evolution of security mechanisms, etc., and hence issues may be addressed in more than one section. It is also important to recognize that conformance with the guidelines will often be subjective. As with many IETF guidelines and requirements, many of these are not quantifiable and hence conformance is a judgment call and a matter of degree. Lastly, the reader may find that some of them are those of general applicability to distributed systems and some are specific to URN resolution. Those of general applicability are included for completeness and are not distinguished as such.
以下の各セクションは、そのセクションで行われたポイントの概要から始まります。セキュリティメカニズムの進化を可能にするなど、領域間である程度の重複があるため、問題が複数のセクションで対処される場合があります。ガイドラインへの適合は主観的であることが多いことを認識することも重要です。多くのIETFガイドラインと要件と同様に、これらの多くは定量化できないため、適合性は判断の呼びかけであり、程度の問題です。最後に、読者の中には、分散システムに一般的に適用できるものもあれば、URN解決に固有のものもあることに気付くかもしれません。一般的な適用性のものは完全を期すために含まれており、そのように区別されていません。
The issues in the area of the first principle, that of evolvability, are:
第一の原則、つまり進化可能性の領域の問題は次のとおりです。
1.1) An RDS must be able to support scaling in at least three
dimensions: the number of resources for which URNs will be
required, the number of publishers and users of those
resources, and the complexity of the delegation, as
authority for resolution grows and possibly reflects
delegation in naming authority;
1.2) A hint resolution environment must support evolution of
mechanisms, specifically for:
* a growing set of URN schemes;
* new kinds local URN resolver services;
* new authentication schemes;
* alternative RDS schemes active simultaneously;
1.3) An RDS must allow the development and deployment of
administrative control mechanisms to manage human behavior
with respect to limited resources.
One of the lessons of the Internet that we must incorporate into the development of mechanisms for resolving URNs is that we must be prepared for change. Such changes may happen slowly enough to be considered evolutionary modifications of existing services, or dramatically enough to be considered revolutionary. They may permeate the Internet universe bit by bit, living side by side with earlier services or they may take the Internet by storm, causing an apparent complete transformation over a short period of time. There are several directions in which we can predict the need for evolution. At the very least, the community and the mechanisms proposed should be prepared for these.
URNを解決するメカニズムの開発に組み込む必要があるインターネットの教訓の1つは、変更に備える必要があるということです。このような変更は、既存のサービスの進化的変更と見なされるほどゆっくりと発生する場合もあれば、革命的と見なされるほど劇的に発生する場合もあります。彼らは少しずつインターネットの世界に浸透し、以前のサービスと並んで生活しているかもしれませんし、インターネットに嵐を巻き起こして、短期間に明らかに完全な変革を引き起こしているかもしれません。進化の必要性を予測できる方向はいくつかあります。少なくとも、提案されているコミュニティとメカニズムは、これらに備える必要があります。
First, scaling is a primary issue in conjunction with evolution. The number of users, both human and electronic, as well as the number of resources will continue to grow exponentially for the near term, at least. Hence the number of URNs will also increase similarly. In addition, with growth in sheer numbers is likely to come growth in the delegation of both naming authority and resolution authority. These facts mean that an RDS design must be prepared to handle increasing numbers of requests for inclusion, update and resolution, in a set of RDS servers perhaps inter-related in more complex ways. This is not to say that there will necessarily be more updates or resolutions per URN; we cannot predict that at this time. But, even so, the infrastructure may become more complex due to delegation, which may (as can be seen in Section 4 on the framework) lead to more complex rules for rewriting or extracting terms for staged resolution. Any design is likely to perform less well above some set of limits, so it is worth considering the growth limitations of each design alternative.
第一に、スケーリングは進化とともに主要な問題です。人間と電子の両方のユーザー数とリソース数は、少なくとも短期的には指数関数的に増加し続けます。したがって、URNの数も同様に増加します。さらに、数の増加に伴い、命名機関と解決機関の両方の委任が増加する可能性があります。これらの事実は、RDSの設計は、おそらくより複雑な方法で相互に関連している一連のRDSサーバーで、包含、更新、および解決のためのますます多くの要求を処理するように準備する必要があることを意味します。これは、必ずしもURNごとに更新や解決策が増えることを意味するものではありません。現時点では予測できません。ただし、そうであっても、委任によりインフラストラクチャはより複雑になる可能性があり、（フレームワークのセクション4でわかるように）段階的な解決のために用語を書き換えまたは抽出するためのより複雑なルールにつながる可能性があります。どの設計でも、特定の制限セットを超えるとパフォーマンスが低下する可能性が高いため、各設計代替案の拡張制限を検討する価値があります。
Second, we expect there to be additions and changes to the mechanisms. The community already understands that there must be a capacity for new URN schemes, as described in [4]. A URN scheme will define a set of URNs that meet the URN requirements [2], but may have further constraints on the internal structure of the URN. The intention is that URN schemes can be free to specify parts of the URN that are left opaque in the larger picture. In fact, a URN scheme may choose to make public or keep private the algorithms for any such "opaque" part of the URN. In any case, we must be prepared for a growing number of URN schemes.
第二に、メカニズムへの追加と変更があることを期待しています。コミュニティは、[4]で説明されているように、新しいURNスキームのキャパシティが必要であることをすでに理解しています。 URNスキームは、URN要件を満たす一連のURNを定義しますが[2]、URNの内部構造にさらに制約がある場合があります。意図は、URNスキームは、大きな図では不透明のままになっているURNの部分を自由に指定できることです。実際、URNスキームは、URNの「不透明な」部分のアルゴリズムを公開するか、非公開にするかを選択できます。いずれにせよ、ますます多くのURNスキームに備える必要があります。
Often in conjunction with a new URN scheme, but possibly independently of any particular URN scheme, new kinds of resolver services may evolve. For example, one can imagine a specialized resolver service based on the particular structure of ISBNs that improves the efficiency of finding documents given their ISBNs. Alternatively, one can also imagine a general purpose resolver service that trades performance for generality; although it exhibits only average performance resolving ISBNs, it makes up for this weakness by understanding all existing URN schemes, so that its clients can use the same service to resolve URNs regardless of naming scheme. In this context, there will always be room for improvement of services, through improved performance, better adaptability to new URN schemes, or lower cost, for example. New models for URN resolution will evolve and we must be prepared to allow for their participation in the overall resolution of URNs.
多くの場合、新しいURNスキームと組み合わせて使用されますが、特定のURNスキームとは無関係に、新しい種類のリゾルバーサービスが進化する可能性があります。たとえば、ISBNの特定の構造に基づいて、ISBNが指定されたドキュメントを検索する効率を向上させる特殊なリゾルバサービスを想像できます。あるいは、パフォーマンスと汎用性をトレードオフする汎用リゾルバーサービスを想像することもできます。 ISBNを解決する平均的なパフォーマンスのみを示しますが、既存のすべてのURNスキームを理解することでこの弱点を補うため、クライアントは同じサービスを使用して命名スキームに関係なくURNを解決できます。このコンテキストでは、たとえば、パフォーマンスの向上、新しいURNスキームへの適応性の向上、コストの削減など、サービスの改善の余地は常にあります。 URN解決の新しいモデルは進化し、URNの全体的な解決に参加できるように準備する必要があります。
If we begin with one overall plan for URN resolution, into which the enhancements described above may fit, we must also be prepared for an evolution in the authentication schemes that will be considered either useful or necessary in the future. There is no single globally accepted authentication scheme, and there may never be one. Even if one does exist at some point in time, we must always be prepared to move on to newer and better schemes, as the old ones become too easily spoofed or guessed.
上記の拡張機能が適合する可能性があるURN解決のための1つの全体的な計画から始める場合、将来的に有用または必要であると見なされる認証方式の進化にも備える必要があります。グローバルに受け入れられる認証方式は1つではなく、存在することもありません。ある時点で存在する場合でも、古いスキームは簡単になりすまされたり推測されたりするため、常に新しいより優れたスキームに移行する準備をする必要があります。
In terms of mechanism, although we may develop and deploy a single RDS scheme initially, we must be prepared for that top level model to evolve. Thus, if the RDS model supports an apparently centralized (from a policy standpoint) scheme for inserting and modifying authoritative information, over time we must be prepared to evolve to a different model, perhaps one that has a more distributed model of authority and authenticity. If the model has no core but rather a cascaded partial discovery of information, we may find that this becomes unmanageable with an increase in scaling. Whatever the model, we must be prepared for it to evolve with changes in scaling, performance, and policy constraints such as security and cost.
メカニズムに関しては、最初は単一のRDSスキームを開発して展開する可能性がありますが、その最上位モデルが進化する準備をする必要があります。したがって、RDSモデルが信頼できる情報を挿入および変更するための明らかに一元化された（ポリシーの観点から）スキームをサポートする場合、時間の経過とともに、異なるモデルに進化する準備を整える必要があります。モデルにコアがなく、カスケードされた情報の部分的な発見がある場合、スケーリングの増加に伴ってこれが管理できなくなる可能性があります。モデルが何であれ、スケーリング、パフォーマンス、およびセキュリティやコストなどのポリシーの制約の変化に合わせて進化させる準備をする必要があります。
The third evolutionary issue is even more mechanical than the others. At any point in time, the community is likely to be supporting a compromise position with respect to resolution. We will probably be operating in a situation balanced between feasibility and the ideal, perhaps with policy controls used to help stabilize use of the service. Ideally, the service would be providing exactly what the customers wanted and they in turn would not request more support than they need, but it seems extremely unlikely. Since we will almost always be in a situation in which some service provision resources will be in short supply, some form of policy controls will generally be necessary. Some policy controls may be realized as mechanisms within the servers or in the details of protocols, while others may only be realized externally to the system. For example, suppose hint entries are being submitted in such volume that the hint servers are using up their excess capacity and need more disk space. Two suggestions for policy control are pricing and administrative. As technology changes and the balance of which resources are in short supply changes, the mechanisms and policies for controlling their use must evolve as well.
3番目の進化論的問題は、他の問題よりもさらに機械的です。いつの時点でも、コミュニティは解決に関して妥協的な立場を支持している可能性があります。おそらくサービスの使用を安定させるのに役立つポリシー制御を使用して、実現可能性と理想の間でバランスの取れた状況で運用することになります。理想的には、サービスは顧客が望むものを正確に提供し、顧客は必要以上のサポートを要求しないことが理想ですが、それは非常にありそうにないようです。ほとんどの場合、サービス提供リソースの一部が不足する状況になるため、何らかの形のポリシー制御が一般に必要になります。一部のポリシー制御は、サーバー内またはプロトコルの詳細内のメカニズムとして実現できますが、その他はシステムの外部でのみ実現できます。たとえば、ヒントエントリがそのようなボリュームで送信され、ヒントサーバーが余剰容量を使い果たし、より多くのディスク領域が必要になるとします。ポリシー制御に関する2つの提案は、価格設定と管理です。テクノロジーが変化し、不足しているリソースのバランスが変化するにつれて、それらの使用を制御するためのメカニズムとポリシーも進化する必要があります。
To summarize, the usability guidelines fall into three areas based on participation in hint management and discovery:
要約すると、ユーザビリティガイドラインは、ヒントの管理と発見への参加に基づいて3つの領域に分類されます。
2.1) The publisher
2.1.1) URN to hint resolution must be correct and efficient
with very high probability;
2.1.2) Publishers must be able to select and move among URN
resolver services to locate their resources;
2.1.3) Publishers must be able to arrange for multiple access
points for their location information;
2.1.4) Publishers should be able to provide hints with
varying lifetimes;
2.1.5) It must be relatively easy for publishers to specify
to the management and observe their hint information as
well as any security constraints they need for their
hints.
2.2) The client
2.2.1) The interface to the RDS must be simple, effective,
and efficient;
2.2.2) The client and client applications must be able to
understand the information stored in and provided by
the RDS easily, in order to be able to make informed
choices.
2.3) The management
2.3.1) The management of hints must be as unobtrusive as
possible, avoiding using too many network resources;
2.3.2) The management of hints must allow for administrative controls that encourage certain sorts of behavior deemed necessary to meet other requirements; 2.3.3) The configuration and verification of configuration of individual RDS servers must be simple enough not to discourage configuration and verification.
2.3.2）ヒントの管理では、他の要件を満たすために必要であると見なされる特定の種類の動作を奨励する管理制御を許可する必要があります。 2.3.3）個々のRDSサーバーの構成と構成の検証は、構成と検証を妨げないように十分に単純でなければなりません。
Usability can be evaluated from three distinct perspectives: those of a publisher wishing to make a piece of information public, those of a client requesting URN resolution, and those of the provider or manager of resolution information. We will separately address the usability issues from each of these three perspectives. It is important to recognize that these may be sitautions in which interests of some of the participants (for exampel a use and a publisher) may be in conflict; some resolution will be needed.
使いやすさは、3つの異なる視点から評価できます。情報の一部を公開したいパブリッシャーの視点、URN解決を要求するクライアントの視点、および解決情報のプロバイダーまたはマネージャーの視点です。これらの3つの視点のそれぞれから、ユーザビリティの問題に個別に対処します。これらは、一部の参加者（たとえば、使用と発行者）の利益が対立する可能性がある状況である可能性があることを認識することが重要です。いくつかの解決策が必要になります。
It is worth noting that there are two additional sorts of participants in the whole naming process, as discussed in the URN WG. They are the naming authorities which choose and assign names, and the authors who include URNs in their resources. These two are not relevant to the design of an RDS and hence are not discussed further here.
URN WGで議論されているように、命名プロセス全体には2種類の参加者がいることは注目に値します。これらは、名前を選択して割り当てる命名機関と、リソースにURNを含める作成者です。これら2つはRDSの設計には関係ないため、ここではこれ以上説明しません。
The publisher must be able to make URNs known to potential customers. From the perspective of a publisher, it is of primary importance that URNs be correctly and efficiently resolvable by potential clients with very high probability. Publishers stand to gain from long-lived URNs, since they increase the chance that references continue to point to their published resources.
パブリッシャーは、URNを潜在的な顧客に知らせることができなければなりません。パブリッシャーの観点からは、URNが非常に高い確率で潜在的なクライアントによって正確かつ効率的に解決できることが最も重要です。パブリッシャーは、参照がパブリッシュされたリソースをポイントし続ける可能性を高めるため、長期間有効なURNから利益を得る立場にあります。
The publisher must also be able to choose easily among a variety of potential services that might translate URNs to location information. In order to allow for this mobility among resolvers, the RDS architecture must support such transitions, within policy control bounds. It is worth noting that although multiple listing services are available in telephone books, they are generally accompanied by a fee. There is nothing preventing there being fees collected for similar sorts of services with respect to URNs.
また、発行者は、URNを位置情報に変換する可能性のあるさまざまな潜在的なサービスの中から簡単に選択できる必要があります。リゾルバ間でこのモビリティを可能にするために、RDSアーキテクチャは、ポリシー制御境界内でそのような移行をサポートする必要があります。電話帳で複数のリスティングサービスを利用できますが、通常は有料です。 URNに関して同様の種類のサービスに対して料金が徴収されることを妨げるものは何もありません。
The publisher must be able to arrange for multiple access points to a published resource. For this to be useful, resolver services should be prepared to provide different resolution or hint information to different clients, based on a variety of information including location and the various access privileges the client might have. It is important to note that this may have serious implications for caching this information. For example, companies might arrange for locally replicated copies of popular resources, and would like to provide access to the local copies only for their own employees. This is distinct from access control on the resource as a whole, and may be applied differently to different copies.
パブリッシャーは、公開されたリソースへの複数のアクセスポイントを手配できる必要があります。これが役立つためには、場所やクライアントが持つ可能性のあるさまざまなアクセス特権などのさまざまな情報に基づいて、さまざまな解決またはヒント情報をさまざまなクライアントに提供するリゾルバーサービスを準備する必要があります。これは、この情報のキャッシュに深刻な影響を与える可能性があることに注意することが重要です。たとえば、人気のあるリソースのローカルに複製されたコピーを用意し、自分の従業員だけにローカルコピーへのアクセスを提供したいとします。これは、リソース全体のアクセス制御とは異なり、コピーごとに異なる方法で適用できます。
The publisher should be able to provide both long and short term location information about accessing the resource. Long term information is likely to be such information as the long term address of a resource itself or the location or identity of a resolver service with which the publisher has a long term relationship. One can imagine that the arrangement with such a long term "authoritative" resolver service might be a guarantee of reliability, resiliency to failure, and atomic updates. Shorter term information is useful for short term changes in services or to avoid short lived congestion or failure problems. For example, if the actual repository of the resource is temporarily inaccessible, the resource might be made available from another repository. This short term information can be viewed as temporary refinements of the longer term information, and as such should be more easily and quickly made available, but may be less reliable. Some RDS designs may not distinguish between these two extremes.
パブリッシャーは、リソースへのアクセスに関する長期および短期の両方の位置情報を提供できる必要があります。長期的な情報は、リソース自体の長期的なアドレスや、パブリッシャーが長期的な関係を持つリゾルバーサービスの場所やIDなどの情報である可能性があります。このような長期間にわたる「信頼できる」リゾルバサービスを使用することで、信頼性、障害に対する回復力、およびアトミックな更新が保証される可能性があると想像できます。短期的な情報は、サービスの短期的な変更や、短期間の輻輳や障害の問題を回避するのに役立ちます。たとえば、リソースの実際のリポジトリに一時的にアクセスできない場合、そのリソースは別のリポジトリから利用できるようになる可能性があります。この短期的な情報は、長期的な情報の一時的な改善と見なすことができるため、より簡単かつ迅速に利用可能にする必要がありますが、信頼性が低くなる可能性があります。一部のRDS設計では、これら2つの極端を区別できない場合があります。
Lastly, the publishers will be the source of much hint information that will be stored and served by the manager of the infrastructure. Despite the fact that many publishers will not understand the details of the RDS mechanism, it must be easy and straightforward for them to install hint information. This means that in general any one who wishes to publish and to whom the privilege of resolution has been extended through delegation, can do so. The publisher must be able not only to express hints, but also to verify that what is being served by the manager is correct. Furthermore, to the extent that there are security constraints on hint information, the publisher must be able to both express them and verify compliance with them easily.
最後に、発行者は、インフラストラクチャの管理者によって保存および提供される多くのヒント情報のソースになります。多くのパブリッシャーはRDSメカニズムの詳細を理解していないという事実にもかかわらず、彼らがヒント情報をインストールすることは簡単で簡単でなければなりません。これは、一般に、公開を希望し、委任を通じて解決の特権が付与されている人なら誰でもそうできることを意味します。パブリッシャーは、ヒントを表現できるだけでなく、マネージャーが提供しているものが正しいことを確認できなければなりません。さらに、ヒント情報にセキュリティ上の制約がある限り、発行者はそれらを表現し、それらのコンプライアンスを簡単に検証できる必要があります。
From the perspective of the client, simplicity and usability are paramount. Of critical importance to serving clients effectively is that there be an efficient protocol through which the client can acquire hint information. Since resolving the name is only the first step on the way to getting access to a resource, the amount of time spent on it must be minimized.
クライアントの観点からは、シンプルさと使いやすさが最も重要です。クライアントに効果的にサービスを提供するために非常に重要なことは、クライアントがヒント情報を取得できる効率的なプロトコルがあることです。名前の解決は、リソースへのアクセスを取得するための最初のステップに過ぎないため、リソースに費やされる時間を最小限に抑える必要があります。
Furthermore, it will be important to be able to build simple, standard interfaces to the RDS so that both the client and applications on the client's behalf can interpret hints and subsequently make informed choices. The client, perhaps with the assistance of the application, must be able to specify preferences and priorities and then apply them. If the ordering of hints is only partial, the client may become directly
さらに、クライアントとクライアントに代わってアプリケーションの両方がヒントを解釈し、その後、情報に基づいた選択を行えるように、RDSへのシンプルな標準インターフェースを構築できることが重要になります。クライアントは、おそらくアプリケーションの助けを借りて、設定と優先順位を指定して適用できる必要があります。ヒントの順序が部分的である場合、クライアントは直接なります。
involved in the choice and interpretation of them and hence they must be understandable to that client. On the other hand, in general it should be possible to configure default preferences, with individual preferences viewed as overriding any defaults.
それらの選択と解釈に関与するため、それらはそのクライアントに理解可能でなければなりません。一方、一般にデフォルト設定を構成して、個々の設定をデフォルトよりも優先するように表示することが可能です。
From the client's perspective, although URNs will provide important functionality, the client is most likely to interact directly only with human friendly names (HFNs). As in direct human interaction (not computer mediated), the sharing of names will be on a small, private, or domain specific scale. HFNs will be the sorts of references and names that are easy to remember, type, choose among, assign, etc. There will also need to be a number of mechanisms for mapping HFNs to URNs. Such services as "yellow pages" or "search tools" fall into this category. Although we are mentioning HFNs here, it is important to recognize that HFNs and the mappings from HFNs to URNs is and must remain a separate functionality from an RDS. Hence, although HFNs will be critical to clients, they do not fall into the domain of this document.
クライアントの観点から見ると、URNは重要な機能を提供しますが、クライアントは人にやさしい名前（HFN）とのみ直接対話する可能性が最も高いです。人間との直接的なやり取り（コンピュータを介さない）と同様に、名前の共有は小規模、プライベート、またはドメイン固有のスケールで行われます。 HFNは、覚えたり、入力したり、選択したり、割り当てたりするのが簡単な種類の参照と名前になります。HFNをURNにマッピングするためのメカニズムもいくつか必要です。 「イエローページ」や「検索ツール」などのサービスはこのカテゴリに分類されます。ここではHFNについて触れていますが、HFNと、HFNからURNへのマッピングは、RDSとは別の機能であり、これを維持する必要があることを認識することが重要です。したがって、HFNはクライアントにとって重要ですが、このドキュメントのドメインには含まれません。
Finally, we must address the usability concerns with respect to the management of the hint infrastructure itself. What we are terming "management" is a service that is distinct from publishing; it is the core of an RDS. It involves the storage and provision of hints to the clients, so that they can find published resources. It also provides security with respect to name resolution to the extent that there is a commitment for provision of such security; this is addressed in Section 3.3 below.
最後に、ヒントインフラストラクチャ自体の管理に関するユーザビリティの問題に対処する必要があります。 「管理」とは、公開とは異なるサービスです。これはRDSの中核です。これには、クライアントへのヒントの保存と提供が含まれ、公開されたリソースを見つけることができます。また、名前の解決に関してセキュリティを提供しますが、そのようなセキュリティを提供することへのコミットメントがあります。これについては、以下のセクション3.3で説明します。
The management of hints must be as unobtrusive as possible. First, its infrastructure (hint storage servers and distribution protocols) must have as little impact as possible on other network activities. It must be remembered that this is an auxiliary activity and must remain in the background.
ヒントの管理はできるだけ控えめにする必要があります。まず、そのインフラストラクチャ（ヒントストレージサーバーと配布プロトコル）は、他のネットワークアクティビティにできるだけ影響を与えないようにする必要があります。これは補助的なアクティビティであり、バックグラウンドに留まる必要があることを忘れないでください。
Second, in order to make hint management feasible, there may need to be a system for administrative incentives and disincentives such as pricing or legal restrictions. Recovering the cost of running the system is only one reason for levying charges. The introduction of payments often has an impact on social behavior. It may be necessary to discourage certain forms of behavior that when out of control have serious negative impact on the whole community. At the same time, any administrative policies should encourage behavior that benefits the community as a whole. Thus, for example, a small one-time charge for authoritatively storing a hint might encourage conservative use of hints. If we assume that there is a fixed cost for managing a hint, then the broader its applicability across the URN space, the more cost effective it is. That is, when one hint can serve for a whole collection of URNs, there will be an incentive to submit one general hint over a large number of more specific hints. Similar policies can be instituted to discourage the frequent changing of hints. In these ways and others, behavior benefitting the community as a whole can be encouraged.
第二に、ヒント管理を実現可能にするために、価格設定や法的制限などの管理インセンティブとインセンティブのシステムが必要になる場合があります。システムの実行コストを回収することは、料金を徴収する理由の1つにすぎません。支払いの導入は、多くの場合、社会的行動に影響を与えます。暴走するとコミュニティ全体に深刻な悪影響を与える特定の行動を阻止することが必要になる場合があります。同時に、管理ポリシーはコミュニティ全体に利益をもたらす行動を奨励する必要があります。したがって、たとえば、ヒントを正式に格納するための1回限りの少額の料金は、ヒントの保守的な使用を促進する可能性があります。ヒントを管理するための固定コストがあると仮定すると、URNスペース全体でその適用範囲が広いほど、費用対効果が高くなります。つまり、1つのヒントがURNのコレクション全体に対応できる場合、多数のより具体的なヒントに対して1つの一般的なヒントを送信するインセンティブがあります。ヒントの頻繁な変更を阻止するために、同様のポリシーを導入できます。これらの方法やその他の方法で、コミュニティ全体に利益をもたらす行動を促すことができます。
Lastly, symmetric to issues of usability for publishers, it must also be simple for the management to configure the mapping of URNs to hints. It must be easy both to understand the configuration and to verify that configuration is correct. With respect to management, this issue may have an impact not only on the information itself but also on how it is partitioned among network servers that collaboratively provide the management service or RDS. For example, it should be straightforward to bring up a server and verify that the data it is managing is correct. Although this is not a guideline, it is worth nothing that since we are discussing a global and probably growing service, encouraging volunteer participants suggests that, as with the DNS, such volunteers can feel confident about the service they are providing and its benefit to both themselves and the rest of the community.
最後に、発行者の使いやすさの問題と対称的に、管理者がURNのヒントへのマッピングを構成することも簡単でなければなりません。構成を理解することも、構成が正しいことを確認することも簡単でなければなりません。管理に関しては、この問題は情報自体だけでなく、管理サービスまたはRDSを共同で提供するネットワークサーバー間での情報の分割方法にも影響を与える可能性があります。たとえば、サーバーを起動して、サーバーが管理しているデータが正しいことを確認するのは簡単です。これはガイドラインではありませんが、グローバルでおそらく成長しているサービスについて説明しているので、ボランティア参加者を奨励することは、DNSと同様に、そのようなボランティアが提供しているサービスとその両方に対する利点に自信を持つことができることを示唆することは何の価値もありません自分自身とコミュニティの残りの部分。
In summary, security and privacy guidelines can be identified as some degree of protection from threats. The guidelines that fall under this third principle, that of security, are all stated in terms of possibilities or options for users of the service to require and utilize. Hence they address the availability of functionality, but not for the use of it. We recognize that all security is a matter of degree and compromise. These may not satisfy all potential customers, and there is no intention here to prevent the building of more secure servers with more secure protocols to suit their needs. These are intended to satisfy the needs of the general public.
要約すると、セキュリティとプライバシーのガイドラインは、脅威からのある程度の保護として識別できます。この3番目の原則（セキュリティの原則）に該当するガイドラインはすべて、サービスのユーザーが必要とし利用する可能性またはオプションの観点から述べられています。したがって、それらは機能の可用性に対処しますが、その使用には対処しません。すべてのセキュリティは程度と妥協の問題であることを認識しています。これらはすべての潜在的な顧客を満足させるものではない可能性があり、ニーズに合わせてより安全なプロトコルを備えたより安全なサーバーの構築を妨げる意図はありません。これらは一般市民のニーズを満たすことを目的としています。
3.1) It must be possible to create authoritative versions of a
hint with access-to-modification privileges controlled;
3.2) It must be possible to determine the identity of servers or
avoid contact with unauthenticated servers;
3.3) It must be possible to reduce the threat of denial of
service by broad distribution of information across servers;
3.4) It must be possible within the bounds of organizational
policy criteria to provide at least some degree of privacy
for traffic;
3.5) It must be possible for publishers to keep private certain information such as an overall picture of the resources they are publishing and the identity of their clients; 3.6) It must be possible for publishers to be able to restrict access to the resolution of the URNs for the resources they publish, if they wish.
3.5）出版社は、出版しているリソースの全体像やクライアントのアイデンティティなどの特定の情報を非公開にしておくことが可能でなければなりません。 3.6）パブリッシャーは、必要に応じて、パブリッシュするリソースのURNの解決へのアクセスを制限できる必要があります。
When one discusses security, one of the primary issues is an enumeration of the threats being considered for mitigation. The tradeoffs often include cost in money and computational and communications resources, ease of use, likelihood of use, and effectiveness of the mechanisms proposed. With this in mind, let us consider a set of threats.
セキュリティについて論じる場合、主要な問題の1つは、緩和策として検討されている脅威の列挙です。トレードオフには、多くの場合、コストと計算および通信リソースのコスト、使いやすさ、使用の可能性、提案されたメカニズムの有効性が含まれます。これを念頭に置いて、一連の脅威について考えてみましょう。
Voydock and Kent [5] provide a useful catalog of potential threats. Of these the passive threats to privacy or confidentiality and the active threats to authenticity and integrity are probably the most important to consider here. To the extent that spurious association causes threats to the privacy, authenticity, or integrity with respect to information within servers managing data, it is also important. Denial of service is probably the most difficult of these areas of threats both to detect and to prevent, and we will therefore set it aside for the present as well, although it will be seen that solutions to other problems will also mitigate some of the problems of denial of service. Furthermore, because this is intended to be provide a global service to meet the needs of a variety of communities, the engineering tradeoffs will be different for different clients. Hence the guidelines are stated in terms of, "It must be possible..." It is important to note that the information of concern here is hint information, which by nature is not guaranteed to be correct or up-to-date; therefore, it is unlikely to be worth putting too much expense into the correctness of hints, because there is no guarantee that they are still correct anyway. The exact choice of degree of privacy, authenticity, and integrity must be determined by the needs of the client and the availability of services from the server.
VoydockとKent [5]は、潜在的な脅威の有用なカタログを提供しています。これらのうち、プライバシーまたは機密性に対する受動的な脅威と、信頼性および整合性に対する能動的な脅威は、おそらくここで検討する必要がある最も重要なものです。偽の関連付けが、データを管理するサーバー内の情報に関してプライバシー、信頼性、または整合性を脅かす程度まで、それも重要です。サービス拒否は、これらの脅威の領域の中で検出と防止の両方でおそらく最も困難であるため、他の問題の解決策によって問題の一部が軽減されることもわかりますが、現時点では除外します。サービス拒否の。さらに、これはさまざまなコミュニティのニーズを満たすグローバルサービスを提供することを目的としているため、エンジニアリングのトレードオフはクライアントによって異なります。したがって、ガイドラインは「可能でなければならない」という観点で述べられています。ここで問題となる情報はヒント情報であり、本質的に正確または最新であることが保証されていないことに注意してください。したがって、ヒントが正しいことを保証するものではないため、ヒントの正確性に多大な費用をかける価値はないでしょう。プライバシー、信頼性、完全性の程度の正確な選択は、クライアントのニーズとサーバーからのサービスの可用性によって決定される必要があります。
To avoid confusion it is valuable to highlight the meanings of terms that have different meanings in other contexts. In this case, the term "authoritative" as it is used here connotes the taking of an action or stamp of approval by a principal (again in the security sense) that has the right to perform such an act of approval. It has no implication of correctness of information, but only perhaps an implication of who claimed it to be correct. In contrast, the term is often also used simply to refer to a primary copy of a piece of information for which there may also be secondary or cached copies available. In this discussion of security we use the former meaning, although it may also be important to be able to learn about whether a piece of information is from a primary source or not and request that it be primary. This second meaning arises elsewhere in the document and is so noted there.
混乱を避けるために、他の文脈で異なる意味を持つ用語の意味を強調することは価値があります。この場合、ここで使用されている「権限のある」という用語は、そのような承認行為を実行する権利を持つプリンシパル（これもセキュリティの意味で）によるアクションまたは承認のスタンプの取得を意味します。それは情報の正確さの影響はありませんが、おそらくそれが正しいと主張した人の影響だけです。対照的に、この用語は多くの場合、利用可能な2次またはキャッシュされたコピーもある情報の1次コピーを単に指すために使用されます。このセキュリティの説明では、前者の意味を使用しますが、情報の一部がプライマリソースからのものであるかどうかを知り、それがプライマリであることを要求できることも重要です。この2番目の意味は、ドキュメントの他の場所で発生し、そこにそのように記載されています。
It is also important to distinguish various possible meanings for "access control". There are two areas in which distinctions can be made. First, there is the question of the kind of access control that is being addressed, for example, in terms of hints whether it is read access, read and modify access, or read with verification for authenticity. Second, there is the question of to what access is being controlled. In the context of naming it might be the names themselves (not the case for URNs), the mapping of URNs to hints (the business of an RDS), the mapping of URNs to addresses (not the business of an RDS as will be discussed below in terms of privacy), or the resource itself (unrelated to naming or name resolution at all). We attempt to be clear about what is meant when using "access control".
「アクセス制御」の考えられるさまざまな意味を区別することも重要です。区別できる領域は2つあります。 1つ目は、たとえば、読み取りアクセス、読み取りと変更アクセス、または信頼性の検証を伴う読み取りなどのヒントに関して、対処されているアクセス制御の種類の問題です。次に、どのアクセスが制御されているかという問題があります。名前付けのコンテキストでは、名前自体（URNの場合ではない）、ヒントへのURNのマッピング（RDSのビジネス）、アドレスへのURNのマッピング（RDSのビジネスではない）が考えられます。以下のプライバシーの観点から）、またはリソース自体（名前付けや名前解決とはまったく関係ありません）。 「アクセス制御」を使用する場合の意味を明確にするように努めます。
There is one further issue to address at this point, the distinction between mechanism and policy. In general, a policy is realized by means of a set of mechanisms. In the case of an RDS there may be policies internal to the RDS that it needs to have supported in order to do its business as it sees fit. Since, in general it is in the business of storing and distributing information, most of its security policies may have to do with maintaining its own integrity, and are rather limited. Beyond that, to the degree possible, it should impose no policy on its customers, the publishers and users. It is they that may have policies that they would like supported by the RDS. To that end, an RDS should provide a spectrum of "tools" or mechanisms that the customers can cause to be deployed on their behalf to realize policies. An RDS may not provide all that is needed by a customer. A customer may have different requirements within his or her administrative bounds than outside. Thus, "it must be possible..." captures the idea that the RDS must generally provide the tools to implement policies as needed by the customers.
この時点で取り組むべきもう1つの問題、メカニズムとポリシーの違いがあります。一般に、ポリシーは一連のメカニズムによって実現されます。 RDSの場合、RDSの内部に、適切と思われるビジネスを行うためにサポートする必要のあるポリシーがある場合があります。一般に、情報の保存と配布の業務であるため、そのセキュリティポリシーのほとんどは、独自の整合性の維持に関係する可能性があり、かなり制限されています。それを超えて、可能な限り、それはその顧客、出版社、ユーザーにポリシーを課すべきではありません。 RDSによるサポートを希望するポリシーを持つ可能性があるのは彼らです。そのために、RDSは、顧客がポリシーを実現するために配備するために導入できる一連の「ツール」またはメカニズムを提供する必要があります。 RDSは、顧客が必要とするすべてを提供するわけではありません。顧客には、管理範囲内と外部とでは異なる要件がある場合があります。したがって、「それは可能でなければならない...」は、RDSが一般に顧客の必要に応じてポリシーを実装するためのツールを提供する必要があるという考えを捉えています。
The first approach to URN resolution is to discover local hints. In order for hints to be discovered locally, they will need to be as widely distributed as possible to what is considered to be local for every locale. The drawback of such wide distribution is the wide distribution of updates, causing network traffic problems or delays in delivering updates. An alternative model would concentrate hint information in servers, thus requiring that update information only be distributed to these servers. In such a model the vulnerable points are the sources of the information and the distribution network among them. Attackers on the integrity of the information stored in a server may come in the form of masquerading as the owner or the server of the information. Wide replication of information among servers increases the difficult of masquerading at all the locations of the information as well as reducing the threat of denial service. These lead us to three identifiable guidelines for our security model:
URN解決への最初のアプローチは、ローカルヒントを発見することです。ヒントをローカルで発見するには、すべてのロケールでローカルと見なされるものにできるだけ広く配布する必要があります。このような幅広い配布の欠点は、更新が広範囲に配布され、ネットワークトラフィックの問題や更新の配信の遅延を引き起こすことです。代替モデルでは、ヒント情報をサーバーに集中させるため、更新情報はこれらのサーバーにのみ配布する必要があります。このようなモデルでは、脆弱なポイントは情報のソースとそれらの間の配信ネットワークです。サーバーに格納されている情報の整合性に対する攻撃者は、情報の所有者またはサーバーになりすましている形で来る可能性があります。サーバー間で情報を幅広く複製すると、情報のすべての場所でのなりすましが困難になるだけでなく、サービス拒否の脅威が軽減されます。これらにより、セキュリティモデルに関する3つの識別可能なガイドラインが導き出されます。
* ACCESS CONTROL ON HINTS: It must be possible to create an authoritative version of each hint with change control limited only to those principals with the right to modify it. The choice of who those principals are or whether they are unlimited must be made by the publisher of a hint.
* ヒントのアクセス制御：各ヒントの信頼できるバージョンを作成し、変更制御を、それを変更する権限を持つプリンシパルのみに制限する必要があります。それらのプリンシパルが誰であるか、またはそれらが無制限であるかどうかの選択は、ヒントの発行者が行う必要があります。
* SERVER AUTHENTICITY: Servers and clients must be able to learn the identity of the servers with which they communicate. This will be a matter of degree and it is possible that there will be more trustworthy, but less accessible servers, supported by a larger cluster of less authenticatable servers that are more widely available. In the worst case, if the client receives what appears to be unvalidated information, the client should assume that the hint may be inaccurate and confirmation of the data might be sought from more reliable but less accessible sources.
* サーバー認証：サーバーとクライアントは、通信するサーバーのIDを学習できる必要があります。これは程度の問題であり、より信頼性は高いがアクセス性の低いサーバーが存在する可能性があります。最悪の場合、クライアントが未検証の情報を受け取った場合、クライアントはヒントが不正確であり、信頼性は高いがアクセスしにくいソースからデータの確認を求める可能性があると想定する必要があります。
* SERVER DISTRIBUTION: Broad availability will provide resistance to denial of service. It is only to the extent that the services are available that they provide any degree of trustworthiness. In addition, the distribution of services will reduce vulnerability of the whole community, by reducing the trust put in any single server. This must be mitigated by the fact that to the extent trust is based on a linked set of servers, if any one fails, the whole chain of trust fails; the more elements there are in such a chain, the more vulnerable it may become.
* サーバーの分散：幅広い可用性により、サービス拒否への抵抗が提供されます。ある程度の信頼性を提供するのは、サービスが利用可能な範囲に限られます。さらに、サービスの配布により、単一のサーバーへの信頼が低下するため、コミュニティ全体の脆弱性が軽減されます。これは、信頼がリンクされたサーバーのセットに基づいているという事実によって緩和する必要があります。いずれかが失敗すると、信頼のチェーン全体が失敗します。このようなチェーンに含まれる要素が多いほど、脆弱になります。
Privacy can be a double-edged sword. For example, on one hand, an organization may consider it critically important that its competitors not be able to read its traffic. On the other hand, it may also consider it important to be able to monitor exactly what its employees are transmitting to and from whom, for a variety of reasons such as reducing the probability that its employees are giving or selling the company's secrets to verifying that employees are not using company resources for private endeavor. Thus, although there are likely to be needs for privacy and confidentiality, what they are, who controls them and how, and by what mechanisms vary widely enough that it is difficult to say anything concrete about them here.
プライバシーは両刃の剣にすることができます。たとえば、組織は、競合他社がトラフィックを読み取ることができないことが非常に重要であると考える場合があります。一方、従業員が会社の秘密を提供または販売する可能性を減らしてそのことを確認するなどのさまざまな理由から、従業員が誰に、そして誰から何を送信しているかを正確に監視できることが重要だと考える場合もあります。従業員は会社のリソースを私的な努力に使用していません。したがって、プライバシーと機密性の必要性がありそうですが、それらは何であり、誰がどのように、どのように制御し、どのメカニズムによって大きく異なるのかについて、ここで具体的に述べることは困難です。
The privacy of publishers is much easier to address. Since they are trying to publish something, in general privacy is probably not desired. However, publishers do have information that they might like to keep private: information about who their clients are, and information about what names exist in their namespace. The information about who their clients are may be difficult to collect depending on the implementation of the resolution system. For example, if the resolution information relating to a given publisher is widely replicated, the hits to _each_ replicated copy would need to be recorded. Of course, determining if a specific client is requesting a given name can be approached from the other direction, by watching the client as we saw above.
パブリッシャーのプライバシーに対処する方がはるかに簡単です。彼らは何かを公開しようとしているので、一般的にプライバシーはおそらく望ましくありません。ただし、パブリッシャーには、非公開にしたい情報、つまりクライアントが誰であるかに関する情報、および名前空間に存在する名前に関する情報があります。解決システムの実装によっては、クライアントが誰であるかに関する情報を収集するのが難しい場合があります。たとえば、特定の発行元に関連する解決情報が広く複製されている場合、複製された各コピーへのヒットを記録する必要があります。もちろん、特定のクライアントが特定の名前を要求しているかどうかを判断することは、上記のようにクライアントを監視することによって、反対方向からアプローチすることができます。
There are likely to be some publishers publishing for a restricted audience. To the extent they want to restrict access to a resource, that is the responsibility of the repository providing and restricting access to the resource. If they wish to keep the name and hints for a resource private, a public RDS may be inadequate for their needs. In general, it is intended for those who want customers to find their resources in an unconstrained fashion.
一部のサイト運営者は、制限された対象ユーザー向けに公開している可能性があります。リソースへのアクセスを制限したい場合は、リソースへのアクセスを提供および制限するリポジトリの責任です。リソースの名前とヒントを非公開にしたい場合、パブリックRDSは彼らのニーズには不十分な場合があります。一般的に、これは、顧客に制約のない方法でリソースを見つけてもらいたい人を対象としています。
The final privacy issue for publishers has to do with access control over URN resolution. This issue is dependent on the implementation of the publisher's authoritative (in the sense of "primary) URN resolver server. URN resolver servers can be designed to require proof of identity in order to be issued resolution information; if the client does not have permission to access the URN requested, the service denies that such a URN exists. An encrypted protocol can also be used so that both the request and the response are obscured. Encryption is possible in this case because the identity of the final recipient is known (i.e. the URN server). Thus, access control over URN resolution can and should be provided by resolver servers rather than an RDS.
パブリッシャーの最後のプライバシー問題は、URN解決に対するアクセス制御に関係しています。この問題は、パブリッシャーの権限のある（「プライマリ」という意味で）URNリゾルバーサーバーの実装に依存しています。URNリゾルバーサーバーは、発行された解決情報のためにIDの証明を要求するように設計できます。クライアントに許可がない場合要求されたURNにアクセスすると、サービスはそのようなURNが存在することを拒否します。暗号化されたプロトコルを使用して、要求と応答の両方を隠すこともできます。この場合、最終受信者のIDがわかっているため（つまり、したがって、URN解決に対するアクセス制御は、RDSではなくリゾルバサーバーによって提供できます。
With these assumptions and guidelines in mind, we conclude with a general framework within which RDS designs may fall. As stated earlier, although this framework is put forth as a suggested guide for RDS designers, compliance with it will in no way guarantee compliance with the guidelines. Such an evaluation must be performed separately. All such lack of compliance should be clearly documented.
これらの仮定とガイドラインを念頭に置いて、RDS設計が該当する可能性のある一般的なフレームワークで結論を出します。前述したように、このフレームワークはRDS設計者向けの推奨ガイドとして提示されていますが、これに準拠してもガイドラインへの準拠は保証されません。このような評価は個別に実行する必要があります。このようなコンプライアンスの欠如はすべて明確に文書化する必要があります。
The design of the framework is based on the syntax of a URN as documented in RFC-2141 [6]. This is:
フレームワークの設計は、RFC-2141 [6]で文書化されているURNの構文に基づいています。これは：
URN:<NID>:<NSS>
where URN: is a prefix on all URNs, NID is the namespace identifier, and NSS is the namespace specific string. The prefix identifies each URN as such. The NID determines the general syntax for all URNs within its namespace. The NSS is probably partitioned into a set of delegated and subdelegated namespaces, and this is possibly reflected in further syntax specifications. In more complex environments, each delegated namespace will be permitted to choose the syntax of the variable part of the namespace that has been delegated to it. In simpler namespaces, the syntax will be restricted completely by the parent namespace. For example, although the DNS does not meet all the requirements for URNs, it has a completely restricted syntax, such that any further structuring must be done only by adding further refinements to the left, maintaining the high order to low order, right to left structure. A delegated syntax might be one in which a host is named by the DNS, but to the right of that and separated by an "@" is a string whose internal ordering is defined by the file system on the host, which may be defined high order to low order, left to right. Of course, much more complex and nested syntaxes should be possible, especially given the need to grandfather namespaces. In order to resolve URNs, rules will be needed for two reasons. One is simply to canonicalize those namespaces that do not fall into a straightforward (probably right to left or left to right) ordering of the components of a URN, as determined by the delegated naming authorities involved. It is also possible that rules will be needed in order to derive from URNs the names of RDS servers to be used in stages.
ここで、URN：はすべてのURNのプレフィックス、NIDはネームスペース識別子、NSSはネームスペース固有の文字列です。プレフィックスは、各URNを識別します。 NIDは、その名前空間内のすべてのURNの一般的な構文を決定します。 NSSは、委任された名前空間とサブ委任された名前空間のセットに分割されている可能性があり、これはおそらく、さらなる構文仕様に反映されています。より複雑な環境では、委任された名前空間ごとに、委任された名前空間の可変部分の構文を選択できます。より単純な名前空間では、構文は親名前空間によって完全に制限されます。たとえば、DNSはURNのすべての要件を満たしていませんが、完全に制限された構文を持っているため、さらに構造化を行うには、左にさらに改良を加え、高次から低次、右から左に維持する必要があります。構造。委任された構文は、ホストがDNSによって名前が付けられている構文の場合がありますが、その右側にあり、「@」で区切られている文字列は、ホストのファイルシステムによって内部順序が定義されています。左から右の順に並べます。もちろん、特に名前空間を祖父にする必要がある場合、もっと複雑でネストされた構文も可能です。 URNを解決するには、2つの理由でルールが必要になります。 1つは、関与する委任された命名機関によって決定された、URNのコンポーネントの単純な順序（おそらく右から左または左から右）に該当しない名前空間を正規化することです。また、段階で使用するRDSサーバーの名前をURNから派生させるためにルールが必要になる場合もあります。
URN:<NID><NSS>
|
|
|
|
v
+-------------------+
|Global NID registry|
+-------------------+
|
|
|
(return rule or URN resolver service reference)
|
+----------------------------------+
| |
+->(apply rule to determine RDS server) |
| | |
| | |
| | |
| +----------+ |
| |RDS server| +-----------------+
| +----------+ |
| | | v
| | | (set of choices)
| | +----+----------(...)--------+
| (rule) | |
| | | |
| | | |
+------+ | |
v v
+----------+ +----------+
|URN | |URN |
|resolver | |resolver |
|service | |service |
+----------+ +----------+
Figure 1: An RDS framework
図1：RDSフレームワーク
The NID defines a top level syntax. This syntax will determine whether the NID alone or in conjunction with some extraction from the NSS (for the top level naming authority name) is to be used to identify the first level server to be contacted. At each stage of the lookup either a new rule for generating the strings used in yet another lookup (the strings being the identity of another RDS server and possibly a string to be resolved if it is different than the original URN) or a reference outside the RDS to a URN resolver service, sidestepping any further use of the RDS scheme. Figure 1 depicts this process.
NIDは最上位の構文を定義します。この構文は、NIDを単独で使用するか、NSSからの抽出（最上位の命名機関名の場合）と組み合わせて使用して、接続する最初のレベルのサーバーを識別するかを決定します。ルックアップの各段階で、さらに別のルックアップで使用される文字列を生成するための新しいルール（文字列は別のRDSサーバーのIDであり、元のURNと異なる場合は解決される文字列）または外部の参照RDSスキームのさらなる使用を回避して、URSリゾルバーサービスへのRDS。図1は、このプロセスを示しています。
There are several points worth noting about the RDS framework. First, it leaves open the determination of the protocols, data organization, distribution and replication needed to support a particular RDS scheme. Second, it leaves open the location of the computations engendered by the rules. Third, it leaves open the possibility that partitioning (distribution) of the RDS database need not be on the same boundaries as the name delegation. This may seem radical to some, but if the information is stored in balanced B-trees for example, the partitioning may not be along those naming authority delegation boundaries (see [7]). Lastly, it leaves open access to the Global NID Registry. Is this distributed to every client, or managed in widely distributed servers? It is important to note that it is the intention here that a single RDS scheme is likely to support names from many or all naming schemes, as embodied in their NIDs.
RDSフレームワークについては、注目に値する点がいくつかあります。まず、特定のRDSスキームをサポートするために必要なプロトコル、データ構成、配布、およびレプリケーションの決定は未解決のままです。第二に、それはルールによって生じた計算の場所を開いたままにしておきます。第3に、RDSデータベースのパーティション化（配布）が名前の委任と同じ境界上にある必要がない可能性を残します。これは一部の人には過激に思えるかもしれませんが、たとえば情報がバランスのとれたBツリーに格納されている場合、パーティションはそれらの命名機関の委任境界に沿っていない可能性があります（[7]を参照）。最後に、グローバルNIDレジストリへのオープンアクセスを残します。これはすべてのクライアントに配布されますか、それとも広く分散したサーバーで管理されますか？ここでは、1つのRDSスキームが、NIDで具体化されているように、多くのまたはすべての命名スキームからの名前をサポートする可能性が高いことが意図されていることに注意することが重要です。
One concept that has not been addressed in Figure 1 is that there may be more than one RDS available at any given time, in order to allow for evolution to new schemes. Thus, the picture should probably look more like Figure 2.
図1で取り上げられていない概念の1つは、新しいスキームへの進化を可能にするために、任意の時点で複数のRDSを使用できる可能性があることです。したがって、図はおそらく図2のようになります。
URN:<NID>:<NSS>
|
|
+-----------+-------(...)-------+
| |
| |
| |
v v
+---------------------+ +---------------------+
|Global NID registry 1| |Global NID registry N|
+---------------------+ +---------------------+
. .
. .
. .
Figure 2: More than one co-existing RDS scheme
図2：複数の共存RDSスキーム
If we are to support more than one co-existing RDS scheme, there will need to be coordination among them with respect to storage and propagation of information and modifications. The issue is that generally it should be assumed that all information should be available through any operational RDS scheme. One cannot expect potential publishers to submit updates to more than one RDS scheme. Hence there will need to be a straightforward mapping of information from one to the other of these schemes. It is possible that that transformation will only go in one direction, because a newer RDS service is replacing an older one, which is not kept up to date, in order to encourage transfer to the newer one. Thus, at some point, updates may be made only to the newer one and not be made available to the older one, as is often done with library catalogs.
複数の共存するRDSスキームをサポートする場合は、情報の保存と伝達、および変更に関して、それらの間で調整を行う必要があります。問題は、一般的に、すべての情報が運用RDSスキームを通じて利用可能であると想定されていることです。潜在的な発行元が複数のRDSスキームに更新を送信することを期待することはできません。したがって、これらのスキームの一方から他方への情報の簡単なマッピングが必要になります。新しいRDSサービスが新しいものへの移行を促進するために、最新ではない古いRDSサービスを置き換えているため、その変換は一方向のみに進む可能性があります。したがって、ある時点で、ライブラリカタログでよく行われるように、更新は新しいものだけに行われ、古いものには利用できない場合があります。
This framework is presented in order to suggest to RDS scheme designers a direction in which to start designing. It should be obvious to the reader that adherence to this framework will in no way guarantee compliance with the guidelines or even the assumptions described in Sections 2 and 3. These must be reviewed independently as part of the design process. There is no single correct design that will conform to these guidelines. Furthermore, it is assumed that preliminary proposals may not meet all the guidelines, but should be expected to itemized and justify any lack of compliance.
このフレームワークは、RDSスキームの設計者に設計を開始する方向を提案するために提示されています。このフレームワークを順守しても、ガイドラインへの準拠、またはセクション2と3で説明されている前提条件を保証することは決してないことは読者に明らかです。これらは、設計プロセスの一部として個別にレビューする必要があります。これらのガイドラインに適合する単一の正しい設計はありません。さらに、予備的な提案はすべてのガイドラインに適合しない可能性があると想定されますが、項目化され、コンプライアンスの欠如を正当化することが期待されます。
Foremost acknowledgment for this document goes to Lewis Girod, as my co-author on a preliminary URN requirements document and for his insightful comments on this version of the document. Thanks also go to Ron Daniel especially for his many comments on my writing. In addition, I recognize the contributors to a previous URN framework document, the "Knoxville" group. There are too many of you to acknowledge here individually, but thank you. Finally, I must thank the contributors to the URN working group and mailing list (urn-ietf@bunyip.com), for your animated discussions on these and related topics.
このドキュメントの最も重要な謝辞は、暫定的なURN要件ドキュメントの共著者として、およびこのバージョンのドキュメントに関する洞察に満ちたコメントについて、ルイスギロドに寄せられます。特に私の執筆についての彼の多くのコメントについてロンダニエルにも感謝します。さらに、以前のURNフレームワークドキュメントである「ノックスビル」グループへの貢献者を認識しています。こちらは個別にご了承いただける方が多すぎますが、よろしくお願いします。最後に、URNワーキンググループとメーリングリスト（urn-ietf@bunyip.com）への貢献者に、これらのトピックと関連トピックについてのアニメーションによるディスカッションに感謝します。
[1] Kunze, J., "Functional Recommendations for Internet Resource Locators", RFC 1736, February 1995.
[1] Kunze、J。、「Internet Resource Locatorsの機能上の推奨事項」、RFC 1736、1995年2月。
[2] Sollins, K., and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1738, December 1994.
[2] Sollins、K。、およびL. Masinter、「Functional Requirements for Uniform Resource Names」、RFC 1738、1994年12月。
[3] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[3] Berners-Lee、T.、Masinter、L。、およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[4] URN Working Group, "Namespace Identifier Requirements for URN Services," Work in Progress.
[4] URNワーキンググループ、「URNサービスの名前空間識別子の要件」、進行中の作業。
[5] Voydock, V. L., and Kent, S. T., "Security Mechanisms in High-Level Protocols", ACM Computing Surveys, v. 15, No. 2, June, 1983, pp. 135-171.
[5] Voydock、V。L.、およびKent、S。T.、「高レベルプロトコルのセキュリティメカニズム」、ACM Computing Surveys、v。15、No。2、1983年6月、pp。135-171。
[6] Moats, R., "URN Syntax", RFC 2141, May 1997.
[6] Moats、R。、「URN構文」、RFC 2141、1997年5月。
[7] Slottow, E.G., "Engineering a Global Resolution Service," MIT-LCS-TR712, June, 1997. Currently available as <http://ana.lcs.mit.edu/anaweb/ps-papers/tr-712.ps> or <http://ana.lcs.mit.edu/anaweb/pdf-papers/tr712.pdf>.
[7] Slottow、EG、「Engineering a Global Resolution Service」、MIT-LCS-TR712、1997年6月。現在<http://ana.lcs.mit.edu/anaweb/ps-papers/tr-712.ps>として入手可能または<http://ana.lcs.mit.edu/anaweb/pdf-papers/tr712.pdf>。
Karen Sollins MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
カレンソリンズMITコンピュータサイエンス研究所545テクノロジースクエアケンブリッジ、MA 02139
Phone: +1 617 253 6006
EMail: sollins@lcs.mit.edu
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。