Network Working Group C. Jennings
Request for Comments: 5341 Cisco Systems
Updates: 3966 V. Gurbani
Category: Standards Track Bell Laboratories, Alcatel-Lucent
September 2008
Network Working Group C. Jennings
Request for Comments: 5341 Cisco Systems
Updates: 3966 V. Gurbani
Category: Standards Track Bell Laboratories, Alcatel-Lucent
September 2008
The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry
Internet分配号码管理局（IANA）tel统一资源标识符（URI）参数注册表
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document creates an Internet Assigned Number Authority (IANA) registry for tel Uniform Resource Identifier (URI) parameters and their values. It populates the registry with the parameters defined in the tel URI specification, along with the parameters in tel URI extensions defined for number portability and trunk groups.
本文档为tel统一资源标识符（URI）参数及其值创建Internet分配号码管理局（IANA）注册表。它使用tel URI规范中定义的参数以及为号码可移植性和中继组定义的tel URI扩展中的参数填充注册表。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Use of the Registry . . . . . . . . . . . . . . . . . . . . . . 2
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
4.1. tel URI Parameters Registry . . . . . . . . . . . . . . . . 3
4.2. Registration Policy for tel URI Parameters . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Use of the Registry . . . . . . . . . . . . . . . . . . . . . . 2
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
4.1. tel URI Parameters Registry . . . . . . . . . . . . . . . . 3
4.2. Registration Policy for tel URI Parameters . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 5
The tel URI (RFC 3966 [1]), defines a URI that can be used to represent resources identified by telephone numbers. The tel URI, like many other URIs, provides extensibility through the definition of new URI parameters and new values for existing parameters. However, RFC 3966 did not specify an IANA registry where such parameters and values can be listed and standardized. This specification creates such a registry.
tel URI（RFC 3966[1]）定义了一个URI，可用于表示由电话号码标识的资源。tel URI与许多其他URI一样，通过定义新的URI参数和现有参数的新值来提供可扩展性。然而，RFC 3966没有指定IANA注册表，在该注册表中可以列出并标准化这些参数和值。本规范创建了这样一个注册表。
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 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[2]中所述进行解释。
The tel URI parameters and values for these parameters MUST be documented in a RFC or other permanent and readily available public specification in order to be registered by IANA. This documentation MUST fully explain the syntax, intended usage, and semantics of the parameter. The intent of this requirement is to assure interoperability between independent implementations, and to prevent accidental namespace collisions between implementations of dissimilar features.
tel URI参数和这些参数的值必须记录在RFC或其他永久性且随时可用的公共规范中，以便IANA注册。本文档必须充分解释参数的语法、预期用途和语义。此需求的目的是确保独立实现之间的互操作性，并防止不同功能实现之间的意外命名空间冲突。
Documents defining tel URI parameters or parameter values MUST register them with IANA, as described in Section 4. The IANA registration policy for such parameters is "Specification Required, Designated Expert," and is further discussed in Section 4.2.
定义tel URI参数或参数值的文档必须向IANA注册，如第4节所述。此类参数的IANA注册政策为“所需规范，指定专家”，并在第4.2节中进一步讨论。
Some tel URI parameters only accept a set of predefined parameter values while others can take any value. There are also parameters that do not have any value; they are used as flags.
一些tel-URI参数只接受一组预定义的参数值，而其他参数可以接受任何值。还有一些参数没有任何值；它们被用作旗帜。
Those URI parameters that take on predefined values typically take on a large number of values. Registering each of those values, or creating a sub-registry for each such parameter is not appropriate. Instead, we have chosen to register URI parameter values by reference. That is, the entry in the URI parameter registry for a given URI parameter contains references to the RFCs defining new values of that parameter.
那些采用预定义值的URI参数通常采用大量值。注册这些值中的每一个，或者为每一个这样的参数创建一个子注册表是不合适的。相反，我们选择通过引用注册URI参数值。也就是说，URI参数注册表中给定URI参数的条目包含对定义该参数新值的RFC的引用。
Accordingly, the tel URI parameter registry contains a column that indicates whether or not each parameter accepts a value. The column may contain "No value" or "Constrained". A "Constrained" in the column implies that certain predefined values exist for this
因此，tel URI参数注册表包含一列，指示每个参数是否接受一个值。该列可能包含“无值”或“受限”。列中的“受约束”表示存在特定的预定义值
parameter and the accompanying RFC or other permanent and readily available public specification should be consulted to find out the accepted set of values. A "No Value" in the column implies that the parameter is used either as a flag, or does not have a set of predefined values. The accompanying RFC or other permanent and readily available public specification should provide more information on the semantics of the parameter.
应参考参数和随附的RFC或其他永久性且随时可用的公共规范，以找出可接受的值集。列中的“无值”表示该参数用作标志，或没有一组预定义值。随附的RFC或其他永久性且随时可用的公共规范应提供有关参数语义的更多信息。
The specification creates a new IANA registry named "tel URI Parameters".
该规范创建了一个名为“tel-URI-Parameters”的新IANA注册表。
New tel URI parameters and new values for existing tel URI parameters MUST be registered with IANA.
必须向IANA注册新的tel URI参数和现有tel URI参数的新值。
When registering a new tel URI parameter, the following information MUST be provided:
注册新的tel URI参数时，必须提供以下信息：
o Name of the parameter.
o 参数的名称。
o Whether the parameter only accepts a set of predefined values.
o 参数是否仅接受一组预定义值。
o Reference to the RFC or other permanent and readily available public specification defining the parameter and new values.
o 参考RFC或其他定义参数和新值的永久和现成的公共规范。
When registering a new value for an existing tel URI parameter, the following information MUST be provided:
为现有tel URI参数注册新值时，必须提供以下信息：
o Name of the parameter.
o 参数的名称。
o Reference to the RFC or other permanent and readily available public specification providing the new value.
o 参考RFC或提供新值的其他永久性和现成的公共规范。
Table 1 contains the initial values for this registry.
表1包含此注册表的初始值。
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
isub Constrained [RFC3966]
isub-encoding Constrained [RFC4715]
ext Constrained [RFC3966]
phone-context Constrained [RFC3966]
enumdi No value [RFC4759]
npdi No value [RFC4694]
rn Constrained [RFC4694]
rn-context Constrained [RFC4694]
cic Constrained [RFC4694]
cic-context Constrained [RFC4694]
tgrp Constrained [RFC4904]
trunk-context Constrained [RFC4904]
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
isub Constrained [RFC3966]
isub-encoding Constrained [RFC4715]
ext Constrained [RFC3966]
phone-context Constrained [RFC3966]
enumdi No value [RFC4759]
npdi No value [RFC4694]
rn Constrained [RFC4694]
rn-context Constrained [RFC4694]
cic Constrained [RFC4694]
cic-context Constrained [RFC4694]
tgrp Constrained [RFC4904]
trunk-context Constrained [RFC4904]
Table 1: IANA tel URI parameter registry
表1:IANA tel URI参数注册表
As per the terminology in [3] and actions accorded to such a role, the registration policy for tel URI parameters shall be "Specification Required, Designated Expert" (the former implicitly implies the latter).
根据[3]中的术语和赋予该角色的行为，tel URI参数的注册策略应为“所需规范，指定专家”（前者暗含后者）。
The Designated Expert, when deliberating on whether to include a new parameter in the tel URI registry, may use the criteria provided below to reach a decision (this is not an exhaustive list but representative of the issues to consider when rendering an equitable decision):
指定专家在考虑是否在Tel-URI注册表中包含新参数时，可以使用下面提供的标准来作出决定（这不是一个详尽的列表，而是代表在做出公平决策时要考虑的问题）：
o If the tel URI -- with the parameter under consideration -- will be converted to a URI used by other signaling protocols such as the Session Initiation Protocol (SIP [5]) or H.323 [7], then the expert must consider whether this parameter merely encapsulates signaling information that is not meaningful to the processing of requests in the domain of the converted URI. For example, certain Integrated Services Digital Network (ISDN) User Part (ISUP, [8]) parameters have no equivalent corollary in SIP; thus, their presence or absence in a SIP URI will not hinder the normal rules for processing that URI. Other parameters may affect the normal processing rules associated with the URI; in such cases, the expert must carefully consider the ramifications, if any, of the presence of such parameters.
o 如果tel URI（带有考虑中的参数）将转换为其他信令协议（如会话启动协议（SIP[5]）或H.323[7]）使用的URI，然后专家必须考虑该参数是否仅仅封装了对转换后的URI域中的请求的处理没有意义的信令信息。例如，某些综合业务数字网（ISDN）用户部分（ISUP，[8]）参数在SIP中没有等效的推论；因此，它们在SIPURI中的存在或不存在不会妨碍处理该URI的正常规则。其他参数可能会影响与URI关联的正常处理规则；在这种情况下，专家必须仔细考虑这些参数存在的后果，如果有的话。
o Certain parameters of a tel URI can be optional. These parameters act as metadata about the identifier in the tel URI. Optional parameters should provide additional information to a service for which they apply instead of acting as enablers of that service in
o teluri的某些参数可以是可选的。这些参数充当tel URI中标识符的元数据。可选参数应为其应用的服务提供附加信息，而不是在中充当该服务的启用码
the first place. The service must continue to be invoked and operate normally even in the absence of these parameters.
第一位。即使没有这些参数，服务也必须继续被调用并正常运行。
The registry in this document does not in itself have security considerations. However, as mentioned in [4], an important reason for the IETF to manage the extensions of SIP is to ensure that all extensions and parameters are able to provide secure usage. The supporting RFC publications for parameter registrations described in this specification MUST provide detailed security considerations for them.
本文档中的注册表本身没有安全考虑。然而，如[4]所述，IETF管理SIP扩展的一个重要原因是确保所有扩展和参数都能够提供安全使用。本规范中描述的参数注册的支持RFC出版物必须提供详细的安全注意事项。
The structure of this document comes from [6], which is the equivalent work done in the SIP domain to establish a registry. Ted Hardie, Alfred Hoenes, Jon Peterson, and Jonathan Rosenberg provided substantive comments that have improved this document.
本文档的结构来源于[6]，这相当于在SIP域中建立注册表所做的工作。Ted Hardie、Alfred Hoenes、Jon Peterson和Jonathan Rosenberg提供了改进本文件的实质性意见。
Brian Carpenter, Lars Eggert, Pasi Eronen, Chris Newman, and Glen Zorn provided feedback during IESG review and Gen-ART review.
Brian Carpenter、Lars Eggert、Pasi Eronen、Chris Newman和Glen Zorn在IESG审查和Gen ART审查期间提供了反馈。
[1] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[1] Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[3] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[4] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[4] Mankin，A.，Bradner，S.，Mahy，R.，Willis，D.，Ott，J.，和B.Rosen，“会话启动协议（SIP）的变更过程”，BCP 67，RFC 3427，2002年12月。
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[5] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[6] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
[6] Camarillo，G.，“会话启动协议（SIP）的Internet分配号码管理局（IANA）统一资源标识符（URI）参数注册表”，BCP 99，RFC 3969，2004年12月。
[7] ITU-T H.323, "H.323: Packet-based multimedia communications systems", June 2006.
[7] ITU-T H.323，“H.323：基于分组的多媒体通信系统”，2006年6月。
[8] ITU-T Q.764, "Signaling System No. 7: ISDN User Part Signaling Procedures", December 1999.
[8] ITU-T Q.764，“第7号信令系统：ISDN用户部分信令程序”，1999年12月。
Authors' Addresses
作者地址
Cullen Jennings Cisco Systems 170 West Tasman Drive Mailstop SJC-21/2 San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市西塔斯曼大道170号邮递站SJC-21/2库伦詹宁斯思科系统公司，邮编95134
Phone: +1 408 902-3341
EMail: fluffy@cisco.com
Phone: +1 408 902-3341
EMail: fluffy@cisco.com
Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane Room 9F-546 Lisle, IL 60532 USA
Vijay K.Gurbani Bell实验室，阿尔卡特朗讯2701朗讯巷，美国伊利诺伊州利斯勒9F-546室，邮编60532
Phone: +1 630 224-0216
EMail: vkg@alcatel-lucent.com
Phone: +1 630 224-0216
EMail: vkg@alcatel-lucent.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.