RFC2276 日本語訳
2276 Architectural Principles of Uniform Resource Name Resolution. K.Sollins. January 1998. (Format: TXT=64811 bytes) (Updated by RFC3401) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Sollins Request for Comments: 2276 MIT/LCS Category: Informational January 1998
Sollinsがコメントのために要求するワーキンググループK.をネットワークでつないでください: 2276 MIT/LCSカテゴリ: 情報の1998年1月
Architectural Principles of Uniform Resource Name Resolution
一定のリソース名前解決の建築プリンシプルズ
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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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.
このドキュメントは順番に直接URL(Uniform Resource Locator)とURCs(一定のResource Characteristics)にURNsを翻訳するURN(一定のResource Name)レゾルバサービスの発見の問題を記述します。 ドキュメントは、実行可能なResolverディスカバリーServiceかRDSと、RDSsを設計するための枠組みになるように3つの大半、仕事、ガイドラインの基礎となる仮定に落ちます。 ガイドラインは3つの原則領域に落ちます: evolvability、ユーザビリティ、セキュリティ、およびプライバシー。 枠組みで言いなりになっている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
1. 序論…2 2. 仮定…5 3. ガイドライン…7 3.1発展…7 3.2ユーザビリティ…10 3.2 .1 出版社…11 3.2 .2 クライアント…12 3.2 .3 管理…13 3.3のセキュリティとプライバシー…14 4. 枠組み…18 5. 承認…23 6. 参照…23 7. 作者のアドレス…23 8. 完全な著作権宣言文…24
Sollins Informational [Page 1] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[1ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
1. Introduction
1. 序論
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.
このドキュメントの目的は私たちがここにResolverディスカバリーService(RDS)を呼ぶつもりであることの工学評価基準を広げることです、URN(一定のResource Name)レゾルバに関して学習で助けるサービス。 「レゾルバ」という用語は、URL(Uniform Resource Locator)かURCs(一定のResource Characteristics)にURNsを翻訳するサービスを示すのに本書では使用されます。 また、リソースに直接アクセスを提供するレゾルバもあるかもしれません。 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.
Uniform Resource Identifier作業部会は命名構造を定義しました、一連の3RFCs1736[1]、1737[2]、および1738[3]に示されるように。 さらなるいくつかのドキュメントがその構造の記述を終了するのに必要ですが、しばしば「命名」に関連している3つのコア機能を取り入れます: 識別か、位置と、ニーモニックか意味論。 位置のそばでは、私たちが完全に適切なDomain NamesかことによるとTCPポート、そして/または、ローカルの識別子で広げられたIPアドレスを言っています、パス名などのように。 名前は別のものとそれらの「名前」を区別することによって1つのリソースを区別する能力を提供するかもしれません。 名前は、「位置」情報を含んでいることによってリソースへのアクセスを提供するのを助けるかもしれません。 さらに、名前には、どちらかが人間のユーザが名前を覚えているか、または理解するのを助けるか、または命名されるリソースに関する他の意味情報を含んでいるという他の意味的であるか簡略記憶の情報があるかもしれません。 URIワーキンググループは、しつこくて、グローバルにユニークな識別子の必要があったと結論を下しました、位置か他の意味情報と、異なります。 これらはURNsと呼ばれました。 これらの「名前」はアイデンティティを提供します、それらの2つが「同じである」なら(canonicalizationの何らかの簡単な規則の下における)、同じリソースを特定するので。 その上、グループは、これらの「名前」が一般に、人間、消費よりむしろマシンのためにあることであると決めました。 最終的に、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
URNsと対照して、人は、バラエティーがアプリケーションの異なった一組を支える人間に優しい命名(HFN)計画とユーザーコミュニティであると想像できます。 名前空間によって、これらは、よりきついか、よりゆるいカップリングのURNsにマッピングを供給する必要があるでしょう。 使用中の変化と意味論を追うために簡略記憶で、内容完全で、恐らく無常であることは、これらのHFNsです。 彼らは愛称で呼んで他で提供するかもしれません。
Sollins Informational [Page 2] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[2ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
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.
エイリアシング、相対的であるか短い名前、文脈の敏感な名、描写的である名前など 彼らの定義は、この努力の一部ではありませんが、結局、明確に重要な役割を果たすでしょう。
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.
RFC1737で説明されるURNsはグローバルに定義されます。 どんな文脈でもどこでもURNが同じリソースを特定するので、それらは遍在しています。 URNsに関するこの要件を考えて、RDSのために含意に関して尋ねなければなりません。 偏在はいたる所でRDS解決の保証を含意しますか? 偏在はいたる所で解決の同じ情報に解決を含意しますか? どちらの場合も、答えはたぶんそうしていません。 1つは理由を超えた費用以外に、グローバルで、システムの保証をすることができません。 同様に、さらに、決議でない技術的な理由と同様に方針がいたる所にあるかもしれません。 リソースの例への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共同体が、より良い用語の不足によって、私たちが、_ヒントを_と呼ぶつもりであるという頻繁に使用される概念です。ヒントはURNの解決で役に立つ何かです。 理論上、私たちは当座のステージとしてリソースにアクセスする際にURNsをヒントに写像します。 実際には、選ぶなら、RDSは直接リソース自体にURNを写像するかもしれません。 URNsの大きいセットに適切なヒントが例えば非常にありそうでしょう、特定のレゾルバが、ある接頭語か接尾語があるすべてのURNsを決議できるのを示すヒント。また、ヒントには、それに関連しているメタ情報があるかもしれません、信憑性の満了時間や証明のように。 私たちは、これらがほかの場所で管理されるよりヒントでむしろ滞在すると予想します。 私たちは、ヒントのすべてのさらなる議論でそれらがヒント情報自体と同様にどんな必要なメタ情報も含んでいると思うつもりです。 ヒントに関する例は以下の通りです。 1) さらにURN、2を決議するかもしれないレゾルバサービスのURN) そのようなサービスのアドレス、3) リソースが以前に見つけられた位置。 ヒントの定義の特徴はそれらがヒントにすぎないということです。 それらは、時代遅れであるか、一時無効であるか、または特定の場所の中で適切であるだけであるかもしれません。 アクセスの保証を提供しませんが、彼らはたぶん解決の過程で助けるでしょう。 利用可能であることを意味することなら何でも、1セットのヒントは発見されます。 ソフトウェアと人間の選択の何らかの組み合わせが、どのヒントが何で注文されてみるかを決定するでしょう。
Sollins Informational [Page 3] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[3ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
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.
私たちは、URNsのほとんどの解決が局所的に格納されたヒントの使用で提供されると思わなければなりません、グローバルに利用可能で、完全に最新の位置情報に関するデータベースを維持するのが性能理由で実行不可能であるので。 多くの事情がどれが、ヒントが無効になると想像できるかであります、リソースが動いたか、または異なった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.
* URNsはしつこいです。 * 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:
次のセクションは3の主要な原則ResolverディスカバリーServiceデザインを広げます。 それぞれのこれらに関しては、私たちはさらに一般的な原則を定義して、洗練する多くの、より特定のガイドラインを特定しました。 このセクションはたぶんドキュメントに最も批判的です、それが適切であるかどうか学ぶためにこれらの原則と推論ガイドラインに対してどんな提案された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.
1) RDSは発展とevolvabilityを考慮しなければなりません。 2) それぞれの識別と位置にかかわる成分かリソースのセットに関するRDSのユーザビリティは最高のです。 3) 中心では、すべての成分のセキュリティとプライバシーの必要性が実行できるように可能な程度に支持されるのは、重要です。
Each of the three major subsections of the guidelines section begins with a summary list of the more detailed guidelines identified in
中に特定されたより詳細なガイドラインの概要リストがある状態で、それぞれのガイドライン部の3つの主要な小区分が始まります。
Sollins Informational [Page 4] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[4ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
that section.
そのセクション。
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.
ドキュメントの最後のセクションはそのようなRDSsのために枠組みを広げます。 最後のセクションがあるこの目的はRDS計画で検索スペースを縛りました。 RDSデザイナーはガイドラインを満たすのが第一に重要であることを意識しているべきです。 枠組みに従わないでそれらに会うのは可能です。 枠組みの中の設計がこの最後のセクションで、より詳しく議論するようにコンプライアンスを保証しないので、また、承諾評価は計画の評価の過程の一部であるに違いありません。
2. Assumptions
2. 仮定
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 BOFsと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が「しつこい識別子」であることになっていると述べます。 何もいつまでも続かないのが、たぶん事実ですが、リソースの時間枠、それらのリソースのユーザ、およびリソースを支持するシステムでは、しつこいか、または識別子にはそれらの他の実体より長い寿命があると考えられるべきです。 URNsの寿命によって含意される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を考えて、リソースを発見する仕事。 どちらの場合も、私たちはマルチtieredされた代表団を予想します。 これらの2セットの責任と代表団関係を合併するRDS計画があるかもしれません。 そうすることによって、彼らは2つの明瞭に異なった活動を一緒にくくるか、または積みすぎて、その結果、たぶん成長を妨害します。
Sollins Informational [Page 5] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[5ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
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番目の仮定が別のものからの1つの権威の独立か孤立である、少なくともある程度、親から。 権利と別の権威への責任、「反-遺産受取人」がいくらか同輩の如何にかかわらず領域の中のそのドメインで手術できる1人の権威代表が「反-遺贈者」の如何にかかわらず代表団で指定したとき。 この孤立は、方針とメカニズムからの独立を考慮するために批判的に重要です。
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つか小さいセットがありそうですが、数は過渡期の間1つの構造から別のものに増加しそうです。 したがって、クライアントがたぶん非常に小さいRDSsの中で選択をすることができると思わなければなりません。 3番目に、セキュリティのレベルとモデルに関する選択には独立があるに違いありません、そして、信憑性が必要です。 この選択は命名部分空間の所有者によってされるかもしれません、だれがその部分空間におけるヒントを変更できるかを制御する際に。 命名権威はそれが割り当てた名前によって指定されたリソースの所有者へこの選択を代表として派遣するかもしれません。 制限が、全体でRDSインフラストラクチャの保全を維持するために例えば、他の関係者には彼らが必要とするセキュリティと信憑性のレベルがあるのを許容するためにこの選択の自由にあるかもしれません。 4番目に、親名前空間によって設定されたどんな制限や規制でも制限された名前空間の中にURNsのcanonicalizationの規則の選択からの独立の仮定があります。 これはそれら自身のの当局を「副-名前空間」に任命しながら固守された選択です。 下の枠組みの部で、より詳しくcanonicalizationのための規則について議論するでしょう。 したがって、さまざまなドメインで代表として派遣されて、独立している権威を考慮するために、独立と孤立の仮定があります。
Sollins Informational [Page 6] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[6ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
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.
代表団と孤立のモジュール方式仮定は決定と実現からの独立を含意します、サービスの否定からある度の安全を提供する分散に通じて。 これらに基づいたRFCs1736と1737年に詳述するURLとURNsのための寿命とそれらのものに関連したこれらの仮定であり、私たちは今、RDSのためのガイドラインに変わることができます。
3. Guidelines
3. ガイドライン
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に適用されるガイドラインはevolvability、ユーザビリティ、セキュリティ、およびプライバシーの領域のおよそ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システムは名前空間における名前、それらのための解決情報、および名前空間における名前から解決情報までのマッピング(または、ヒント)から成るでしょう。 URNs自身はRFC1737に関する必要条件を満たさなければなりません。 さらに、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.
ポイントの概要がそのセクションで作られている状態で、下の各セクションは始まります。 領域の中にオーバラップがいくらかのあります、セキュリティー対策などの発展を考慮するのなどように、そして、したがって、問題は1つ以上のセクションで記述されるかもしれません。 また、ガイドラインがある順応がしばしば主観的になると認めるのも重要です。 したがって、順応が多くのIETFガイドラインと要件で、これらの多くが定量化可能でなく、審判の判定と程度の問題であるので。 最後に、読者は、それらのいくつかが分散システムへの一般的な適用性のものであることがわかるかもしれません、そして、或るものはURN解決に特定です。 一般的な適用性のものは、完全性のために含まれていて、そういうものとして区別されません。
3.1 Evolution
3.1 発展
The issues in the area of the first principle, that of evolvability, are:
原則の領域の問題(evolvabilityのもの)は以下の通りです。
Sollins Informational [Page 7] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[7ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
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.
1.1) RDSは、少なくとも三次元を計量するのを支持できなければなりません: URNsが必要であるリソースの数、それらのリソースの出版社とユーザの数、および解決のための権威としての代表団の複雑さは、成長して、ことによると権威を命名するのに代表団を反映します。 1.2) ヒント解決環境は特に以下のためにメカニズムの発展を支持しなければなりません。 * URNの増加しているセットは計画されます。 * 新しい種類の地方のURNレゾルバサービス。 * 新しい認証は計画されます。 * 同時にアクティブな代替のRDS計画。 1.3) RDSは運営管理コントロールメカニズムの開発と展開に限りある資源に関して人間挙動を管理させなければなりません。
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.
私たちがURNsを決議するためにメカニズムの開発に取り入れなければならないインターネットのレッスンの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.
まず最初に、スケーリングは発展に関連した第一の問題です。 少なくとも人間の、そして、電子の両方のリソースの数が、短期間指数関数的に成長し続けるのと同じくらい健康なユーザの数。 したがって、また、URNsの数は同様に増加するでしょう。 さらに、全くの数における成長と共に、権威を命名して、解決権威の両方の代表団での成長はおそらく来ていることになっています。 これらの事実は、サーバが恐らく相互関係づけたRDSの1セットで、より複雑な方法で包含、アップデート、および解決を求める増加する数の要求を扱うようにRDSデザインを準備しなければならないことを意味します。 これは1URNあたりの、より多くのアップデートか解決が必ずあると言わないためのものです。 私たちはこのとき、それを予測できません。 たとえそうだとしても、しかし、インフラストラクチャは代表団のために、より複雑になるかもしれません。(代表団は上演された解決のための用語を書き直すか、または取りつけるための、より複雑な規則に通じるかもしれません(枠組みのセクション4で見ることができるように))。 どんなデザインも何らかのセットの限界を超えてそれほどよくない働きそうにないので、成長がそれぞれのデザイン選択肢の制限であると考える価値があります。
Sollins Informational [Page 8] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[8ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
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.
2番目に、私たちは、そこでメカニズムへの追加と変化であると予想します。共同体は、新しいURN計画のための容量があるに違いないのを既に理解します、[4]で説明されるように。 URN計画は、URN必要条件[2]を満たすURNsの1セットを定義しますが、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計画の如何にかかわらず計画してください、そして、新しい種類のレゾルバサービスは発展してもよいです。 例えば、人はそれらのISBNsを考えて、ドキュメントを見つける効率を高めるISBNsの特定の構造に基づく専門化しているレゾルバサービスを想像できます。 あるいはまた、また、人は、一般的な目的が一般性のために性能を交えるレゾルバサービスであると想像できます。 ISBNsを決議しながら、平均した性能だけを示しますが、すべての既存のURN計画を理解していることによって、この弱点の埋め合わせをします、クライアントが命名にかかわらずURNsが計画すると決議するのに同じサービスを利用できるように。 このような関係においては、向上した性能によるサービスの改善の余地、例えば新しいURN計画、または低い費用への、より良い適応性がいつもあるでしょう。 URN解決のための新しいモデルは発展するでしょう、そして、私たちはURNsの総合的な解決への彼らの参加を考慮する用意ができていなければなりません。
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つが決してないかもしれません。 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モデルが信頼できる情報を挿入して、変更することの明らかに集結された(方針見地から)計画を支持するなら、それには、私たちが異なったモデル、恐らく1つに発展する用意ができていなければならない時間の上間、権威と信憑性の、より分配されたモデルがあります。 モデルがコアを全く持っていなくて、むしろ情報のどっと落している部分的な発見を持っているなら、私たちは、これがスケーリングの増加で「非-処理しやす」になるのがわかったかもしれません。 モデルが何であっても、私たちはスケーリング、性能、および方針規制における、セキュリティや費用などの変化に従ってそれを発展する用意ができていなければなりません。
Sollins Informational [Page 9] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[9ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
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つの提案が、値を付けて管理です。 また、技術が変化して、どのリソースが不足するかに関する残額が変化するのに従って、彼らの使用を制御するためのメカニズムと方針は発展しなければなりません。
3.2 Usability
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.1) 出版社2.1.1) 解決について暗示するURNは非常に高い確率のために正しくて、効率的であるに違いありません。 2.1.2) 出版社は、それらのリソースの場所を見つけるようにURNレゾルバサービスの中を選択して、動くことができなければなりません。 2.1.3) 出版社はそれらの位置情報のために複数のアクセスポイントを準備できなければなりません。 2.1.4) 出版社は異なった生涯をヒントに提供できるべきです。 2.1.5) 出版社が彼らが自分達のヒントに必要とするどんなセキュリティ規制と同様に管理に指定して、それらのヒント情報を観測するのは、比較的簡単でなければなりません。 2.2) クライアント2.2.1) RDSへのインタフェースは、簡単で、有効で、効率的であるに違いありません。 2.2.2) クライアントとクライアントアプリケーションは、RDSで容易に格納された情報を理解して、提供できなければなりません、インフォームド・チョイスをすることができるように。 2.3) 管理2.3.1) あまりに多くのネットワーク資源を使用するのを避けて、ヒントの管理はできるだけ控え目でなければなりません。
Sollins Informational [Page 10] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[10ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
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つの見解からのユーザビリティ問題を記述するつもりです。 これらが何人かの関係者(exampel a使用と出版社のための)の関心が闘争中であるかもしれないsitautionsであるかもしれないと認めるのは重要です。 何らかの解決が必要でしょう。
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.
追加2種類の全体の命名の過程の関係者がいることに注意する価値があります、URN WGで議論するように。 彼らは命名当局です(名前、および彼らのリソースにURNsを含んでいる作者を、選んで、選任します)。 これらの2について、RDSのデザインに関連していなくて、またしたがって、ここでさらに議論しません。
3.2.1 The Publisher
3.2.1 出版社
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.
出版社は見込み客にURNsを明らかにすることができなければなりません。 第一の重要性では、URNsは正しいのと効率的に出版社の見解からの、そうです。可能なクライアントは非常に高い確率で溶解性です。 出版社は長命のURNsから得します、彼らが参照が、それらの発行されたリソースを示し続けているという可能性を高めるので。
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.
また、出版社はURNsを位置情報に翻訳するかもしれないさまざまな潜在的サービスの中で容易に選ぶことができなければなりません。 レゾルバの中でこの移動性を考慮するために、RDS構造は方針コントロール領域の中でそのような変遷を支持しなければなりません。 マルチプル・リスティングサービスが電話帳で利用可能ですが、一般に、それらが料金によって伴われることに注意する価値があります。 同様の種類のサービスのためにURNsに関して集められた料金であるそこで防いでいるものは何もありません。
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
出版社は発行されたリソースに複数のアクセスポイントを準備できなければなりません。 これが役に立つように、レゾルバサービスは異なった解決かヒント情報を異なったクライアントに提供するように準備されるべきです、位置とクライアントが持っているかもしれない様々なアクセス権を含むさまざまな情報に基づいて。 これにはこの情報をキャッシュするための重大な意味があるかもしれないことに注意するのは重要です。 例えば、会社は準備するかもしれません。
Sollins Informational [Page 11] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[11ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
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.
出版社は長いものとリソースにアクセスすることに関する同様に短い用語位置情報を提供できるべきです。 長期情報は出版社には長期関係があるレゾルバサービスのリソース自体の長期アドレス、位置またはアイデンティティのように情報である傾向があります。 人は、そのような長期の「正式」のレゾルバサービスによるアレンジメントが信頼性の保証と、失敗への弾性と、原子アップデートであるかもしれないと想像できます。 より短い用語情報は、サービスにおける短い用語変化か短い送られた混雑か失敗問題を避けるために役に立ちます。例えば、リソースの実際の倉庫が一時近づきがたいなら、リソースを別の倉庫から利用可能にするかもしれません。 この短期間情報は、情報というより長い期間の一時的な気品として見なすことができて、そういうものとしてより簡単にすぐに利用可能に作られているべきですが、それほど信頼できないかもしれません。 いくつかの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メカニズムの細部を理解しないという事実にもかかわらず、彼らがヒント情報をインストールするのは、簡単であって、簡単であるに違いありません。 これは、一般に、発行することを願って、解決の特権があったいずれも代表団を通して広げられて、そうできることを意味します。 出版社は、単にヒントを言い表すのではなく、マネージャによって勤められていることが正しいことを確かめもすることができなければなりません。 その上、出版社は、それらを言い表して、セキュリティ規制がヒント情報にあるという範囲に、容易にそれらへのコンプライアンスについて確かめることができなければなりません。
3.2.2 The Client
3.2.2 クライアント
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
その上、クライアントに代わったクライアントとアプリケーションの両方がヒントを解釈して、次にインフォームド・チョイスをすることができるように簡単な標準インターフェースをRDSに築き上げることができるのは重要でしょう。 恐らくクライアント
Sollins Informational [Page 12] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[12ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
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
アプリケーションの支援は、好みとプライオリティを指定して、次に、それらを適用できなければなりません。 ヒントの注文が部分的であるだけであるなら、クライアントは直接なるかもしれません。
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.
クライアントの見解から、URNsは重要な機能性を提供するでしょうが、クライアントは単に直接人間の好意的な名前(HFNs)で最も相互作用しそうです。 ダイレクト人間の交流(どんなコンピュータも調停されなかった)のように、名前の共有が小さいか、個人的であるか、ドメイン特有のスケールにあるでしょう。 HFNsは覚えていて、タイプして、選ぶ簡単な名前、参照の種類と案配になるでしょうなど。 また、そこでは、HFNsをURNsに写像するための多くのメカニズムであることが必要でしょう。 「職業別広告欄」や「検索ツール」のようなサービスはこのカテゴリになります。 私たちはHFNsについてここに言及していますが、HFNsからURNsまでそのHFNsとマッピングを認識するのがあって、RDSから別々の機能性のままで残らなければならないのは、重要です。 したがって、HFNsはクライアントにとって重要になるでしょうが、彼らはこのドキュメントのドメインに落ちません。
3.2.3 The Management
3.2.3 管理
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
2番目に、ヒント管理を可能にするように、そこでは、値を付けているか法的な制限などの管理誘因と行動を妨げるもののシステムであることが必要であるかもしれません。 システムを動かす費用を取り戻すのが、料金を徴収する1つの理由にすぎません。 支払いの導入はしばしば社会的な振舞いに影響を与えます。 制御しきれないときに共同体全体に深刻な悪影響を持っている振舞いのあるフォームに水をさしているのが必要であるかもしれません。 同時に、どんな施政方針も利益を得る振舞いを奨励するべきです。
Sollins Informational [Page 13] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[13ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
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回の料金はヒントの保守的な使用を奨励するかもしれません。 私たちが、ヒントを管理するための固定費があると思えばURNスペース中の適用性が広いほど、それは、より費用効率がよいです。 すなわち、1つのヒントがURNsの全体の収集を満たすことができるとき、多くの、より特定のヒントの上の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.
最後に、出版社にユーザビリティの問題に左右対称であることで、簡単でなければなりません、また、経営者側がURNsに関するマッピングをヒントに構成するのも、簡単にしてください。 ともに構成を理解しているのが簡単であるに違いなく、その構成について確かめるのは正しいです。 管理に関して、この問題は情報自体に持つだけではなく、それが協力して経営指導を提供するネットワークサーバかRDSの中でどうまた仕切られるかに影響力を持っているかもしれません。 例えば、サーバを持って来て、それが管理しているデータが正しいことを確かめるのは簡単であるべきです。 これはガイドラインではありませんが、それはボランティア関係者を奨励して、私たちがグローバルでたぶん増加しているサービスについて議論しているのでそのようなボランティアがDNSなら彼らが提供しているサービス、両方自体への利益、および共同体の残りに関して自信があるように感じることができるのを示さない何でも価値があります。
3.3 Security and Privacy
3.3 セキュリティとプライバシー
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.1) アクセスから変更への特権が制御されている状態でヒントの正式のバージョンを作成するのは可能であるに違いありません。 3.2) サーバのアイデンティティを決定するか、または非認証されたサーバとの接触を避けるのが可能であるに違いありません。 3.3) サーバの向こう側の広い情報の流通でサービスの否定の脅威を抑えるのは可能であるに違いありません。 3.4) 少なくとも何らかの度のプライバシーを交通に提供するのは組織的な方針評価基準の領域の中で可能であるに違いありません。
Sollins Informational [Page 14] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[14ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
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) 出版社がそれらが発表するリソースのためにURNsの解決へのアクセスを制限できるのは、可能であるに違いありません、彼らが願うなら。
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つは緩和のために考えられる脅威の列挙です。 見返りはしばしばお金とコンピュータの費用とコミュニケーションリソースを含んでいます、使いやすさ、使用の見込み、そして、メカニズムの有効性は提案しました。 これが念頭にある状態で、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とケント[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
混乱を避けるために、他の文脈での異なった意味を持っている用語の意味を強調するのは貴重です。 この場合、それがここで使用されているとき、「正式である」という用語は承認のそのような行為を実行する権利を持っている元本(再びセキュリティ意味における)による動作か検印の取りを内包します。 それには、情報の正当性の含意がない、しかし、恐らくだけだれが、それが正しいと主張したかに関する意味があります。 対照的に、また、存在という用語は単に、以前は、しばしばよくまた、利用可能な二次の、または、キャッシュされたコピーがあるかもしれない第一のコピーの1つの情報を示していました。 セキュリティのこの議論では、私たちは前の意味を使用します、また、それも学ぶことができるように重要であるかもしれませんが
Sollins Informational [Page 15] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[15ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
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番目の意味は、ドキュメントのほかの場所に起こって、そこに非常に述べられます。
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つの領域があります。 まず最初に、例えばアクセスがそれに読み込まれるか否かに関係なく、ヒントで扱われているアクセスコントロールの種類の問題があるか、アクセスを読んで、変更するか、または信憑性のための検証で読んでください。 2番目に、アクセスが何に制御されるかに関する質問があります。 中では、それを命名することの文脈は、名前(URNsのためのケースでない)自体、ヒント(RDSのビジネス)へのURNsに関するマッピング、アドレス(プライバシーに関する議論された下のRDSのビジネスでない)へのURNsに関するマッピング、またはリソース自体であるかもしれません(全く命名か名前解決に関係ない)。 私たちは、「アクセスコントロール」を使用するとき、何が意味されるかに関して明確であることを試みます。
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冊、区別があります。 一般に、方針は1セットのメカニズムによって実現されます。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
URN解決への最初のアプローチは地方のヒントを発見することです。 ヒントが局所的に発見されるために、それらは、広くあらゆる現場において地方であると考えられることに可能な状態で分配されているとしてある必要があるでしょう。 そのような広範な分布の欠点はアップデートの広範な分布です、アップデートを提供する問題か遅れをネットワークトラフィックに引き起こして。 代替のモデルはサーバのヒント情報を集結して、その結果、アップデート情報がこれらのサーバに分配されるだけであるのが必要にするでしょう。 そのようなモデルでは、損傷を受けやすい箇所は、情報の源と彼らの中の流通機構です。 サーバで保存された情報の保全の攻撃者は所有者のふりをするフォームか情報のサーバに入るかもしれません。 情報の広い模写
Sollins Informational [Page 16] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[16ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
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:
サーバの中では、情報のすべての位置で仮装して、否定サービスの脅威を抑える難しさは増加しています。 これらは私たちの機密保護モデルのために私たちを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.
* サーバの信憑性: サーバとクライアントはそれらが交信するサーバのアイデンティティを学ぶことができなければなりません。 これは程度の問題になるでしょう、そして、より少ないより広く利用可能な認証可能サーバの、より大きいクラスタによってサポートされたより信頼できますが、それほどアクセスしやすくないサーバがあるのは、可能です。 最悪の場合には、クライアントが非有効にされた情報であるように見えるものを受けるなら、クライアントは、ヒントが不正確であるかもしれないと仮定するべきです、そして、データの確認は、より信頼できますが、それほど理解できないソースから求められるかもしれません。
* 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.
* サーバ分配: 広い有用性はサービスの否定への抵抗を提供するでしょう。 それらがどんな度合いの信頼できることも提供するのは、サービスが利用可能であるという範囲だけへのそうです。 さらに、サービスの分配は共同体全体の脆弱性を減少させるでしょう、どんなただ一つのサーバにも入れられた信頼を減少させることによって。いくらか1つが失敗するなら、信頼が繋がっているセットのサーバに基づいているという範囲まで、信頼の全体のチェーンが行き詰まるという事実でこれを緩和しなければなりません。 そのようなチェーンにそこの、より多くの要素があればあるほど、それは、より被害を受け易くなるかもしれません。
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
出版社のプライバシーははるかに扱いやすいです。 彼らが何かを発行しようとしているので、一般に、プライバシーはたぶん望まれていません。 しかしながら、出版社には、彼らが、個人的にままであることが好きであるかもしれないという情報があります: 彼らのクライアントがだれであるかの情報、およびどんな名前がそれらの名前空間で存在するかの情報。 The
Sollins Informational [Page 17] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[17ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
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レゾルバサーバは解決情報を発行するために身元の証拠を必要とするように設計される場合がある」意味で。 クライアントがURNが要求したアクセスに許可を持っていないなら、サービスは、そのようなURNが存在することを否定します。 また、暗号化されたプロトコルを使用できるので、要求と応答の両方があいまいにされます。 最終的な受取人のアイデンティティが知られているので(すなわち、URNサーバ)、暗号化はこの場合可能です。 したがって、URN解決のアクセスコントロールを提供できて、RDSよりむしろレゾルバサーバは提供するべきです。
4. The Framework
4. フレームワーク
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>
つぼ: <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
どこURN: 接頭語がすべてのURNsにあります、そして、NIDは名前空間識別子です、そして、NSSは名前空間の特定のストリングです。 接頭語はそういうものの各URNを特定します。 NIDはすべてのURNsのために名前空間の中で一般的な構文を決定します。 NSSはたぶんaに設定していた状態で仕切られます。
Sollins Informational [Page 18] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[18ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
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.
代表として派遣されて、副代表として派遣されて、名前空間、およびこれはことによるとそうです。さらなる構文仕様に反映されます。 より複雑な環境で、それぞれの代表として派遣された名前空間がそれへ代表として派遣された名前空間の可変部分の構文を選ぶことが許可されるでしょう。 より簡単な名前空間では、構文は完全に親名前空間によって制限されるでしょう。 例えば、それには、DNSはURNsのためのすべての必要条件を満たすというわけではありませんが、完全に制限された構文があります、単にさらなる気品を左に加えることによってどんな一層の構造もしなければならないように、下位に高位を維持して、左の構造に正しいです。 代表として派遣された構文はホストがしかし、DNSによってその右と命名されて、"@"によって切り離されるものが右まで残っている下位への内部の注文がホストの上の定義された高位であるかもしれないファイルシステムによって定義されるストリングであるということであるかもしれません。 もちろん、祖父名前空間への必要性を特に考えて、はるかに複雑で入れ子にされた構文は可能であるべきです。 URNsを決議するために、規則が2つの理由に必要でしょう。 1つは単にURNの部品の簡単な(たぶん右への左か左に正しい)注文にならないそれらの名前空間をcanonicalizeすることになっています、当局がかかわった代表として派遣された命名で決定するように。 また、規則が段階で使用されるためにURNsからRDSサーバの名前を得るのに必要であるのも、可能です。
Sollins Informational [Page 19] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[19ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
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 |
+----------+ +----------+
つぼ: <NID><NSS>。| | | | +に対して-------------------+ |グローバルなNID登録| +-------------------+ | | | (リターン規則かURNレゾルバサービス参照) | +----------------------------------+ | | +->(RDSサーバを決定するために規則を適用します)| | | | | | | | | | | +----------+ | | |RDSサーバ| +-----------------+ | +----------+ | | | | v| | | (選択のセット) | | +----+----------(...)--------+ | (規則) | | | | | | | | | | +------+ | | v対+----------+ +----------+ |つぼ| |つぼ| |レゾルバ| |レゾルバ| |サービス| |サービス| +----------+ +----------+
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
NIDは最高平らな構文を定義します。 この構文は、単独かNSS(最高平らな命名権威名のための)からの何らかの抽出に関連したNIDが連絡されるべき平らな最初のサーバを特定するのに使用されることになっているかどうか決定するでしょう。 ルックアップの各段階では、ストリングを生成するための新しい規則はRDSの外でさらに別のルックアップに(それがオリジナルのURNと異なるなら、別のRDSサーバのアイデンティティとことによると決議されるべきストリングであるストリング)か参照をURNレゾルバサービスに使用しました、RDS体系のどんなさらなる使用も回避して。 図1
Sollins Informational [Page 20] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[20ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
depicts this process.
このプロセスについて表現します。
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体系をサポートするのに必要であるプロトコル、データ編成、分配、および模写の決断を戸外に発ちます。 2番目に、それは規則で生み出された計算の位置に戸外を出ます。 3番目に、それはRDSデータベースの仕切り(分配)が委譲という名前と同じ境界にある必要はない可能性を残しています。 これはいくつかに急進的に見えるかもしれませんが、情報が例えば、バランスのとれているB-木に保存されるなら、それらに沿って仕切りが、委譲境界と権威を命名しながら、ないかもしれません。([7])を見てください。 最後に、Global NID Registryへの開架は残っています。 これは、すべてのクライアントに分配されますか、または広く分配されたサーバで管理されますか? それがただ一つのRDS体系が多くかすべての命名体系から名前をサポートしそうであるというここでの意志であることに注意するのは重要です、それらのNIDsに表現されるように。
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つの概念は利用可能な1RDSがその時々であるかもしれないということです、新しい体系への発展を考慮するために。 したがって、画像はたぶん図2にさらに似るべきです。
Sollins Informational [Page 21] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[21ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
URN:<NID>:<NSS>
|
|
+-----------+-------(...)-------+
| |
| |
| |
v v
+---------------------+ +---------------------+
|Global NID registry 1| |Global NID registry N|
+---------------------+ +---------------------+
. .
. .
. .
つぼ: <NID>: <NSS>。| | +-----------+-------(...)-------+ | | | | | | v対+---------------------+ +---------------------+ |グローバルなNID登録1| |グローバルなNID登録N| +---------------------+ +---------------------+ . . . . . .
Figure 2: More than one co-existing RDS scheme
図2: 1つ以上の共存している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.
私たちが1つ以上の共存しているRDS計画を支持するつもりであると、そこでは、彼らの中の情報と変更の格納と伝播に関するコーディネートであることが必要でしょう。 問題は一般に、すべての情報がどんな操作上のRDS計画を通しても利用可能であるべきであると思われるべきであるということです。 人は、潜在的出版社が1つ以上のRDS計画にアップデートを提出することを期待できません。 したがって、そこでは、1からのこれらの計画のもう片方への情報の簡単なマッピングであることが必要でしょう。 その変化が一方向に入るだけであるのは、可能です、より新しい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で説明されるガイドラインか仮定があってもコンプライアンスを決して保証しないのは、明白であるべきです。 デザイン過程の一部として独自にこれらを見直さなければなりません。 これらのガイドラインに従うどんなただ一つの正しいデザインもありません。 その上、予備の提案がすべてのガイドラインを満たすかもしれないというわけではありませんが、承諾のどんな不足も箇条書きして、正当化すると予想されるべきであると思われます。
Sollins Informational [Page 22] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[22ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
5. Acknowledgments
5. 承認
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ワーキンググループとメーリングリストへの貢献者(つぼの ietf@bunyip.com )に感謝しなければなりません。
6. References
6. 参照
[1] Kunze, J., "Functional Recommendations for Internet Resource Locators", RFC 1736, February 1995.
[1] クンツェ、J.、「インターネット資料ロケータのための機能的な推薦」、RFC1736、1995年2月。
[2] Sollins, K., and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1738, December 1994.
1994年12月の[2] Sollins、K.とL.Masinter、「一定のリソース名のための機能条件書」RFC1738。
[3] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[3] バーナーズ・リーとT.とMasinter、L.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[4] URN Working Group, "Namespace Identifier Requirements for URN Services," Work in Progress.
[4] つぼの作業部会、「つぼのサービスのための名前空間識別子要件」は進行中で働いています。
[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.とケント、S.T.、「高値レベルプロトコルのセキュリティー対策」ACM Computing Surveys、v。 15 No.2、1983年6月、ページ 135-171.
[6] Moats, R., "URN Syntax", RFC 2141, May 1997.
[6]堀(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
[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、例えば、「グローバルな解決サービスを設計します」MIT LCS-TR712、1997年6月。 現在、<ps http://ana.lcs.mit.edu/anaweb/書類/tr-712.ps>か<pdf http://ana.lcs.mit.edu/anaweb/書類/tr712.pdf>として利用可能です。
7. Author's Address
7. 作者のアドレス
Karen Sollins MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
カレンSollins MIT Laboratory for Computer Science545技術平方です。 ケンブリッジ、MA 02139
Phone: +1 617 253 6006 EMail: sollins@lcs.mit.edu
以下に電話をしてください。 +1 6006年の617 253メール: sollins@lcs.mit.edu
Sollins Informational [Page 23] RFC 2276 Uniform Resource Name Resolution January 1998
2276年の[23ページ]RFCユニフォームリソース名前解決1998年1月の情報のSollins
8. Full Copyright Statement
8. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Sollins Informational [Page 24]
Sollins情報です。[24ページ]
一覧
スポンサーリンク
