Network Working Group M. Mealling, Ed.
Request for Comments: 3305 R. Denenberg, Ed.
Category: Informational W3C URI Interest Group
August 2002
Network Working Group M. Mealling, Ed.
Request for Comments: 3305 R. Denenberg, Ed.
Category: Informational W3C URI Interest Group
August 2002
Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations
来自W3C/IETF URI规划联合兴趣小组的报告：统一资源标识符（URI）、URL和统一资源名称（URN）：澄清和建议
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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document, a product of the W3C Uniform Resource Identifier (URI) Interest Group, addresses and attempts to clarify issues pertaining to URIs. This document addresses how URI space is partitioned and the relationship between URIs, URLs, and URNs, describes how URI schemes and URN namespaces ids are registered, and presents recommendations for continued work on this subject.
本文档是W3C统一资源标识符（URI）兴趣小组的一个产品，它解决并试图澄清与URI相关的问题。本文档介绍了URI空间的分区方式以及URI、URL和URN之间的关系，描述了URI方案和URN命名空间ID的注册方式，并提出了继续研究此主题的建议。
Table of Contents
目录
1. The W3C URI Interest Group . . . . . . . . . . . . . . . . 2
2. URI Partitioning . . . . . . . . . . . . . . . . . . . . . 2
2.1 Classical View . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Contemporary View . . . . . . . . . . . . . . . . . . . . 3
2.3 Confusion . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Registration . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1 Registered URI schemes . . . . . . . . . . . . . . . . . . 4
3.1.2 Unregistered URI Schemes . . . . . . . . . . . . . . . . . 4
3.1.2.1 Public Unregistered Schemes . . . . . . . . . . . . . . . 4
3.1.2.2 Private Schemes . . . . . . . . . . . . . . . . . . . . . 5
3.1.3 Registration of URI Schemes . . . . . . . . . . . . . . . 5
3.1.3.1 IETF Tree . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.3.2 Other Trees . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 URN Namespaces . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Registered URN NIDs . . . . . . . . . . . . . . . . . . . 5
3.2.2 Pending URN NIDs . . . . . . . . . . . . . . . . . . . . . 6
3.2.3 Unregistered NIDs . . . . . . . . . . . . . . . . . . . . 7
3.2.4 Registration Procedures for URN NIDs . . . . . . . . . . . 7
4. Additional URI Issues . . . . . . . . . . . . . . . . . . 7
5. Recommendations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . 11
1. The W3C URI Interest Group . . . . . . . . . . . . . . . . 2
2. URI Partitioning . . . . . . . . . . . . . . . . . . . . . 2
2.1 Classical View . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Contemporary View . . . . . . . . . . . . . . . . . . . . 3
2.3 Confusion . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Registration . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1 Registered URI schemes . . . . . . . . . . . . . . . . . . 4
3.1.2 Unregistered URI Schemes . . . . . . . . . . . . . . . . . 4
3.1.2.1 Public Unregistered Schemes . . . . . . . . . . . . . . . 4
3.1.2.2 Private Schemes . . . . . . . . . . . . . . . . . . . . . 5
3.1.3 Registration of URI Schemes . . . . . . . . . . . . . . . 5
3.1.3.1 IETF Tree . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.3.2 Other Trees . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 URN Namespaces . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Registered URN NIDs . . . . . . . . . . . . . . . . . . . 5
3.2.2 Pending URN NIDs . . . . . . . . . . . . . . . . . . . . . 6
3.2.3 Unregistered NIDs . . . . . . . . . . . . . . . . . . . . 7
3.2.4 Registration Procedures for URN NIDs . . . . . . . . . . . 7
4. Additional URI Issues . . . . . . . . . . . . . . . . . . 7
5. Recommendations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . 11
In October, 2000 the W3C formed a planning group whose mission was to evaluate the opportunities for W3C work in the area of Uniform Resource Identifiers (URIs) and to develop a proposal for continued work in this area. The Interest Group was composed of W3C members and invited experts from the IETF to participate as well. This document is a set of recommendations from this group, to the W3C and the IETF for work that can and should continue in this area.
2000年10月，W3C成立了一个规划小组，其任务是评估W3C在统一资源标识符（URI）领域的工作机会，并制定在该领域继续工作的建议。兴趣小组由W3C成员组成，并邀请IETF的专家参加。本文档是该小组向W3C和IETF提出的一组建议，这些建议可以并且应该继续在该领域开展工作。
There is some confusion in the web community over the partitioning of URI space, specifically, the relationship among the concepts of URL, URN, and URI. The confusion owes to the incompatibility between two different views of URI partitioning, which we call the "classical" and "contemporary" views.
web社区对URI空间的划分存在一些混乱，特别是URL、URN和URI概念之间的关系。这种混乱是由于URI分区的两种不同视图之间的不兼容造成的，我们称之为“经典”和“当代”视图。
During the early years of discussion of web identifiers (early to mid 90s), people assumed that an identifier type would be cast into one of two (or possibly more) classes. An identifier might specify the location of a resource (a URL) or its name (a URN), independent of location. Thus a URI was either a URL or a URN. There was discussion about generalizing this by the addition of a discrete number of additional classes; for example, a URI might point to metadata rather than the resource itself, in which case the URI would be a URC (citation). URI space was thus viewed as partitioned into subspaces: URL, URN, and additional subspaces to be defined. The only such additional space ever proposed was Uniform Resource Characteristics (URC) and there never was any buy-in; so without loss of generality, it's reasonable to say that URI space was thought to be partitioned into two classes: URL and URN. Thus, for example, "http:" was a URL scheme, and "isbn:" would (someday) be a URN scheme. Any new scheme would be cast into one of these two classes.
在web标识符的早期讨论中（90年代早期到中期），人们认为标识符类型将被转换为两个（或可能更多）类中的一个。标识符可以指定资源的位置（URL）或名称（URN），与位置无关。因此，URI是URL或URN。有人讨论通过增加离散数量的附加类来推广这一点；例如，URI可能指向元数据而不是资源本身，在这种情况下，URI将是URC（引文）。因此，URI空间被视为划分为子空间：URL、URN和要定义的附加子空间。唯一提出的此类额外空间是统一资源特征（URC），从未有任何买入；因此，在不丧失通用性的情况下，可以合理地说URI空间被划分为两个类：URL和URN。因此，例如，“http:”是一个URL方案，“isbn:”有一天会是一个URN方案。任何新的计划都会被归入这两类中的一类。
Over time, the importance of this additional level of hierarchy seemed to lessen; the view became that an individual scheme did not need to be cast into one of a discrete set of URI types, such as "URL", "URN", "URC", etc. Web-identifier schemes are, in general, URI schemes, as a given URI scheme may define subspaces. Thus "http:" is a URI scheme. "urn:" is also a URI scheme; it defines subspaces, called "namespaces". For example, the set of URNs, of the form "urn:isbn:n-nn-nnnnnn-n", is a URN namespace. ("isbn" is an URN namespace identifier. It is not a "URN scheme", nor is it a "URI scheme.")
随着时间的推移，这种额外层次的重要性似乎逐渐降低；有人认为，单个方案不需要转换为一组离散的URI类型，例如“URL”、“URN”、“URC”等。Web标识符方案通常是URI方案，因为给定的URI方案可以定义子空间。因此，“http:”是一个URI方案。“urn:”也是一个URI方案；它定义了子空间，称为“名称空间”。例如，格式为“urn:isbn:n-nn-nnnn-n”的urn集是urn命名空间。（“isbn”是URN命名空间标识符。它不是“URN方案”，也不是“URI方案”。）
Further, according to the contemporary view, the term "URL" does not refer to a formal partition of URI space; rather, URL is a useful but informal concept. A URL is a type of URI that identifies a resource via a representation of its primary access mechanism (e.g., its network "location"), rather than by some other attributes it may have. Thus, as we noted, "http:" is a URI scheme. An http URI is a URL. The phrase "URL scheme" is now used infrequently, usually to refer to some subclass of URI schemes which exclude URNs.
此外，根据当代观点，术语“URL”并不指URI空间的形式划分；相反，URL是一个有用但非正式的概念。URL是一种URI类型，它通过资源的主要访问机制（例如，其网络“位置”）的表示来标识资源，而不是通过资源可能具有的某些其他属性来标识资源。因此，正如我们所指出的，“http:”是一个URI方案。http URI是一个URL。短语“URL方案”现在很少使用，通常指的是排除URN的URI方案的一些子类。
The body of documents (RFCs, etc) covering URI architecture, syntax, registration, etc., spans both the classical and contemporary periods. People who are well-versed in URI matters tend to use "URL" and "URI" in ways that seem to be interchangeable. Among these experts, this isn't a problem, but among the Internet community at
涵盖URI体系结构、语法、注册等的文档体（RFC等）跨越了古典和现代两个时期。精通URI事务的人倾向于以似乎可以互换的方式使用“URL”和“URI”。在这些专家中，这不是一个问题，但在美国的互联网社区中
large, it is a problem. People are not convinced that URI and URL mean the same thing, in documents where they (apparently) do. When one RFC talks about URI schemes (e.g. "URI Syntax" (RFC 2396) [12]), another talks about URL schemes (e.g. "Registration Procedures for URL Schemes" (RFC 2717) [1]), and yet another talks of URN schemes ("Architectural Principles of URN Resolution" (RFC 2276) [13]), it is natural to wonder how they difference, and how they relate to one another. While RFC 2396, section 1.2, attempts to address the distinction between URIs, URLs and URNs, it has not been successful in clearing up the confusion.
大，这是一个问题。人们不相信URI和URL在文档中的含义是一样的（显然是一样的）。当一个RFC讨论URI方案（例如“URI语法”（RFC 2396）[12]），另一个RFC讨论URL方案（例如“URL方案的注册过程”（RFC 2717）[1]），还有另一个RFC讨论URN方案（“URN解析的体系结构原则”（RFC 2276）[13]），人们自然会想知道它们之间有什么区别，以及它们之间的关系。尽管RFC 2396第1.2节试图解决URI、URL和URN之间的区别，但它并没有成功地消除混淆。
This section examines the state of registration of URI schemes and URN namespaces and the mechanisms by which registration currently occurs.
本节检查URI方案和URN名称空间的注册状态以及当前进行注册的机制。
The official register of URI scheme names is maintained by IANA, at http://www.iana.org/assignments/uri-schemes. For each scheme, the RFC that defines the scheme is listed; for example "http:" is defined by RFC2616 [14]. The table lists 34 schemes (at time of publication of this RFC). In addition, there are a few "reserved" scheme names; at one point in time, these were intended to become registered schemes but have since been dropped.
URI方案名称的官方登记册由IANA维护，位于http://www.iana.org/assignments/uri-schemes. 对于每个方案，列出定义方案的RFC；例如，“http:”由RFC2616[14]定义。该表列出了34个方案（在本RFC发布时）。此外，还有一些“保留”方案名称；这些计划曾一度打算成为注册计划，但后来被取消。
We distinguish between public (unregistered) and private schemes. A public scheme (registered or not) is one for which there is some public document describing it.
我们区分公共（未注册）和私人计划。公共计划（注册或未注册）是指有公共文件对其进行描述的计划。
Dan Conolly's paper, at http://www.w3.org/Addressing/schemes, provides a list of known public URI schemes, both registered and un-registered, a total of 85 schemes at time of publication of this RFC. 50 or so of these are unregistered (not listed in the IANA register). Some of these URI schemes are obsolete (for example, "phone" is obsolete, superceded by "tel"), while some have an RFC, but are not included in the IANA list.
Dan Conolly的论文，在http://www.w3.org/Addressing/schemes，提供了已注册和未注册的已知公共URI方案列表，在本RFC发布时共有85个方案。其中50个左右未注册（未列入IANA注册）。其中一些URI方案已过时（例如，“phone”已过时，由“tel”取代），而一些具有RFC，但不包括在IANA列表中。
It is probably impossible to determine all of these, and it's not clear that it's worthwhile to try, except perhaps to get some idea of their number. In the minutes of the August 1997 IETF meeting is the observation that there may be 20-40 in use at Microsoft, with 2-3 being added a day, and that WebTV has 24, with 6 added per year.
可能不可能确定所有这些，也不清楚是否值得尝试，除非可能了解它们的数量。在1997年8月IETF会议记录中，观察到微软可能有20-40台在使用，每天增加2-3台，而WebTV有24台，每年增加6台。
"Registration Procedures for URL Scheme Names" (RFC 2717) [1] specifies procedures for registering scheme names and points to "Guidelines for new URL Schemes" (RFC 2718) [2], which supplies guidelines. RFC 2717 describes an organization of schemes into "trees". It is important to note that these two documents use the historical term 'URL' when in fact, they refer to URIs in general. In fact, one of the recommended tasks in Section 5 is for these documents to be updated to use the term 'URI' instead of 'URL'.
“URL方案名称的注册程序”（RFC 2717）[1]规定了注册方案名称的程序，并指向提供指南的“新URL方案指南”（RFC 2718）[2]。RFC2717将方案组织为“树”。需要注意的是，这两个文档使用了历史术语“URL”，而实际上它们通常指的是URI。事实上，第5节中推荐的任务之一是更新这些文档，以使用术语“URI”而不是“URL”。
The IETF tree is intended for schemes of general interest to the Internet community, and for those which require a substantive review and approval process. Registration in the IETF tree requires publication of the scheme syntax and semantics in an RFC.
IETF树用于互联网社区普遍感兴趣的计划，以及需要实质性审查和批准流程的计划。在IETF树中注册需要在RFC中发布方案语法和语义。
Although RFC 2717 describes "alternative trees", no alternative trees have been registered to date, although a vendor-supplied tree ("vnd") is pending. URI schemes in alternative trees will be distinguished because they will have a "." in the scheme name.
尽管RFC 2717描述了“替代树”，但迄今为止尚未注册替代树，尽管供应商提供的树（“vnd”）正在等待注册。将区分备选树中的URI方案，因为它们在方案名称中有一个“.”。
A URN namespace is identified by a "Namespace ID" (NID), which is registered with IANA (see Section 3.2.4).
URN名称空间由“名称空间ID”（NID）标识，该名称空间在IANA注册（见第3.2.4节）。
There are two categories of registered URN NIDs:
有两类已注册的URN NID：
o Informal: These are of the form, "urn-<number>", where <number> is assigned by IANA. There are four registered (at time of publication of this RFC) in this category (urn-1, urn-2, urn-3, and urn-4).
o 非正式：它们的形式为“urn-<number>”，其中<number>由IANA分配。在本RFC发布时，该类别中有四个已注册（urn-1、urn-2、urn-3和urn-4）。
o Formal: The official list of registered NIDs is kept by IANA at http://www.iana.org/assignments/urn-namespaces. At the time of publication of this RFC it lists ten registered NIDs:
o 正式：注册NID的正式列表由IANA保存在http://www.iana.org/assignments/urn-namespaces. 在本RFC发布时，它列出了十个已注册的NID：
* 'ietf', defined by "URN Namespace for IETF Documents" (RFC 2648) [3]
* “ietf”，由“ietf文档的URN名称空间”（RFC 2648）[3]定义
* 'pin', defined by "The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations" (RFC 3043) [4]
* “pin”，由“网络解决方案个人互联网名称（pin）：个人和组织的URN名称空间”（RFC 3043）[4]定义
* 'issn' defined by "Using The ISSN as URN within an ISSN-URN Namespace" (RFC 3043) [4]
* “将issn用作issn-URN命名空间中的URN”定义为“issn”（RFC 3043）[4]
* 'oid' defined by "A URN Namespace of Object Identifiers" (RFC 3061) [6]
* “oid”由“对象标识符的URN命名空间”定义（RFC 3061）[6]
* 'newsml' defined by "URN Namespace for NewsML Resources" (RFC 3085) [7]
* “newsml”由“newsml资源的URN命名空间”（RFC 3085）定义[7]
* 'oasis' defined by "A URN Namespace for OASIS" (RFC 3121) [8]
* “oasis”由“oasis的URN命名空间”定义（RFC 3121）[8]
* 'xmlorg' defined by "A URN Namespace for XML.org" (RFC 3120) [9]
* “XML.org的URN名称空间”定义的“xmlorg”（RFC3120）[9]
* 'publicid' defined by "A URN Namespace for Public Identifiers" (RFC 3151) [10]
* “公共标识符的URN名称空间”（RFC 3151）[10]定义的“publicid”
* 'isbn' defined by "Using International Standard Book Numbers as Uniform Resource Names" (RFC 3187) [15]
* “isbn”定义为“使用国际标准图书编号作为统一资源名称”（RFC 3187）[15]
* 'nbn' defined by "Using National Bibliography Numbers as Uniform Resource Names" (RFC 3188) [16]
* “nbn”定义为“使用国家书目编号作为统一资源名称”（RFC 3188）[16]
There are a number of pending URN NID registration requests, but there is no reliable way to discover them, or their status. It would be helpful if there were some formal means to track the status of NID requests such as 'isbn'.
有许多挂起的URN NID注册请求，但是没有可靠的方法来发现它们或它们的状态。如果有一些正式的方法来跟踪NID请求的状态，例如“isbn”，这将是很有帮助的。
In the "unregistered" category (besides the experimental case, not described in this paper), there are entities that maintain namespaces that, while completely appropriate as URNs, just haven't bothered to explore the process of NID registration. The most prominent that comes to mind is 'hdl'. In the case of 'hdl', it has been speculated that this scheme has not been registered because it is not clear to the owners whether it should be registered as a URI scheme or as a URN namespace.
在“未注册”类别中（除了实验性案例，本文中没有描述），有一些实体维护名称空间，虽然它们完全适合作为URN，但却懒得探索NID注册的过程。想到的最突出的是“hdl”。在“hdl”的情况下，有人推测该方案尚未注册，因为所有者不清楚该方案是否应注册为URI方案或URN名称空间。
"URN Namespace Definition Mechanisms" (RFC 2611) [11] describes the mechanism to obtain an NID for a URN namespace, which is registered with IANA.
“URN名称空间定义机制”（RFC 2611）[11]描述了为URN名称空间获取NID的机制，该名称空间已向IANA注册。
A request for an NID should describe features including: structural
characteristic of identifiers (for example, features relevant to
caching/shortcuts approaches); specific character encoding rules
(e.g., which character should be used for single-quotes); RFCs,
standards, etc, that explain the namespace structure; identifier
uniqueness considerations; delegation of assignment authority,
including how to become an assigner of identifiers; identifier
persistence considerations; quality of service considerations;
process for identifier resolution; rules for lexical equivalence; any
special considerations required for conforming with the URN syntax
(particularly applicable in the case of legacy naming systems);
validation mechanisms (determining whether a given string is
currently a validly-assigned URN); and scope (for example,"United
States social security numbers").
A request for an NID should describe features including: structural
characteristic of identifiers (for example, features relevant to
caching/shortcuts approaches); specific character encoding rules
(e.g., which character should be used for single-quotes); RFCs,
standards, etc, that explain the namespace structure; identifier
uniqueness considerations; delegation of assignment authority,
including how to become an assigner of identifiers; identifier
persistence considerations; quality of service considerations;
process for identifier resolution; rules for lexical equivalence; any
special considerations required for conforming with the URN syntax
(particularly applicable in the case of legacy naming systems);
validation mechanisms (determining whether a given string is
currently a validly-assigned URN); and scope (for example,"United
States social security numbers").
There are additional unresolved URI issues not considered by this paper, which we hope will be addressed by a follow-on effort. We have not attempted to completely enumerate these issues, however, they include (but are not limited to) the following:
本文没有考虑其他未解决的URI问题，我们希望后续工作能够解决这些问题。我们没有试图完全列举这些问题，但是，它们包括（但不限于）以下内容：
o The use of URIs as identifiers that don't actually identify network resources (for example, they identify an abstract object, such as an XML namespace, or a physical object such as a book or even a person).
o 使用URI作为标识符，实际上并不标识网络资源（例如，它们标识抽象对象，如XML名称空间，或物理对象，如书籍甚至人）。
o IRIs (International Resource Identifiers): the extension of URI syntax to non-ASCII.
o IRIs（国际资源标识符）：URI语法对非ASCII的扩展。
We recommend the following:
我们建议如下：
1. The W3C and IETF should jointly develop and endorse a model for URIs, URLs, and URNs consistent with the "Contemporary View" described in section 1, and which considers the additional URI issues listed or alluded to in section 3.
1. W3C和IETF应联合开发并认可一个URI、URL和URN模型，该模型符合第1节中描述的“当代视图”，并考虑第3节中列出或提及的其他URI问题。
2. RFCs such as 2717 ("Registration Procedures for URL Scheme Names") and 2718 ("Guidelines for new URL Schemes") should both be generalized to refer to "URI schemes", rather than "URL schemes" and, after refinement, moved forward as Best Current Practices in the IETF.
2. 诸如2717（“URL方案名称的注册程序”）和2718（“新URL方案的指南”）等RFC都应泛化为“URI方案”，而不是“URL方案”，并在细化后，作为IETF中的最佳现行实践向前推进。
3. The registration procedures for alternative trees should be clarified in RFC 2717.
3. 替代树木的登记程序应在RFC 2717中明确。
4. Public, but unregistered schemes, should become registered, where possible. Obsolete schemes should be purged or clearly marked as obsolete.
4. 在可能的情况下，公共但未注册的计划应注册。过时的方案应清除或清楚标记为过时。
5. IANA registration information should be updated:
5. IANA注册信息应更新：
* Add 'urn' to the list of registered URI schemes with a pointer to the URN namespace registry.
* 使用指向urn命名空间注册表的指针将“urn”添加到已注册URI方案的列表中。
* Maintain status information about pending registrations (URI schemes and URN NID requests ).
* 维护有关挂起注册的状态信息（URI方案和URN NID请求）。
* Insure that it is clear that the page is the official registry, e.g., by adding a heading to the effect "This is the Official IANA Registry of URI Schemes".
* 确保页面是官方注册，例如，添加一个标题，大意是“这是URI方案的官方IANA注册”。
This memo does not raise any known security threats.
这份备忘录没有提出任何已知的安全威胁。
The participants in the URI Planning Interest Group are:
URI规划兴趣小组的参与者包括：
o Tony Coates
o 托尼·科茨
o Dan Connolly
o 丹康纳利
o Diana Dack
o 戴安娜·达克
o Leslie Daigle
o 莱斯利·戴格尔
o Ray Denenberg
o 雷·登伯格
o Martin Duerst
o 马丁·杜尔斯特
o Paul Grosso
o 保罗·格罗索
o Sandro Hawke
o 桑德罗·霍克
o Renato Iannella
o 雷纳托·伊安内拉
o Graham Klyne
o 格雷厄姆·克莱恩
o Larry Masinter
o 拉里·马辛特
o Michael Mealling
o 迈克尔·米林
o Mark Needleman
o 马克·莱德曼
o Norman Walsh
o 诺曼·沃尔什
References
工具书类
[1] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.
[1] Petke，R.和I.King，“URL方案名称的注册程序”，BCP 35，RFC 2717，1999年11月。
[2] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke, "Guidelines for new URL Schemes", RFC 2718, November 1999.
[2] Masinter，L.，Alvestrand，H.，Zigmond，D.和R.Petke，“新URL方案指南”，RFC 2718，1999年11月。
[3] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[3] Moats，R.，“IETF文档的URN名称空间”，RFC 2648，1999年8月。
[4] Mealling, M., "The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations", RFC 3043, January 2001.
[4] Mealling，M.，“网络解决方案个人互联网名称（PIN）：个人和组织的URN名称空间”，RFC3043，2001年1月。
[5] Rozenfeld, S., "Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace", RFC 3044, January 2001.
[5] Rozenfeld，S.，“在ISSN-URN名称空间中将ISSN（国际序列号）用作URN（统一资源名）”，RFC 3044，2001年1月。
[6] Mealling, M., "A URN Namespace of Object Identifiers", RFC 3061, February 2001.
[6] Mealling，M.“对象标识符的URN名称空间”，RFC 3061，2001年2月。
[7] Coates, A., Allen, D. and D. Rivers-Moore, "URN Namespace for NewsML Resources", RFC 3085, March 2001.
[7] Coates，A.，Allen，D.和D.Rivers Moore，“NewsML资源的URN名称空间”，RFC 30852001年3月。
[8] Best, K. and N. Walsh, "A URN Namespace for OASIS", RFC 3121, June 2001.
[8] 贝斯特，K.和N.沃尔什，“绿洲的瓮名称空间”，RFC31212001年6月。
[9] Best, K. and N. Walsh, "A URN Namespace for XML.org", RFC 3120, June 2001.
[9] Best，K.和N.Walsh，“XML.org的URN名称空间”，RFC31202001年6月。
[10] Walsh, N., Cowan, J. and P. Grosso, "A URN Namespace for Public Identifiers", RFC 3151, August 2001.
[10] Walsh，N.，Cowan，J.和P.Grosso，“公共标识符的URN名称空间”，RFC3512001年8月。
[11] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "URN Namespace Definition Mechanisms", BCP 33, RFC 2611, June 1999.
[11] Daigle，L.，van Gulik，D.，Iannella，R.和P.Faltstrom，“URN名称空间定义机制”，BCP 33，RFC 2611，1999年6月。
[12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[12] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[13] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998.
[13] Sollins，K.，“统一资源名称解析的体系结构原则”，RFC 2276，1998年1月。
[14] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[14] 菲尔丁，R.，盖蒂斯，J.，莫格尔，J.，尼尔森，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[15] Hakala, J. and H. Walravens, "Using International Standard Book Numbers as Uniform Resource Names", RFC 3187, October 2001.
[15] Hakala，J.和H.Walravens，“使用国际标准书号作为统一资源名称”，RFC 3187，2001年10月。
[16] Hakala, J., "Using National Bibliography Numbers as Uniform Resource Names", RFC 3188, October 2001.
[16] Hakala，J.，“使用国家书目编号作为统一资源名称”，RFC 3188，2001年10月。
Authors' Addresses
作者地址
Michael Mealling VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 US
Michael Mealling VeriSign，Inc.美国弗吉尼亚州斯特林Ridgetop Circle 21345邮编20166
EMail: michael@verisignlabs.com
EMail: michael@verisignlabs.com
Ray Denenberg Library of Congress Washington, DC 20540 US
美国国会图书馆华盛顿哥伦比亚特区20540
EMail: rden@loc.gov
EMail: rden@loc.gov
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。