Network Working Group A. Niemi Internet-Draft Nokia Intended status: Standards Track May 2, 2007 Expires: November 3, 2007 An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification draft-ietf-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 November 3, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). 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 November 3, 2007 [Page 1] Internet-Draft Entity-tags for SIP Events May 2007 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 true, either the body of an event notification or the entire notification message is suppressed. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Document Conventions . . . . . . . . . . . . . . . . . . . 4 2. Motivations and Background . . . . . . . . . . . . . . . . . . 5 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Problem Description . . . . . . . . . . . . . . . . . . . 5 2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 4. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 10 4.1. Indicating Support for Entity Tags . . . . . . . . . . . . 10 4.2. Generating Conditional SUBSCRIBEs . . . . . . . . . . . . 10 4.3. Polling or Fetching Resource State . . . . . . . . . . . . 11 4.4. Resuming a Subscription . . . . . . . . . . . . . . . . . 13 4.5. Refreshing a Subscription . . . . . . . . . . . . . . . . 14 4.6. Terminating a Subscription . . . . . . . . . . . . . . . . 14 5. Notifier Behavior . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Generating Entity-tags . . . . . . . . . . . . . . . . . . 15 5.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 16 5.3. Suppressing NOTIFY Requests . . . . . . . . . . . . . . . 16 5.4. State Differentials . . . . . . . . . . . . . . . . . . . 17 5.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 17 6. Protocol Element Definitions . . . . . . . . . . . . . . . . . 17 6.1. 204 (No Notification) Response Code . . . . . . . . . . . 17 6.2. Suppress-Notify-If-Match Header Field . . . . . . . . . . 18 6.3. Suppress-Body-If-Match Header Field . . . . . . . . . . . 18 6.4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Open Issues and Todo . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8.1. "subnot-etags" Option Tag . . . . . . . . . . . . . . . . 19 8.2. 204 (No Notification) Response Code . . . . . . . . . . . 19 8.3. Suppress-Body-If-Match Header Field . . . . . . . . . . . 19 8.4. Suppress-Notify-If-Match Header Field . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Niemi Expires November 3, 2007 [Page 2] Internet-Draft Entity-tags for SIP Events May 2007 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Niemi Expires November 3, 2007 [Page 3] Internet-Draft Entity-tags for SIP Events May 2007 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 [6], message waiting indications [7] and registrations [8]. 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) [9], 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 14, RFC 2119 [2] and indicate requirement levels for compliant implementations. Niemi Expires November 3, 2007 [Page 4] Internet-Draft Entity-tags for SIP Events May 2007 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, the subscription is terminated. 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) URI (GRUU) [10] as a stable endpoint contact for subscriptions. 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 November 3, 2007 [Page 5] Internet-Draft Entity-tags for SIP Events May 2007 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 consumption 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 [9] 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 November 3, 2007 [Page 6] Internet-Draft Entity-tags for SIP Events May 2007 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 can include a "subnot-etags" tag in the Supported header field. 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 every NOTIFY request. The entity tag is unique for that particular resource and event notification. Entity-tags are independent of subscriptions; the notifier remembers the entity-tag of the resource state regardless of whether or not there are any active subscription to that resource. This allows notifications generated to a fetch or a poll to have valid entity- tags even across subsequent fetches of the resource state. The subscriber will store the entity-tag received in the notification along with the resource state. It can then later use this entity-tag to make a SUBSCRIBE contain a condition in the form of a header field. Unlike the "If-Match" condition in a PUBLISH [1] request, which applies to whether the PUBLISH succeeds or returns an error, this condition applies to the notifications that are sent after the SUBSCRIBE request has been processed. The two types of conditions available for a SUBSCRIBE are a Suppress- Body-If-Match and a Suppress-Notify-If-Match; each of these header fields contains the last entity-tag seen by the subscriber. If the condition evaluates to true, the first of these conditions will instruct the notifier to suppress the body of the next notification and the second the entire notification. The condition is evaluated by matching the value of the header field against the current entity- tag of the resource state. There is also a wildcard entity-tag with a special value of "*" that always matches. Niemi Expires November 3, 2007 [Page 7] Internet-Draft Entity-tags for SIP Events May 2007 Subscriber Notifier ---------- -------- (1) SUBSCRIBE --------> Supported: subnot-etags Expires: 3600 <-------- (2) 202 <-------- (3) NOTIFY SIP-ETag: ffee2 (4) 200 --------> ... (5) SUBSCRIBE --------> \ if "ffee2" Suppress-Notify-If-Match: ffee2 | matches Supported: subnot-etags | local Expires: 3600 | entity-tag | <-------- (6) 204 / then ... <-------- (7) NOTIFY SIP-ETag: ca89a (8) 200 --------> ... (9) SUBSCRIBE --------> \ if "ca89" Suppress-Notify-If-Match: ca89a | matches Supported: subnot-etags | local Expires: 0 | entity-tag | <-------- (10) 204 / then Figure 1: Example Message Flow Figure 1 describes a typical message flow for conditional SUBSCRIBEs: 1. The subscriber initiates a subscription by sending a SUBSCRIBE request for a resource. The request can contain a Supported tag of "subnot-etags" to indicate support for conditional subscriptions. 2. After proper authentication and authorization, the the notifier accepts the subscription. Niemi Expires November 3, 2007 [Page 8] Internet-Draft Entity-tags for SIP Events May 2007 3. The notifier then immediately sends the initial resource state in a notification. And since the subscriber supports the mechanism, it includes a resource-specific entity-tag in a SIP- ETag header field. 4. The subscriber accepts the notification and stores the entity- tag value along with the resource state. 5. Later, the subscriber refreshes the subscription by a reSUBSCRIBE, and includes an entity-tag in a Suppress-Notify-If- Match header field. 6. The notifier evaluates the condition by matching its entity-tag for the resource against the value of the Suppress-Notify-If- Match header field. If the condition evaluates to true, the notifier informs the subscriber that the notification was blocked. 7. At some point, the state of the resource changes, e.g., the presence status of a user changes from online to busy. This triggers an event notification with a new value in the SIP-ETag header field. 8. The subscriber accepts the notification and stores the new entity-tag along with the resource state. 9. After a while, the subscriber decides to terminate the subscription with an unSUBSCRIBE. It adds a condition for Suppress-Notify-If-Match, and includes the entity-tag it received in the previous NOTIFY. 10. The notifier evaluates the condition by matching its entity-tag for the resource against the value of the Suppress-Notify-If- Match header field. If the condition evaluates to true, the notifier informs the subscriber that the notification was blocked. This concludes the subscription. The benefit of using conditional subscriptions in this example is in the reduction of the number of NOTIFY requests the subscriber can expect to receive. Each event notification that the subscriber has already seen is blocked by the notifier. This example illustrates only one use case for the mechanism; the same principles can be used to optimize workflows related to other use cases of event notification. Niemi Expires November 3, 2007 [Page 9] Internet-Draft Entity-tags for SIP Events May 2007 4. Subscriber Behavior This section augments the subscriber behavior defined in RFC3265 [4]. It first discusses general issues related to indicating support for the mechanism (Section 4.1) and creating conditions in SUBSCRIBE requests (Section 4.2); it then describes the workflows for the main three use cases for making the subscription conditional. 4.1. Indicating Support for Entity Tags The mechanism defined in this memo 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 it in creating a conditional request. Unaware subscribers will simply ignore the entity-tag, make requests without conditions and receive the default treatment from the notifier. However, to explicitly advertise the support for conditional subscriptions, the subscriber MAY use the Supported header field in advertising support for receiving entity tags in notifications. Example: Supported: subnot-etags 4.2. Generating Conditional SUBSCRIBEs When creating a conditional SUBSCRIBE request, the subscriber MUST include a conditional header field including an entity-tag to the request. The condition is evaluated by comparing the entity-tag of the subscribed resource with the entity-tag carried in the conditional header field. If they match, the condition evaluates to true. Unlike the condition introduced for the SIP PUBLISH [1] method, these conditions do not apply to the SUBSCRIBE request itself, but to the resulting NOTIFY request. When true, the condition drives the notifier to change its behavior with regards to sending the first notification after the SUBSCRIBE. There are two types of conditional header fields defined in this specification: Niemi Expires November 3, 2007 [Page 10] Internet-Draft Entity-tags for SIP Events May 2007 Suppress-Body-If-Match: if this condition evaluates to true, the notifier is instructed to suppress (i.e., remove) the body of the first NOTIFY request following the SUBSCRIBE. If false, the notifier follows the default behavior. Suppress-Notify-If-Match: if this condition evaluates to true, the notifier is instructed to suppress (i.e., block) the entire first NOTIFY request following the SUBSCRIBE, and instead send a 204 (No Notification) response. If false, the notifier again follows the default behavior. The value of these header-fields is an entity-tag, which is an opaque token that the subscriber simply copies from a previously received NOTIFY request. Examples: Suppress-Body-If-Match: b4cf7 Suppress-Notify-If-Match: 628736 The conditional header field can also be wildcarded using the special "*" entity-tag value. Such a condition always evaluates to true regardless of the value of the current entity-tag for the resource. Example: Suppress-Notify-If-Match: * 4.3. Polling or Fetching Resource State Polling with conditional notification allows a user agent to efficiently poll resource state. This is accomplished using the Suppress-Notify-If-Match condition: Niemi Expires November 3, 2007 [Page 11] Internet-Draft Entity-tags for SIP Events May 2007 Subscriber Notifier ---------- -------- (1) SUBSCRIBE --------> Supported: subnot-etags Expires: 0 <-------- (2) 202 <-------- (3) NOTIFY SIP-ETag: f2e45 (4) 200 --------> ... poll interval elapses (5) SUBSCRIBE --------> Supported: subnot-etags Suppress-Notify-If-Match: f2e45 Expires: 0 <-------- (6) 204 Figure 2: Polling Resource State 1. The subscriber polls for resource state by sending a SUBSCRIBE with zero expiry (expires immediately). 2. The notifier accepts the SUBSCRIBE with a 202 (Accepted) response. 3. The notifier then immediately sends a first (and last) NOTIFY request with the current resource state, and the current entity- tag in the SIP-ETag header field. 4. The subsciber accepts the notification with a 200 (OK) response. 5. After some arbitrary poll interval, the subscriber sends another SUBSCRIBE with a Suppress-Notify-If-Match header field that includes the entity-tag received in the previous NOTIFY. 6. Since the resource state has not changed since the previous poll occurred, the notifier sends a 204 (No Notification) response, which concludes the poll. Fetching resource state using conditional notification and the Niemi Expires November 3, 2007 [Page 12] Internet-Draft Entity-tags for SIP Events May 2007 wildcard entity-tag allows two other types of operations as well: Liveliness check: this allows a user agent to periodically check whether a resource is still available. This is accomplished using the Suppress-Notify-If-Match header field and the wildcard entity- tag. Meta-information query: this allows a user agent to query the latest meta-information related to a resource. This is accomplished using the Suppress-Body-If-Match header field and the wildcard entity-tag. 4.4. Resuming a Subscription Resuming a subscription means the ability to continue an earlier subscription that either closed abruptly, or was explicitly terminated. When resuming, the subscription is established without transmitting the resource state. This is accomplished with conditional notification and the Suppress-Body-If-Match header field: Subscriber Notifier ---------- -------- (1) SUBSCRIBE --------> Supported: subnot-etags Suppress-Body-If-Match: ega23 Expires: 3600 <-------- (2) 202 <-------- (3) NOTIFY SIP-ETag: ega23 Content-Length: 0 (4) 200 --------> Figure 3: Resuming a Subscription 1. The subscriber attempts to resume an earlier subscription by including a Suppress-Body-If-Match header field with the entity- tag it last received. 2. The notifier accepts the subscription after proper authentication and authorization, by sending a 202 (Accepted) (Accepted) response. 3. The notifier then immediately sends an initial NOTIFY request that now has no body. It also mirrors the current entity-tag of Niemi Expires November 3, 2007 [Page 13] Internet-Draft Entity-tags for SIP Events May 2007 the resource in the SIP-ETag header field. 4. The subscriber accepts the NOTIFY and sends a 200 (OK) response. Had the entity-tag not been valid any longer, the condition would have evaluated to false, and the NOTIFY would have had a body containing the latest resource state. 4.5. Refreshing a Subscription To refresh a subscription using conditional notification, the subscriber creates a subscription refresh before the subscription is about to expire, and uses the Suppress-Notify-If-Match header field: Subscriber Notifier ---------- -------- (1) SUBSCRIBE --------> Supported: subnot-etags Suppress-Notify-If-Match: aba91 Expires: 3600 <-------- (2) 204 Expires: 3600 Figure 4: Refreshing a Subscription 1. Before the subscription is about to expire, the subscriber sends a SUBSCRIBE request that includes the Suppress-Notify-If-Match header field with the latest entity-tag it has seen. 2. If the condition evaluates to true, the notifier sends a 204 (No Notification) response sends no NOTIFY request. The Expires header field of the 204 (No Notification) indicates the new expiry time. 4.6. Terminating a Subscription To terminate a subscription using conditional notification, the subscriber creates a SUBSCRIBE request with a Suppress-Notify-If- Match condition: Niemi Expires November 3, 2007 [Page 14] Internet-Draft Entity-tags for SIP Events May 2007 Subscriber Notifier ---------- -------- (1) SUBSCRIBE --------> Supported: subnot-etags Suppress-Notify-If-Match: ega23 Expires: 0 <-------- (2) 204 Figure 5: Terminating a Subscription 1. The subscriber decides to terminate the subscription and sends a SUBSCRIBE request with the Suppress-Notify-If-Match condition with the entity-tag it has last seen. 2. If the condition evaluates to true, the notifier sends a 204 (No Notification) response, which concludes the subscription, and the subscriber can clear all state related to the subscription. 5. Notifier Behavior This section augments the notifier behavior as specified in RFC3265 [4]. 5.1. Generating Entity-tags A notifier MUST generate entity tags for each resource it is responsible for. The views might correspond to different groups of users that have varying levels of access rights to the resource state, or to subscribers that have modified their subscription using event notification filtering [11]. For example, in presence [6] watchers may get different levels of accuracy in geolocation information, based on the presentity's privacy settings. An entity-tag is a token carried in the SIP-ETag header field, and it is opaque to the client. The notifier is free to decide the means for generating an entity-tag, except for the special "*" value. 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. An entity-tag is valid for as long as the resource state is valid. The notifier MUST remember the entity-tag of a resource as long as Niemi Expires November 3, 2007 [Page 15] Internet-Draft Entity-tags for SIP Events May 2007 the associated resource state is valid. The notifier MAY remember the entity-tag longer than this, e.g., for implementing journaled state differentials (Section 5.4). 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 sources to the event composition process. 5.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. That is, the resulting NOTIFY contains no Content-Type header field, the Content-Length is 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. A Suppress-Body-If-Match header field that includes an entity-tag with the value of "*" MUST always evaluate to true. 5.3. Suppressing NOTIFY Requests When a condition in a SUBSCRIBE request to suppress a NOTIFY request is true, i.e., the local entity-tag of the resource and the entity- tag in a Suppress-Notify-If-Match header field of a SUBSCRIBE request match, the notifier MUST suppress the resulting NOTIFY request, and generate a 204 (No Notification) "No Notification" response. Such a successful conditional SUBSCRIBE request MUST extend the subscription expiry time. Suppressing the entire NOTIFY has no effect on the entity-tag of the resource. In other words, it remains unchanged. A Suppress-Body-If-Match header field that includes an entity-tag with the value of "*" MUST always evaluate to true. Niemi Expires November 3, 2007 [Page 16] Internet-Draft Entity-tags for SIP Events May 2007 5.4. State Differentials Some event packages may support a scheme where notifications contain state differentials, or state deltas [4] instead of complete resource state. 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. When state differentials are sent, the SIP-ETag header field MUST contain an entity-tag that corresponds to the full resource state. 5.5. List Subscriptions OPEN ISSUE: What approach should we take in defining how conditional notification works in RLSs? Seems there are roughly three different approaches: 1. Treat meta-information as independent of the actual resource state, don't apply conditional notification to meta-information at all. 2. Treat everything as a single resource, and update the etag whenever either meta or real info changes. 3. Have separate etags for meta and real information. 6. Protocol Element Definitions This section describes the protocol extensions required for conditional notification. 6.1. 204 (No Notification) Response Code The 204 (No Notification) response code indicates that the request was successful, but the notification associated with the request will not be sent. The response code is added to the "Success" production rule in the SIP [3] message grammar. Niemi Expires November 3, 2007 [Page 17] Internet-Draft Entity-tags for SIP Events May 2007 6.2. Suppress-Notify-If-Match Header Field The Suppress-Notify-If-Match header field is added to the definition of the "message-header" rule in the SIP [3] grammar. Its use is described in Section 4 and Section 5.3. This header field is allowed to appear in any request, but it's behavior is only defined for the SUBSCRIBE request. 6.3. Suppress-Body-If-Match Header Field The Suppress-Body-If-Match header field is added to the definition of the "message-header" rule in the SIP [3] grammar. Its use is described in Section 4 and Section 5.2. This header field is allowed to appear in any request, but it's behavior is only defined for the SUBSCRIBE request. 6.4. Grammar This section defines the formal syntax for extensions described in this memo in Augmented BNF (ABNF) [5]. The rules defined here augment and reference the syntax defined in RFC3261 [3] and RFC3903 [1]. Success =/ "204" ; No Notification ; Success is defined in RFC3261. 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. Open Issues and Todo 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 November 3, 2007 [Page 18] Internet-Draft Entity-tags for SIP Events May 2007 o Should add detailed examples of all of the different use cases for conditional notification presented in this document. 8. IANA Considerations This document registers a new SIP option-tag, a new response code and two new header field names. Note to IANA and the RFC editor: please replace all occurrences of RFCXYZ in this section with the RFC number of this specification upon publication. 8.1. "subnot-etags" Option Tag This document registers a new SIP option tag. This option tag is defined by the following information, which has been added to the option-tags sub-registry under http://www.iana.org/assignments/sip-parameters. +--------------+----------------------------------------+-----------+ | Name | Description | Reference | +--------------+----------------------------------------+-----------+ | subnot-etags | This option tag indicates support for | [RFCXYZ] | | | entity-tags and conditional | | | | notifications in SIP events. | | +--------------+----------------------------------------+-----------+ 8.2. 204 (No Notification) Response Code This document registers a new response code. This response code is defined by the following information, which has been added to the methods and response-codes sub-registry under http://www.iana.org/assignments/sip-parameters. This information is to be added under "Successful 2xx" category. +---------------------+-----------+ | Response Code | Reference | +---------------------+-----------+ | 204 No Notification | [RFCXYZ] | +---------------------+-----------+ 8.3. Suppress-Body-If-Match Header Field This document registers two new SIP header field names. These headers are defined by the following information, which has been added to the header fields sub-registry under Niemi Expires November 3, 2007 [Page 19] Internet-Draft Entity-tags for SIP Events May 2007 http://www.iana.org/assignments/sip-parameters. +------------------------+---------+-----------+ | Header Name | Compact | Reference | +------------------------+---------+-----------+ | Suppress-Body-If-Match | | [RFCXYZ] | +------------------------+---------+-----------+ 8.4. Suppress-Notify-If-Match Header Field This document registers two new SIP header field names. These headers are defined by the following information, which has been added to the header fields sub-registry under http://www.iana.org/assignments/sip-parameters. +--------------------------+---------+-----------+ | Header Name | Compact | Reference | +--------------------------+---------+-----------+ | Suppress-Notify-If-Match | | [RFCXYZ] | +--------------------------+---------+-----------+ 9. Security Considerations The security considerations for SIP event notification are extensively discussed in RFC 3265 [4]. This specification introduces an optimization to SIP event notification, which in itself does not alter the security properties of the protocol. 10. Acknowledgments The following people have contributed corrections and suggestions to this document: Adam Roach, Sean Olson, Johnny Vrancken, Pekka Pessi, Eva Leppanen, Krisztian Kiss, Peili Xu, Avshalom Houri, David Viamonte and the SIP and SIMPLE working groups. 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. Niemi Expires November 3, 2007 [Page 20] Internet-Draft Entity-tags for SIP Events May 2007 [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. [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. 11.2. Informative References [6] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. [7] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004. [8] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004. [9] 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. [10] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-12 (work in progress), March 2007. [11] 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 P.O. Box 407 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 389 1644 Email: aki.niemi@nokia.com Niemi Expires November 3, 2007 [Page 21] Internet-Draft Entity-tags for SIP Events May 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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 November 3, 2007 [Page 22]