Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 6963 Cisco Systems, Inc.
BCP: 183 May 2013
Category: Best Current Practice
ISSN: 2070-1721
Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 6963 Cisco Systems, Inc.
BCP: 183 May 2013
Category: Best Current Practice
ISSN: 2070-1721
A Uniform Resource Name (URN) Namespace for Examples
例如，统一资源名（URN）命名空间
Abstract
摘要
This document defines a Uniform Resource Name (URN) namespace identifier enabling the generation of URNs that are appropriate for use in documentation and in URN-related testing and experimentation.
本文档定义了统一资源名称（URN）命名空间标识符，支持生成适合在文档和URN相关测试和实验中使用的URN。
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/rfc6963.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6963.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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
2. Terminology .....................................................2
3. Completed Namespace Definition Template .........................3
4. Namespace Considerations ........................................4
5. Community Considerations ........................................5
6. Security Considerations .........................................5
7. IANA Considerations .............................................5
8. References ......................................................6
Appendix A. Acknowledgements .......................................7
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Completed Namespace Definition Template .........................3
4. Namespace Considerations ........................................4
5. Community Considerations ........................................5
6. Security Considerations .........................................5
7. IANA Considerations .............................................5
8. References ......................................................6
Appendix A. Acknowledgements .......................................7
The Uniform Resource Name (URN) technology [RFC2141] provides a way to generate persistent, location-independent resource identifiers. The primary "scope" of a URN is provided by its namespace identifier (NID). As specified in [RFC3406], there are three kinds of NIDs: formal, informal, and experimental. Most of the NIDs registered to date are formal. As far as is known, the few informal namespaces have not been widely used, and the experimental namespaces are by definition unregistered.
统一资源名（URN）技术[RFC2141]提供了一种生成持久的、与位置无关的资源标识符的方法。URN的主要“作用域”由其名称空间标识符（NID）提供。如[RFC3406]所述，有三种类型的NID：正式的、非正式的和实验性的。迄今为止注册的大多数国家情报局都是正式的。就我们所知，少数非正式名称空间尚未得到广泛使用，而实验名称空间根据定义是未注册的。
The experimental namespaces take the form "X-NID" (where "NID" is the desired namespace identifier). Because the "X-" convention has been deprecated in general [RFC6648], it seems sensible to achieve the same objective in a different way. Therefore, this document registers a formal namespace identifier of "example", similar to "example.com" and other domain names [RFC2606]. Under the "example" NID, specification authors and code developers can mint URNs for use in documentation and in URN-related testing and experimentation by assigning their own unique Namespace Specific Strings without fear of conflicts with current or future actual URNs. Such URNs are intended for use as examples in documentation, testing of code for URN and URI processing, URN-related experimentation, invalid URNs, and other similar uses. They are not intended for testing non-URI code or for building higher-level applications for use over the Internet or private networks (e.g., as XML namespace names), since it is relatively easy to mint URIs whose authority component is a domain name controlled by the person or organization that wishes to engage in such testing and experimentation.
实验名称空间的形式为“X-NID”（其中“NID”是所需的名称空间标识符）。由于“X-”约定已被普遍否决[RFC6648]，因此以不同的方式实现相同的目标似乎是明智的。因此，本文档注册了“example”的正式名称空间标识符，类似于“example.com”和其他域名[RFC2606]。在“示例”NID下，规范作者和代码开发人员可以通过分配自己独特的特定于名称空间的字符串来创建URN，以便在文档和与URN相关的测试和实验中使用，而不用担心与当前或未来的实际URN冲突。此类URN旨在用作文档、URN和URI处理代码测试、URN相关实验、无效URN以及其他类似用途中的示例。它们不用于测试非URI代码或构建更高级别的应用程序，以便在Internet或专用网络上使用（例如，作为XML命名空间名称），因为创建URI相对容易，其授权组件是由希望参与此类测试和实验的个人或组织控制的域名。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
The Namespace ID "example" has been assigned.
已分配名称空间ID“example”。
Version 1
版本1
Date: 2013-04-24
日期：2013-04-24
Registering organization: IETF
注册机构：IETF
Designated contact: IESG, iesg@ietf.org
指定联系人：IESG，iesg@ietf.org
URNs that use the "example" NID shall have the following structure:
使用“示例”NID的URN应具有以下结构：
urn:example:{NSS}
urn:example:{NSS}
The Namespace Specific String (NSS) is a mandatory string of ASCII characters [RFC20] that conforms to the URN syntax requirements [RFC2141] and provides a name that is useful within the relevant documentation example, test suite, or other application.
名称空间特定字符串（NSS）是ASCII字符的强制字符串[RFC20]，符合URN语法要求[RFC2141]，并提供在相关文档示例、测试套件或其他应用程序中有用的名称。
See [RFC6648] for information about deprecation of the "X-" convention in protocol parameters and identifiers.
有关协议参数和标识符中“X-”约定的弃用信息，请参阅[RFC6648]。
Those who mint example URNs ought to strive for uniqueness in the Namespace Specific String portion of the URN. However, such uniqueness cannot be guaranteed through the assignment process. Therefore, it is NOT RECOMMENDED for implementers to use example URNs for any purposes other than documentation, private testing, and truly experimental contexts.
创建示例URN的人应该在URN的特定于名称空间的字符串部分中争取唯一性。但是，这种唯一性无法通过分配过程得到保证。因此，不建议实现者将示例URN用于文档、私有测试和真正的实验环境之外的任何目的。
Once minted, an example URN is immutable. However, it is simply a string; and there is no guarantee that the documentation, test suite, or other application using the URN is immutable.
一旦创建，示例URN是不可变的。然而，它只是一个字符串；而且也不能保证使用URN的文档、测试套件或其他应用程序是不可变的。
Assignment is completely open, since anyone can mint example URNs for use in documentation, private testing, and other experimental contexts.
分配是完全开放的，因为任何人都可以创建示例URN用于文档、私人测试和其他实验环境。
Example URNs are not intended to be resolved, and the namespace will probably never be registered with a Resolution Discovery System (except to simply inform requesters that such URNs are merely examples).
示例URN不打算被解析，并且名称空间可能永远不会在解析发现系统中注册（除非只是通知请求者此类URN只是示例）。
No special considerations; the rules for lexical equivalence specified in [RFC2141] apply.
没有特别考虑；[RFC2141]中规定的词汇等效规则适用。
No special considerations
没有特别考虑
None
没有一个
The scope of an example URN is limited to the documentation in which it is found, the test in which it is used, the experiment in which it appears, etc. Example URNs have no meaning outside such strictly limited contexts.
示例URN的范围仅限于发现它的文档、使用它的测试、出现它的实验等。示例URN在严格限制的上下文之外没有任何意义。
No existing formal namespace enables entities to generate URNs that are appropriate for use as examples in documentation and in URN-related testing and experimentation. It could be argued that no such formal namespace is needed, given that experimental namespaces can be minted at will. However, experimental namespaces run afoul of the trend away from using the "X-" convention in the names of protocol parameters and identifiers [RFC6648]. Additionally, in practice, specification authors often mint examples using fake NIDs that go unregistered because they are never intended to be used. To minimize the possibility of confusion, use of this dedicated example namespace is recommended for generating example URNs.
现有的正式名称空间不允许实体生成适合在文档和与URN相关的测试和实验中用作示例的URN。考虑到实验性名称空间可以随意创建，可以认为不需要这样的正式名称空间。然而，实验名称空间与在协议参数和标识符的名称中使用“X-”约定的趋势背道而驰[RFC6648]。此外，在实践中，规范作者经常造出使用伪造NID的示例，这些NID未注册，因为它们从未打算被使用。为了尽量减少混淆的可能性，建议使用此专用示例名称空间来生成示例URN。
The "example" NID is intended to provide a clean, easily recognizable space for minting examples to be used in documentation and in URN-related testing and experimentation. The NSS is best as a unique string, generated by the person, organization, or other entity that creates the documentation, test suite, or other application. There is no issuing authority for example URNs, and it is not intended that they can be resolved in any meaningful way.
“示例”NID旨在提供一个干净、易于识别的空间，用于制作用于文档和与URN相关的测试和实验的示例。NSS最好是由创建文档、测试套件或其他应用程序的个人、组织或其他实体生成的唯一字符串。例如，URN没有发布机构，也不打算以任何有意义的方式解决它们。
The "example" NID does not obviate the need to coordinate with issuing authorities for existing namespaces (e.g., minting "urn:example:xmpp:foo" instead of requesting issuance of "urn:xmpp:foo"), to register new namespace identifiers if existing namespaces do not match one's desired functionality (e.g., minting "urn:example:sha-1:29ead03e784b2f636a23ffff95ed12b56e2f2637" instead of registering the "sha-1" NID), or to respect the basic spirit of URN NID assignment (e.g., setting up shadow NIDs such as "urn:example:MyCompany:*" instead of using, say, HTTP URIs).
“示例”NID并不排除需要与现有名称空间的发布机构协调（例如，在现有名称空间与所需功能不匹配（例如，minting）的情况下注册新的名称空间标识符（例如，minting“urn:example:xmpp:foo”，而不是请求发布“urn:xmpp:foo”）“urn:example:sha-1:29ead03e784b2f636a23ffff95ed12b56e2f2637”而不是注册“sha-1”NID），或尊重urn NID分配的基本精神（例如，设置影子NID，如“urn:example:MyCompany:*”而不是使用HTTP URI）。
This document introduces no additional security considerations beyond those associated with the use and resolution of URNs in general.
本文档除了介绍与一般URN的使用和解析相关的安全注意事项外，没有介绍其他安全注意事项。
This document defines a URN NID registration of "example", which IANA has added to the "Formal URN Namespaces" registry. The completed registration template can be found in Section 3.
本文档定义了“示例”的URN NID注册，IANA已将其添加到“正式URN名称空间”注册表中。完整的注册模板见第3节。
[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，RFC201969年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141]Moats，R.，“瓮语法”，RFC 21411997年5月。
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.
[RFC3406]Daigle，L.，van Gulik，D.，Iannella，R.，和P.Faltstrom，“统一资源名称（URN）命名空间定义机制”，BCP 66，RFC 3406，2002年10月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]Eastlake，D.和A.Panitz，“保留顶级DNS名称”，BCP 32，RFC 26061999年6月。
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, June 2012.
[RFC6648]圣安德烈，P.，克罗克，D.，和M.诺丁汉，“反对应用协议中的“X-”前缀和类似结构”，BCP 178，RFC 6648，2012年6月。
Thanks to Martin Duerst, Barry Leiba, and Jim Schaad for their feedback; to Christer Holmberg for his Gen-ART review; and to Benoit Claise, Adrian Farrel, and Stephen Farrell for their helpful input during IESG review. Julian Reschke inspired the work on this document, provided valuable suggestions, and shepherded the document.
感谢Martin Duerst、Barry Leiba和Jim Schaad的反馈；致克里斯特·霍姆伯格的《当代艺术评论》；感谢Benoit Claise、Adrian Farrell和Stephen Farrell在IESG审查期间提供的有用信息。朱利安·雷什克（Julian Reschke）激发了这份文件的创作灵感，提供了宝贵的建议，并指导了这份文件。
Author's Address
作者地址
Peter Saint-Andre Cisco Systems, Inc. 1899 Wynkoop Street, Suite 600 Denver, CO 80202 USA
Peter Saint Andre Cisco Systems，Inc.美国科罗拉多州丹佛市温库普街1899号600室，邮编：80202
EMail: psaintan@cisco.com
EMail: psaintan@cisco.com