Internet Engineering Task Force (IETF) R. Sparks
Request for Comments: 8217 Oracle
Updates: 3261, 3325, 3515, 3892, 4508, August 2017
5002, 5318, 5360, 5502
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Sparks
Request for Comments: 8217 Oracle
Updates: 3261, 3325, 3515, 3892, 4508, August 2017
5002, 5318, 5360, 5502
Category: Standards Track
ISSN: 2070-1721
Clarifications for When to Use the name-addr Production in SIP Messages
关于何时在SIP消息中使用名称addr Production的澄清
Abstract
摘要
RFC 3261 constrained several SIP header fields whose grammar contains the "name-addr / addr-spec" alternative to use name-addr when certain characters appear. Unfortunately, it expressed the constraints with prose copied into each header field definition, and at least one header field was missed. Further, the constraint has not been copied into documents defining extension headers whose grammar contains the alternative.
RFC 3261约束了多个SIP头字段，这些字段的语法包含“name addr/addr spec”选项，以便在出现某些字符时使用name addr。不幸的是，它通过将散文复制到每个标题字段定义中来表示约束，并且至少缺少一个标题字段。此外，还没有将约束复制到定义扩展头的文档中，扩展头的语法中包含替代项。
This document updates RFC 3261 to state the constraint generically and clarifies that the constraint applies to all SIP header fields where there is a choice between using name-addr or addr-spec. It also updates the RFCs that define extension SIP header fields using the alternative to clarify that the constraint applies (RFCs 3325, 3515, 3892, 4508, 5002, 5318, 5360, and 5502).
本文档更新RFC 3261，以一般性地说明约束，并澄清约束适用于所有SIP头字段，其中可以选择使用名称addr或addr-spec。本文档还更新了使用替代项定义扩展SIP头字段的RFC，以澄清约束是否适用（RFCs 3325、3515、3892、4508、5002、5318、5360和5502）。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8217.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8217.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束
(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.
(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . . . 4
4. Updates to RFCs Defining SIP Extension Header Fields . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 5
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . . . 4
4. Updates to RFCs Defining SIP Extension Header Fields . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 5
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
[RFC3261] defines several header fields that contain URIs to allow both a form that contains the bare URI (addr-spec) and one that provides a name and the URI (name-addr). This subset, taken from the ABNF [RFC5234] specified in [RFC3261], shows the relevant part of the definition of the syntax of the "From" header field:
[RFC3261]定义了几个包含URI的头字段，以允许包含裸URI（addr spec）的表单和提供名称和URI（name addr）的表单。该子集取自[RFC3261]中指定的ABNF[RFC5234]，显示了“from”头字段语法定义的相关部分：
From = ( "From" / "f" ) HCOLON from-spec
from-spec = ( name-addr / addr-spec )
*( SEMI from-param )
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec = SIP-URI / SIPS-URI / absoluteURI
From = ( "From" / "f" ) HCOLON from-spec
from-spec = ( name-addr / addr-spec )
*( SEMI from-param )
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec = SIP-URI / SIPS-URI / absoluteURI
The prose in Section 20.20 of [RFC3261], which discusses the "From" header field, constrains how the production may be used by saying:
[RFC3261]第20.20节中的散文讨论了“From”标题字段，通过以下方式限制了如何使用产品：
Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, question mark, or semicolon.
即使“display name”为空，如果“addr spec”包含逗号、问号或分号，也必须使用“name addr”表单。
Section 20.39 of [RFC3261], which discusses the "To" header field, contains no such constraining text.
[RFC3261]第20.39节讨论了“收件人”标题字段，其中不包含此类约束文本。
This constraint is specified slightly differently, but with the same intent, in the introduction to Section 20 of [RFC3261]:
在[RFC3261]第20节引言中，对该约束的规定略有不同，但目的相同：
The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >).
联系人、发件人和收件人标头字段包含URI。如果URI包含逗号、问号或分号，则URI必须用尖括号（<和>）括起来。
Unfortunately, this can be read to only apply to the Contact, From, and To header fields, making it necessary to provide the constraint explicitly in the prose discussing any other header field using the name-addr or addr-spec alternative.
不幸的是，这可以理解为仅适用于Contact、From和to标题字段，因此有必要在讨论任何其他标题字段时使用名称addr或addr spec alternative明确提供约束。
As extension header fields were standardized, the specifications sometimes failed to include the constraint. Many errata have been entered to correct this omission. When the constraint has been included, the requirement to use the name-addr form has not been consistently stated.
由于扩展头字段被标准化，规范有时无法包含约束。已输入许多勘误表以纠正此遗漏。当约束包含在内时，使用名称addr表单的要求没有得到一致的说明。
This memo updates the specifications of SIP and its extensions to clarify that the constraint to use the name-addr form applies anywhere there is a choice between the name-addr and addr-spec production rules in the grammar for SIP header fields.
本备忘录更新了SIP及其扩展的规范，以澄清使用名称addr表单的约束适用于SIP头字段语法中名称addr和addr spec生成规则之间有选择的任何地方。
It is important to note that a message formed without honoring the constraint will still be syntactically valid, but it would very likely be interpreted differently. The characters after the comma, question mark, or semicolon will, in most cases, be interpreted as header field parameters or additional header field values as discussed in Section 7.3.1 of [RFC3261]. (An exception is the degenerate case of a URL like sip:10.0.0.1,@10.0.0.0 where it is possible to parse the comma via the 'user' production).
需要注意的是，在不遵守约束的情况下生成的消息在语法上仍然有效，但很可能会有不同的解释。在大多数情况下，逗号、问号或分号后的字符将被解释为标题字段参数或附加标题字段值，如[RFC3261]第7.3.1节所述。（一个例外是像sip:10.0.0.1、@10.0.0.0这样的URL的退化情况，在这种情况下，可以通过“用户”产品解析逗号）。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This text from introduction to Section 20 of [RFC3261]:
[RFC3261]第20节导言的正文如下：
The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters.
联系人、发件人和收件人标头字段包含URI。如果URI包含逗号、问号或分号，则URI必须用尖括号（<和>）括起来。任何URI参数都包含在这些括号内。如果URI未括在尖括号中，则任何分号分隔的参数都是标头参数，而不是URI参数。
is replaced with:
替换为：
When constructing the value of any SIP header field whose grammar allows choosing between name-addr and addr-spec, such as those that use the form '(name-addr / addr-spec)', the addr-spec form MUST NOT be used if its value would contain a comma, semicolon, or question mark.
当构造语法允许在名称addr和addr spec之间进行选择的任何SIP头字段的值时，例如那些使用“（名称addr/addr spec）”格式的字段，如果addr spec格式的值包含逗号、分号或问号，则不得使用该格式。
When a URI appears in such a header field, any URI parameters MUST be contained within angle brackets (< and >). If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters.
当URI出现在这样的标题字段中时，任何URI参数都必须包含在尖括号（<和>）中。如果URI未括在尖括号中，则任何分号分隔的参数都是标头参数，而不是URI参数。
The header fields defined in this specification that allow this choice are "To", "From", "Contact", and "Reply-To".
本规范中定义的允许此选择的标题字段为“收件人”、“发件人”、“联系人”和“回复收件人”。
The following Standards Track RFCs: [RFC3515], [RFC3892], [RFC4508], and [RFC5360]
以下标准跟踪RFC:[RFC3515]、[RFC3892]、[RFC4508]和[RFC5360]
and the following Informational RFCs: [RFC3325], [RFC5002], [RFC5318], and [RFC5502]
以及以下信息性RFC:[RFC3325]、[RFC5002]、[RFC5318]和[RFC5502]
are updated to include:
更新内容包括：
This RFC contains the definition of one or more SIP header fields that allow choosing between addr-spec and name-addr when constructing header field values. As specified in RFC 8217, the "addr-spec" form MUST NOT be used if its value would contain a comma, semicolon, or question mark.
此RFC包含一个或多个SIP头字段的定义，允许在构造头字段值时在addr spec和name addr之间进行选择。如RFC 8217所述，如果“addr spec”表单的值包含逗号、分号或问号，则不得使用该表单。
The status of these RFCs remains unchanged. In particular the status of the Informational RFCs remains Informational.
这些RFC的状态保持不变。特别是，信息性RFC的状态仍然是信息性的。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
The updates specified in this memo clarify a constraint on the grammar for producing SIP messages. It introduces no new security considerations. One pre-existing consideration is worth reiterating: messages produced without honoring the constraint will very likely be misinterpreted by the receiving element.
此备忘录中指定的更新澄清了生成SIP消息的语法约束。它没有引入新的安全考虑。一个预先存在的考虑值得重申：未遵守约束而生成的消息很可能会被接收元素误解。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <http://www.rfc-editor.org/info/rfc3325>.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的专用扩展”，RFC 3325，DOI 10.17487/RFC3325，2002年11月<http://www.rfc-editor.org/info/rfc3325>.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, <http://www.rfc-editor.org/info/rfc3515>.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，DOI 10.17487/RFC3515，2003年4月<http://www.rfc-editor.org/info/rfc3515>.
[RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, DOI 10.17487/RFC3892, September 2004, <http://www.rfc-editor.org/info/rfc3892>.
[RFC3892]Sparks，R.，“机制引用的会话启动协议（SIP）”，RFC 3892，DOI 10.17487/RFC3892，2004年9月<http://www.rfc-editor.org/info/rfc3892>.
[RFC4508] Levin, O. and A. Johnston, "Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method", RFC 4508, DOI 10.17487/RFC4508, May 2006, <http://www.rfc-editor.org/info/rfc4508>.
[RFC4508]Levin，O.和A.Johnston，“使用会话启动协议（SIP）引用方法传递功能标签”，RFC 4508，DOI 10.17487/RFC4508，2006年5月<http://www.rfc-editor.org/info/rfc4508>.
[RFC5002] Camarillo, G. and G. Blanco, "The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header)", RFC 5002, DOI 10.17487/RFC5002, August 2007, <http://www.rfc-editor.org/info/rfc5002>.
[RFC5002]Camarillo，G.和G.Blanco，“会话启动协议（SIP）P-Profile-Key私有头（P-Header）”，RFC 5002，DOI 10.17487/RFC5002，2007年8月<http://www.rfc-editor.org/info/rfc5002>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5318] Hautakorpi, J. and G. Camarillo, "The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header)", RFC 5318, DOI 10.17487/RFC5318, December 2008, <http://www.rfc-editor.org/info/rfc5318>.
[RFC5318]Hautakorpi，J.和G.Camarillo，“会话启动协议（SIP）P-Reked-URI-List私有头（P-Header）”，RFC 5318，DOI 10.17487/RFC5318，2008年12月<http://www.rfc-editor.org/info/rfc5318>.
[RFC5360] Rosenberg, J., Camarillo, G., Ed., and D. Willis, "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)", RFC 5360, DOI 10.17487/RFC5360, October 2008, <http://www.rfc-editor.org/info/rfc5360>.
[RFC5360]Rosenberg，J.，Camarillo，G.，Ed.，和D.Willis，“会话启动协议（SIP）中基于同意的通信框架”，RFC 5360，DOI 10.17487/RFC5360，2008年10月<http://www.rfc-editor.org/info/rfc5360>.
[RFC5502] van Elburg, J., "The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem", RFC 5502, DOI 10.17487/RFC5502, April 2009, <http://www.rfc-editor.org/info/rfc5502>.
[RFC5502]van Elburg，J.，“3GPP IP多媒体（IM）核心网络（CN）子系统的SIP P服务用户专用报头（P报头）”，RFC 5502，DOI 10.17487/RFC5502，2009年4月<http://www.rfc-editor.org/info/rfc5502>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
Acknowledgments
致谢
Brett Tate identified this issue in several extension documents, submitted several corresponding errata, and drove the discussion that led to this memo. Substantive comments leading to this text were provided by Paul Kyzivat, Gonzalo Camarillo, Dale Worley, and Yehoshua Gev.
Brett Tate在几份扩展文件中确定了这一问题，提交了几份相应的勘误表，并推动了导致这份备忘录的讨论。Paul Kyzivat、Gonzalo Camarillo、Dale Worley和Yehoshua Gev提供了导致该文本的实质性评论。
Author's Address
作者地址
Robert Sparks Oracle
罗伯特·斯帕克斯神谕
Email: rjsparks@nostrum.com
Email: rjsparks@nostrum.com