draft-ietf-sipcore-subnot-etags-03.txt   draft-ietf-sipcore-subnot-etags-04.txt 
Session Initiation Protocol A. Niemi Session Initiation Protocol A. Niemi
Working Group Nokia Working Group Nokia
Internet-Draft D. Willis, Ed. Internet-Draft D. Willis, Ed.
Intended status: Standards Track Softarmor Systems Intended status: Standards Track Softarmor Systems
Expires: May 26, 2010 November 22, 2009 Expires: July 19, 2010 January 15, 2010
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-03 draft-ietf-sipcore-subnot-etags-04
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 provide no periodic polling of resource state. These procedures provide no
tools to avoid replaying event notifications that have already been tools to avoid replaying event notifications that have already been
received by a user agent. This memo defines an extension to SIP received by a user agent. This memo defines an extension to SIP
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 May 26, 2010. This Internet-Draft will expire on July 19, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 21 skipping to change at page 3, line 21
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Problem Description . . . . . . . . . . . . . . . . . . . 5 2.2. Problem Description . . . . . . . . . . . . . . . . . . . 5
2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4. Resource Model for Entity-Tags . . . . . . . . . . . . . . . . 10 4. Resource Model for Entity-Tags . . . . . . . . . . . . . . . . 10
5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 12 5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 12
5.1. Detecting Support for Conditional Notification . . . . . . 13 5.1. Detecting Support for Conditional Notification . . . . . . 13
5.2. Generating SUBSCRIBE Requests . . . . . . . . . . . . . . 13 5.2. Generating SUBSCRIBE Requests . . . . . . . . . . . . . . 13
5.3. Receiving NOTIFY Requests . . . . . . . . . . . . . . . . 14 5.3. Receiving NOTIFY Requests . . . . . . . . . . . . . . . . 14
5.4. Polling or Fetching Resource State . . . . . . . . . . . . 15 5.4. Polling or Fetching Resource State . . . . . . . . . . . . 15
5.5. Resuming a Subscription . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . 21 6.4. State Differentials . . . . . . . . . . . . . . . . . . . 21
6.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 21 6.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 22
7. Protocol Element Definitions . . . . . . . . . . . . . . . . . 21 7. Protocol Element Definitions . . . . . . . . . . . . . . . . . 22
7.1. 204 (No Notification) Response Code . . . . . . . . . . . 22 7.1. 204 (No Notification) Response Code . . . . . . . . . . . 22
7.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 22 7.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 22
7.3. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.3. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8.1. 204 (No Notification) Response Code . . . . . . . . . . . 23 8.1. 204 (No Notification) Response Code . . . . . . . . . . . 23
8.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 23 8.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 14, line 7 skipping to change at page 14, line 7
If the condition is false, the notifier follows its default If the condition is false, the notifier follows its default
behaviour. behaviour.
If the subscriber receives a 204 (No Notification) to an in-dialog If the subscriber receives a 204 (No Notification) to an in-dialog
SUBSCRIBE, the subscriber can clear handle that it may have had SUBSCRIBE, the subscriber can clear handle that it may have had
pending on a NOTIFY in response the SUBSCRIBE message. pending on a NOTIFY in response the SUBSCRIBE message.
The value of the "Suppress-If-Match" header field is an entity-tag, The value of the "Suppress-If-Match" header field is an entity-tag,
which is an opaque token that the subscriber simply copies (bytewise) which is an opaque token that the subscriber simply copies (bytewise)
from a previously received NOTIFY request. 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.
Example: Example:
Suppress-If-Match: b4cf7 Suppress-If-Match: b4cf7
The header field can also be wildcarded using the special "*" entity- The header field can also be wildcarded using the special "*" entity-
tag value. Such a condition always evaluates to true regardless of tag value. Such a condition always evaluates to true regardless of
the value of the current entity-tag for the resource. the value of the current entity-tag for the resource.
Example: Example:
skipping to change at page 21, line 16 skipping to change at page 21, line 38
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
Some event packages may support a scheme where notifications contain Some event packages support a scheme where notifications contain
state differentials, or state deltas [RFC3265] instead of complete state differentials, or state deltas [RFC3265] instead of complete
resource state. resource state.
An event package definition MAY allow a notifier to keep track of the Further extensions could define means for notifiers to keep track of
state changes of a resource, e.g., storing the changes in a journal. the state changes of a resource, e.g., storing the changes in a
If a condition fails, the notifier MAY then send a state differential journal. If a condition fails, the notifier would then send a state
in the NOTIFY rather than the full state of the event resource. This differential in the NOTIFY rather than the full state of the event
is only possible if the event package and the subscriber both support resource. This is only possible if the event package and the
a payload format that has this capability. subscriber both support a payload format that has this capability.
When state differentials are sent, the SIP-ETag header field MUST When state differentials are sent, the SIP-ETag header field MUST
contain an entity-tag that corresponds to the full resource state. contain an entity-tag that corresponds to the full resource state.
6.5. List Subscriptions 6.5. List Subscriptions
The Event Notification Extension for Resource Lists [RFC4662] defines The Event Notification Extension for Resource Lists [RFC4662] defines
a mechanism for subscribing to a homogeneous list of resources using a mechanism for subscribing to a homogeneous list of resources using
the SIP events framework. the SIP events framework.
 End of changes. 14 change blocks. 
23 lines changed or deleted 26 lines changed or added

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