Internet Engineering Task Force (IETF) D. Thaler, Ed.
Request for Comments: 7595 Microsoft
Obsoletes: 4395 T. Hansen
BCP: 35 AT&T Laboratories
Category: Best Current Practice T. Hardie
ISSN: 2070-1721 Google
June 2015
Internet Engineering Task Force (IETF) D. Thaler, Ed.
Request for Comments: 7595 Microsoft
Obsoletes: 4395 T. Hansen
BCP: 35 AT&T Laboratories
Category: Best Current Practice T. Hardie
ISSN: 2070-1721 Google
June 2015
Guidelines and Registration Procedures for URI Schemes
URI计划的指南和注册程序
Abstract
摘要
This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395.
本文件更新了统一资源标识符（URI）方案定义的指南和建议以及IANA注册流程。它淘汰了RFC 4395。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7595.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7595.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements for Permanent Scheme Definitions . . . . . . . . 4
3.1. Demonstrable, New, Long-Lived Utility . . . . . . . . . . 4
3.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 4
3.3. Well Defined . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Definition of Operations . . . . . . . . . . . . . . . . 6
3.5. Context of Use . . . . . . . . . . . . . . . . . . . . . 6
3.6. Internationalization and Character Encoding . . . . . . . 7
3.7. Clear Security and Privacy Considerations . . . . . . . . 7
3.8. Scheme Name Considerations . . . . . . . . . . . . . . . 8
3.9. Interoperability Considerations . . . . . . . . . . . . . 9
4. Guidelines for Provisional URI Scheme Registration . . . . . 9
5. Guidelines for Historical URI Scheme Registration . . . . . . 10
6. Guidelines for Private URI Scheme Use . . . . . . . . . . . . 10
7. URI Scheme Registration Procedure . . . . . . . . . . . . . . 10
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Registration Procedures . . . . . . . . . . . . . . . . . 11
7.3. Change Control . . . . . . . . . . . . . . . . . . . . . 13
7.4. URI Scheme Registration Template . . . . . . . . . . . . 13
8. The "example" URI Scheme . . . . . . . . . . . . . . . . . . 14
8.1. "example" URI Scheme Registration Request . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Contributor . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements for Permanent Scheme Definitions . . . . . . . . 4
3.1. Demonstrable, New, Long-Lived Utility . . . . . . . . . . 4
3.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 4
3.3. Well Defined . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Definition of Operations . . . . . . . . . . . . . . . . 6
3.5. Context of Use . . . . . . . . . . . . . . . . . . . . . 6
3.6. Internationalization and Character Encoding . . . . . . . 7
3.7. Clear Security and Privacy Considerations . . . . . . . . 7
3.8. Scheme Name Considerations . . . . . . . . . . . . . . . 8
3.9. Interoperability Considerations . . . . . . . . . . . . . 9
4. Guidelines for Provisional URI Scheme Registration . . . . . 9
5. Guidelines for Historical URI Scheme Registration . . . . . . 10
6. Guidelines for Private URI Scheme Use . . . . . . . . . . . . 10
7. URI Scheme Registration Procedure . . . . . . . . . . . . . . 10
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Registration Procedures . . . . . . . . . . . . . . . . . 11
7.3. Change Control . . . . . . . . . . . . . . . . . . . . . 13
7.4. URI Scheme Registration Template . . . . . . . . . . . . 13
8. The "example" URI Scheme . . . . . . . . . . . . . . . . . . 14
8.1. "example" URI Scheme Registration Request . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Contributor . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
The Uniform Resource Identifier (URI) protocol element and generic syntax is defined by [RFC3986]. Each URI begins with a scheme name, as defined by Section 3.1 of RFC 3986, that refers to a specification for identifiers within that scheme. The URI syntax provides a federated and extensible naming system, where each scheme's specification can further restrict the syntax and define the semantics of identifiers using that scheme.
统一资源标识符（URI）协议元素和通用语法由[RFC3986]定义。每个URI以一个方案名称开始，如RFC 3986第3.1节所定义，该名称引用该方案中标识符的规范。URI语法提供了一个联邦的和可扩展的命名系统，其中每个方案的规范可以进一步限制语法并使用该方案定义标识符的语义。
This document obsoletes [RFC4395], which in turn obsoleted [RFC2717] and [RFC2718]. Recent documents have used the term "URI" for all resource identifiers, avoiding the term "URL" and reserving the term "URN" explicitly for those URIs using the "urn" scheme name
本文件淘汰了[RFC4395]，后者又淘汰了[RFC2717]和[RFC2718]。最近的文档对所有资源标识符使用了术语“URI”，避免了术语“URL”，并为那些使用“URN”方案名称的URI明确保留了术语“URN”
[RFC2141]. URN "namespaces" [RFC3406] are specific to the "urn" scheme and are not covered explicitly by this specification.
[RFC2141]。URN“名称空间”[RFC3406]特定于“URN”方案，本规范未明确涵盖。
This document provides updated guidelines for the definition of new schemes, for consideration by those who are defining, registering, or evaluating those definitions. In addition, this document provides an updated process and mechanism for registering schemes within the IANA URI Schemes registry. There is a single namespace for registered schemes. The intent of the registry is to:
本文件提供了新方案定义的更新指南，供定义、注册或评估这些定义的人员参考。此外，本文档还提供了在IANAURI方案注册中心内注册方案的更新过程和机制。注册的方案只有一个名称空间。注册处的目的是：
o provide a central point of discovery for established URI scheme names and easy location of defining documents for schemes;
o 为已建立的URI方案名称提供中心发现点，并为方案定义文档提供方便的位置；
o discourage multiple separate uses of the same scheme name;
o 不鼓励多个单独使用同一方案名称；
o help those proposing new scheme names to discern established trends and conventions and to avoid names that might be confused with existing ones; and
o 帮助提出新方案名称的人员识别既定趋势和惯例，避免将名称与现有名称混淆；和
o encourage registration by setting a low barrier for registration.
o 通过设置较低的注册门槛来鼓励注册。
As originally defined, URIs only allowed a limited repertoire of characters chosen from US-ASCII. An Internationalized Resource Identifier (IRI), as defined by [RFC3987], extends the URI syntax to allow characters from a much greater repertoire to accommodate resource identifiers from the world's languages. RFC 3987 [RFC3987] also defined a mapping between URIs and IRIs. IRIs use the same scheme names as URIs. Thus, there is no separate independent registry or registration process for IRI schemes: the URI Schemes registry is used for both URIs and IRIs. Those who wish to describe resource identifiers that are useful as IRIs should define the corresponding URI syntax and note that the IRI usage follows the rules and transformations defined in [RFC3987].
按照最初的定义，URI只允许从US-ASCII中选择有限的字符集。[RFC3987]定义的国际化资源标识符（IRI）扩展了URI语法，允许来自更大曲目的字符容纳来自世界语言的资源标识符。RFC 3987[RFC3987]还定义了URI和IRIs之间的映射。IRI使用与URI相同的方案名称。因此，IRI方案没有单独的独立注册表或注册过程：URI方案注册表用于URI和IRI。那些希望描述作为IRI有用的资源标识符的人应该定义相应的URI语法，并注意IRI的使用遵循[RFC3987]中定义的规则和转换。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document distinguishes between a "scheme specification", which is a document defining the syntax and semantics of a scheme, and a "scheme registration request", which is the completed template submitted to IANA. The term "scheme definition" refers generically to the syntax and semantics of a scheme and is typically documented in a scheme specification.
本文件区分了“方案规范”（定义方案语法和语义的文件）和“方案注册请求”（提交给IANA的完整模板）。术语“方案定义”泛指方案的语法和语义，通常记录在方案规范中。
This section gives considerations for new schemes. Meeting these guidelines is REQUIRED for 'permanent' scheme registration. 'Permanent' status is appropriate for, but not limited to, use in standards. For URI schemes defined or normatively referenced by IETF Standards Track documents, 'permanent' registration status is REQUIRED.
本节给出了新方案的考虑因素。“永久”计划注册必须符合这些准则“永久”状态适用于但不限于在标准中使用。对于IETF标准跟踪文档定义或规范性引用的URI方案，需要“永久”注册状态。
[RFC3986] defines the overall syntax for URIs as:
[RFC3986]将URI的总体语法定义为：
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
A scheme definition cannot override the overall syntax for URIs. For example, this means that fragment identifiers cannot be reused outside the generic syntax restrictions and that fragment identifiers are not scheme specific. A scheme definition must specify the scheme name and the syntax of the scheme-specific part, which is clarified as follows:
方案定义不能覆盖URI的整体语法。例如，这意味着不能在通用语法限制之外重用片段标识符，并且片段标识符不是特定于方案的。方案定义必须指定方案名称和方案特定部分的语法，具体说明如下：
URI = scheme ":" scheme-specific-part [ "#" fragment ]
URI = scheme ":" scheme-specific-part [ "#" fragment ]
scheme-specific-part = hier-part [ "?" query ]
方案特定部分=层次部分[“？”查询]
In general, the use and deployment of new schemes in the Internet infrastructure can be costly; some parts of URI processing are often scheme dependent. Introducing a new scheme might require additional software not only for client software and user agents but also in additional parts of the network infrastructure (gateways, proxies, caches) [W3CWebArch]. Since scheme names share a single, global namespace, it is desirable to avoid contention over use of short, mnemonic scheme names. New schemes ought to have utility to the Internet community beyond that available with already registered schemes. The scheme specification SHOULD discuss the utility of the scheme being registered.
一般来说，在互联网基础设施中使用和部署新方案的成本可能很高；URI处理的某些部分通常依赖于方案。引入新方案可能不仅需要客户端软件和用户代理的附加软件，还需要网络基础设施的附加部分（网关、代理、缓存）[W3CWebArch]。由于方案名称共享一个全局名称空间，因此需要避免因使用简短的助记符方案名称而产生争用。除了已经注册的计划之外，新的计划应该对互联网社区具有更大的效用。方案规范应讨论注册方案的效用。
[RFC3986] defines the generic syntax for all URI schemes, along with the syntax of common URI components that are used by many URI schemes to define hierarchical identifiers. [RFC3987] extended this generic syntax to cover IRIs. All scheme specifications MUST define their own URI <scheme-specific-part> syntax. Care must be taken to ensure
[RFC3986]定义了所有URI方案的通用语法，以及许多URI方案用于定义层次标识符的公共URI组件的语法。[RFC3987]扩展了此通用语法以涵盖IRIs。所有方案规范都必须定义自己的URI<scheme specific part>语法。必须注意确保
that all strings matching their scheme-specific syntax will also match the <absolute-URI> grammar described in [RFC3986].
所有匹配其特定于方案的语法的字符串也将匹配[RFC3986]中描述的<absolute URI>语法。
New schemes SHOULD reuse the common URI components of [RFC3986] for the definition of hierarchical naming schemes. If there is a strong reason for a scheme not to use the hierarchical syntax, then the new scheme definition SHOULD follow the syntax of similar previously registered schemes.
新方案应重用[RFC3986]的公共URI组件来定义分层命名方案。如果一个方案有充分理由不使用分层语法，那么新的方案定义应该遵循以前注册的类似方案的语法。
Schemes that are not intended for use with relative URIs SHOULD avoid use of the forward slash "/" character in order to avoid unintended processing, such as resolution of "." and ".." (dot segments).
不用于相对URI的方案应避免使用正斜杠“/”字符，以避免意外处理，例如“.”和“.”（点段）的分辨率。
Schemes SHOULD avoid improper use of "//". The use of double slashes in the first part of a URI is not a stylistic indicator that what follows is a URI: double slashes are intended for use ONLY when the syntax of the <scheme-specific-part> contains a hierarchical structure. In URIs from such schemes, the use of double slashes indicates that what follows is the top hierarchical element for a naming authority (Section 3.2 of RFC 3986 has more details). Schemes that do not contain a conformant hierarchical structure in their <scheme-specific-part> SHOULD NOT use double slashes following the "<scheme>:" string.
方案应避免不当使用“/”。在URI的第一部分中使用双斜杠并不是一个风格指标，表明下面的内容是URI：双斜杠仅用于<scheme-specific-part>的语法包含层次结构时。在此类方案的URI中，使用双斜杠表示以下是命名机构的顶级层次元素（RFC 3986第3.2节有更多详细信息）。在其<scheme-specific part>中不包含一致层次结构的方案不应在“<scheme>：”字符串后使用双斜杠。
New schemes SHOULD clearly define the role of reserved characters (see Section 2.2 of [RFC3986]) in URIs of the scheme being defined. The syntax of the new scheme should be clear about which of the "reserved" set of characters are used as delimiters within the URIs of the new scheme, and when those characters must be escaped, versus when they can be used without escaping.
新方案应明确定义所定义方案的URI中保留字符的角色（见[RFC3986]第2.2节）。新方案的语法应该明确哪些“保留”字符集在新方案的URI中用作分隔符，以及这些字符何时必须转义，何时可以不转义使用。
While URIs might or might not be defined as locators in practice, a scheme definition itself MUST be clear as to how it is expected to function. Schemes that are not intended to be used as locators SHOULD describe how the resource identified can be determined or accessed by software that obtains a URI of that scheme.
虽然uri在实践中可能被定义为定位器，也可能不被定义为定位器，但方案定义本身必须清楚地知道它的预期功能。不打算用作定位器的方案应描述如何通过获取该方案URI的软件确定或访问所标识的资源。
For schemes that function as locators, it is important that the mechanism of resource location be clearly defined. This might mean different things depending on the nature of the scheme.
对于充当定位器的方案，明确定义资源定位机制非常重要。根据计划的性质，这可能意味着不同的事情。
In many cases, new schemes are defined as ways to translate between other namespaces or protocols and the general framework of URIs. For example, the "ftp" scheme translates into the FTP protocol while the "mid" scheme translates into a Message-ID identifier of an email message. For such schemes, the description of the mapping SHOULD be
在许多情况下，新方案被定义为在其他名称空间或协议与URI的通用框架之间进行转换的方式。例如，“ftp”方案转换为ftp协议，“mid”方案转换为电子邮件的消息ID标识符。对于此类方案，应对映射进行描述
complete and in sufficient detail so that the mapping in both directions is clear: how to map from a URI into an identifier or set of protocol actions or name in the target namespace, and how legal values in the base namespace, or legal protocol interactions, are represented in a valid URI. See Section 3.6 for guidelines for encoding strings or sequences of bytes within valid character sequences in a URI. If not all legal values or protocol interactions of the base standard can be represented using the scheme, the definition SHOULD be clear about which subset is allowed and why.
完整且足够详细，以便两个方向的映射都清晰：如何从URI映射到目标命名空间中的标识符或协议操作集或名称，以及如何在有效URI中表示基本命名空间中的合法值或合法协议交互。有关URI中有效字符序列内的字符串或字节序列的编码准则，请参见第3.6节。如果不能使用方案表示基本标准的所有法律价值或协议交互，则定义应明确允许使用哪一子集以及为什么。
As part of the definition of how a URI identifies a resource, a scheme definition SHOULD define the applicable set of operations that can be performed on a resource using the URI as its identifier. A model for this is HTTP methods; an HTTP resource can be operated on by GET, POST, PUT, and a number of other methods available through the HTTP protocol. The scheme definition SHOULD describe all well-defined operations on the resource identifier and what they are supposed to do.
作为URI如何标识资源定义的一部分，方案定义应定义可使用URI作为其标识符对资源执行的适用操作集。这方面的一个模型是HTTP方法；HTTP资源可以通过GET、POST、PUT和通过HTTP协议可用的许多其他方法进行操作。方案定义应该描述资源标识符上所有定义良好的操作以及它们应该做什么。
Some schemes don't fit into the "information access" paradigm of URIs. For example, "telnet" provides location information for initiating a bidirectional data stream to a remote host; the only operation defined is to initiate the connection. In any case, the operations appropriate for a scheme SHOULD be documented.
有些方案不符合URI的“信息访问”范式。例如，“telnet”提供用于向远程主机发起双向数据流的位置信息；定义的唯一操作是启动连接。在任何情况下，应记录适用于方案的操作。
Note: It is perfectly valid to say that "no operation apart from GET is defined for this URI." It is also valid to say that "there's only one operation defined for this URI, and it's not very GET-like." The important point is that what is defined on this scheme is described.
注意：说“除了GET之外，没有为这个URI定义任何操作”是完全正确的。说“这个URI只定义了一个操作，它不是很像GET”也是正确的。重要的一点是，描述了在这个方案上定义的内容。
Scheme definitions SHOULD define a "default" operation for when a URI is invoked (or "dereferenced") by an application. For example, a common "default" operation today is to launch an application associated with the scheme name and let it use the other URI components as inputs to do something. The default invocation, or dereferencing, of a URI SHOULD be "safe" in the sense described by Section 3.4 of [W3CWebArch]; i.e., performing such an invocation should not incur any additional obligations by doing so.
当应用程序调用（或“取消引用”）URI时，方案定义应定义“默认”操作。例如，现在常见的“默认”操作是启动与方案名称关联的应用程序，并让它使用其他URI组件作为输入来执行某些操作。URI的默认调用或取消引用应该是[W3CWebArch]第3.4节描述的“安全”的；i、 例如，执行这样的调用不应因此招致任何额外的义务。
In general, URIs are used within a broad range of protocols and applications. For example, URIs are commonly used within hypertext documents as references to other resources. In some cases, a scheme is intended for use within a different, specific set of protocols or applications. If so, the scheme definition SHOULD describe the
一般来说，URI在广泛的协议和应用程序中使用。例如，URI通常在超文本文档中用作对其他资源的引用。在某些情况下，方案旨在用于不同的特定协议集或应用程序中。如果是，方案定义应描述
intended use and include references to documentation that define the applications and/or protocols cited. This does not obviate the need for documentation on applications and/or protocols to discuss URI schemes relevant to them.
预期用途，包括对定义所引用应用和/或协议的文件的引用。这并不意味着无需编写有关应用程序和/或协议的文档来讨论与其相关的URI方案。
When describing schemes in which (some of) the elements of the URI are actually representations of human-readable text, care should be taken not to introduce unnecessary variety in the ways in which characters are encoded into octets and then into URI characters; see [RFC3987] and Section 2.5 (especially the last paragraph) of [RFC3986] for guidelines. If URIs of a scheme contain any text fields, the scheme definition MUST describe the ways in which characters are encoded and any compatibility issues with IRIs of the scheme.
在描述URI的（某些）元素实际上是人类可读文本表示的方案时，应注意不要在将字符编码为八位字节然后再编码为URI字符的方式中引入不必要的变化；有关指南，请参见[RFC3987]和[RFC3986]的第2.5节（尤其是最后一段）。如果方案的URI包含任何文本字段，则方案定义必须描述字符的编码方式以及与方案的IRIs的任何兼容性问题。
The scheme specification SHOULD be as restrictive as possible regarding what characters are allowed in the URI because some characters can create several different security issues (see, for example, [RFC4690]).
对于URI中允许哪些字符，scheme规范应该尽可能严格，因为某些字符可能会产生几个不同的安全问题（例如，请参见[RFC4690]）。
Percent-encoded character sequences are automatically included by definition for characters given in IRI productions. This means that if you want to restrict the URI percent-encoded forms in some way, you must restrict the Unicode forms that would lead to them. In most cases, it is advisable to define the actual characters allowed in an IRI production in order to allow the 'pct-encoded' definition from Section 2.1 of [RFC3986] at the same places and to add prose that limits percent escapes to those that can be created by converting valid UTF-8 character sequences to percent-encoding.
对于IRI产品中给定的字符，百分比编码字符序列会自动包含在定义中。这意味着，如果您想以某种方式限制URI百分比编码的表单，则必须限制导致它们的Unicode表单。在大多数情况下，建议定义IRI产品中允许的实际字符，以便允许[RFC3986]第2.1节中的“pct编码”定义位于相同位置，并添加散文，将转义百分比限制为通过将有效UTF-8字符序列转换为百分比编码来创建的转义百分比。
Definitions of schemes MUST be accompanied by a clear analysis of the security and privacy implications for systems that use the scheme; this follows the practice of Security Consideration sections within IANA registrations [RFC5226].
方案的定义必须附有对使用方案的系统的安全和隐私影响的明确分析；这遵循IANA注册[RFC5226]中安全考虑部分的做法。
In particular, Section 7 of RFC 3986 [RFC3986] describes general security considerations for URIs while [RFC3987] gives those for IRIs. The definition of an individual scheme should note which of these apply to the specified scheme, in addition to any more scheme-specific concerns. For example, if the scheme-specific part is privacy sensitive, then that should be documented.
特别是，RFC 3986[RFC3986]第7节描述了URI的一般安全注意事项，而[RFC3987]给出了IRIs的一般安全注意事项。单个计划的定义应注意，除了任何特定于计划的问题外，其中哪些适用于指定的计划。例如，如果方案特定部分对隐私敏感，则应记录该部分。
Section 3.1 of RFC 3986 defines the syntax of a URI scheme name; this syntax remains the same for IRIs. New scheme registrations MUST follow this syntax, which only allows a limited repertoire of characters (taken from US-ASCII). Although the syntax for the scheme name in URIs is case insensitive, the scheme name itself MUST be registered using lowercase letters.
RFC 3986的第3.1节定义了URI方案名称的语法；IRIs的语法保持不变。新方案注册必须遵循此语法，该语法只允许有限的字符集（取自US-ASCII）。尽管URI中方案名称的语法不区分大小写，但方案名称本身必须使用小写字母注册。
Scheme names SHOULD be short but also sufficiently descriptive and distinguished to avoid problems.
方案名称应简短，但也应具有足够的描述性和可区分性，以避免出现问题。
Schemes SHOULD NOT use names or other symbols that might cause problems with rights to use the name in IETF specifications and Internet protocols. For example, be careful with trademark and service mark names. (See Section 3.4 of [RFC5378]).
方案不应使用可能导致IETF规范和互联网协议中使用名称的权限出现问题的名称或其他符号。例如，请注意商标和服务商标名称。（见[RFC5378]第3.4节）。
Schemes SHOULD NOT use names that are either very general purpose or associated in the community with some other application or protocol. Schemes also SHOULD NOT use names that are overly general or grandiose in scope (e.g., that allude to their "universal" or "standard" nature).
方案不应使用非常通用或在社区中与其他应用程序或协议关联的名称。方案也不应使用范围过于笼统或宏大的名称（例如，暗示其“普遍”或“标准”性质）。
A scheme name is not a "protocol." However, like a service name as defined in Section 5 of [RFC6335], it often identifies a particular protocol or application. If a scheme name has a one-to-one correspondence with a service name, then the names SHOULD be the same.
方案名称不是“协议”。但是，与[RFC6335]第5节中定义的服务名称一样，它通常标识特定的协议或应用程序。如果方案名称与服务名称一一对应，则名称应相同。
Some organizations desire their own namespace for URI scheme names for private use (see Section 6). In doing so, it is important to prevent collisions and to make it possible to identify the owner of a private-use scheme. To accomplish these two goals, such organizations SHOULD use a prefix based on their domain name, expressed in reverse order. For example, a URI scheme name of com.example.mything might be used by the organization that owns the example.com domain name. Care must be taken, however, if the organization later loses the domain name embedded in their scheme names since domain name registrations are not permanent. To associate the private-use scheme name with the original organization, the private-use scheme can be registered using the registration procedure in Section 7.
一些组织希望自己的名称空间用于URI方案名称，以供私人使用（参见第6节）。在这样做时，重要的是要防止冲突，并使其能够识别私人使用方案的所有者。为了实现这两个目标，这些组织应该使用基于其域名的前缀，以相反的顺序表示。例如，拥有example.com域名的组织可能会使用com.example.mything的URI方案名称。但是，如果组织后来丢失了其方案名称中嵌入的域名，则必须小心，因为域名注册不是永久性的。要将私人使用计划名称与原始组织关联，可使用第7节中的注册程序注册私人使用计划。
Furthermore, to prevent collisions with private-use scheme names, new scheme names registered MUST NOT contain a "." unless actually constructed from a reversed domain name.
此外，为了防止与私用方案名称发生冲突，注册的新方案名称不得包含“.”，除非实际由反向域名构造。
If the person or group registering the scheme is aware of any details regarding the scheme that might impact interoperability, identify them, for example, proprietary or uncommon encoding methods, or incompatibility with types or versions of any underlying protocol.
如果注册方案的人员或组知道可能影响互操作性的方案的任何详细信息，请识别这些信息，例如，专有或不常见的编码方法，或与任何基础协议的类型或版本不兼容。
'Provisional' registration can be used for schemes that are not part of any standard but that are intended for use (or observed to be in use) that is not limited to a private environment within a single organization. 'Provisional' registration can also be used as an intermediate step on the way to 'permanent' registration, e.g., before the scheme specification is finalized as a standard.
“临时”注册可用于不属于任何标准的计划，但计划用于（或观察到正在使用）不限于单个组织内的私人环境临时“注册”也可作为“永久”注册的中间步骤，例如，在方案规范最终确定为标准之前。
For a 'provisional' registration, the following apply:
对于“临时”注册，以下内容适用：
o The scheme name must meet the syntactic requirements of Section 3.8.
o 方案名称必须符合第3.8节的语法要求。
o There must not already be an entry with the same scheme name. In the unfortunate case that there are multiple, different uses of the same scheme name, the Designated Expert can approve a request to modify an existing entry to note the separate use.
o 不能已有具有相同方案名称的条目。在不幸的情况下，同一方案名称有多个不同的用途，指定专家可以批准修改现有条目的请求，以记录单独的用途。
o Contact information identifying the person supplying the registration must be included. Previously unregistered schemes discovered in use can be registered by third parties (even if not on behalf of those who created the scheme). In this case, both the registering party and the scheme creator SHOULD be identified.
o 必须包括识别提供注册的人员的联系信息。在使用中发现的以前未注册的方案可以由第三方注册（即使不代表创建方案的人）。在这种情况下，应同时识别注册方和方案创建者。
o If no permanent, citable specification for the scheme definition is included, credible reasons for not providing it SHOULD be given.
o 如果方案定义中未包含永久性、可引用的规范，则应给出不提供该规范的可信理由。
o The scheme definition SHOULD include clear security considerations (Section 3.7) or explain why a full security analysis is not available (e.g., in a third-party scheme registration).
o 方案定义应包括明确的安全注意事项（第3.7节）或解释为什么不提供完整的安全分析（例如，在第三方方案注册中）。
o If the scheme definition does not meet the guidelines laid out in Section 3, the differences and reasons SHOULD be noted.
o 如果方案定义不符合第3节中规定的指南，则应注意差异和原因。
In some circumstances, it is appropriate to note a scheme that was once in use or registered but for whatever reason is no longer in common use or whose use is not recommended. In this case, it is possible for an individual to request that the URI scheme be registered (newly, or as an update to an existing registration) as 'historical'. Any scheme that is no longer in common use MAY be designated as 'historical'; the registration SHOULD contain some indication as to where the scheme was previously defined or documented.
在某些情况下，宜注意曾使用或注册但因任何原因不再通用或不建议使用的方案。在这种情况下，个人可以请求将URI方案注册为“历史”（新注册或作为现有注册的更新）。任何不再通用的方案可被指定为“历史”方案；注册应包含一些指示，说明先前在何处定义或记录了该计划。
Unregistered schemes can cause problems if use is not limited to a private environment within a single organization since the use could leak out beyond the closed environment. Even within a closed environment, other colliding uses of the same scheme name could occur. As such, a unique namespace MUST be used and 'provisional' registration is strongly encouraged (unless the scheme name is constructed from a domain name), as discussed in Section 3.8.
如果使用不限于单个组织内的私有环境，则未注册的方案可能会导致问题，因为使用可能会泄漏到封闭环境之外。即使在封闭的环境中，也可能发生相同方案名称的其他冲突使用。因此，必须使用唯一的名称空间，并且强烈鼓励“临时”注册（除非方案名称由域名构成），如第3.8节所述。
The IANA policy (using terms defined in [RFC5226]) for 'provisional' registration was formerly Expert Review; this document changes the policy to First Come First Served. The policy for 'permanent' and 'historical' registration continues to be Expert Review.
“临时”注册的IANA政策（使用[RFC5226]中定义的术语）以前是专家评审；本文件将政策更改为先到先得。“永久”和“历史”注册的政策仍然是专家审查。
The registration procedure is intended to be very lightweight for noncontentious registrations. For the most part, we expect the good sense of submitters and reviewers, guided by these procedures, to achieve an acceptable and useful consensus for the community.
注册程序对于非争议性注册来说是非常轻量级的。在大多数情况下，我们期望提交者和审阅者在这些程序的指导下，能够达成社区可接受和有用的共识。
In exceptional cases, where the negotiating parties cannot form a consensus, the final arbiter of any contested registration shall be the IESG.
在例外情况下，如果谈判各方无法达成共识，任何有争议的注册的最终仲裁人应为IESG。
If standardization is anticipated, the working group or individuals concerned are advised to submit an early 'permanent' registration request rather than waiting until the standardization process has run its course. IANA will pass this to the Designated Expert who may recommend 'provisional' registration until the specification is approved as a standard. This will provide an opportunity for feedback while specification development and review is still active, and while the submitter(s) are still in a position to respond to any
如果预计会实现标准化，建议相关工作组或个人尽早提交“永久”注册申请，而不是等到标准化过程完成后再提交。IANA将此信息传递给指定专家，该专家可建议“临时”注册，直到规范被批准为标准。这将提供一个反馈机会，同时规范开发和审查仍处于活动状态，并且提交人仍能够对任何问题做出响应
issues that might be raised. If and when the specification is approved as a standard, the submitters should submit a request to change the registration status to 'permanent'.
可能提出的问题。如果规范被批准为标准，提交人应提交一份将注册状态更改为“永久”的请求。
The role of the Designated Expert in the procedure for 'permanent' registrations described here is to ensure that the normal open review process has been properly followed and to raise possible concerns about wider implications of proposals for the use and deployment of URIs. Nothing in the procedure empowers the Designated Expert to override properly arrived-at IETF or working group consensus.
指定专家在此处描述的“永久”注册程序中的作用是确保正常的公开审查流程得到适当遵守，并对URI的使用和部署提案的更广泛影响提出可能的担忧。本程序中的任何内容均不授权指定专家推翻IETF或工作组达成的一致意见。
Someone wishing to register a new scheme MUST:
希望注册新计划的人必须：
1. Check the IANA "Uniform Resource Identifier (URI) Schemes" registry to see whether there is already an entry for the desired name. If there is already an entry under the name, choose a different scheme name or update the existing scheme specification.
1. 检查IANA“统一资源标识符（URI）方案”注册表，查看是否已存在所需名称的条目。如果名称下已有条目，请选择其他方案名称或更新现有方案规范。
2. Prepare a scheme registration request using the template specified in Section 7.4. The scheme registration request can be contained in an Internet-Draft, submitted alone, or as part of some other permanently available, stable, protocol specification. The scheme registration request can also be submitted in some other form (as part of another document or as a stand-alone document), but the scheme registration request will be treated as an "IETF Contribution" under the guidelines of [RFC5378].
2. 使用第7.4节规定的模板编制方案注册申请。方案注册请求可以包含在互联网草案中，单独提交，或者作为其他永久可用、稳定的协议规范的一部分提交。方案注册申请也可以以其他形式提交（作为另一份文件的一部分或作为独立文件），但根据[RFC5378]指南，方案注册申请将被视为“IETF贡献”。
3. If the registration request is for a 'permanent' registration (or, optionally, for any other registration if desired):
3. 如果注册请求为“永久”注册（或者，如果需要，可选择为任何其他注册）：
1. Review the requirements in Section 3.
1. 审查第3节中的要求。
2. Send a copy of the scheme registration request or a pointer to the document containing the request (with specific reference to the section that requests the scheme registration) to the mailing list uri-review@ietf.org, requesting review. In addition, request review on other relevant mailing lists as appropriate. For example, general discussion of URI syntactical issues can be discussed on uri@w3.org; schemes for a network protocol can be discussed on a mailing list for that protocol. Allow a reasonable time for discussion and comments. Four weeks is reasonable for a 'permanent' registration request.
2. 将方案注册请求的副本或指向包含该请求的文档的指针（具体参考请求方案注册的部分）发送到邮件列表uri-review@ietf.org，要求覆核。此外，酌情要求审查其他相关邮件列表。例如，URI语法问题的一般性讨论可以在uri@w3.org; 网络协议的方案可以在该协议的邮件列表上讨论。留出合理的时间进行讨论和评论。对于“永久”注册申请而言，四周是合理的。
3. Respond to review comments and make revisions to the proposed registration as needed to bring it into line with the guidelines given in this document.
3. 回应审查意见，并根据需要对拟议注册进行修订，使其符合本文件中给出的指南。
4. Submit the (possibly updated) scheme registration request (or pointer to document containing it) to IANA at iana@iana.org.
4. 向IANA提交（可能更新的）方案注册请求（或指向包含该请求的文档的指针），地址为iana@iana.org.
Upon receipt of a scheme registration request, the following steps MUST be followed:
收到计划注册申请后，必须遵循以下步骤：
1. IANA checks the submission for completeness; if required sections of the scheme registration request are missing or any citations are not correct, IANA will reject the registration request. A registrant can resubmit a corrected request if desired.
1. IANA检查提交文件的完整性；如果计划注册申请的必要部分缺失或引用不正确，IANA将拒绝注册申请。如果需要，注册人可以重新提交更正的请求。
2. If the request is for 'provisional' registration and no entry already exists in the current registry for the same name, IANA adds the registration to the registry under the First Come First Served policy.
2. 如果请求是“临时”注册，且当前注册表中没有相同名称的条目，IANA将根据先到先得政策将注册添加到注册表中。
3. Otherwise, IANA enters the registration request in the IANA registry with the status marked as "Pending Review", and the remainder of this section applies.
3. 否则，IANA在IANA注册表中输入注册请求，状态标记为“待定审查”，本节其余部分适用。
4. IANA requests Expert Review of the registration request against the corresponding guidelines from this document.
4. IANA要求根据本文件中的相应指南对注册申请进行专家审查。
5. The Designated Expert will evaluate the request against the criteria of the requested status.
5. 指定专家将根据所请求的地位标准对请求进行评估。
6. In the case of a 'permanent' registration request, the Designated Expert may:
6. 在“永久”注册申请的情况下，指定专家可以：
* Accept the specification of the scheme for 'permanent' registration.
* 接受“永久”注册计划的说明。
* Suggest 'provisional' registration instead.
* 建议改为“临时”注册。
* Request IETF review and IESG approval; in the meanwhile, suggest 'provisional' registration.
* 请求IETF审查和IESG批准；同时，建议“临时”注册。
* Request additional review or discussion as necessary.
* 必要时要求进行额外的审查或讨论。
7. If an entry already exists for the same name, the Designated Expert will determine whether the request should be rejected or whether the existing entry should be modified to note the separate use. This conflict process applies regardless of the requested status or the status of the existing entry.
7. 如果已存在同名条目，指定专家将确定是否应拒绝该请求，或是否应修改现有条目以注明单独用途。无论请求的状态或现有条目的状态如何，此冲突过程均适用。
8. Once the Designated Expert approves registration for a given status, IANA updates the registration to indicate the approved status. If the Designated Expert instead rejects the registration, the "Pending Review" request is removed from the registry.
8. 一旦指定专家批准某一特定状态的注册，IANA将更新该注册以表明已批准的状态。如果指定专家拒绝注册，则从登记处删除“待审查”请求。
Either based on an explicit request or independently initiated, the Designated Expert or the IESG can request the upgrade of a 'provisional' registration to a 'permanent' one. In such cases, IANA will update the status of the corresponding entry. Typically, this would only occur if the use is considered a standard (not necessarily an IETF standard).
无论是基于明确的请求还是独立发起的，指定专家或IESG都可以请求将“临时”注册升级为“永久”注册。在这种情况下，IANA将更新相应条目的状态。通常，只有当使用被视为标准（不一定是IETF标准）时，才会发生这种情况。
Registrations can be updated in the registry by the same mechanism as required for an initial registration. In cases where the original definition of the scheme is contained in an IESG-approved document, update of the specification also requires IESG approval.
注册可以通过初始注册所需的相同机制在注册表中更新。如果计划的原始定义包含在IESG批准的文件中，则规范的更新也需要IESG批准。
'Provisional' registrations can be updated by the original registrant or anyone designated by the original registrant. In addition, the IESG can reassign responsibility for a 'provisional' registration scheme or can request specific changes to a scheme registration. This will enable changes to be made to schemes where the original registrant is out of contact or unwilling or unable to make changes.
“临时”注册可由原始注册人或原始注册人指定的任何人更新。此外，IESG可以重新分配“临时”注册计划的责任，也可以请求对计划注册进行特定更改。这将允许对原始注册人失去联系或不愿意或无法进行更改的计划进行更改。
Transition from 'provisional' to 'permanent' status can be requested and approved in the same manner as a new 'permanent' registration. Transition from 'permanent' to 'historical' status requires IESG approval. Transition from 'provisional' to 'historical' can be requested by anyone authorized to update the 'provisional' registration.
从“临时”状态过渡到“永久”状态的请求和批准方式与新的“永久”注册相同。从“永久”状态过渡到“历史”状态需要IESG批准。授权更新“临时”注册的任何人都可以请求从“临时”转换为“历史”。
This template describes the fields that MUST be supplied in a scheme registration request suitable for adding to the registry:
此模板描述了适用于添加到注册表的方案注册请求中必须提供的字段：
Scheme name: See Section 3.8 for guidelines.
方案名称：指南见第3.8节。
Status: This reflects the status requested and must be one of 'Permanent', 'Provisional', or 'Historical'.
状态：反映请求的状态，必须是“永久”、“临时”或“历史”状态之一。
Applications/protocols that use this scheme name: See Section 3.5.
使用此方案名称的应用程序/协议：见第3.5节。
Contact: Person (including contact information) to contact for further information.
联系人：联系以获取更多信息的人员（包括联系信息）。
Change controller: Organization or person (often the author), including contact information, authorized to change this.
变更控制者：授权变更的组织或个人（通常是作者），包括联系信息。
References: Include full citations for all referenced documents. Scheme registration requests for 'provisional' registration can be included in an Internet-Draft; when the documents expire or are approved for publication as an RFC, the registration will be updated. A scheme specification is only required for 'permanent' registration.
参考文献：包括所有参考文献的完整引文。“临时”注册的计划注册请求可包含在互联网草稿中；当文件到期或批准作为RFC发布时，将更新注册。只有“永久”注册才需要方案说明。
The previous version of this specification required the following additional fields in a scheme registration request. These fields are no longer part of the template. The answers instead belong in the scheme specification.
本规范的早期版本要求在方案注册请求中包含以下附加字段。这些字段不再是模板的一部分。相反，答案属于方案规范。
Scheme syntax: See Section 3.2 for guidelines.
方案语法：有关指南，请参见第3.2节。
Scheme semantics: See Section 3.3 and Section 3.4 for guidelines.
方案语义：有关指南，请参见第3.3节和第3.4节。
Encoding considerations: See Section 3.3 and Section 3.6 for guidelines.
编码注意事项：有关指南，请参见第3.3节和第3.6节。
Interoperability considerations: See Section 3.9 for guidelines.
互操作性注意事项：有关指南，请参见第3.9节。
Security considerations: See Section 3.7 for guidelines.
安全注意事项：有关指南，请参见第3.7节。
There is a need for a scheme name that can be used for examples in documentation without fear of conflicts with current or future actual schemes. The scheme "example" is hereby registered as a 'permanent' scheme for that purpose.
需要一个方案名称，该名称可用于文档中的示例，而无需担心与当前或未来的实际方案发生冲突。为此，该计划“范例”特此注册为“永久性”计划。
The "example" scheme is specified as follows:
“示例”方案规定如下：
Scheme syntax: The entire range of allowable syntax specified in [RFC3986] is allowed for "example" URIs. Similarly, the entire range of allowable syntax specified in [RFC3987] is allowed for "example" IRIs. For example, <example:foo>, <example:/foo>, and <example://foo> are all valid.
方案语法：“示例”URI允许[RFC3986]中指定的整个允许语法范围。类似地，[RFC3987]中规定的整个允许语法范围也允许用于“示例”IRIs。例如，<example:foo>、<example:/foo>和<example://foo>都是有效的。
Scheme semantics: URIs in the "example" scheme are to be used for documentation purposes only. The use of "example" URIs must not be used as locators, identify any resources, or specify any particular set of operations.
方案语义：“示例”方案中的URI仅用于文档目的。“示例”URI的使用不得用作定位器、标识任何资源或指定任何特定的操作集。
Encoding considerations: See Section 2.5 of [RFC3986] for guidelines.
编码注意事项：参考[RFC3986]第2.5节了解指南。
Interoperability considerations: None.
互操作性考虑：无。
Security considerations: None.
安全考虑：无。
Scheme name: example
方案名称：示例
Status: permanent
地位：永久
Applications/protocols that use this scheme name: An "example" URI is to be used for documentation purposes only. It MUST NOT be used for any protocol.
使用此方案名称的应用程序/协议：“示例”URI仅用于文档目的。它不得用于任何协议。
Contact: N/A
联系人：不适用
Change controller: IETF
更改控制器：IETF
References: Section 8 of this document (RFC 7595).
参考：本文件第8节（RFC 7595）。
Previously, the former "URL Scheme" registry was replaced by the "Uniform Resource Identifier (URI) Schemes" registry. The process was based on "Expert Review" [RFC5226] with an initial (optional) mailing list review.
以前，以前的“URL方案”注册表被“统一资源标识符（URI）方案”注册表取代。该过程基于“专家评审”[RFC5226]和初始（可选）邮件列表评审。
The updated template has an additional field for the status of the scheme, and the procedures for entering new name schemes have been augmented. Section 7 establishes the process for new scheme registration.
更新后的模板有一个用于方案状态的附加字段，并且增加了输入新名称方案的过程。第7节规定了新计划注册的流程。
IANA has done the following:
IANA已完成以下工作：
o Updated the URI Schemes registry to point to this document.
o 已更新URI方案注册表以指向此文档。
o Combined the "Permanent URI Schemes", "Provisional URI Schemes", and "Historical URI Schemes" subregistries into a single common registry with an additional "Status" column containing the status ('Permanent', 'Provisional', 'Historical', or 'Pending Review'), and an additional "Notes" column that is normally empty but may contain notes approved by the Designated Expert.
o 将“永久性URI方案”、“临时性URI方案”和“历史性URI方案”子区域合并为一个单一的通用注册表，并增加一个“状态”列，其中包含状态（“永久性”、“临时性”、“历史性”或“待审查”），以及一个额外的“注释”通常为空的列，但可能包含指定专家批准的注释。
o Added the "example" URI scheme to the registry (see the template in Section 8.1 for registration).
o 将“示例”URI方案添加到注册表中（有关注册信息，请参阅第8.1节中的模板）。
All registered values are expected to contain clear security considerations as discussed in Section 3.7. However, information concerning possible security vulnerabilities of a protocol might change over time. Consequently, claims as to the security properties of a registered scheme might change as well. As new vulnerabilities are discovered, information about such vulnerabilities might need to be attached to existing documentation, so that users are not misled as to the true security properties of a registered scheme.
如第3.7节所述，所有注册值均应包含明确的安全注意事项。但是，有关协议可能存在的安全漏洞的信息可能会随着时间的推移而变化。因此，关于注册计划的安全属性的主张也可能发生变化。当发现新的漏洞时，可能需要将有关此类漏洞的信息附加到现有文档中，以便用户不会对已注册方案的真实安全属性产生误解。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, May 1997, <http://www.rfc-editor.org/info/rfc2141>.
[RFC2141]护城河，R.，“瓮语法”，RFC 2141，DOI 10.17487/RFC2141，1997年5月<http://www.rfc-editor.org/info/rfc2141>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, DOI 10.17487/RFC5378, November 2008, <http://www.rfc-editor.org/info/rfc5378>.
[RFC5378]Bradner，S.，Ed.和J.Contreras，Ed.，“向IETF信托提供的权利出资人”，BCP 78，RFC 5378，DOI 10.17487/RFC5378，2008年11月<http://www.rfc-editor.org/info/rfc5378>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 6335，DOI 10.17487/RFC6335，2011年8月<http://www.rfc-editor.org/info/rfc6335>.
[RFC2717] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", RFC 2717, DOI 10.17487/RFC2717, November 1999, <http://www.rfc-editor.org/info/rfc2717>.
[RFC2717]Petke，R.和I.King，“URL方案名称的注册程序”，RFC 2717，DOI 10.17487/RFC2717，1999年11月<http://www.rfc-editor.org/info/rfc2717>.
[RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, "Guidelines for new URL Schemes", RFC 2718, DOI 10.17487/RFC2718, November 1999, <http://www.rfc-editor.org/info/rfc2718>.
[RFC2718]Masinter，L.，Alvestrand，H.，Zigmond，D.，和R.Petke，“新URL方案指南”，RFC 2718，DOI 10.17487/RFC2718，1999年11月<http://www.rfc-editor.org/info/rfc2718>.
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, DOI 10.17487/RFC3406, October 2002, <http://www.rfc-editor.org/info/rfc3406>.
[RFC3406]Daigle，L.，van Gulik，D.，Iannella，R.，和P.Faltstrom，“统一资源名称（URN）命名空间定义机制”，BCP 66，RFC 3406，DOI 10.17487/RFC3406，2002年10月<http://www.rfc-editor.org/info/rfc3406>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <http://www.rfc-editor.org/info/rfc3864>.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，DOI 10.17487/RFC3864，2004年9月<http://www.rfc-editor.org/info/rfc3864>.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, <http://www.rfc-editor.org/info/rfc3987>.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，DOI 10.17487/RFC3987，2005年1月<http://www.rfc-editor.org/info/rfc3987>.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", RFC 4395, DOI 10.17487/RFC4395, February 2006, <http://www.rfc-editor.org/info/rfc4395>.
[RFC4395]Hansen，T.，Hardie，T.，和L.Masinter，“新URI方案的指南和注册程序”，RFC 4395，DOI 10.17487/RFC4395，2006年2月<http://www.rfc-editor.org/info/rfc4395>.
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006, <http://www.rfc-editor.org/info/rfc4690>.
[RFC4690]Klensin，J.，Faltstrom，P.，Karp，C.，和IAB，“国际化域名（IDN）的审查和建议”，RFC 4690，DOI 10.17487/RFC4690，2006年9月<http://www.rfc-editor.org/info/rfc4690>.
[W3CWebArch] W3C Technical Architecture Group, "Architecture of the World Wide Web, Volume One", W3C Recommendation, December 2004, <http://www.w3.org/TR/webarch/>.
[W3CWebArch]W3C技术架构组，“万维网架构，第一卷”，W3C建议，2004年12月<http://www.w3.org/TR/webarch/>.
Acknowledgements
致谢
Thanks to Mark Nottingham and Graham Klyne and other members of the apps-discuss@ietf.org mailing list for their comments on this document.
感谢马克·诺丁汉和格雷厄姆·克莱恩以及应用程序的其他成员-discuss@ietf.org他们对本文件的评论的邮件列表。
Many thanks to Patrik Faltstrom, Paul Hoffmann, Ira McDonald, Roy Fielding, Stu Weibel, Tony Hammond, Charles Lindsey, Mark Baker, and other members of the uri@w3.org mailing list for their comments on earlier draft versions of this document.
非常感谢帕特里克·法茨特罗姆、保罗·霍夫曼、艾拉·麦克唐纳、罗伊·菲尔丁、斯图·韦贝尔、托尼·哈蒙德、查尔斯·林赛、马克·贝克和其他委员会成员uri@w3.org他们对本文件早期草案版本的评论的邮件列表。
Parts of this document are based on [RFC2717], [RFC2718] and [RFC3864]. Some of the ideas about use of URIs were taken from the "Architecture of the World Wide Web" [W3CWebArch].
本文件的部分内容基于[RFC2717]、[RFC2718]和[RFC3864]。关于URI使用的一些想法取自“万维网体系结构”[W3CWebArch]。
Contributor
贡献者
Larry Masinter was an author of the document from which this work is derived, and he continued as author of this version through the working group and IESG evaluation period. His many contributions are gratefully acknowledged.
Larry Masinter是本作品来源文件的作者，在工作组和IESG评估期间，他继续担任本版本的作者。他做出的许多贡献都受到了感激。
Authors' Addresses
作者地址
Dave Thaler (editor) Microsoft One Microsoft Way Redmond, WA 98052 United States
Dave Thaler（编辑）微软一路微软雷德蒙，华盛顿州98052美国
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Tony Hansen AT&T Laboratories 200 Laurel Ave. Middletown, NJ 07748 United States
美国新泽西州米德尔顿劳雷尔大道200号托尼·汉森AT&T实验室，邮编：07748
EMail: tony+urireg@maillennium.att.com
EMail: tony+urireg@maillennium.att.com
Ted Hardie Google
泰德·哈迪·谷歌
Phone: +1 408 628 5864
EMail: ted.ietf@gmail.com
Phone: +1 408 628 5864
EMail: ted.ietf@gmail.com