One document matched: draft-ietf-sipcore-subnot-etags-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc sortrefs="yes"?>
<?rfc linkmailto="yes"?>
<?rfc strict="no"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<rfc category="std" docName="draft-ietf-sipcore-subnot-etags-04"
ipr="pre5378Trust200902">
<!-- ************************************************************** -->
<!-- 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 fullname="Aki Niemi" initials="A" surname="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>
<author fullname="Dean Willis" initials="D" surname="Willis" role="editor">
<organization>Softarmor Systems</organization>
<address>
<postal>
<street>3100 Independence Pkwy #311-164</street>
<city>Plano</city>
<region>TX</region>
<code>75075</code>
<country>USA</country>
</postal>
<phone>+1 214 504 1987</phone>
<email>dean.willis@softarmor.com</email>
</address>
</author>
<date day="15" month="January" year="2010" />
<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 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 optimize the SIP events framework.
This extension allows a notifier to tag notifications (called
entity-tags hereafter), and the subscriber to condition its subsequent
SUBSCRIBE requests for actual changes since a notification carrying that
entity-tag was issued. The solution is similar 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"></xref> explains the background, motivations and
requirements for the work; <xref target="operation"></xref> gives a
general overview of the mechanism; <xref target="model"></xref> explains
the underlying model for resources and entities as they apply to
conditional notification; <xref target="subscriber"></xref> defines the
subscriber behavior; <xref target="notifier"></xref> defines the
notifier behavior; <xref target="proto"></xref> includes the protocol
element definitions; <xref target="iana"></xref> includes the IANA
considerations; and <xref target="security"></xref> 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>, <xref target="RFC3265"></xref> and <xref
target="RFC3903"></xref>, 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 state 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>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. The SUBSCRIBE method is
overloaded to perform all of these functions
The 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. Lasting subscriptions typically have relatively
short expiry periods, requiring periodic sending of new SUBSCRIBE
requests in order to refresh the subscription.</t>
<t>Each new SUBSCRIBE request generates a NOTIFY request containing the
latest resource state. Even if the state has not changed, it is sent again
in response to each poll or subscription refresh. This is very similar to
the <xref target="RFC2616">HTTP</xref> problem of repeated GET operations
on a resource. HTTP solves the problem using conditional requests. The server
versions each entity with an entity tag that identifies a specific instance of
that entity. Clients making GET requests can then include the entity tag for
the version of the entity that they currently to be current in an
"If-None-Match" header field, and the 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. </t>
<t>The <xref target="RFC3903">SIP PUBLISH</xref> method uses
a similar mechanism, 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 (or has previously received and discarded) 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 that has been paused. </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">The Session Initiation Protocol</xref>, and <xref
target="RFC3265">SIP Specific Event Notification</xref>.</t>
<t>If the notifier receiving the SUBSCRIBE request supports conditional
subscriptions, it generates an entity tag for the current entity,
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"></xref>.</t>
<t>Entity-tags are independent of subscriptions. 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 entity-tag of the entity that would normally be sent in
the associated NOTIFY message. There is also a
wildcard entity-tag with a special value of "*" that always matches.</t>
<figure anchor="ov" title="Example Message Flow">
<artwork>
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Expires: 3600
<-------- (2) 200 (or 202)
<-------- (3) NOTIFY
Subscription-State: active
SIP-ETag: ffee2
(4) 200 -------->
... time passes ...
(5) SUBSCRIBE --------> \ if "ffee2"
Suppress-If-Match: ffee2 | matches
Expires: 3600 | local
| entity-tag
|
<-------- (6) 204 / then
... time passes and resource state (entity) changes...
<-------- (7) NOTIFY
Subscription-State: active
SIP-ETag: ca89a
(8) 200 -------->
... time passes ...
(9) SUBSCRIBE --------> \ if "ca89"
Suppress-If-Match: ca89a | matches
Expires: 0 | local
| entity-tag
|
<-------- (10) 204 / then
</artwork>
</figure>
<t><xref target="ov"></xref> 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"></xref> illustrates the model.</t>
<figure anchor="diagram" title="Resource Model Diagram">
<artwork>
+-----+
............ | |
. . | 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"></xref>.</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 an "entity". Each
resource may be associated with zero or more entities. For example, there may
be multiple subscribers to the presence information of a single user (a resource),
and each subscriber may have a different filtered view of that resource,
producing one entity per subscriber. However, each entity is associated with
one and only one resource; there is no "compositing" of resources at the entity level.
Resources may themselves be made up of information from other resources (be
"composite resources"), but this does not change the one-resource-per-entity rule.</t>
<t>An entity consists of the data carried in the body of a NOTIFY
message, and related meta-data in the message header. Whenever the data in
the body or any of the meta-data changes, the notifier MUST produce a
new entity-tag. This meta-data MUST
include, but is not limited to the following SIP header fields defined in <xref
target="RFC3261">The Session Initiation Protocol</xref> and <xref
target="RFC3265">SIP Specific Event Notification</xref>:
<list style="numbers">
<t>Content-Disposition</t>
<t>Content-Encoding</t>
<t>Content-Language</t>
<t>Content-Length</t>
<t>Content-Type</t>
<t>Event</t>
</list>
</t>
<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>Note that two entity-tags for different resources being equal does not
indicate identical
entities. In other words, if an entity-tag received for a subscription to
a first resource matches an entity-tag received for a subscription to a
second resource, the subscriber cannot assume that the two entity values
are equal.</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 either omit
the body of the resulting NOTIFY message (if the SUBSCRIBE is not sent
within an existing dialog), or suppress (i.e., block) the NOTIFY
request that would otherwise be triggered the SUBSCRIBE (for an
established dialog). In the latter case, the SUBSCRIBE message will be
answered with a 204 (No Notification) response. As long as the
condition remains true, it also instructs the notifier to either
suppress any subsequent NOTIFY request, or if there are reportable
changes in the NOTIFY header, e.g., the Subscription-State has
changed, suppress the body of any subsequent NOTIFY request.</t>
<t>If the condition is false, the notifier follows its default
behaviour.</t>
<t>If the subscriber receives a 204 (No Notification) to an in-dialog
SUBSCRIBE, the subscriber can clear handle that it may have had
pending on a NOTIFY in response the SUBSCRIBE message.</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 (bytewise)
from a previously received NOTIFY request. Inclusion of an entity-tag
in a "Suppress-If-Match" header field of a SUBSCRIBE request indicates
that the client either has a copy of, or is capable of re-creating a
copy of, the entity associated with that entity-tag.</t>
<t>Example: <list style="empty">
<t>Suppress-If-Match: b4cf7</t>
</list></t>
<t> </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 and those in response to a SUBSCRIBE message sent
outside of an existing dialog. In both cases, the notifications will
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 contacts.</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>
<t>The subscriber MUST NOT infer any meaning from the value of an
entity-tag; specifically, the subscriber MUST NOT assume identical
entities (i.e., event state) for NOTIFYs with identical entity-tag
values when those NOTIFYs result from subscription to different
resources.
<list style="empty">
<t>Note that there are valid cases for which identical entity-tag
values on different resources may occur. For example, it is
possible to generate entity-tag values using a one-way hash
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.</t>
</list>
</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>
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Expires: 0
<-------- (2) 202
<-------- (3) NOTIFY
Subscription-State: terminated
SIP-ETag: f2e45
Content-Length: 17539
(4) 200 -------->
... poll interval elapses ...
(5) SUBSCRIBE -------->
Suppress-If-Match: f2e45
Expires: 0
<-------- (6) 202
<-------- (7) NOTIFY
Subscription-State: terminated
SIP-ETag: f2e45
Content-Length: 0
(8) 200 -------->
</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>The notifier accepts the SUBSCRIBE with a 202 (Accepted)
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 <xref
target="RFC3265">SIP Specific Event Notification"</xref>.)</t>
<t>Since the resource state has not changed since the previous
poll occurred, the notifier sends a NOTIFY message with no body.
It also mirrors the current entity-tag of the resource in the
SIP-ETag header field.</t>
<t>The subscriber accepts the notification with a 200 (OK)
response.</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>
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
expires, and uses the Suppress-If-Match header field:</t>
<figure anchor="fig_refresh" title="Refreshing a Subscription">
<artwork>
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: aba91
Expires: 3600
<-------- (2) 204
Expires: 3600
</artwork>
</figure>
<t><list style="numbers">
<t>Before the subscription expires, 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>
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 some B2BUA devices may treat a NOTIFY with
suppressed body as an error, or may expect all SUBSCRIBE messages to
have an associated NOTIFY message.</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>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>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.</t>
<t>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 one. The notifier MUST remember (or be able to recalculate)
the entity-tag of an entity as long as the version of the entity
is 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 of state change; there may be several
sources to the
event composition process, and a publication into a resource may
not affect the resulting entity.</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
are byte-wise identical)
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>Additionally, when a condition in a SUBSCRIBE request for
suppressing notifications is true and the SUBSCRIBE message is not
sent within an established dialog, the notifier MUST send a NOTIFY
request with a suppressed entity body.</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), and the SUBSCRIBE is sent
within an established dialog, then the notifier MUST suppress the
resulting NOTIFY request, and generate a 204 (No Notification)
response. As long as the condition remains true, and there are no
reportable changes in the NOTIFY header, all subsequent NOTIFY
requests MUST also be suppressed.</t>
<t>Notifiers MUST NOT suppress a NOTIFY unless the corresponding
SUBSCRIBE message was sent in an established dialog.</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 support a scheme where notifications
contain state differentials, or <xref target="RFC3265">state
deltas</xref> instead of complete resource state.</t>
<t>Further extensions could define means for notifiers to keep track of
the state changes of a resource, e.g., storing the changes in a journal.
If a condition fails, the notifier would then send a state 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. It is valid only in response to a SUBSCRIBE message sent
within an established dialog.</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>,
<xref target="suppressing_request"></xref> and <xref
target="suppressing"></xref>.</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="RFC5234">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">
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" HCOLON ( 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.
</t>
<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>
</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. </t>
<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>
</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. </t>
<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>
</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,
Eric Rescorla, Arun Arunachalam 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.5234" ?>
</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.4662" ?>
<?rfc include="reference.RFC.3859" ?>
<?rfc include="reference.RFC.3515" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 00:02:28 |