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]