Internet Engineering Task Force (IETF) A. Niemi
Request for Comments: 5839 Nokia
Category: Standards Track D. Willis, Ed.
ISSN: 2070-1721 Softarmor Systems
May 2010
Internet Engineering Task Force (IETF) A. Niemi
Request for Comments: 5839 Nokia
Category: Standards Track D. Willis, Ed.
ISSN: 2070-1721 Softarmor Systems
May 2010
An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification
用于条件事件通知的会话启动协议（SIP）事件的扩展
Abstract
摘要
The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing, and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed.
会话启动协议（SIP）事件框架允许从其他SIP用户代理接收各种事件的异步通知。该框架定义了创建、刷新和终止订阅以及获取和定期轮询资源状态的过程。这些过程不提供任何工具来避免重播用户代理已接收到的事件通知。此备忘录定义了SIP事件的扩展，该扩展允许订阅者将订阅请求的条件设置为自收到上一次通知后状态是否已更改。如果此条件为真，则结果事件通知的正文或整个通知消息将被抑制。
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/rfc5839.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5839.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Document Conventions . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Motivations and Background . . . . . . . . . . . . . . . . . . 5
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Problem Description . . . . . . . . . . . . . . . . . . . 5
2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4. Resource Model for Entity-Tags . . . . . . . . . . . . . . . . 10
5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 12
5.1. Detecting Support for Conditional Notification . . . . . . 13
5.2. Generating SUBSCRIBE Requests . . . . . . . . . . . . . . 13
5.3. Receiving NOTIFY Requests . . . . . . . . . . . . . . . . 14
5.4. Polling or Fetching Resource State . . . . . . . . . . . . 15
5.5. Resuming a Subscription . . . . . . . . . . . . . . . . . 17
5.6. Refreshing a Subscription . . . . . . . . . . . . . . . . 18
5.7. Terminating a Subscription . . . . . . . . . . . . . . . . 18
5.8. Handling Transient Errors . . . . . . . . . . . . . . . . 19
6. Notifier Behavior . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Generating Entity-tags . . . . . . . . . . . . . . . . . . 20
6.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 20
6.3. Suppressing NOTIFY Requests . . . . . . . . . . . . . . . 21
6.4. State Differentials . . . . . . . . . . . . . . . . . . . 21
6.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 22
7. Protocol Element Definitions . . . . . . . . . . . . . . . . . 22
7.1. 204 (No Notification) Response Code . . . . . . . . . . . 22
7.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 22
7.3. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8.1. 204 (No Notification) Response Code . . . . . . . . . . . 23
8.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Document Conventions . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Motivations and Background . . . . . . . . . . . . . . . . . . 5
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Problem Description . . . . . . . . . . . . . . . . . . . 5
2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4. Resource Model for Entity-Tags . . . . . . . . . . . . . . . . 10
5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 12
5.1. Detecting Support for Conditional Notification . . . . . . 13
5.2. Generating SUBSCRIBE Requests . . . . . . . . . . . . . . 13
5.3. Receiving NOTIFY Requests . . . . . . . . . . . . . . . . 14
5.4. Polling or Fetching Resource State . . . . . . . . . . . . 15
5.5. Resuming a Subscription . . . . . . . . . . . . . . . . . 17
5.6. Refreshing a Subscription . . . . . . . . . . . . . . . . 18
5.7. Terminating a Subscription . . . . . . . . . . . . . . . . 18
5.8. Handling Transient Errors . . . . . . . . . . . . . . . . 19
6. Notifier Behavior . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Generating Entity-tags . . . . . . . . . . . . . . . . . . 20
6.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 20
6.3. Suppressing NOTIFY Requests . . . . . . . . . . . . . . . 21
6.4. State Differentials . . . . . . . . . . . . . . . . . . . 21
6.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 22
7. Protocol Element Definitions . . . . . . . . . . . . . . . . . 22
7.1. 204 (No Notification) Response Code . . . . . . . . . . . 22
7.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 22
7.3. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8.1. 204 (No Notification) Response Code . . . . . . . . . . . 23
8.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 24
The Session Initiation Protocol (SIP) events framework provides an extensible facility for requesting notification of certain events from other SIP user agents. This framework includes procedures for creating, refreshing, and terminating subscriptions, as well as the possibility to fetch or periodically poll the event resource.
会话发起协议（SIP）事件框架提供了一个可扩展的工具，用于请求来自其他SIP用户代理的特定事件通知。此框架包括创建、刷新和终止订阅的过程，以及获取或定期轮询事件资源的可能性。
Several instantiations of this framework, called event packages have been defined, e.g., for presence [RFC3856], message waiting indications [RFC3842], and registrations [RFC3680].
已经定义了该框架的几个实例，称为事件包，例如，存在[RFC3856]、消息等待指示[RFC3842]和注册[RFC3680]。
By default, every SUBSCRIBE request generates a NOTIFY request containing the latest event state. Typically, a SUBSCRIBE request is issued by the subscriber whenever it needs a subscription to be installed, periodically refreshed, or terminated. Once the subscription has been installed, the majority of the NOTIFYs generated by the subscription refreshes are superfluous; the subscriber usually is in possession of the event state already, except in the unlikely case where a state change exactly coincides with the periodic subscription refresh. In most cases, the final event state generated upon terminating the subscription similarly contains resource state that the subscriber already has.
默认情况下，每个订阅请求都会生成一个包含最新事件状态的NOTIFY请求。通常，订阅服务器在需要安装、定期刷新或终止订阅时发出订阅请求。安装订阅后，订阅刷新生成的大部分NOTIFY都是多余的；订阅者通常已经拥有事件状态，除非在不太可能的情况下，状态更改与定期订阅刷新完全一致。在大多数情况下，终止订阅时生成的最终事件状态类似地包含订阅服务器已经具有的资源状态。
Fetching or polling of resource state behaves in a similarly suboptimal way in cases where the state has not changed since the previous poll occurred. In general, the problem lies with the inability to persist state across a SUBSCRIBE request.
如果自上次轮询发生后资源状态未发生更改，则资源状态的获取或轮询的行为也会以类似的次优方式进行。通常，问题在于无法在订阅请求中保持状态。
This memo defines an extension to optimize the SIP events framework. This extension allows a notifier to tag notifications (called entity-tags hereafter) and the subscriber to condition its subsequent SUBSCRIBE requests for actual changes since a notification carrying that entity-tag was issued. The solution is similar to conditional requests defined in the Hypertext Transfer Protocol (HTTP) [RFC2616], and follows the mechanism already defined for the PUBLISH [RFC3903] method for issuing conditional event publications.
此备忘录定义了一个扩展以优化SIP事件框架。此扩展允许通知程序标记通知（以下称为实体标记），订阅者自发出带有该实体标记的通知以来，调节其后续订阅请求的实际更改。该解决方案类似于超文本传输协议（HTTP）[RFC2616]中定义的条件请求，并遵循已经为发布[RFC3903]方法定义的机制来发布条件事件发布。
This memo is structured as follows. Section 2 explains the background, motivations, and requirements for the work; Section 3 gives a general overview of the mechanism; Section 4 explains the underlying model for resources and entities as they apply to conditional notification; Section 5 defines the subscriber behavior; Section 6 defines the notifier behavior; Section 7 includes the protocol element definitions; Section 8 includes the IANA considerations; and Section 9 includes the security considerations.
本备忘录的结构如下。第2节解释了工作的背景、动机和要求；第3节概述了该机制；第4节解释了适用于有条件通知的资源和实体的基本模型；第5节定义了认购人的行为；第6节定义了通知程序的行为；第7节包括协议元素定义；第8节包括IANA考虑因素；第9节包括安全考虑。
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 BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的描述进行解释，并指出合规实施的要求级别。
In addition to the terminology introduced in [RFC3261], [RFC3265], and [RFC3903], this specification uses these additional terms to describe the objects of conditional notification:
除了[RFC3261]、[RFC3265]和[RFC3903]中介绍的术语外，本规范还使用这些附加术语来描述有条件通知的对象：
resource An object identified by a URI whose resource state can be accessed using the SIP Event Notification framework. There is a single authoritative notifier responsible for communicating the resource state.
资源由URI标识的对象，可以使用SIP事件通知框架访问该URI的资源状态。只有一个权威通知程序负责传递资源状态。
entity The representation of resource state. An entity consists of the state data carried in the body of a NOTIFY message, as well as related meta-data in the message header. There may be many versions of an entity, one current and the others stale. Each version of an entity is identified by an entity-tag, which is guaranteed to be unique across all versions of all entities for a resource and event package.
实体资源状态的表示。实体由NOTIFY消息体中携带的状态数据以及消息头中的相关元数据组成。一个实体可能有多个版本，一个是当前版本，另一个是过时版本。实体的每个版本都由一个实体标记标识，该标记保证在资源和事件包的所有实体的所有版本中都是唯一的。
A SUBSCRIBE request creates a subscription with a finite lifetime. This lifetime is negotiated using the Expires header field, and unless the subscription is refreshed by the subscriber before the expiration is met, the subscription is terminated. The frequency of these subscription refreshes depends on the event package, and typically ranges from minutes to hours.
订阅请求创建具有有限生存期的订阅。此生存期是使用Expires标头字段协商的，除非订阅服务器在到期之前刷新订阅，否则订阅将终止。这些订阅刷新的频率取决于事件包，通常从分钟到小时不等。
The SIP events framework does not include different protocol methods for initiating and terminating of subscriptions, subscription refreshes, and fetches inside and outside of the SIP dialog. The SUBSCRIBE method is overloaded to perform all of these functions. The difference between a fetch that does not create a (lasting) subscription and a SUBSCRIBE that creates one is in the Expires
SIP事件框架不包括用于在SIP对话框内外启动和终止订阅、订阅刷新和获取的不同协议方法。SUBSCRIBE方法被重载以执行所有这些函数。不创建（持久）订阅的获取与创建（持久）订阅的订阅之间的区别在于过期
header field value of the SUBSCRIBE; a zero-expiry SUBSCRIBE only generates a single NOTIFY, after which the subscription immediately terminates. Lasting subscriptions typically have relatively short expiry periods, requiring periodic sending of new SUBSCRIBE requests in order to refresh the subscription.
订阅的头字段值；零到期订阅只生成一个通知，之后订阅立即终止。持久订阅通常具有相对较短的到期期限，需要定期发送新订阅请求以刷新订阅。
Each new SUBSCRIBE request generates a NOTIFY request containing the latest resource state. Even if the state has not changed, it is sent again in response to each poll or subscription refresh. This is very similar to the HTTP [RFC2616] problem of repeated GET operations on a resource. HTTP solves the problem using conditional requests. The server versions each entity with an entity-tag that identifies a specific instance of that entity. Clients making GET requests can then include the entity-tag for the version of the entity that they believe to be current in an "If-None-Match" header field. The server can compare this entity-tag to the entity it believes to be current and suppress resending the entity in the response if the server believes the client's version matches. In other words, the server doesn't resend information that the client has already received.
每个新的订阅请求生成一个包含最新资源状态的通知请求。即使状态没有更改，也会再次发送该状态以响应每次轮询或订阅刷新。这与HTTP[RFC2616]在资源上重复GET操作的问题非常相似。HTTP使用条件请求解决了这个问题。服务器使用实体标记对每个实体进行版本设置，该标记标识该实体的特定实例。然后，发出GET请求的客户端可以在“If None Match”头字段中包含他们认为是当前实体版本的实体标记。服务器可以将此实体标记与它认为是当前的实体进行比较，如果服务器认为客户端的版本匹配，则禁止在响应中重新发送该实体。换句话说，服务器不会重新发送客户端已经接收到的信息。
The SIP PUBLISH [RFC3903] method uses a similar mechanism, where a refresh of a publication is done by reference to its assigned entity-tag, instead of retransmitting the event state each time the publication expiration is extended.
SIP PUBLISH[RFC3903]方法使用类似的机制，其中通过引用其分配的实体标记来刷新发布，而不是在每次发布过期时重新传输事件状态。
As a summary, here is the required functionality to solve the presented issues:
作为总结，以下是解决上述问题所需的功能：
REQ1: It must be possible to suppress the NOTIFY request (or at a minimum, the event body therein) if the subscriber is already in possession of (or has previously received and discarded) the latest event state of the resource.
REQ1：如果订户已经拥有（或之前已经接收并丢弃）资源的最新事件状态，则必须能够抑制NOTIFY请求（或至少抑制其中的事件体）。
REQ2: This mechanism must apply to initial subscriptions in which the subscriber is attempting to resume an earlier subscription that has been paused.
REQ2：此机制必须适用于初始订阅，其中订阅服务器尝试恢复已暂停的早期订阅。
REQ3: This mechanism must apply to refreshing a subscription.
REQ3：此机制必须应用于刷新订阅。
REQ4: This mechanism must apply to terminating a subscription (i.e., an unsubscribe).
要求4：此机制必须适用于终止订阅（即取消订阅）。
REQ5: This mechanism must apply to fetching or polling of resource state.
REQ5：此机制必须应用于获取或轮询资源状态。
Whenever a subscriber initiates a subscription, it issues a SUBSCRIBE request. The SUBSCRIBE request is sent, routed, and processed by the notifier normally, i.e., according to the Session Initiation Protocol [RFC3261] and SIP-Specific Event Notification [RFC3265].
每当订户发起订阅时，都会发出订阅请求。订阅请求通常由通知程序发送、路由和处理，即，根据会话启动协议[RFC3261]和SIP特定事件通知[RFC3265]。
If the notifier receiving the SUBSCRIBE request supports conditional subscriptions, it generates an entity-tag for the current entity, and includes it in a SIP-ETag header field of the NOTIFY request. The entity-tag is unique across all versions of all entities for a resource and event package. See Section 4 for more on this.
如果接收订阅请求的通知程序支持条件订阅，它将为当前实体生成一个实体标记，并将其包含在通知请求的SIP ETag头字段中。对于资源和事件包，实体标记在所有实体的所有版本中都是唯一的。有关这方面的更多信息，请参见第4节。
Entity-tags are independent of subscriptions. This allows notifications generated to a fetch or a poll to have valid entity-tags even across subsequent fetches or polls.
实体标记独立于订阅。这使得为获取或轮询生成的通知即使在后续获取或轮询中也具有有效的实体标记。
The subscriber will store the entity-tag received in the notification along with the resource state. It can then later use this entity-tag to make a SUBSCRIBE contain a condition in the form of a "Suppress-If-Match" header field. Unlike the "If-Match" condition in a PUBLISH [RFC3903] request, which applies to whether the PUBLISH succeeds or returns an error, this condition applies to the stream of notifications that are sent after the SUBSCRIBE request has been processed.
订户将存储通知中接收到的实体标记以及资源状态。然后，它可以稍后使用该实体标记使订阅包含一个“Suppress If Match”头字段形式的条件。发布[RFC3903]请求中的“如果匹配”条件适用于发布是否成功或是否返回错误，与此不同，此条件适用于处理订阅请求后发送的通知流。
The Suppress-If-Match header field contains the last entity-tag seen by the subscriber. This condition, if true, instructs the notifier to suppress either the body of a subsequent notification, or the entire notification.
抑制如果匹配标头字段包含订阅服务器看到的最后一个实体标记。如果此条件为true，则指示通知程序抑制后续通知的正文或整个通知。
The condition is evaluated by matching the value of the header field against the entity-tag of the entity that would normally be sent in the associated NOTIFY message. There is also a wildcard entity-tag with a special value of "*" that always matches.
通过将header字段的值与通常在关联的NOTIFY消息中发送的实体的实体标记相匹配来评估该条件。还有一个通配符实体标记，其特殊值为“*”，始终匹配。
Subscriber Notifier
---------- --------
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Expires: 3600
<-------- (2) 200 (or 202)
(1) SUBSCRIBE -------->
Expires: 3600
<-------- (2) 200 (or 202)
<-------- (3) NOTIFY
Subscription-State: active
SIP-ETag: ffee2
(4) 200 -------->
<-------- (3) NOTIFY
Subscription-State: active
SIP-ETag: ffee2
(4) 200 -------->
... time passes ...
... 时光流逝。。。
(5) SUBSCRIBE --------> \ if "ffee2"
Suppress-If-Match: ffee2 | matches
Expires: 3600 | local
| entity-tag
|
<-------- (6) 204 / then
(5) SUBSCRIBE --------> \ if "ffee2"
Suppress-If-Match: ffee2 | matches
Expires: 3600 | local
| entity-tag
|
<-------- (6) 204 / then
... time passes and resource state (entity) changes...
... 时间流逝和资源状态（实体）更改。。。
<-------- (7) NOTIFY
Subscription-State: active
SIP-ETag: ca89a
(8) 200 -------->
<-------- (7) NOTIFY
Subscription-State: active
SIP-ETag: ca89a
(8) 200 -------->
... time passes ...
... 时光流逝。。。
(9) SUBSCRIBE --------> \ if "ca89"
Suppress-If-Match: ca89a | matches
Expires: 0 | local
| entity-tag
|
<-------- (10) 204 / then
(9) SUBSCRIBE --------> \ if "ca89"
Suppress-If-Match: ca89a | matches
Expires: 0 | local
| entity-tag
|
<-------- (10) 204 / then
Figure 1: Example Message Flow
图1：示例消息流
Figure 1 describes a typical message flow for conditional notification:
图1描述了条件通知的典型消息流：
(1) The subscriber initiates a subscription by sending a SUBSCRIBE request for a resource.
(1) 订阅者通过发送资源的订阅请求来发起订阅。
(2) After proper authentication and authorization, the notifier accepts the subscription.
(2) 在正确的身份验证和授权之后，通知程序接受订阅。
(3) The notifier then immediately sends the initial event notification, including a unique entity-tag in a SIP-ETag header field.
(3) 然后，通知程序立即发送初始事件通知，包括SIP ETag头字段中的唯一实体标记。
(4) The subscriber accepts the notification and stores the entity-tag value along with the resource state.
(4) 订户接受通知并将实体标记值与资源状态一起存储。
(5) Later, the subscriber refreshes the subscription, and includes an entity-tag in a Suppress-If-Match header field.
(5) 稍后，订阅服务器刷新订阅，并在抑制If匹配头字段中包含实体标记。
(6) The notifier evaluates the condition by matching its local entity-tag value for the resource against the value of the Suppress-If-Match header field. If the condition evaluates to true, the notifier informs the subscriber that the notification will not be sent.
(6) 通知程序通过将资源的本地实体标记值与Suppress If Match标头字段的值相匹配来评估条件。如果条件的计算结果为true，通知程序将通知订户将不发送通知。
(7) At some point, the state of the resource changes, e.g., the presence status of a user changes from online to busy. This triggers an event notification with a new value in the SIP-ETag header field.
(7) 在某一点上，资源的状态改变，例如，用户的存在状态从在线改变为忙碌。这会在SIP ETag头字段中触发具有新值的事件通知。
(8) The subscriber accepts the notification and stores the new entity-tag along with the resource state.
(8) 订阅者接受通知并将新的实体标记与资源状态一起存储。
(9) After a while, the subscriber decides to terminate the subscription. It adds a condition for Suppress-If-Match, and includes the entity-tag it received in the previous NOTIFY.
(9) 一段时间后，订户决定终止订阅。它添加了抑制If匹配的条件，并包括它在上一次通知中收到的实体标记。
(10) The notifier evaluates the condition by matching its entity-tag for the resource against the value of the Suppress-If-Match header field. If the condition evaluates to true, the notifier informs the subscriber that no notification will be sent. This concludes the subscription.
（10） 通知程序通过将资源的实体标记与Suppress If Match标头字段的值相匹配来评估条件。如果条件的计算结果为true，通知程序将通知订户不发送通知。订阅到此结束。
The benefit of using conditional notification in this example is in the reduction of the number of NOTIFY requests the subscriber can expect to receive. Each event notification that the subscriber has already seen is suppressed by the notifier. This example illustrates only one use case for the mechanism; the same principles can be used to optimize the flow of messages related to other event notification use cases.
在本例中使用条件通知的好处在于减少了订阅者预期接收的通知请求数量。订户已经看到的每个事件通知都会被通知程序抑制。该示例仅说明了该机制的一个用例；相同的原则可用于优化与其他事件通知用例相关的消息流。
The key to understanding how conditional notification works is understanding the underlying resource model of event notification. In general, this model is similar to the resource model of HTTP with some key differences. This section explains in detail the model as it applies to SIP events. Figure 2 illustrates the model.
理解条件通知如何工作的关键是理解事件通知的底层资源模型。一般来说，该模型与HTTP的资源模型类似，但有一些关键区别。本节详细解释了适用于SIP事件的模型。图2说明了该模型。
+-----+
............ | |
. . | URI |
. Represen . | |
. tation . +-----+
. . |*
............ |
. |
. V
. +----------+ +---------+
composition | |* | Event |
+------<>| Resource |----------->| Package |<----.
| | | | | |
| +----------+ +----.----+ |
| /_\ |
|* | classification
+--------+ | |
| | .----------------.------' |
| Entity | | | |
| | | | |*
+--------+ +----------+ +------------+ +----------+
^ | | | | | |
| | Presence | | Conference | | Template |
| | | | | | |
|1..* +----------+ +------------+ +----.-----+
+---------+ /_\
| | |
| Version | |
| | +---------+
+---------+ | Watcher |
|1 | Info |
| | |
V +---------+
+---------+
| Entity- |
| Tag |
| |
+---------+
+-----+
............ | |
. . | URI |
. Represen . | |
. tation . +-----+
. . |*
............ |
. |
. V
. +----------+ +---------+
composition | |* | Event |
+------<>| Resource |----------->| Package |<----.
| | | | | |
| +----------+ +----.----+ |
| /_\ |
|* | classification
+--------+ | |
| | .----------------.------' |
| Entity | | | |
| | | | |*
+--------+ +----------+ +------------+ +----------+
^ | | | | | |
| | Presence | | Conference | | Template |
| | | | | | |
|1..* +----------+ +------------+ +----.-----+
+---------+ /_\
| | |
| Version | |
| | +---------+
+---------+ | Watcher |
|1 | Info |
| | |
V +---------+
+---------+
| Entity- |
| Tag |
| |
+---------+
Figure 2: Resource Model Diagram
图2：资源模型图
For a given event package, there is a single authoritative agent responsible for zero or more resources. That is, even for a distributed agent, the resource state is uniform across all instances. The resource itself can be a list of resources [RFC4662]. Conditional notification for list subscriptions is addressed in Section 6.5.
对于给定的事件包，只有一个权威代理负责零个或多个资源。也就是说，即使对于分布式代理，资源状态在所有实例中都是统一的。资源本身可以是资源列表[RFC4662]。第6.5节介绍了列表订阅的条件通知。
A resource is identified by zero or more URIs, which can be SIP URIs, pres URIs [RFC3859], or similar. Subscribers use this URI to subscribe to the resource for certain types of events, identified by the event package.
资源由零个或多个URI标识，这些URI可以是SIP URI、pres URI[RFC3859]或类似的URI。订阅者使用此URI为事件包标识的特定类型的事件订阅资源。
With a successful subscription, a subscriber receives event notifications that communicate the resource state and the changes thereto. Each event notification carries a representation of the current resource state. This representation is influenced by many factors, e.g., authorization and filtering rules, and the event composition rules of the notifier.
订阅成功后，订阅服务器将接收事件通知，通知资源状态及其更改。每个事件通知都包含当前资源状态的表示。此表示受许多因素的影响，例如授权和筛选规则，以及通知程序的事件组合规则。
This representation is realized in an "entity". Each resource may be associated with zero or more entities. For example, there may be multiple subscribers to the presence information of a single user (a resource), and each subscriber may have a different filtered view of that resource, producing one entity per subscriber. However, each entity is associated with one and only one resource; there is no "compositing" of resources at the entity level. Resources may themselves be made up of information from other resources (be "composite resources"), but this does not change the one-resource-per-entity rule.
这种表示在“实体”中实现。每个资源可以与零个或多个实体相关联。例如，单个用户（资源）的存在信息可能有多个订阅者，并且每个订阅者可能具有该资源的不同过滤视图，从而为每个订阅者生成一个实体。然而，每个实体仅与一个资源相关联；实体级别没有资源的“合成”。资源本身可能由来自其他资源的信息组成（即“复合资源”），但这不会改变每个实体一个资源的规则。
An entity consists of the data carried in the body of a NOTIFY message and related meta-data in the message header. Whenever the data in the body or any of the meta-data changes, the notifier MUST produce a new entity-tag. This meta-data MUST include, but is not limited to the following SIP header fields defined in the Session Initiation Protocol [RFC3261] and SIP Specific Event Notification [RFC3265]:
实体由NOTIFY消息体中的数据和消息头中的相关元数据组成。每当正文中的数据或任何元数据发生更改时，通知程序必须生成一个新的实体标记。此元数据必须包括但不限于会话启动协议[RFC3261]和SIP特定事件通知[RFC3265]中定义的以下SIP头字段：
1. Content-Disposition
1. 内容配置
2. Content-Encoding
2. 内容编码
3. Content-Language
3. 内容语言
4. Content-Length
4. 内容长度
5. Content-Type
5. 内容类型
6. Event
6. 事件
Note that the Subscription-State is explicitly not part of the entity. In the future, event packages may define additional fields that implementations need to consider as part of the entity.
请注意，订阅状态不是实体的一部分。在将来，事件包可以定义实现需要作为实体的一部分考虑的附加字段。
An entity has one or more versions of which only one is current and all others stale. Each version has an entity-tag, which uniquely identifies it across all versions of all entities pertaining to a single resource and event package.
一个实体有一个或多个版本，其中只有一个是当前版本，其他所有版本都是过时版本。每个版本都有一个实体标记，它在与单个资源和事件包相关的所有实体的所有版本中唯一地标识它。
Note that two entity-tags for different resources being equal does not indicate identical entities. In other words, if an entity-tag received for a subscription to a first resource matches an entity-tag received for a subscription to a second resource, the subscriber cannot assume that the two entity values are equal.
请注意，不同资源的两个实体标记相等并不表示相同的实体。换句话说，如果为第一资源的订阅接收的实体标记与为第二资源的订阅接收的实体标记匹配，则订户不能假定这两个实体值相等。
With partial event notification, the NOTIFY message only carries the delta state, or the set of changes to the previous version of the entity. In that case, implementations MUST consider the full event state as the version of the entity to which the entity-tag in the NOTIFY message applies.
对于部分事件通知，NOTIFY消息仅携带增量状态或对实体先前版本的更改集。在这种情况下，实现必须将完整事件状态视为通知消息中实体标签应用到的实体的版本。
The conditional notification mechanism is independent of the way in which subscriptions are installed. In other words, the mechanism supports implicit subscriptions, such as those associated with the REFER method [RFC3515].
条件通知机制独立于订阅的安装方式。换句话说，该机制支持隐式订阅，例如与refere方法[RFC3515]关联的订阅。
It is possible that the same resource is in some shape or form accessible through another mechanism in addition to SIP Event Notification, e.g., HTTP or the SIP PUBLISH method. In general, implementations MUST NOT expect the entity-tags to be shared between the mechanisms, unless event packages or specific applications of SIP events explicitly define such dependencies.
除了SIP事件通知（例如HTTP或SIP发布方法）之外，还可能通过另一种机制以某种形状或形式访问相同的资源。通常，除非SIP事件的事件包或特定应用程序明确定义了此类依赖关系，否则实现不能期望实体标记在机制之间共享。
This section augments the subscriber behavior defined in RFC 3265 [RFC3265]. It first discusses general issues related to indicating support for the mechanism (Section 5.1) and creating conditions in SUBSCRIBE requests (Section 5.2). Next, it describes subscriber behavior for receiving NOTIFY requests (Section 5.3), and specific client workflows for polling resource state (Section 5.4), resuming a subscription (Section 5.5), refreshing a subscription (Section 5.6), and terminating a subscription (Section 5.7). Finally, handling of transient errors is discussed (Section 5.8).
本节扩充了RFC 3265[RFC3265]中定义的订户行为。它首先讨论与表示支持该机制（第5.1节）和在订阅请求中创建条件（第5.2节）相关的一般问题。接下来，它描述了接收通知请求（第5.3节）的订户行为，以及轮询资源状态（第5.4节）、恢复订阅（第5.5节）、刷新订阅（第5.6节）和终止订阅（第5.7节）的特定客户端工作流。最后，讨论了瞬态误差的处理（第5.8节）。
The mechanism defined in this memo is backwards compatible with SIP events [RFC3265] in that a notifier supporting this mechanism will insert a SIP entity-tag in its NOTIFY requests, and a subscriber that understands this mechanism will know how to use it in creating a conditional request.
此备忘录中定义的机制与SIP事件[RFC3265]向后兼容，因为支持此机制的通知程序将在其NOTIFY请求中插入SIP实体标记，而了解此机制的订户将知道如何使用它创建条件请求。
Unaware subscribers will simply ignore the entity-tag, make requests without conditions, and receive the default treatment from the notifier. Unaware notifiers will simply ignore the conditional header fields and continue normal operation.
不知情的订阅者只需忽略实体标记，无条件地发出请求，并从通知程序接收默认处理。不知道的通知程序将忽略条件标头字段并继续正常操作。
When creating a conditional SUBSCRIBE request, the subscriber MUST include a single conditional header field including an entity-tag in the request. The condition is evaluated by comparing the entity-tag of the subscribed resource with the entity-tag carried in the conditional header field. If they match, the condition evaluates to true.
创建条件订阅请求时，订阅服务器必须在请求中包含一个包含实体标记的单个条件头字段。通过将订阅资源的实体标记与条件标头字段中携带的实体标记进行比较来评估条件。如果它们匹配，则条件的计算结果为true。
Unlike the condition introduced for the SIP PUBLISH [RFC3903] method, these conditions do not apply to the SUBSCRIBE request itself, but to the resulting NOTIFY requests. When true, the condition drives the notifier to change its behavior with regard to sending the notifications after the SUBSCRIBE.
与SIP PUBLISH[RFC3903]方法引入的条件不同，这些条件不适用于订阅请求本身，而是适用于生成的NOTIFY请求。如果为true，则该条件会促使通知程序更改其在订阅后发送通知的行为。
This specification defines a new header field called Suppress-If-Match. This header field introduces a condition to the SUBSCRIBE request. If true, it instructs the notifier either to omit the body of the resulting NOTIFY message (if the SUBSCRIBE is not sent within an existing dialog) or to suppress (i.e., block) the NOTIFY request that would otherwise be triggered by the SUBSCRIBE (for an established dialog). In the latter case, the SUBSCRIBE message will be answered with a 204 (No Notification) response. As long as the condition remains true, it also instructs the notifier either to suppress any subsequent NOTIFY request or, if there are reportable changes in the NOTIFY header, e.g., the Subscription-State has changed, to suppress the body of any subsequent NOTIFY request.
此规范定义了一个名为Suppress If Match的新标题字段。此标头字段向订阅请求引入条件。如果为true，则指示通知程序忽略结果NOTIFY消息的正文（如果订阅未在现有对话框中发送），或禁止（即，阻止）订阅将触发的NOTIFY请求（对于已建立的对话框）。在后一种情况下，订阅消息将得到204（无通知）响应。只要条件保持为真，它还指示通知程序抑制任何后续通知请求，或者，如果通知头中存在可报告的更改（例如，订阅状态已更改），则指示通知程序抑制任何后续通知请求的正文。
If the condition is false, the notifier follows its default behavior.
如果条件为false，通知程序将遵循其默认行为。
If the subscriber receives a 204 (No Notification) response to an in-dialog SUBSCRIBE, the subscriber MUST consider the event state and the subscription state unchanged.
如果订户接收到对IN对话订阅的204（无通知）响应，订阅者必须考虑事件状态和订阅状态不变。
The value of the Suppress-If-Match header field is an entity-tag, which is an opaque token that the subscriber simply copies (byte-wise) from a previously received NOTIFY request. Inclusion of an entity-tag in a Suppress-If-Match header field of a SUBSCRIBE request indicates that the client has a copy of, or is capable of recreating a copy of, the entity associated with that entity-tag.
Suppress If Match header字段的值是一个实体标记，这是一个不透明的标记，订阅者只需从以前接收到的通知请求复制（按字节复制）。在SUBSCRIBE请求的Suppress If Match标头字段中包含实体标记表示客户端具有与该实体标记关联的实体的副本或能够重新创建该实体的副本。
Example:
例子：
Suppress-If-Match: b4cf7
如果匹配则抑制：b4cf7
The header field can also be wildcarded using the special "*" entity-tag value. Such a condition always evaluates to true regardless of the value of the current entity-tag for the resource.
标题字段也可以使用特殊的“*”实体标记值进行通配符。无论资源的当前实体标记的值如何，此类条件的计算结果始终为true。
Example:
例子：
Suppress-If-Match: *
如果匹配，则抑制：*
Such a wildcard condition effectively quenches a subscription; the only notifications received are those reporting changes to the subscription state and those in response to a SUBSCRIBE message sent outside of an existing dialog. In both cases, the notifications will not contain a body.
这种通配符条件有效地终止了订阅；收到的唯一通知是那些报告订阅状态更改的通知和那些响应在现有对话框外部发送的订阅消息的通知。在这两种情况下，通知都不包含正文。
A subscription with a wildcard Suppress-If-Match condition is useful in scenarios where the subscriber wants to temporarily put a subscription in dormant mode. For example, a host may want to conserve bandwidth and power when it detects from screen or input device inactivity that the user isn't actively monitoring the presence statuses of contacts.
具有通配符Suppress If Match条件的订阅在订阅服务器希望临时将订阅置于休眠模式的情况下非常有用。例如，当主机从屏幕或输入设备的非活动状态检测到用户没有主动监视联系人的存在状态时，可能希望节省带宽和电源。
When a subscriber receives a NOTIFY request that contains a SIP-ETag header field, it MUST store the entity-tag if it wishes to make use of the conditional notification mechanism. The subscriber MUST be prepared to receive a NOTIFY with any entity-tag value, including a value that matches any previous value that the subscriber might have seen.
当订户收到包含SIP ETag头字段的通知请求时，如果它希望使用条件通知机制，则必须存储实体标记。订阅服务器必须准备好接收具有任何实体标记值的通知，包括与订阅服务器可能看到的任何先前值匹配的值。
The subscriber MUST NOT infer any meaning from the value of an entity-tag; specifically, the subscriber MUST NOT assume identical entities (i.e., event state) for NOTIFYs with identical entity-tag values when those NOTIFYs result from subscription to different resources.
订户不得从实体标记的值推断任何含义；具体地说，当NOTIFY由对不同资源的订阅产生时，订阅者不得为NOTIFY采用相同的实体（即事件状态）和相同的实体标记值。
Note that there are valid cases for which identical entity-tag values on different resources may occur. For example, it is possible to generate entity-tag values using a one-way hash function, resulting in the possibility that two different resources having the same entity-value will also have the same entity-tag. Clients however MUST NOT assume that this is the case, as the algorithm for the generation of entity-tags is notifier-dependent and not negotiated with the subscriber. Consequently, the subscriber cannot differentiate between two entity-tags that have the same value because they are similar hashes of identical entities, or because two notifiers happen to have used the same sequential number as an entity-tag. Entity tags are only required to be unique for a given resource, not globally unique.
请注意，在某些有效情况下，不同资源上可能会出现相同的实体标记值。例如，可以使用单向散列函数生成实体标记值，从而导致具有相同实体值的两个不同资源也将具有相同实体标记的可能性。但是，客户机不能假设这种情况，因为生成实体标记的算法依赖于通知程序，而不是与订阅者协商。因此，订户无法区分具有相同值的两个实体标记，因为它们是相同实体的相似散列，或者因为两个通知程序碰巧使用了与实体标记相同的序列号。实体标记只要求对于给定资源是唯一的，而不是全局唯一的。
Polling with conditional notification allows a user agent to efficiently poll resource state. This is accomplished using the Suppress-If-Match condition:
带条件通知的轮询允许用户代理有效地轮询资源状态。这是使用“抑制如果匹配”条件完成的：
Subscriber Notifier
---------- --------
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Expires: 0
<-------- (2) 202
(1) SUBSCRIBE -------->
Expires: 0
<-------- (2) 202
<-------- (3) NOTIFY
Subscription-State: terminated
SIP-ETag: f2e45
Content-Length: 17539
<-------- (3) NOTIFY
Subscription-State: terminated
SIP-ETag: f2e45
Content-Length: 17539
(4) 200 -------->
(4) 200 -------->
... poll interval elapses ...
... 轮询间隔已过。。。
(5) SUBSCRIBE -------->
Suppress-If-Match: f2e45
Expires: 0
<-------- (6) 202
(5) SUBSCRIBE -------->
Suppress-If-Match: f2e45
Expires: 0
<-------- (6) 202
<-------- (7) NOTIFY
Subscription-State: terminated
SIP-ETag: f2e45
Content-Length: 0
<-------- (7) NOTIFY
Subscription-State: terminated
SIP-ETag: f2e45
Content-Length: 0
(8) 200 -------->
(8) 200 -------->
Figure 3: Polling Resource State
图3：轮询资源状态
(1) The subscriber polls for resource state by sending a SUBSCRIBE with zero expiry (expires immediately).
(1) 订阅者通过发送到期时间为零（立即到期）的订阅来轮询资源状态。
(2) The notifier accepts the SUBSCRIBE with a 202 (Accepted) response.
(2) 通知程序接受带有202（已接受）响应的订阅。
(3) The notifier then immediately sends a first (and last) NOTIFY request with the current resource state and the current entity-tag in the SIP-ETag header field.
(3) 然后，通知程序立即发送第一个（也是最后一个）通知请求，其中包含SIP ETag头字段中的当前资源状态和当前实体标记。
(4) The subscriber accepts the notification with a 200 (OK) response.
(4) 订阅者接受带有200（OK）响应的通知。
(5) After some arbitrary poll interval, the subscriber sends another SUBSCRIBE with a Suppress-If-Match header field that includes the entity-tag received in the previous NOTIFY.
(5) 在某个任意轮询间隔之后，订阅者发送另一个订阅，其中包含一个SUPPORT If Match头字段，该字段包含在上一个NOTIFY中接收到的实体标记。
(6) The notifier accepts the SUBSCRIBE with a 202 (Accepted) response. (202 would be used to indicate that the subscription request was understood without also indicating that it was authorized, as per Section 3.1.6.1 of SIP-Specific Event Notification [RFC3265].)
(6) 通知程序接受带有202（已接受）响应的订阅。（根据SIP特定事件通知[RFC3265]第3.1.6.1节，202将用于表示订阅请求已被理解，而不表示其已被授权。）
(7) Since the resource state has not changed since the previous poll occurred, the notifier sends a NOTIFY message with no body. It also mirrors the current entity-tag of the resource in the SIP-ETag header field.
(7) 由于自上次轮询发生后资源状态未更改，通知程序将发送一条无正文的NOTIFY消息。它还镜像SIP ETag头字段中资源的当前实体标记。
(8) The subscriber accepts the notification with a 200 (OK) response.
(8) 订阅者接受带有200（OK）响应的通知。
Resuming a subscription means the ability to continue an earlier subscription that either closed abruptly or was explicitly terminated. When resuming, the subscription is established without transmitting the resource state. This is accomplished with conditional notification and the Suppress-If-Match header field:
恢复订阅意味着能够继续先前突然关闭或显式终止的订阅。恢复时，将在不传输资源状态的情况下建立订阅。这是通过条件通知和抑制如果匹配头字段实现的：
Subscriber Notifier
---------- --------
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: ega23
Expires: 3600
<-------- (2) 202
(1) SUBSCRIBE -------->
Suppress-If-Match: ega23
Expires: 3600
<-------- (2) 202
<-------- (3) NOTIFY
Subscription-State: active
SIP-ETag: ega23
Content-Length: 0
(4) 200 -------->
<-------- (3) NOTIFY
Subscription-State: active
SIP-ETag: ega23
Content-Length: 0
(4) 200 -------->
Figure 4: Resuming a Subscription
图4：恢复订阅
(1) The subscriber attempts to resume an earlier subscription by including a Suppress-If-Match header field with the entity-tag it last received.
(1) 订阅者试图通过使用上次接收到的实体标记包含抑制If匹配头字段来恢复早期订阅。
(2) The notifier accepts the subscription after proper authentication and authorization, by sending a 202 (Accepted) response.
(2) 通知程序通过发送202（已接受）响应，在正确的身份验证和授权后接受订阅。
(3) Since the condition is true, the notifier then immediately sends an initial NOTIFY request that has no body. It also mirrors the current entity-tag of the resource in the SIP-ETag header field.
(3) 由于条件为true，通知程序随后立即发送没有正文的初始通知请求。它还镜像SIP ETag头字段中资源的当前实体标记。
(4) The subscriber accepts the NOTIFY and sends a 200 (OK) response.
(4) 订户接受通知并发送200（OK）响应。
Had the entity-tag not been valid any longer, the condition would have evaluated to false, and the NOTIFY would have had a body containing the latest resource state.
如果实体标记不再有效，则条件的计算结果将为false，通知将具有包含最新资源状态的正文。
To refresh a subscription using conditional notification, the subscriber creates a subscription refresh before the subscription expires, and uses the Suppress-If-Match header field:
若要使用条件通知刷新订阅，订阅服务器将在订阅过期之前创建订阅刷新，并使用“抑制如果匹配头”字段：
Subscriber Notifier
---------- --------
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: aba91
Expires: 3600
(1) SUBSCRIBE -------->
Suppress-If-Match: aba91
Expires: 3600
<-------- (2) 204
Expires: 3600
<-------- (2) 204
Expires: 3600
Figure 5: Refreshing a Subscription
图5：刷新订阅
(1) Before the subscription expires, the subscriber sends a SUBSCRIBE request that includes the Suppress-If-Match header field with the latest entity-tag it has seen.
(1) 在订阅过期之前，订阅服务器发送一个订阅请求，该请求包括具有其看到的最新实体标记的SUPPORSE If Match头字段。
(2) If the condition evaluates to true, the notifier sends a 204 (No Notification) response and sends no NOTIFY request. The Expires header field of the 204 (No Notification) response indicates the new expiry time.
(2) 如果条件评估为true，通知程序将发送204（无通知）响应，并且不发送通知请求。204（无通知）响应的Expires标头字段指示新的到期时间。
To terminate a subscription using conditional notification, the subscriber creates a SUBSCRIBE request with a Suppress-If-Match condition:
若要使用条件通知终止订阅，订阅者将创建一个订阅请求，其中包含“抑制如果匹配”条件：
Subscriber Notifier
---------- --------
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: ega23
Expires: 0
(1) SUBSCRIBE -------->
Suppress-If-Match: ega23
Expires: 0
<-------- (2) 204
<-------- (2) 204
Figure 6: Terminating a Subscription
图6：终止订阅
(1) The subscriber decides to terminate the subscription and sends a SUBSCRIBE request with the Suppress-If-Match condition with the entity-tag it has last seen.
(1) 订阅者决定终止订阅，并发送一个订阅请求，其中包含SUPPRES If Match条件和它最后看到的实体标记。
(2) If the condition evaluates to true, the notifier sends a 204 (No Notification) response, which concludes the subscription, and the subscriber can clear all state related to the subscription.
(2) 如果条件的计算结果为true，通知程序将发送204（无通知）响应，从而结束订阅，订阅方可以清除与订阅相关的所有状态。
This section is non-normative.
本节是非规范性的。
In some deployments, there may be Back-to-Back User Agent (B2BUA) devices that track SIP dialogs such as subscription dialogs. These devices may be unaware of the conditional notification mechanism.
在某些部署中，可能存在跟踪SIP对话框（如订阅对话框）的背对背用户代理（B2BUA）设备。这些设备可能不知道条件通知机制。
It is possible that some B2BUA devices may treat a NOTIFY with suppressed body as an error, or may expect all SUBSCRIBE messages to have an associated NOTIFY message.
一些B2BUA设备可能将具有抑制正文的通知视为错误，或者可能期望所有订阅消息具有关联的通知消息。
In general, there is very little that an endpoint can do to recover from such transient errors. The most that can be done is to try to detect such errors, and define a fallback behavior.
一般来说，端点几乎无法从此类瞬时错误中恢复。可以做的最多的就是尝试检测此类错误，并定义回退行为。
If subscribers encounter transient errors in conditional notification, they should disable the feature and fall back to normal subscription behavior.
如果订阅者在条件通知中遇到暂时性错误，他们应该禁用该功能并返回到正常的订阅行为。
This section augments the notifier behavior as specified in RFC 3265 [RFC3265].
本节扩充了RFC 3265[RFC3265]中指定的通知程序行为。
An entity-tag is a token carried in the SIP-ETag header field, and it is opaque to the client. The notifier is free to decide on any means for generating the entity-tag. It can have any value, except for "*". For example, one possible method is to implement the entity-tag as a simple counter, incrementing it by one for each generated notification per resource.
实体标记是SIP ETag头字段中携带的令牌，对客户端来说是不透明的。通知程序可以自由决定生成实体标记的任何方法。它可以有除“*”之外的任何值。例如，一种可能的方法是将实体标记实现为一个简单的计数器，为每个资源生成的每个通知增加一个。
A notifier MUST generate entity-tags for event notifications of all resources for which it is responsible. The entity-tag MUST be unique across all versions of all entities for each state of a resource as reported by a given event package. Otherwise said, for any subscription or sequence of subscriptions to a specific resource using a singular event package, each entity-tag produced MUST map to one and only one presentation of resource state (entity). Two identical entities for a specific resource might or might not have identical entity-tags; this decision is left to the notifier.
通知程序必须为其负责的所有资源的事件通知生成实体标记。对于给定事件包报告的资源的每个状态，实体标记在所有实体的所有版本中都必须是唯一的。否则，对于使用单个事件包的特定资源的任何订阅或订阅序列，生成的每个实体标记必须映射到资源状态（实体）的一个且仅一个表示形式。特定资源的两个相同实体可能有相同的实体标记，也可能没有相同的实体标记；这个决定留给通知者。
An entity-tag is considered valid for as long as the entity exists. An entity becomes stale when its version is no longer the current one. The notifier MUST remember (or be able to recalculate) the entity-tag of an entity as long as the version of the entity is current. The notifier MAY remember the entity-tag longer than this, e.g., for implementing journaled state differentials (Section 6.4).
只要实体存在，实体标记就被视为有效。当一个实体的版本不再是当前版本时，该实体就会过时。只要实体的版本是当前的，通知程序就必须记住（或能够重新计算）实体的实体标记。通知者可能记住实体标记的时间比这长，例如，为了实现日志状态差异（第6.4节）。
The entity-tag values used in publications are not necessarily shared with the entity-tag values used in subscriptions. This is because there may not always be a one-to-one mapping between a publication and a notification of state change; there may be several sources to the event composition process, and a publication into a resource may not affect the resulting entity.
发布中使用的实体标记值不一定与订阅中使用的实体标记值共享。这是因为在发布和状态更改通知之间可能并不总是存在一对一的映射；事件合成过程可能有多个源，发布到资源中可能不会影响结果实体。
When a condition in a SUBSCRIBE request for suppressing notifications is true (i.e., the local entity-tag for the resource state and the entity-tag in a Suppress-If-Match header field are byte-wise identical) but there are reportable changes in the NOTIFY header (e.g., the Subscription-State has changed), the notifier MUST suppress the body of the NOTIFY request. That is, the resulting NOTIFY contains no Content-Type header field, the Content-Length is set to zero, and no payload is attached to the message.
当订阅请求中抑制通知的条件为真时（即，资源状态的本地实体标记和抑制如果匹配头字段中的实体标记在字节上相同），但通知头中存在可报告的更改（例如，订阅状态已更改），通知程序必须抑制通知请求的正文。也就是说，结果NOTIFY不包含Content-Type头字段，内容长度设置为零，并且没有有效负载附加到消息。
Additionally, when a condition in a SUBSCRIBE request for suppressing notifications is true and the SUBSCRIBE message is not sent within an established dialog, the notifier MUST send a NOTIFY request with a suppressed entity body.
此外，当订阅请求中抑制通知的条件为true且订阅消息未在已建立的对话框中发送时，通知程序必须发送具有抑制实体正文的通知请求。
Suppressing the entity body of a NOTIFY does not change the current entity-tag of the resource. Hence, the NOTIFY MUST contain a SIP-ETag header field that contains the unchanged entity-tag of the resource state.
抑制NOTIFY的实体主体不会更改资源的当前实体标记。因此，NOTIFY必须包含SIP ETag头字段，该字段包含资源状态的未更改实体标记。
A Suppress-If-Match header field that includes an entity-tag with the value of "*" MUST always evaluate to true.
包含值为“*”的实体标记的抑制如果匹配标头字段的计算结果必须始终为true。
When a condition in a SUBSCRIBE request to suppress notifications is true (i.e., the local entity-tag of the resource and the entity-tag in a Suppress-If-Match header field match), and the SUBSCRIBE is sent within an established dialog, then the notifier MUST suppress the resulting NOTIFY request, and generate a 204 (No Notification) response. As long as the condition remains true, and there are no reportable changes in the NOTIFY header, all subsequent NOTIFY requests MUST also be suppressed.
当抑制通知的订阅请求中的条件为真（即，资源的本地实体标记和抑制If Match头字段Match中的实体标记），并且在已建立的对话框内发送订阅时，通知程序必须抑制生成的通知请求，并生成204（无通知）响应。只要条件保持为真，并且NOTIFY标头中没有可报告的更改，所有后续NOTIFY请求也必须被抑制。
Notifiers MUST NOT suppress a NOTIFY unless the corresponding SUBSCRIBE message was sent in an established dialog.
除非在已建立的对话框中发送了相应的订阅消息，否则通知程序不得禁止通知。
A successful conditional SUBSCRIBE request MUST extend the subscription expiry time.
成功的条件订阅请求必须延长订阅到期时间。
Suppressing the entire NOTIFY has no effect on the entity-tag of the resource. In other words, it remains unchanged.
抑制整个通知对资源的实体标记没有影响。换句话说，它保持不变。
A Suppress-If-Match header field that includes an entity-tag with the value of "*" MUST always evaluate to true.
包含值为“*”的实体标记的抑制如果匹配标头字段的计算结果必须始终为true。
Some event packages support a scheme where notifications contain state differentials, or state deltas [RFC3265], instead of complete resource state.
一些事件包支持一种方案，其中通知包含状态差异或状态增量[RFC3265]，而不是完整的资源状态。
Further extensions could define means for notifiers to keep track of the state changes of a resource, e.g., storing the changes in a journal. If a condition fails, the notifier would then send a state differential in the NOTIFY rather than the full state of the event resource. This is only possible if the event package and the subscriber both support a payload format that has this capability.
进一步的扩展可以定义通知程序跟踪资源状态更改的方法，例如，将更改存储在日志中。如果条件失败，通知程序将在通知中发送状态差异，而不是事件资源的完整状态。只有当事件包和订阅者都支持具有此功能的有效负载格式时，这才是可能的。
When state differentials are sent, the SIP-ETag header field MUST contain an entity-tag that corresponds to the full resource state.
发送状态差异时，SIP ETag头字段必须包含对应于完整资源状态的实体标记。
The Event Notification Extension for Resource Lists [RFC4662] defines a mechanism for subscribing to a homogeneous list of resources using the SIP events framework.
资源列表的事件通知扩展[RFC4662]定义了一种使用SIP事件框架订阅同类资源列表的机制。
A list subscription delivers event notifications that contain both Resource List Meta-Information (RLMI) documents as well as the resource state of the individual resources on the list.
列表订阅提供包含资源列表元信息（RLMI）文档以及列表上各个资源的资源状态的事件通知。
Implementations MUST consider the full resource state of a resource list including RLMI and the entity-header as the entity to which the entity-tag applies.
实现必须考虑资源列表的完整资源状态，包括RLMI和实体头作为实体标签应用的实体。
This section describes the protocol extensions required for conditional notification.
本节介绍条件通知所需的协议扩展。
The 204 (No Notification) response code indicates that the request was successful, but the notification associated with the request will not be sent. It is valid only in response to a SUBSCRIBE message sent within an established dialog.
204（无通知）响应代码表示请求成功，但不会发送与请求关联的通知。它仅在响应在已建立的对话框中发送的订阅消息时有效。
The response code is added to the "Success" production rule in the SIP [RFC3261] message grammar.
响应代码被添加到SIP[RFC3261]消息语法中的“成功”生成规则中。
The Suppress-If-Match header field is added to the definition of the "message-header" rule in the SIP [RFC3261] grammar. Its use is described in Sections 5, 6.3, and 6.2.
在SIP[RFC3261]语法中的“消息头”规则定义中添加了抑制如果匹配头字段。第5节、第6.3节和第6.2节对其使用进行了说明。
This header field is allowed to appear in any request, but its behavior is only defined for the SUBSCRIBE request.
此标头字段允许出现在任何请求中，但其行为仅为订阅请求定义。
This section defines the formal syntax for extensions described in this memo in Augmented BNF (ABNF) [RFC5234]. The rules defined here augment and reference the syntax defined in RFC 3261 [RFC3261] and RFC 3903 [RFC3903].
本节定义了增广BNF（ABNF）[RFC5234]中本备忘录所述扩展的形式语法。此处定义的规则扩充并引用了RFC 3261[RFC3261]和RFC 3903[RFC3903]中定义的语法。
Success =/ "204" ; No Notification
Success =/ "204" ; No Notification
; Success is defined in RFC 3261.
; RFC 3261中定义了成功。
message-header =/ Suppress-If-Match
消息头=/Suppress If Match
; message-header is defined in RFC 3261.
; 消息头在RFC 3261中定义。
Suppress-If-Match = "Suppress-If-Match" HCOLON ( entity-tag / "*" )
Suppress-If-Match = "Suppress-If-Match" HCOLON ( entity-tag / "*" )
; entity-tag is defined in RFC 3903.
; 实体标记在RFC 3903中定义。
This document registers a new response code and a new header field name.
此文档注册一个新的响应代码和一个新的标题字段名。
This document registers a new response code. This response code is defined by the following information, which has been added to the methods and response-codes sub-registry available from http://www.iana.org.
此文档注册了一个新的响应代码。此响应代码由以下信息定义，这些信息已添加到方法和响应代码子注册表中，可从http://www.iana.org.
This information has been added under "Successful 2xx" category.
此信息已添加到“成功2xx”类别下。
+---------------------+-----------+
| Response Code | Reference |
+---------------------+-----------+
| 204 No Notification | [RFC5839] |
+---------------------+-----------+
+---------------------+-----------+
| Response Code | Reference |
+---------------------+-----------+
| 204 No Notification | [RFC5839] |
+---------------------+-----------+
This document registers a new SIP header field called Suppress-If-Match. This header field is defined by the following information, which has been added to the header fields sub-registry available from http://www.iana.org.
此文档注册了一个名为Suppress If Match的新SIP头字段。此标题字段由以下信息定义，这些信息已添加到标题字段子注册表中，可从http://www.iana.org.
+-------------------+---------+-----------+
| Header Name | Compact | Reference |
+-------------------+---------+-----------+
| Suppress-If-Match | | [RFC5839] |
+-------------------+---------+-----------+
+-------------------+---------+-----------+
| Header Name | Compact | Reference |
+-------------------+---------+-----------+
| Suppress-If-Match | | [RFC5839] |
+-------------------+---------+-----------+
The security considerations for SIP event notification are extensively discussed in RFC 3265 [RFC3265]. This specification introduces an optimization to SIP event notification, which in itself does not alter the security properties of the protocol.
RFC 3265[RFC3265]中广泛讨论了SIP事件通知的安全注意事项。本规范引入了对SIP事件通知的优化，其本身不会改变协议的安全属性。
The following people have contributed corrections and suggestions to this document: Adam Roach, Sean Olson, Johnny Vrancken, Pekka Pessi, Eva Leppanen, Krisztian Kiss, Peili Xu, Avshalom Houri, David Viamonte, Jonathan Rosenberg, Qian Sun, Dale Worley, Tolga Asveren, Brian Stucker, Eric Rescorla, Arun Arunachalam, and the SIP and SIMPLE working groups.
以下人士对本文件提出了更正和建议：亚当·罗奇、肖恩·奥尔森、约翰尼·范兰肯、佩卡·佩西、伊娃·莱普潘、克里斯汀·基斯、佩利·徐、阿夫沙洛姆·霍里、大卫·维亚蒙特、乔纳森·罗森博格、钱孙、戴尔·沃利、托尔加·阿斯维伦、布赖恩·斯图克、埃里克·雷索拉、阿伦·阿鲁纳查拉姆、，以及SIP和简单工作组。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] 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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903]Niemi，A.，“事件状态发布的会话启动协议（SIP）扩展”，RFC 3903，2004年10月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月。
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[RFC3680]Rosenberg，J.，“用于注册的会话启动协议（SIP）事件包”，RFC3680，2004年3月。
[RFC3842] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
[RFC3842]Mahy，R.“会话启动协议（SIP）的消息摘要和消息等待指示事件包”，RFC 3842，2004年8月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856]Rosenberg，J.，“会话启动协议（SIP）的存在事件包”，RFC3856，2004年8月。
[RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[RFC3859]彼得森，J.，“存在的共同特征（CPP）”，RFC3859，2004年8月。
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
[RFC4662]Roach，A.，Campbell，B.，和J.Rosenberg，“资源列表的会话启动协议（SIP）事件通知扩展”，RFC 4662，2006年8月。
Authors' Addresses
作者地址
Aki Niemi Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland
芬兰芬兰芬兰诺基亚集团Aki Niemi诺基亚邮政信箱407
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Dean Willis (editor) Softarmor Systems 3100 Independence Pkwy #311-164 Plano, TX 75075 USA
迪安·威利斯（编辑）Softarmor Systems 3100 Independence Pkwy#311-164美国德克萨斯州普莱诺市75075
Phone: +1 214 504 1987
EMail: dean.willis@softarmor.com
Phone: +1 214 504 1987
EMail: dean.willis@softarmor.com