| TOC |
|
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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.
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 http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 24, 2009.
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
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.
1.
Introduction
1.1.
Document Conventions
1.2.
Terminology
2.
Motivations and Background
2.1.
Overview
2.2.
Problem Description
2.3.
Requirements
3.
Overview of Operation
4.
Resource Model for Entity-Tags
5.
Subscriber Behavior
5.1.
Detecting Support for Conditional Notification
5.2.
Generating SUBSCRIBE Requests
5.3.
Receiving NOTIFY Requests
5.4.
Polling or Fetching Resource State
5.5.
Resuming a Subscription
5.6.
Refreshing a Subscription
5.7.
Terminating a Subscription
5.8.
Handling Transient Errors
6.
Notifier Behavior
6.1.
Generating Entity-tags
6.2.
Suppressing NOTIFY Bodies
6.3.
Suppressing NOTIFY Requests
6.4.
State Differentials
6.5.
List Subscriptions
7.
Protocol Element Definitions
7.1.
204 (No Notification) Response Code
7.2.
Suppress-If-Match Header Field
7.3.
Grammar
8.
IANA Considerations
8.1.
204 (No Notification) Response Code
8.2.
Suppress-If-Match Header Field
9.
Security Considerations
10.
Acknowledgments
11.
References
11.1.
Normative References
11.2.
Informative References
§
Author's Address
| TOC |
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 of subscriptions, as well as the possibility to fetch or periodically poll the event resource.
Several instantiations of this framework, called event packages have been defined, e.g., for presence (Rosenberg, J., “A Presence Event Package for the Session Initiation Protocol (SIP),” August 2004.) [RFC3856], message waiting indications (Mahy, R., “A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP),” August 2004.) [RFC3842] and registrations (Rosenberg, J., “A Session Initiation Protocol (SIP) Event Package for Registrations,” March 2004.) [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.
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 in 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 almost identical to conditional requests defined in the HyperText Transfer Protocol (HTTP) (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616], and follows the mechanism already defined for the PUBLISH (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) [RFC3903] method for issuing conditional event publications.
This memo is structured as follows. Section 2 (Motivations and Background) explains the background, motivations and requirements for the work; Section 3 (Overview of Operation) gives a general overview of the mechanism; Section 4 (Resource Model for Entity-Tags) explains the underlying model for resources and entities as they apply to conditional notification; Section 5 (Subscriber Behavior) defines the subscriber behavior; Section 6 (Notifier Behavior) defines the notifier behavior; Section 7 (Protocol Element Definitions) includes the protocol element definitions; Section 8 (IANA Considerations) includes the IANA considerations; and Section 9 (Security Considerations) includes the security considerations.
| TOC |
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119] and indicate requirement levels for compliant implementations.
| TOC |
In addition to the terminology introduced in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.), [RFC3265] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) and [RFC3903] (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.), this specification uses these additional terms to describe the objects of conditional notification:
- 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.
- entity
- The representation of resource state. An entity consists of the event 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.
| TOC |
| TOC |
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.
| TOC |
In spite of being somewhat distinct operations, 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. Instead, the SUBSCRIBE method is overloaded to perform all of these functions, and the notifier behavior is identical in each of them; each SUBSCRIBE request generates a NOTIFY request containing the latest resource state. In fact, the only difference between a fetch that does not create a (lasting) subscription, and a SUBSCRIBE that creates one is in the Expires header field value of the SUBSCRIBE; a zero-expiry SUBSCRIBE only generates a single NOTIFY, after which the subscription immediately terminates.
Some subscriber implementations may choose to operate in semi-stateless mode, in which they immediately upon receiving and processing the NOTIFY forget the resource state. This operation necessarily needs every NOTIFY to carry the full resource state. However, for an implementation that stores the resource state locally, this mode of operation is inefficient.
There are certain conditions that aggravate the problem. Such conditions usually entail such things as:
In effect, for an event package that generates few state changes, and is refreshed relatively often the majority of traffic generated may be related to subscription maintenance. Especially in networks where bandwidth consumption and traffic count is at a premium, the high overhead of subscription maintenance becomes a barrier for deployment.
The same problem affects fetching and polling of resource state as well. As a benchmark, if we look at the performance of HTTP (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616] in similar scenarios, it performs substantially better using conditional requests. When resources are tagged with an entity-tag, and each GET is a conditional one using the "If-None-Match" header field, the entity body need not be sent more than once; if the resource has not changed between successive polls, an error response is returned indicating this fact, and the resource entity is not transmitted again.
The SIP PUBLISH (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) [RFC3903] method also contains a similar feature, 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.
| TOC |
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 the latest event state of the resource.
- REQ2:
- This mechanism must apply to initial subscriptions, in which the subscriber is attempting to "resume" an earlier subscription.
- REQ3:
- This mechanism must apply to refreshing a subscription.
- REQ4:
- This mechanism must apply to terminating a subscription (i.e., an unsubscribe).
- REQ5:
- This mechanism must apply to fetching or polling of resource state.
| TOC |
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 RFC3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261], RFC3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265].
If the notifier receiving the SUBSCRIBE request supports conditional subscriptions, it generates a unique entity tag for the event notification, 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. More on this in Section 4 (Resource Model for Entity-Tags).
Entity-tags are independent of subscriptions; the notifier remembers the entity-tags of all versions of entities for a resource regardless of whether or not there are any active subscription to that resource. 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 (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) [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.
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.
The condition is evaluated by matching the value of the header field against the current entity-tag of the resource state. There is also a wildcard entity-tag with a special value of "*" that always matches.
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Expires: 3600
<-------- (2) 200 (or 202)
<-------- (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
... time passes ...
<-------- (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
| Figure 1: Example Message Flow |
Figure 1 (Example Message Flow) describes a typical message flow for conditional notification:
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.
| TOC |
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 (Resource Model Diagram) illustrates the model.
+-----+
............ | |
. . | 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 |
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 (Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” August 2006.) [RFC4662]. Conditional notification for list subscriptions is addressed in Section 6.5 (List Subscriptions).
A resource is identified by zero or more URIs, which can be SIP URIs, pres URIs (Peterson, J., “Common Profile for Presence (CPP),” August 2004.) [RFC3859] or similar. Subscribers use this URI to subscribe to the resource for certain types of events, identified by the event package.
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 what is called an entity. Each resource may be associated with zero or more entities; however, an entity is only valid for a single resource.
Note that, as can be seen from the illustration, the association between a resource and an entity follows the typical composition relationship, i.e., an entity may belong to only one resource, and it is expected to only exist with that resource.
An entity consists of the data carried in the body of a NOTIFY message, and related meta-data in the message header. This meta-data includes, but is not limited to the following SIP header fields:
entity-header = Content-Disposition ; defined in RFC 3261
/ Content-Encoding ; defined in RFC 3261
/ Content-Language ; defined in RFC 3261
/ Content-Length ; defined in RFC 3261
/ Content-Type ; defined in RFC 3261
/ Event ; defined in RFC 3265
/ extension-header ; defined in RFC 3261
Note that the Subscription-State is explicitly not part of the entity. Event packages may in the future 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 being equal does not indicate identical entities. In other words, if an entity-tag is received that matches a previously seen entity-tag, the subscriber cannot assume the event state to be identical to that received earlier.
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.
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 (Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” April 2003.) [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.
| TOC |
This section augments the subscriber behavior defined in RFC3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265]. It first discusses general issues related to indicating support for the mechanism (Detecting Support for Conditional Notification) and creating conditions in SUBSCRIBE requests (Generating SUBSCRIBE Requests); it then describes the workflows for the main three use cases for making the subscription conditional.
| TOC |
The mechanism defined in this memo is backwards compatible with SIP events (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [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.
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.
| TOC |
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.
Unlike the condition introduced for the SIP PUBLISH (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) [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 regards to sending the notifications after the SUBSCRIBE.
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 to either omit the body of the resulting NOTIFY message (if the SUBSCRIBE is not sent within an existing dialog), or suppress (i.e., block) the NOTIFY request that would otherwise be triggered 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 to either suppress any subsequent NOTIFY request, or if there are reportable changes in the NOTIFY header, e.g., the Subscription-State has changed, suppress the body of any subsequent NOTIFY request.
If the condition is false, the notifier follows its default behaviour.
If the subscriber receives a 204 (No Notification) to an in-dialog SUBSCRIBE, the subscriber can clear handle that it may have had pending on a NOTIFY in response the SUBSCRIBE message.
The value of the "Suppress-If-Match" header field is an entity-tag, which is an opaque token that the subscriber simply copies from a previously received NOTIFY request.
Example:
Suppress-If-Match: 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.
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.
| TOC |
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.
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.
Note that there are valid cases for which identical entity-tag values indeed imply identical event state. For example, it is possible to generate entity-tag values using a one-way hash function.
| TOC |
Polling with conditional notification allows a user agent to efficiently poll resource state. This is accomplished using the Suppress-If-Match condition:
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Expires: 0
<-------- (2) 202
<-------- (3) NOTIFY
Subscription-State: terminated
SIP-ETag: f2e45
Content-Length: 17539
(4) 200 -------->
... poll interval elapses ...
(5) SUBSCRIBE -------->
Suppress-If-Match: f2e45
Expires: 0
<-------- (6) 202
<-------- (7) NOTIFY
Subscription-State: terminated
SIP-ETag: f2e45
Content-Length: 0
(8) 200 -------->
| Figure 3: Polling Resource State |
| TOC |
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
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: ega23
Expires: 3600
<-------- (2) 202
<-------- (3) NOTIFY
Subscription-State: active
SIP-ETag: ega23
Content-Length: 0
(4) 200 -------->
| Figure 4: Resuming a Subscription |
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.
| TOC |
To refresh a subscription using conditional notification, the subscriber creates a subscription refresh before the subscription is about to expire, and uses the Suppress-If-Match header field:
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: aba91
Expires: 3600
<-------- (2) 204
Expires: 3600
| Figure 5: Refreshing a Subscription |
| TOC |
To terminate a subscription using conditional notification, the subscriber creates a SUBSCRIBE request with a Suppress-If-Match condition:
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: ega23
Expires: 0
<-------- (2) 204
| Figure 6: Terminating a Subscription |
| TOC |
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.
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.
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 fall back behavior.
If subscribers encounter transient errors in conditional notification, they should disable the feature and fall back to normal subscription behavior.
| TOC |
This section augments the notifier behavior as specified in RFC3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265].
| TOC |
A notifier MUST generate entity-tags for event notifications of all resources it is responsible for. The entity-tag MUST be unique across all versions of all entities for a resource and event package.
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.
An entity-tag is considered valid for as long as the entity is valid. An entity becomes stale when its version is no longer the current one. The notifier MUST remember 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 (State Differentials).
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; there may be several sources to the event composition process.
| TOC |
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 match) 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.
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.
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.
A Suppress-If-Match header field that includes an entity-tag with the value of "*" MUST always evaluate to true.
| TOC |
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.
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.
| TOC |
Some event packages may support a scheme where notifications contain state differentials, or state deltas (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265] instead of complete resource state.
A notifier can optionally keep track of the state changes of a resource, e.g., storing the changes in a journal. If a condition fails, the notifier MAY 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.
| TOC |
The Event Notification Extension for Resource Lists (Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” August 2006.) [RFC4662] defines a mechanism for subscribing to a homogeneous list of resources using the SIP events framework.
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.
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.
| TOC |
This section describes the protocol extensions required for conditional notification.
| TOC |
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.
The response code is added to the "Success" production rule in the SIP (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] message grammar.
| TOC |
The Suppress-If-Match header field is added to the definition of the "message-header" rule in the SIP (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] grammar. Its use is described in Section 5 (Subscriber Behavior), Section 6.3 (Suppressing NOTIFY Requests) and Section 6.2 (Suppressing NOTIFY Bodies).
This header field is allowed to appear in any request, but its behavior is only defined for the SUBSCRIBE request.
| TOC |
This section defines the formal syntax for extensions described in this memo in Augmented BNF (ABNF) (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [RFC5234]. The rules defined here augment and reference the syntax defined in RFC3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] and RFC3903 (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) [RFC3903].
Success =/ "204" ; No Notification ; Success is defined in RFC3261. message-header =/ Suppress-If-Match ; message-header is defined in RFC3261. Suppress-If-Match = "Suppress-If-Match:" ( entity-tag / "*" ) ; entity-tag is defined in RFC3903.
| TOC |
This document registers a new response code and a new header field 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.
| TOC |
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 under http://www.iana.org/assignments/sip-parameters.
This information is to be added under "Successful 2xx" category.
| Response Code | Reference |
|---|---|
| 204 No Notification | [RFCXYZ] |
| TOC |
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 under http://www.iana.org/assignments/sip-parameters.
| Header Name | Compact | Reference |
|---|---|---|
| Suppress-If-Match | [RFCXYZ] |
| TOC |
The security considerations for SIP event notification are extensively discussed in RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265]. This specification introduces an optimization to SIP event notification, which in itself does not alter the security properties of the protocol.
| TOC |
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.
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [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 (TXT). |
| [RFC3265] | Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” RFC 3265, June 2002 (TXT). |
| [RFC3903] | Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” RFC 3903, October 2004 (TXT). |
| [RFC5234] | Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” STD 68, RFC 5234, January 2008 (TXT). |
| TOC |
| [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 (TXT, PS, PDF, HTML, XML). |
| [RFC3515] | Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” RFC 3515, April 2003 (TXT). |
| [RFC3680] | Rosenberg, J., “A Session Initiation Protocol (SIP) Event Package for Registrations,” RFC 3680, March 2004 (TXT). |
| [RFC3842] | Mahy, R., “A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP),” RFC 3842, August 2004 (TXT). |
| [RFC3856] | Rosenberg, J., “A Presence Event Package for the Session Initiation Protocol (SIP),” RFC 3856, August 2004 (TXT). |
| [RFC3859] | Peterson, J., “Common Profile for Presence (CPP),” RFC 3859, August 2004 (TXT). |
| [RFC4662] | Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” RFC 4662, August 2006 (TXT). |
| TOC |
| Aki Niemi | |
| Nokia | |
| P.O. Box 407 | |
| NOKIA GROUP, FIN 00045 | |
| Finland | |
| Phone: | +358 50 389 1644 |
| Email: | aki.niemi@nokia.com |