Internet Engineering Task Force (IETF) R. Sparks
Request for Comments: 7647 Oracle
Updates: 3515 A.B. Roach
Category: Standards Track Mozilla
ISSN: 2070-1721 September 2015
Internet Engineering Task Force (IETF) R. Sparks
Request for Comments: 7647 Oracle
Updates: 3515 A.B. Roach
Category: Standards Track Mozilla
ISSN: 2070-1721 September 2015
Clarifications for the Use of REFER with RFC 6665
有关使用的说明，请参考RFC 6665
Abstract
摘要
The SIP REFER method relies on the SIP-Specific Event Notification framework. That framework was revised by RFC 6665. This document highlights the implications of the requirement changes in RFC 6665, and updates the definition of the REFER method described in RFC 3515 to clarify and disambiguate the impact of those changes.
SIP REFER方法依赖于特定于SIP的事件通知框架。RFC 6665修订了该框架。本文件强调了RFC 6665中需求变更的含义，并更新了RFC 3515中描述的REFER方法的定义，以澄清和消除这些变更的影响。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见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/rfc7647.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7647.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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. Conventions Used in This Document . . . . . . . . . . . . . . 2
3. Use of GRUU Is Mandatory . . . . . . . . . . . . . . . . . . 3
4. Dialog Reuse Is Prohibited . . . . . . . . . . . . . . . . . 3
5. The 202 Response Code Is Deprecated . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2
3. Use of GRUU Is Mandatory . . . . . . . . . . . . . . . . . . 3
4. Dialog Reuse Is Prohibited . . . . . . . . . . . . . . . . . 3
5. The 202 Response Code Is Deprecated . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
The SIP REFER method relies on the SIP-Specific Event Notification framework. That framework was revised by [RFC6665]. This document highlights the implications of the requirement changes in RFC 6665, and updates [RFC3515] to clarify and disambiguate the impact of those changes.
SIP REFER方法依赖于特定于SIP的事件通知框架。该框架由[RFC6665]修订。本文件强调了RFC 6665中需求变更的含义，并更新了[RFC3515]，以澄清和消除这些变更的影响。
Accepting a REFER request (without invoking extensions) results in an implicit SIP-Events subscription. If that REFER was part of an existing dialog, the implicit subscription creates a new, problematic dialog usage within that dialog [RFC5057]. The "norefersub" extension defined in [RFC4488] asks to suppress this implicit subscription, but cannot prevent its creation.
接受REFER请求（不调用扩展）会导致隐式SIP事件订阅。如果该引用是现有对话框的一部分，则隐式订阅会在该对话框中创建新的有问题的对话框用法[RFC5057]。[RFC4488]中定义的“norefersub”扩展请求抑制此隐式订阅，但无法阻止其创建。
There are implementations in some known specialized environments (such as 3GPP) that use out-of-signaling agreements to ensure that in-dialog REFER requests using the RFC 4488 extension do not create a new subscription inside that dialog. In the 3GPP environment, the behavior is based on capabilities advertised using media feature tags. That mechanism does not, however, prevent additional dialog usages when interoperating with implementations that do not support the mechanism. The extensions in [RFC7614] provide a standardized mechanism that allows avoiding any additional dialog usage.
在一些已知的专用环境（如3GPP）中，存在使用out-of-signaling协议来确保使用RFC 4488扩展的in-dialog-REFER请求不会在该对话框内创建新订阅的实现。在3GPP环境中，该行为基于使用媒体功能标签宣传的功能。但是，当与不支持该机制的实现进行互操作时，该机制不会阻止额外的对话框使用。[RFC7614]中的扩展提供了一种标准化机制，允许避免任何额外的对话框使用。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Section 4.5.1 of [RFC6665] makes GRUU [RFC5627] mandatory for notifiers to implement and use as the local target in the subscription created by the REFER request.
[RFC6665]的第4.5.1节规定GRUU[RFC5627]对于通知程序来说是强制性的，通知程序必须在REFER请求创建的订阅中实现并用作本地目标。
A user agent (UA) accepting a REFER that creates a subscription MUST populate its Contact header field with a GRUU.
接受用于创建订阅的引用的用户代理（UA）必须使用GRUU填充其联系人标头字段。
A UA that might possibly become a notifier (e.g., by accepting a REFER request that creates a subscription) needs to include a GRUU in the Contact header field of dialog-forming and target-refresh methods (such as INVITE) [RFC7621]. This ensures that out-of-dialog REFER requests corresponding to any resulting INVITE dialogs arrive at this UA. Extensions can relax this requirement by defining a REFER request that cannot create an implicit subscription, thus not causing the accepting UA to become an RFC 6665 notifier in the context of this dialog. [RFC7614] is an example of such an extension.
可能成为通知程序的UA（例如，通过接受创建订阅的REFER请求）需要在对话框形成和目标刷新方法（如INVITE）的联系人标头字段中包含GRUU）[RFC7621]。这确保了与任何结果INVITE对话框对应的out of dialog REFER请求到达该UA。扩展可以通过定义一个不能创建隐式订阅的REFER请求来放宽这一要求，从而不会导致接受UA成为该对话框上下文中的RFC66665通知程序。[RFC7614]就是这种扩展的一个例子。
If a peer in an existing dialog has provided a GRUU as its Contact, sending a REFER that might result in an additional dialog usage within that dialog is prohibited. This is a direct consequence of [RFC6665] requiring the use of GRUU and the requirements in Section 4.5.2 of that document.
如果现有对话框中的对等方提供了GRUU作为其联系人，则禁止发送可能导致该对话框中使用其他对话框的引用。这是[RFC6665]要求使用GRUU和该文件第4.5.2节要求的直接结果。
A user agent constructing a REFER request that could result in an implicit subscription in a dialog MUST build it as an out-of-dialog message as defined in [RFC3261], unless the remote endpoint is an older implementation of RFC 3515 that has not been updated to conform to RFC 6665 (as determined by the absence of a GRUU in the remote target). Thus, the REFER request will have no tag parameter in its To: header field.
除非远程端点是RFC 3515的较旧实现，且该实现尚未更新以符合RFC 6665（由远程目标中缺少GRUU确定），否则构造可能导致对话框中隐式订阅的REFER请求的用户代理必须将其构建为[RFC3261]中定义的对话外消息。因此，REFER请求在其To:头字段中将没有标记参数。
Using the "norefersub" option tag [RFC4488] does not change this requirement, even if used in a "Require" header field. Even if the recipient supports the "norefersub" mechanism, and accepts the request with the option tag in the "Require" header field, it is allowed to return a "Refer-Sub" header field with a value of "true" in the response, and create an implicit subscription.
使用“norefersub”选项标记[RFC4488]不会改变此要求，即使在“Require”标题字段中使用。即使收件人支持“norefersub”机制，并在“Require”头字段中使用选项标记接受请求，也可以在响应中返回值为“true”的“referesub”头字段，并创建隐式订阅。
A user agent wishing to identify an existing dialog (such as for call transfer as defined in [RFC5589]) MUST use the "Target-Dialog" extension defined in [RFC4538] to do so, and user agents accepting REFER MUST be able to process that extension in requests they receive.
希望识别现有对话（如[RFC5589]中定义的呼叫转移）的用户代理必须使用[RFC4538]中定义的“目标对话”扩展来识别现有对话，并且接受REFER的用户代理必须能够在收到的请求中处理该扩展。
If a user agent can be certain that no implicit subscription will be created as a result of sending a REFER request (such as by requiring an extension that disallows any such subscription [RFC7614]), the REFER request MAY be sent within an existing dialog (whether or not the remote target is a GRUU). Such a REFER will be constructed with its Contact header field populated with the dialog's local URI as specified in Section 12 of [RFC3261].
如果用户代理可以确定，由于发送REFER请求（例如，通过要求不允许任何此类订阅的扩展[RFC7614]），不会创建任何隐式订阅，则可以在现有对话框中发送REFER请求（无论远程目标是否为GRUU）。此类REFER将使用[RFC3261]第12节中指定的对话框本地URI填充其联系人标头字段进行构造。
As described in Section 4.5.2 of [RFC6665], there are cases where a user agent may fall back to sharing existing dialogs for backwards-compatibility purposes. This applies to a REFER only when the peer has not provided a GRUU as its Contact in the existing dialog (i.e., when the peer is an implementation of RFC 3515 that has not been updated to conform with RFC 6665).
如[RFC6665]第4.5.2节所述，在某些情况下，出于向后兼容性的目的，用户代理可能会退回到共享现有对话框。这仅适用于当对等方未在现有对话框中提供GRUU作为其联系人时（即，当对等方是RFC 3515的实现且尚未更新以符合RFC 6665时）的REFER。
Section 8.3.1 of [RFC6665] requires that elements not send a 202 response code to a subscribe request, but use the 200 response code instead. Any 202 response codes received to a subscribe request are treated as 200s. These changes also apply to REFER. Specifically, an element accepting a REFER request MUST NOT reply with a 202 response code and MUST treat any 202 responses received as identical to a 200 response. Wherever [RFC3515] requires sending a 202 response code, a 200 response code MUST be sent instead.
[RFC6665]第8.3.1节要求元素不向订阅请求发送202响应代码，而是使用200响应代码。接收到订阅请求的任何202个响应代码都被视为200。这些变化也适用于参考。具体而言，接受REFER请求的元素不得使用202响应代码进行响应，并且必须将收到的任何202响应视为与200响应相同。[RFC3515]需要发送202响应代码的地方，必须发送200响应代码。
This document introduces no new security considerations directly. The updated considerations in [RFC6665] apply to the implicit subscription created by an accepted REFER request.
本文档没有直接介绍新的安全注意事项。[RFC6665]中更新的注意事项适用于由接受的REFER请求创建的隐式订阅。
[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>.
[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>.
[RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, DOI 10.17487/RFC4538, June 2006, <http://www.rfc-editor.org/info/rfc4538>.
[RFC4538]Rosenberg，J.，“通过会话启动协议（SIP）中的对话标识请求授权”，RFC 4538，DOI 10.17487/RFC4538，2006年6月<http://www.rfc-editor.org/info/rfc4538>.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, <http://www.rfc-editor.org/info/rfc5627>.
[RFC5627]Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，RFC 5627，DOI 10.17487/RFC5627，2009年10月<http://www.rfc-editor.org/info/rfc5627>.
[RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665, DOI 10.17487/RFC6665, July 2012, <http://www.rfc-editor.org/info/rfc6665>.
[RFC6665]Roach，A.B.，“SIP特定事件通知”，RFC 6665，DOI 10.17487/RFC66652012年7月<http://www.rfc-editor.org/info/rfc6665>.
[RFC7621] Roach, A.B., "A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework", RFC 7621, DOI 10.17487/RFC7621, August 2015, <http://www.rfc-editor.org/info/rfc7621>.
[RFC7621]Roach，A.B.，“关于在SIP事件通知框架中使用全局可路由用户代理URI（GROUS）的澄清”，RFC 7621，DOI 10.17487/RFC7621，2015年8月<http://www.rfc-editor.org/info/rfc7621>.
[RFC4488] Levin, O., "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription", RFC 4488, DOI 10.17487/RFC4488, May 2006, <http://www.rfc-editor.org/info/rfc4488>.
[RFC4488]Levin，O.“会话启动协议（SIP）的抑制参考方法隐式订阅”，RFC 4488，DOI 10.17487/RFC4488，2006年5月<http://www.rfc-editor.org/info/rfc4488>.
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, DOI 10.17487/RFC5057, November 2007, <http://www.rfc-editor.org/info/rfc5057>.
[RFC5057]Sparks，R.，“会话启动协议中的多个对话用法”，RFC 5057，DOI 10.17487/RFC5057，2007年11月<http://www.rfc-editor.org/info/rfc5057>.
[RFC5589] Sparks, R., Johnston, A., Ed., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009, <http://www.rfc-editor.org/info/rfc5589>.
[RFC5589]Sparks，R.，Johnston，A.，Ed.，和D.Petrie，“会话启动协议（SIP）呼叫控制-传输”，BCP 149，RFC 5589，DOI 10.17487/RFC5589，2009年6月<http://www.rfc-editor.org/info/rfc5589>.
[RFC7614] Sparks, R., "Explicit Subscriptions for the REFER Method", RFC 7614, DOI 10.17487/RFC7614, August 2015, <http://www.rfc-editor.org/info/rfc7614>.
[RFC7614]Sparks，R.“引用方法的显式订阅”，RFC 7614，DOI 10.17487/RFC7614，2015年8月<http://www.rfc-editor.org/info/rfc7614>.
Acknowledgements
致谢
Christer Holmberg provided the formulation for the final paragraph of the introduction. Christer Holmberg and Ivo Sedlacek provided detailed comments during working group discussion of the document.
克里斯特·霍姆伯格为导言的最后一段提供了表述。Christer Holmberg和Ivo Sedracek在工作组讨论该文件期间提供了详细的评论。
Authors' Addresses
作者地址
Robert Sparks Oracle 7460 Warren Parkway Suite 300 Frisco, Texas 75034 United States
Robert Sparks Oracle 7460 Warren Parkway套房300美国德克萨斯州弗里斯科75034
Email: rjsparks@nostrum.com
Email: rjsparks@nostrum.com
Adam Roach Mozilla Dallas, TX United States
Adam Roach Mozilla美国德克萨斯州达拉斯
Phone: +1 650 903 0800 x863
Email: adam@nostrum.com
Phone: +1 650 903 0800 x863
Email: adam@nostrum.com