Network Working Group R. Petke
Request for Comments: 2717 UUNET Technologies
BCP: 35 I. King
Category: Best Current Practice Microsoft Corporation
November 1999
Network Working Group R. Petke
Request for Comments: 2717 UUNET Technologies
BCP: 35 I. King
Category: Best Current Practice Microsoft Corporation
November 1999
Registration Procedures for URL Scheme Names
URL方案名称的注册程序
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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document defines the process by which new URL scheme names are registered.
本文档定义了注册新URL方案名称的过程。
A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet. RFC 2396 [1] defines the general syntax and semantics of URIs, and, by inclusion, URLs. URLs are designated by including a "<scheme>:" and then a "<scheme-specific-part>". Many URL schemes are already defined, however, new schemes may need to be defined in the future in order to accommodate new Internet protocols and/or procedures.
统一资源定位器（URL）是可通过Internet访问的资源位置的紧凑字符串表示形式。RFC 2396[1]定义了URI的一般语法和语义，并通过包含定义了URL。URL通过包含“<scheme>：”和“<scheme-specific-part>”来指定。许多URL方案已经定义，但是，将来可能需要定义新的方案，以适应新的Internet协议和/或过程。
A registration process is needed to ensure that the names of all such new schemes are guaranteed not to collide. Further, the registration process ensures that URL schemes intended for wide spread, public use are developed in an orderly, well-specified, and public manner.
需要一个登记程序，以确保所有此类新方案的名称不会发生冲突。此外，注册过程确保以有序、明确和公开的方式开发用于广泛公共用途的URL方案。
This document defines the registration procedures to be followed when new URL schemes are created. A separate document, RFC 2718, Guidelines for URL Schemes [2], provides guidelines for the creation of new URL schemes. The primary focus of this document is on the <scheme> portion of new URL schemes, referred to as the "scheme name" throughout this document.
本文档定义了创建新URL方案时要遵循的注册过程。另一份文件RFC 2718，URL方案指南[2]，提供了创建新URL方案的指南。本文档主要关注新URL方案的<scheme>部分，在本文档中称为“方案名称”。
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 RFC 2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
In order to increase the efficiency and flexibility of the URL scheme name registration process, the need is recognized for multiple registration "trees". The registration requirements and specific registration procedures for each tree differ, allowing the overall registration procedure to accommodate the different natural requirements for URL schemes. For example, a scheme that will be recommended for wide support and implementation by the Internet community requires a more complete review than a scheme intended to be used for resources associated with proprietary software.
为了提高URL方案名称注册过程的效率和灵活性，需要多个注册“树”。每棵树的注册要求和具体注册程序各不相同，允许整个注册程序适应URL方案的不同自然要求。例如，一个将被互联网社区广泛支持和实施的方案需要比一个用于与专有软件相关的资源的方案更全面的审查。
The first step in registering a new URL scheme name is to determine which registration tree the scheme should be registered in. Determination of the proper registration tree is based on the intended use for the new scheme and the desired syntax for the scheme name.
注册新URL方案名称的第一步是确定该方案应在哪个注册树中注册。正确注册树的确定基于新方案的预期用途和方案名称所需的语法。
This document will discuss in detail the tree that reflects current practice, under IETF ownership and control. It will also set forth an outline to assist authors in creating new trees to address differing needs for wide acceptance and interoperability, ease of creation and use, and type and "strength" of ownership.
本文件将详细讨论IETF所有权和控制下反映当前实践的树。它还将提出一个大纲，帮助作者创建新的树，以满足广泛接受和互操作性、易于创建和使用以及所有权类型和“强度”的不同需求。
The IETF tree is intended for URL schemes of general interest to the Internet community. The tree exists for URL schemes that require a substantive review and approval process. It is expected that applicability statements for particular applications will be published from time to time that recommend implementation of, and support for, URL schemes that have proven particularly useful in those contexts.
IETF树用于互联网社区普遍感兴趣的URL方案。该树适用于需要实质性审查和批准流程的URL方案。预计将不时发布特定应用程序的适用性声明，建议实施和支持在这些环境中证明特别有用的URL方案。
From time to time and as required by the community, the IESG may create new top-level registration trees. These trees may require significant, little or no registration, and may allow change control to rest in the hands of individuals or groups other than IETF. A new tree should only be created if no existing tree can be shown to address the set of needs of some sector of the community.
根据社区的要求，IESG可不时创建新的顶级注册树。这些树可能需要大量、少量或不需要注册，并且可能允许变更控制权掌握在IETF以外的个人或团体手中。只有在无法显示现有树以满足社区某些部门的需求时，才应创建新树。
All new URL schemes, regardless of registration tree, MUST conform to the generic syntax for URLs as specified in RFC 2396.
所有新的URL方案，无论注册树如何，都必须符合RFC 2396中指定的URL通用语法。
Registration in the IETF tree requires publication of the URL scheme syntax and semantics in either an Informational or Standards Track RFC. In general, the creation of a new URL scheme requires a Standards Track RFC. An Informational RFC may be employed for registration only in the case of a URL scheme which is already in wide usage and meets other standards set forth in RFC 2718, such as "demonstrated utility" within the Internet Architecture; the IESG shall have broad discretion in determining whether an Informational RFC is suitable in any given case, and may either recommend changes to such document prior to publication, or reject it for publication. An Informational RFC purporting to describe a URL scheme shall not be published without IESG approval. This is a departure from practice for Informational RFCs as set forth in RFC 2026, for the purpose of ensuring that the registration of URL schemes shall serve the best interests of the Internet community.
在IETF树中注册需要在信息或标准跟踪RFC中发布URL方案语法和语义。通常，创建新的URL方案需要标准跟踪RFC。仅当URL方案已被广泛使用且符合RFC 2718中规定的其他标准（例如互联网架构内的“演示实用程序”）时，信息RFC才可用于注册；IESG在确定信息RFC是否适用于任何给定情况时具有广泛的自由裁量权，并可在发布前建议对此类文件进行更改，或拒绝发布。未经IESG批准，不得发布旨在描述URL方案的信息性RFC。这与RFC 2026中规定的信息RFC的做法不同，其目的是确保URL方案的注册符合互联网社区的最佳利益。
The NAMES of schemes registered in the IETF tree MUST NOT contain the dash (also known as the hyphen and minus sign) character ('-') USASCII value 2Dh. Use of this character can cause confusion with schemes registered in alternative trees (see section 3.3).
IETF树中注册的方案名称不得包含破折号（也称为连字符和减号）字符（“-”）USASCII值2Dh。使用此字符可能会导致与在替代树中注册的方案混淆（参见第3.3节）。
An analysis of the security issues inherent in the new URL scheme is REQUIRED. (This is in accordance with the basic requirements for all IETF protocols.) URL schemes registered in the IETF tree should not introduce additional security risks into the Internet Architecture. For example, URLs should not embed information which should remain confidential, such as passwords, nor should new schemes subvert the security of existing schemes or protocols (i.e. by layering or tunneling).
需要分析新URL方案中固有的安全问题。（这符合所有IETF协议的基本要求。）在IETF树中注册的URL方案不应给互联网体系结构带来额外的安全风险。例如，URL不应嵌入应保密的信息，如密码，新方案也不应破坏现有方案或协议的安全性（即通过分层或隧道）。
The "owner" of a URL scheme name registered in the IETF tree is assumed to be the IETF itself. Modification or alteration of the specification requires the same level of processing (e.g. Informational or Standards Track RFC) as used for the initial registration. Schemes originally defined via an Informational RFC may, however, be replaced with Standards Track documents.
在IETF树中注册的URL方案名称的“所有者”被假定为IETF本身。规范的修改或变更需要与初始注册相同的处理水平（例如信息或标准跟踪RFC）。然而，最初通过信息RFC定义的方案可能会被标准跟踪文件所取代。
While public exposure and review of a URL scheme created in an alternative tree is not required, using the IETF Internet-Draft mechanism for peer review is strongly encouraged to improve the quality of the specification. RFC publication of alternative tree URL schemes is encouraged but not required. Material may be published as an Informational RFC by sending it to the RFC Editor (please follow the instructions to RFC authors, RFC 2223 [3]).
虽然不需要公开披露和审查在替代树中创建的URL方案，但强烈鼓励使用IETF互联网草案机制进行同行审查，以提高规范的质量。鼓励但不要求RFC发布替代树URL方案。通过将材料发送至RFC编辑器（请遵循RFC作者须知，RFC 2223[3]），可以将材料发布为信息性RFC。
The defining document for an alternative tree may require public exposure and/or review for schemes defined in that tree via a mechanism other than the IETF Internet-Draft mechanism.
替代树的定义文件可能需要通过IETF互联网草案机制以外的机制公开和/或审查该树中定义的方案。
URL schemes created in an alternative tree must conform to the generic URL syntax, RFC 2396. The tree's defining document may set forth additional syntax and semantics requirements above and beyond those specified in RFC 2396.
在替代树中创建的URL方案必须符合通用URL语法RFC 2396。树的定义文档可能会规定RFC 2396规定之外的额外语法和语义要求。
All new URL schemes SHOULD follow the Guidelines for URL Schemes, set forth in RFC 2718 [2].
所有新的URL方案应遵循RFC 2718[2]中规定的URL方案指南。
An analysis of the security issues inherent in the new URL scheme is encouraged. Regardless of what security analysis is or is not performed, all descriptions of security issues must be as accurate as possible. In particular, a statement that there are "no security issues associated with this scheme" must not be confused with "the security issues associates with this scheme have not been assessed" or "the security issues associated with this scheme cannot be predicted because of <reason>".
鼓励对新URL方案中固有的安全问题进行分析。无论是否执行安全分析，所有安全问题的描述都必须尽可能准确。特别是，不得将“不存在与此方案相关的安全问题”的声明与“未评估与此方案相关的安全问题”或“由于<原因>无法预测与此方案相关的安全问题”混淆。
There is absolutely no requirement that URL schemes created in an alternative tree be secure or completely free from risks. Nevertheless, the tree's defining document must set forth the standard for security considerations, and in any event all known security risks SHOULD be identified.
在替代树中创建的URL方案绝对不要求是安全的或完全没有风险的。然而，树的定义文件必须规定安全考虑的标准，并且在任何情况下都应该识别所有已知的安全风险。
Change control must be defined for a new tree. Change control may be vested in the IETF, or in an individual, group or other entity. The change control standard for the tree must be approved by the IESG.
必须为新树定义更改控制。变更控制权可归属于IETF，或个人、集团或其他实体。树木的变更控制标准必须经IESG批准。
The syntax for alternative trees shall be as follows: each tree will be identified by a unique prefix, which must be established in the same fashion as a URL scheme name in the IETF tree, except that the prefix must be defined by a Standards Track document. Scheme names in the new tree are then constructed by prepending the prefix to an identifier unique to each scheme in that tree, as prescribed by that tree's identifying document:
备选树的语法应如下所示：每个树将由唯一前缀标识，该前缀必须以与IETF树中URL方案名称相同的方式建立，但前缀必须由标准跟踪文件定义。然后，按照树的标识文档的规定，通过将前缀前置到树中每个方案唯一的标识符来构造新树中的方案名称：
<prefix>'-'<tree-specific identifier>
<prefix>'-'<tree-specific identifier>
For instance, the "foo" tree would allow creation of scheme names of the form: "foo-blahblah:" and "foo-bar:", where the tree prescribes an arbitrary USASCII string following the tree's unique prefix.
例如，“foo”树允许创建格式为“foo blahblah:”和“foo bar:”的方案名称，其中树在树的唯一前缀后规定了任意USASCII字符串。
The first step in registering a new URL scheme in the IETF tree is to publish an IETF Internet-Draft detailing the syntax and semantics of the proposed scheme. The draft must, minimally, address all of the items covered by the template provided in section 6 of this document.
在IETF树中注册新的URL方案的第一步是发布一份IETF Internet草案，详细说明拟议方案的语法和语义。草案必须至少涉及本文件第6节提供的模板所涵盖的所有项目。
After all issues raised during a review period of no less than 4 weeks have been addressed, submit the draft to the IESG for review.
在不少于4周的审查期内提出的所有问题得到解决后，将草案提交给IESG审查。
The IESG will review the proposed new scheme and either refer the scheme to a working group (existing or new) or directly present the scheme to the IESG for a last call. In the former case, the working group is responsible for submitting a final version of the draft to the IESG for approval at such time as it has received adequate review and deliberation.
IESG将审查拟议的新计划，并将该计划提交给工作组（现有或新），或直接将该计划提交给IESG进行最后一次通话。在前一种情况下，工作组负责将草案的最终版本提交给IESG，供其在获得充分审查和审议后批准。
Registration of URL schemes created in an alternative tree may be formal, through IETF documents, IANA registration, or other acknowledged organization; informal, through a mailing list or other publication mechanism; or nonexistent. The registration mechanism must be documented for each alternative tree, and must be consistent for all URL scheme names created in that tree.
通过IETF文档、IANA注册或其他公认的组织，在替代树中创建的URL方案的注册可以是正式的；非正式，通过邮件列表或其他发布机制；或者根本不存在。必须为每个备选树记录注册机制，并且必须对该树中创建的所有URL方案名称保持一致。
It is the responsibility of the creator of the tree's registration requirements to establish that the registration mechanism is workable as described; it is within the discretion of the IESG to reject the document describing a tree if it determines the registration mechanism is impractical or creates an undue burden on a party who
树的注册要求的创建者有责任确定注册机制如所述是可行的；如果IESG确定登记机制不切实际或对以下一方造成不当负担，则IESG可自行决定拒绝描述树木的文件：
will not accept it. (For instance, if an IANA registration mechanism is proposed, IESG might reject the tree if its mechanism would create undue liability on the part of IANA.)
我不会接受的。（例如，如果提议IANA注册机制，IESG可能会拒绝该树，如果其机制会对IANA造成不适当的责任。）
While the template in section 6 of this document is intended to apply to URL scheme names in the IETF tree, it is also offered as a guideline for those documenting alternative trees.
虽然本文件第6节中的模板旨在应用于IETF树中的URL方案名称，但它也作为记录替代树的指南提供。
URL schemes created in the IETF tree are "owned" by the IETF itself and may be changed, as needed, by updating the RFC that describes them. Schemes described by Standards Track RFC but be replaced with new Standards Track RFCs. Informational RFCs may be replaced by new Informational RFCs or Standards Track RFCs.
在IETF树中创建的URL方案由IETF本身“拥有”，并可根据需要通过更新描述它们的RFC进行更改。标准描述的方案跟踪RFC，但可以用新的标准跟踪RFC替换。信息性RFC可由新的信息性RFC或标准跟踪RFC替代。
URL schemes in an alternative tree that are undocumented (as allowed by that tree's rules) may be changed by their owner at any time without notifying the IETF.
替代树中未记录的URL方案（如该树的规则所允许）可由其所有者随时更改，而无需通知IETF。
URL schemes created in an alternative tree that have been documented by an Informational RFC, may be changed at any time by the owner, however, an updated Informational RFC which details the changes made, must be submitted to the IESG.
在信息RFC记录的备选树中创建的URL方案可由所有者随时更改，但是，必须向IESG提交更新的信息RFC，详细说明所做的更改。
The owner of a URL scheme registered in an alternative tree and documented by an Informational RFC may pass responsibility for the registration to another person or agency by informing the IESG.
在替代树中注册并由信息RFC记录的URL方案的所有者可以通过通知IESG将注册责任转移给另一个人或机构。
The IESG may reassign responsibility for a URL scheme registered in an alternative tree and documented by an Informational RFC. The most common case of this will be to enable changes to be made to schemes where the scheme name is privately owned by the rules of its tree, and the owner of the scheme name has died, moved out of contact or is otherwise unable to make changes that are important to the community.
IESG可以重新分配在替代树中注册并由信息RFC记录的URL方案的责任。最常见的情况是，如果方案名称由其树的规则私有，并且方案名称的所有者已去世、失去联系或无法进行对社区重要的更改，则可以对方案进行更改。
The IESG may reclassify a URL scheme created in an alternative tree and documented via an Informational RFC as "historic" if it determines that the scheme is no longer in use.
IESG可以将在替代树中创建并通过信息RFC记录的URL方案重新分类为“历史”，如果它确定该方案不再使用。
The following issues should be addressed when documenting a new URL scheme:
在记录新的URL方案时，应解决以下问题：
URL scheme name.
URL方案名称。
URL scheme syntax. This should be expressed in a clear and concise manner. The use of ABNF is encouraged. Please refer to RFC 2718 for guidance on designing and explaining your scheme's syntax.
URL方案语法。这一点应以明确和简洁的方式表达。鼓励使用ABNF。有关设计和解释方案语法的指导，请参考RFC 2718。
Character encoding considerations. It is important to identify what your scheme supports in this regard. It is obvious that for interoperability, it is best if there is a means to support character sets beyond USASCII, but especially for private schemes, this may not be the case.
字符编码注意事项。确定您的计划在这方面支持什么是很重要的。很明显，对于互操作性，最好有一种方法支持USASCII以外的字符集，但特别是对于私有方案，情况可能并非如此。
Intended usage. What sort of resource is being identified? If this is not a 'resource' type of URL (e.g. mailto:), explain the action that should be initiated by the consumer of the URL. If there is a MIME type associated with this resource, please identify it.
预期用途。正在识别哪种资源？如果这不是“资源”类型的URL（例如mailto:），请解释URL使用者应发起的操作。如果存在与此资源关联的MIME类型，请标识它。
Applications and/or protocols which use this URL scheme name. Including references to documentation which defines the applications and/or protocols cited is especially useful.
使用此URL方案名称的应用程序和/或协议。包括对定义引用的应用程序和/或协议的文档的引用尤其有用。
Interoperability considerations. If you are aware of any details regarding your scheme which 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 underlying protocol (if scheme is tunneled over another protocol).
互操作性考虑。如果您知道有关您的方案的任何可能影响互操作性的详细信息，请在此处进行标识。例如：专有或不常见的编码方法；无法支持多字节字符集；与基础协议的类型或版本不兼容（如果方案通过另一协议进行隧道传输）。
Security considerations.
安全考虑。
Relevant publications.
相关出版物。
Person & email address to contact for further information.
联系人和电子邮件地址，以获取更多信息。
Author/Change controller.
作者/更改控制器。
Applications and/or protocols which use this URL scheme name.
使用此URL方案名称的应用程序和/或协议。
Information that creates or updates a registration needs to be authenticated.
创建或更新注册的信息需要经过身份验证。
Information concerning possible security vulnerabilities of a protocol may change over time. Consequently, claims as to the security properties of a registered URL 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 URL scheme.
有关协议可能存在的安全漏洞的信息可能会随时间而变化。因此，关于已注册URL方案的安全属性的声明也可能改变。当发现新的漏洞时，可能需要将有关此类漏洞的信息附加到现有文档中，这样用户就不会对已注册URL方案的真实安全属性产生误解。
If the IESG agrees to delegate the registration and change control functions of an alternative tree to a group or individual outside of the IETF, that group or individual should have sufficient security procedures in place to authenticate registration changes.
如果IESG同意将替代树的注册和变更控制功能委托给IETF之外的团体或个人，则该团体或个人应具有足够的安全程序，以验证注册变更。
[1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[1] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[2] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke, "Guidelines for new URL Schemes", RFC 2718, November 1999.
[2] Masinter，L.，Alvestrand，H.，Zigmond，D.和R.Petke，“新URL方案指南”，RFC 2718，1999年11月。
[3] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[3] Postel，J.和J.Reynolds，“RFC作者须知”，RFC 2223，1997年10月。
Rich Petke UUNET Technologies 5000 Britton Road P. O. Box 5000 Hilliard, OH 43026-5000 USA
Rich Petke UUNET Technologies美国俄亥俄州希利亚德布里顿路5000号邮政信箱43026-5000
Phone: +1 614 723 4157
Fax: +1 614 723 8407
EMail: rpetke@wcom.net
Phone: +1 614 723 4157
Fax: +1 614 723 8407
EMail: rpetke@wcom.net
Ian King Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA Phone: +1 425-703-2293 Fax: +1 425-936-7329 EMail: iking@microsoft.com
Ian King Microsoft Corporation One Microsoft Way Redmond，WA 98052-6399美国电话：+1 425-703-2293传真：+1 425-936-7329电子邮件：iking@microsoft.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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编辑功能的资金目前由互联网协会提供。