Network Working Group L. Daigle
Request for Comments: 3406 Thinking Cat Enterprises
BCP: 66 D.W. van Gulik
Obsoletes: 2611 WebWeaving
Category: Best Current Practice R. Iannella
IPR Systems
P. Faltstrom
Cisco
October 2002
Network Working Group L. Daigle
Request for Comments: 3406 Thinking Cat Enterprises
BCP: 66 D.W. van Gulik
Obsoletes: 2611 WebWeaving
Category: Best Current Practice R. Iannella
IPR Systems
P. Faltstrom
Cisco
October 2002
Uniform Resource Names (URN) Namespace Definition Mechanisms
统一资源名称（URN）命名空间定义机制
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document lays out general definitions of and mechanisms for establishing Uniform Resource Names (URN) "namespaces". The URN WG has defined a syntax for URNs in RFC 2141, as well as some proposed mechanisms for their resolution and use in Internet applications in RFC 3401 and RFC 3405. The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed in RFC 2288.
本文档列出了建立统一资源名称（URN）“名称空间”的一般定义和机制。URN工作组在RFC 2141中定义了URN的语法，并在RFC 3401和RFC 3405中为其解析和在Internet应用程序中使用提出了一些机制。整体基于URN结构中单个“名称空间”的概念。除了概念验证名称空间外，RFC 2288还讨论了URN中现有标识符的使用。
Table of Contents
目录
1.0 Introduction ................................................. 2
2.0 What is a URN Namespace? ..................................... 3
3.0 URN Namespace (Registration) Types ........................... 3
3.1 Experimental Namespaces ..................................... 4
3.2 Informal Namespaces ......................................... 4
3.3 Formal Namespaces ........................................... 4
4.0 URN Namespace Registration, Update, and NID Assignment
Process ..................................................... 6
4.1 Experimental ................................................ 6
4.2 Informal .................................................... 6
4.3 Formal ...................................................... 7
5.0 Security Considerations ..................................... 9
1.0 Introduction ................................................. 2
2.0 What is a URN Namespace? ..................................... 3
3.0 URN Namespace (Registration) Types ........................... 3
3.1 Experimental Namespaces ..................................... 4
3.2 Informal Namespaces ......................................... 4
3.3 Formal Namespaces ........................................... 4
4.0 URN Namespace Registration, Update, and NID Assignment
Process ..................................................... 6
4.1 Experimental ................................................ 6
4.2 Informal .................................................... 6
4.3 Formal ...................................................... 7
5.0 Security Considerations ..................................... 9
6.0 IANA Considerations ......................................... 9
7.0 References .................................................. 9
Appendix A -- URN Namespace Definition Template ................. 11
Appendix B -- Illustration ...................................... 15
B.1 Example Template ............................................ 15
B.2 Registration steps in practice .............................. 17
Appendix C -- Changes from RFC 2611 ............................. 18
C.1 Detailed Document Changes ................................... 19
Authors' Addresses .............................................. 21
Full Copyright Statement ........................................ 22
6.0 IANA Considerations ......................................... 9
7.0 References .................................................. 9
Appendix A -- URN Namespace Definition Template ................. 11
Appendix B -- Illustration ...................................... 15
B.1 Example Template ............................................ 15
B.2 Registration steps in practice .............................. 17
Appendix C -- Changes from RFC 2611 ............................. 18
C.1 Detailed Document Changes ................................... 19
Authors' Addresses .............................................. 21
Full Copyright Statement ........................................ 22
Uniform Resource Names (URNs) are resource identifiers with the specific requirements for enabling location independent identification of a resource, as well as longevity of reference. URNs are part of the larger Uniform Resource Identifier (URI) family [RFC3305] with the specific goal of providing persistent naming of resources.
统一资源名称（URN）是资源标识符，具有实现资源位置独立标识以及引用寿命的特定要求。URN是更大的统一资源标识符（URI）系列[RFC3305]的一部分，其具体目标是提供资源的持久命名。
There are 2 assumptions that are key to this document:
本文件有两个关键假设：
Assumption #1:
假设#1：
Assignment of a URN is a managed process.
URN的分配是一个托管过程。
I.e., not all strings that conform to URN syntax are necessarily valid URNs. A URN is assigned according to the rules of a particular namespace (in terms of syntax, semantics, and process).
也就是说，并非所有符合URN语法的字符串都必须是有效的URN。URN是根据特定名称空间的规则（在语法、语义和过程方面）分配的。
Assumption #2:
假设2：
The space of URN namespaces is managed.
URN名称空间的空间是受管理的。
I.e., not all syntactically correct URN namespaces (per the URN syntax definition) are valid URN namespaces. A URN namespace must have a recognized definition in order to be valid.
也就是说，并非所有语法正确的URN命名空间（根据URN语法定义）都是有效的URN命名空间。URN命名空间必须具有可识别的定义才能有效。
The purpose of this document is to outline a mechanism and provide a template for explicit namespace definition, as well as provide the mechanism for associating an identifier (called a "Namespace ID", or NID) which is registered with the Internet Assigned Numbers Authority (IANA).
本文档的目的是概述一种机制，并为显式命名空间定义提供模板，以及提供与在Internet分配号码管理局（IANA）注册的标识符（称为“命名空间ID”或NID）关联的机制。
Note that this document restricts itself to the description of processes for the creation of URN namespaces. If "resolution" of any so-created URN identifiers is desired, a separate process of registration in a global NID directory, such as that provided by the
请注意，本文档仅限于描述创建URN命名空间的过程。如果需要“解析”任何这样创建的URN标识符，则需要在全局NID目录中进行单独的注册过程，如
DDDS system [RFC3401], is necessary. See [RFC3405] for information on obtaining registration in the DDDS global NID directory.
DDDS系统[RFC3401]是必需的。有关在DDDS全局NID目录中获得注册的信息，请参阅[RFC3405]。
For the purposes of URNs, a "namespace" is a collection of uniquely-assigned identifiers. That is, the identifiers are not ever assigned to more than 1 resource, nor are they ever re-assigned to a different resource. A single resource, however, may have more than one URN assigned to it for different purposes. A URN namespace itself has an identifier in order to:
就URN而言，“名称空间”是唯一分配的标识符的集合。也就是说，标识符从未分配给超过1个资源，也从未重新分配给不同的资源。但是，单个资源可能有多个URN分配给它用于不同的目的。URN命名空间本身具有标识符，以便：
- ensure global uniqueness of URNs - (where desired) provide a cue for the structure of the identifier
- 确保URN的全局唯一性-（如果需要）为标识符的结构提供提示
For example, many identifier systems may use strings of numbers as identifiers (e.g., ISBN, ISSN, phone numbers). It is conceivable that there might be some numbers that are valid identifiers in two different established identifier systems. Using different designators for the two collections ensures that no two URNs will be the same for different resources (since each collection is required to uniquely assign each identifier).
例如，许多标识符系统可以使用数字串作为标识符（例如，ISBN、ISSN、电话号码）。可以想象，在两个不同的已建立标识符系统中，可能存在一些作为有效标识符的数字。对两个集合使用不同的标识符可确保对于不同的资源，没有两个URN是相同的（因为每个集合都需要唯一地分配每个标识符）。
The development of an identifier structure, and thereby a collection of identifiers, is a process that is inherently dependent on the requirements of the community defining the identifier, how they will be assigned, and the uses to which they will be put. All of these issues are specific to the individual community seeking to define a namespace (e.g., publishing community, association of booksellers, protocol developers, etc); they are beyond the scope of the IETF URN work.
标识符结构的开发，以及标识符集合的开发，是一个内在地依赖于定义标识符的社区的需求、如何分配标识符以及标识符的用途的过程。所有这些问题都是特定于寻求定义名称空间的单个社区（例如，发布社区、书商协会、协议开发人员等）；它们超出了IETF URN工作的范围。
This document outlines the processes by which a collection of identifiers satisfying certain constraints (uniqueness of assignment, etc) can become a bona fide URN namespace by obtaining a NID. In a nutshell, a template for the definition of the namespace is completed for deposit with IANA, and a NID is assigned. The details of the process and possibilities for NID strings are outlined below.
本文档概述了通过获取NID，满足某些约束（分配的唯一性等）的标识符集合可以成为真正的URN命名空间的过程。简言之，名称空间定义的模板已完成，存放在IANA中，并分配了NID。NID字符串的过程细节和可能性概述如下。
There are three categories of URN namespaces defined here, distinguished by expected level of service and required procedures for registration. Registration processes for each of these namespace types are given in Section 4.0.
这里定义了三类URN名称空间，根据预期的服务级别和注册所需的过程进行区分。第4.0节中给出了每种命名空间类型的注册过程。
These are not explicitly registered with IANA. They take the form:
这些未在IANA明确注册。它们的形式如下：
X-<NID>
X-<NID>
No provision is made for avoiding collision of experimental NIDs; they are intended for use within internal or limited experimental contexts.
没有关于避免实验NID碰撞的规定；它们用于内部或有限的实验环境。
These are fully fledged URN namespaces, with all the rights and requirements associated thereto. Informal namespaces can be registered in global registration services. They are required to uphold the general principles of a well-managed URN namespace -- providing persistent identification of resources, and unique assignment of identifier strings. Informal and formal namespaces (described below) differ in the NID assignment. IANA will assign an alphanumeric NID to registered informal namespaces, per the process outlined in Section 4.0.
这些是成熟的URN名称空间，具有与之相关的所有权利和要求。可以在全局注册服务中注册非正式名称空间。它们需要维护良好管理的URN名称空间的一般原则——提供资源的持久标识和标识符字符串的唯一分配。非正式名称空间和正式名称空间（如下所述）在NID分配方面有所不同。IANA将按照第4.0节概述的流程，为注册的非正式名称空间分配字母数字NID。
A formal namespace may be requested, and IETF review sought, in cases where the publication of the NID proposal and the underlying namespace will provide benefit to some subset of users on the Internet. That is, a formal NID proposal, if accepted, must be functional on and with the global Internet, not limited to users in communities or networks not connected to the Internet. For example, a NID that is meant for naming of physics research is requested. If that NID request required that the user use a proprietary network or service that was not at all open to the general Internet user, then it would make a poor request for a formal NID. The intent is that, while the community of those who may actively use the names assigned within that NID may be small (but no less important), the potential use of names within that NID is open to any user on the Internet.
如果NID提案和基础名称空间的发布将为互联网上的某些用户子集带来好处，则可以请求正式名称空间，并寻求IETF审查。也就是说，正式的NID提案如果被接受，必须在全球互联网上发挥作用，而不仅仅限于社区或未连接到互联网的网络中的用户。例如，需要一个用于物理研究命名的NID。如果该NID请求要求用户使用一个对一般互联网用户完全不开放的专有网络或服务，那么它将对正式NID提出一个糟糕的请求。其目的是，尽管积极使用该NID中指定名称的人的社区可能很小（但同样重要），但该NID中名称的潜在使用对互联网上的任何用户开放。
It is expected that Formal NIDs may be applied to namespaces where some aspects are not fully open. For example, a namespace may make use of a fee-based, privately managed, or proprietary registry for assignment of URNs in the namespace, but it may still provide benefit to some Internet users if the services associated have openly-published access protocols.
预计正式的NID可以应用于某些方面未完全开放的名称空间。例如，名称空间可以使用收费的、私人管理的或专有的注册中心来分配名称空间中的URN，但如果相关服务公开发布了访问协议，则它仍然可以为某些Internet用户提供好处。
In addition to the basic registration information defined in the registration template (in Appendix A), a formal namespace request must be accompanied by documented considerations of the need for a new namespace and of the community benefit from formally establishing the proposed URN namespace.
除了注册模板（附录A）中定义的基本注册信息外，正式的名称空间请求还必须附带对新名称空间的需要以及正式建立提议的URN名称空间所带来的社区利益的书面考虑。
Additionally, since the goal of URNs is to provide persistent identification, some consideration as to the longevity and maintainability of the namespace must be given. The URN WG discussed at length the issue of finding objective measures for predicting (a priori) the continued success of a namespace. No conclusion was reached -- much depends on factors that are completely beyond the technical scope of the namespace. However, the collective experience of the IETF community does contain a wealth of information on technical factors that will prevent longevity of identification. The IESG may elect not to publish a proposed namespace RFC if the IETF community consensus is that it contains technical flaws that will prevent (or seriously impair the possibility of) persistent identification.
此外，由于URN的目标是提供持久性标识，因此必须考虑命名空间的寿命和可维护性。URN工作组详细讨论了寻找预测（先验）名称空间持续成功的客观度量的问题。没有得出任何结论——这在很大程度上取决于完全超出名称空间技术范围的因素。然而，IETF社区的集体经验确实包含了大量有关技术因素的信息，这些技术因素将阻止身份识别的长期性。如果IETF社区一致认为提议的名称空间RFC包含会阻止（或严重损害）持久识别的技术缺陷，IESG可以选择不发布该名称空间RFC。
The kinds of things the URN WG discussed included:
URN工作组讨论的内容包括：
- the organization maintaining the URN namespace should demonstrate stability and the ability to maintain the URN namespace for a long time, and/or it should be clear how the namespace can continue to be usable/useful if the organization ceases to be able to foster it;
- 维护URN名称空间的组织应证明其稳定性和长期维护URN名称空间的能力，和/或应清楚，如果该组织不再能够支持该名称空间，该名称空间如何继续可用/有用；
- it should demonstrate ability and competency in name assignment. This should improve the likelihood of persistence (e.g. to minimize the likelihood of conflicts);
- 应证明其在姓名分配方面的能力和能力。这将提高持久性的可能性（例如，将冲突的可能性降至最低）；
- it should commit to not re-assigning existing names and allowing old names to continue to be valid, even if the owners or assignees of those names are no longer members or customers of that organization. This does not mean that there must be resolution of such names, but that they must not resolve the name to false or stale information, and that they must not be reassigned.
- 它应承诺不重新分配现有名称，并允许旧名称继续有效，即使这些名称的所有者或受让人不再是该组织的成员或客户。这并不意味着必须对这些名称进行解析，但它们不得将名称解析为虚假或陈旧的信息，也不得重新分配这些名称。
These aspects, though hard to quantify objectively, should be considered by organizations/people considering the development of a Formal URN namespace, and they will be kept in mind when evaluating the technical merits of any proposed Formal namespace.
这些方面虽然很难客观地量化，但考虑开发正式URN名称空间的组织/人员应该考虑这些方面，并且在评估任何提议的正式名称空间的技术优点时，应该记住这些方面。
Different levels of disclosure are expected/defined for namespaces. According to the level of open-forum discussion surrounding the disclosure, a URN namespace may be assigned or may request a particular identifier. The "IANA Considerations" document [RFC2434] suggests the need to specify update mechanisms for registrations -- who is given the authority to do so, from time to time, and what are the processes. Since URNs are meant to be persistently useful, few (if any) changes should be made to the structural interpretation of URN strings (e.g., adding or removing rules for lexical equivalence that might affect the interpretation of URN IDs already assigned). However, it may be important to introduce clarifications, expand the list of authorized URN assigners, etc, over the natural course of a namespace's lifetime. Specific processes are outlined below.
名称空间需要/定义不同级别的公开。根据围绕本公开的公开论坛讨论的级别，可以分配URN名称空间或请求特定标识符。“IANA注意事项”文件[RFC2434]建议需要指定注册的更新机制——不时授予谁这样做的权限，以及流程是什么。由于URN是持久有用的，因此应该对URN字符串的结构解释进行少量（如果有）更改（例如，添加或删除可能影响已分配URN ID解释的词汇等效规则）。但是，在名称空间生命周期的自然过程中，引入澄清、扩展授权URN分配者的列表等可能很重要。具体过程概述如下。
The official list of registered URN namespaces is maintained by IANA. URN namespace registrations are currently being posted in the anonymous FTP directory:
注册的URN名称空间的正式列表由IANA维护。当前正在匿名FTP目录中发布URN命名空间注册：
http://www.iana.org/assignments/urn-namespaces
http://www.iana.org/assignments/urn-namespaces
See [RFC3232] for the current location of IANA registry.
有关IANA注册表的当前位置，请参阅[RFC3232]。
The registration and maintenance procedures vary slightly from one namespace type (as defined in Section 3.0) to another.
不同名称空间类型（如第3.0节所定义）的注册和维护程序略有不同。
These are not explicitly registered with IANA. They take the form:
这些未在IANA明确注册。它们的形式如下：
X-<NID>
X-<NID>
No provision is made for avoiding collision of experimental NIDs; they are intended for use within internal or limited experimental contexts.
没有关于避免实验NID碰撞的规定；它们用于内部或有限的实验环境。
As there is no registration, no registration maintenance procedures are needed.
由于没有注册，因此不需要注册维护程序。
These are registered with IANA and are assigned a number sequence as an identifier, in the format:
它们在IANA注册，并被分配一个编号序列作为标识符，格式如下：
"urn-" <number>
“urn-”<number>
where <number> is chosen by the IANA on a First Come First Served basis (see [RFC2434]).
其中，<number>由IANA根据先到先得的原则选择（见[RFC2434]）。
Registrants should send a copy of the registration template (see Appendix A), duly completed, to:
注册人应将正式填写的注册模板副本（见附录a）发送至：
urn-nid@apps.ietf.org
瓮-nid@apps.ietf.org
and allow for a 2 week discussion period for clarifying the expression of the registration information and suggestions for technical improvements to the namespace proposal.
并留出两周的讨论时间，以澄清注册信息的表达，以及对名称空间提案的技术改进建议。
After suggestions for clarification of the registration information have been incorporated, the template may be submitted for assignment of a NID to:
纳入注册信息澄清建议后，可将模板提交给以下机构，以分配NID：
iana@iana.org
iana@iana.org
The only restrictions on <number> are that it consist strictly of digits and that it not cause the NID to exceed length limitations outlined in the URN syntax ([RFC2141]).
<number>的唯一限制是它严格由数字组成，并且不会导致NID超过URN语法（[RFC2141]）中概述的长度限制。
Registrations may be updated by the original registrant, or an entity designated by the registrant, by updating the registration template, submitting it to the discussion list for a further 2 week discussion period, and finally resubmitting it to IANA, as described above.
如上文所述，原始注册人或注册人指定的实体可通过更新注册模板，将其提交至讨论列表再进行2周的讨论，并最终将其重新提交给IANA来更新注册。
Formal NIDs are assigned via IETF Consensus, as defined in [RFC2434]:
按照[RFC2434]中的定义，通过IETF共识分配正式NID：
"IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists)."
“IETF共识-通过IETF共识流程分配新值。具体而言，通过IESG批准的RFC进行新分配。通常情况下，IESG将寻求适当人员（如存在相关工作组）对预期分配的意见。”
Thus, the Formal NID application is made via publication of an RFC through standard IETF processes. The RFC need not be standards-track, but it will be subject to IESG review and acceptance pursuant to the guidelines written here (as well as standard RFC publication guidelines). The template defined in Appendix A may be included as part of an RFC defining some other aspect of the namespace, or it may be put forward as an RFC in its own right. The proposed template should be sent to the:
因此，正式的NID应用程序是通过标准IETF流程发布RFC来实现的。RFC无需为标准轨道，但将根据此处编写的指南（以及标准RFC出版指南）接受IESG的审查和验收。附录A中定义的模板可以作为RFC的一部分包含，RFC定义了名称空间的其他方面，也可以作为RFC单独提出。建议的模板应发送至：
urn-nid@apps.ietf.org
瓮-nid@apps.ietf.org
mailing list to allow for a two week discussion period for clarifying the expression of the registration information, before the IESG reviews the document.
邮件列表，以便在IESG审查文件之前，有两周的讨论时间澄清注册信息的表达。
The RFC must include a "Namespace Considerations" section, which outlines the perceived need for a new namespace (i.e., where existing namespaces fall short of the proposer's requirements).
RFC必须包括一个“名称空间注意事项”部分，该部分概述了对新名称空间的感知需求（即，现有名称空间不能满足投标人的要求）。
Considerations might include:
考虑因素可能包括：
- URN assignment procedures - URN resolution/delegation - type of resources to be identified - type of services to be supported
- URN分配程序-URN解决/委派-待识别的资源类型-待支持的服务类型
NOTE: It is expected that more than one namespace may serve the same "functional" purpose; the intent of the "Namespace Considerations" section is to provide a record of the proposer's "due diligence" in exploring existing possibilities, for the IESG's consideration.
注意：预期不止一个名称空间可以用于相同的“功能”目的；“名称空间考虑”部分的目的是提供投标人在探索现有可能性时的“尽职调查”记录，供IESG考虑。
The RFC must also include a "Community Considerations" section, which indicates the dimensions upon which the proposer expects its community to be able to benefit by publication of this namespace as well as how a general Internet user will be able to use the space if they care to do so. Potential considerations include:
RFC还必须包括一个“社区注意事项”部分，该部分指出了投标人希望其社区能够通过公布该名称空间而受益的方面，以及如果普通互联网用户愿意，他们将如何使用该空间。可能的考虑因素包括：
- open assignment and use of identifiers within the namespace - open operation of resolution servers for the namespace (server) - creation of software that can meaningfully resolve and access services for the namespace (client)
- 名称空间内标识符的开放分配和使用-名称空间解析服务器的开放操作（服务器）-创建可以有意义地解析和访问名称空间服务的软件（客户端）
The RFC must include an "IANA Considerations" section, indicating that the document includes a URN NID registration that is to be entered into the IANA registry of URN NIDs.
RFC必须包括一个“IANA注意事项”部分，表明该文件包括一个URN NID注册，该注册将输入URN NID的IANA注册。
A particular NID string is requested, and is assigned by IETF consensus (as defined in [RFC2434]), with the additional constraints that the NID string must:
请求特定NID字符串，并由IETF consensus（如[RFC2434]中所定义）分配，NID字符串必须满足以下附加约束：
- not be an already-registered NID - not start with "x-" (see Type I above) - not start with "urn-" (see Type II above) - not start with "XY-", where XY is any combination of 2 ASCII letters (see NOTE, below) - be more than 2 letters long
- 不是已注册的NID-不以“x-”开头（见上文类型I）-不以“urn-”开头（见上文类型II）-不以“XY-”开头，其中XY是2个ASCII字母的任意组合（见下文注释）-长度超过2个字母
NOTE: ALL two-letter combinations, and two-letter combinations followed by "-" and any sequence of valid NID characters are reserved for potential use as countrycode-based NIDs for eventual national registrations of URN namespaces. The definition and scoping of rules for allocation of responsibility for such namespaces is beyond the scope of this document.
注：保留所有两个字母组合、后跟“-”的两个字母组合以及任何有效NID字符序列，以作为基于国家代码的NID，用于最终的URN名称空间国家注册。此类名称空间责任分配规则的定义和范围超出了本文档的范围。
Registrations may be revised by updating the RFC through standard IETF RFC update processes (see [RFC2606] for a discussion of IETF process). In any case, a revised document, in the form of a new Internet-Draft, must be published, and the proposed updated template must be circulated on the urn-nid discussion list, allowing for a 2 week review period before pursuing publication of the new RFC document.
可以通过标准IETF RFC更新过程更新RFC来修改注册（有关IETF过程的讨论，请参见[RFC2606]）。在任何情况下，必须以新的互联网草案的形式发布修订后的文件，并且必须在urn nid讨论列表上分发建议的更新模板，允许在发布新的RFC文件之前有2周的审查期。
This document largely focuses on providing mechanisms for the declaration of public information. Nominally, these declarations should be of relatively low security profile, however there is always the danger of "spoofing" and providing mis-information. Information in these declarations should be taken as advisory.
本文件主要侧重于提供公布公共信息的机制。名义上，这些声明应该具有相对较低的安全性，但是始终存在“欺骗”和提供错误信息的危险。这些声明中的信息应被视为咨询信息。
This document outlines the processes for registering URN namespaces, and has implications for the IANA in terms of registries to be maintained. In all cases, the IANA should assign the appropriate NID (informal or formal), as described above, once an IESG-designated expert has confirmed that the requisite registration process steps have been completed. This document defines processes to replace those outlined in [RFC2611].
本文档概述了注册URN名称空间的过程，并就要维护的注册表对IANA具有影响。在所有情况下，一旦IESG指定的专家确认必要的注册流程步骤已经完成，IANA应指派适当的NID（非正式或正式），如上所述。本文件定义了替代[RFC2611]中概述的流程。
[ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange formats - Information interchange - Representation of dates and times"
[ISO8601]ISO 8601:1988（E），“数据元素和交换格式-信息交换-日期和时间的表示”
[RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994.
[RFC1737]Sollins，K.和L.Masinter，“统一资源名称的功能要求”，RFC 1737，1994年12月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141]Moats，R.，“瓮语法”，RFC 21411997年5月。
[RFC2276] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998.
[RFC2276]Sollins，K.，“统一资源名称解析的架构原则”，RFC 2276，1998年1月。
[RFC2288] Lynch, C., Preston, C. and R. Daniel, "Using Existing Bibliographic Identifiers as Uniform Resource Names", RFC 2288, February 1998.
[RFC2288]Lynch，C.，Preston，C.和R.Daniel，“使用现有书目标识符作为统一资源名”，RFC 2288，1998年2月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2611] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "URN Namespace Definition Mechanisms", RFC 2611, June 1999.
[RFC2611]Daigle，L.，van Gulik，D.，Iannella，R.和P.Faltstrom，“URN命名空间定义机制”，RFC 26111999年6月。
[RFC3232] Reynolds, J, Editor, "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232]Reynolds，J，编辑，“分配号码：RFC 1700被在线数据库取代”，RFC 3232，2002年1月。
[RFC3305] Mealling, M. (Ed.) and R. Denenberg (Ed.), "Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations", RFC 3305, August 2002.
[RFC3305]Mealling，M.（编辑）和R.Denenberg（编辑），“W3C/IETF URI规划联合兴趣小组的报告：统一资源标识符（URI）、URL和统一资源名称（URN）：澄清和建议”，RFC33052002年8月。
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3401]Mealling，M.“动态委托发现系统（DDDS）第一部分：综合DDDS”，RFC 3401，2002年10月。
[RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
[RFC3405]Mealling，M.“动态委托发现系统（DDDS）第五部分：URI.ARPA分配程序”，RFC3405，2002年10月。
Appendix A -- URN Namespace Definition Template
附录A—URN命名空间定义模板
Definition of a URN namespace is accomplished by completing the following information template. Apart from providing a mechanism for disclosing structure of the URN namespace, this information is designed to be useful for
URN命名空间的定义是通过完成以下信息模板来完成的。除了提供一种公开URN名称空间结构的机制外，此信息还可用于
- entities seeking to have a URN assigned in a namespace (if applicable) - entities seeking to provide URN resolvers for a namespace (if applicable)
- 寻求在命名空间中分配URN的实体（如果适用）-寻求为命名空间提供URN解析器的实体（如果适用）
This is particularly important for communities evaluating the possibility of using a portion of an existing URN namespace rather than creating their own.
这对于社区评估使用现有URN名称空间的一部分而不是创建自己的名称空间的可能性尤为重要。
Applications for Formal URN namespaces must also document "Namespace Considerations", "Community Considerations" and "IANA Considerations", as described in Section 4.3.
正式URN名称空间的应用程序还必须记录“名称空间注意事项”、“社区注意事项”和“IANA注意事项”，如第4.3节所述。
Information in the template is as follows:
模板中的信息如下所示：
Namespace ID:
命名空间ID:
Assigned by IANA. In the case of a Formal NID registration, a particular NID string may be requested.
由IANA指派。在正式NID注册的情况下，可能会请求特定的NID字符串。
Registration Information:
注册资料：
This is information to identify the particular version of registration information:
此信息用于识别特定版本的注册信息：
- registration version number: starting with 1, incrementing by 1 with each new version - registration date: date submitted to the IANA, using the format outlined in [ISO8601]:
- 注册版本号：从1开始，每个新版本递增1-注册日期：提交给IANA的日期，使用[ISO8601]中概述的格式：
YYYY-MM-DD
YYYY-MM-DD
Declared registrant of the namespace: This includes: Registering organization Name Address Designated contact person Name Coordinates (at least one of: e-mail, phone, postal address)
名称空间的声明注册人：这包括：注册组织名称地址指定联系人名称坐标（至少一个：电子邮件、电话、邮政地址）
Declaration of syntactic structure:
句法结构声明：
This section should outline any structural features of identifiers in this namespace. At the very least, this description may be used to introduce terminology used in other sections. This structure may also be used for determining realistic caching/shortcuts approaches; suitable caveats should be provided. If there are any specific character encoding rules (e.g., which character should always be used for single-quotes), these should be listed here.
本节应概述此命名空间中标识符的任何结构特征。至少，本说明可用于介绍其他章节中使用的术语。该结构还可用于确定实际的缓存/快捷方式方法；应提供适当的注意事项。如果有任何特定的字符编码规则（例如，哪个字符应始终用于单引号），则应在此处列出这些规则。
Answers might include, but are not limited to:
答案可能包括但不限于：
- the structure is opaque (no exposition) - a regular expression for parsing the identifier into components, including naming authorities
- 该结构是不透明的（没有公开）——用于将标识符解析为组件（包括命名权限）的正则表达式
Relevant ancillary documentation:
相关辅助文件：
This section should list any RFCs, standards, or other published documentation that defines or explains all or part of the namespace structure.
本节应列出定义或解释全部或部分命名空间结构的所有RFC、标准或其他已发布文档。
Answers might include, but are not limited to:
答案可能包括但不限于：
- RFCs outlining syntax of the namespace - Other of the defining community's (e.g., ISO) documents outlining syntax of the identifiers in the namespace - Explanatory material introducing the namespace
- RFC概述名称空间的语法-定义社区的其他（如ISO）文档概述名称空间中标识符的语法-介绍名称空间的解释性材料
Identifier uniqueness considerations:
标识符唯一性注意事项：
This section should address the requirement that URN identifiers be assigned uniquely -- they are assigned to at most one resource, and are not reassigned.
本节应讨论唯一分配URN标识符的要求——它们最多分配给一个资源，而不是重新分配。
(Note that the definition of "resource" is fairly broad; for example, information on "Today's Weather" might be considered a single resource, although the content is dynamic.)
（请注意，“资源”的定义相当宽泛；例如，“今天的天气”信息可能被视为单一资源，尽管内容是动态的。）
Possible answers include, but are not limited to:
可能的答案包括但不限于：
- exposition of the structure of the identifiers, and partitioning of the space of identifiers amongst assignment authorities which are individually responsible for respecting uniqueness rules - identifiers are assigned sequentially - information is withheld; the namespace is opaque
- 说明标识符的结构，以及分配机构之间标识符空间的划分，分配机构单独负责遵守唯一性规则-标识符按顺序分配-信息被保留；名称空间是不透明的
Identifier persistence considerations:
标识符持久性注意事项：
Although non-reassignment of URN identifiers ensures that a URN will persist in identifying a particular resource even after the "lifetime of the resource", some consideration should be given to the persistence of the usability of the URN. This is particularly important in the case of URN namespaces providing global resolution.
尽管不重新分配URN标识符可确保URN即使在“资源生命周期”之后仍能持续标识特定资源，但仍应考虑URN可用性的持续性。对于提供全局解析的URN命名空间，这一点尤为重要。
Possible answers include, but are not limited to:
可能的答案包括但不限于：
- quality of service considerations
- 服务质素考虑
Process of identifier assignment:
标识符分配过程：
This section should detail the mechanisms and/or authorities for assigning URNs to resources. It should make clear whether assignment is completely open, or if limited, how to become an assigner of identifiers, and/or get one assigned by existing assignment authorities.
本节应详细说明将URN分配给资源的机制和/或权限。应明确转让是否完全开放，或者如果有限，如何成为标识符的转让人，和/或获得现有转让机构的转让。
Answers could include, but are not limited to:
答案可能包括但不限于：
- assignment is completely open, following a particular algorithm - assignment is delegated to authorities recognized by a particular organization (e.g., the Digital Object Identifier Foundation controls the DOI assignment space and its delegation) - assignment is completely closed (e.g., for a private organization)
- 赋值是完全开放的，遵循特定的算法-赋值被委派给特定组织认可的权威机构（例如，数字对象标识符基金会控制DOI分配空间及其委托）-分配完全关闭（例如，对于私有组织）
Process for identifier resolution:
标识符解析过程：
If a namespace is intended to be accessible for global resolution, it must be registered in an RDS (Resolution Discovery System, see [RFC2276]) such as DDDS. Resolution then proceeds according to standard URI resolution processes, and the mechanisms of the RDS. What this section should outline is the requirements for becoming a recognized resolver of URNs in this namespace (and being so-listed in the RDS registry).
如果一个名称空间打算用于全局解析，则必须在RDS（解析发现系统，请参见[RFC2276]）中注册，如DDDS。然后根据标准URI解析过程和RDS的机制进行解析。本节应概述成为此名称空间中的URN的公认解析器的要求（并在RDS注册表中列出）。
Answers may include, but are not limited to:
答案可能包括但不限于：
- the namespace is not listed with an RDS; this is not relevant - resolution mirroring is completely open, with a mechanism for updating an appropriate RDS - resolution is controlled by entities to which assignment has been delegated
- 名称空间未与RDS一起列出；这与此无关-解决方案镜像是完全开放的，具有更新适当RDS的机制-解决方案由已委派任务的实体控制
Rules for Lexical Equivalence:
词汇对等规则：
If there are particular algorithms for determining equivalence between two identifiers in the underlying namespace (hence, in the URN string itself), rules can be provided here.
如果有特定的算法来确定基础命名空间（因此，在URN字符串本身中）中两个标识符之间的等价性，那么可以在这里提供规则。
Some examples include:
一些例子包括：
- equivalence between hyphenated and non-hyphenated groupings in the identifier string - equivalence between single-quotes and double-quotes - Namespace-defined equivalences between specific characters, such as "character X with or without diacritic marks".
- 标识符字符串中连字符和非连字符分组之间的等效性-单引号和双引号之间的等效性-特定字符之间命名空间定义的等效性，例如“带或不带变音符号的字符X”。
Note that these are not normative statements for any kind of best practice for handling equivalences between characters; they are statements limited to reflecting the namespace's own rules.
请注意，这些不是处理字符之间等价关系的任何类型最佳实践的规范性陈述；它们是仅限于反映名称空间自身规则的语句。
Conformance with URN Syntax:
符合URN语法：
This section should outline any special considerations required for conforming with the URN syntax. This is particularly applicable in the case of legacy naming systems that are used in the context of URNs.
本节应概述符合URN语法所需的任何特殊注意事项。这尤其适用于在URN上下文中使用的传统命名系统。
For example, if a namespace is used in contexts other than URNs, it may make use of characters that are reserved in the URN syntax.
例如，如果命名空间用于URN以外的上下文，则它可能会使用URN语法中保留的字符。
This section should flag any such characters, and outline necessary mappings to conform to URN syntax. Normally, this will be handled by hex encoding the symbol.
本节应标记任何此类字符，并概述符合URN语法的必要映射。通常，这将通过十六进制编码符号来处理。
For example, see the section on SICIs in [RFC2288].
例如，请参见[RFC2288]中有关SICIs的部分。
Validation mechanism:
验证机制：
Apart from attempting resolution of a URN, a URN namespace may provide mechanisms for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN. There are 2 issues here: 1) users should not "guess" URNs in a namespace; 2) when the URN namespace is based on an existing identifier system, it may not be the case that all the existing identifiers are assigned on Day 0. The reasonable expectation is that the resource associated with each resulting URN is somehow related to the thing identified by the original identifier system, but those resources may not exist for each original identifier. For example, even if a telephone number-based URN namespace was created, it is not clear that all telephone numbers would
除了尝试解析URN外，URN命名空间还可以提供“验证”URN的机制——即确定给定字符串当前是否是有效分配的URN。这里有两个问题：1）用户不应该“猜测”命名空间中的URN；2） 当URN命名空间基于现有标识符系统时，可能不会在第0天分配所有现有标识符。合理的期望是，与每个结果URN相关联的资源以某种方式与原始标识符系统标识的对象相关，但是对于每个原始标识符，这些资源可能不存在。例如，即使创建了一个基于电话号码的URN名称空间，也不清楚是否所有电话号码都可以
immediately become "valid" URNs, that could be resolved using whatever mechanisms are described as part of the namespace registration.
立即成为“有效”URN，可以使用名称空间注册中描述的任何机制来解析该URN。
Validation mechanisms might be:
验证机制可能是：
- a syntax grammar - an on-line service - an off-line service
- 语法-在线服务-离线服务
Scope:
范围：
This section should outline the scope of the use of the identifiers in this namespace. Apart from considerations of private vs. public namespaces, this section is critical in evaluating the applicability of a requested NID. For example, a namespace claiming to deal in "social security numbers" should have a global scope and address all social security number structures (unlikely). On the other hand, at a national level, it is reasonable to propose a URN namespace for "this nation's social security numbers".
本节应概述此命名空间中标识符的使用范围。除了考虑私有名称空间和公共名称空间之外，本节对于评估所请求NID的适用性至关重要。例如，一个声称处理“社会安全号码”的名称空间应该具有全局范围，并处理所有社会安全号码结构（不太可能）。另一方面，在国家一级，为“这个国家的社会保障号码”提议一个URN名称空间是合理的。
Appendix B -- Illustration
附录B——说明
The following example is provided for the purposes of illustrating the URN NID template described in Appendix A. Although it is based on a hypothetical "generic Internet namespace" that has been discussed informally within the URN WG, there are still technical and infrastructural issues that would have to be resolved before such a namespace could be properly and completely described.
提供以下示例是为了说明附录A中所述的URN NID模板。尽管它基于一个假设的“通用互联网名称空间”，该名称空间已在URN工作组中进行了非正式讨论，在正确和完整地描述这样一个名称空间之前，仍然需要解决一些技术和基础设施问题。
Namespace ID:
命名空间ID:
To be assigned
分配
Registration Information:
注册资料：
Version 1 Date: <when submitted>
版本1日期：<提交时>
Declared registrant of the namespace:
已声明命名空间的注册人：
Name: Thinking Cat Enterprises Address: 1 ThinkingCat Way Trupville, NewCountry Contact: L. Daigle E-mail: leslie@thinkingcat.com
姓名：Thinking Cat企业地址：1 Thinking Cat Way Trupville，NewCountry联系人：L.Daigle电子邮件：leslie@thinkingcat.com
Declaration of structure:
结构声明：
The identifier structure is as follows:
标识符结构如下所示：
URN:<assigned number>:<FQDN>:<assigned string>
URN:<assigned number>:<FQDN>:<assigned string>
where FQDN is a fully-qualified domain name, and the assigned string is conformant to URN syntax requirements.
其中FQDN是一个完全限定的域名，分配的字符串符合URN语法要求。
Relevant ancillary documentation:
相关辅助文件：
Definition of domain names, found in:
域名的定义，见：
P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", RFC 1035, November 1987.
P.Mockapetris，“域名-实现和规范”，RFC 10351987年11月。
Identifier uniqueness considerations:
标识符唯一性注意事项：
Uniqueness is guaranteed as long as the assigned string is never reassigned for a given FQDN, and that the FQDN is never reassigned.
只要从未为给定FQDN重新分配分配的字符串，并且从未重新分配FQDN，就可以保证唯一性。
N.B.: operationally, there is nothing that prevents a domain name from being reassigned; indeed, it is not an uncommon occurrence. This is one of the reasons that this example makes a poor URN namespace in practice, and is therefore not seriously being proposed as it stands.
注意：在操作上，没有任何东西可以阻止域名被重新分配；事实上，这种情况并不罕见。这是该示例在实践中使用较差的URN名称空间的原因之一，因此目前没有认真地提出。
Identifier persistence considerations:
标识符持久性注意事项：
Persistence of identifiers is dependent upon suitable delegation of resolution at the level of "FQDN"s, and persistence of FQDN assignment.
标识符的持久性取决于“FQDN”级别上适当的解析委派以及FQDN分配的持久性。
Same note as above.
同上。
Process of identifier assignment:
标识符分配过程：
Assignment of these URNs is delegated to individual domain name holders (for FQDNs). The holder of the FQDN registration is required to maintain an entry (or delegate it) in the DDDS. Within each of these delegated name partitions, the string may be assigned per local requirements.
将这些URN的分配委派给各个域名持有者（对于FQDN）。FQDN注册持有人需要在DDDS中维护（或委托）条目。在每个委托名称分区中，可以根据本地需求分配字符串。
e.g., urn:<assigned number>:thinkingcat.com:001203
e.g., urn:<assigned number>:thinkingcat.com:001203
Process for identifier resolution:
标识符解析过程：
Domain name holders are responsible for operating or delegating resolution servers for the FQDN in which they have assigned URNs.
域名持有者负责为其已分配URN的FQDN操作或委派解析服务器。
Rules for Lexical Equivalence:
词汇对等规则：
FQDNs are case-insensitive. Thus, the portion of the URN
FQDN不区分大小写。因此，骨灰盒的部分
urn:<assigned number>:<FQDN>:
urn:<assigned number>：<FQDN>：
is case-insensitive for matches. The remainder of the identifier must be considered case-sensitive.
匹配项不区分大小写。标识符的其余部分必须视为区分大小写。
Conformance with URN Syntax:
符合URN语法：
No special considerations.
没有特别考虑。
Validation mechanism:
验证机制：
None specified.
没有具体说明。
Scope:
范围：
Global.
全球的
The key steps for registration of informal or formal namespaces typically play out as follows:
注册非正式或正式名称空间的关键步骤通常如下所示：
Informal NID:
非正式NID：
1. Complete the registration template. This may be done as part of an Internet-Draft.
1. 完成注册模板。这可以作为互联网草案的一部分来完成。
2. Communicate the registration template to urn-nid@apps.ietf.org for technical review -- as a published I-D, or text e-mail message containing the template.
2. 将注册模板传达给urn-nid@apps.ietf.org用于技术审查--作为已发布的ID，或包含模板的文本电子邮件。
3. Update the registration template as necessary from comments, and repeat steps 2 and 3 as necessary.
3. 必要时根据注释更新注册模板，必要时重复步骤2和3。
4. Once comments have been addressed (and the review period has expired), send a request to IANA with the revised registration template.
4. 一旦意见得到解决（且审查期已过），请向IANA发送一份请求，并附上修订后的注册模板。
Formal NID:
正式NID：
1. Write an Internet-Draft describing the namespace and include the registration template, duly completed. Be sure to include "Namespace Considerations", "Community Considerations" and "IANA Considerations" sections, as described in Section 4.3.
1. 写一份描述名称空间的互联网草稿，并包括正式完成的注册模板。确保包括“名称空间注意事项”、“社区注意事项”和“IANA注意事项”部分，如第4.3节所述。
2. Send the Internet-Draft to the I-D editor, and send a copy to urn-nid@apps.ietf.org for technical review.
2. 将互联网草稿发送给I-D编辑，并将副本发送给urn-nid@apps.ietf.org进行技术审查。
3. Update the Internet-Draft as necessary from comments, and repeat steps 2 and 3 as needed.
3. 必要时根据评论更新互联网草稿，并根据需要重复步骤2和3。
4. Send a request to the IESG to publish the I-D as an RFC. The IESG may request further changes (published as I-D revisions) and/or direct discussion to designated working groups, area experts, etc.
4. 向IESG发送请求，将I-D发布为RFC。IESG可要求进一步修改（发布为I-D修订版）和/或直接与指定工作组、领域专家等讨论。
5. If the IESG approves the document for publication as an RFC, send a request to IANA to register the requested NID.
5. 如果IESG批准该文件作为RFC发布，则向IANA发送请求，以注册请求的NID。
Appendix C -- Changes from RFC 2611
附录C——对RFC 2611的变更
This revision of [RFC2611] adds more detail describing the process of registering a URN namespace identifier (in terms of mechanical steps).
[RFC2611]的这一修订版添加了更多详细信息，描述了注册URN命名空间标识符的过程（以机械步骤的形式）。
This version of the document also separates the process (mechanics) from the discussion of the requirements for namespaces, attempting to make the latter as objective as possible.
本版本的文档还将过程（机制）与名称空间需求的讨论分开，试图使后者尽可能客观。
Throughout the document, references have been updated to the current versions of the DDDS and related documentation (which collectively obsolete [RFC2168] and related drafts).
在本文件中，对DDDS和相关文件的当前版本进行了更新（这些文件与[RFC2168]和相关草案一起过时）。
Added table of contents
新增目录
Section 2
第二节
Clarified the definition of a URN namespace, the uniqueness of assignment, and that a single resource may have more than one identifier associated with it.
阐明了URN命名空间的定义、赋值的唯一性以及单个资源可能有多个与其关联的标识符。
Clarified the "number example" -- that the same string may appear in 2 different namespaces, and be applied to different resources. Originally used ISBN/ISSN example, but structurally this is not possible.
澄清了“数字示例”——相同的字符串可能出现在两个不同的名称空间中，并应用于不同的资源。最初使用ISBN/ISSN示例，但从结构上讲，这是不可能的。
Section 3 (new)
第3节（新）
This section explicitly defines the 3 categories of namespace -- Experimental, Informal and Formal. This section provides a description of the intended use of the different namespace types, as well as some acceptability guidelines for Formal namespaces (which require IETF review).
本节明确定义了名称空间的3个类别——实验性、非正式和正式。本节描述了不同名称空间类型的预期用途，以及正式名称空间的一些可接受性指南（需要IETF审查）。
Section 4.0
第4.0节
Spelled out the name of RFC 2434 ("IANA Considerations").
详细说明RFC 2434的名称（“IANA注意事项”）。
Provided a pointer to the IANA URN namespace registry.
提供了指向IANA URN命名空间注册表的指针。
Sections 4.1-4.3
第4.1-4.3节
New subsection divisions of the existing discussion of individual namespace types.
对单个名称空间类型现有讨论的新小节划分。
Section 4.2
第4.2节
Corrected reference to URN Syntax document (RFC 2141, not RFC 2168).
更正了对URN语法文档（RFC 2141，而不是RFC 2168）的引用。
Section 4.3
第4.3节
Added clarifying text as to the intended nature of Formal namespaces and processes for registering them.
添加了关于正式名称空间的预期性质和注册过程的澄清文本。
Added text to describe the requirement for a "Namespace Considerations" section in RFCs defining Formal namespaces. Defined the required content of that section.
添加了描述RFCs定义正式名称空间中“名称空间注意事项”部分要求的文本。定义了该节所需的内容。
Added text to describe the new requirement for a "Community Considerations" section in RFCs defining Formal namespaces. Defined the required content of that section.
添加了描述RFC定义正式名称空间中“社区注意事项”部分的新要求的文本。定义了该节所需的内容。
Added text to explicitly call out the need for an "IANA Considerations" section in such RFCs, in order to alert IANA to required action.
添加文本，明确指出此类RFC中需要“IANA注意事项”部分，以便提醒IANA采取所需行动。
Added text to further clarify the (IETF) process for revising Formal namespace registrations through the RFC and IETF review process.
增加了文本，以进一步澄清通过RFC和IETF审查过程修改正式名称空间注册的（IETF）过程。
Section 6
第六节
New section -- added text to describe the IANA considerations for this document.
新章节——添加了描述本文档IANA注意事项的文本。
Section 7 -- References
第7节——参考文献
Added references to revised NAPTR documentation ([RFC3401]), and the previous version of this document ([RFC2611]).
增加了对修订版NAPTR文件（[RFC3401]）和本文件先前版本（[RFC2611]）的参考。
Appendix A
附录A
Section created by moving the "URN Namespace Definition Template" (RFC2611's Section 3) to an appendix.
通过将“URN名称空间定义模板”（RFC2611的第3节）移动到附录中创建的节。
Added references to the new requirements for "Namespace Considerations", "Community Considerations", and "IANA Considerations" sections for Formal namespace registrations.
增加了对正式名称空间注册的“名称空间注意事项”、“社区注意事项”和“IANA注意事项”部分的新要求的引用。
Clarified the "Declared registrant of the namespace" template element.
澄清了“名称空间的声明注册人”模板元素。
Added text to describe the purpose and scope of the "Validating Mechanism".
增加了描述“验证机制”的目的和范围的文本。
Appendix B
附录B
Section B.1 is the "example template" that was "Section 5" in RFC 2611.
第B.1节是RFC 2611中“第5节”的“示例模板”。
Update the sample "declared registrant" data per the changes to the template description.
根据模板说明的更改更新“声明注册人”样本数据。
Removed the reference to "US-ASCII" in the "namespace specific string" of the example namespace.
删除了示例命名空间的“命名空间特定字符串”中对“US-ASCII”的引用。
Section B.2 (new)
B.2节（新）
This added section is a step-by-step walkthrough of the process for registering Informal namespaces and Formal namespaces.
添加的这一部分是注册非正式名称空间和正式名称空间过程的逐步演练。
Authors' Addresses
作者地址
Leslie L. Daigle Thinking Cat Enterprises
莱斯利·L·戴格尔思维猫企业
EMail: leslie@thinkingcat.com
EMail: leslie@thinkingcat.com
Dirk-Willem van Gulik WebWeaving Internet Engineering Nieuwsteeg 37A 2311 RZ Leiden The Netherlands
Dirk Willem van Gulik网络编织互联网工程荷兰莱顿Nieuwsteeg 37A 2311 RZ
URL: http://www.webweaving.org/
Email: dirkx@webweaving.org
URL: http://www.webweaving.org/
Email: dirkx@webweaving.org
Renato Iannella IPR Systems Pty Ltd.
Renato Iannella知识产权系统私人有限公司。
EMail: renato@iprsystems.com
EMail: renato@iprsystems.com
Patrik Faltstrom Cisco Systems Inc 170 W Tasman Drive SJ-13/2 San Jose CA 95134 USA
Patrik Faltstrom Cisco Systems Inc 170 W塔斯曼大道SJ-13/2美国加利福尼亚州圣何塞95134
EMail: paf@cisco.com
EMail: paf@cisco.com
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编辑功能的资金目前由互联网协会提供。