draft-ietf-sipcore-subnot-etags-04.txt   rfc5839.txt 
Session Initiation Protocol A. Niemi Internet Engineering Task Force (IETF) A. Niemi
Working Group Nokia Request for Comments: 5839 Nokia
Internet-Draft D. Willis, Ed. Category: Standards Track D. Willis, Ed.
Intended status: Standards Track Softarmor Systems ISSN: 2070-1721 Softarmor Systems
Expires: July 19, 2010 January 15, 2010 May 2010
An Extension to Session Initiation Protocol (SIP) Events for Conditional An Extension to Session Initiation Protocol (SIP) Events
Event Notification for Conditional Event Notification
draft-ietf-sipcore-subnot-etags-04
Abstract Abstract
The Session Initiation Protocol (SIP) events framework enables The Session Initiation Protocol (SIP) events framework enables
receiving asynchronous notification of various events from other SIP receiving asynchronous notification of various events from other SIP
user agents. This framework defines the procedures for creating, user agents. This framework defines the procedures for creating,
refreshing and terminating subscriptions, as well as fetching and refreshing, and terminating subscriptions, as well as fetching and
periodic polling of resource state. These procedures provide no periodic polling of resource state. These procedures provide no
tools to avoid replaying event notifications that have already been tools to avoid replaying event notifications that have already been
received by a user agent. This memo defines an extension to SIP received by a user agent. This memo defines an extension to SIP
events that allows the subscriber to condition the subscription events that allows the subscriber to condition the subscription
request to whether the state has changed since the previous request to whether the state has changed since the previous
notification was received. When such a condition is true, either the notification was received. When such a condition is true, either the
body of a resulting event notification or the entire notification body of a resulting event notification or the entire notification
message is suppressed. message is suppressed.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (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.
This Internet-Draft will expire on July 19, 2010. 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.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 3, line 25 skipping to change at page 3, line 25
4. Resource Model for Entity-Tags . . . . . . . . . . . . . . . . 10 4. Resource Model for Entity-Tags . . . . . . . . . . . . . . . . 10
5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 12 5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 12
5.1. Detecting Support for Conditional Notification . . . . . . 13 5.1. Detecting Support for Conditional Notification . . . . . . 13
5.2. Generating SUBSCRIBE Requests . . . . . . . . . . . . . . 13 5.2. Generating SUBSCRIBE Requests . . . . . . . . . . . . . . 13
5.3. Receiving NOTIFY Requests . . . . . . . . . . . . . . . . 14 5.3. Receiving NOTIFY Requests . . . . . . . . . . . . . . . . 14
5.4. Polling or Fetching Resource State . . . . . . . . . . . . 15 5.4. Polling or Fetching Resource State . . . . . . . . . . . . 15
5.5. Resuming a Subscription . . . . . . . . . . . . . . . . . 17 5.5. Resuming a Subscription . . . . . . . . . . . . . . . . . 17
5.6. Refreshing a Subscription . . . . . . . . . . . . . . . . 18 5.6. Refreshing a Subscription . . . . . . . . . . . . . . . . 18
5.7. Terminating a Subscription . . . . . . . . . . . . . . . . 18 5.7. Terminating a Subscription . . . . . . . . . . . . . . . . 18
5.8. Handling Transient Errors . . . . . . . . . . . . . . . . 19 5.8. Handling Transient Errors . . . . . . . . . . . . . . . . 19
6. Notifier Behavior . . . . . . . . . . . . . . . . . . . . . . 19 6. Notifier Behavior . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Generating Entity-tags . . . . . . . . . . . . . . . . . . 20 6.1. Generating Entity-tags . . . . . . . . . . . . . . . . . . 20
6.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 20 6.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 20
6.3. Suppressing NOTIFY Requests . . . . . . . . . . . . . . . 21 6.3. Suppressing NOTIFY Requests . . . . . . . . . . . . . . . 21
6.4. State Differentials . . . . . . . . . . . . . . . . . . . 21 6.4. State Differentials . . . . . . . . . . . . . . . . . . . 21
6.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 22 6.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 22
7. Protocol Element Definitions . . . . . . . . . . . . . . . . . 22 7. Protocol Element Definitions . . . . . . . . . . . . . . . . . 22
7.1. 204 (No Notification) Response Code . . . . . . . . . . . 22 7.1. 204 (No Notification) Response Code . . . . . . . . . . . 22
7.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 22 7.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 22
7.3. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.3. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8.1. 204 (No Notification) Response Code . . . . . . . . . . . 23 8.1. 204 (No Notification) Response Code . . . . . . . . . . . 23
8.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 23 8.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) events framework provides an The Session Initiation Protocol (SIP) events framework provides an
extensible facility for requesting notification of certain events extensible facility for requesting notification of certain events
from other SIP user agents. This framework includes procedures for from other SIP user agents. This framework includes procedures for
creating, refreshing and terminating of subscriptions, as well as the creating, refreshing, and terminating subscriptions, as well as the
possibility to fetch or periodically poll the event resource. possibility to fetch or periodically poll the event resource.
Several instantiations of this framework, called event packages have Several instantiations of this framework, called event packages have
been defined, e.g., for presence [RFC3856], message waiting been defined, e.g., for presence [RFC3856], message waiting
indications [RFC3842] and registrations [RFC3680]. indications [RFC3842], and registrations [RFC3680].
By default, every SUBSCRIBE request generates a NOTIFY request By default, every SUBSCRIBE request generates a NOTIFY request
containing the latest event state. Typically, a SUBSCRIBE request is containing the latest event state. Typically, a SUBSCRIBE request is
issued by the subscriber whenever it needs a subscription to be issued by the subscriber whenever it needs a subscription to be
installed, periodically refreshed or terminated. Once the installed, periodically refreshed, or terminated. Once the
subscription has been installed, the majority of the NOTIFYs subscription has been installed, the majority of the NOTIFYs
generated by the subscription refreshes are superfluous; the generated by the subscription refreshes are superfluous; the
subscriber usually is in possession of the event state already, subscriber usually is in possession of the event state already,
except in the unlikely case where a state change exactly coincides except in the unlikely case where a state change exactly coincides
with the periodic subscription refresh. In most cases, the final with the periodic subscription refresh. In most cases, the final
event state generated upon terminating the subscription similarly event state generated upon terminating the subscription similarly
contains resource state that the subscriber already has. contains resource state that the subscriber already has.
Fetching or polling of resource state behaves in a similarly Fetching or polling of resource state behaves in a similarly
suboptimal way in cases where the state has not changed since the suboptimal way in cases where the state has not changed since the
previous poll occurred. In general, the problem lies in with the previous poll occurred. In general, the problem lies with the
inability to persist state across a SUBSCRIBE request. inability to persist state across a SUBSCRIBE request.
This memo defines an extension to optimize the SIP events framework. This memo defines an extension to optimize the SIP events framework.
This extension allows a notifier to tag notifications (called entity- This extension allows a notifier to tag notifications (called entity-
tags hereafter), and the subscriber to condition its subsequent tags hereafter) and the subscriber to condition its subsequent
SUBSCRIBE requests for actual changes since a notification carrying SUBSCRIBE requests for actual changes since a notification carrying
that entity-tag was issued. The solution is similar to conditional that entity-tag was issued. The solution is similar to conditional
requests defined in the Hypertext Transfer Protocol (HTTP) [RFC2616], requests defined in the Hypertext Transfer Protocol (HTTP) [RFC2616],
and follows the mechanism already defined for the PUBLISH [RFC3903] and follows the mechanism already defined for the PUBLISH [RFC3903]
method for issuing conditional event publications. method for issuing conditional event publications.
This memo is structured as follows. Section 2 explains the This memo is structured as follows. Section 2 explains the
background, motivations and requirements for the work; Section 3 background, motivations, and requirements for the work; Section 3
gives a general overview of the mechanism; Section 4 explains the gives a general overview of the mechanism; Section 4 explains the
underlying model for resources and entities as they apply to underlying model for resources and entities as they apply to
conditional notification; Section 5 defines the subscriber behavior; conditional notification; Section 5 defines the subscriber behavior;
Section 6 defines the notifier behavior; Section 7 includes the Section 6 defines the notifier behavior; Section 7 includes the
protocol element definitions; Section 8 includes the IANA protocol element definitions; Section 8 includes the IANA
considerations; and Section 9 includes the security considerations. considerations; and Section 9 includes the security considerations.
1.1. Document Conventions 1.1. Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant [RFC2119] and indicate requirement levels for compliant
implementations. implementations.
1.2. Terminology 1.2. Terminology
In addition to the terminology introduced in [RFC3261], [RFC3265] and In addition to the terminology introduced in [RFC3261], [RFC3265],
[RFC3903], this specification uses these additional terms to describe and [RFC3903], this specification uses these additional terms to
the objects of conditional notification: describe the objects of conditional notification:
resource resource
An object identified by a URI, whose resource state can be An object identified by a URI whose resource state can be accessed
accessed using the SIP Event Notification framework. There is a using the SIP Event Notification framework. There is a single
single authoritative notifier responsible for communicating the authoritative notifier responsible for communicating the resource
resource state. state.
entity entity
The representation of resource state. An entity consists of the The representation of resource state. An entity consists of the
state data carried in the body of a NOTIFY message, as well as state data carried in the body of a NOTIFY message, as well as
related meta-data in the message header. There may be many related meta-data in the message header. There may be many
versions of an entity, one current and the others stale. Each versions of an entity, one current and the others stale. Each
version of an entity is identified by an entity-tag, which is version of an entity is identified by an entity-tag, which is
guaranteed to be unique across all versions of all entities for a guaranteed to be unique across all versions of all entities for a
resource and event package. resource and event package.
skipping to change at page 5, line 49 skipping to change at page 5, line 49
This lifetime is negotiated using the Expires header field, and This lifetime is negotiated using the Expires header field, and
unless the subscription is refreshed by the subscriber before the unless the subscription is refreshed by the subscriber before the
expiration is met, the subscription is terminated. The frequency of expiration is met, the subscription is terminated. The frequency of
these subscription refreshes depends on the event package, and these subscription refreshes depends on the event package, and
typically ranges from minutes to hours. typically ranges from minutes to hours.
2.2. Problem Description 2.2. Problem Description
The SIP events framework does not include different protocol methods The SIP events framework does not include different protocol methods
for initiating and terminating of subscriptions, subscription for initiating and terminating of subscriptions, subscription
refreshes and fetches inside and outside of the SIP dialog. The refreshes, and fetches inside and outside of the SIP dialog. The
SUBSCRIBE method is overloaded to perform all of these functions The SUBSCRIBE method is overloaded to perform all of these functions.
difference between a fetch that does not create a (lasting) The difference between a fetch that does not create a (lasting)
subscription, and a SUBSCRIBE that creates one is in the Expires subscription and a SUBSCRIBE that creates one is in the Expires
header field value of the SUBSCRIBE; a zero-expiry SUBSCRIBE only header field value of the SUBSCRIBE; a zero-expiry SUBSCRIBE only
generates a single NOTIFY, after which the subscription immediately generates a single NOTIFY, after which the subscription immediately
terminates. Lasting subscriptions typically have relatively short terminates. Lasting subscriptions typically have relatively short
expiry periods, requiring periodic sending of new SUBSCRIBE requests expiry periods, requiring periodic sending of new SUBSCRIBE requests
in order to refresh the subscription. in order to refresh the subscription.
Each new SUBSCRIBE request generates a NOTIFY request containing the Each new SUBSCRIBE request generates a NOTIFY request containing the
latest resource state. Even if the state has not changed, it is sent 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 again in response to each poll or subscription refresh. This is very
similar to the HTTP [RFC2616] problem of repeated GET operations on a similar to the HTTP [RFC2616] problem of repeated GET operations on a
resource. HTTP solves the problem using conditional requests. The resource. HTTP solves the problem using conditional requests. The
server versions each entity with an entity tag that identifies a server versions each entity with an entity-tag that identifies a
specific instance of that entity. Clients making GET requests can specific instance of that entity. Clients making GET requests can
then include the entity tag for the version of the entity that they then include the entity-tag for the version of the entity that they
currently to be current in an "If-None-Match" header field, and the believe to be current in an "If-None-Match" header field. The server
server can compare this entity tag to the entity it believes to be can compare this entity-tag to the entity it believes to be current
current and suppress resending the entity in the response if the and suppress resending the entity in the response if the server
server believes the client's version matches. In other words, the believes the client's version matches. In other words, the server
server doesn't re-send information that the client has already doesn't resend information that the client has already received.
received.
The SIP PUBLISH [RFC3903] method uses a similar mechanism, where a The SIP PUBLISH [RFC3903] method uses a similar mechanism, where a
refresh of a publication is done by reference to its assigned entity- refresh of a publication is done by reference to its assigned entity-
tag, instead of retransmitting the event state each time the tag, instead of retransmitting the event state each time the
publication expiration is extended. publication expiration is extended.
2.3. Requirements 2.3. Requirements
As a summary, here is the required functionality to solve the As a summary, here is the required functionality to solve the
presented issues: presented issues:
REQ1: It must be possible to suppress the NOTIFY request (or at a REQ1: It must be possible to suppress the NOTIFY request (or at a
minimum the event body therein) if the subscriber is already minimum, the event body therein) if the subscriber is already
in possession of (or has previously received and discarded) in possession of (or has previously received and discarded)
the latest event state of the resource. the latest event state of the resource.
REQ2: This mechanism must apply to initial subscriptions, in which REQ2: This mechanism must apply to initial subscriptions in which
the subscriber is attempting to resume an earlier the subscriber is attempting to resume an earlier
subscription that has been paused. subscription that has been paused.
REQ3: This mechanism must apply to refreshing a subscription. REQ3: This mechanism must apply to refreshing a subscription.
REQ4: This mechanism must apply to terminating a subscription REQ4: This mechanism must apply to terminating a subscription
(i.e., an unsubscribe). (i.e., an unsubscribe).
REQ5: This mechanism must apply to fetching or polling of resource REQ5: This mechanism must apply to fetching or polling of resource
state. state.
3. Overview of Operation 3. Overview of Operation
Whenever a subscriber initiates a subscription, it issues a SUBSCRIBE Whenever a subscriber initiates a subscription, it issues a SUBSCRIBE
request. The SUBSCRIBE request is sent, routed and processed by the request. The SUBSCRIBE request is sent, routed, and processed by the
notifier normally, i.e., according to The Session Initiation Protocol notifier normally, i.e., according to the Session Initiation Protocol
[RFC3261], and SIP Specific Event Notification [RFC3265]. [RFC3261] and SIP-Specific Event Notification [RFC3265].
If the notifier receiving the SUBSCRIBE request supports conditional If the notifier receiving the SUBSCRIBE request supports conditional
subscriptions, it generates an entity tag for the current entity, and subscriptions, it generates an entity-tag for the current entity, and
includes it in a SIP-ETag header field of the NOTIFY request. The 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 entity-tag is unique across all versions of all entities for a
resource and event package. More on this in Section 4. resource and event package. See Section 4 for more on this.
Entity-tags are independent of subscriptions. This allows Entity-tags are independent of subscriptions. This allows
notifications generated to a fetch or a poll to have valid entity- notifications generated to a fetch or a poll to have valid entity-
tags even across subsequent fetches or polls. tags even across subsequent fetches or polls.
The subscriber will store the entity-tag received in the notification The subscriber will store the entity-tag received in the notification
along with the resource state. It can then later use this entity-tag 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- 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 If-Match" header field. Unlike the "If-Match" condition in a PUBLISH
[RFC3903] request, which applies to whether the PUBLISH succeeds or [RFC3903] request, which applies to whether the PUBLISH succeeds or
returns an error, this condition applies to the stream of returns an error, this condition applies to the stream of
notifications that are sent after the SUBSCRIBE request has been notifications that are sent after the SUBSCRIBE request has been
processed. processed.
The "Suppress-If-Match" header field contains the last entity-tag The Suppress-If-Match header field contains the last entity-tag seen
seen by the subscriber. This condition, if true, instructs the by the subscriber. This condition, if true, instructs the notifier
notifier to suppress either the body of a subsequent notification, or to suppress either the body of a subsequent notification, or the
the entire notification. entire notification.
The condition is evaluated by matching the value of the header field 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 against the entity-tag of the entity that would normally be sent in
the associated NOTIFY message. There is also a wildcard entity-tag the associated NOTIFY message. There is also a wildcard entity-tag
with a special value of "*" that always matches. with a special value of "*" that always matches.
Subscriber Notifier Subscriber Notifier
---------- -------- ---------- --------
(1) SUBSCRIBE --------> (1) SUBSCRIBE -------->
skipping to change at page 8, line 47 skipping to change at page 8, line 47
Expires: 0 | local Expires: 0 | local
| entity-tag | entity-tag
| |
<-------- (10) 204 / then <-------- (10) 204 / then
Figure 1: Example Message Flow Figure 1: Example Message Flow
Figure 1 describes a typical message flow for conditional Figure 1 describes a typical message flow for conditional
notification: notification:
1. The subscriber initiates a subscription by sending a SUBSCRIBE (1) The subscriber initiates a subscription by sending a SUBSCRIBE
request for a resource. request for a resource.
2. After proper authentication and authorization, the notifier (2) After proper authentication and authorization, the notifier
accepts the subscription. accepts the subscription.
3. The notifier then immediately sends the initial event (3) The notifier then immediately sends the initial event
notification, including a unique entity-tag in a SIP-ETag header notification, including a unique entity-tag in a SIP-ETag
field. header field.
4. The subscriber accepts the notification and stores the entity- (4) The subscriber accepts the notification and stores the entity-
tag value along with the resource state. tag value along with the resource state.
5. Later, the subscriber refreshes the subscription, and includes (5) Later, the subscriber refreshes the subscription, and includes
an entity-tag in a Suppress-If-Match header field. an entity-tag in a Suppress-If-Match header field.
6. The notifier evaluates the condition by matching its local (6) The notifier evaluates the condition by matching its local
entity-tag value for the resource against the value of the entity-tag value for the resource against the value of the
Suppress-If-Match header field. If the condition evaluates to Suppress-If-Match header field. If the condition evaluates to
true, the notifier informs the subscriber that the notification true, the notifier informs the subscriber that the notification
will not be sent. will not be sent.
7. At some point, the state of the resource changes, e.g., the (7) At some point, the state of the resource changes, e.g., the
presence status of a user changes from online to busy. This presence status of a user changes from online to busy. This
triggers an event notification with a new value in the SIP-ETag triggers an event notification with a new value in the SIP-ETag
header field. header field.
8. The subscriber accepts the notification and stores the new (8) The subscriber accepts the notification and stores the new
entity-tag along with the resource state. entity-tag along with the resource state.
9. After a while, the subscriber decides to terminate the (9) After a while, the subscriber decides to terminate the
subscription. It adds a condition for Suppress-If-Match, and subscription. It adds a condition for Suppress-If-Match, and
includes the entity-tag it received in the previous NOTIFY. includes the entity-tag it received in the previous NOTIFY.
10. The notifier evaluates the condition by matching its entity-tag (10) The notifier evaluates the condition by matching its entity-tag
for the resource against the value of the Suppress-If-Match for the resource against the value of the Suppress-If-Match
header field. If the condition evaluates to true, the notifier header field. If the condition evaluates to true, the notifier
informs the subscriber that no notification will be sent. This informs the subscriber that no notification will be sent. This
concludes the subscription. concludes the subscription.
The benefit of using conditional notification in this example is in The benefit of using conditional notification in this example is in
the reduction of the number of NOTIFY requests the subscriber can the reduction of the number of NOTIFY requests the subscriber can
expect to receive. Each event notification that the subscriber has expect to receive. Each event notification that the subscriber has
already seen is suppressed by the notifier. This example illustrates already seen is suppressed by the notifier. This example illustrates
only one use case for the mechanism; the same principles can be used only one use case for the mechanism; the same principles can be used
to optimize the flow of messages related to other event notification to optimize the flow of messages related to other event notification
use cases. use cases.
4. Resource Model for Entity-Tags 4. Resource Model for Entity-Tags
skipping to change at page 10, line 45 skipping to change at page 10, line 45
| | Presence | | Conference | | Template | | | Presence | | Conference | | Template |
| | | | | | | | | | | | | |
|1..* +----------+ +------------+ +----.-----+ |1..* +----------+ +------------+ +----.-----+
+---------+ /_\ +---------+ /_\
| | | | | |
| Version | | | Version | |
| | +---------+ | | +---------+
+---------+ | Watcher | +---------+ | Watcher |
|1 | Info | |1 | Info |
| | | | | |
| +---------+ V +---------+
V
+---------+ +---------+
| Entity- | | Entity- |
| Tag | | Tag |
| | | |
+---------+ +---------+
Figure 2: Resource Model Diagram Figure 2: Resource Model Diagram
For a given event package, there is a single authoritative agent For a given event package, there is a single authoritative agent
responsible for zero or more resources. That is, even for a responsible for zero or more resources. That is, even for a
distributed agent, the resource state is uniform across all distributed agent, the resource state is uniform across all
instances. The resource itself can be a list of resources [RFC4662]. instances. The resource itself can be a list of resources [RFC4662].
Conditional notification for list subscriptions is addressed in Conditional notification for list subscriptions is addressed in
Section 6.5. Section 6.5.
A resource is identified by zero or more URIs, which can be SIP URIs, A resource is identified by zero or more URIs, which can be SIP URIs,
skipping to change at page 11, line 14 skipping to change at page 11, line 13
Figure 2: Resource Model Diagram Figure 2: Resource Model Diagram
For a given event package, there is a single authoritative agent For a given event package, there is a single authoritative agent
responsible for zero or more resources. That is, even for a responsible for zero or more resources. That is, even for a
distributed agent, the resource state is uniform across all distributed agent, the resource state is uniform across all
instances. The resource itself can be a list of resources [RFC4662]. instances. The resource itself can be a list of resources [RFC4662].
Conditional notification for list subscriptions is addressed in Conditional notification for list subscriptions is addressed in
Section 6.5. Section 6.5.
A resource is identified by zero or more URIs, which can be SIP URIs, A resource is identified by zero or more URIs, which can be SIP URIs,
pres URIs [RFC3859] or similar. Subscribers use this URI to pres URIs [RFC3859], or similar. Subscribers use this URI to
subscribe to the resource for certain types of events, identified by subscribe to the resource for certain types of events, identified by
the event package. the event package.
With a successful subscription, a subscriber receives event With a successful subscription, a subscriber receives event
notifications that communicate the resource state and the changes notifications that communicate the resource state and the changes
thereto. Each event notification carries a representation of the thereto. Each event notification carries a representation of the
current resource state. This representation is influenced by many current resource state. This representation is influenced by many
factors, e.g., authorization and filtering rules, and the event factors, e.g., authorization and filtering rules, and the event
composition rules of the notifier. composition rules of the notifier.
skipping to change at page 11, line 37 skipping to change at page 11, line 36
multiple subscribers to the presence information of a single user (a multiple subscribers to the presence information of a single user (a
resource), and each subscriber may have a different filtered view of resource), and each subscriber may have a different filtered view of
that resource, producing one entity per subscriber. However, each that resource, producing one entity per subscriber. However, each
entity is associated with one and only one resource; there is no entity is associated with one and only one resource; there is no
"compositing" of resources at the entity level. Resources may "compositing" of resources at the entity level. Resources may
themselves be made up of information from other resources (be themselves be made up of information from other resources (be
"composite resources"), but this does not change the one-resource- "composite resources"), but this does not change the one-resource-
per-entity rule. per-entity rule.
An entity consists of the data carried in the body of a NOTIFY An entity consists of the data carried in the body of a NOTIFY
message, and related meta-data in the message header. Whenever the 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 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 produce a new entity-tag. This meta-data MUST include, but is not
limited to the following SIP header fields defined in The Session limited to the following SIP header fields defined in the Session
Initiation Protocol [RFC3261] and SIP Specific Event Notification Initiation Protocol [RFC3261] and SIP Specific Event Notification
[RFC3265]: [RFC3265]:
1. Content-Disposition 1. Content-Disposition
2. Content-Encoding 2. Content-Encoding
3. Content-Language 3. Content-Language
4. Content-Length 4. Content-Length
5. Content-Type
6. Event 5. Content-Type
6. Event
Note that the Subscription-State is explicitly not part of the Note that the Subscription-State is explicitly not part of the
entity. Event packages may in the future define additional fields entity. In the future, event packages may define additional fields
that implementations need to consider as part of the entity. that implementations need to consider as part of the entity.
An entity has one or more versions of which only one is current and 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 all others stale. Each version has an entity-tag, which uniquely
identifies it across all versions of all entities pertaining to a identifies it across all versions of all entities pertaining to a
single resource and event package. single resource and event package.
Note that two entity-tags for different resources being equal does Note that two entity-tags for different resources being equal does
not indicate identical entities. In other words, if an entity-tag 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 first resource matches an entity-tag
skipping to change at page 12, line 39 skipping to change at page 12, line 37
The conditional notification mechanism is independent of the way in The conditional notification mechanism is independent of the way in
which subscriptions are installed. In other words, the mechanism which subscriptions are installed. In other words, the mechanism
supports implicit subscriptions, such as those associated with the supports implicit subscriptions, such as those associated with the
REFER method [RFC3515]. REFER method [RFC3515].
It is possible that the same resource is in some shape or form It is possible that the same resource is in some shape or form
accessible through another mechanism in addition to SIP Event accessible through another mechanism in addition to SIP Event
Notification, e.g., HTTP or the SIP PUBLISH method. In general, Notification, e.g., HTTP or the SIP PUBLISH method. In general,
implementations MUST NOT expect the entity-tags to be shared between implementations MUST NOT expect the entity-tags to be shared between
the mechanisms, unless event packages or specific applications of SIP the mechanisms, unless event packages or specific applications of SIP
Events explicitly define such dependencies. events explicitly define such dependencies.
5. Subscriber Behavior 5. Subscriber Behavior
This section augments the subscriber behavior defined in RFC3265 This section augments the subscriber behavior defined in RFC 3265
[RFC3265]. It first discusses general issues related to indicating [RFC3265]. It first discusses general issues related to indicating
support for the mechanism (Section 5.1) and creating conditions in support for the mechanism (Section 5.1) and creating conditions in
SUBSCRIBE requests (Section 5.2); it then describes the workflows for SUBSCRIBE requests (Section 5.2). Next, it describes subscriber
the main three use cases for making the subscription conditional. 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).
5.1. Detecting Support for Conditional Notification 5.1. Detecting Support for Conditional Notification
The mechanism defined in this memo is backwards compatible with SIP The mechanism defined in this memo is backwards compatible with SIP
events [RFC3265] in that a notifier supporting this mechanism will events [RFC3265] in that a notifier supporting this mechanism will
insert a SIP entity-tag in its NOTIFY requests, and a subscriber that 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 understands this mechanism will know how to use it in creating a
conditional request. conditional request.
Unaware subscribers will simply ignore the entity-tag, make requests Unaware subscribers will simply ignore the entity-tag, make requests
without conditions and receive the default treatment from the without conditions, and receive the default treatment from the
notifier. Unaware notifiers will simply ignore the conditional notifier. Unaware notifiers will simply ignore the conditional
header fields, and continue normal operation. header fields and continue normal operation.
5.2. Generating SUBSCRIBE Requests 5.2. Generating SUBSCRIBE Requests
When creating a conditional SUBSCRIBE request, the subscriber MUST When creating a conditional SUBSCRIBE request, the subscriber MUST
include a single conditional header field including an entity-tag in include a single conditional header field including an entity-tag in
the request. The condition is evaluated by comparing the entity-tag the request. The condition is evaluated by comparing the entity-tag
of the subscribed resource with the entity-tag carried in the of the subscribed resource with the entity-tag carried in the
conditional header field. If they match, the condition evaluates to conditional header field. If they match, the condition evaluates to
true. true.
Unlike the condition introduced for the SIP PUBLISH [RFC3903] method, Unlike the condition introduced for the SIP PUBLISH [RFC3903] method,
these conditions do not apply to the SUBSCRIBE request itself, but to these conditions do not apply to the SUBSCRIBE request itself, but to
the resulting NOTIFY requests. When true, the condition drives the the resulting NOTIFY requests. When true, the condition drives the
notifier to change its behavior with regards to sending the notifier to change its behavior with regard to sending the
notifications after the SUBSCRIBE. notifications after the SUBSCRIBE.
This specification defines a new header field called "Suppress-If- This specification defines a new header field called Suppress-If-
Match". This header field introduces a condition to the SUBSCRIBE Match. This header field introduces a condition to the SUBSCRIBE
request. If true, it instructs the notifier to either omit the body request. If true, it instructs the notifier either to omit the body
of the resulting NOTIFY message (if the SUBSCRIBE is not sent within of the resulting NOTIFY message (if the SUBSCRIBE is not sent within
an existing dialog), or suppress (i.e., block) the NOTIFY request an existing dialog) or to suppress (i.e., block) the NOTIFY request
that would otherwise be triggered the SUBSCRIBE (for an established that would otherwise be triggered by the SUBSCRIBE (for an
dialog). In the latter case, the SUBSCRIBE message will be answered established dialog). In the latter case, the SUBSCRIBE message will
with a 204 (No Notification) response. As long as the condition be answered with a 204 (No Notification) response. As long as the
remains true, it also instructs the notifier to either suppress any condition remains true, it also instructs the notifier either to
subsequent NOTIFY request, or if there are reportable changes in the suppress any subsequent NOTIFY request or, if there are reportable
NOTIFY header, e.g., the Subscription-State has changed, suppress the changes in the NOTIFY header, e.g., the Subscription-State has
body of any subsequent NOTIFY request. changed, to suppress the body of any subsequent NOTIFY request.
If the condition is false, the notifier follows its default If the condition is false, the notifier follows its default behavior.
behaviour.
If the subscriber receives a 204 (No Notification) to an in-dialog If the subscriber receives a 204 (No Notification) response to an in-
SUBSCRIBE, the subscriber can clear handle that it may have had dialog SUBSCRIBE, the subscriber MUST consider the event state and
pending on a NOTIFY in response the SUBSCRIBE message. the subscription state unchanged.
The value of the "Suppress-If-Match" header field is an entity-tag, The value of the Suppress-If-Match header field is an entity-tag,
which is an opaque token that the subscriber simply copies (bytewise) which is an opaque token that the subscriber simply copies (byte-
from a previously received NOTIFY request. Inclusion of an entity- wise) from a previously received NOTIFY request. Inclusion of an
tag in a "Suppress-If-Match" header field of a SUBSCRIBE request entity-tag in a Suppress-If-Match header field of a SUBSCRIBE request
indicates that the client either has a copy of, or is capable of re- indicates that the client has a copy of, or is capable of recreating
creating a copy of, the entity associated with that entity-tag. a copy of, the entity associated with that entity-tag.
Example: Example:
Suppress-If-Match: b4cf7 Suppress-If-Match: b4cf7
The header field can also be wildcarded using the special "*" entity- The header field can also be wildcarded using the special "*" entity-
tag value. Such a condition always evaluates to true regardless of tag value. Such a condition always evaluates to true regardless of
the value of the current entity-tag for the resource. the value of the current entity-tag for the resource.
Example: Example:
Suppress-If-Match: * Suppress-If-Match: *
Such a wildcard condition effectively quenches a subscription; the Such a wildcard condition effectively quenches a subscription; the
only notifications received are those reporting changes to the only notifications received are those reporting changes to the
subscription state and those in response to a SUBSCRIBE message sent subscription state and those in response to a SUBSCRIBE message sent
outside of an existing dialog. In both cases, the notifications will outside of an existing dialog. In both cases, the notifications will
not contain a body. not contain a body.
A subscription with a wildcard "Suppress-If-Match" condition is A subscription with a wildcard Suppress-If-Match condition is
useful in scenarios where the subscriber wants to temporarily put useful in scenarios where the subscriber wants to temporarily put
a subscription in dormant mode. For example, a host may want to a subscription in dormant mode. For example, a host may want to
conserve bandwidth and power when it detects from screen or input conserve bandwidth and power when it detects from screen or input
device inactivity that the user isn't actively monitoring the device inactivity that the user isn't actively monitoring the
presence statuses of contacts. presence statuses of contacts.
5.3. Receiving NOTIFY Requests 5.3. Receiving NOTIFY Requests
When a subscriber receives a NOTIFY request that contains a SIP-ETag 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 header field, it MUST store the entity-tag if it wishes to make use
skipping to change at page 15, line 10 skipping to change at page 15, line 10
entity-tag; specifically, the subscriber MUST NOT assume identical entity-tag; specifically, the subscriber MUST NOT assume identical
entities (i.e., event state) for NOTIFYs with identical entity-tag entities (i.e., event state) for NOTIFYs with identical entity-tag
values when those NOTIFYs result from subscription to different values when those NOTIFYs result from subscription to different
resources. resources.
Note that there are valid cases for which identical entity-tag Note that there are valid cases for which identical entity-tag
values on different resources may occur. For example, it is values on different resources may occur. For example, it is
possible to generate entity-tag values using a one-way hash possible to generate entity-tag values using a one-way hash
function, resulting in the possibility that two different function, resulting in the possibility that two different
resources having the same entity-value will also have the same resources having the same entity-value will also have the same
entity tag. Clients however MUST NOT assume that this is the entity-tag. Clients however MUST NOT assume that this is the
case, as the algorithm for the generation of entity tags is case, as the algorithm for the generation of entity-tags is
notifier-dependent and not negotiated with the subscriber. notifier-dependent and not negotiated with the subscriber.
Consequently, the subscriber cannot differentiate between two Consequently, the subscriber cannot differentiate between two
entity tags that have the same value because they are similar entity-tags that have the same value because they are similar
hashes of identical entities, or because two notifiers happen to hashes of identical entities, or because two notifiers happen to
have used the same sequential number as an entity tag. Entity have used the same sequential number as an entity-tag. Entity
tags are only required to be unique for a given resource, not tags are only required to be unique for a given resource, not
globally unique. globally unique.
5.4. Polling or Fetching Resource State 5.4. Polling or Fetching Resource State
Polling with conditional notification allows a user agent to Polling with conditional notification allows a user agent to
efficiently poll resource state. This is accomplished using the efficiently poll resource state. This is accomplished using the
Suppress-If-Match condition: Suppress-If-Match condition:
Subscriber Notifier Subscriber Notifier
skipping to change at page 16, line 35 skipping to change at page 16, line 35
<-------- (7) NOTIFY <-------- (7) NOTIFY
Subscription-State: terminated Subscription-State: terminated
SIP-ETag: f2e45 SIP-ETag: f2e45
Content-Length: 0 Content-Length: 0
(8) 200 --------> (8) 200 -------->
Figure 3: Polling Resource State Figure 3: Polling Resource State
1. The subscriber polls for resource state by sending a SUBSCRIBE (1) The subscriber polls for resource state by sending a SUBSCRIBE
with zero expiry (expires immediately). with zero expiry (expires immediately).
2. The notifier accepts the SUBSCRIBE with a 202 (Accepted) (2) The notifier accepts the SUBSCRIBE with a 202 (Accepted)
response. response.
3. The notifier then immediately sends a first (and last) NOTIFY (3) The notifier then immediately sends a first (and last) NOTIFY
request with the current resource state, and the current entity- request with the current resource state and the current entity-
tag in the SIP-ETag header field. tag in the SIP-ETag header field.
4. The subscriber accepts the notification with a 200 (OK) response. (4) The subscriber accepts the notification with a 200 (OK)
response.
5. After some arbitrary poll interval, the subscriber sends another (5) After some arbitrary poll interval, the subscriber sends another
SUBSCRIBE with a Suppress-If-Match header field that includes the SUBSCRIBE with a Suppress-If-Match header field that includes
entity-tag received in the previous NOTIFY. the entity-tag received in the previous NOTIFY.
6. The notifier accepts the SUBSCRIBE with a 202 (Accepted) (6) The notifier accepts the SUBSCRIBE with a 202 (Accepted)
response. (202 would be used to indicate that the subscription response. (202 would be used to indicate that the subscription
request was understood without also indicating that it was request was understood without also indicating that it was
authorized, as per section 3.1.6.1 of SIP Specific Event authorized, as per Section 3.1.6.1 of SIP-Specific Event
Notification" [RFC3265].) Notification [RFC3265].)
7. Since the resource state has not changed since the previous poll (7) Since the resource state has not changed since the previous poll
occurred, the notifier sends a NOTIFY message with no body. It occurred, the notifier sends a NOTIFY message with no body. It
also mirrors the current entity-tag of the resource in the SIP- also mirrors the current entity-tag of the resource in the SIP-
ETag header field. ETag header field.
8. The subscriber accepts the notification with a 200 (OK) response. (8) The subscriber accepts the notification with a 200 (OK)
response.
5.5. Resuming a Subscription 5.5. Resuming a Subscription
Resuming a subscription means the ability to continue an earlier Resuming a subscription means the ability to continue an earlier
subscription that either closed abruptly, or was explicitly subscription that either closed abruptly or was explicitly
terminated. When resuming, the subscription is established without terminated. When resuming, the subscription is established without
transmitting the resource state. This is accomplished with transmitting the resource state. This is accomplished with
conditional notification and the Suppress-If-Match header field: conditional notification and the Suppress-If-Match header field:
Subscriber Notifier Subscriber Notifier
---------- -------- ---------- --------
(1) SUBSCRIBE --------> (1) SUBSCRIBE -------->
Suppress-If-Match: ega23 Suppress-If-Match: ega23
Expires: 3600 Expires: 3600
<-------- (2) 202 <-------- (2) 202
<-------- (3) NOTIFY <-------- (3) NOTIFY
Subscription-State: active Subscription-State: active
SIP-ETag: ega23 SIP-ETag: ega23
Content-Length: 0 Content-Length: 0
(4) 200 --------> (4) 200 -------->
Figure 4: Resuming a Subscription Figure 4: Resuming a Subscription
1. The subscriber attempts to resume an earlier subscription by (1) The subscriber attempts to resume an earlier subscription by
including a Suppress-If-Match header field with the entity-tag it including a Suppress-If-Match header field with the entity-tag
last received. it last received.
2. The notifier accepts the subscription after proper authentication (2) The notifier accepts the subscription after proper
and authorization, by sending a 202 (Accepted) response. authentication and authorization, by sending a 202 (Accepted)
response.
3. Since the condition is true, the notifier then immediately sends (3) Since the condition is true, the notifier then immediately sends
an initial NOTIFY request that has no body. It also mirrors the an initial NOTIFY request that has no body. It also mirrors the
current entity-tag of the resource in the SIP-ETag header field. current entity-tag of the resource in the SIP-ETag header field.
4. The subscriber accepts the NOTIFY and sends a 200 (OK) response. (4) The subscriber accepts the NOTIFY and sends a 200 (OK) response.
Had the entity-tag not been valid any longer, the condition would Had the entity-tag not been valid any longer, the condition would
have evaluated to false, and the NOTIFY would have had a body have evaluated to false, and the NOTIFY would have had a body
containing the latest resource state. containing the latest resource state.
5.6. Refreshing a Subscription 5.6. Refreshing a Subscription
To refresh a subscription using conditional notification, the To refresh a subscription using conditional notification, the
subscriber creates a subscription refresh before the subscription subscriber creates a subscription refresh before the subscription
expires, and uses the Suppress-If-Match header field: expires, and uses the Suppress-If-Match header field:
skipping to change at page 18, line 36 skipping to change at page 18, line 33
(1) SUBSCRIBE --------> (1) SUBSCRIBE -------->
Suppress-If-Match: aba91 Suppress-If-Match: aba91
Expires: 3600 Expires: 3600
<-------- (2) 204 <-------- (2) 204
Expires: 3600 Expires: 3600
Figure 5: Refreshing a Subscription Figure 5: Refreshing a Subscription
1. Before the subscription expires, the subscriber sends a SUBSCRIBE (1) Before the subscription expires, the subscriber sends a
request that includes the Suppress-If-Match header field with the SUBSCRIBE request that includes the Suppress-If-Match header
latest entity-tag it has seen. field with the latest entity-tag it has seen.
2. If the condition evaluates to true, the notifier sends a 204 (No (2) If the condition evaluates to true, the notifier sends a 204 (No
Notification) response and sends no NOTIFY request. The Expires Notification) response and sends no NOTIFY request. The Expires
header field of the 204 (No Notification) indicates the new header field of the 204 (No Notification) response indicates the
expiry time. new expiry time.
5.7. Terminating a Subscription 5.7. Terminating a Subscription
To terminate a subscription using conditional notification, the To terminate a subscription using conditional notification, the
subscriber creates a SUBSCRIBE request with a Suppress-If-Match subscriber creates a SUBSCRIBE request with a Suppress-If-Match
condition: condition:
Subscriber Notifier Subscriber Notifier
---------- -------- ---------- --------
(1) SUBSCRIBE --------> (1) SUBSCRIBE -------->
Suppress-If-Match: ega23 Suppress-If-Match: ega23
Expires: 0 Expires: 0
<-------- (2) 204 <-------- (2) 204
Figure 6: Terminating a Subscription Figure 6: Terminating a Subscription
1. The subscriber decides to terminate the subscription and sends a (1) The subscriber decides to terminate the subscription and sends a
SUBSCRIBE request with the Suppress-If-Match condition with the SUBSCRIBE request with the Suppress-If-Match condition with the
entity-tag it has last seen. entity-tag it has last seen.
2. If the condition evaluates to true, the notifier sends a 204 (No (2) If the condition evaluates to true, the notifier sends a 204 (No
Notification) response, which concludes the subscription, and the Notification) response, which concludes the subscription, and
subscriber can clear all state related to the subscription. the subscriber can clear all state related to the subscription.
5.8. Handling Transient Errors 5.8. Handling Transient Errors
This section is non-normative. This section is non-normative.
In some deployments, there may be Back-to-Back User Agent (B2BUA) In some deployments, there may be Back-to-Back User Agent (B2BUA)
devices that track SIP dialogs such as subscription dialogs. These devices that track SIP dialogs such as subscription dialogs. These
devices may be unaware of the conditional notification mechanism. devices may be unaware of the conditional notification mechanism.
It is possible that some B2BUA devices may treat a NOTIFY with It is possible that some B2BUA devices may treat a NOTIFY with
suppressed body as an error, or may expect all SUBSCRIBE messages to suppressed body as an error, or may expect all SUBSCRIBE messages to
have an associated NOTIFY message. have an associated NOTIFY message.
In general, there is very little that an endpoint can do to recover 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 from such transient errors. The most that can be done is to try to
detect such errors, and define a fall back behavior. detect such errors, and define a fallback behavior.
If subscribers encounter transient errors in conditional If subscribers encounter transient errors in conditional
notification, they should disable the feature and fall back to normal notification, they should disable the feature and fall back to normal
subscription behavior. subscription behavior.
6. Notifier Behavior 6. Notifier Behavior
This section augments the notifier behavior as specified in RFC3265 This section augments the notifier behavior as specified in RFC 3265
[RFC3265]. [RFC3265].
6.1. Generating Entity-tags 6.1. Generating Entity-tags
An entity-tag is a token carried in the SIP-ETag header field, and it 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 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 generating the entity-tag. It can have any value, except for
"*". For example, one possible method is to implement the entity-tag "*". For example, one possible method is to implement the entity-tag
as a simple counter, incrementing it by one for each generated as a simple counter, incrementing it by one for each generated
notification per resource. notification per resource.
A notifier MUST generate entity-tags for event notifications of all A notifier MUST generate entity-tags for event notifications of all
resources it is responsible for. The entity-tag MUST be unique 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 across all versions of all entities for each state of a resource as
reported by a given event package. Otherwise said, for any reported by a given event package. Otherwise said, for any
subscription or sequence of subscriptions to a specific resource subscription or sequence of subscriptions to a specific resource
using a singular event package, each entity tag produced MUST map to using a singular event package, each entity-tag produced MUST map to
one and only one presentation of resource state (entity). Two one and only one presentation of resource state (entity). Two
identical entities for a specific resource might or might not have identical entities for a specific resource might or might not have
identical entity tags; this decision is left to the notifier. identical entity-tags; this decision is left to the notifier.
An entity-tag is considered valid for as long as the entity exits. 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 An entity becomes stale when its version is no longer the current
one. The notifier MUST remember (or be able to recalculate) the 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 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, current. The notifier MAY remember the entity-tag longer than this,
e.g., for implementing journaled state differentials (Section 6.4). e.g., for implementing journaled state differentials (Section 6.4).
The entity tag values used in publications are not necessarily shared The entity-tag values used in publications are not necessarily shared
with the entity tag values used in subscriptions. This is because with the entity-tag values used in subscriptions. This is because
there may not always be a one-to-one mapping between a publication 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 and a notification of state change; there may be several sources to
the event composition process, and a publication into a resource may the event composition process, and a publication into a resource may
not affect the resulting entity. not affect the resulting entity.
6.2. Suppressing NOTIFY Bodies 6.2. Suppressing NOTIFY Bodies
When a condition in a SUBSCRIBE request for suppressing notifications When a condition in a SUBSCRIBE request for suppressing notifications
is true (i.e., the local entity-tag for the resource state and the 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 entity-tag in a Suppress-If-Match header field are byte-wise
skipping to change at page 21, line 7 skipping to change at page 21, line 12
NOTIFY contains no Content-Type header field, the Content-Length is NOTIFY contains no Content-Type header field, the Content-Length is
set to zero, and no payload is attached to the message. set to zero, and no payload is attached to the message.
Additionally, when a condition in a SUBSCRIBE request for suppressing Additionally, when a condition in a SUBSCRIBE request for suppressing
notifications is true and the SUBSCRIBE message is not sent within an notifications is true and the SUBSCRIBE message is not sent within an
established dialog, the notifier MUST send a NOTIFY request with a established dialog, the notifier MUST send a NOTIFY request with a
suppressed entity body. suppressed entity body.
Suppressing the entity body of a NOTIFY does not change the current Suppressing the entity body of a NOTIFY does not change the current
entity-tag of the resource. Hence, the NOTIFY MUST contain a SIP- entity-tag of the resource. Hence, the NOTIFY MUST contain a SIP-
Etag header field that contains the unchanged entity-tag of the ETag header field that contains the unchanged entity-tag of the
resource state. resource state.
A Suppress-If-Match header field that includes an entity-tag with the A Suppress-If-Match header field that includes an entity-tag with the
value of "*" MUST always evaluate to true. value of "*" MUST always evaluate to true.
6.3. Suppressing NOTIFY Requests 6.3. Suppressing NOTIFY Requests
When a condition in a SUBSCRIBE request to suppress notifications is 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 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 in a Suppress-If-Match header field match), and the SUBSCRIBE is sent
skipping to change at page 21, line 39 skipping to change at page 21, line 44
Suppressing the entire NOTIFY has no effect on the entity-tag of the Suppressing the entire NOTIFY has no effect on the entity-tag of the
resource. In other words, it remains unchanged. resource. In other words, it remains unchanged.
A Suppress-If-Match header field that includes an entity-tag with the A Suppress-If-Match header field that includes an entity-tag with the
value of "*" MUST always evaluate to true. value of "*" MUST always evaluate to true.
6.4. State Differentials 6.4. State Differentials
Some event packages support a scheme where notifications contain Some event packages support a scheme where notifications contain
state differentials, or state deltas [RFC3265] instead of complete state differentials, or state deltas [RFC3265], instead of complete
resource state. resource state.
Further extensions could define means for notifiers to keep track of Further extensions could define means for notifiers to keep track of
the state changes of a resource, e.g., storing the changes in a 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 journal. If a condition fails, the notifier would then send a state
differential in the NOTIFY rather than the full state of the event differential in the NOTIFY rather than the full state of the event
resource. This is only possible if the event package and the resource. This is only possible if the event package and the
subscriber both support a payload format that has this capability. subscriber both support a payload format that has this capability.
When state differentials are sent, the SIP-ETag header field MUST When state differentials are sent, the SIP-ETag header field MUST
skipping to change at page 22, line 38 skipping to change at page 22, line 41
not be sent. It is valid only in response to a SUBSCRIBE message not be sent. It is valid only in response to a SUBSCRIBE message
sent within an established dialog. sent within an established dialog.
The response code is added to the "Success" production rule in the The response code is added to the "Success" production rule in the
SIP [RFC3261] message grammar. SIP [RFC3261] message grammar.
7.2. Suppress-If-Match Header Field 7.2. Suppress-If-Match Header Field
The Suppress-If-Match header field is added to the definition of the The Suppress-If-Match header field is added to the definition of the
"message-header" rule in the SIP [RFC3261] grammar. Its use is "message-header" rule in the SIP [RFC3261] grammar. Its use is
described in Section 5, Section 6.3 and Section 6.2. described in Sections 5, 6.3, and 6.2.
This header field is allowed to appear in any request, but its This header field is allowed to appear in any request, but its
behavior is only defined for the SUBSCRIBE request. behavior is only defined for the SUBSCRIBE request.
7.3. Grammar 7.3. Grammar
This section defines the formal syntax for extensions described in This section defines the formal syntax for extensions described in
this memo in Augmented BNF (ABNF) [RFC5234]. The rules defined here this memo in Augmented BNF (ABNF) [RFC5234]. The rules defined here
augment and reference the syntax defined in RFC3261 [RFC3261] and augment and reference the syntax defined in RFC 3261 [RFC3261] and
RFC3903 [RFC3903]. RFC 3903 [RFC3903].
Success =/ "204" ; No Notification Success =/ "204" ; No Notification
; Success is defined in RFC3261. ; Success is defined in RFC 3261.
message-header =/ Suppress-If-Match message-header =/ Suppress-If-Match
; message-header is defined in RFC3261. ; message-header is defined in 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 RFC3903. ; entity-tag is defined in RFC 3903.
8. IANA Considerations 8. IANA Considerations
This document registers a new response code and a new header field This document registers a new response code and a new header field
name. name.
Note to IANA and the RFC editor: please replace all occurrences of
RFCXYZ in this section with the RFC number of this specification
upon publication.
8.1. 204 (No Notification) Response Code 8.1. 204 (No Notification) Response Code
This document registers a new response code. This response code is This document registers a new response code. This response code is
defined by the following information, which has been added to the defined by the following information, which has been added to the
methods and response-codes sub-registry under methods and response-codes sub-registry available from
http://www.iana.org/assignments/sip-parameters. http://www.iana.org.
This information is to be added under "Successful 2xx" category. This information has been added under "Successful 2xx" category.
+---------------------+-----------+ +---------------------+-----------+
| Response Code | Reference | | Response Code | Reference |
+---------------------+-----------+ +---------------------+-----------+
| 204 No Notification | [RFCXYZ] | | 204 No Notification | [RFC5839] |
+---------------------+-----------+ +---------------------+-----------+
8.2. Suppress-If-Match Header Field 8.2. Suppress-If-Match Header Field
This document registers a new SIP header field called Suppress-If- This document registers a new SIP header field called Suppress-If-
Match. This header field is defined by the following information, Match. This header field is defined by the following information,
which has been added to the header fields sub-registry under which has been added to the header fields sub-registry available from
http://www.iana.org/assignments/sip-parameters. http://www.iana.org.
+-------------------+---------+-----------+ +-------------------+---------+-----------+
| Header Name | Compact | Reference | | Header Name | Compact | Reference |
+-------------------+---------+-----------+ +-------------------+---------+-----------+
| Suppress-If-Match | | [RFCXYZ] | | Suppress-If-Match | | [RFC5839] |
+-------------------+---------+-----------+ +-------------------+---------+-----------+
9. Security Considerations 9. Security Considerations
The security considerations for SIP event notification are The security considerations for SIP event notification are
extensively discussed in RFC 3265 [RFC3265]. This specification extensively discussed in RFC 3265 [RFC3265]. This specification
introduces an optimization to SIP event notification, which in itself introduces an optimization to SIP event notification, which in itself
does not alter the security properties of the protocol. does not alter the security properties of the protocol.
10. Acknowledgments 10. Acknowledgments
The following people have contributed corrections and suggestions to The following people have contributed corrections and suggestions to
this document: Adam Roach, Sean Olson, Johnny Vrancken, Pekka Pessi, this document: Adam Roach, Sean Olson, Johnny Vrancken, Pekka Pessi,
Eva Leppanen, Krisztian Kiss, Peili Xu, Avshalom Houri, David Eva Leppanen, Krisztian Kiss, Peili Xu, Avshalom Houri, David
Viamonte, Jonathan Rosenberg, Qian Sun, Dale Worley, Tolga Asveren, Viamonte, Jonathan Rosenberg, Qian Sun, Dale Worley, Tolga Asveren,
Brian Stucker, Eric Rescorla, Arun Arunachalam and the SIP and SIMPLE Brian Stucker, Eric Rescorla, Arun Arunachalam, and the SIP and
working groups. SIMPLE working groups.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
skipping to change at page 25, line 40 skipping to change at page 25, line 28
Authors' Addresses Authors' Addresses
Aki Niemi Aki Niemi
Nokia Nokia
P.O. Box 407 P.O. Box 407
NOKIA GROUP, FIN 00045 NOKIA GROUP, FIN 00045
Finland Finland
Phone: +358 50 389 1644 Phone: +358 50 389 1644
Email: aki.niemi@nokia.com EMail: aki.niemi@nokia.com
Dean Willis (editor) Dean Willis (editor)
Softarmor Systems Softarmor Systems
3100 Independence Pkwy #311-164 3100 Independence Pkwy #311-164
Plano, TX 75075 Plano, TX 75075
USA USA
Phone: +1 214 504 1987 Phone: +1 214 504 1987
Email: dean.willis@softarmor.com EMail: dean.willis@softarmor.com
 End of changes. 106 change blocks. 
222 lines changed or deleted 212 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/