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]