Network Working Group A. Niemi Internet-Draft Nokia Research Center Intended status: Informational October 23, 2006 Expires: April 26, 2007 An Extension to Session Initiation Protocol (SIP) Events for Issuing Conditional Subscriptions draft-niemi-sip-subnot-etags-02 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 April 26, 2007. 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 Niemi Expires April 26, 2007 [Page 1]
Internet-Draft Entity-tags in SIP Events October 2006 inability to suppress notifications of state already known to the subscriber results in superfluous traffic in the network. 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 is met, either the body of an event notification or the entire notification message is suppressed. 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. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 8 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 5.2.1. Suppressing the NOTIFY Body . . . . . . . . . . . . . 9 5.2.2. Suppressing the NOTIFY request . . . . . . . . . . . . 9 6. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Niemi Expires April 26, 2007 [Page 2]
Internet-Draft Entity-tags in SIP Events October 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 April 26, 2007 [Page 3]
Internet-Draft Entity-tags in SIP Events October 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 initiating and terminating of 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 April 26, 2007 [Page 4]
Internet-Draft Entity-tags in SIP Events October 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 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) if the subscriber is already in possession of the latest event state of the resource. REQ2: This mechanism must apply to initial subscriptions, in which the subscriber is attempting to "resume" an earlier subscription. REQ3: This mechanism must apply to refreshing a subscription. REQ4: This mechanism must apply to terminating a subscription (i.e., an unsubscribe). Niemi Expires April 26, 2007 [Page 5]
Internet-Draft Entity-tags in SIP Events October 2006 REQ5: This mechanism must apply to fetching or polling of resource state. 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 includes a tag in the Supported header field that indicates support for the feature to the notifier. 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 entity-tag. 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 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 body of a notification and the second the entire notification if the resource state has not changed, i.e., the local and remote entity- tags match. The subscriber can also include to its condition a special value of "*", which matches any entity-tag. Suppressing the body only allows access to the NOTIFY header, in which 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 Niemi Expires April 26, 2007 [Page 6]
Internet-Draft Entity-tags in SIP Events October 2006 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 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 a payload format. 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, or to subscribers that have modified their subscription using event notification filtering [10]. 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, except for the special "*" value for matching any entity-tag. 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. Niemi Expires April 26, 2007 [Page 7]
Internet-Draft Entity-tags in SIP Events October 2006 4.2. Suppressing NOTIFY Bodies When a condition for suppressing a NOTIFY body is true, i.e., the local entity-tag for the resource state 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 NOTIFY MUST NOT contain a Content-Type header field, 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. Hence, the NOTIFY MUST contain a SIP- Etag header field that contains the unchanged entity-tag of the event state resource. 4.3. Suppressing NOTIFY Requests When a condition to suppress a NOTIFY request is true, i.e., the local entity-tag of the resource state 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. Supressing the entire NOTIFY has no effect on the entity-tag of the resource. In other words, it remains unchanged. 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 Niemi Expires April 26, 2007 [Page 8]
Internet-Draft Entity-tags in SIP Events October 2006 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 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. 5.2.1. Suppressing the NOTIFY Body Suppressing the NOTIFY body is useful when resuming an earlier subscription. For example, when the watcher returns back from being offline, and wants to resume the subscription(s) it had active previously. There, the NOTIFY request is needed to complete the subscription, and report the status of the subscription (e.g., active, pending) via the Subscription-State header field. 5.2.2. Suppressing the NOTIFY request Suppressing the entire NOTIFY request is useful in three different scenarios: Subscription refresh: When the subscriber extends the expiration interval of the subscription it can suppress the NOTIFY request that would otherwise be generated. Subscription termination: When the subscriber terminates a subscription (by setting the expiration interval to zero), it can suppress the final NOTIFY that would otherwise be generated. Polling or fetching: When the subscriber wants to periodically fetch the event state, it can select to only receive a notification if the event state has changed. The entity-tag in a Suppress-Notify-If-Match can have two forms: either it contains the entity-tag delivered to the subscriber in a previous NOTIFY, or it contains a special entity-tag value of "*", Niemi Expires April 26, 2007 [Page 9]
Internet-Draft Entity-tags in SIP Events October 2006 which in essence matches anything. Example: Suppress-Notify-If-Match: * This would always suppress the resulting NOTIFY, which simplifies subscriber operation for subscription refresh and termination, as they already work within the context of a specific subscription. Using the "*" value may also be useful with polling, e.g., to check the liveliness of an event resource. However, normally polls would supply the notifier with a valid entity-tag that they had previously received in a NOTIFY request. Example: Suppress-Notify-If-Match: 126572363 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" ":" entity-tag / "*" Suppress-Notify-If-Match = "Suppress-Notify-If-Match" ":" entity-tag / "*" ; entity-tag is defined in RFC3903. 7. Examples FIXME: Add examples 8. Open Issues o The applicability of subnot-etags to RLS subscriptions should be clarified. In particular, how does the entity-tag relate to RLMI vs. the resource state? Niemi Expires April 26, 2007 [Page 10]
Internet-Draft Entity-tags in SIP Events October 2006 o Entity-tag definition already allows "*"; yet we treat is as a special etag value to "match anything". Is this a problem? 9. IANA Considerations FIXME: Add this section. 10. Security Considerations FIXME: Add this section. 11. References 11.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. [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. 11.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 Niemi Expires April 26, 2007 [Page 11]
Internet-Draft Entity-tags in SIP Events October 2006 Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-10 (work in progress), August 2006. [10] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- Requena, "Functional Description of Event Notification Filtering", RFC 4660, September 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 April 26, 2007 [Page 12]
Internet-Draft Entity-tags in SIP Events October 2006 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, 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 provided by the IETF Administrative Support Activity (IASA). Niemi Expires April 26, 2007 [Page 13]