Network Working Group K. Sollins
Request for Comments: 2276 MIT/LCS
Category: Informational January 1998
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.
版权所有（C）互联网协会（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（统一资源名称）解析程序服务的发现问题，这些服务将直接将URN转换为URL（统一资源定位器）和URC（统一资源特征）。本文档分为三个主要部分：工作的基本假设、成为可行的解析器发现服务或RDS的指导原则，以及设计RDS的框架。该指南分为三个主要领域：可进化性、可用性、安全性和隐私性。符合框架的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. 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.
本文档的目的是为我们将在此处称之为解析器发现服务（RDS）的服务制定工程标准，该服务有助于了解URN（统一资源名称）解析器。本文档中使用术语“解析器”来表示将URN转换为URL（统一资源定位器）或URC（统一资源特征）的服务。一些解析器也可以提供对资源的直接访问。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.
统一资源标识符工作组定义了命名体系结构，如三个RFC 1736[1]、1737[2]和1738[3]系列中所示。尽管需要更多的文档来完成该体系结构的描述，但它包含了通常与“命名”相关的三个核心功能：标识、位置和助记符或语义。所谓位置，我们指的是完全限定的域名或IP地址，可能扩展为TCP端口和/或本地标识符，如路径名。名称可以通过区分资源的“名称”来区分资源。名称可以通过包含“位置”信息来帮助提供对资源的访问。此外，名称可能具有其他语义或助记符信息，这些信息可以帮助人类用户记住或识别名称，或者包括有关被命名资源的其他语义信息。URI工作组的结论是，需要持久的、全球唯一的标识符，与位置或其他语义信息不同；这些被称为骨灰盒。这些“名称”提供了标识，因为如果其中两个“相同”（根据一些简单的规范化规则），它们标识相同的资源。此外，该小组决定，这些“名称”一般用于机器消费，而非人类消费。最后，通过这些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
与URN不同的是，可以想象各种人性化命名（HFN）方案支持不同的应用程序套件和用户社区。根据名称空间的不同，它们需要以更紧密或更松散的耦合方式提供到URN的映射。正是这些HFN具有助记功能、内容完整性，并且可能是可变的，以跟踪使用和语义的变化。他们可能会提供小摆设和其他服务
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.
RFC 1737中所述的URN是全局定义的；它们无处不在，因为任何上下文中的任何位置的URN都标识相同的资源。鉴于对URN的这一要求，必须询问其对RDS的含义。无处不在是否意味着处处都能保证RDS解决方案？普遍性是否意味着各地的分辨率信息相同？在这两种情况下，答案可能都不是。人们无法做出全球性、系统性的保证，除非付出超出理性的代价。此外，可能有政策和技术原因导致各地不能以同样的方式解决问题。URN到资源实例的解析很可能会在不同的条件下到达不同的实例或副本。因此，尽管URN anywhere指的是相同的资源，但在某些环境中，在某些条件下，在不同的时间，由于网络条件或策略控制的变幻莫测，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集的提示，例如，指示具有特定前缀或后缀的所有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维护或缓存一组提示。这些可能是从资源所有者、资源推荐人或许多其他来源中获得的。此外，对于那些在本地发现的提示失败的情况，精心设计的系统将提供一种回退机制来发现进一步的提示。本文档中讨论的正是这种回退机制，即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:
本文件其余部分分为三节。第一部分确定了这项工作背后的几组假设。有三个一般假设：
* URNs are persistent; * URN assignment can be delegated; * Decisions can be made independently, enabling isolation from decisions of one's peers.
* 骨灰盒是持久的；*可以委派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:
下一节介绍了解析器发现服务设计的三个主要原则。对于其中每一项，我们都确定了一些更具体的指导方针，进一步定义和完善了一般原则。本节可能是文件中最关键的部分，因为任何拟议的RDS计划都必须与这些原则和相应的指导方针相比较，以了解其是否足够。这三项中心原则可概括为：
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) 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.
那部分。
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邮件列表中的讨论，三个主要的假设领域是显而易见的：寿命、授权和独立性。每一项都将单独讨论。
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解决方案的支持基础设施的几乎任何部分都会发生变化。为了处理基于寿命假设的移动性和进化假设，我们必须假设用户及其应用程序可以保持独立于支持基础设施的这些变化细节。
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.
第二种假设是，命名和处置机构可能会将其部分权力或责任委托给其他机构；在这两种情况下，授权是唯一已知的允许预期缩放的方法。需要注意的是，这项工作的一个重要特点是，它有可能将名称分配、使用URN标记资源的工作与名称解析、发现给定URN的资源的工作分开。在这两种情况下，我们都希望有多层授权。可能存在合并这两组职责和委托关系的RDS方案；通过这样做，它们结合在一起或使两种截然不同的活动过载，从而可能阻碍生长。
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.
第三个假设是一个权威独立于另一个权威，至少在某种程度上独立于其父权威。当一个机构将其部分权利和责任委托给另一个机构时，被委托人可以在该域中独立于其对等机构进行操作，并在委托规定的范围内独立于委托人进行操作。为了实现政策和机制的独立性，这种隔离至关重要。
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.
第三个假设有几个推论。首先，我们假设资源的发布者可以独立于其他人的选择来选择解析器服务。在任何给定时间，命名空间的所有者都可以为该委派命名空间选择特定的URN解析器服务。这样的URN解析器服务可以在RDS服务模型之外，并且仅由RDS服务识别或定位。第二，必须能够在RDS服务中进行选择。多个RDS服务的存在可能源于RDS服务的发展或新服务的开发。尽管在任何给定的时间都可能只有一个或一小组这样的服务，但在从一个体系结构到另一个体系结构的过渡期间，数量可能会增加。因此，必须假设客户机可以在可能非常小的一组RDS中进行选择。第三，在选择所需的安全性和真实性的级别和模型时必须具有独立性。命名子空间的所有者可以进行此选择，以控制谁可以修改该子空间中的提示。命名机构可以将此选择委托给以其分配的名称命名的资源的所有者。为了允许其他参与者拥有他们所需的安全性和真实性水平，例如为了维护整个RDS基础设施的完整性，这种选择自由可能会受到限制。第四，存在一种独立于名称空间内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.
授权和隔离的模块化假设意味着决策和实现的独立性，从而导致分散，从而提供一定程度的安全性，防止拒绝服务。基于这些假设以及RFCs 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的指南围绕着可进化性、可用性、安全性和隐私性三个重要的设计原则。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系统将由名称空间中的名称、它们的解析信息以及从名称空间中的名称到解析信息（或提示）的映射组成。骨灰盒本身必须符合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.
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.
我们必须将互联网的经验教训之一纳入解决骨灰盒问题的机制的发展中，这就是我们必须为变革做好准备。这种变化可能发生得很慢，足以被认为是对现有服务的进化性修改，也可能发生得很戏剧性，足以被认为是革命性的。他们可能会一点一点地渗透到互联网世界，与早期的服务并肩生活，或者他们可能会狂风暴雨般地占领互联网，在短时间内造成明显的彻底转变。我们可以从几个方向预测进化的需要。至少，社区和提议的机制应该为此做好准备。
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.
首先，扩展是与进化相关的主要问题。至少在短期内，人类和电子用户的数量以及资源的数量将继续呈指数级增长。因此，骨灰盒的数量也将同样增加。此外，随着数量的增加，命名权和处置权的授权可能会增加。这些事实意味着，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.
第二，我们预计机制将有所增加和改变。社区已经了解到，必须有新的URN计划的容量，如[4]所述。URN方案将定义一组满足URN要求[2]的URN，但可能对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解决方案的总体计划开始，上面描述的增强可能适合于此，那么我们还必须为认证方案的发展做好准备，这将被认为是有用的或在将来是必要的。没有一个全局接受的身份验证方案，也可能永远不会有。即使在某个时候确实存在这样的计划，我们也必须随时准备采用更新更好的计划，因为旧计划太容易被欺骗或猜测。
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.
第三个进化问题比其他问题更加机械。在任何时候，社区都可能支持在解决问题上采取折衷立场。我们可能会在可行性和理想之间保持平衡的情况下运营，可能会使用政策控制来帮助稳定服务的使用。理想情况下，该服务将提供客户所需的服务，而客户不会要求提供超出其需要的支持，但这似乎极不可能。由于我们几乎总是处于某些服务提供资源短缺的情况下，因此通常需要某种形式的政策控制。一些策略控制可以在服务器内部或协议细节中实现为机制，而其他策略控制只能在系统外部实现。例如，假设正在提交提示条目，提示服务器正在使用其多余的容量，并且需要更多的磁盘空间。政策控制的两个建议是定价和管理。随着技术的变化和资源短缺平衡的变化，控制其使用的机制和政策也必须演变。
To summarize, the usability guidelines fall into three areas based on participation in hint management and discovery:
总之，根据参与提示管理和发现，可用性指南分为三个方面：
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) 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.
可用性可以从三个不同的角度进行评估：希望公开某一信息的发布者、请求URN解析的客户以及解析信息的提供者或管理者。我们将分别从这三个角度讨论可用性问题。重要的是要认识到，在这些情况下，一些参与者的利益（例如使用和出版商）可能会发生冲突；需要一些解决方案。
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工作组所讨论的，在整个命名过程中还有两种额外的参与者。他们是选择和分配名称的命名机构，也是在其资源中包含骨灰盒的作者。这两个问题与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中获益，因为它们增加了引用继续指向其已发布资源的机会。
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体系结构必须在策略控制范围内支持这种转换。值得注意的是，尽管电话簿中提供多种登录服务，但通常都会附带费用。没有任何东西可以阻止对骨灰盒的类似服务收取费用。
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.
发布者应该能够提供有关访问资源的长期和短期位置信息。长期信息可能是资源本身的长期地址或与发布者有长期关系的解析程序服务的位置或标识等信息。可以想象，与这样一个长期的“权威”解析器服务的安排可能是可靠性、故障恢复能力和原子更新的保证。短期信息对于服务的短期变更或避免短期拥塞或故障问题非常有用。例如，如果资源的实际存储库暂时无法访问，则可以从另一个存储库获取资源。这种短期信息可以被视为对长期信息的临时改进，因此应该更容易、更迅速地提供，但可能不太可靠。某些RDS设计可能无法区分这两个极端。
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
此外，能够为RDS构建简单、标准的接口非常重要，这样客户机和代表客户的应用程序都可以解释提示，并随后做出明智的选择。客户，也许是
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.
从客户端的角度来看，尽管URN将提供重要的功能，但客户端最有可能仅与人类友好名称（HFN）直接交互。与直接的人际互动（非计算机介导）一样，姓名共享将以小型、私有或特定领域的规模进行。HFN将是易于记忆、键入、选择、分配等的引用和名称。还需要有许多机制将HFN映射到URN。“黄页”或“搜索工具”等服务属于这一类。尽管我们在这里提到了HFNs，但必须认识到HFNs和从HFNs到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.
整个社区。因此，例如，授权存储提示的少量一次性费用可能会鼓励保守使用提示。如果我们假设管理提示的成本是固定的，那么它在整个URN空间中的适用性越广，成本效益就越高。也就是说，当一个提示可以用于整个骨灰盒集合时，就会有一种动机，即在大量更具体的提示之上提交一个通用提示。可以制定类似的政策来阻止提示的频繁更改。通过这些方式和其他方式，可以鼓励有利于整个社区的行为。
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.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) 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.
在讨论安全性时，主要问题之一是列举正在考虑缓解的威胁。权衡通常包括资金成本、计算和通信资源、易用性、使用可能性以及所提议机制的有效性。考虑到这一点，让我们考虑一系列威胁。
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.
一条信息是否来自主要来源，并要求它是主要来源。第二种含义出现在文件的其他地方，并在文件中注明。
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".
区分“访问控制”的各种可能含义也很重要。有两个方面可以区分。首先，存在正在解决的访问控制类型的问题，例如，在提示方面，它是读取访问、读取和修改访问，还是读取并验证真实性。第二个问题是什么样的访问被控制。在命名上下文中，可能是名称本身（不是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.
在这一点上还有一个问题需要解决，即机制和政策之间的区别。一般来说，一项政策是通过一套机制来实现的。在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
URN解析的第一种方法是发现本地提示。为了在本地发现提示，它们需要尽可能广泛地分布到每个区域的本地。这种广泛分发的缺点是更新的广泛分发，导致网络流量问题或在交付更新时出现延迟。另一种模型将提示信息集中在服务器中，因此要求更新信息只分发给这些服务器。在这种模型中，脆弱点是信息的来源和它们之间的分布网络。攻击服务器中存储的信息完整性的攻击者可能伪装成信息的所有者或服务器。信息的广泛复制
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:
在服务器之间，增加了在信息的所有位置伪装的难度，并降低了拒绝服务的威胁。这就为我们的安全模型提供了三个可识别的指导原则：
* 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.
* 服务器分布：广泛的可用性将提供对拒绝服务的抵抗。只有在服务可用的情况下，它们才能提供任何程度的可信度。此外，服务的分发将减少对任何单个服务器的信任，从而降低整个社区的脆弱性。这必须通过以下事实来缓解：在某种程度上，信任是基于一组链接的服务器，如果任何一台服务器出现故障，整个信任链就会出现故障；这种链条中的元素越多，它就越容易受到攻击。
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解析程序服务器可以设计为需要身份证明才能获得解析信息；如果客户端没有访问请求的URN的权限，则服务会拒绝此类URN的存在。还可以使用加密协议，以使请求和响应都被隐藏。Encryption在这种情况下是可能的，因为最终收件人的身份是已知的（即URN服务器）。因此，对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>
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
其中URN：是所有URN上的前缀，NID是名称空间标识符，NSS是特定于名称空间的字符串。前缀标识每个URN。NID确定其命名空间内所有URN的通用语法。NSS可能被划分为一组
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不满足URN的所有要求，但它具有完全受限的语法，因此任何进一步的结构化都必须通过向左侧添加进一步的细化来完成，保持从高阶到低阶、从右到左的结构。委托语法可能是这样一种语法：主机由DNS命名，但在该语法的右侧，由“@”分隔的是一个字符串，其内部顺序由主机上的文件系统定义，可以从高到低、从左到右进行定义。当然，更复杂和嵌套的语法应该是可能的，特别是考虑到需要使用名称空间。为了解决URN问题，出于两个原因需要制定规则。一种方法是规范化那些不属于URN组件的直接（可能是从右到左或从左到右）排序的名称空间，这是由相关的委托命名机构确定的。还可能需要规则才能从URN中派生出要分阶段使用的RDS服务器的名称。
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 |
+----------+ +----------+
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
NID定义了顶级语法。此语法将确定是单独使用NID还是与NSS的某些提取（用于顶级命名机构名称）结合使用来标识要联系的第一级服务器。在查找的每个阶段，要么是用于生成在另一个查找中使用的字符串的新规则（字符串是另一个RDS服务器的标识，如果它不同于原始URN，则可能是要解析的字符串），要么是RDS外部对URN解析器服务的引用，从而避免进一步使用RDS方案。图1
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方案所需的协议、数据组织、分发和复制。其次，它保留了由规则产生的计算的位置。第三，它允许RDS数据库的分区（分布）不必与名称委派位于同一边界上。对于某些人来说，这似乎很激进，但是如果信息存储在平衡的B-树中，那么分区可能不会沿着命名机构委托边界进行（参见[7]）。最后，它允许对全局NID注册表进行开放访问。这是分布到每个客户端，还是在分布广泛的服务器中进行管理？需要注意的是，此处的意图是单个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中未提及的一个概念是，在任何给定时间都可能有多个可用的RDS，以允许演变为新方案。因此，图片应该更像图2。
URN:<NID>:<NSS>
|
|
+-----------+-------(...)-------+
| |
| |
| |
v v
+---------------------+ +---------------------+
|Global NID registry 1| |Global NID registry N|
+---------------------+ +---------------------+
. .
. .
. .
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服务，而旧的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.
对于本文档的最重要的感谢是Lewis Girod，他是我在一份初步的URN需求文档上的合作者，并对本文档的版本发表了深刻的评论。还要感谢罗恩·丹尼尔，特别是他对我的写作发表了许多评论。此外，我还认识了以前的URN框架文档“Knoxville”组的贡献者。你们中有太多人无法在这里单独致谢，但谢谢你们。最后，我必须感谢URN工作组和邮件列表（URN）的贡献者-ietf@bunyip.com)，供您就这些主题和相关主题进行生动的讨论。
[1] Kunze, J., "Functional Recommendations for Internet Resource Locators", RFC 1736, February 1995.
[1] Kunze，J.，“因特网资源定位器的功能建议”，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，“统一资源名称的功能要求”，RFC 17381994年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，“统一资源定位器（URL）”，RFC 17381994年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计算调查，V。1983年6月15日，第2号，第135-171页。
[6] Moats, R., "URN Syntax", RFC 2141, May 1997.
[6] 护城河，R.，“瓮语法”，RFC 21411997年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，例如，“设计全球解决方案服务”，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
卡伦·索林麻省理工学院计算机科学实验室，马萨诸塞州剑桥545技术广场，邮编：02139
Phone: +1 617 253 6006
EMail: sollins@lcs.mit.edu
Phone: +1 617 253 6006
EMail: sollins@lcs.mit.edu
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。