Network Working Group                                        M. Mealling
Request for Comments: 3553                                      VeriSign
BCP: 73                                                      L. Masinter
Category: Best Current Practice                            Adobe Systems
                                                               T. Hardie
                                                                Qualcomm
                                                                G. Klyne
                                                            Nine by Nine
                                                               June 2003
        
Network Working Group                                        M. Mealling
Request for Comments: 3553                                      VeriSign
BCP: 73                                                      L. Masinter
Category: Best Current Practice                            Adobe Systems
                                                               T. Hardie
                                                                Qualcomm
                                                                G. Klyne
                                                            Nine by Nine
                                                               June 2003
        

An IETF URN Sub-namespace for Registered Protocol Parameters

已注册协议参数的IETF URN子命名空间

Status of this Memo

本备忘录的状况

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

本文件规定了互联网社区的最佳现行做法,并要求进行讨论和提出改进建议。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2003). All Rights Reserved.

版权所有(C)互联网协会(2003年)。版权所有。

Abstract

摘要

This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items. The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer to IETF-defined resources.

本文档描述了注册协议项的“ietf”URN命名空间的新子委托。RFC 2648中将“ietf”URN命名空间定义为引用ietf定义的资源的持久URI的根。

1. Introduction
1. 介绍

From time to time IETF standards require the registration of various protocol elements in well known central repository. The Internet Assigned Numbers Authority maintains this central repository and takes direction from the IETF on what, how and when to add items to it. The IANA maintains lists of items such as all assigned port numbers, MIME media types, enterprise numbers, etc.

IETF标准不时要求在著名的中央存储库中注册各种协议元素。Internet分配号码管理局维护该中央存储库,并接受IETF关于向其中添加项目的内容、方式和时间的指示。IANA维护项目列表,如所有分配的端口号、MIME媒体类型、企业编号等。

Over time there has developed a need to be able to reference these elements as URIs in various schema. In the past this was done in a very ad hoc way that easily led to interoperability problems. This document creates a new sub-delegation below the "ietf" [2]URN namespace [1] called 'params' which acts as a standardized mechanism for naming the items registered for IETF standards. Any assignments below that are specified in an RFC according to the IETF consensus process and which include the template found in Section 4.

随着时间的推移,人们需要能够在各种模式中将这些元素引用为URI。在过去,这是以一种非常特别的方式进行的,很容易导致互操作性问题。本文档在“ietf”[2]URN名称空间[1]下创建了一个新的子委托,称为“params”,它作为命名为ietf标准注册的项目的标准化机制。根据IETF共识流程,RFC中规定的以下任何作业,包括第4节中的模板。

2. Terminology
2. 术语

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中的说明进行解释。

3. IETF Sub-namespace Specifics
3. IETF子命名空间详细信息

Sub-namespace name:

子命名空间名称:

params

params

Declared registrant of the namespace:

已声明命名空间的注册人:

The Internet Engineering Task Force

互联网工程特别工作组

Declaration of structure:

结构声明:

The namespace is primarily opaque. The IANA, as operator of the registry, may take suggestions for names to assign but they reserve the right to assign whatever name they desire, within guidelines set by the IESG. The colon character (":") is used to denote a very limited concept of hierarchy. If a colon is present then the items on both sides of it are valid names. In general, if a name has a colon then the item on the left hand side represents a class of those items that would contain other items of that class. For example, a name can be assigned to the entire list of DNS resource record type codes as well as for each individual code. The URN for the list might look like this:

名称空间主要是不透明的。IANA作为注册中心的运营商,可能会接受关于名称分配的建议,但他们保留在IESG规定的指导方针范围内分配其想要的任何名称的权利。冒号字符(“:”)用于表示非常有限的层次结构概念。如果存在冒号,则冒号两侧的项目都是有效名称。通常,如果名称有冒号,则左侧的项表示包含该类其他项的那些项的类。例如,可以为整个DNS资源记录类型代码列表以及每个代码分配名称。列表的URN可能如下所示:

            urn:ietf:params:dns:rr-type-codes
        
            urn:ietf:params:dns:rr-type-codes
        

while the URN for the SOA records type code might look like this:

SOA记录类型代码的URN可能如下所示:

            urn:ietf:params:dns:rr-type-codes:soa
        
            urn:ietf:params:dns:rr-type-codes:soa
        

Relevant ancillary documentation:

相关辅助文件:

[3], [2], [1]

[3], [2], [1]

Identifier uniqueness considerations:

标识符唯一性注意事项:

The IESG uses the IETF consensus process to ensure that sub-namespaces generate unique names within that sub-namespace. The IESG delegates to the IANA the task of ensuring that the sub-namespace names themselves are unique. Until and unless the IESG specifies differently, the IANA is directed to ensure uniqueness by comparing the name to be assigned

IESG使用IETF一致性过程来确保子命名空间在该子命名空间中生成唯一的名称。IESG将确保子命名空间名称本身唯一的任务委托给IANA。除非IESG另有规定,否则IANA将通过比较要分配的名称来确保唯一性

with the list of previously assigned names. In the case of a conflict the IANA is to request a new string from the registrant until the conflict is resolved.

使用以前分配的名称列表。在发生冲突的情况下,IANA将向注册人请求一个新字符串,直到冲突得到解决。

Identifier persistence considerations:

标识符持久性注意事项:

Once a name has been allocated it MUST NOT be re-allocated for a different purpose. The rules provided for assignments of values within a sub-namespace MUST be constructed so that the meaning of values cannot change. This registration mechanism is not appropriate for naming values whose meaning may change over time. If a value that changes over time the assignment MUST name the container or concept that contains the value, not the value itself. For example, if a parameter called 'foo' has a value that changes over time, it is valid to create the name 'urn:ietf:params:foo-params:foo' that identifies that 'slot'. It is not valid to actually create a name that contains that value unless it is a persistent and unique value such as a version number.

一旦分配了名称,则不得将其重新分配用于其他目的。必须构造为子命名空间中的值赋值提供的规则,以便值的含义不会更改。这种注册机制不适合命名含义可能随时间变化的值。如果某个值随时间变化,则赋值必须命名包含该值的容器或概念,而不是该值本身。例如,如果名为“foo”的参数具有随时间变化的值,则创建标识该“插槽”的名称“urn:ietf:params:foo-params:foo”是有效的。除非名称是持久且唯一的值(如版本号),否则实际创建包含该值的名称是无效的。

Process of identifier assignment:

标识符分配过程:

Identifiers are assigned only after a particular protocol element or number has been registered with the IANA using standard policies and procedures, or documented in an RFC describing a standards track protocol. This means that the 'gating' function for assignment is the "IETF Consensus" process documented in RFC 2434 [4].

只有在使用标准策略和程序向IANA注册特定协议元素或编号,或在描述标准跟踪协议的RFC中记录后,才能分配标识符。这意味着分配的“选通”功能是RFC 2434[4]中记录的“IETF共识”过程。

Process of identifier resolution:

标识符解析过程:

At this time no resolution mechanism is defined.

目前尚未定义任何解析机制。

Rules for Lexical Equivalence:

词汇对等规则:

Lexical equivalence is achieved by exact string match according to the rules for URN syntax found in RFC 2141 [1]. Specifically, due to the URN syntax definitions, the 'stringprep' standard found in RFC 3454 [7] does not apply.

根据RFC 2141[1]中的URN语法规则,通过精确的字符串匹配实现词汇等价。具体而言,由于URN语法定义,RFC 3454[7]中的“stringprep”标准不适用。

Conformance with URN Syntax:

符合URN语法:

There are no additional characters reserved.

没有保留其他字符。

Validation mechanism:

验证机制:

None.

没有一个

Scope:

范围:

Global

全球的

4. Assigning Names
4. 指定名称

The creation of a new registry name will be simple for most flat registries. The only required elements will be the registry name, a reference to relevant documents, a statement about which current/proposed document repositories contains the authoritative data for the registry, and a statement specifying which element in the registry is the value to be used in the URN. In most cases this last element will be the index value assigned by the IANA.

对于大多数平面注册表,创建新的注册表名将非常简单。唯一需要的元素是注册表名、相关文档的引用、关于当前/建议的文档存储库包含注册表权威数据的语句,以及指定注册表中的哪个元素是要在URN中使用的值的语句。在大多数情况下,最后一个元素将是IANA分配的索引值。

More complex registries (DNS Parameters for example) will need to repeat that information for any sub-namespaces. It should also be clear as to whether or not a name is assigned to the sub-namespace itself (i.e., is 'urn:ietf:params:dns:rr-types' valid by itself and if so, what does it name?).

更复杂的注册表(例如DNS参数)将需要为任何子名称空间重复该信息。还应明确是否将名称分配给子命名空间本身(即,“urn:ietf:params:dns:rr types”本身是否有效,如果有效,名称是什么?)。

The template:

模板:

Registry name: -- The name of the sub-namespace. In many cases this should be the same name that the IANA calls the registry itself.

注册表名称:--子命名空间的名称。在许多情况下,这应该与IANA调用注册表本身的名称相同。

Specification: -- Relevant IETF published documents that define the registry and the items in it.

规范:定义注册表及其项的相关IETF发布文档。

Repository: -- A pointer to the 'current' location of the registry in the protocol parameters repository or the relevant RFCs that document the items being named. This value will change over time as the entity that maintains the repository moves files and or fileservers. It is not meant as a permanent binding to the filename but as a hint to the IANA for what the initial mapping would be.

Repository:--指向协议参数存储库中注册表的“当前”位置或记录命名项的相关RFC的指针。随着维护存储库的实体移动文件和/或文件服务器,此值将随时间而更改。它并不是作为对文件名的永久绑定,而是作为对IANA的初始映射的提示。

Index value: -- Description of how a registered value is to be embedded in the URI form. This MUST include details of any transformations that may be needed for the resulting string to conform to URN syntax rules and any canonicalization needed so that the case-sensitive string comparison yields the expected equivalences.

索引值:--描述如何将注册值嵌入URI表单。这必须包括生成的字符串符合URN语法规则所需的任何转换的详细信息,以及所需的任何规范化,以便区分大小写的字符串比较产生预期的等价性。

The process for requesting that a URN be assigned is currently to put the above template or a reference to it in the IANA considerations section of the specifying document. Other more automated processes may be proposed at a latter time if demand requires it.

请求分配URN的过程当前是将上述模板或对其的引用放在指定文档的IANA注意事项部分。如果需求需要,可在稍后时间提出其他更自动化的流程。

5. Security Considerations
5. 安全考虑

None not already inherent to using URNs. Security considerations for URNs in general can be found in RFC 2141 [1]. Further security considerations for one specific URN resolution method can be found in Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application (RFC 3404) [5] which is part of a series starting with Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS (RFC 3401) [6].

没有一个不是使用URN所固有的。一般而言,URN的安全注意事项可在RFC 2141[1]中找到。有关一种特定URN解析方法的更多安全注意事项,请参见动态委派发现系统(DDDS)第四部分:统一资源标识符(URI)解析应用程序(RFC 3404)[5],该应用程序是从动态委派发现系统(DDDS)开始的系列的一部分。第一部分:综合DDDS(RFC 3401)[6]。

6. IANA Considerations
6. IANA考虑

This document puts a new and significant burden on the IANA since it may require an additional assignment process to happen for each new IANA registry. To minimize the administrative burden on IANA, any parameter namespace registration is very clear about the criteria for inclusion in that namespace.

本文件给IANA带来了新的重大负担,因为它可能需要为每个新的IANA注册中心进行额外的分配过程。为了尽量减少IANA的管理负担,任何参数名称空间注册都非常清楚包含在该名称空间中的标准。

Defining a registry that fits the constraints of a URN namespace will impose extra discipline that should take some of the guess-work about creating and maintaining that registry.

定义一个符合URN名称空间约束的注册表将强加额外的规则,这将需要一些关于创建和维护该注册表的猜测工作。

7. Intellectual Property Statement
7. 知识产权声明

The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息,请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。

8. Normative References
8. 规范性引用文件

[1] Moats, R., "URN Syntax", RFC 2141, May 1997.

[1] 护城河,R.,“瓮语法”,RFC 21411997年5月。

[2] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.

[2] Moats,R.,“IETF文档的URN名称空间”,RFC 2648,1999年8月。

[3] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.

[3] Daigle,L.,van Gulik,D.,Iannella,R.和P.Faltstrom,“统一资源名(URN)命名空间定义机制”,BCP 66,RFC 3406,2002年10月。

[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[4] Narten,T.和H.Alvestrand,“在RFCs中编写IANA注意事项部分的指南”,BCP 26,RFC 2434,1998年10月。

[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, February 2002.

[5] Mealling,M.“动态委托发现系统(DDDS)第四部分:统一资源标识符(URI)”,RFC34042002年2月。

[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, May 2002.

[6] Mealling,M,“动态委托发现系统(DDDS)第一部分:综合DDDS”,RFC 3401,2002年5月。

[7] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.

[7] Hoffman,P.和M.Blanchet,“国际化弦的准备(“stringprep”)”,RFC 3454,2002年12月。

9. Authors' Addresses
9. 作者地址

Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US

Michael Mealling VeriSign 21345 Ridgetop Circle Sterling,弗吉尼亚州,美国20166

   EMail: michael@verisignlabs.com, michael@neonym.net
   URI:   http://www.verisign.com
        
   EMail: michael@verisignlabs.com, michael@neonym.net
   URI:   http://www.verisign.com
        

Larry Masinter Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 US

美国加利福尼亚州圣何塞公园大道345号Larry Masinter Adobe系统公司,邮编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
        

Ted Hardie Qualcomm, Inc. 675 Campbell Technology Parkway Suite 200 Campbell, CA U.S.A.

Ted Hardie Qualcomm,Inc.675 Campbell Technology Parkway Suite 200,加利福尼亚州坎贝尔市。

   EMail: hardie@qualcomm.com
        
   EMail: hardie@qualcomm.com
        

Graham Klyne Nine by Nine

格雷厄姆·克莱恩九乘九

   EMail: GK-IETF@ninebynine.org
   URI:   http://www.ninebynine.net/
        
   EMail: GK-IETF@ninebynine.org
   URI:   http://www.ninebynine.net/
        
10. Full Copyright Statement
10. 完整版权声明

Copyright (C) The Internet Society (2003). All Rights Reserved.

版权所有(C)互联网协会(2003年)。版权所有。

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编辑功能的资金目前由互联网协会提供。