One document matched: draft-niemi-sip-subnot-etags-00.txt
Network Working Group A. Niemi
Internet-Draft Nokia Research Center
Expires: July 29, 2006 January 25, 2006
An Extension to Session Initiation Protocol (SIP) Events for Issuing
Conditional Subscriptions
draft-niemi-sip-subnot-etags-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 29, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Session Initiation Protocol (SIP) events framework enables
receiving asynchronous notification of various events from other SIP
user agents. This framework defines the procedures for creating,
refreshing and terminating subscriptions, as well as fetching and
periodic polling of resource state. These procedures have a serious
deficiency in that they do not allow state to persist over a
subscription refresh, or between two consecutive polls. This
inablity to suppress notifications of state already known to the
Niemi Expires July 29, 2006 [Page 1]
Internet-Draft Entity-tags in SIP Events January 2006
subscriber results in superfluous traffic. 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 fails, the
event state is not sent in a notification.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Document Conventions . . . . . . . . . . . . . . . . . . . 3
2. Motivations and Background . . . . . . . . . . . . . . . . . . 4
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Problem Description . . . . . . . . . . . . . . . . . . . 4
2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6
4. Notifier Behavior . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Generating Entity Tags . . . . . . . . . . . . . . . . . . 7
4.2. Comparison Rules for Entity Tags . . . . . . . . . . . . . 7
4.3. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 7
4.4. State Differentials . . . . . . . . . . . . . . . . . . . 8
5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 8
5.1. Indicating Support for Entity Tags . . . . . . . . . . . . 8
5.2. Creating Conditional SUBSCRIBEs . . . . . . . . . . . . . 9
6. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Niemi Expires July 29, 2006 [Page 2]
Internet-Draft Entity-tags in SIP Events January 2006
1. Introduction
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.
Several instantiations of this framework, called event packages have
been defined, e.g., for presence [5], message waiting indications [6]
and registrations [7].
By default, every SUBSCRIBE request generates a NOTIFY request
containing the latest event state. Typically, a SUBSCRIBE request is
issued whenever a subscription is 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.
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.
This memo defines an extension to the SIP events framework allowing a
notifier to issue versioning in the form of entity tags to
notifications, and the subscriber to condition the SUBSCRIBE request
for actual changes since the last notification carrying that entity
tag was issued. The solution is almost identical to conditional
requests defined in the HyperText Transfer Protocol (HTTP) [8], and
follows the mechanism already defined for the PUBLISH [1] method for
issuing conditional event publications.
1.1. Document Conventions
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 19, RFC 2119 [2]
and indicate requirement levels for compliant implementations.
Niemi Expires July 29, 2006 [Page 3]
Internet-Draft Entity-tags in SIP Events January 2006
2. Motivations and Background
2.1. Overview
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, this soft state is cleared. The frequency of
these subscription refreshes depends on the event package, and
typically ranges from minutes to hours.
Changes in connectivity represent another impetus for a subscriber
re-subscribing. If the subscriber's point of attachment to the
Internet changes, e.g., due to dynamic address allocation, the
subscriber needs to re-subscribe in order to update the dialog
endpoint, which is carried in the Contact header field of the
SUBSCRIBE request.
Another option for reducing connectivity induced subscription
refreshes is to use the Globally Routable User Agent (UA) URIs
(GRUU) [9].
2.2. Problem Description
In spite of being somewhat distinct operations, the SIP events
framework does not include different protocol methods for initial
subscriptions, subscription refreshes and fetches inside and outside
of the SIP dialog. Instead, the SUBSCRIBE method is overloaded to
perform all of these functions, and the notifier behavior is
identical in each of them; each SUBSCRIBE request generates a NOTIFY
request containing the latest resource state. In fact, the only
difference between a fetch that does not create a (lasting)
subscription, and a SUBSCRIBE that creates one is in the Expires
header field value of the SUBSCRIBE; a zero-expiry SUBSCRIBE only
generates a single NOTIFY, after which the subscription immediately
terminates.
Some subscriber implementations may choose to operate in semi-
stateless mode, in which they immediately upon receiving and
processing the NOTIFY forget the resource state. This operation
necessarily needs every NOTIFY to carry the full resource state.
However, for an implementation that stores the resource state
locally, this mode of operation is inefficient.
There are certain conditions that aggravate the problem. Such
conditions usually entail such things as:
Niemi Expires July 29, 2006 [Page 4]
Internet-Draft Entity-tags in SIP Events January 2006
o Large entity bodies in the payloads of notifications
o High rate of subscription refreshes
o Relatively low rate of actual notifications triggered by actual
state changes
In effect, for an event package that generates few state changes, and
is refreshed relatively often the majority of traffic generated may
be related to subscription maintenance. Especially in networks where
bandwidth consuption and traffic count is at a premium, the high
overhead of subscription maintenance becomes a barrier for
deployment.
The same problem affects fetching and polling of resource state as
well. As a benchmark, if we look at the performance of HTTP [8] in
similar scenarios, it performs substantially better using conditional
requests. When resources are tagged with an entity-tag, and each GET
is a conditional one using the "If-None-Match" header field, the
entity body need not send more than once; if the resource has not
changed between successive polls, an error response is returned
indicating this fact, and the resource entity is not transmitted
again.
The SIP PUBLISH [1] method also contains a similar feature, where a
refresh of a publication is done by reference to its assigned entity-
tag, instead of retransmitting the event state each time the
publication expiration is extended.
2.3. Requirements
As a summary, here is the required functionality to solve the
presented issues:
REQ1: It must be possible to suppress the NOTIFY request (or at a
minimum the event body therein) triggered by a subscription
refresh, if the subscriber already has possession of the
latest event state of the resource
REQ2: It must be possible to suppress the NOTIFY request (or at a
minimum the event body therein) triggered by a fetch, if the
subscriber already has possession of the latest event state
of the resource
Niemi Expires July 29, 2006 [Page 5]
Internet-Draft Entity-tags in SIP Events January 2006
3. Overview of Operation
Whenever a subscriber initiates a subscription, it issues a SUBSCRIBE
request. If the subscriber supports the conditional subscription
mechanism described in this memo, it also includes a supported tag
indicating so. The SUBSCRIBE request is sent, routed and processed
by the notifier normally, i.e., according to RFC3261 [3], RFC3265
[4].
If the notifier receiving the SUBSCRIBE request supports conditional
subscriptions, it generates a unique entity tag for the resource
state, and attaches that tag in a SIP-ETag header field of the NOTIFY
request. The entity tag is unique for that particular resource and
event state; however, depending on the notifier composition, a single
resource may be represented by several different views, in which case
each separate view would also have its own etag.
Entity-tags are independent of subscriptions; the notifier should
store the entity tag along with the resource state regardless of
whether there is an active subscription to that resource. This
allows notifications generated to a fetch or poll to also be tagged
with the same entity-tag.
The subscriber will use the entity tag received in the notification
and store it along with the event state. For issuing a conditional
subscription, the subscriber issues a SUBSCRIBE request that includes
a SIP-If-None-Match header field containing the last received entity-
tag for the requested resource. This is to instruct the notifier to
send resource state only if the included entity-tag and the notifier
entity-tag are not equal. If the entity-tags are equal, a NOTIFY is
still generated, but contains an empty body.
There are two reasons for this design: first, the Subscription-State
header field carries information about the state of the subscription;
second, a conditional subscription should still maintain the ability
to extend the subscription expiration, so a 412 error response is not
entirely appropriate (since the request has succeeded in part).
When processing the conditional SUBSCRIBE, normal processing of the
request is followed, e.g., the request is authenticated and
authorized based on the notifier's authorization and composition
policy. When generating a NOTIFY request, the notifier makes a
comparison between the entity-tag received in the SIP-If-None-Match
header field of the SUBSCRIBE, and the locally stored entity tag for
the requested resource. If there is no match, the latest resource
state (including it's current entity-tag) is sent in a notification;
if the entity-tags match, an empty entity body is sent in the
notification.
Niemi Expires July 29, 2006 [Page 6]
Internet-Draft Entity-tags in SIP Events January 2006
Whenever the notifier detects a state change it needs to report to
(potential) subscribers of that resource, it needs to generate and
store a fresh entity-tag for that resource. Optionally, the notifier
can also keep record in a journal of recent state changes and their
associated entity tags. Such a journal can then be used to create a
state differential for a subscriber and event package that support
such payload formats.
4. Notifier Behavior
This section augments the notifier behavior as specified in RFC3265
[4].
4.1. Generating Entity Tags
A notifier generates entity tags for each resource it is responsible
for. Depending on its composition policy, there may in addition
exist several different views of the resource state, requiring
several different entity tags per resource.
The views might correspond to different groups of users that have
varying levels of access rigths to the resource state. For
example, in presence [5] watchers may get different levels of
accuracy in geolocation information, based on the presentity's
privacy settings.
An entity tag is defined as an opaque token, and the notifier is free
to decide the means for generating one. 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.
Note that the entity tag values used in publications are not
necessarily shared with the entity tag values used in subscriptions.
This is because there may not always be a one-to-one mapping between
a publication and a notification; there may be several inputs to the
composition process, which is dictated by composition policy.
4.2. Comparison Rules for Entity Tags
FIXME: Add some text here.
4.3. Suppressing NOTIFY Bodies
When a condition fails, i.e., the local and subscriber provided
entity-tags do not match, the notifier MUST suppress the body of the
resulting NOTIFY request. The Content-Type header field of the
NOTIFY request is set an appropriate value, depending on the event
Niemi Expires July 29, 2006 [Page 7]
Internet-Draft Entity-tags in SIP Events January 2006
package, but the Content-Length MUST be set to zero, and no payload
is attached to the message.
Suppressing the entity body of a NOTIFY does not change the current
entity-tag of the resource.
4.4. State Differentials
A notifier can optionally keep track of the state changes of a
resource, e.g., storing the changes in a journal. If a condition
fails, the notifier MAY send a state differential in the NOTIFY
rather than the full state of the event resource. This is only
possible if the event package and the subscriber both support a
payload format that has this capability.
OPEN ISSUE: How about using timestamps and Modified-Since
construct? This probably works just as well, and at least makes
the idea of a journal seem more intuitive. The problem present in
HTTP (why HTTP has moved away from timestamps and into etags)
regarding limited 1 second granularity in timestamps is not a
problem in SIP events. Each package restricts sending
notifications that close to each other.
5. Subscriber Behavior
This section augments the subscriber behavior defined in RFC3265 [4].
5.1. Indicating Support for Entity Tags
The proposed solution is backwards compatible with SIP events [4] 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 them in creating a conditional
request.
Unaware subscribers will simply ignore the entity-tag, make
unconditional requests and get the usual defined behavior from the
notifier.
As a hint to the notifier, the subscriber can also use the Supported
header field in advertizing support for receiving entity tags in
notifications:
Supported: etags
Niemi Expires July 29, 2006 [Page 8]
Internet-Draft Entity-tags in SIP Events January 2006
5.2. Creating Conditional SUBSCRIBEs
When creating a conditional SUBSCRIBE request, the subscriber
includes a "SIP-If-None-Match" header field that includes an entity-
tag the subscriber received in a previous notification.
6. Grammar
This section defines new extension syntax elements to those elements
defined in RFC3261 [3] and RFC3903 [1].
message-header =/ SIP-If-None-Match
; message-header is defined in RFC3261,
SIP-If-None-Match = "SIP-If-None-Match" HCOLON entity-tag
; and entity-tag in RFC3265.
7. Examples
Below is an example message flow that utilizes conditional SUBSCRIBE
requests and entity-tags.
Initial subscription, at t=0:
Watcher Notifier
| |
|'---...__M1 |
| `'---...__ |
| ->|
| |
| M2___..,--'' |
| _.,--''' |
|<- |
| |
| M3___..,--'' |
| _.,--''' |
|<- |
| |
| |
|'---...__M4 |
| `'---...__ |
| ->|
M1: SUBSCRIBE, no entity-tag, Expires: 3600. M2: 200 OK. M3:
NOTIFY, SIP-ETag: 0001. M4: 200 OK, Expires: 3600
Niemi Expires July 29, 2006 [Page 9]
Internet-Draft Entity-tags in SIP Events January 2006
Subscription refresh, at t=3000:
Watcher Notifier
| |
|'---...__M5 |
| `'---...__ |
| ->|
| |
| M6___..,--'' |
| _.,--''' |
|<- |
| M7___..,--'' |
| _.,--''' |
|<- |
| |
|'---...__M8 |
| `'---...__ |
| ->|
| |
M5: SUBSCRIBE, If-None-Match: 0001, Expires:3600. M6: 200 OK,
Expires: 3600. M7: NOTIFY, Content-Length: 0. M8: 200 OK.
8. IANA Considerations
FIXME: Add this section.
9. Security Considerations
FIXME: Add this section.
10. References
10.1. Normative References
[1] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
Niemi Expires July 29, 2006 [Page 10]
Internet-Draft Entity-tags in SIP Events January 2006
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
10.2. Informative References
[5] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[6] Mahy, R., "A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP)",
RFC 3842, August 2004.
[7] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[9] Rosenberg, J., "Obtaining and Using Globally Routable User Agent
(UA) URIs (GRUU) in the Session Initiation Protocol (SIP)",
draft-ietf-sip-gruu-06 (work in progress), October 2005.
Author's Address
Aki Niemi
Nokia Research Center
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 389 1644
Email: aki.niemi@nokia.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
Niemi Expires July 29, 2006 [Page 11]
Internet-Draft Entity-tags in SIP Events January 2006
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Niemi Expires July 29, 2006 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 05:46:37 |