draft-ietf-sipcore-subnot-etags-02.txt   draft-ietf-sipcore-subnot-etags-03.txt 
Session Initiation Protocol A. Niemi Session Initiation Protocol A. Niemi
Working Group Nokia Working Group Nokia
Internet-Draft April 22, 2009 Internet-Draft D. Willis, Ed.
Intended status: Standards Track Intended status: Standards Track Softarmor Systems
Expires: October 24, 2009 Expires: May 26, 2010 November 22, 2009
An Extension to Session Initiation Protocol (SIP) Events for Conditional An Extension to Session Initiation Protocol (SIP) Events for Conditional
Event Notification Event Notification
draft-ietf-sipcore-subnot-etags-02 draft-ietf-sipcore-subnot-etags-03
Abstract
The Session Initiation Protocol (SIP) events framework enables
receiving asynchronous notification of various events from other SIP
user agents. This framework defines the procedures for creating,
refreshing and terminating subscriptions, as well as fetching and
periodic polling of resource state. These procedures provide no
tools to avoid replaying event notifications that have already been
received by a user agent. This memo defines an extension to SIP
events that allows the subscriber to condition the subscription
request to whether the state has changed since the previous
notification was received. When such a condition is true, either the
body of a resulting event notification or the entire notification
message is suppressed.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 24, 2009. This Internet-Draft will expire on May 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
The Session Initiation Protocol (SIP) events framework enables This document may contain material from IETF Documents or IETF
receiving asynchronous notification of various events from other SIP Contributions published or made publicly available before November
user agents. This framework defines the procedures for creating, 10, 2008. The person(s) controlling the copyright in some of this
refreshing and terminating subscriptions, as well as fetching and material may not have granted the IETF Trust the right to allow
periodic polling of resource state. These procedures provide no modifications of such material outside the IETF Standards Process.
tools to avoid replaying event notifications that have already been Without obtaining an adequate license from the person(s) controlling
received by a user agent. This memo defines an extension to SIP the copyright in such materials, this document may not be modified
events that allows the subscriber to condition the subscription outside the IETF Standards Process, and derivative works of it may
request to whether the state has changed since the previous not be created outside the IETF Standards Process, except to format
notification was received. When such a condition is true, either the it for publication as an RFC or to translate it into languages other
body of a resulting event notification or the entire notification than English.
message is suppressed.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Document Conventions . . . . . . . . . . . . . . . . . . . 5 1.1. Document Conventions . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Motivations and Background . . . . . . . . . . . . . . . . . . 5 2. Motivations and Background . . . . . . . . . . . . . . . . . . 5
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Problem Description . . . . . . . . . . . . . . . . . . . 5 2.2. Problem Description . . . . . . . . . . . . . . . . . . . 5
2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4. Resource Model for Entity-Tags . . . . . . . . . . . . . . . . 11 4. Resource Model for Entity-Tags . . . . . . . . . . . . . . . . 10
5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . 14 5.2. Generating SUBSCRIBE Requests . . . . . . . . . . . . . . 13
5.3. Receiving NOTIFY Requests . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . 16
5.6. Refreshing a Subscription . . . . . . . . . . . . . . . . 18 5.6. Refreshing a Subscription . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Generating Entity-tags . . . . . . . . . . . . . . . . . . 20 6.1. Generating Entity-tags . . . . . . . . . . . . . . . . . . 19
6.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 20 6.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 20
6.3. Suppressing NOTIFY Requests . . . . . . . . . . . . . . . 21 6.3. Suppressing NOTIFY Requests . . . . . . . . . . . . . . . 20
6.4. State Differentials . . . . . . . . . . . . . . . . . . . 21 6.4. State Differentials . . . . . . . . . . . . . . . . . . . 21
6.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 21 6.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 21
7. Protocol Element Definitions . . . . . . . . . . . . . . . . . 22 7. Protocol Element Definitions . . . . . . . . . . . . . . . . . 21
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 . . . . . . . . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
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
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
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 of 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
skipping to change at page 4, line 38 skipping to change at page 4, line 38
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 in 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 almost identical to that entity-tag was issued. The solution is similar to conditional
conditional requests defined in the HyperText Transfer Protocol requests defined in the Hypertext Transfer Protocol (HTTP) [RFC2616],
(HTTP) [RFC2616], and follows the mechanism already defined for the and follows the mechanism already defined for the PUBLISH [RFC3903]
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.
skipping to change at page 5, line 27 skipping to change at page 5, line 27
the objects of conditional notification: 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 using the SIP Event Notification framework. There is a accessed using the SIP Event Notification framework. There is a
single authoritative notifier responsible for communicating the single authoritative notifier responsible for communicating the
resource state. resource state.
entity entity
The representation of resource state. An entity consists of the The representation of resource state. An entity consists of the
event 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.
2. Motivations and Background 2. Motivations and Background
2.1. Overview 2.1. Overview
A SUBSCRIBE request creates a subscription with a finite lifetime. A SUBSCRIBE request creates a subscription with a finite lifetime.
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
In spite of being somewhat distinct operations, the SIP events The SIP events framework does not include different protocol methods
framework does not include different protocol methods for initiating for initiating and terminating of subscriptions, subscription
and terminating of subscriptions, subscription refreshes and fetches refreshes and fetches inside and outside of the SIP dialog. The
inside and outside of the SIP dialog. Instead, the SUBSCRIBE method SUBSCRIBE method is overloaded to perform all of these functions The
is overloaded to perform all of these functions, and the notifier difference between a fetch that does not create a (lasting)
behavior is identical in each of them; each SUBSCRIBE request subscription, and a SUBSCRIBE that creates one is in the Expires
generates a NOTIFY request containing the latest resource state. In header field value of the SUBSCRIBE; a zero-expiry SUBSCRIBE only
fact, the only difference between a fetch that does not create a generates a single NOTIFY, after which the subscription immediately
(lasting) subscription, and a SUBSCRIBE that creates one is in the terminates. Lasting subscriptions typically have relatively short
Expires header field value of the SUBSCRIBE; a zero-expiry SUBSCRIBE expiry periods, requiring periodic sending of new SUBSCRIBE requests
only generates a single NOTIFY, after which the subscription in order to refresh 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 Each new SUBSCRIBE request generates a NOTIFY request containing the
well. As a benchmark, if we look at the performance of HTTP latest resource state. Even if the state has not changed, it is sent
[RFC2616] in similar scenarios, it performs substantially better again in response to each poll or subscription refresh. This is very
using conditional requests. When resources are tagged with an similar to the HTTP [RFC2616] problem of repeated GET operations on a
entity-tag, and each GET is a conditional one using the "If-None- resource. HTTP solves the problem using conditional requests. The
Match" header field, the entity body need not be sent more than once; server versions each entity with an entity tag that identifies a
if the resource has not changed between successive polls, an error specific instance of that entity. Clients making GET requests can
response is returned indicating this fact, and the resource entity is then include the entity tag for the version of the entity that they
not transmitted again. currently to be current in an "If-None-Match" header field, and the
server can compare this entity tag to the entity it believes to be
current and suppress resending the entity in the response if the
server believes the client's version matches. In other words, the
server doesn't re-send information that the client has already
received.
The SIP PUBLISH [RFC3903] method also contains a similar feature, The SIP PUBLISH [RFC3903] method uses a similar mechanism, where a
where a refresh of a publication is done by reference to its assigned refresh of a publication is done by reference to its assigned entity-
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 the latest event state of the resource. in possession of (or has previously received and discarded)
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. 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 RFC3261 [RFC3261], RFC3265 notifier normally, i.e., according to The Session Initiation Protocol
[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 a unique entity tag for the event subscriptions, it generates an entity tag for the current entity, and
notification, and includes it in a SIP-ETag header field of the includes it in a SIP-ETag header field of the NOTIFY request. The
NOTIFY request. The entity tag is unique across all versions of all entity tag is unique across all versions of all entities for a
entities for a resource and event package. More on this in resource and event package. More on this in Section 4.
Section 4.
Entity-tags are independent of subscriptions; the notifier remembers Entity-tags are independent of subscriptions. This allows
the entity-tags of all versions of entities for a resource regardless notifications generated to a fetch or a poll to have valid entity-
of whether or not there are any active subscription to that resource. tags even across subsequent fetches or polls.
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 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 by the subscriber. This condition, if true, instructs the seen by the subscriber. This condition, if true, instructs the
notifier to suppress either the body of a subsequent notification, or notifier to suppress either the body of a subsequent notification, or
the entire notification. the 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 current entity-tag of the resource state. There is also against the entity-tag of the entity that would normally be sent in
a wildcard entity-tag with a special value of "*" that always the associated NOTIFY message. There is also a wildcard entity-tag
matches. with a special value of "*" that always matches.
Subscriber Notifier Subscriber Notifier
---------- -------- ---------- --------
(1) SUBSCRIBE --------> (1) SUBSCRIBE -------->
Expires: 3600 Expires: 3600
<-------- (2) 200 (or 202) <-------- (2) 200 (or 202)
<-------- (3) NOTIFY <-------- (3) NOTIFY
Subscription-State: active Subscription-State: active
skipping to change at page 9, line 26 skipping to change at page 8, line 26
... time passes ... ... time passes ...
(5) SUBSCRIBE --------> \ if "ffee2" (5) SUBSCRIBE --------> \ if "ffee2"
Suppress-If-Match: ffee2 | matches Suppress-If-Match: ffee2 | matches
Expires: 3600 | local Expires: 3600 | local
| entity-tag | entity-tag
| |
<-------- (6) 204 / then <-------- (6) 204 / then
... time passes ... ... time passes and resource state (entity) changes...
<-------- (7) NOTIFY <-------- (7) NOTIFY
Subscription-State: active Subscription-State: active
SIP-ETag: ca89a SIP-ETag: ca89a
(8) 200 --------> (8) 200 -------->
... time passes ... ... time passes ...
(9) SUBSCRIBE --------> \ if "ca89" (9) SUBSCRIBE --------> \ if "ca89"
Suppress-If-Match: ca89a | matches Suppress-If-Match: ca89a | matches
skipping to change at page 12, line 25 skipping to change at page 11, line 25
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.
This representation is realized in what is called an entity. Each This representation is realized in an "entity". Each resource may be
resource may be associated with zero or more entities; however, an associated with zero or more entities. For example, there may be
entity is only valid for a single resource. multiple subscribers to the presence information of a single user (a
resource), and each subscriber may have a different filtered view of
Note that, as can be seen from the illustration, the association that resource, producing one entity per subscriber. However, each
between a resource and an entity follows the typical composition entity is associated with one and only one resource; there is no
relationship, i.e., an entity may belong to only one resource, and "compositing" of resources at the entity level. Resources may
it is expected to only exist with that resource. themselves be made up of information from other resources (be
"composite resources"), but this does not change the one-resource-
per-entity rule.
An entity consists of the data carried in the body of a NOTIFY 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 message, and related meta-data in the message header. Whenever the
includes, but is not limited to the following SIP header fields: data in the body or any of the meta-data changes, the notifier MUST
produce a new entity-tag. This meta-data MUST include, but is not
limited to the following SIP header fields defined in The Session
Initiation Protocol [RFC3261] and SIP Specific Event Notification
[RFC3265]:
entity-header = Content-Disposition ; defined in RFC 3261 1. Content-Disposition
/ Content-Encoding ; defined in RFC 3261
/ Content-Language ; defined in RFC 3261 2. Content-Encoding
/ Content-Length ; defined in RFC 3261
/ Content-Type ; defined in RFC 3261 3. Content-Language
/ Event ; defined in RFC 3265
/ extension-header ; defined in RFC 3261 4. Content-Length
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. Event packages may in the future 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 being equal does not indicate identical Note that two entity-tags for different resources being equal does
entities. In other words, if an entity-tag is received that matches not indicate identical entities. In other words, if an entity-tag
a previously seen entity-tag, the subscriber cannot assume the event received for a subscription to a first resource matches an entity-tag
state to be identical to that received earlier. received for a subscription to a second resource, the subscriber
cannot assume that the two entity values are equal.
With partial event notification, the NOTIFY message only carries the With partial event notification, the NOTIFY message only carries the
delta state, or the set of changes to the previous version of the delta state, or the set of changes to the previous version of the
entity. In that case, implementations MUST consider the full event entity. In that case, implementations MUST consider the full event
state as the version of the entity to which the entity-tag in the state as the version of the entity to which the entity-tag in the
NOTIFY message applies. NOTIFY message applies.
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
skipping to change at page 14, line 41 skipping to change at page 14, line 6
body of any subsequent NOTIFY request. 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
behaviour. behaviour.
If the subscriber receives a 204 (No Notification) to an in-dialog If the subscriber receives a 204 (No Notification) to an in-dialog
SUBSCRIBE, the subscriber can clear handle that it may have had SUBSCRIBE, the subscriber can clear handle that it may have had
pending on a NOTIFY in response the SUBSCRIBE message. pending on a NOTIFY in response the SUBSCRIBE message.
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 from a which is an opaque token that the subscriber simply copies (bytewise)
previously received NOTIFY request. from a previously received NOTIFY request.
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:
skipping to change at page 15, line 32 skipping to change at page 14, line 46
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
of the conditional notification mechanism. The subscriber MUST be of the conditional notification mechanism. The subscriber MUST be
prepared to receive a NOTIFY with any entity-tag value, including a prepared to receive a NOTIFY with any entity-tag value, including a
value that matches any previous value that the subscriber might have value that matches any previous value that the subscriber might have
seen. seen.
The subscriber MUST NOT infer any meaning from the value of an The subscriber MUST NOT infer any meaning from the value of an
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. values when those NOTIFYs result from subscription to different
resources.
Note that there are valid cases for which identical entity-tag Note that there are valid cases for which identical entity-tag
values indeed imply identical event state. 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. function, resulting in the possibility that two different
resources having the same entity-value will also have the same
entity tag. Clients however MUST NOT assume that this is the
case, as the algorithm for the generation of entity tags is
notifier-dependent and not negotiated with the subscriber.
Consequently, the subscriber cannot differentiate between two
entity tags that have the same value because they are similar
hashes of identical entities, or because two notifiers happen to
have used the same sequential number as an entity tag. Entity
tags are only required to be unique for a given resource, not
globally unique.
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 17, line 10 skipping to change at page 16, line 23
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 the
entity-tag received in the previous NOTIFY. 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. response. (202 would be used to indicate that the subscription
request was understood without also indicating that it was
authorized, as per section 3.1.6.1 of SIP Specific Event
Notification" [RFC3265].)
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
skipping to change at page 18, line 18 skipping to change at page 17, line 41
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 is subscriber creates a subscription refresh before the subscription
about to expire, and uses the Suppress-If-Match header field: expires, and uses the Suppress-If-Match header field:
Subscriber Notifier Subscriber Notifier
---------- -------- ---------- --------
(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 is about to expire, the subscriber sends 1. Before the subscription expires, the subscriber sends a SUBSCRIBE
a SUBSCRIBE request that includes the Suppress-If-Match header request that includes the Suppress-If-Match header field with the
field with the latest entity-tag it has seen. 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) indicates the new
expiry time. 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
skipping to change at page 20, line 7 skipping to change at page 19, line 32
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 RFC3265
[RFC3265]. [RFC3265].
6.1. Generating Entity-tags 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 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.
An entity-tag is considered valid for as long as the entity is valid. 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 each state of a resource as
reported by a given event package. Otherwise said, for any
subscription or sequence of subscriptions to a specific resource
using a singular event package, each entity tag produced MUST map to
one and only one presentation of resource state (entity). Two
identical entities for a specific resource might or might not have
identical entity tags; this decision is left to the notifier.
An entity-tag is considered valid for as long as the entity exits.
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 the entity-tag of an entity as long one. The notifier MUST remember (or be able to recalculate) the
as the version of the entity is current. The notifier MAY remember entity-tag of an entity as long as the version of the entity is
the entity-tag longer than this, e.g., for implementing journaled current. The notifier MAY remember the entity-tag longer than this,
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; there may be several sources to the event and a notification of state change; there may be several sources to
composition process. the event composition process, and a publication into a resource may
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 match) but there are entity-tag in a Suppress-If-Match header field are byte-wise
reportable changes in the NOTIFY header (e.g., the Subscription-State identical) but there are reportable changes in the NOTIFY header
has changed), the notifier MUST suppress the body of the NOTIFY (e.g., the Subscription-State has changed), the notifier MUST
request. That is, the resulting NOTIFY contains no Content-Type suppress the body of the NOTIFY request. That is, the resulting
header field, the Content-Length is set to zero, and no payload is NOTIFY contains no Content-Type header field, the Content-Length 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.
skipping to change at page 21, line 35 skipping to change at page 21, line 20
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 may support a scheme where notifications contain Some event packages may 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.
A notifier can optionally keep track of the state changes of a An event package definition MAY allow a notifier to keep track of the
resource, e.g., storing the changes in a journal. If a condition state changes of a resource, e.g., storing the changes in a journal.
fails, the notifier MAY send a state differential in the NOTIFY If a condition fails, the notifier MAY then send a state differential
rather than the full state of the event resource. This is only in the NOTIFY rather than the full state of the event resource. This
possible if the event package and the subscriber both support a is only possible if the event package and the subscriber both support
payload format that has this capability. 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
contain an entity-tag that corresponds to the full resource state. contain an entity-tag that corresponds to the full resource state.
6.5. List Subscriptions 6.5. List Subscriptions
The Event Notification Extension for Resource Lists [RFC4662] defines The Event Notification Extension for Resource Lists [RFC4662] defines
a mechanism for subscribing to a homogeneous list of resources using a mechanism for subscribing to a homogeneous list of resources using
the SIP events framework. the SIP events framework.
skipping to change at page 25, line 31 skipping to change at page 25, line 5
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session [RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004. Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3859] Peterson, J., "Common Profile for Presence (CPP)", [RFC3859] Peterson, J., "Common Profile for Presence (CPP)",
RFC 3859, August 2004. RFC 3859, August 2004.
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006. Resource Lists", RFC 4662, August 2006.
Author's Address 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)
Softarmor Systems
3100 Independence Pkwy #311-164
Plano, TX 75075
USA
Phone: +1 214 504 1987
Email: dean.willis@softarmor.com
 End of changes. 47 change blocks. 
176 lines changed or deleted 192 lines changed or added

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