Session Initiation Protocol A. Niemi
Working Group Nokia
Internet-Draft August 26, 2007
Intended status: Standards Track
Expires: February 27, 2008
An Extension to Session Initiation Protocol (SIP) Events for Conditional
Event Notification
draft-ietf-sip-subnot-etags-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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
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 February 27, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The Session Initiation Protocol (SIP) events framework enables
receiving asynchronous notification of various events from other SIP
user agents. This framework defines the procedures for creating,
refreshing and terminating subscriptions, as well as fetching and
periodic polling of resource state. These procedures have a serious
deficiency in that they provide no tools to avoid replaying event
Niemi Expires February 27, 2008 [Page 1]
Internet-Draft Entity-tags for SIP Events August 2007
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Document Conventions . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Motivations and Background . . . . . . . . . . . . . . . . . . 5
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Problem Description . . . . . . . . . . . . . . . . . . . 6
2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4. Resource Model for Entity-Tags . . . . . . . . . . . . . . . . 10
5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 13
5.1. Detecting Support for Conditional Notification . . . . . . 13
5.2. Generating SUBSCRIBE Requests . . . . . . . . . . . . . . 13
5.3. Receiving NOTIFY Requests . . . . . . . . . . . . . . . . 14
5.4. Polling or Fetching Resource State . . . . . . . . . . . . 14
5.5. Resuming a Subscription . . . . . . . . . . . . . . . . . 16
5.6. Refreshing a Subscription . . . . . . . . . . . . . . . . 17
5.7. Terminating a Subscription . . . . . . . . . . . . . . . . 17
6. Notifier Behavior . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Generating Entity-tags . . . . . . . . . . . . . . . . . . 18
6.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 19
6.3. Suppressing NOTIFY Requests . . . . . . . . . . . . . . . 19
6.4. State Differentials . . . . . . . . . . . . . . . . . . . 19
6.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 20
7. Protocol Element Definitions . . . . . . . . . . . . . . . . . 20
7.1. 204 (No Notification) Response Code . . . . . . . . . . . 20
7.2. Suppress-Notify-If-Match Header Field . . . . . . . . . . 20
7.3. Suppress-Body-If-Match Header Field . . . . . . . . . . . 21
7.4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8.1. 204 (No Notification) Response Code . . . . . . . . . . . 21
8.2. Suppress-Body-If-Match Header Field . . . . . . . . . . . 22
8.3. Suppress-Notify-If-Match Header Field . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
Niemi Expires February 27, 2008 [Page 2]
Internet-Draft Entity-tags for SIP Events August 2007
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Niemi Expires February 27, 2008 [Page 3]
Internet-Draft Entity-tags for SIP Events August 2007
1. Introduction
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 [6], message waiting indications [7]
and registrations [8].
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 the SIP events framework allowing a
notifier to issue versioning in the form of entity-tags to
notifications, and the subscriber to condition the SUBSCRIBE request
for actual changes since the last notification carrying that entity-
tag was issued. The solution is almost identical to conditional
requests defined in the HyperText Transfer Protocol (HTTP) [9], and
follows the mechanism already defined for the PUBLISH [1] method for
issuing conditional event publications.
This memo is structured as follows. Section 2 explains the
backround, motivations and requirements for the work; Section 3 gives
a general overview of the mechanism; Section 4 explains the
underlying model for resources and entities as they apply to
conditional notification; Section 5 defines the subscriber behavior;
Section 6 defines the notifier behavior; Section 7 includes the
protocol element definitions; Section 8 includes the IANA
considerations; and Section 9 includes the security considerations.
Niemi Expires February 27, 2008 [Page 4]
Internet-Draft Entity-tags for SIP Events August 2007
1.1. Document Conventions
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 [2]
and indicate requirement levels for compliant implementations.
1.2. Terminology
In addition to the terminology introduced in [3], [4] and [1], 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.
representation
An event notification carries a representation of the current
resource state. The physical realization of a representation is
called an entity. There may be many different representations of
the state of a single resource.
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 accross all versions of all entities for a
resource and event package.
2. Motivations and Background
2.1. Overview
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.
Niemi Expires February 27, 2008 [Page 5]
Internet-Draft Entity-tags for SIP Events August 2007
2.2. Problem Description
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:
o Large entity bodies in the payloads of notifications
o High rate of subscription refreshes
o Relatively low rate of notifications triggered by state changes
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 [9] 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.
Niemi Expires February 27, 2008 [Page 6]
Internet-Draft Entity-tags for SIP Events August 2007
The SIP PUBLISH [1] 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.
2.3. Requirements
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.
3. Overview of Operation
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 [3], RFC3265 [4].
If the notifier receiving the SUBSCRIBE request supports conditional
subscriptions, it generates a unique entity tag for the event
notification, and attaches includes it in a SIP-ETag header field of
the NOTIFY request. The entity tag is unique accross all versions of
all entities for a resource and event package. More on this in
Section 4.
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
Niemi Expires February 27, 2008 [Page 7]
Internet-Draft Entity-tags for SIP Events August 2007
to make a SUBSCRIBE contain a condition in the form of a header
field. Unlike the "If-Match" condition in a PUBLISH [1] request,
which applies to whether the PUBLISH succeeds or returns an error,
this condition applies to the notification that is sent after the
SUBSCRIBE request has been processed.
The two conditions available for SUBSCRIBE are Suppress-Body-If-Match
and Suppress-Notify-If-Match. Each of these header fields contains
the last entity-tag seen by the subscriber. If the condition
evaluates to true, Suppress-Body-If-Match instructs the notifier to
suppress the body of the next notification and Suppress-Notify-If-
Match instructs the notifier to suppress 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.
Niemi Expires February 27, 2008 [Page 8]
Internet-Draft Entity-tags for SIP Events August 2007
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Expires: 3600
<-------- (2) 202
<-------- (3) NOTIFY
SIP-ETag: ffee2
(4) 200 -------->
...
(5) SUBSCRIBE --------> \ if "ffee2"
Suppress-Notify-If-Match: ffee2 | matches
Expires: 3600 | local
| entity-tag
|
<-------- (6) 204 / then
...
<-------- (7) NOTIFY
SIP-ETag: ca89a
(8) 200 -------->
...
(9) SUBSCRIBE --------> \ if "ca89"
Suppress-Notify-If-Match: ca89a | matches
Expires: 0 | local
| entity-tag
|
<-------- (10) 204 / then
Figure 1: Example Message Flow
Figure 1 describes a typical message flow for conditional
notification:
1. The subscriber initiates a subscription by sending a SUBSCRIBE
request for a resource.
2. After proper authentication and authorization, the notifier
accepts the subscription.
Niemi Expires February 27, 2008 [Page 9]
Internet-Draft Entity-tags for SIP Events August 2007
3. The notifier then immediately sends the initial event
notification, including a unique entity-tag in a SIP-ETag header
field.
4. The subscriber accepts the notification and stores the entity-
tag value along with the resource state.
5. Later, the subscriber refreshes the subscription, and includes
an entity-tag in a Suppress-Notify-If-Match header field.
6. The notifier evaluates the condition by matching its local
entity-tag value for the resource against the value of the
Suppress-Notify-If-Match header field. If the condition
evaluates to true, the notifier informs the subscriber that the
notification will not be sent.
7. At some point, the state of the resource changes, e.g., the
presence status of a user changes from online to busy. This
triggers an event notification with a new value in the SIP-ETag
header field.
8. The subscriber accepts the notification and stores the new
entity-tag along with the resource state.
9. After a while, the subscriber decides to terminate the
subscription. It adds a condition for Suppress-Notify-If-Match,
and includes the entity-tag it received in the previous NOTIFY.
10. The notifier evaluates the condition by matching its entity-tag
for the resource against the value of the Suppress-Notify-If-
Match header field. If the condition evaluates to true, the
notifier informs the subscriber that no notification will be
sent. This concludes the subscription.
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.
4. Resource Model for Entity-Tags
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
Niemi Expires February 27, 2008 [Page 10]
Internet-Draft Entity-tags for SIP Events August 2007
some key differences. This section explains in detail the model as
it applies to SIP events. Figure 2 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
Niemi Expires February 27, 2008 [Page 11]
Internet-Draft Entity-tags for SIP Events August 2007
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 [10].
Conditional notification for list subscriptions is addressed in
Section 6.5.
A resource is identified by zero or more URIs, which can be SIP URIs,
pres URIs [11] 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 have zero or more entities associated with them;
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 accross all versions of all entities pertaining to a
single resource and event package.
Niemi Expires February 27, 2008 [Page 12]
Internet-Draft Entity-tags for SIP Events August 2007
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.
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 that case,
implementations MUST NOT expect the entity-tags to be shared between
the mechanisms. Of course, event packages or specific applications
of SIP Events may allow such dependencies.
5. Subscriber Behavior
This section augments the subscriber behavior defined in RFC3265 [4].
It first discusses general issues related to indicating support for
the mechanism (Section 5.1) and creating conditions in SUBSCRIBE
requests (Section 5.2); it then describes the workflows for the main
three use cases for making the subscription conditional.
5.1. Detecting Support for Conditional Notification
The mechanism defined in this memo is backwards compatible with SIP
events [4] 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 conditioning a
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.
5.2. Generating SUBSCRIBE Requests
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 [1] method, these
conditions do not apply to the SUBSCRIBE request itself, but to the
resulting NOTIFY request. When true, the condition drives the
notifier to change its behavior with regards to sending the first
Niemi Expires February 27, 2008 [Page 13]
Internet-Draft Entity-tags for SIP Events August 2007
notification after the SUBSCRIBE.
There are two conditional header fields defined in this
specification:
Suppress-Body-If-Match: if this condition evaluates to true, the
notifier is instructed to suppress (i.e., remove) the body of the
first NOTIFY request following the SUBSCRIBE. If false, the
notifier follows the default behavior.
Suppress-Notify-If-Match: if this condition evaluates to true, the
notifier is instructed to suppress (i.e., block) the entire first
NOTIFY request following the SUBSCRIBE, and instead send a 204 (No
Notification) response. If false, the notifier again follows the
default behavior.
If the subscriber receives a 204 (No Notification) response to
SUBSCRIBE, it MUST consider the subscription handshake as completed.
That is, the subscriber can clear any handle that it may have had
pending on a NOTIFY to conclude establishing the subsctiption.
The value of these header-fields is an entity-tag, which is an opaque
token that the subscriber simply copies from a previously received
NOTIFY request.
Examples:
Suppress-Body-If-Match: b4cf7
Suppress-Notify-If-Match: 628736
The conditional 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-Notify-If-Match: *
5.3. Receiving NOTIFY Requests
When a subscriber receives a NOTIFY request that contains a SIP-ETag
header field, it MUST store the entity-tag.
5.4. Polling or Fetching Resource State
Polling with conditional notification allows a user agent to
efficiently poll resource state. This is accomplished using the
Niemi Expires February 27, 2008 [Page 14]
Internet-Draft Entity-tags for SIP Events August 2007
Suppress-Notify-If-Match condition:
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Expires: 0
<-------- (2) 202
<-------- (3) NOTIFY
SIP-ETag: f2e45
(4) 200 -------->
... poll interval elapses
(5) SUBSCRIBE -------->
Suppress-Notify-If-Match: f2e45
Expires: 0
<-------- (6) 204
Figure 4: Polling Resource State
1. The subscriber polls for resource state by sending a SUBSCRIBE
with zero expiry (expires immediately).
2. The notifier accepts the SUBSCRIBE with a 202 (Accepted)
response.
3. The notifier then immediately sends a first (and last) NOTIFY
request with the current resource state, and the current entity-
tag in the SIP-ETag header field.
4. The subsciber accepts the notification with a 200 (OK) response.
5. After some arbitrary poll interval, the subscriber sends another
SUBSCRIBE with a Suppress-Notify-If-Match header field that
includes the entity-tag received in the previous NOTIFY.
6. Since the resource state has not changed since the previous poll
occurred, the notifier sends a 204 (No Notification) response,
which concludes the poll.
Niemi Expires February 27, 2008 [Page 15]
Internet-Draft Entity-tags for SIP Events August 2007
Fetching resource state using conditional notification and the
wildcard entity-tag allows two other types of operations as well:
Liveliness check: this allows a user agent to periodically check
whether a resource is still available. This is accomplished using
the Suppress-Notify-If-Match header field and the wildcard entity-
tag.
Meta-information query: this allows a user agent to query the latest
meta-information related to a resource, e.g., its current entity-
tag value. This is accomplished using the Suppress-Body-If-Match
header field and the wildcard entity-tag.
5.5. Resuming a Subscription
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-Body-If-Match header field:
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-Body-If-Match: ega23
Expires: 3600
<-------- (2) 202
<-------- (3) NOTIFY
SIP-ETag: ega23
Content-Length: 0
(4) 200 -------->
Figure 5: Resuming a Subscription
1. The subscriber attempts to resume an earlier subscription by
including a Suppress-Body-If-Match header field with the entity-
tag it last received.
2. The notifier accepts the subscription after proper authentication
and authorization, by sending a 202 (Accepted) (Accepted)
response.
3. The notifier then immediately sends an initial NOTIFY request
that now has no body. It also mirrors the current entity-tag of
Niemi Expires February 27, 2008 [Page 16]
Internet-Draft Entity-tags for SIP Events August 2007
the resource in the SIP-ETag header field.
4. The subscriber accepts the NOTIFY and sends a 200 (OK) response.
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.
5.6. Refreshing a Subscription
To refresh a subscription using conditional notification, the
subscriber creates a subscription refresh before the subscription is
about to expire, and uses the Suppress-Notify-If-Match header field:
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-Notify-If-Match: aba91
Expires: 3600
<-------- (2) 204
Expires: 3600
Figure 6: Refreshing a Subscription
1. Before the subscription is about to expire, the subscriber sends
a SUBSCRIBE request that includes the Suppress-Notify-If-Match
header field with the latest entity-tag it has seen.
2. If the condition evaluates to true, the notifier sends a 204 (No
Notification) response and sends no NOTIFY request. The Expires
header field of the 204 (No Notification) indicates the new
expiry time.
5.7. Terminating a Subscription
To terminate a subscription using conditional notification, the
subscriber creates a SUBSCRIBE request with a Suppress-Notify-If-
Match condition:
Niemi Expires February 27, 2008 [Page 17]
Internet-Draft Entity-tags for SIP Events August 2007
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-Notify-If-Match: ega23
Expires: 0
<-------- (2) 204
Figure 7: Terminating a Subscription
1. The subscriber decides to terminate the subscription and sends a
SUBSCRIBE request with the Suppress-Notify-If-Match condition
with the entity-tag it has last seen.
2. If the condition evaluates to true, the notifier sends a 204 (No
Notification) response, which concludes the subscription, and the
subscriber can clear all state related to the subscription.
6. Notifier Behavior
This section augments the notifier behavior as specified in RFC3265
[4].
6.1. Generating Entity-tags
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 (Section 6.4).
The entity tag values used in publications are not necessarily shared
with the entity tag values used in subscriptions. This is because
Niemi Expires February 27, 2008 [Page 18]
Internet-Draft Entity-tags for SIP Events August 2007
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.
6.2. Suppressing NOTIFY Bodies
When a condition for suppressing a NOTIFY body is true, i.e., the
local entity-tag for the resource state and the subscriber provided
entity-tag in a Suppress-Body-If-Match header field match, the
notifier MUST suppress the body of the resulting 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.
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 event
state resource.
A Suppress-Body-If-Match header field that includes an entity-tag
with the value of "*" MUST always evaluate to true.
6.3. Suppressing NOTIFY Requests
When a condition in a SUBSCRIBE request to suppress a NOTIFY request
is true, i.e., the local entity-tag of the resource and the entity-
tag in a Suppress-Notify-If-Match header field of a SUBSCRIBE request
match, the notifier MUST suppress the resulting NOTIFY request, and
generate a 204 (No Notification) response.
Such 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-Body-If-Match header field that includes an entity-tag
with the value of "*" MUST always evaluate to true.
6.4. State Differentials
Some event packages may support a scheme where notifications contain
state differentials, or state deltas [4] 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
Niemi Expires February 27, 2008 [Page 19]
Internet-Draft Entity-tags for SIP Events August 2007
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.
6.5. List Subscriptions
The Event Notification Extension for Resource Lists [10] 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.
7. Protocol Element Definitions
This section describes the protocol extensions required for
conditional notification.
7.1. 204 (No Notification) Response Code
The 204 (No Notification) response code indicates that the request
was successful, but the notification associated with the request will
not be sent.
The response code is added to the "Success" production rule in the
SIP [3] message grammar.
7.2. Suppress-Notify-If-Match Header Field
The Suppress-Notify-If-Match header field is added to the definition
of the "message-header" rule in the SIP [3] grammar. Its use is
described in Section 5 and Section 6.3.
This header field is allowed to appear in any request, but it's
behavior is only defined for the SUBSCRIBE request.
Niemi Expires February 27, 2008 [Page 20]
Internet-Draft Entity-tags for SIP Events August 2007
7.3. Suppress-Body-If-Match Header Field
The Suppress-Body-If-Match header field is added to the definition of
the "message-header" rule in the SIP [3] grammar. Its use is
described in Section 5 and Section 6.2.
This header field is allowed to appear in any request, but it's
behavior is only defined for the SUBSCRIBE request.
7.4. Grammar
This section defines the formal syntax for extensions described in
this memo in Augmented BNF (ABNF) [5]. The rules defined here
augment and reference the syntax defined in RFC3261 [3] and RFC3903
[1].
Success =/ "204" ; No Notification
; Success is defined in RFC3261.
message-header =/ Suppress-Body-If-Match
message-header =/ Suppress-Notify-If-Match
; message-header is defined in RFC3261.
Suppress-Body-If-Match = "Suppress-Body-If-Match" ":"
entity-tag / "*"
Suppress-Notify-If-Match = "Suppress-Notify-If-Match" ":"
entity-tag / "*"
; entity-tag is defined in RFC3903.
8. IANA Considerations
This document registers a new response code and two new header field
names.
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
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
Niemi Expires February 27, 2008 [Page 21]
Internet-Draft Entity-tags for SIP Events August 2007
http://www.iana.org/assignments/sip-parameters.
This information is to be added under "Successful 2xx" category.
+---------------------+-----------+
| Response Code | Reference |
+---------------------+-----------+
| 204 No Notification | [RFCXYZ] |
+---------------------+-----------+
8.2. Suppress-Body-If-Match Header Field
This document registers a new SIP header field called Suppress-Body-
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-Body-If-Match | | [RFCXYZ] |
+------------------------+---------+-----------+
8.3. Suppress-Notify-If-Match Header Field
This document registers a new SIP header field called Suppress-
Notify-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-Notify-If-Match | | [RFCXYZ] |
+--------------------------+---------+-----------+
9. Security Considerations
The security considerations for SIP event notification are
extensively discussed in RFC 3265 [4]. This specification introduces
an optimization to SIP event notification, which in itself does not
alter the security properties of the protocol.
10. Acknowledgments
The following people have contributed corrections and suggestions to
Niemi Expires February 27, 2008 [Page 22]
Internet-Draft Entity-tags for SIP Events August 2007
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 and the SIP and
SIMPLE working groups.
11. References
11.1. Normative References
[1] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] 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.
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
11.2. Informative References
[6] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[7] Mahy, R., "A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP)",
RFC 3842, August 2004.
[8] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[9] 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.
[10] Roach, A., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006.
[11] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
August 2004.
Niemi Expires February 27, 2008 [Page 23]
Internet-Draft Entity-tags for SIP Events August 2007
[12] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "Functional Description of Event Notification
Filtering", RFC 4660, September 2006.
Author's Address
Aki Niemi
Nokia
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 389 1644
Email: aki.niemi@nokia.com
Niemi Expires February 27, 2008 [Page 24]
Internet-Draft Entity-tags for SIP Events August 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Niemi Expires February 27, 2008 [Page 25]
