Network Working Group T. Hansen
Request for Comments: 4395 AT&T Laboratories
Obsoletes: 2717, 2718 T. Hardie
BCP: 115 Qualcomm, Inc.
Category: Best Current Practice L. Masinter
Adobe Systems
February 2006
Network Working Group T. Hansen
Request for Comments: 4395 AT&T Laboratories
Obsoletes: 2717, 2718 T. Hardie
BCP: 115 Qualcomm, Inc.
Category: Best Current Practice L. Masinter
Adobe Systems
February 2006
Guidelines and Registration Procedures for New URI Schemes
新URI方案的指南和注册程序
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718.
本文档为统一资源标识符（URI）方案的定义提供了指南和建议。它还为URI方案更新进程和IANA注册表。它淘汰了RFC 2717和RFC 2718。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Guidelines for Permanent URI Scheme Definitions . . . . . . . 4
2.1. Demonstratable, New, Long-Lived Utility . . . . . . . . . 4
2.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 5
2.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Definition of Operations . . . . . . . . . . . . . . . . . 6
2.5. Context of Use . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Internationalization and Character Encoding . . . . . . . 7
2.7. Clear Security Considerations . . . . . . . . . . . . . . 7
2.8. Scheme Name Considerations . . . . . . . . . . . . . . . . 7
3. Guidelines for Provisional URI Scheme Registration . . . . . . 8
4. Guidelines for Historical URI Scheme Registration . . . . . . 8
5. URI Scheme Registration Procedure . . . . . . . . . . . . . . 9
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Registration Procedures . . . . . . . . . . . . . . . . . 9
5.3. Change Control . . . . . . . . . . . . . . . . . . . . . . 10
5.4. URI Scheme Registration Template . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Guidelines for Permanent URI Scheme Definitions . . . . . . . 4
2.1. Demonstratable, New, Long-Lived Utility . . . . . . . . . 4
2.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 5
2.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Definition of Operations . . . . . . . . . . . . . . . . . 6
2.5. Context of Use . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Internationalization and Character Encoding . . . . . . . 7
2.7. Clear Security Considerations . . . . . . . . . . . . . . 7
2.8. Scheme Name Considerations . . . . . . . . . . . . . . . . 7
3. Guidelines for Provisional URI Scheme Registration . . . . . . 8
4. Guidelines for Historical URI Scheme Registration . . . . . . 8
5. URI Scheme Registration Procedure . . . . . . . . . . . . . . 9
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Registration Procedures . . . . . . . . . . . . . . . . . 9
5.3. Change Control . . . . . . . . . . . . . . . . . . . . . . 10
5.4. URI Scheme Registration Template . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
The Uniform Resource Identifier (URI) protocol element and generic syntax is defined by RFC 3986 [5]. 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 may further restrict the syntax and semantics of identifiers using that scheme. This document provides guidelines for the definition of new URI schemes, for consideration by those who are defining, registering, or evaluating those definitions, as well as a process and mechanism for registering URI schemes within the IANA URI scheme registry. The registry has two parts: 'provisional' and 'permanent', with different requirements. Guidelines and requirements for both parts are given.
统一资源标识符（URI）协议元素和通用语法由RFC 3986定义[5]。每个URI以一个方案名称开始，如RFC 3986第3.1节所定义，该名称引用该方案中标识符的规范。URI语法提供了一个联邦和可扩展的命名系统，其中每个方案的规范可以进一步限制使用该方案的标识符的语法和语义。本文档提供了定义新URI方案的指南，供定义、注册或评估这些定义的人员参考，以及在IANA URI方案注册表中注册URI方案的过程和机制。登记册分为“临时”和“永久”两部分，要求不同。给出了这两部分的指南和要求。
This document obsoletes both RFCs 2717 [7] and 2718 [8]. RFCs 2717 and 2718 drew a distinction between 'locators' (identifiers used for accessing resources available on the Internet) and 'names' (identifiers used for naming possibly abstract resources, independent of any mechanism for accessing them). The intent was to use the designation "URL" (Uniform Resource Locator) for those identifiers that were locators and "URN" (Uniform Resource Name) for those identifiers that were names. In practice, the line between 'locator' and 'name' has been difficult to draw: locators can be used as names, and names can be used as locators.
本文件废除了RFC 2717[7]和2718[8]。RFCs 2717和2718对“定位器”（用于访问Internet上可用资源的标识符）和“名称”（用于命名可能的抽象资源的标识符，独立于访问这些资源的任何机制）进行了区分。其目的是对作为定位器的标识符使用名称“URL”（统一资源定位器），对作为名称的标识符使用名称“URN”（统一资源名称）。实际上，“定位器”和“名称”之间的界限很难划清：定位器可以用作名称，而名称可以用作定位器。
As a result, 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 (RFC 2141 [2]). URN "namespaces" (RFC 3406 [9]) are specific to the "urn" scheme and not covered explicitly by this document.
因此，最近的文档对所有资源标识符使用了术语“URI”，避免了术语“URL”，并为使用“URN”方案名称的URI明确保留了术语“URN”（RFC 2141[2]）。URN“名称空间”（RFC 3406[9]）特定于“URN”方案，本文档未明确涵盖。
RFC 2717 defined a set of registration trees in which URI schemes could be registered, one of which was called the IETF Tree, to be managed by IANA. RFC 2717 proposed that additional registration trees might be approved by the IESG. However, no such registration trees have been approved.
RFC2717定义了一组注册树，其中可以注册URI方案，其中一个被称为IETF树，由IANA管理。RFC 2717建议IESG批准额外的注册树。然而，尚未批准此类登记树。
This document eliminates RFC 2717's distinction between different 'trees' for URI schemes; instead there is a single namespace for registered values. Within that namespace, there are values that are approved as meeting a set of criteria for URI schemes. Other scheme names may also be registered provisionally, without necessarily meeting those criteria. The intent of the registry is to:
本文档消除了RFC2717在URI方案的不同“树”之间的区别；相反，注册值只有一个名称空间。在该名称空间中，有一些值被批准为满足URI方案的一组标准。其他方案名称也可以临时注册，但不一定符合这些标准。注册处的目的是：
o provide a central point of discovery for established URI scheme names, and easy location of their defining documents; o discourage use of the same URI scheme name for different purposes; o help those proposing new URI scheme names to discern established trends and conventions, and avoid names that might be confused with existing ones; o encourage registration by setting a low barrier for provisional registrations.
o 为已建立的URI方案名称提供一个中心发现点，并方便地定位其定义文档；o不鼓励为不同目的使用相同的URI方案名称；o帮助那些提出新URI方案名称的人辨别既定的趋势和惯例，并避免可能与现有名称混淆的名称；o通过为临时注册设置较低的门槛来鼓励注册。
RFC 3987 [6] introduced a new protocol element, the Internationalized Resource Identifier (IRI), and defined a mapping between URIs and IRIs. There is no separate registry or registration process for 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 RFC 3987.
RFC 3987[6]引入了一个新的协议元素，即国际化资源标识符（IRI），并定义了URI和IRI之间的映射。IRIs没有单独的注册或注册流程。那些希望描述作为IRI有用的资源标识符的人应该定义相应的URI语法，并注意IRI的使用遵循RFC3987中定义的规则和转换。
Within this document, the key words MUST, MAY, SHOULD, REQUIRED, RECOMMENDED, and so forth are used within the general meanings established in RFC 2119 [1], within the context that they are requirements on future registration documents.
在本文件中，关键字“必须”、“可能”、“应该”、“要求”、“建议”等在RFC 2119[1]中确定的一般含义内使用，在其为未来注册文件要求的上下文中使用。
This section gives considerations for new URI schemes. Meeting these guidelines is REQUIRED for permanent URI scheme registration. Meeting these guidelines is also RECOMMENDED for provisional registration, as described in Section 3.
本节给出了新URI方案的注意事项。永久URI计划注册需要符合这些准则。如第3节所述，临时注册也建议符合这些指南。
The use and deployment of new URI schemes in the Internet infrastructure is costly; some parts of URI processing may be scheme-dependent, and deployed software already processes URIs of well-known schemes. Introducing a new URI scheme may require additional software, not only for client software and user agents but also in additional parts of the network infrastructure (gateways, proxies, caches) [11]. URI schemes constitute a single, global namespace; it is desirable to avoid contention over use of short, mnemonic scheme names. For these reasons, the unbounded registration of new schemes is harmful. New URI schemes SHOULD have clear utility to the broad Internet community, beyond that available with already registered URI schemes.
在互联网基础设施中使用和部署新的URI方案成本高昂；URI处理的某些部分可能依赖于方案，部署的软件已经处理了已知方案的URI。引入新的URI方案可能需要额外的软件，不仅针对客户端软件和用户代理，而且还针对网络基础设施的其他部分（网关、代理、缓存）[11]。URI方案构成一个单一的全局名称空间；希望避免因使用简短的助记方案名称而产生争用。基于这些原因，新计划的无限注册是有害的。除了已经注册的URI方案之外，新的URI方案应该对广泛的Internet社区具有明确的实用性。
RFC 3986 [5] 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. All URI scheme specifications MUST define their own syntax such that all strings matching their scheme-specific syntax will also match the <absolute-URI> grammar described in Section 4.3 of RFC 3986.
RFC 3986[5]定义了所有URI方案的通用语法，以及许多URI方案用于定义层次标识符的公共URI组件的语法。所有URI方案规范必须定义自己的语法，以便所有匹配其方案特定语法的字符串也将匹配RFC 3986第4.3节中描述的<absolute URI>语法。
New URI schemes SHOULD reuse the common URI components of RFC 3986 for the definition of hierarchical naming schemes. However, if there is a strong reason for a URI scheme not to use the hierarchical syntax, then the new scheme definition SHOULD follow the syntax of previously registered schemes.
新的URI方案应该重用RFC3986的公共URI组件来定义分层命名方案。但是，如果URI方案有充分的理由不使用分层语法，那么新的方案定义应该遵循以前注册的方案的语法。
URI schemes that are not intended for use with relative URIs SHOULD avoid use of the forward slash "/" character, which is used for hierarchical delimiters, and the complete path segments "." and ".." (dot-segments).
不用于相对URI的URI方案应避免使用正斜杠“/”字符（用于分层分隔符）以及完整的路径段“.”和“.”（点段）。
Avoid improper use of "//". The use of double slashes in the first part of a URI is not an artistic indicator that what follows is a URI: Double slashes are used ONLY when the syntax of the URI's <scheme-specific-part> contains a hierarchical structure as described in RFC 3986. In URIs from such schemes, the use of double slashes indicates that what follows is the top hierarchical element for a naming authority. (See Section 3.2 of RFC 3986 for more details.) URI 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：只有当URI的<scheme specific part>的语法包含RFC 3986中描述的层次结构时，才使用双斜杠。在此类方案的URI中，使用双斜杠表示下面是命名机构的顶级层次元素。（有关更多详细信息，请参阅RFC 3986的第3.2节。）在其<scheme specific part>中不包含一致层次结构的URI方案不应在“<scheme>：”字符串后使用双斜杠。
New URI schemes SHOULD clearly define the role of RFC 3986 [5] reserved characters in URIs of the scheme being defined. The syntax of the new scheme should be clear about which of the "reserved" set of characters (as defined in RFC 3986) are used as delimiters within the URIs of the new scheme, and when those characters must be escaped, versus when they may be used without escaping.
新的URI方案应明确定义RFC 3986[5]保留字符在所定义方案的URI中的角色。新方案的语法应该明确哪些“保留”字符集（如RFC 3986中定义）在新方案的URI中用作分隔符，以及这些字符何时必须转义，而何时可以不转义使用。
While URIs may or may not be useful as locators in practice, a URI 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方案定义本身必须清楚它的预期功能。不打算用作定位器的方案应描述如何通过获取该方案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 URI scheme.
对于充当定位器的方案，明确定义资源定位机制非常重要。根据URI方案的性质，这可能意味着不同的事情。
In many cases, new URI schemes are defined as ways to translate between other namespaces or protocols and the general framework of URIs. For example, the "ftp" URI scheme translates into the FTP protocol, while the "mid" URI scheme translates into a Message-ID identifier of an email message. For such schemes, the description of the mapping must be 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, might be represented in a valid URI. In particular, the mapping should describe the mechanisms for encoding binary or character strings within valid character sequences in a URI (See Section 2.6 for guidelines). If not all legal values or protocol interactions of the base standard can be represented using the URI scheme, the definition should be clear about which subset are allowed, and why.
在许多情况下，新的URI方案被定义为在其他名称空间或协议与URI的通用框架之间进行转换的方式。例如，“ftp”URI方案转换为ftp协议，“mid”URI方案转换为电子邮件的消息ID标识符。对于此类方案，映射的描述必须完整且足够详细，以便在两个方向上的映射都是清晰的：如何从URI映射到目标命名空间中的一个标识符或一组协议操作或名称，以及基本命名空间中的合法值或合法协议交互，可能在有效的URI中表示。特别是，映射应该描述在URI中有效字符序列内对二进制或字符串进行编码的机制（参见第2.6节了解指导原则）。如果不能使用URI方案表示基本标准的所有法律值或协议交互，则定义应明确允许哪些子集，以及为什么允许。
As part of the definition of how a URI identifies a resource, a URI scheme definition SHOULD define the applicable set of operations that may be performed on a resource using the URI as its identifier. A model for this is HTTP; an HTTP resource can be operated on by GET, POST, PUT, and a number of other operations available through the HTTP protocol. The URI scheme definition should describe all well-defined operations on the URI identifier, and what they are supposed to do.
作为URI如何标识资源定义的一部分，URI方案定义应定义可使用URI作为其标识符对资源执行的适用操作集。这方面的一个模型是HTTP；HTTP资源可以通过GET、POST、PUT和通过HTTP协议提供的许多其他操作进行操作。URI方案定义应该描述URI标识符上所有定义良好的操作，以及它们应该做什么。
Some URI schemes don't fit into the "information access" paradigm of URIs. For example, "telnet" provides location information for initiating a bi-directional data stream to a remote host; the only operation defined is to initiate the connection. In any case, the operations appropriate for a URI scheme should be documented.
一些URI方案不适合URI的“信息访问”范式。例如，“telnet”提供用于向远程主机发起双向数据流的位置信息；定义的唯一操作是启动连接。在任何情况下，都应该记录适用于URI方案的操作。
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”。重要的一点是，对该方案的定义进行了描述。
In general, URIs are used within a broad range of protocols and applications. Most commonly, URIs are used as references to resources within directories or hypertext documents, as hyperlinks to
一般来说，URI在广泛的协议和应用程序中使用。最常见的情况是，URI用作目录或超文本文档中资源的引用，作为指向的超链接
other resources. In some cases, a URI scheme is intended for use within a different, specific set of protocols or applications. If so, the scheme definition SHOULD describe the intended use and include references to documentation that define the applications and/or protocols cited.
其他资源。在某些情况下，URI方案旨在用于不同的特定协议集或应用程序中。如果是，方案定义应描述预期用途，并包括对定义所引用应用和/或协议的文件的引用。
When describing URI 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 RFC 3987 [6] and Section 2.5 of RFC 3986 [5] 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元素实际上是人类可读文本的表示，应注意不要在将字符编码为八位字节然后再编码为URI字符的方式中引入不必要的变化；有关指南，请参见RFC 3987[6]和RFC 3986[5]第2.5节。如果方案的URI包含任何文本字段，则方案定义必须描述字符的编码方式，以及与方案的IRIs的任何兼容性问题。
Definitions of URI schemes MUST be accompanied by a clear analysis of the security implications for systems that use the URI scheme; this follows the practice of Security Consideration sections within IANA registrations [3].
URI方案的定义必须伴随着对使用URI方案的系统的安全影响的清晰分析；这遵循IANA注册中安全考虑部分的做法[3]。
In particular, Section 7 of RFC 3986 [5] describes general security considerations for URI schemes. The definition of an individual URI scheme should note which of these apply to the specified scheme.
具体而言，RFC 3986[5]的第7节描述了URI方案的一般安全注意事项。单个URI方案的定义应注意其中哪些适用于指定的方案。
Section 3.1 of RFC 3986 defines the syntax of a URI scheme name. New scheme registrations MUST comply. Note that although scheme names are case insensitive, scheme names MUST be registered using lowercase letters.
RFC3986的第3.1节定义了URI方案名称的语法。新的计划注册必须遵守。请注意，尽管方案名称不区分大小写，但方案名称必须使用小写字母注册。
URI scheme names should be short, but also sufficiently descriptive and distinguished to avoid problems.
URI方案名称应简短，但也应具有足够的描述性和可区分性，以避免出现问题。
Avoid 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 7.4 of RFC 3978 [4].)
避免使用可能导致IETF规范和Internet协议中使用名称的权限出现问题的名称或其他符号。例如，请注意商标和服务商标名称。（见RFC 3978[4]第7.4节）
Avoid using names that are either very general purpose or associated in the community with some other application or protocol. Avoid scheme names that are overly general or grandiose in scope (e.g., that allude to their "universal" or "standard" nature when the described namespace is not.)
避免使用非常通用或社区中与其他应用程序或协议关联的名称。避免使用范围过于笼统或宏大的方案名称（例如，当所描述的名称空间不适用时，暗示其“通用”或“标准”性质）
Organizations that desire a private name space for URI scheme names are encouraged to use a prefix based on their domain name, expressed in reverse order. For example, a URI scheme name of com-example-info might be registered by the vendor that owns the example.com domain name.
鼓励希望为URI方案名称提供私有名称空间的组织使用基于其域名的前缀，以相反顺序表示。例如，拥有example.com域名的供应商可能会注册com example info的URI方案名称。
While the guidelines in Section 2 are REQUIRED for permanent registration, they are RECOMMENDED for provisional registration. For a provisional registration, the following are REQUIRED:
虽然永久注册需要第2节中的指南，但建议临时注册。临时注册需具备以下条件：
o The scheme name meets the syntactic requirements of Section 2.8. o There is not already an entry with the same URI scheme name. (In the unfortunate case that there are multiple, different uses of the same scheme name, the IESG may approve a request to modify an existing entry to note the separate use.) o Contact information identifying the person supplying the registration is included. Previously unregistered URI schemes discovered in use may be registered by third parties on behalf of those who created the URI scheme; in this case, both the registering party and the scheme creator SHOULD be identified. o If no permanent, citable specification for the URI scheme definition is included, credible reasons for not providing it should be given. o A valid Security Considerations section, as required by Section 6 of [3]. o If the scheme definition does not meet the guidelines laid out in Section 2, the differences and reasons SHOULD be noted.
o 方案名称符合第2.8节的语法要求。o尚未存在具有相同URI方案名称的条目。（在不幸的情况下，同一计划名称有多个不同的用途，IESG可批准修改现有条目的请求，以说明单独的用途。）o包括识别提供注册的人员的联系信息。在使用中发现的先前未注册的URI方案可由第三方代表创建该URI方案的人员进行注册；在这种情况下，应同时识别注册方和方案创建者。o如果未包含URI方案定义的永久性、可引用的规范，则应给出不提供该规范的可信理由。o根据[3]第6节的要求，提供有效的安全考虑条款。o如果计划定义不符合第2节中列出的指南，则应注意差异和原因。
In some circumstances, it is appropriate to note a URI scheme that was once in use or registered but for whatever reason is no longer in common use or the 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 to where the scheme was previously defined or documented.
在某些情况下，宜注意曾经使用或注册过的URI方案，但由于任何原因不再常用或不建议使用。在这种情况下，个人可以请求将URI方案注册为“历史”（新注册或作为现有注册的更新）。任何不再通用的方案可指定为历史方案；注册应包含一些指示，说明该计划之前在何处定义或记录。
The URI registration process is described in the terminology of [3]. The registration process is an optional mailing list review, followed by "Expert Review". The registration request should note the desired status. The Designated Expert will evaluate the request against the criteria of the requested status. In the case of a permanent registration request, the Designated Expert may:
URI注册过程在[3]的术语中描述。注册过程是可选的邮件列表审查，然后是“专家审查”。注册请求应注明所需状态。指定专家将根据所请求的地位标准对请求进行评估。对于永久注册申请，指定专家可：
o Accept the URI scheme name for permanent registration. o Suggest provisional registration instead. o Request IETF review and IESG approval; in the meanwhile, suggest provisional registration.
o 接受永久注册的URI方案名称。o建议临时注册。o请求IETF审查和IESG批准；同时，建议临时注册。
URI scheme definitions contained within other IETF documents (Informational, Experimental, or Standards-Track RFCs) must also undergo Expert Review; in the case of Standards-Track documents, permanent registration status approval is required.
其他IETF文件（信息、实验或标准跟踪RFC）中包含的URI方案定义也必须经过专家审查；对于标准跟踪文件，需要获得永久注册状态批准。
Someone wishing to register a URI scheme SHOULD:
希望注册URI方案的人应：
1. Check the IANA URI scheme registry to see whether or not there is already an entry for the desired name. If there is already an entry under the name, choose a different URI scheme name. 2. Prepare a URI scheme registration template, as specified in Section 5.4. The URI scheme registration template may be contained in an Internet Draft, alone or as part of some other protocol specification. The template may also be submitted in some other form (as part of another document or as a stand-alone document), but the contents will be treated as an "IETF Contribution" under the guidelines of RFC 3978 [4]. 3. Send a copy of the template or a pointer to the containing document (with specific reference to the section with the template) to the mailing list uri-review@ietf.org, requesting review. In addition, request review on other mailing lists as appropriate. For example, general discussion of URI syntactical issues could be discussed on uri@w3.org; schemes for a network protocol could 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 requests. 4. 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.
1. 检查IANA URI方案注册表，查看是否已经存在所需名称的条目。如果名称下已存在条目，请选择其他URI方案名称。2.按照第5.4节的规定，准备URI方案注册模板。URI方案注册模板可以单独包含在互联网草案中，或者作为某些其他协议规范的一部分。模板也可以以其他形式提交（作为其他文件的一部分或作为独立文件），但根据RFC 3978[4]的指导原则，其内容将被视为“IETF贡献”。3.向邮件列表uri发送模板副本或指向包含文档的指针（具体引用带有模板的部分）-review@ietf.org，要求覆核。此外，酌情要求审查其他邮件列表。例如，URI语法问题的一般性讨论可以在uri@w3.org; 网络协议的方案可以在该协议的邮件列表上讨论。留出合理的时间进行讨论和评论。对于永久注册申请而言，四周是合理的。4.回应审查意见，并根据需要对拟议注册进行修订，使其符合本文件中给出的指南。
5. Submit the (possibly updated) registration template (or pointer to document containing it) to IANA at iana@iana.org, specifying whether 'permanent' or 'provisional' registration is requested.
5. 将（可能更新的）注册模板（或指向包含该模板的文档的指针）提交给IANA，地址为iana@iana.org，指定是请求“永久”注册还是“临时”注册。
Upon receipt of a URI scheme registration request,
收到URI方案注册请求后，
1. IANA checks the submission for completeness; if sections are missing or citations are not correct, IANA rejects the registration request. 2. IANA checks the current registry for a entry with the same name; if such a registry exists, IANA rejects the registration request. 3. IANA requests Expert Review of the registration request against the corresponding guidelines. 4. The Designated Expert may request additional review or discussion, as necessary. 5. If Expert Review recommends registration 'provisional' or 'permanent' registration, IANA adds the registration to the appropriate registry. 6. Unless Expert Review has explicitly rejected the registration request within two weeks, IANA should automatically add the registration in the 'provisional' registry.
1. IANA检查提交文件的完整性；如果章节缺失或引用不正确，IANA将拒绝注册请求。2.IANA检查当前注册表中是否有同名条目；如果存在这样的注册表，IANA将拒绝注册请求。3.IANA要求根据相应指南对注册申请进行专家审查。4.必要时，指定专家可要求进行额外审查或讨论。5.如果专家评审建议注册为“临时”或“永久”注册，IANA会将注册添加到相应的注册中。6.除非专家评审在两周内明确拒绝注册请求，否则IANA应自动将注册添加到“临时”注册中。
Either based on an explicit request or independently initiated, the Designated Expert or IESG may request the upgrade of a 'provisional' registration to a 'permanent' one. In such cases, IANA should move the corresponding entry from the provisional registry.
指定专家或IESG可根据明确请求或独立发起请求将“临时”注册升级为“永久”注册。在这种情况下，IANA应将相应条目从临时注册表中移出。
Registrations may be updated in each 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 may be updated by the original registrant or anyone designated by the original registrant. In addition, the IESG may reassign responsibility for a provisional registration scheme, or may 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 may 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' may be requested by anyone authorized to update the provisional registration.
从“临时”状态过渡到“永久”状态的请求和批准方式与新的“永久”注册相同。从“永久”状态过渡到“历史”状态需要IESG批准。授权更新临时注册的任何人均可要求从“临时”过渡到“历史”。
This template describes the fields that must be supplied in a URI scheme registration request:
此模板描述URI方案注册请求中必须提供的字段：
URI scheme name. See Section 2.8 for guidelines. Status. This reflects the status requested, and should be one of 'permanent', 'provisional', or 'historical'. URI scheme syntax. See Section 2.2 for guidelines. URI scheme semantics. See Section 2.3 and Section 2.4 for guidelines. Encoding considerations. See Section 2.3 and Section 2.6 for guidelines. Applications/protocols that use this URI scheme name. Applications and/or protocols that use this URI scheme name; see Section 2.5. Interoperability considerations. If you are aware of any details regarding your scheme that might impact interoperability, please identify them here. For example: proprietary or uncommon encoding method; inability to support multibyte character sets; incompatibility with types or versions of any underlying protocol. Security considerations. See Section 2.7 for guidelines. Contact. Person (including contact information) to contact for further information. Author/Change controller. Person (including contact information) authorized to change this, if a provisional registration. References. Include full citations for all referenced documents. Registration templates for provisional registration may be included in an Internet Draft; when the documents expire or are approved for publication as an RFC, the registration will be updated.
URI方案名称。有关指南，请参见第2.8节。地位这反映了请求的状态，应该是“永久”、“临时”或“历史”状态之一。URI方案语法。有关指南，请参见第2.2节。URI模式语义。有关指南，请参见第2.3节和第2.4节。编码注意事项。有关指南，请参见第2.3节和第2.6节。使用此URI方案名称的应用程序/协议。使用此URI方案名称的应用程序和/或协议；见第2.5节。互操作性考虑。如果您知道有关您的方案的任何可能影响互操作性的详细信息，请在此处进行标识。例如：专有或不常见的编码方法；无法支持多字节字符集；与任何基础协议的类型或版本不兼容。安全考虑。有关指南，请参见第2.7节。联系联系人（包括联系信息）以获取更多信息。作者/更改控制器。如果是临时注册，有权更改此信息的人员（包括联系信息）。参考资料。包括所有引用文件的完整引用。临时注册的注册模板可包含在互联网草稿中；当文件到期或批准作为RFC发布时，将更新注册。
This document replaces the current "URL Scheme" registry with a new Uniform Resource Identifier scheme registry, and establishes a new registration template and a new process for registration. The process is based on [3] "Expert Review" with an initial (optional) mailing list review.
本文档使用新的统一资源标识符方案注册表替换当前的“URL方案”注册表，并建立新的注册模板和新的注册过程。该过程基于[3]“专家评审”和初始（可选）邮件列表评审。
The template has an additional field for the status of the URI name scheme, and the procedures for entering new name schemes have been augmented. Section 5 establishes the process for new URI scheme registration.
该模板有一个用于URI名称方案状态的附加字段，并且输入新名称方案的过程已得到扩展。第5节建立了新URI方案注册的流程。
To transition to the new registry, all URL name schemes in the existing table should be entered as URI schemes, with 'permanent' status.
要转换到新注册表，现有表中的所有URL名称方案都应作为URI方案输入，并具有“永久”状态。
All registered values are expected to contain accurate security consideration sections; 'permanent' registered scheme names are expected to contain complete definitions.
所有注册值均应包含准确的安全考虑部分；'永久注册的方案名称应包含完整的定义。
Information concerning possible security vulnerabilities of a protocol may change over time. Consequently, claims as to the security properties of a registered URI scheme may change as well. As new vulnerabilities are discovered, information about such vulnerabilities may need to be attached to existing documentation, so that users are not misled as to the true security properties of a registered URI scheme.
有关协议可能存在的安全漏洞的信息可能会随时间而变化。因此，关于已注册URI方案的安全属性的声明也可能改变。当发现新的漏洞时，可能需要将有关此类漏洞的信息附加到现有文档中，以便用户不会对已注册URI方案的真实安全属性产生误解。
Many thanks to 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 versions.
非常感谢保罗·霍夫曼、艾拉·麦克唐纳、罗伊·菲尔丁、斯图·韦贝尔、托尼·哈蒙德、查尔斯·林赛、马克·贝克和其他团队成员uri@w3.org他们对早期版本的评论的邮件列表。
Parts of this document are based on [7], [8] and [10]. Some of the ideas about use of URIs were taken from the "Architecture of the World Wide Web" [11].
本文件的部分内容基于[7]、[8]和[10]。关于URI使用的一些想法取自“万维网架构”[11]。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[2] 护城河，R.，“瓮语法”，RFC 21411997年5月。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[4] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[4] Bradner，S.，“IETF在贡献中的权利”，BCP 78，RFC 3978，2005年3月。
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[5] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[6] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[6] Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
[7] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.
[7] Petke，R.和I.King，“URL方案名称的注册程序”，BCP 35，RFC 2717，1999年11月。
[8] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, "Guidelines for new URL Schemes", RFC 2718, November 1999.
[8] Masinter，L.，Alvestrand，H.，Zigmond，D.，和R.Petke，“新URL方案指南”，RFC 2718，1999年11月。
[9] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.
[9] Daigle，L.，van Gulik，D.，Iannella，R.，和P.Faltstrom，“统一资源名（URN）命名空间定义机制”，BCP 66，RFC 3406，2002年10月。
[10] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[10] Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[11] W3C Technical Architecture Group, "Architecture of the World Wide Web, Volume One", December 2004, <http://www.w3.org/TR/webarch/>.
[11] W3C技术架构组，“万维网架构，第一卷”，2004年12月<http://www.w3.org/TR/webarch/>.
Authors' Addresses
作者地址
Tony Hansen AT&T Laboratories 200 Laurel Ave. Middletown, NJ 07748 USA
美国新泽西州米德尔顿劳雷尔大道200号托尼·汉森AT&T实验室，邮编：07748
EMail: tony+urireg@maillennium.att.com
EMail: tony+urireg@maillennium.att.com
Ted Hardie Qualcomm, Inc. 675 Campbell Technology Parkway Campbell, CA USA
Ted Hardie Qualcomm，Inc.美国加利福尼亚州坎贝尔市坎贝尔科技园区675号
EMail: hardie@qualcomm.com
EMail: hardie@qualcomm.com
Larry Masinter Adobe Systems 345 Park Ave San Jose, CA 95110 US
美国加利福尼亚州圣何塞公园大道345号Larry Masinter Adobe Systems 95110
Phone: +1 408 536 3024
EMail: LMM@acm.org
URI: http://larry.masinter.net
Phone: +1 408 536 3024
EMail: LMM@acm.org
URI: http://larry.masinter.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。