idnits 2.17.1 draft-ietf-sipcore-subnot-etags-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 21, 2009) is 5483 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXYZ' is mentioned on line 987, but not defined ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Session Initiation Protocol A. Niemi 3 Working Group Nokia 4 Internet-Draft April 21, 2009 5 Intended status: Standards Track 6 Expires: October 23, 2009 8 An Extension to Session Initiation Protocol (SIP) Events for Conditional 9 Event Notification 10 draft-ietf-sipcore-subnot-etags-01 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on October 23, 2009. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 The Session Initiation Protocol (SIP) events framework enables 59 receiving asynchronous notification of various events from other SIP 60 user agents. This framework defines the procedures for creating, 61 refreshing and terminating subscriptions, as well as fetching and 62 periodic polling of resource state. These procedures provide no 63 tools to avoid replaying event notifications that have already been 64 received by a user agent. This memo defines an extension to SIP 65 events that allows the subscriber to condition the subscription 66 request to whether the state has changed since the previous 67 notification was received. When such a condition is true, either the 68 body of a resulting event notification or the entire notification 69 message is suppressed. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1. Document Conventions . . . . . . . . . . . . . . . . . . . 5 75 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Motivations and Background . . . . . . . . . . . . . . . . . . 5 77 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 2.2. Problem Description . . . . . . . . . . . . . . . . . . . 5 79 2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 80 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 81 4. Resource Model for Entity-Tags . . . . . . . . . . . . . . . . 11 82 5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 13 83 5.1. Detecting Support for Conditional 84 Notification . . . . . . . . . . . . . . . . . . . . . . . 13 85 5.2. Generating SUBSCRIBE Requests . . . . . . . . . . . . . . 14 86 5.3. Receiving NOTIFY Requests . . . . . . . . . . . . . . . . 15 87 5.4. Polling or Fetching Resource State . . . . . . . . . . . . 15 88 5.5. Resuming a Subscription . . . . . . . . . . . . . . . . . 17 89 5.6. Refreshing a Subscription . . . . . . . . . . . 18 90 5.7. Terminating a Subscription . . . . . . . . . . . . . 18 91 5.8. Handling Transient Errors . . . . . . . . . . . . . . . . 19 92 6. Notifier Behavior . . . . . . . . . . . . . . . . . . . . . . 19 93 6.1. Generating Entity-tags . . . . . . . . . . . . . . . . . . 20 94 6.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 20 95 6.3. Suppressing NOTIFY Requests . . . . . . . . . . 21 96 6.4. State Differentials . . . . . . . . . . . . . . . . . . . 21 97 6.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 21 98 7. Protocol Element Definitions . . . . . . . . . . . . . . . . . 22 99 7.1. 204 (No Notification) Response Code . . . . . . . . . . . 22 100 7.2. Suppress-If-Match Header Field . . . . . . . . . 22 101 7.3. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 103 8.1. 204 (No Notification) Response Code . . . . . . . . . . . 23 104 8.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 23 105 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 106 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 108 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 109 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 110 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 112 1. Introduction 114 The Session Initiation Protocol (SIP) events framework provides an 115 extensible facility for requesting notification of certain events 116 from other SIP user agents. This framework includes procedures for 117 creating, refreshing and terminating of subscriptions, as well as the 118 possibility to fetch or periodically poll the event resource. 120 Several instantiations of this framework, called event packages have 121 been defined, e.g., for presence [RFC3856], message waiting 122 indications [RFC3842] and registrations [RFC3680]. 124 By default, every SUBSCRIBE request generates a NOTIFY request 125 containing the latest event state. Typically, a SUBSCRIBE request is 126 issued by the subscriber whenever it needs a subscription to be 127 installed, periodically refreshed or terminated. Once the 128 subscription has been installed, the majority of the NOTIFYs 129 generated by the subscription refreshes are superfluous; the 130 subscriber usually is in possession of the event state already, 131 except in the unlikely case where a state change exactly coincides 132 with the periodic subscription refresh. In most cases, the final 133 event state generated upon terminating the subscription similarly 134 contains resource state that the subscriber already has. 136 Fetching or polling of resource state behaves in a similarly 137 suboptimal way in cases where the state has not changed since the 138 previous poll occurred. In general, the problem lies in with the 139 inability to persist state across a SUBSCRIBE request. 141 This memo defines an extension to optimize the SIP events framework. 142 This extension allows a notifier to tag notifications (called entity- 143 tags hereafter), and the subscriber to condition its subsequent 144 SUBSCRIBE requests for actual changes since a notification carrying 145 that entity-tag was issued. The solution is almost identical to 146 conditional requests defined in the HyperText Transfer Protocol 147 (HTTP) [RFC2616], and follows the mechanism already defined for the 148 PUBLISH [RFC3903] method for issuing conditional event publications. 150 This memo is structured as follows. Section 2 explains the 151 background, motivations and requirements for the work; Section 3 152 gives a general overview of the mechanism; Section 4 explains the 153 underlying model for resources and entities as they apply to 154 conditional notification; Section 5 defines the subscriber behavior; 155 Section 6 defines the notifier behavior; Section 7 includes the 156 protocol element definitions; Section 8 includes the IANA 157 considerations; and Section 9 includes the security considerations. 159 1.1. Document Conventions 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in BCP 14, RFC 2119 164 [RFC2119] and indicate requirement levels for compliant 165 implementations. 167 1.2. Terminology 169 In addition to the terminology introduced in [RFC3261], [RFC3265] and 170 [RFC3903], this specification uses these additional terms to describe 171 the objects of conditional notification: 173 resource 174 An object identified by a URI, whose resource state can be 175 accessed using the SIP Event Notification framework. There is a 176 single authoritative notifier responsible for communicating the 177 resource state. 179 entity 180 The representation of resource state. An entity consists of the 181 event data carried in the body of a NOTIFY message, as well as 182 related meta-data in the message header. There may be many 183 versions of an entity, one current and the others stale. Each 184 version of an entity is identified by an entity-tag, which is 185 guaranteed to be unique across all versions of all entities for a 186 resource and event package. 188 2. Motivations and Background 190 2.1. Overview 192 A SUBSCRIBE request creates a subscription with a finite lifetime. 193 This lifetime is negotiated using the Expires header field, and 194 unless the subscription is refreshed by the subscriber before the 195 expiration is met, the subscription is terminated. The frequency of 196 these subscription refreshes depends on the event package, and 197 typically ranges from minutes to hours. 199 2.2. Problem Description 201 In spite of being somewhat distinct operations, the SIP events 202 framework does not include different protocol methods for initiating 203 and terminating of subscriptions, subscription refreshes and fetches 204 inside and outside of the SIP dialog. Instead, the SUBSCRIBE method 205 is overloaded to perform all of these functions, and the notifier 206 behavior is identical in each of them; each SUBSCRIBE request 207 generates a NOTIFY request containing the latest resource state. In 208 fact, the only difference between a fetch that does not create a 209 (lasting) subscription, and a SUBSCRIBE that creates one is in the 210 Expires header field value of the SUBSCRIBE; a zero-expiry SUBSCRIBE 211 only generates a single NOTIFY, after which the subscription 212 immediately terminates. 214 Some subscriber implementations may choose to operate in semi- 215 stateless mode, in which they immediately upon receiving and 216 processing the NOTIFY forget the resource state. This operation 217 necessarily needs every NOTIFY to carry the full resource state. 218 However, for an implementation that stores the resource state 219 locally, this mode of operation is inefficient. 221 There are certain conditions that aggravate the problem. Such 222 conditions usually entail such things as: 224 o Large entity bodies in the payloads of notifications 226 o High rate of subscription refreshes 228 o Relatively low rate of notifications triggered by state changes 230 In effect, for an event package that generates few state changes, and 231 is refreshed relatively often the majority of traffic generated may 232 be related to subscription maintenance. Especially in networks where 233 bandwidth consumption and traffic count is at a premium, the high 234 overhead of subscription maintenance becomes a barrier for 235 deployment. 237 The same problem affects fetching and polling of resource state as 238 well. As a benchmark, if we look at the performance of HTTP 239 [RFC2616] in similar scenarios, it performs substantially better 240 using conditional requests. When resources are tagged with an 241 entity-tag, and each GET is a conditional one using the "If-None- 242 Match" header field, the entity body need not be sent more than once; 243 if the resource has not changed between successive polls, an error 244 response is returned indicating this fact, and the resource entity is 245 not transmitted again. 247 The SIP PUBLISH [RFC3903] method also contains a similar feature, 248 where a refresh of a publication is done by reference to its assigned 249 entity-tag, instead of retransmitting the event state each time the 250 publication expiration is extended. 252 2.3. Requirements 254 As a summary, here is the required functionality to solve the 255 presented issues: 257 REQ1: It must be possible to suppress the NOTIFY request (or at a 258 minimum the event body therein) if the subscriber is already 259 in possession of the latest event state of the resource. 261 REQ2: This mechanism must apply to initial subscriptions, in which 262 the subscriber is attempting to "resume" an earlier 263 subscription. 265 REQ3: This mechanism must apply to refreshing a subscription. 267 REQ4: This mechanism must apply to terminating a subscription 268 (i.e., an unsubscribe). 270 REQ5: This mechanism must apply to fetching or polling of resource 271 state. 273 3. Overview of Operation 275 Whenever a subscriber initiates a subscription, it issues a SUBSCRIBE 276 request. The SUBSCRIBE request is sent, routed and processed by the 277 notifier normally, i.e., according to RFC3261 [RFC3261], RFC3265 278 [RFC3265]. 280 If the notifier receiving the SUBSCRIBE request supports conditional 281 subscriptions, it generates a unique entity tag for the event 282 notification, and includes it in a SIP-ETag header field of the 283 NOTIFY request. The entity tag is unique across all versions of all 284 entities for a resource and event package. More on this in 285 Section 4. 287 Entity-tags are independent of subscriptions; the notifier remembers 288 the entity-tags of all versions of entities for a resource regardless 289 of whether or not there are any active subscription to that resource. 290 This allows notifications generated to a fetch or a poll to have 291 valid entity-tags even across subsequent fetches or polls. 293 The subscriber will store the entity-tag received in the notification 294 along with the resource state. It can then later use this entity-tag 295 to make a SUBSCRIBE contain a condition in the form of a "Suppress- 296 If-Match" header field. Unlike the "If-Match" condition in a PUBLISH 297 [RFC3903] request, which applies to whether the PUBLISH succeeds or 298 returns an error, this condition applies to the stream of 299 notifications that are sent after the SUBSCRIBE request has been 300 processed. 302 The "Suppress-If-Match" header field contains the last entity-tag 303 seen by the subscriber. This condition, if true, instructs the 304 notifier to suppress either the body of a subsequent notification, or 305 the entire notification. 307 The condition is evaluated by matching the value of the header field 308 against the current entity-tag of the resource state. There is also 309 a wildcard entity-tag with a special value of "*" that always 310 matches. 312 Subscriber Notifier 313 ---------- -------- 315 (1) SUBSCRIBE --------> 316 Expires: 3600 317 <-------- (2) 200 (or 202) 319 <-------- (3) NOTIFY 320 Subscription-State: active 321 SIP-ETag: ffee2 322 (4) 200 --------> 324 ... time passes ... 326 (5) SUBSCRIBE --------> \ if "ffee2" 327 Suppress-If-Match: ffee2 | matches 328 Expires: 3600 | local 329 | entity-tag 330 | 331 <-------- (6) 204 / then 333 ... time passes ... 335 <-------- (7) NOTIFY 336 Subscription-State: active 337 SIP-ETag: ca89a 338 (8) 200 --------> 340 ... time passes ... 342 (9) SUBSCRIBE --------> \ if "ca89" 343 Suppress-If-Match: ca89a | matches 344 Expires: 0 | local 345 | entity-tag 346 | 347 <-------- (10) 204 / then 349 Figure 1: Example Message Flow 351 Figure 1 describes a typical message flow for conditional 352 notification: 354 1. The subscriber initiates a subscription by sending a SUBSCRIBE 355 request for a resource. 357 2. After proper authentication and authorization, the notifier 358 accepts the subscription. 360 3. The notifier then immediately sends the initial event 361 notification, including a unique entity-tag in a SIP-ETag header 362 field. 364 4. The subscriber accepts the notification and stores the entity- 365 tag value along with the resource state. 367 5. Later, the subscriber refreshes the subscription, and includes 368 an entity-tag in a Suppress-If-Match header field. 370 6. The notifier evaluates the condition by matching its local 371 entity-tag value for the resource against the value of the 372 Suppress-If-Match header field. If the condition evaluates to 373 true, the notifier informs the subscriber that the notification 374 will not be sent. 376 7. At some point, the state of the resource changes, e.g., the 377 presence status of a user changes from online to busy. This 378 triggers an event notification with a new value in the SIP-ETag 379 header field. 381 8. The subscriber accepts the notification and stores the new 382 entity-tag along with the resource state. 384 9. After a while, the subscriber decides to terminate the 385 subscription. It adds a condition for Suppress-If-Match, and 386 includes the entity-tag it received in the previous NOTIFY. 388 10. The notifier evaluates the condition by matching its entity-tag 389 for the resource against the value of the Suppress-If-Match 390 header field. If the condition evaluates to true, the notifier 391 informs the subscriber that no notification will be sent. This 392 concludes the subscription. 394 The benefit of using conditional notification in this example is in 395 the reduction of the number of NOTIFY requests the subscriber can 396 expect to receive. Each event notification that the subscriber has 397 already seen is suppressed by the notifier. This example illustrates 398 only one use case for the mechanism; the same principles can be used 399 to optimize the flow of messages related to other event notification 400 use cases. 402 4. Resource Model for Entity-Tags 404 The key to understanding how conditional notification works is 405 understanding the underlying resource model of event notification. 406 In general, this model is similar to the resource model of HTTP with 407 some key differences. This section explains in detail the model as 408 it applies to SIP events. Figure 2 illustrates the model. 410 +-----+ 411 ............ | | 412 . . | URI | 413 . Represen . | | 414 . tation . +-----+ 415 . . |* 416 ............ | 417 . | 418 . V 419 . +----------+ +---------+ 420 composition | |* | Event | 421 +------<>| Resource |----------->| Package |<----. 422 | | | | | | 423 | +----------+ +----.----+ | 424 | /_\ | 425 |* | classification 426 +--------+ | | 427 | | .----------------.------' | 428 | Entity | | | | 429 | | | | |* 430 +--------+ +----------+ +------------+ +----------+ 431 ^ | | | | | | 432 | | Presence | | Conference | | Template | 433 | | | | | | | 434 |1..* +----------+ +------------+ +----.-----+ 435 +---------+ /_\ 436 | | | 437 | Version | | 438 | | +---------+ 439 +---------+ | Watcher | 440 |1 | Info | 441 | | | 442 | +---------+ 443 V 444 +---------+ 445 | Entity- | 446 | Tag | 447 | | 448 +---------+ 449 Figure 2: Resource Model Diagram 451 For a given event package, there is a single authoritative agent 452 responsible for zero or more resources. That is, even for a 453 distributed agent, the resource state is uniform across all 454 instances. The resource itself can be a list of resources [RFC4662]. 455 Conditional notification for list subscriptions is addressed in 456 Section 6.5. 458 A resource is identified by zero or more URIs, which can be SIP URIs, 459 pres URIs [RFC3859] or similar. Subscribers use this URI to 460 subscribe to the resource for certain types of events, identified by 461 the event package. 463 With a successful subscription, a subscriber receives event 464 notifications that communicate the resource state and the changes 465 thereto. Each event notification carries a representation of the 466 current resource state. This representation is influenced by many 467 factors, e.g., authorization and filtering rules, and the event 468 composition rules of the notifier. 470 This representation is realized in what is called an entity. Each 471 resource may be associated with zero or more entities; however, an 472 entity is only valid for a single resource. 474 Note that, as can be seen from the illustration, the association 475 between a resource and an entity follows the typical composition 476 relationship, i.e., an entity may belong to only one resource, and 477 it is expected to only exist with that resource. 479 An entity consists of the data carried in the body of a NOTIFY 480 message, and related meta-data in the message header. This meta-data 481 includes, but is not limited to the following SIP header fields: 483 entity-header = Content-Disposition ; defined in RFC 3261 484 / Content-Encoding ; defined in RFC 3261 485 / Content-Language ; defined in RFC 3261 486 / Content-Length ; defined in RFC 3261 487 / Content-Type ; defined in RFC 3261 488 / Event ; defined in RFC 3265 489 / extension-header ; defined in RFC 3261 491 Note that the Subscription-State is explicitly not part of the 492 entity. Event packages may in the future define additional fields 493 that implementations need to consider as part of the entity. 495 An entity has one or more versions of which only one is current and 496 all others stale. Each version has an entity-tag, which uniquely 497 identifies it across all versions of all entities pertaining to a 498 single resource and event package. 500 Note that two entity-tags being equal does not indicate identical 501 entities. In other words, if an entity-tag is received that matches 502 a previously seen entity-tag, the subscriber cannot assume the event 503 state to be identical to that received earlier. 505 With partial event notification, the NOTIFY message only carries the 506 delta state, or the set of changes to the previous version of the 507 entity. In that case, implementations MUST consider the full event 508 state as the version of the entity to which the entity-tag in the 509 NOTIFY message applies. 511 The conditional notification mechanism is independent of the way in 512 which subscriptions are installed. In other words, the mechanism 513 supports implicit subscriptions, such as those associated with the 514 REFER method [RFC3515]. 516 It is possible that the same resource is in some shape or form 517 accessible through another mechanism in addition to SIP Event 518 Notification, e.g., HTTP or the SIP PUBLISH method. In general, 519 implementations MUST NOT expect the entity-tags to be shared between 520 the mechanisms, unless event packages or specific applications of SIP 521 Events explicitly define such dependencies. 523 5. Subscriber Behavior 525 This section augments the subscriber behavior defined in RFC3265 526 [RFC3265]. It first discusses general issues related to indicating 527 support for the mechanism (Section 5.1) and creating conditions in 528 SUBSCRIBE requests (Section 5.2); it then describes the workflows for 529 the main three use cases for making the subscription conditional. 531 5.1. Detecting Support for Conditional Notification 533 The mechanism defined in this memo is backwards compatible with SIP 534 events [RFC3265] in that a notifier supporting this mechanism will 535 insert a SIP entity-tag in its NOTIFY requests, and a subscriber that 536 understands this mechanism will know how to use it in creating a 537 conditional request. 539 Unaware subscribers will simply ignore the entity-tag, make requests 540 without conditions and receive the default treatment from the 541 notifier. Unaware notifiers will simply ignore the conditional 542 header fields, and continue normal operation. 544 5.2. Generating SUBSCRIBE Requests 546 When creating a conditional SUBSCRIBE request, the subscriber MUST 547 include a single conditional header field including an entity-tag in 548 the request. The condition is evaluated by comparing the entity-tag 549 of the subscribed resource with the entity-tag carried in the 550 conditional header field. If they match, the condition evaluates to 551 true. 553 Unlike the condition introduced for the SIP PUBLISH [RFC3903] method, 554 these conditions do not apply to the SUBSCRIBE request itself, but to 555 the resulting NOTIFY requests. When true, the condition drives the 556 notifier to change its behavior with regards to sending the 557 notifications after the SUBSCRIBE. 559 This specification defines a new header field called "Suppress-If- 560 Match". This header field introduces a condition to the SUBSCRIBE 561 request. If true, it instructs the notifier to either omit the body 562 of the resulting NOTIFY message (if the SUBSCRIBE is not sent within 563 an existing dialog), or suppress (i.e., block) the NOTIFY request 564 that would otherwise be triggered the SUBSCRIBE (for an established 565 dialog). In the latter case, the SUBSCRIBE message will be answered 566 with a 204 (No Notification) response. As long as the condition 567 remains true, it also instructs the notifier to either suppress any 568 subsequent NOTIFY request, or if there are reportable changes in the 569 NOTIFY header, e.g., the Subscription-State has changed, suppress the 570 body of any subsequent NOTIFY request. 572 If the condition is false, the notifier follows its default 573 behaviour. 575 If the subscriber receives a 204 (No Notification) to an in-dialog 576 SUBSCRIBE, the subscriber can clear handle that it may have had 577 pending on a NOTIFY in response the SUBSCRIBE message. 579 The value of the "Suppress-If-Match" header field is an entity-tag, 580 which is an opaque token that the subscriber simply copies from a 581 previously received NOTIFY request. 583 Example: 585 Suppress-If-Match: b4cf7 587 The header field can also be wildcarded using the special "*" entity- 588 tag value. Such a condition always evaluates to true regardless of 589 the value of the current entity-tag for the resource. 591 Example: 593 Suppress-If-Match: * 595 Such a wildcard condition effectively quenches a subscription; the 596 only notifications received are those reporting changes to the 597 subscription state and those in response to a SUBSCRIBE message sent 598 outside of an existing dialog. In both cases, the notifications will 599 not contain a body. 601 A subscription with a wildcard "Suppress-If-Match" condition is 602 useful in scenarios where the subscriber wants to temporarily put 603 a subscription in dormant mode. For example, a host may want to 604 conserve bandwidth and power when it detects from screen or input 605 device inactivity that the user isn't actively monitoring the 606 presence statuses of contacts. 608 5.3. Receiving NOTIFY Requests 610 When a subscriber receives a NOTIFY request that contains a SIP-ETag 611 header field, it MUST store the entity-tag if it wishes to make use 612 of the conditional notification mechanism. The subscriber MUST be 613 prepared to receive a NOTIFY with any entity-tag value, including a 614 value that matches any previous value that the subscriber might have 615 seen. 617 The subscriber MUST NOT infer any meaning from the value of an 618 entity-tag; specifically, the subscriber MUST NOT assume identical 619 entities (i.e., event state) for NOTIFYs with identical entity-tag 620 values. 622 Note that there are valid cases for which identical entity-tag 623 values indeed imply identical event state. For example, it is 624 possible to generate entity-tag values using a one-way hash 625 function. 627 5.4. Polling or Fetching Resource State 629 Polling with conditional notification allows a user agent to 630 efficiently poll resource state. This is accomplished using the 631 Suppress-If-Match condition: 633 Subscriber Notifier 634 ---------- -------- 636 (1) SUBSCRIBE --------> 637 Expires: 0 638 <-------- (2) 202 640 <-------- (3) NOTIFY 641 Subscription-State: terminated 642 SIP-ETag: f2e45 643 Content-Length: 17539 645 (4) 200 --------> 647 ... poll interval elapses ... 649 (5) SUBSCRIBE --------> 650 Suppress-If-Match: f2e45 651 Expires: 0 652 <-------- (6) 202 654 <-------- (7) NOTIFY 655 Subscription-State: terminated 656 SIP-ETag: f2e45 657 Content-Length: 0 659 (8) 200 --------> 661 Figure 3: Polling Resource State 663 1. The subscriber polls for resource state by sending a SUBSCRIBE 664 with zero expiry (expires immediately). 666 2. The notifier accepts the SUBSCRIBE with a 202 (Accepted) 667 response. 669 3. The notifier then immediately sends a first (and last) NOTIFY 670 request with the current resource state, and the current entity- 671 tag in the SIP-ETag header field. 673 4. The subscriber accepts the notification with a 200 (OK) response. 675 5. After some arbitrary poll interval, the subscriber sends another 676 SUBSCRIBE with a Suppress-If-Match header field that includes the 677 entity-tag received in the previous NOTIFY. 679 6. The notifier accepts the SUBSCRIBE with a 202 (Accepted) 680 response. 682 7. Since the resource state has not changed since the previous poll 683 occurred, the notifier sends a NOTIFY message with no body. It 684 also mirrors the current entity-tag of the resource in the SIP- 685 ETag header field. 687 8. The subscriber accepts the notification with a 200 (OK) response. 689 5.5. Resuming a Subscription 691 Resuming a subscription means the ability to continue an earlier 692 subscription that either closed abruptly, or was explicitly 693 terminated. When resuming, the subscription is established without 694 transmitting the resource state. This is accomplished with 695 conditional notification and the Suppress-If-Match header field: 697 Subscriber Notifier 698 ---------- -------- 700 (1) SUBSCRIBE --------> 701 Suppress-If-Match: ega23 702 Expires: 3600 703 <-------- (2) 202 705 <-------- (3) NOTIFY 706 Subscription-State: active 707 SIP-ETag: ega23 708 Content-Length: 0 709 (4) 200 --------> 711 Figure 4: Resuming a Subscription 713 1. The subscriber attempts to resume an earlier subscription by 714 including a Suppress-If-Match header field with the entity-tag it 715 last received. 717 2. The notifier accepts the subscription after proper authentication 718 and authorization, by sending a 202 (Accepted) response. 720 3. Since the condition is true, the notifier then immediately sends 721 an initial NOTIFY request that has no body. It also mirrors the 722 current entity-tag of the resource in the SIP-ETag header field. 724 4. The subscriber accepts the NOTIFY and sends a 200 (OK) response. 726 Had the entity-tag not been valid any longer, the condition would 727 have evaluated to false, and the NOTIFY would have had a body 728 containing the latest resource state. 730 5.6. Refreshing a Subscription 732 To refresh a subscription using conditional notification, the 733 subscriber creates a subscription refresh before the subscription is 734 about to expire, and uses the Suppress-If-Match header field: 736 Subscriber Notifier 737 ---------- -------- 739 (1) SUBSCRIBE --------> 740 Suppress-If-Match: aba91 741 Expires: 3600 743 <-------- (2) 204 744 Expires: 3600 746 Figure 5: Refreshing a Subscription 748 1. Before the subscription is about to expire, the subscriber sends 749 a SUBSCRIBE request that includes the Suppress-If-Match header 750 field with the latest entity-tag it has seen. 752 2. If the condition evaluates to true, the notifier sends a 204 (No 753 Notification) response and sends no NOTIFY request. The Expires 754 header field of the 204 (No Notification) indicates the new 755 expiry time. 757 5.7. Terminating a Subscription 759 To terminate a subscription using conditional notification, the 760 subscriber creates a SUBSCRIBE request with a Suppress-If-Match 761 condition: 763 Subscriber Notifier 764 ---------- -------- 766 (1) SUBSCRIBE --------> 767 Suppress-If-Match: ega23 768 Expires: 0 770 <-------- (2) 204 772 Figure 6: Terminating a Subscription 774 1. The subscriber decides to terminate the subscription and sends a 775 SUBSCRIBE request with the Suppress-If-Match condition with the 776 entity-tag it has last seen. 778 2. If the condition evaluates to true, the notifier sends a 204 (No 779 Notification) response, which concludes the subscription, and the 780 subscriber can clear all state related to the subscription. 782 5.8. Handling Transient Errors 784 This section is non-normative. 786 In some deployments, there may be Back-to-Back User Agent (B2BUA) 787 devices that track SIP dialogs such as subscription dialogs. These 788 devices may be unaware of the conditional notification mechanism. 790 It is possible that some B2BUA devices may treat a NOTIFY with 791 suppressed body as an error, or may expect all SUBSCRIBE messages to 792 have an associated NOTIFY message. 794 In general, there is very little that an endpoint can do to recover 795 from such transient errors. The most that can be done is to try to 796 detect such errors, and define a fall back behavior. 798 If subscribers encounter transient errors in conditional 799 notification, they should disable the feature and fall back to normal 800 subscription behavior. 802 6. Notifier Behavior 804 This section augments the notifier behavior as specified in RFC3265 805 [RFC3265]. 807 6.1. Generating Entity-tags 809 A notifier MUST generate entity-tags for event notifications of all 810 resources it is responsible for. The entity-tag MUST be unique 811 across all versions of all entities for a resource and event package. 813 An entity-tag is a token carried in the SIP-ETag header field, and it 814 is opaque to the client. The notifier is free to decide on any means 815 for generating the entity-tag. It can have any value, except for 816 "*". For example, one possible method is to implement the entity-tag 817 as a simple counter, incrementing it by one for each generated 818 notification per resource. 820 An entity-tag is considered valid for as long as the entity is valid. 821 An entity becomes stale when its version is no longer the current 822 one. The notifier MUST remember the entity-tag of an entity as long 823 as the version of the entity is current. The notifier MAY remember 824 the entity-tag longer than this, e.g., for implementing journaled 825 state differentials (Section 6.4). 827 The entity tag values used in publications are not necessarily shared 828 with the entity tag values used in subscriptions. This is because 829 there may not always be a one-to-one mapping between a publication 830 and a notification; there may be several sources to the event 831 composition process. 833 6.2. Suppressing NOTIFY Bodies 835 When a condition in a SUBSCRIBE request for suppressing notifications 836 is true (i.e., the local entity-tag for the resource state and the 837 entity-tag in a Suppress-If-Match header field match) but there are 838 reportable changes in the NOTIFY header (e.g., the Subscription-State 839 has changed), the notifier MUST suppress the body of the NOTIFY 840 request. That is, the resulting NOTIFY contains no Content-Type 841 header field, the Content-Length is set to zero, and no payload is 842 attached to the message. 844 Additionally, when a condition in a SUBSCRIBE request for suppressing 845 notifications is true and the SUBSCRIBE message is not sent within an 846 established dialog, the notifier MUST send a NOTIFY request with a 847 suppressed entity body. 849 Suppressing the entity body of a NOTIFY does not change the current 850 entity-tag of the resource. Hence, the NOTIFY MUST contain a SIP- 851 Etag header field that contains the unchanged entity-tag of the 852 resource state. 854 A Suppress-If-Match header field that includes an entity-tag with the 855 value of "*" MUST always evaluate to true. 857 6.3. Suppressing NOTIFY Requests 859 When a condition in a SUBSCRIBE request to suppress notifications is 860 true (i.e., the local entity-tag of the resource and the entity-tag 861 in a Suppress-If-Match header field match), and the SUBSCRIBE is sent 862 within an established dialog, then the notifier MUST suppress the 863 resulting NOTIFY request, and generate a 204 (No Notification) 864 response. As long as the condition remains true, and there are no 865 reportable changes in the NOTIFY header, all subsequent NOTIFY 866 requests MUST also be suppressed. 868 Notifiers MUST NOT suppress a NOTIFY unless the corresponding 869 SUBSCRIBE message was sent in an established dialog. 871 A successful conditional SUBSCRIBE request MUST extend the 872 subscription expiry time. 874 Suppressing the entire NOTIFY has no effect on the entity-tag of the 875 resource. In other words, it remains unchanged. 877 A Suppress-If-Match header field that includes an entity-tag with the 878 value of "*" MUST always evaluate to true. 880 6.4. State Differentials 882 Some event packages may support a scheme where notifications contain 883 state differentials, or state deltas [RFC3265] instead of complete 884 resource state. 886 A notifier can optionally keep track of the state changes of a 887 resource, e.g., storing the changes in a journal. If a condition 888 fails, the notifier MAY send a state differential in the NOTIFY 889 rather than the full state of the event resource. This is only 890 possible if the event package and the subscriber both support a 891 payload format that has this capability. 893 When state differentials are sent, the SIP-ETag header field MUST 894 contain an entity-tag that corresponds to the full resource state. 896 6.5. List Subscriptions 898 The Event Notification Extension for Resource Lists [RFC4662] defines 899 a mechanism for subscribing to a homogeneous list of resources using 900 the SIP events framework. 902 A list subscription delivers event notifications that contain both 903 Resource List Meta-Information (RLMI) documents as well as the 904 resource state of the individual resources on the list. 906 Implementations MUST consider the full resource state of a resource 907 list including RLMI and the entity-header as the entity to which the 908 entity-tag applies. 910 7. Protocol Element Definitions 912 This section describes the protocol extensions required for 913 conditional notification. 915 7.1. 204 (No Notification) Response Code 917 The 204 (No Notification) response code indicates that the request 918 was successful, but the notification associated with the request will 919 not be sent. It is valid only in response to a SUBSCRIBE message 920 sent within an established dialog. 922 The response code is added to the "Success" production rule in the 923 SIP [RFC3261] message grammar. 925 7.2. Suppress-If-Match Header Field 927 The Suppress-If-Match header field is added to the definition of the 928 "message-header" rule in the SIP [RFC3261] grammar. Its use is 929 described in Section 5, Section 6.3 and Section 6.2. 931 This header field is allowed to appear in any request, but its 932 behavior is only defined for the SUBSCRIBE request. 934 7.3. Grammar 936 This section defines the formal syntax for extensions described in 937 this memo in Augmented BNF (ABNF) [RFC5234]. The rules defined here 938 augment and reference the syntax defined in RFC3261 [RFC3261] and 939 RFC3903 [RFC3903]. 941 Success =/ "204" ; No Notification 943 ; Success is defined in RFC3261. 945 message-header =/ Suppress-If-Match 947 ; message-header is defined in RFC3261. 949 Suppress-If-Match = "Suppress-If-Match:" ( entity-tag / "*" ) 951 ; entity-tag is defined in RFC3903. 953 8. IANA Considerations 955 This document registers a new response code and a new header field 956 name. 958 Note to IANA and the RFC editor: please replace all occurrences of 959 RFCXYZ in this section with the RFC number of this specification 960 upon publication. 962 8.1. 204 (No Notification) Response Code 964 This document registers a new response code. This response code is 965 defined by the following information, which has been added to the 966 methods and response-codes sub-registry under 967 http://www.iana.org/assignments/sip-parameters. 969 This information is to be added under "Successful 2xx" category. 971 +---------------------+-----------+ 972 | Response Code | Reference | 973 +---------------------+-----------+ 974 | 204 No Notification | [RFCXYZ] | 975 +---------------------+-----------+ 977 8.2. Suppress-If-Match Header Field 979 This document registers a new SIP header field called Suppress-If- 980 Match. This header field is defined by the following information, 981 which has been added to the header fields sub-registry under 982 http://www.iana.org/assignments/sip-parameters. 984 +-------------------+---------+-----------+ 985 | Header Name | Compact | Reference | 986 +-------------------+---------+-----------+ 987 | Suppress-If-Match | | [RFCXYZ] | 988 +-------------------+---------+-----------+ 990 9. Security Considerations 992 The security considerations for SIP event notification are 993 extensively discussed in RFC 3265 [RFC3265]. This specification 994 introduces an optimization to SIP event notification, which in itself 995 does not alter the security properties of the protocol. 997 10. Acknowledgments 999 The following people have contributed corrections and suggestions to 1000 this document: Adam Roach, Sean Olson, Johnny Vrancken, Pekka Pessi, 1001 Eva Leppanen, Krisztian Kiss, Peili Xu, Avshalom Houri, David 1002 Viamonte, Jonathan Rosenberg, Qian Sun, Dale Worley, Tolga Asveren, 1003 Brian Stucker, Eric Rescorla, Arun Arunachalam and the SIP and SIMPLE 1004 working groups. 1006 11. References 1008 11.1. Normative References 1010 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1011 Requirement Levels", BCP 14, RFC 2119, March 1997. 1013 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1014 A., Peterson, J., Sparks, R., Handley, M., and E. 1015 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1016 June 2002. 1018 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1019 Event Notification", RFC 3265, June 2002. 1021 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 1022 for Event State Publication", RFC 3903, October 2004. 1024 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1025 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1027 11.2. Informative References 1029 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1030 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1031 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1033 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1034 Method", RFC 3515, April 2003. 1036 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1037 Package for Registrations", RFC 3680, March 2004. 1039 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 1040 Indication Event Package for the Session Initiation 1041 Protocol (SIP)", RFC 3842, August 2004. 1043 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1044 Initiation Protocol (SIP)", RFC 3856, August 2004. 1046 [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", 1047 RFC 3859, August 2004. 1049 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 1050 Initiation Protocol (SIP) Event Notification Extension for 1051 Resource Lists", RFC 4662, August 2006. 1053 Author's Address 1055 Aki Niemi 1056 Nokia 1057 P.O. Box 407 1058 NOKIA GROUP, FIN 00045 1059 Finland 1061 Phone: +358 50 389 1644 1062 Email: aki.niemi@nokia.com