One document matched: draft-niemi-sip-subnot-etags-01.txt
Differences from draft-niemi-sip-subnot-etags-00.txt
Network Working Group A. Niemi
Internet-Draft Nokia Research Center
Expires: December 28, 2006 June 26, 2006
An Extension to Session Initiation Protocol (SIP) Events for Issuing
Conditional Subscriptions
draft-niemi-sip-subnot-etags-01
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 December 28, 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
inability to suppress notifications of state already known to the
Niemi Expires December 28, 2006 [Page 1]
Internet-Draft Entity-tags in SIP Events June 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 . . . . . . . . . . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Problem Description . . . . . . . . . . . . . . . . . . . 4
2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
4. Notifier Behavior . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Generating Entity Tags . . . . . . . . . . . . . . . . . . 7
4.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 7
4.3. Suppressing NOTIFY Requests . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Niemi Expires December 28, 2006 [Page 2]
Internet-Draft Entity-tags in SIP Events June 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.
2. Motivations and Background
Niemi Expires December 28, 2006 [Page 3]
Internet-Draft Entity-tags in SIP Events June 2006
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:
o Large entity bodies in the payloads of notifications
Niemi Expires December 28, 2006 [Page 4]
Internet-Draft Entity-tags in SIP Events June 2006
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 be sent more than once; if the resource has not
changed between successive polls, an error response is returned
indicating this fact, and the resource entity is not transmitted
again.
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
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
Niemi Expires December 28, 2006 [Page 5]
Internet-Draft Entity-tags in SIP Events June 2006
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
either a Suppress-Body-If-Match or a Suppress-Notify-If-Match header
field containing the last received entity-tag for the requested
resource. The first will instruct the notifier to suppress the event
state body and the second the entire notification if the resource
state has not changed, and the local and remote entity-tags match.
Suppressing the body only allows access to the NOTIFY header, where
for example the Subscription-State header field carries useful
information about the state of the subscription. Suppressing the
entire NOTIFY will work in cases where the subscriber already is
fully aware of the subscription state e.g., when refreshing a
subscription.
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 Suppress-Body-If-
Match or Suppress-Notify-If-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,
either an empty entity body is sent in a notification, or no
notification is sent.
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
Niemi Expires December 28, 2006 [Page 6]
Internet-Draft Entity-tags in SIP Events June 2006
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. Suppressing NOTIFY Bodies
When a condition for suppressing a NOTIFY body is true, i.e., the
local entity-tag for the resource and the subscriber provided entity-
tag in a Suppress-Body-If-Match header field 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 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.
Niemi Expires December 28, 2006 [Page 7]
Internet-Draft Entity-tags in SIP Events June 2006
4.3. Suppressing NOTIFY Requests
When a condition to suppress a NOTIFY is true, i.e., the local
entity-tag and the subscriber provided entity-tag in a Suppress-
Notify-If-Match header field match, the notifier MUST suppress the
resulting NOTIFY request. Such a successful conditinal SUBSCRIBE
request MUST otherwise work the same as one without the condition.
For instance, a conditional subscription refresh would still extend
the subscription expiry time.
Suppressing of a NOTIFY request 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.
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 December 28, 2006 [Page 8]
Internet-Draft Entity-tags in SIP Events June 2006
5.2. Creating Conditional SUBSCRIBEs
When creating a conditional SUBSCRIBE request, the subscriber
includes either a "Suppress-Body-If-Match" or "Suppress-Notify-If-
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 =/ Suppress-Body-If-Match
message-header =/ Suppress-Notify-If-Match
; message-header is defined in RFC3261,
Suppress-Body-If-Match = "Suppress-Body-If-Match" HCOLON entity-tag
Suppress-Notify-If-Match = "Suppress-Notify-If-Match" HCOLON entity-tag
; and entity-tag in RFC3265.
7. Examples
FIXME: Add this section.
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.
Niemi Expires December 28, 2006 [Page 9]
Internet-Draft Entity-tags in SIP Events June 2006
[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.
[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-09 (work in progress), June 2006.
Niemi Expires December 28, 2006 [Page 10]
Internet-Draft Entity-tags in SIP Events June 2006
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
Niemi Expires December 28, 2006 [Page 11]
Internet-Draft Entity-tags in SIP Events June 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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,
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Niemi Expires December 28, 2006 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 05:44:39 |