Internet Engineering Task Force (IETF) A.B. Roach
Request for Comments: 7621 Mozilla
Updates: 6665 August 2015
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A.B. Roach
Request for Comments: 7621 Mozilla
Updates: 6665 August 2015
Category: Standards Track
ISSN: 2070-1721
A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework
关于在SIP事件通知框架中使用全局可路由用户代理URI（GROUS）的说明
Abstract
摘要
Experience since the publication of the most recent SIP Events framework (in July 2012) has shown that there is room for interpretation around the use of Globally Routable User Agent URIs in that specification. This document clarifies the intended behavior.
自最新的SIP事件框架（2012年7月）发布以来的经验表明，在该规范中使用全局可路由用户代理URI存在解释空间。本文件澄清了预期行为。
This document updates RFC 6665.
本文件更新了RFC 6665。
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/rfc7621.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7621.
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. Clarification of GRUU Handling . . . . . . . . . . . . . . . 2
3. Security Considerations . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
5. Normative References . . . . . . . . . . . . . . . . . . . . 3
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Clarification of GRUU Handling . . . . . . . . . . . . . . . 2
3. Security Considerations . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
5. Normative References . . . . . . . . . . . . . . . . . . . . 3
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4
This document is intended to clarify a point of implementor confusion arising from lack of clarity in [RFC6665].
本文件旨在澄清由于[RFC6665]中缺乏明确性而导致的实施者混淆点。
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] contains the following normative requirement on implementations:
[RFC6665]第4.5.1节包含以下关于实施的规范性要求：
Notifiers MUST implement the Globally Routable User Agent URI (GRUU) extension defined in [RFC5627], and MUST use a GRUU as their local target. This allows subscribers to explicitly target desired devices.
通知程序必须实现[RFC5627]中定义的全局可路由用户代理URI（GRUU）扩展，并且必须使用GRUU作为其本地目标。这允许订阅者明确地以所需的设备为目标。
The second sentence of this paragraph attempted to set context for the normative statement: the reason GRUUs are required in this context is to allow you to send SUBSCRIBE or REFER requests to a specific user agent, with the target of the subscription request being something like an INVITE dialog on that device. Consequently, the requirement to include a GRUU as a local target was intended to apply not just to the local target for SUBSCRIBE-created dialogs, but to *all* dialogs, even those created by INVITE. This requirement has been interpreted in a variety of ways by implementors, so a clarification is in order.
本段的第二句试图为规范性语句设置上下文：在该上下文中需要GROUS的原因是允许您向特定的用户代理发送订阅或引用请求，订阅请求的目标类似于该设备上的INVITE对话框。因此，将GRUU作为本地目标的要求不仅适用于订阅创建的对话框的本地目标，还适用于*all*对话框，甚至是由INVITE创建的对话框。实现者以各种方式解释了该需求，因此需要进行澄清。
Discussion subsequent to the publication of [RFC6665] has highlighted obscure cases in which implementations might be notifiers in some contexts, but may not wish to act as notifiers in others. Under these narrow circumstances, the restriction described above is not necessary for dialogs about which the notifier will never accept subscriptions (although the use of GRUUs in such a context causes no harm, either).
[RFC6665]发布后的讨论强调了一些模糊的情况，在这些情况下，实现在某些上下文中可能是通知程序，但在其他上下文中可能不希望充当通知程序。在这些狭隘的情况下，对于通知程序永远不会接受订阅的对话框，上述限制是不必要的（尽管在这样的上下文中使用GROUS也不会造成任何伤害）。
This document updates [RFC6665] to clarify the actual requirements. The replacement text is as follows:
本文件更新了[RFC6665]，以澄清实际要求。替换案文如下：
Notifiers MUST implement the Globally Routable User Agent URI (GRUU) extension defined in [RFC5627]. Notifiers MUST use a GRUU as their local target for all dialog-forming methods and all target-refresh methods, except for those dialogs for which they will reject all subscription requests (implicit or explicit). For clarity: an implementation that uses a non-GRUU local contact under the exception described above MUST reject a request that might create a subscription to the associated dialog, regardless of whether such subscription would be created by a SUBSCRIBE or a REFER message. The rejection code under such conditions SHOULD be 403 (Forbidden) unless some other code is more appropriate to the circumstances. The foregoing requirements to implement and use GRUUs specifically include dialogs created by the INVITE method.
通知程序必须实现[RFC5627]中定义的全局可路由用户代理URI（GRUU）扩展。通知程序必须将GRUU用作所有对话框形成方法和所有目标刷新方法的本地目标，但拒绝所有订阅请求（隐式或显式）的对话框除外。为清楚起见：在上述异常情况下使用非GRUU本地联系人的实现必须拒绝可能创建关联对话框订阅的请求，无论该订阅是由订阅还是引用消息创建的。这种情况下的拒收代码应为403（禁止），除非其他代码更适合这种情况。实现和使用GROUS的上述要求特别包括由INVITE方法创建的对话框。
This mechanism does not introduce any security issues beyond those discussed in [RFC6665].
除[RFC6665]中讨论的安全问题外，该机制不会引入任何安全问题。
This document requests no actions of IANA.
本文件不要求IANA采取任何行动。
[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>.
[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>.
Author's Address
作者地址
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