draft-ietf-sipcore-subnot-etags-00.txt   draft-ietf-sipcore-subnot-etags-01.txt 
Session Initiation Protocol A. Niemi Session Initiation Protocol A. Niemi
Working Group Nokia Working Group Nokia
Intended status: Standards Track Intended status: Standards Track
Expires: October 21, 2009 Expires: October 23, 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-00 draft-ietf-sipcore-subnot-etags-01
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. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 21, 2009. This Internet-Draft will expire on October 23, 2009.
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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
The Session Initiation Protocol (SIP) events framework enables The Session Initiation Protocol (SIP) events framework enables
receiving asynchronous notification of various events from other SIP receiving asynchronous notification of various events from other SIP
user agents. This framework defines the procedures for creating, user agents. This framework defines the procedures for creating,
refreshing and terminating subscriptions, as well as fetching and refreshing and terminating subscriptions, as well as fetching and
periodic polling of resource state. These procedures have a serious periodic polling of resource state. These procedures provide no
deficiency in that they provide no tools to avoid replaying event tools to avoid replaying event notifications that have already been
notifications that have already been received by a user agent. This received by a user agent. This memo defines an extension to SIP
memo defines an extension to SIP events that allows the subscriber to events that allows the subscriber to condition the subscription
condition the subscription request to whether the state has changed request to whether the state has changed since the previous
since the previous notification was received. When such a condition notification was received. When such a condition is true, either the
is true, either the body of a resulting event notification or the body of a resulting event notification or the entire notification
entire notification message is suppressed. 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 . . . . . . . . . . . . . . . . . . . . . . . 7
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4. Resource Model for Entity-Tags . . . . . . . . . . . . . . . . 11 4. Resource Model for Entity-Tags . . . . . . . . . . . . . . . . 11
5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 13 5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . 14
5.3. Receiving NOTIFY Requests . . . . . . . . . . . . . . . . 15 5.3. Receiving NOTIFY Requests . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . 17
5.6. Refreshing a Subscription . . . . . . . . . . . . . . . . 17 5.6. Refreshing a Subscription . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . 19 6.1. Generating Entity-tags . . . . . . . . . . . . . . . . . . 20
6.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 20 6.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 20
6.3. Suppressing NOTIFY Requests . . . . . . . . . . . . . . . 20 6.3. Suppressing NOTIFY Requests . . . . . . . . . . 21
6.4. State Differentials . . . . . . . . . . . . . . . . . . . 20 6.4. State Differentials . . . . . . . . . . . . . . . . . . . 21
6.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 21 6.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 21
7. Protocol Element Definitions . . . . . . . . . . . . . . . . . 21 7. Protocol Element Definitions . . . . . . . . . . . . . . . . . 22
7.1. 204 (No Notification) Response Code . . . . . . . . . . . 21 7.1. 204 (No Notification) Response Code . . . . . . . . . . . 22
7.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 21 7.2. Suppress-If-Match Header Field . . . . . . . . . 22
7.3. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.3. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8.1. 204 (No Notification) Response Code . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
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 44 skipping to change at page 4, line 44
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 almost identical to
conditional requests defined in the HyperText Transfer Protocol conditional requests defined in the HyperText Transfer Protocol
(HTTP) [RFC2616], and follows the mechanism already defined for the (HTTP) [RFC2616], and follows the mechanism already defined for the
PUBLISH [RFC3903] method for issuing conditional event publications. PUBLISH [RFC3903] 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
backround, motivations and requirements for the work; Section 3 gives background, motivations and requirements for the work; Section 3
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.
1.1. Document Conventions 1.1. Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 5, line 31 skipping to change at page 5, line 31
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 event 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 accross 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
skipping to change at page 7, line 36 skipping to change at page 7, line 36
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 RFC3261 [RFC3261], RFC3265
[RFC3265]. [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 a unique entity tag for the event
notification, and includes it in a SIP-ETag header field of the notification, and includes it in a SIP-ETag header field of the
NOTIFY request. The entity tag is unique accross all versions of all NOTIFY request. The entity tag is unique across all versions of all
entities for a resource and event package. More on this in entities for a 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; the notifier remembers
the entity-tags of all versions of entities for a resource regardless the entity-tags of all versions of entities for a resource regardless
of whether or not there are any active subscription to that resource. of whether or not there are any active subscription to that resource.
This allows notifications generated to a fetch or a poll to have This allows notifications generated to a fetch or a poll to have
valid entity-tags even across subsequent fetches or polls. 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
skipping to change at page 13, line 4 skipping to change at page 13, line 4
/ Content-Type ; defined in RFC 3261 / Content-Type ; defined in RFC 3261
/ Event ; defined in RFC 3265 / Event ; defined in RFC 3265
/ extension-header ; defined in RFC 3261 / extension-header ; defined in RFC 3261
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 accross 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 being equal does not indicate identical
entities. In other words, if an entity-tag is received that matches entities. In other words, if an entity-tag is received that matches
a previously seen entity-tag, the subscriber cannot assume the event a previously seen entity-tag, the subscriber cannot assume the event
state to be identical to that received earlier. state to be identical to that received earlier.
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
skipping to change at page 14, line 22 skipping to change at page 14, line 22
true. true.
Unlike the condition introduced for the SIP PUBLISH [RFC3903] method, Unlike the condition introduced for the SIP PUBLISH [RFC3903] method,
these conditions do not apply to the SUBSCRIBE request itself, but to these conditions do not apply to the SUBSCRIBE request itself, but to
the resulting NOTIFY requests. When true, the condition drives the the resulting NOTIFY requests. When true, the condition drives the
notifier to change its behavior with regards to sending the notifier to change its behavior with regards to sending the
notifications after the SUBSCRIBE. notifications after the SUBSCRIBE.
This specification defines a new header field called "Suppress-If- This specification defines a new header field called "Suppress-If-
Match". This header field introduces a condition to the SUBSCRIBE Match". This header field introduces a condition to the SUBSCRIBE
request. If true, it instructs the notifier to suppress (i.e., request. If true, it instructs the notifier to either omit the body
block) the first NOTIFY request following the SUBSCRIBE, and return a of the resulting NOTIFY message (if the SUBSCRIBE is not sent within
204 (No Notification) response to the SUBSCRIBE request. As long as an existing dialog), or suppress (i.e., block) the NOTIFY request
the condition remains true, it also instructs the notifier to either that would otherwise be triggered the SUBSCRIBE (for an established
suppress any subsequent NOTIFY request, or if there are reportable dialog). In the latter case, the SUBSCRIBE message will be answered
changes in the NOTIFY header, e.g., the Subscription-State has with a 204 (No Notification) response. As long as the condition
changed, suppress the body of any subsequent NOTIFY request. remains true, it also instructs the notifier to either suppress any
subsequent NOTIFY request, or if there are reportable changes in the
NOTIFY header, e.g., the Subscription-State has changed, suppress the
body of any subsequent NOTIFY request.
If the condition is false, the notifier follows its default If the condition is false, the notifier follows its default
behaviour. behaviour.
If the subscriber receives a 204 (No Notification) response to If the subscriber receives a 204 (No Notification) to an in-dialog
SUBSCRIBE, it MUST consider the subscription handshake as completed. SUBSCRIBE, the subscriber can clear handle that it may have had
That is, the subscriber can clear any handle that it may have had pending on a NOTIFY in response the SUBSCRIBE message.
pending on a NOTIFY to conclude establishing the subsctiption.
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 from a
previously received NOTIFY request. 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:
Suppress-If-Match: * Suppress-If-Match: *
Such a wildcard condition effectively quenches a subscription; the Such a wildcard condition effectively quenches a subscription; the
only notifications received are those reporting changes to the only notifications received are those reporting changes to the
subscription state. Such notifications will also not contain a body. subscription state and those in response to a SUBSCRIBE message sent
outside of an existing dialog. In both cases, the notifications will
not contain a body.
A subscription with a wildcard "Suppress-If-Match" condition is A subscription with a wildcard "Suppress-If-Match" condition is
useful in scenarios where the subscriber wants to temporarily put useful in scenarios where the subscriber wants to temporarily put
a subscription in dormant mode. For example, a host may want to a subscription in dormant mode. For example, a host may want to
conserve bandwidth and power when it detects from screen or input conserve bandwidth and power when it detects from screen or input
device inactivity that the user isn't actively monitoring the device inactivity that the user isn't actively monitoring the
presence statuses of contacts. presence statuses of contacts.
5.3. Receiving NOTIFY Requests 5.3. Receiving NOTIFY Requests
skipping to change at page 16, line 15 skipping to change at page 16, line 15
Subscriber Notifier Subscriber Notifier
---------- -------- ---------- --------
(1) SUBSCRIBE --------> (1) SUBSCRIBE -------->
Expires: 0 Expires: 0
<-------- (2) 202 <-------- (2) 202
<-------- (3) NOTIFY <-------- (3) NOTIFY
Subscription-State: terminated Subscription-State: terminated
SIP-ETag: f2e45 SIP-ETag: f2e45
Content-Length: 17539
(4) 200 --------> (4) 200 -------->
... poll interval elapses ... ... poll interval elapses ...
(5) SUBSCRIBE --------> (5) SUBSCRIBE -------->
Suppress-If-Match: f2e45 Suppress-If-Match: f2e45
Expires: 0 Expires: 0
<-------- (6) 202
<-------- (6) 204 <-------- (7) NOTIFY
Subscription-State: terminated
SIP-ETag: f2e45
Content-Length: 0
(8) 200 -------->
Figure 3: Polling Resource State Figure 3: Polling Resource State
1. The subscriber polls for resource state by sending a SUBSCRIBE 1. The subscriber polls for resource state by sending a SUBSCRIBE
with zero expiry (expires immediately). with zero expiry (expires immediately).
2. The notifier accepts the SUBSCRIBE with a 202 (Accepted) 2. The notifier accepts the SUBSCRIBE with a 202 (Accepted)
response. response.
3. The notifier then immediately sends a first (and last) NOTIFY 3. The notifier then immediately sends a first (and last) NOTIFY
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 subsciber 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. Since the resource state has not changed since the previous poll 6. The notifier accepts the SUBSCRIBE with a 202 (Accepted)
occurred, the notifier sends a 204 (No Notification) response, response.
which concludes the poll.
7. 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.
8. The subscriber accepts the notification with a 200 (OK) response.
5.5. Resuming a Subscription 5.5. Resuming a Subscription
Resuming a subscription means the ability to continue an earlier Resuming a subscription means the ability to continue an earlier
subscription that either closed abruptly, or was explicitly subscription that either closed abruptly, or was explicitly
terminated. When resuming, the subscription is established without terminated. When resuming, the subscription is established without
transmitting the resource state. This is accomplished with transmitting the resource state. This is accomplished with
conditional notification and the Suppress-If-Match header field: conditional notification and the Suppress-If-Match header field:
Subscriber Notifier Subscriber Notifier
skipping to change at page 19, line 13 skipping to change at page 19, line 32
subscriber can clear all state related to the subscription. subscriber can clear all state related to the subscription.
5.8. Handling Transient Errors 5.8. Handling Transient Errors
This section is non-normative. This section is non-normative.
In some deployments, there may be Back-to-Back User Agent (B2BUA) In some deployments, there may be Back-to-Back User Agent (B2BUA)
devices that track SIP dialogs such as subscription dialogs. These devices that track SIP dialogs such as subscription dialogs. These
devices may be unaware of the conditional notification mechanism. devices may be unaware of the conditional notification mechanism.
It is possible that such B2BUAs always expect to see a NOTIFY method It is possible that some B2BUA devices may treat a NOTIFY with
to conclude the dialog establishment as specified in SIP Events suppressed body as an error, or may expect all SUBSCRIBE messages to
[RFC3265], and if this NOTIFY request is suppressed, may terminate or have an associated NOTIFY message.
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.
In general, there is very little that an endpoint can do to recover 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 from such transient errors. The most that can be done is to try to
detect such errors, and define a fall back behavior. detect such errors, and define a fall back behavior.
If subscribers encounter transient errors in conditional If subscribers encounter transient errors in conditional
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
skipping to change at page 20, line 14 skipping to change at page 20, line 34
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; there may be several sources to the event
composition process. composition process.
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 match) but there are
reportable changes in the NOTIFY header, e.g., the Subscription-State reportable changes in the NOTIFY header (e.g., the Subscription-State
has changed, the notifier MUST suppress the body of the NOTIFY has changed), the notifier MUST suppress the body of the NOTIFY
request. That is, the resulting NOTIFY contains no Content-Type request. That is, the resulting NOTIFY contains no Content-Type
header field, the Content-Length is set to zero, and no payload is header field, the Content-Length is set to zero, and no payload is
attached to the message. attached to the message.
Additionally, when a condition in a SUBSCRIBE request for suppressing
notifications is true and the SUBSCRIBE message is not sent within an
established dialog, the notifier MUST send a NOTIFY request with a
suppressed entity body.
Suppressing the entity body of a NOTIFY does not change the current 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.
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.3. Suppressing NOTIFY Requests 6.3. Suppressing NOTIFY Requests
When a condition in a SUBSCRIBE request to suppress notifications is 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 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 in a Suppress-If-Match header field match), and the SUBSCRIBE is sent
the resulting NOTIFY request, and generate a 204 (No Notification) 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 response. As long as the condition remains true, and there are no
reportable changes in the NOTIFY header, all subsequent NOTIFY reportable changes in the NOTIFY header, all subsequent NOTIFY
requests MUST also be suppressed. requests MUST also be suppressed.
Notifiers MUST NOT suppress a NOTIFY unless the corresponding
SUBSCRIBE message was sent in an established dialog.
A successful conditional SUBSCRIBE request MUST extend the A successful conditional SUBSCRIBE request MUST extend the
subscription expiry time. subscription expiry time.
Suppressing the entire NOTIFY has no effect on the entity-tag of the Suppressing the entire NOTIFY has no effect on the entity-tag of the
resource. In other words, it remains unchanged. resource. In other words, it remains unchanged.
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
skipping to change at page 21, line 39 skipping to change at page 22, line 20
7. Protocol Element Definitions 7. Protocol Element Definitions
This section describes the protocol extensions required for This section describes the protocol extensions required for
conditional notification. conditional notification.
7.1. 204 (No Notification) Response Code 7.1. 204 (No Notification) Response Code
The 204 (No Notification) response code indicates that the request The 204 (No Notification) response code indicates that the request
was successful, but the notification associated with the request will was successful, but the notification associated with the request will
not be sent. not be sent. It is valid only in response to a SUBSCRIBE message
sent within an established dialog.
The response code is added to the "Success" production rule in the The response code is added to the "Success" production rule in the
SIP [RFC3261] message grammar. SIP [RFC3261] message grammar.
7.2. Suppress-If-Match Header Field 7.2. Suppress-If-Match Header Field
The Suppress-If-Match header field is added to the definition of the The Suppress-If-Match header field is added to the definition of the
"message-header" rule in the SIP [RFC3261] grammar. Its use is "message-header" rule in the SIP [RFC3261] grammar. Its use is
described in Section 5, Section 6.3 and Section 6.2. described in Section 5, Section 6.3 and Section 6.2.
skipping to change at page 22, line 21 skipping to change at page 23, line 13
RFC3903 [RFC3903]. RFC3903 [RFC3903].
Success =/ "204" ; No Notification Success =/ "204" ; No Notification
; Success is defined in RFC3261. ; Success is defined in RFC3261.
message-header =/ Suppress-If-Match message-header =/ Suppress-If-Match
; message-header is defined in RFC3261. ; message-header is defined in RFC3261.
Suppress-If-Match = "Suppress-If-Match" ":" entity-tag / "*" Suppress-If-Match = "Suppress-If-Match:" ( entity-tag / "*" )
; entity-tag is defined in RFC3903. ; entity-tag is defined in RFC3903.
8. IANA Considerations 8. IANA Considerations
This document registers a new response code and a new header field This document registers a new response code and a new header field
name. name.
Note to IANA and the RFC editor: please replace all occurrences of Note to IANA and the RFC editor: please replace all occurrences of
RFCXYZ in this section with the RFC number of this specification RFCXYZ in this section with the RFC number of this specification
 End of changes. 30 change blocks. 
65 lines changed or deleted 90 lines changed or added

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