One document matched: draft-ietf-sip-subnot-etags-02.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc sortrefs="yes"?>
<?rfc linkmailto="yes"?>
<?rfc strict="no"?>
<?rfc subcompact="no"?>
<rfc ipr="full3978" category="std" docName="draft-ietf-sip-subnot-etags-02">
<!-- ************************************************************** -->
<!-- The FRONT section includes the title, date, authors names and -->
<!-- addresses, abstract etc. Some of the stuff, like TOC, expiration -->
<!-- date and the rest are automatically generated by the conversion -->
<!-- tools (e.g., xml2rfc) -->
<!-- ************************************************************** -->
<front>
<title abbrev="Entity-tags for SIP Events">An Extension to Session
Initiation Protocol (SIP) Events for Conditional Event Notification</title>
<author initials="A" surname="Niemi" fullname="Aki Niemi">
<organization>Nokia</organization>
<address>
<postal>
<street>P.O. Box 407</street>
<city>NOKIA GROUP</city> <region>FIN</region> <code>00045</code>
<country>Finland</country>
</postal>
<phone>+358 50 389 1644</phone>
<email>aki.niemi@nokia.com</email>
</address>
</author>
<date month="February" year="2008" />
<area>Real-Time Applications and Infrastructure</area>
<workgroup>Session Initiation Protocol Working Group</workgroup>
<keyword>I-D</keyword>
<keyword>RFC</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Request For Comments</keyword>
<keyword>SIP events</keyword>
<keyword>subnot-etags</keyword>
<keyword>optimization</keyword>
<abstract>
<t>
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 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.
</t>
</abstract>
</front>
<!-- ************************************************************** -->
<!-- The MIDDLE section includes the actual draft contents -->
<!-- ************************************************************** -->
<middle>
<!-- Introduction -->
<section anchor="intro" title="Introduction">
<t>
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.
</t>
<t>
Several instantiations of this framework, called event
packages have been defined, e.g., for <xref
target="RFC3856">presence</xref>, <xref target="RFC3842">message
waiting indications</xref> and <xref
target="RFC3680">registrations</xref>.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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 <xref
target="RFC2616">HyperText Transfer Protocol (HTTP)</xref>,
and follows the mechanism already defined for the <xref
target="RFC3903">PUBLISH</xref> method for issuing conditional
event publications.
</t>
<t>
This memo is structured as follows. <xref target="motivations"
/> explains the background, motivations and requirements for
the work; <xref target="operation" /> gives a general overview
of the mechanism; <xref target="model" /> explains the
underlying model for resources and entities as they apply to
conditional notification; <xref target="subscriber" /> defines
the subscriber behavior; <xref target="notifier" /> defines
the notifier behavior; <xref target="proto" /> includes the
protocol element definitions; <xref target="iana" /> includes
the IANA considerations; and <xref target="security" />
includes the security considerations.
</t>
<section title="Document Conventions">
<t>
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, <xref target="RFC2119">RFC 2119</xref> and indicate
requirement levels for compliant implementations.
</t>
</section>
<section title="Terminology">
<t>
In addition to the terminology introduced in <xref
target="RFC3261" />, <xref target="RFC3265" /> and <xref
target="RFC3903" />, this specification uses these
additional terms to describe the objects of conditional
notification:
<list style="hanging">
<t hangText="resource">
<vspace blankLines="0" />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.
</t>
<!-- Deleted <t hangText="representation">
<vspace blankLines="0" />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.
</t>-->
<t hangText="entity">
<vspace blankLines="0" />The representation of resource
state. An entity consists of the event data carried in
the body of a NOTIFY message, as well as related
meta-data in the message header. There may be many
versions of an entity, one current and the others
stale. Each version of an entity is identified by an
entity-tag, which is guaranteed to be unique across all
versions of all entities for a resource and event
package.
</t>
</list>
</t>
</section>
</section>
<section anchor="motivations" title="Motivations and Background">
<section anchor="overview" title="Overview">
<t>
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.
</t>
</section>
<section title="Problem Description">
<t>
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.
</t>
<t>
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.
</t>
<t>
There are certain conditions that aggravate the
problem. Such conditions usually entail such things as:
<list style="symbols">
<t>Large entity bodies in the payloads of notifications</t>
<t>High rate of subscription refreshes</t>
<t>Relatively low rate of notifications triggered by state
changes</t>
</list>
</t>
<t>
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.
</t>
<t>
The same problem affects fetching and polling of resource
state as well. As a benchmark, if we look at the performance
of <xref target="RFC2616">HTTP</xref> 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.
</t>
<t>
The <xref target="RFC3903">SIP PUBLISH</xref> 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.
</t>
</section>
<section title="Requirements">
<t>
As a summary, here is the required functionality to solve
the presented issues:
<list style="format REQ%d: ">
<t>
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.
</t>
<t>
This mechanism must apply to initial subscriptions, in
which the subscriber is attempting to "resume" an earlier
subscription.
</t>
<t>
This mechanism must apply to refreshing a subscription.
</t>
<t>
This mechanism must apply to terminating a subscription
(i.e., an unsubscribe).
</t>
<t>
This mechanism must apply to fetching or polling of
resource state.
</t>
</list></t>
</section>
</section>
<section anchor="operation" title="Overview of Operation">
<t>
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 <xref
target="RFC3261">RFC3261</xref>, <xref
target="RFC3265">RFC3265</xref>.
</t>
<t>
If the notifier receiving the SUBSCRIBE request supports
conditional subscriptions, it generates a unique entity tag
for the event notification, and includes it in a SIP-ETag
header field of the NOTIFY request. The entity tag is unique
across all versions of all entities for a resource and event
package. More on this in <xref target="model" />.
</t>
<t>
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.
</t>
<t>
The subscriber will store the entity-tag received in the
notification along with the resource state. It can then later
use this entity-tag to make a SUBSCRIBE contain a condition in
the form of a "Suppress-If-Match" header field. Unlike the
"If-Match" condition in
a <xref target="RFC3903">PUBLISH</xref> request, which applies
to whether the PUBLISH succeeds or returns an error, this
condition applies to the stream of notifications that are sent
after the SUBSCRIBE request has been processed.
</t>
<t>
The "Suppress-If-Match" header field contains the last
entity-tag seen by the subscriber. This condition, if true,
instructs the notifier to suppress either the body of a
subsequent notification, or the entire notification.
</t>
<t>
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.
</t>
<figure anchor="ov" title="Example Message Flow">
<artwork><![CDATA[
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Expires: 3600
<-------- (2) 200 (or 202)
<-------- (3) NOTIFY
SIP-ETag: ffee2
(4) 200 -------->
... time passes ...
(5) SUBSCRIBE --------> \ if "ffee2"
Suppress-If-Match: ffee2 | matches
Expires: 3600 | local
| entity-tag
|
<-------- (6) 204 / then
... time passes ...
<-------- (7) NOTIFY
SIP-ETag: ca89a
(8) 200 -------->
... time passes ...
(9) SUBSCRIBE --------> \ if "ca89"
Suppress-If-Match: ca89a | matches
Expires: 0 | local
| entity-tag
|
<-------- (10) 204 / then
]]></artwork>
</figure>
<t>
<xref target="ov"/> describes a typical message flow for conditional
notification:
<list style="numbers">
<t>
The subscriber initiates a subscription by sending a
SUBSCRIBE request for a resource.
</t>
<t>
After proper authentication and authorization, the
notifier accepts the subscription.
</t>
<t>
The notifier then immediately sends the initial event
notification, including a unique entity-tag in a SIP-ETag
header field.
</t>
<t>
The subscriber accepts the notification and stores the
entity-tag value along with the resource state.
</t>
<t>
Later, the subscriber refreshes the subscription, and
includes an entity-tag in a Suppress-If-Match header
field.
</t>
<t>
The notifier evaluates the condition by matching its local
entity-tag value for the resource against the value of the
Suppress-If-Match header field. If the condition evaluates
to true, the notifier informs the subscriber that the
notification will not be sent.
</t>
<t>
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.
</t>
<t>
The subscriber accepts the notification and stores the new
entity-tag along with the resource state.
</t>
<t>
After a while, the subscriber decides to terminate the
subscription. It adds a condition for Suppress-If-Match,
and includes the entity-tag it received in the previous
NOTIFY.
</t>
<t>
The notifier evaluates the condition by matching its
entity-tag for the resource against the value of the
Suppress-If-Match header field. If the condition
evaluates to true, the notifier informs the subscriber
that no notification will be sent. This concludes the
subscription.
</t>
</list>
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.
</t>
</section>
<section anchor="model" title="Resource Model for Entity-Tags">
<t>
The key to understanding how conditional notification works is
understanding the underlying resource model of event
notification. In general, this model is similar to the
resource model of HTTP with some key differences. This section
explains in detail the model as it applies to SIP
events. <xref target="diagram" /> illustrates the model.
</t>
<figure anchor="diagram" title="Resource Model Diagram">
<artwork><![CDATA[
+-----+
............ | |
. . | URI |
. Represen . | |
. tation . +-----+
. . |*
............ |
. |
. V
. +----------+ +---------+
composition | |* | Event |
+------<>| Resource |----------->| Package |<----.
| | | | | |
| +----------+ +----.----+ |
| /_\ |
|* | classification
+--------+ | |
| | .----------------.------' |
| Entity | | | |
| | | | |*
+--------+ +----------+ +------------+ +----------+
^ | | | | | |
| | Presence | | Conference | | Template |
| | | | | | |
|1..* +----------+ +------------+ +----.-----+
+---------+ /_\
| | |
| Version | |
| | +---------+
+---------+ | Watcher |
|1 | Info |
| | |
| +---------+
V
+---------+
| Entity- |
| Tag |
| |
+---------+
]]></artwork>
</figure>
<t>
For a given event package, there is a single authoritative
agent responsible for zero or more resources. That is, even
for a distributed agent, the resource state is uniform across
all instances. The resource itself can be a <xref
target="RFC4662">list of resources</xref>. Conditional
notification for list subscriptions is addressed in <xref
target="rls" />.
</t>
<t>
A resource is identified by zero or more URIs, which can be
SIP URIs, <xref target="RFC3859">pres URIs</xref> or
similar. Subscribers use this URI to subscribe to the resource
for certain types of events, identified by the event package.
</t>
<t>
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.
</t>
<t>
This representation is realized in what is called an entity.
Each resource may be associated with zero or more entities;
however, an entity is only valid for a single resource.
<list style="empty">
<t>
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.
</t>
</list>
</t>
<t>
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:
</t>
<figure>
<artwork type="abnf"><![CDATA[
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
]]></artwork>
</figure>
<t>
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.
</t>
<t>
An entity has one or more versions of which only one is
current and all others stale. Each version has an entity-tag,
which uniquely identifies it across all versions of all
entities pertaining to a single resource and event package.
</t>
<t>
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.
</t>
<t>
The conditional notification mechanism is independent of the
way in which subscriptions are installed. In other words, the
mechanism supports implicit subscriptions, such as those
associated with the <xref target="RFC3515">REFER
method</xref>.
</t>
<t>
It is possible that the same resource is in some shape or form
accessible through another mechanism in addition to SIP Event
Notification, e.g., HTTP or the SIP PUBLISH method. In
general, implementations MUST NOT expect the entity-tags to be
shared between the mechanisms, unless event packages or
specific applications of SIP Events explicitly define such
dependencies.
</t>
</section>
<section anchor="subscriber" title="Subscriber Behavior">
<t>
This section augments the subscriber behavior defined in
<xref target="RFC3265">RFC3265</xref>. It first discusses
general issues related to <xref target="subs_support">indicating
support for the mechanism</xref> and <xref
target="subs_gen">creating conditions in SUBSCRIBE
requests</xref>; it then describes the workflows for the
main three use cases for making the subscription
conditional.
</t>
<section anchor="subs_support" title="Detecting Support for
Conditional Notification">
<t>
The mechanism defined in this memo is backwards compatible
with <xref target="RFC3265">SIP events</xref> in that a
notifier supporting this mechanism will insert a SIP
entity-tag in its NOTIFY requests, and a subscriber that
understands this mechanism will know how to use it in
creating a conditional request.
</t>
<t>
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.
</t>
</section>
<section anchor="subs_gen" title="Generating SUBSCRIBE Requests">
<t>
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.
</t>
<t>
Unlike the condition introduced for
the <xref target="RFC3903">SIP PUBLISH</xref> method,
these conditions do not apply to the SUBSCRIBE request
itself, but to the resulting NOTIFY requests. When true,
the condition drives the notifier to change its behavior
with regards to sending the notifications after the
SUBSCRIBE.
</t>
<t>
This specification defines a new header field called
"Suppress-If-Match". This header field introduces a
condition to the SUBSCRIBE request. If true, it instructs
the notifier to suppress (i.e., block) the first NOTIFY
request following the SUBSCRIBE, and return a 204 (No
Notification) response to the SUBSCRIBE request. As long
as the condition remains true, it also instructs the
notifier to either suppress any subsequent NOTIFY request,
or if there are reportable changes in the NOTIFY header,
e.g., the Subscription-State has changed, suppress the
body of any subsequent NOTIFY request.
</t>
<t>
If the condition is false, the notifier follows its
default behaviour.
</t>
<t>
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 subscription.
</t>
<t>
The value of the "Suppress-If-Match" header field is an
entity-tag, which is an opaque token that the subscriber
simply copies from a previously received NOTIFY request.
</t>
<t>
Example:
<list style="empty">
<t>Suppress-If-Match: b4cf7</t>
</list>
</t>
<t>
The header field can also be wildcarded using the special
"*" entity-tag value. Such a condition always evaluates to
true regardless of the value of the current entity-tag for
the resource.
</t>
<t>
Example:
<list style="empty">
<t>Suppress-If-Match: *</t>
</list>
</t>
<t>
Such a wildcard condition effectively quenches a
subscription; the only notifications received are those
reporting changes to the subscription state. Such
notifications will also not contain a body.
<list style="empty">
<t>
A subscription with a wildcard "Suppress-If-Match"
condition is useful in scenarios where the subscriber
wants to temporarily put a subscription in dormant
mode. For example, a host may want to conserve
bandwidth and power when it detects from screen or
input device inactivity that the user isn't actively
monitoring the presence statuses of buddies.
</t>
</list>
</t>
</section>
<section title="Receiving NOTIFY Requests">
<t>
When a subscriber receives a NOTIFY request that contains
a SIP-ETag header field, it MUST store the entity-tag if
it wishes to make use of the conditional notification
mechanism. The subscriber MUST be prepared to receive a
NOTIFY with any entity-tag value, including a value that
matches any previous value that the subscriber might have
seen.
</t>
</section>
<section title="Polling or Fetching Resource State">
<t>
Polling with conditional notification allows a user agent
to efficiently poll resource state. This is accomplished
using the Suppress-If-Match condition:
</t>
<figure anchor="fig_poll" title="Polling Resource State">
<artwork><![CDATA[
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Expires: 0
<-------- (2) 202
<-------- (3) NOTIFY
SIP-ETag: f2e45
(4) 200 -------->
... poll interval elapses ...
(5) SUBSCRIBE -------->
Suppress-If-Match: f2e45
Expires: 0
<-------- (6) 204
]]></artwork>
</figure>
<t>
<list style="numbers">
<t>The subscriber polls for resource state by sending a
SUBSCRIBE with zero expiry (expires immediately).</t>
<t>The notifier accepts the SUBSCRIBE with a 202 (Accepted)
response.</t>
<t>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.</t>
<t>The subscriber accepts the notification with a 200 (OK)
response.</t>
<t>After some arbitrary poll interval, the subscriber
sends another SUBSCRIBE with a Suppress-If-Match
header field that includes the entity-tag received in
the previous NOTIFY.</t>
<t>Since the resource state has not changed since the
previous poll occurred, the notifier sends a 204 (No
Notification) response, which concludes the poll.</t>
</list>
</t>
</section>
<section anchor="subs_resume" title="Resuming a Subscription">
<t>
Resuming a subscription means the ability to continue an
earlier subscription that either closed abruptly, or was
explicitly terminated. When resuming, the subscription is
established without transmitting the resource state. This
is accomplished with conditional notification and the
Suppress-If-Match header field:
</t>
<figure anchor="fig_resume" title="Resuming a Subscription">
<artwork><![CDATA[
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: ega23
Expires: 3600
<-------- (2) 202
<-------- (3) NOTIFY
Subscription-State: active
SIP-ETag: ega23
Content-Length: 0
(4) 200 -------->
]]></artwork>
</figure>
<t>
<list style="numbers">
<t>The subscriber attempts to resume an earlier
subscription by including a Suppress-If-Match
header field with the entity-tag it last received.</t>
<t>The notifier accepts the subscription after proper
authentication and authorization, by sending a 202
(Accepted) response.</t>
<t>Since the condition is true, the notifier then
immediately sends an initial NOTIFY request that has no
body. It also mirrors the current entity-tag of the
resource in the SIP-ETag header field.</t>
<t>The subscriber accepts the NOTIFY and sends a 200 (OK)
response.</t>
</list>
</t>
<t>
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.
</t>
</section>
<section anchor="subs_refresh" title="Refreshing a
Subscription">
<t>
To refresh a subscription using conditional notification,
the subscriber creates a subscription refresh before the
subscription is about to expire, and uses the
Suppress-If-Match header field:
</t>
<figure anchor="fig_refresh" title="Refreshing a Subscription">
<artwork><![CDATA[
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: aba91
Expires: 3600
<-------- (2) 204
Expires: 3600
]]></artwork>
</figure>
<t>
<list style="numbers">
<t>Before the subscription is about to expire, the
subscriber sends a SUBSCRIBE request that includes the
Suppress-If-Match header field with the latest
entity-tag it has seen.</t>
<t>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.</t>
</list>
</t>
</section>
<section anchor="subs_terminate" title="Terminating a
Subscription">
<t>
To terminate a subscription using conditional
notification, the subscriber creates a SUBSCRIBE request
with a Suppress-If-Match condition:
</t>
<figure anchor="fig_terminate" title="Terminating a Subscription">
<artwork><![CDATA[
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: ega23
Expires: 0
<-------- (2) 204
]]></artwork>
</figure>
<t>
<list style="numbers">
<t>The subscriber decides to terminate the subscription
and sends a SUBSCRIBE request with the
Suppress-If-Match condition with the entity-tag
it has last seen.</t>
<t>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.</t>
</list>
</t>
</section>
<section anchor="error_conditions" title="Handling Transient Errors">
<t>
This section is non-normative.
</t>
<t>
In some deployments, there may be Back-to-Back
User Agent (B2BUA) devices that track SIP dialogs such as
subscription dialogs. These devices may be unaware of the
conditional notification mechanism.
</t>
<t>
It is possible that such B2BUAs always expect to see a
NOTIFY method to conclude the dialog establishment as
specified in <xref target="RFC3265">SIP Events</xref>, and
if this NOTIFY request is suppressed, may terminate or
block the subscription. Other problems may also arise,
e.g., it is possible that some B2BUA devices treat a
NOTIFY with suppressed body as an error.
</t>
<t>
In general, there is very little that an endpoint can do
to recover from such transient errors. The most that can
be done is to try to detect such errors, and define a fall
back behavior.
</t>
<t>
If subscribers encounter transient errors in conditional
notification, they should disable the feature and fall
back to normal subscription behavior.
</t>
</section>
</section>
<section anchor="notifier" title="Notifier Behavior">
<t>
This section augments the notifier behavior as specified in
<xref target="RFC3265">RFC3265</xref>.
</t>
<section anchor="generating" title="Generating Entity-tags">
<t>
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.
</t>
<t>
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.
</t>
<t>
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 <xref
target="differentials">journaled state
differentials</xref>.
</t>
<t>
The entity tag values used in publications are not
necessarily shared with the entity tag values used in
subscriptions. This is because there may not always be a
one-to-one mapping between a publication and a
notification; there may be several sources to the event
composition process.
</t>
</section>
<section anchor="suppressing" title="Suppressing NOTIFY Bodies">
<t>
When a condition in a SUBSCRIBE request for suppressing
notifications is true, i.e., the local entity-tag for the
resource state and the entity-tag in a Suppress-If-Match
header field match, but there are reportable changes in the
NOTIFY header, e.g., the Subscription-State has changed,
the notifier MUST suppress the body of the NOTIFY
request. That is, the resulting NOTIFY contains no
Content-Type header field, the Content-Length is set to
zero, and no payload is attached to the message.
</t>
<t>
Suppressing the entity body of a NOTIFY does not change the
current entity-tag of the resource. Hence, the NOTIFY MUST
contain a SIP-Etag header field that contains the unchanged
entity-tag of the resource state.
</t>
<t>
A Suppress-If-Match header field that includes an
entity-tag with the value of "*" MUST always evaluate to
true.
</t>
</section>
<section anchor="suppressing_request" title="Suppressing NOTIFY
Requests">
<t>
When a condition in a SUBSCRIBE request to suppress
notifications is true, i.e., the local entity-tag of the
resource and the entity-tag in a Suppress-If-Match header
field match, the notifier MUST suppress the resulting
NOTIFY request, and generate a 204 (No Notification)
response. As long as the condition remains true, and there
are no reportable changes in the NOTIFY header, all
subsequent NOTIFY requests MUST also be suppressed.
</t>
<t>
A successful conditional SUBSCRIBE request MUST extend the
subscription expiry time.
</t>
<t>
Suppressing the entire NOTIFY has no effect on the
entity-tag of the resource. In other words, it remains
unchanged.
</t>
<t>
A Suppress-If-Match header field that includes an
entity-tag with the value of "*" MUST always evaluate to
true.
</t>
</section>
<section anchor="differentials" title="State Differentials">
<t>
Some event packages may support a scheme where
notifications contain state differentials, or <xref
target="RFC3265">state deltas</xref> instead of complete
resource state.
</t>
<t>
A notifier can optionally keep track of the state changes
of a resource, e.g., storing the changes in a journal. If a
condition fails, the notifier MAY send a state differential
in the NOTIFY rather than the full state of the event
resource. This is only possible if the event package and
the subscriber both support a payload format that has this
capability.
</t>
<t>
When state differentials are sent, the SIP-ETag header
field MUST contain an entity-tag that corresponds to the
full resource state.
</t>
</section>
<section anchor="rls" title="List Subscriptions">
<t>
The <xref target="RFC4662">Event Notification Extension for
Resource Lists</xref> defines a mechanism for subscribing
to a homogeneous list of resources using the SIP events
framework.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section anchor="proto" title="Protocol Element Definitions">
<t>
This section describes the protocol extensions required for
conditional notification.
</t>
<section anchor="proto_resp" title="204 (No Notification)
Response Code">
<t>
The 204 (No Notification) response code indicates that
the request was successful, but the notification associated
with the request will not be sent.
</t>
<t>
The response code is added to the "Success" production rule
in the <xref target="RFC3261">SIP</xref> message grammar.
</t>
</section>
<section anchor="proto_header" title="Suppress-If-Match
Header Field">
<t>
The Suppress-If-Match header field is added to the
definition of the "message-header" rule in
the <xref target="RFC3261">SIP</xref> grammar. Its use is
described in <xref target="subscriber" />,
<xref target="suppressing_request" /> and
<xref target="suppressing" />.
</t>
<t>
This header field is allowed to appear in any
request, but its behavior is only defined for the
SUBSCRIBE request.
</t>
</section>
<section anchor="proto_grammar" title="Grammar">
<t>
This section defines the formal syntax for extensions
described in this memo in <xref target="RFC4234">Augmented
BNF (ABNF)</xref>. The rules defined here augment and
reference the syntax defined in <xref
target="RFC3261">RFC3261</xref> and <xref
target="RFC3903">RFC3903</xref>.
</t>
<figure>
<artwork type="abnf"><![CDATA[
Success =/ "204" ; No Notification
; Success is defined in RFC3261.
message-header =/ Suppress-If-Match
; message-header is defined in RFC3261.
Suppress-If-Match = "Suppress-If-Match" ":" entity-tag / "*"
; entity-tag is defined in RFC3903.
]]></artwork>
</figure>
</section>
</section>
<!--
<section title="Examples">
<t>
FIXME: Add examples
</t>
<t>
In these examples, simple message exchange between a
subscriber (S:) and a notifier (N:) is shown. Note that the
messages use addresses from a <xref target="RFC3330">special
block of the IPv4 address space dedicated for
documentation</xref>.
</t>
<section title="Initial Subscription">
<t>S:</t>
<figure>
<artwork><![CDATA[
SUBSCRIBE sip:alice@example.net SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:5060;rport \
;branch=z9hG4bK5Q96v7g0K6ZKj
Max-Forwards: 70
From: <sip:192.0.2.1:5060>;tag=51y690065yQeN
To: <sip:alice@example.net>
Call-ID: 984b6db8-4101-122a-83be-001641a9e6ae
CSeq: 80171475 SUBSCRIBE
Contact: <sip:192.0.2.1:5060;transport=tcp>
Expires: 3600
User-Agent: example/1.0
Accept: application/pidf+xml;q=0.5, \
application/pidf-partial+xml
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, \
MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE
Event: presence
Content-Length: 0
]]></artwork>
</figure>
<t>N:</t>
<figure>
<artwork><![CDATA[
]]></artwork>
</figure>
<t>N:</t>
<figure>
<artwork><![CDATA[
]]></artwork>
</figure>
<t>S:</t>
<figure>
<artwork><![CDATA[
]]></artwork>
</figure>
</section>
<section title="Subscription Resume">
<t>
In this example, the subscriber resumes a subscription
that was previously terminated.
</t>
<t>S:</t>
<figure>
<artwork><![CDATA[
SUBSCRIBE sip:alice@example.net SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:5060;rport \
;branch=z9hG4bK5Q96v7g0K6ZKj
Max-Forwards: 70
From: <sip:192.0.2.1:5060>;tag=51y690065yQeN
To: <sip:alice@example.net>
Call-ID: 984b6db8-4101-122a-83be-001641a9e6ae
CSeq: 80171475 SUBSCRIBE
Contact: <sip:192.0.2.1:5060;transport=tcp>
Expires: 3600
User-Agent: example/1.0
Accept: application/pidf+xml;q=0.5, \
application/pidf-partial+xml
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, \
MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE
Event: presence
SIP-Etag: 7bbfd2
Content-Length: 0
]]></artwork>
</figure>
<t>N:</t>
<figure>
<artwork><![CDATA[
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
]]></artwork>
</figure>
</section>
<section title="Subscription Refresh">
<t>TODO</t>
</section>
<section title="Subscription Termination">
<t>TODO</t>
</section>
</section>
-->
<!-- No longer necessary
<section title="Open Issues and Todo">
<t>
<list style="symbols">
<t>
The applicability of subnot-etags to RLS subscriptions
should be clarified. In particular, how does the
entity-tag relate to RLMI vs. the resource state?
</t>
<t>
Should add detailed examples of all of the different use
cases for conditional notification presented in this
document.
</t>
</list>
</t>
</section>
-->
<section anchor="iana" title="IANA Considerations">
<t>This document registers a new response code and a new
header field name.</t>
<t><list style="empty">
<t>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.</t>
</list>
</t>
<!-- Deleted
<section title='"subnot-etags" Option Tag'>
<t>
This document registers a new SIP option tag. This option
tag is defined by the following information, which has been
added to the option-tags sub-registry under
http://www.iana.org/assignments/sip-parameters.
<texttable>
<ttcol align="left">Name</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>subnot-etags</c>
<c>This option tag indicates support for
entity-tags and conditional notifications in SIP
events.</c>
<c>[RFCXYZ]</c>
</texttable>
</t>
</section>
-->
<section title="204 (No Notification) Response Code">
<t>
This document registers a new response code. This response
code is defined by the following information, which has
been added to the methods and response-codes sub-registry
under http://www.iana.org/assignments/sip-parameters.
<texttable>
<preamble>This information is to be added under
"Successful 2xx" category.</preamble>
<ttcol align="left">Response Code</ttcol>
<ttcol align="left">Reference</ttcol>
<c>204 No Notification</c>
<c>[RFCXYZ]</c>
</texttable>
</t>
</section>
<section title="Suppress-If-Match Header Field">
<t>
This document registers a new SIP header field called
Suppress-If-Match. This header field is defined by the
following information, which has been added to the header
fields sub-registry under
http://www.iana.org/assignments/sip-parameters.
<texttable>
<ttcol align="left">Header Name</ttcol>
<ttcol align="left">Compact</ttcol>
<ttcol align="left">Reference</ttcol>
<c>Suppress-If-Match</c>
<c></c>
<c>[RFCXYZ]</c>
</texttable>
</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>
The security considerations for SIP event notification are
extensively discussed in <xref target="RFC3265">RFC
3265</xref>. This specification introduces an optimization to
SIP event notification, which in itself does not alter the
security properties of the protocol.
</t>
</section>
<section title="Acknowledgments">
<t>
The following people have contributed corrections and
suggestions to this document: Adam Roach, Sean Olson, Johnny
Vrancken, Pekka Pessi, Eva Leppanen, Krisztian Kiss, Peili
Xu, Avshalom Houri, David Viamonte, Jonathan Rosenberg, Qian
Sun, Dale Worley, Tolga Asveren, Brian Stucker and the SIP
and SIMPLE working groups.
</t>
</section>
</middle>
<!-- ************************************************************** -->
<!-- The BACK section includes the rest of the stuff, references, -->
<!-- acknowledgements, authors addresses, etc. -->
<!-- ************************************************************** -->
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3261" ?>
<?rfc include="reference.RFC.3265" ?>
<?rfc include="reference.RFC.3903" ?>
<?rfc include="reference.RFC.4234" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3856" ?>
<?rfc include="reference.RFC.3842" ?>
<?rfc include="reference.RFC.3680" ?>
<?rfc include="reference.RFC.2616" ?>
<?rfc include="reference.RFC.4660" ?>
<?rfc include="reference.RFC.4662" ?>
<?rfc include="reference.RFC.3859" ?>
<?rfc include="reference.RFC.3515" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:33:47 |