idnits 2.17.1 draft-ietf-sipcore-subnot-etags-00.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 19, 2009) is 5458 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 962, 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 19, 2009 5 Intended status: Standards Track 6 Expires: October 21, 2009 8 An Extension to Session Initiation Protocol (SIP) Events for Conditional 9 Event Notification 10 draft-ietf-sipcore-subnot-etags-00 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 21, 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 have a serious 63 deficiency in that they provide no tools to avoid replaying event 64 notifications that have already been received by a user agent. This 65 memo defines an extension to SIP events that allows the subscriber to 66 condition the subscription request to whether the state has changed 67 since the previous notification was received. When such a condition 68 is true, either the body of a resulting event notification or the 69 entire notification 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 Notification . . . . . . 13 84 5.2. Generating SUBSCRIBE Requests . . . . . . . . . . . . . . 14 85 5.3. Receiving NOTIFY Requests . . . . . . . . . . . . . . . . 15 86 5.4. Polling or Fetching Resource State . . . . . . . . . . . . 15 87 5.5. Resuming a Subscription . . . . . . . . . . . . . . . . . 17 88 5.6. Refreshing a Subscription . . . . . . . . . . . . . . . . 17 89 5.7. Terminating a Subscription . . . . . . . . . . . . . . . . 18 90 5.8. Handling Transient Errors . . . . . . . . . . . . . . . . 19 91 6. Notifier Behavior . . . . . . . . . . . . . . . . . . . . . . 19 92 6.1. Generating Entity-tags . . . . . . . . . . . . . . . . . . 19 93 6.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 20 94 6.3. Suppressing NOTIFY Requests . . . . . . . . . . . . . . . 20 95 6.4. State Differentials . . . . . . . . . . . . . . . . . . . 20 96 6.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 21 97 7. Protocol Element Definitions . . . . . . . . . . . . . . . . . 21 98 7.1. 204 (No Notification) Response Code . . . . . . . . . . . 21 99 7.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 21 100 7.3. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 22 101 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 102 8.1. 204 (No Notification) Response Code . . . . . . . . . . . 22 103 8.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 23 104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 105 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 106 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 107 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 108 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 109 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 111 1. Introduction 113 The Session Initiation Protocol (SIP) events framework provides an 114 extensible facility for requesting notification of certain events 115 from other SIP user agents. This framework includes procedures for 116 creating, refreshing and terminating of subscriptions, as well as the 117 possibility to fetch or periodically poll the event resource. 119 Several instantiations of this framework, called event packages have 120 been defined, e.g., for presence [RFC3856], message waiting 121 indications [RFC3842] and registrations [RFC3680]. 123 By default, every SUBSCRIBE request generates a NOTIFY request 124 containing the latest event state. Typically, a SUBSCRIBE request is 125 issued by the subscriber whenever it needs a subscription to be 126 installed, periodically refreshed or terminated. Once the 127 subscription has been installed, the majority of the NOTIFYs 128 generated by the subscription refreshes are superfluous; the 129 subscriber usually is in possession of the event state already, 130 except in the unlikely case where a state change exactly coincides 131 with the periodic subscription refresh. In most cases, the final 132 event state generated upon terminating the subscription similarly 133 contains resource state that the subscriber already has. 135 Fetching or polling of resource state behaves in a similarly 136 suboptimal way in cases where the state has not changed since the 137 previous poll occurred. In general, the problem lies in with the 138 inability to persist state across a SUBSCRIBE request. 140 This memo defines an extension to optimize the SIP events framework. 141 This extension allows a notifier to tag notifications (called entity- 142 tags hereafter), and the subscriber to condition its subsequent 143 SUBSCRIBE requests for actual changes since a notification carrying 144 that entity-tag was issued. The solution is almost identical to 145 conditional requests defined in the HyperText Transfer Protocol 146 (HTTP) [RFC2616], and follows the mechanism already defined for the 147 PUBLISH [RFC3903] method for issuing conditional event publications. 149 This memo is structured as follows. Section 2 explains the 150 backround, motivations and requirements for the work; Section 3 gives 151 a general overview of the mechanism; Section 4 explains the 152 underlying model for resources and entities as they apply to 153 conditional notification; Section 5 defines the subscriber behavior; 154 Section 6 defines the notifier behavior; Section 7 includes the 155 protocol element definitions; Section 8 includes the IANA 156 considerations; and Section 9 includes the security considerations. 158 1.1. Document Conventions 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in BCP 14, RFC 2119 163 [RFC2119] and indicate requirement levels for compliant 164 implementations. 166 1.2. Terminology 168 In addition to the terminology introduced in [RFC3261], [RFC3265] and 169 [RFC3903], this specification uses these additional terms to describe 170 the objects of conditional notification: 172 resource 173 An object identified by a URI, whose resource state can be 174 accessed using the SIP Event Notification framework. There is a 175 single authoritative notifier responsible for communicating the 176 resource state. 178 entity 179 The representation of resource state. An entity consists of the 180 event data carried in the body of a NOTIFY message, as well as 181 related meta-data in the message header. There may be many 182 versions of an entity, one current and the others stale. Each 183 version of an entity is identified by an entity-tag, which is 184 guaranteed to be unique accross all versions of all entities for a 185 resource and event package. 187 2. Motivations and Background 189 2.1. Overview 191 A SUBSCRIBE request creates a subscription with a finite lifetime. 192 This lifetime is negotiated using the Expires header field, and 193 unless the subscription is refreshed by the subscriber before the 194 expiration is met, the subscription is terminated. The frequency of 195 these subscription refreshes depends on the event package, and 196 typically ranges from minutes to hours. 198 2.2. Problem Description 200 In spite of being somewhat distinct operations, the SIP events 201 framework does not include different protocol methods for initiating 202 and terminating of subscriptions, subscription refreshes and fetches 203 inside and outside of the SIP dialog. Instead, the SUBSCRIBE method 204 is overloaded to perform all of these functions, and the notifier 205 behavior is identical in each of them; each SUBSCRIBE request 206 generates a NOTIFY request containing the latest resource state. In 207 fact, the only difference between a fetch that does not create a 208 (lasting) subscription, and a SUBSCRIBE that creates one is in the 209 Expires header field value of the SUBSCRIBE; a zero-expiry SUBSCRIBE 210 only generates a single NOTIFY, after which the subscription 211 immediately terminates. 213 Some subscriber implementations may choose to operate in semi- 214 stateless mode, in which they immediately upon receiving and 215 processing the NOTIFY forget the resource state. This operation 216 necessarily needs every NOTIFY to carry the full resource state. 217 However, for an implementation that stores the resource state 218 locally, this mode of operation is inefficient. 220 There are certain conditions that aggravate the problem. Such 221 conditions usually entail such things as: 223 o Large entity bodies in the payloads of notifications 225 o High rate of subscription refreshes 227 o Relatively low rate of notifications triggered by state changes 229 In effect, for an event package that generates few state changes, and 230 is refreshed relatively often the majority of traffic generated may 231 be related to subscription maintenance. Especially in networks where 232 bandwidth consumption and traffic count is at a premium, the high 233 overhead of subscription maintenance becomes a barrier for 234 deployment. 236 The same problem affects fetching and polling of resource state as 237 well. As a benchmark, if we look at the performance of HTTP 238 [RFC2616] in similar scenarios, it performs substantially better 239 using conditional requests. When resources are tagged with an 240 entity-tag, and each GET is a conditional one using the "If-None- 241 Match" header field, the entity body need not be sent more than once; 242 if the resource has not changed between successive polls, an error 243 response is returned indicating this fact, and the resource entity is 244 not transmitted again. 246 The SIP PUBLISH [RFC3903] method also contains a similar feature, 247 where a refresh of a publication is done by reference to its assigned 248 entity-tag, instead of retransmitting the event state each time the 249 publication expiration is extended. 251 2.3. Requirements 253 As a summary, here is the required functionality to solve the 254 presented issues: 256 REQ1: It must be possible to suppress the NOTIFY request (or at a 257 minimum the event body therein) if the subscriber is already 258 in possession of the latest event state of the resource. 260 REQ2: This mechanism must apply to initial subscriptions, in which 261 the subscriber is attempting to "resume" an earlier 262 subscription. 264 REQ3: This mechanism must apply to refreshing a subscription. 266 REQ4: This mechanism must apply to terminating a subscription 267 (i.e., an unsubscribe). 269 REQ5: This mechanism must apply to fetching or polling of resource 270 state. 272 3. Overview of Operation 274 Whenever a subscriber initiates a subscription, it issues a SUBSCRIBE 275 request. The SUBSCRIBE request is sent, routed and processed by the 276 notifier normally, i.e., according to RFC3261 [RFC3261], RFC3265 277 [RFC3265]. 279 If the notifier receiving the SUBSCRIBE request supports conditional 280 subscriptions, it generates a unique entity tag for the event 281 notification, and includes it in a SIP-ETag header field of the 282 NOTIFY request. The entity tag is unique accross all versions of all 283 entities for a resource and event package. More on this in 284 Section 4. 286 Entity-tags are independent of subscriptions; the notifier remembers 287 the entity-tags of all versions of entities for a resource regardless 288 of whether or not there are any active subscription to that resource. 289 This allows notifications generated to a fetch or a poll to have 290 valid entity-tags even across subsequent fetches or polls. 292 The subscriber will store the entity-tag received in the notification 293 along with the resource state. It can then later use this entity-tag 294 to make a SUBSCRIBE contain a condition in the form of a "Suppress- 295 If-Match" header field. Unlike the "If-Match" condition in a PUBLISH 296 [RFC3903] request, which applies to whether the PUBLISH succeeds or 297 returns an error, this condition applies to the stream of 298 notifications that are sent after the SUBSCRIBE request has been 299 processed. 301 The "Suppress-If-Match" header field contains the last entity-tag 302 seen by the subscriber. This condition, if true, instructs the 303 notifier to suppress either the body of a subsequent notification, or 304 the entire notification. 306 The condition is evaluated by matching the value of the header field 307 against the current entity-tag of the resource state. There is also 308 a wildcard entity-tag with a special value of "*" that always 309 matches. 311 Subscriber Notifier 312 ---------- -------- 314 (1) SUBSCRIBE --------> 315 Expires: 3600 316 <-------- (2) 200 (or 202) 318 <-------- (3) NOTIFY 319 Subscription-State: active 320 SIP-ETag: ffee2 321 (4) 200 --------> 323 ... time passes ... 325 (5) SUBSCRIBE --------> \ if "ffee2" 326 Suppress-If-Match: ffee2 | matches 327 Expires: 3600 | local 328 | entity-tag 329 | 330 <-------- (6) 204 / then 332 ... time passes ... 334 <-------- (7) NOTIFY 335 Subscription-State: active 336 SIP-ETag: ca89a 337 (8) 200 --------> 339 ... time passes ... 341 (9) SUBSCRIBE --------> \ if "ca89" 342 Suppress-If-Match: ca89a | matches 343 Expires: 0 | local 344 | entity-tag 345 | 346 <-------- (10) 204 / then 348 Figure 1: Example Message Flow 350 Figure 1 describes a typical message flow for conditional 351 notification: 353 1. The subscriber initiates a subscription by sending a SUBSCRIBE 354 request for a resource. 356 2. After proper authentication and authorization, the notifier 357 accepts the subscription. 359 3. The notifier then immediately sends the initial event 360 notification, including a unique entity-tag in a SIP-ETag header 361 field. 363 4. The subscriber accepts the notification and stores the entity- 364 tag value along with the resource state. 366 5. Later, the subscriber refreshes the subscription, and includes 367 an entity-tag in a Suppress-If-Match header field. 369 6. The notifier evaluates the condition by matching its local 370 entity-tag value for the resource against the value of the 371 Suppress-If-Match header field. If the condition evaluates to 372 true, the notifier informs the subscriber that the notification 373 will not be sent. 375 7. At some point, the state of the resource changes, e.g., the 376 presence status of a user changes from online to busy. This 377 triggers an event notification with a new value in the SIP-ETag 378 header field. 380 8. The subscriber accepts the notification and stores the new 381 entity-tag along with the resource state. 383 9. After a while, the subscriber decides to terminate the 384 subscription. It adds a condition for Suppress-If-Match, and 385 includes the entity-tag it received in the previous NOTIFY. 387 10. The notifier evaluates the condition by matching its entity-tag 388 for the resource against the value of the Suppress-If-Match 389 header field. If the condition evaluates to true, the notifier 390 informs the subscriber that no notification will be sent. This 391 concludes the subscription. 393 The benefit of using conditional notification in this example is in 394 the reduction of the number of NOTIFY requests the subscriber can 395 expect to receive. Each event notification that the subscriber has 396 already seen is suppressed by the notifier. This example illustrates 397 only one use case for the mechanism; the same principles can be used 398 to optimize the flow of messages related to other event notification 399 use cases. 401 4. Resource Model for Entity-Tags 403 The key to understanding how conditional notification works is 404 understanding the underlying resource model of event notification. 405 In general, this model is similar to the resource model of HTTP with 406 some key differences. This section explains in detail the model as 407 it applies to SIP events. Figure 2 illustrates the model. 409 +-----+ 410 ............ | | 411 . . | URI | 412 . Represen . | | 413 . tation . +-----+ 414 . . |* 415 ............ | 416 . | 417 . V 418 . +----------+ +---------+ 419 composition | |* | Event | 420 +------<>| Resource |----------->| Package |<----. 421 | | | | | | 422 | +----------+ +----.----+ | 423 | /_\ | 424 |* | classification 425 +--------+ | | 426 | | .----------------.------' | 427 | Entity | | | | 428 | | | | |* 429 +--------+ +----------+ +------------+ +----------+ 430 ^ | | | | | | 431 | | Presence | | Conference | | Template | 432 | | | | | | | 433 |1..* +----------+ +------------+ +----.-----+ 434 +---------+ /_\ 435 | | | 436 | Version | | 437 | | +---------+ 438 +---------+ | Watcher | 439 |1 | Info | 440 | | | 441 | +---------+ 442 V 443 +---------+ 444 | Entity- | 445 | Tag | 446 | | 447 +---------+ 448 Figure 2: Resource Model Diagram 450 For a given event package, there is a single authoritative agent 451 responsible for zero or more resources. That is, even for a 452 distributed agent, the resource state is uniform across all 453 instances. The resource itself can be a list of resources [RFC4662]. 454 Conditional notification for list subscriptions is addressed in 455 Section 6.5. 457 A resource is identified by zero or more URIs, which can be SIP URIs, 458 pres URIs [RFC3859] or similar. Subscribers use this URI to 459 subscribe to the resource for certain types of events, identified by 460 the event package. 462 With a successful subscription, a subscriber receives event 463 notifications that communicate the resource state and the changes 464 thereto. Each event notification carries a representation of the 465 current resource state. This representation is influenced by many 466 factors, e.g., authorization and filtering rules, and the event 467 composition rules of the notifier. 469 This representation is realized in what is called an entity. Each 470 resource may be associated with zero or more entities; however, an 471 entity is only valid for a single resource. 473 Note that, as can be seen from the illustration, the association 474 between a resource and an entity follows the typical composition 475 relationship, i.e., an entity may belong to only one resource, and 476 it is expected to only exist with that resource. 478 An entity consists of the data carried in the body of a NOTIFY 479 message, and related meta-data in the message header. This meta-data 480 includes, but is not limited to the following SIP header fields: 482 entity-header = Content-Disposition ; defined in RFC 3261 483 / Content-Encoding ; defined in RFC 3261 484 / Content-Language ; defined in RFC 3261 485 / Content-Length ; defined in RFC 3261 486 / Content-Type ; defined in RFC 3261 487 / Event ; defined in RFC 3265 488 / extension-header ; defined in RFC 3261 490 Note that the Subscription-State is explicitly not part of the 491 entity. Event packages may in the future define additional fields 492 that implementations need to consider as part of the entity. 494 An entity has one or more versions of which only one is current and 495 all others stale. Each version has an entity-tag, which uniquely 496 identifies it accross all versions of all entities pertaining to a 497 single resource and event package. 499 Note that two entity-tags being equal does not indicate identical 500 entities. In other words, if an entity-tag is received that matches 501 a previously seen entity-tag, the subscriber cannot assume the event 502 state to be identical to that received earlier. 504 With partial event notification, the NOTIFY message only carries the 505 delta state, or the set of changes to the previous version of the 506 entity. In that case, implementations MUST consider the full event 507 state as the version of the entity to which the entity-tag in the 508 NOTIFY message applies. 510 The conditional notification mechanism is independent of the way in 511 which subscriptions are installed. In other words, the mechanism 512 supports implicit subscriptions, such as those associated with the 513 REFER method [RFC3515]. 515 It is possible that the same resource is in some shape or form 516 accessible through another mechanism in addition to SIP Event 517 Notification, e.g., HTTP or the SIP PUBLISH method. In general, 518 implementations MUST NOT expect the entity-tags to be shared between 519 the mechanisms, unless event packages or specific applications of SIP 520 Events explicitly define such dependencies. 522 5. Subscriber Behavior 524 This section augments the subscriber behavior defined in RFC3265 525 [RFC3265]. It first discusses general issues related to indicating 526 support for the mechanism (Section 5.1) and creating conditions in 527 SUBSCRIBE requests (Section 5.2); it then describes the workflows for 528 the main three use cases for making the subscription conditional. 530 5.1. Detecting Support for Conditional Notification 532 The mechanism defined in this memo is backwards compatible with SIP 533 events [RFC3265] in that a notifier supporting this mechanism will 534 insert a SIP entity-tag in its NOTIFY requests, and a subscriber that 535 understands this mechanism will know how to use it in creating a 536 conditional request. 538 Unaware subscribers will simply ignore the entity-tag, make requests 539 without conditions and receive the default treatment from the 540 notifier. Unaware notifiers will simply ignore the conditional 541 header fields, and continue normal operation. 543 5.2. Generating SUBSCRIBE Requests 545 When creating a conditional SUBSCRIBE request, the subscriber MUST 546 include a single conditional header field including an entity-tag in 547 the request. The condition is evaluated by comparing the entity-tag 548 of the subscribed resource with the entity-tag carried in the 549 conditional header field. If they match, the condition evaluates to 550 true. 552 Unlike the condition introduced for the SIP PUBLISH [RFC3903] method, 553 these conditions do not apply to the SUBSCRIBE request itself, but to 554 the resulting NOTIFY requests. When true, the condition drives the 555 notifier to change its behavior with regards to sending the 556 notifications after the SUBSCRIBE. 558 This specification defines a new header field called "Suppress-If- 559 Match". This header field introduces a condition to the SUBSCRIBE 560 request. If true, it instructs the notifier to suppress (i.e., 561 block) the first NOTIFY request following the SUBSCRIBE, and return a 562 204 (No Notification) response to the SUBSCRIBE request. As long as 563 the condition remains true, it also instructs the notifier to either 564 suppress any subsequent NOTIFY request, or if there are reportable 565 changes in the NOTIFY header, e.g., the Subscription-State has 566 changed, suppress the body of any subsequent NOTIFY request. 568 If the condition is false, the notifier follows its default 569 behaviour. 571 If the subscriber receives a 204 (No Notification) response to 572 SUBSCRIBE, it MUST consider the subscription handshake as completed. 573 That is, the subscriber can clear any handle that it may have had 574 pending on a NOTIFY to conclude establishing the subsctiption. 576 The value of the "Suppress-If-Match" header field is an entity-tag, 577 which is an opaque token that the subscriber simply copies from a 578 previously received NOTIFY request. 580 Example: 582 Suppress-If-Match: b4cf7 584 The header field can also be wildcarded using the special "*" entity- 585 tag value. Such a condition always evaluates to true regardless of 586 the value of the current entity-tag for the resource. 588 Example: 590 Suppress-If-Match: * 592 Such a wildcard condition effectively quenches a subscription; the 593 only notifications received are those reporting changes to the 594 subscription state. Such notifications will also not contain a body. 596 A subscription with a wildcard "Suppress-If-Match" condition is 597 useful in scenarios where the subscriber wants to temporarily put 598 a subscription in dormant mode. For example, a host may want to 599 conserve bandwidth and power when it detects from screen or input 600 device inactivity that the user isn't actively monitoring the 601 presence statuses of contacts. 603 5.3. Receiving NOTIFY Requests 605 When a subscriber receives a NOTIFY request that contains a SIP-ETag 606 header field, it MUST store the entity-tag if it wishes to make use 607 of the conditional notification mechanism. The subscriber MUST be 608 prepared to receive a NOTIFY with any entity-tag value, including a 609 value that matches any previous value that the subscriber might have 610 seen. 612 The subscriber MUST NOT infer any meaning from the value of an 613 entity-tag; specifically, the subscriber MUST NOT assume identical 614 entities (i.e., event state) for NOTIFYs with identical entity-tag 615 values. 617 Note that there are valid cases for which identical entity-tag 618 values indeed imply identical event state. For example, it is 619 possible to generate entity-tag values using a one-way hash 620 function. 622 5.4. Polling or Fetching Resource State 624 Polling with conditional notification allows a user agent to 625 efficiently poll resource state. This is accomplished using the 626 Suppress-If-Match condition: 628 Subscriber Notifier 629 ---------- -------- 631 (1) SUBSCRIBE --------> 632 Expires: 0 633 <-------- (2) 202 635 <-------- (3) NOTIFY 636 Subscription-State: terminated 637 SIP-ETag: f2e45 639 (4) 200 --------> 641 ... poll interval elapses ... 643 (5) SUBSCRIBE --------> 644 Suppress-If-Match: f2e45 645 Expires: 0 647 <-------- (6) 204 649 Figure 3: Polling Resource State 651 1. The subscriber polls for resource state by sending a SUBSCRIBE 652 with zero expiry (expires immediately). 654 2. The notifier accepts the SUBSCRIBE with a 202 (Accepted) 655 response. 657 3. The notifier then immediately sends a first (and last) NOTIFY 658 request with the current resource state, and the current entity- 659 tag in the SIP-ETag header field. 661 4. The subsciber accepts the notification with a 200 (OK) response. 663 5. After some arbitrary poll interval, the subscriber sends another 664 SUBSCRIBE with a Suppress-If-Match header field that includes the 665 entity-tag received in the previous NOTIFY. 667 6. Since the resource state has not changed since the previous poll 668 occurred, the notifier sends a 204 (No Notification) response, 669 which concludes the poll. 671 5.5. Resuming a Subscription 673 Resuming a subscription means the ability to continue an earlier 674 subscription that either closed abruptly, or was explicitly 675 terminated. When resuming, the subscription is established without 676 transmitting the resource state. This is accomplished with 677 conditional notification and the Suppress-If-Match header field: 679 Subscriber Notifier 680 ---------- -------- 682 (1) SUBSCRIBE --------> 683 Suppress-If-Match: ega23 684 Expires: 3600 685 <-------- (2) 202 687 <-------- (3) NOTIFY 688 Subscription-State: active 689 SIP-ETag: ega23 690 Content-Length: 0 691 (4) 200 --------> 693 Figure 4: Resuming a Subscription 695 1. The subscriber attempts to resume an earlier subscription by 696 including a Suppress-If-Match header field with the entity-tag it 697 last received. 699 2. The notifier accepts the subscription after proper authentication 700 and authorization, by sending a 202 (Accepted) response. 702 3. Since the condition is true, the notifier then immediately sends 703 an initial NOTIFY request that has no body. It also mirrors the 704 current entity-tag of the resource in the SIP-ETag header field. 706 4. The subscriber accepts the NOTIFY and sends a 200 (OK) response. 708 Had the entity-tag not been valid any longer, the condition would 709 have evaluated to false, and the NOTIFY would have had a body 710 containing the latest resource state. 712 5.6. Refreshing a Subscription 714 To refresh a subscription using conditional notification, the 715 subscriber creates a subscription refresh before the subscription is 716 about to expire, and uses the Suppress-If-Match header field: 718 Subscriber Notifier 719 ---------- -------- 721 (1) SUBSCRIBE --------> 722 Suppress-If-Match: aba91 723 Expires: 3600 725 <-------- (2) 204 726 Expires: 3600 728 Figure 5: Refreshing a Subscription 730 1. Before the subscription is about to expire, the subscriber sends 731 a SUBSCRIBE request that includes the Suppress-If-Match header 732 field with the latest entity-tag it has seen. 734 2. If the condition evaluates to true, the notifier sends a 204 (No 735 Notification) response and sends no NOTIFY request. The Expires 736 header field of the 204 (No Notification) indicates the new 737 expiry time. 739 5.7. Terminating a Subscription 741 To terminate a subscription using conditional notification, the 742 subscriber creates a SUBSCRIBE request with a Suppress-If-Match 743 condition: 745 Subscriber Notifier 746 ---------- -------- 748 (1) SUBSCRIBE --------> 749 Suppress-If-Match: ega23 750 Expires: 0 752 <-------- (2) 204 754 Figure 6: Terminating a Subscription 756 1. The subscriber decides to terminate the subscription and sends a 757 SUBSCRIBE request with the Suppress-If-Match condition with the 758 entity-tag it has last seen. 760 2. If the condition evaluates to true, the notifier sends a 204 (No 761 Notification) response, which concludes the subscription, and the 762 subscriber can clear all state related to the subscription. 764 5.8. Handling Transient Errors 766 This section is non-normative. 768 In some deployments, there may be Back-to-Back User Agent (B2BUA) 769 devices that track SIP dialogs such as subscription dialogs. These 770 devices may be unaware of the conditional notification mechanism. 772 It is possible that such B2BUAs always expect to see a NOTIFY method 773 to conclude the dialog establishment as specified in SIP Events 774 [RFC3265], and if this NOTIFY request is suppressed, may terminate or 775 block the subscription. Other problems may also arise, e.g., it is 776 possible that some B2BUA devices treat a NOTIFY with suppressed body 777 as an error. 779 In general, there is very little that an endpoint can do to recover 780 from such transient errors. The most that can be done is to try to 781 detect such errors, and define a fall back behavior. 783 If subscribers encounter transient errors in conditional 784 notification, they should disable the feature and fall back to normal 785 subscription behavior. 787 6. Notifier Behavior 789 This section augments the notifier behavior as specified in RFC3265 790 [RFC3265]. 792 6.1. Generating Entity-tags 794 A notifier MUST generate entity-tags for event notifications of all 795 resources it is responsible for. The entity-tag MUST be unique 796 across all versions of all entities for a resource and event package. 798 An entity-tag is a token carried in the SIP-ETag header field, and it 799 is opaque to the client. The notifier is free to decide on any means 800 for generating the entity-tag. It can have any value, except for 801 "*". For example, one possible method is to implement the entity-tag 802 as a simple counter, incrementing it by one for each generated 803 notification per resource. 805 An entity-tag is considered valid for as long as the entity is valid. 806 An entity becomes stale when its version is no longer the current 807 one. The notifier MUST remember the entity-tag of an entity as long 808 as the version of the entity is current. The notifier MAY remember 809 the entity-tag longer than this, e.g., for implementing journaled 810 state differentials (Section 6.4). 812 The entity tag values used in publications are not necessarily shared 813 with the entity tag values used in subscriptions. This is because 814 there may not always be a one-to-one mapping between a publication 815 and a notification; there may be several sources to the event 816 composition process. 818 6.2. Suppressing NOTIFY Bodies 820 When a condition in a SUBSCRIBE request for suppressing notifications 821 is true, i.e., the local entity-tag for the resource state and the 822 entity-tag in a Suppress-If-Match header field match, but there are 823 reportable changes in the NOTIFY header, e.g., the Subscription-State 824 has changed, the notifier MUST suppress the body of the NOTIFY 825 request. That is, the resulting NOTIFY contains no Content-Type 826 header field, the Content-Length is set to zero, and no payload is 827 attached to the message. 829 Suppressing the entity body of a NOTIFY does not change the current 830 entity-tag of the resource. Hence, the NOTIFY MUST contain a SIP- 831 Etag header field that contains the unchanged entity-tag of the 832 resource state. 834 A Suppress-If-Match header field that includes an entity-tag with the 835 value of "*" MUST always evaluate to true. 837 6.3. Suppressing NOTIFY Requests 839 When a condition in a SUBSCRIBE request to suppress notifications is 840 true, i.e., the local entity-tag of the resource and the entity-tag 841 in a Suppress-If-Match header field match, the notifier MUST suppress 842 the resulting NOTIFY request, and generate a 204 (No Notification) 843 response. As long as the condition remains true, and there are no 844 reportable changes in the NOTIFY header, all subsequent NOTIFY 845 requests MUST also be suppressed. 847 A successful conditional SUBSCRIBE request MUST extend the 848 subscription expiry time. 850 Suppressing the entire NOTIFY has no effect on the entity-tag of the 851 resource. In other words, it remains unchanged. 853 A Suppress-If-Match header field that includes an entity-tag with the 854 value of "*" MUST always evaluate to true. 856 6.4. State Differentials 858 Some event packages may support a scheme where notifications contain 859 state differentials, or state deltas [RFC3265] instead of complete 860 resource state. 862 A notifier can optionally keep track of the state changes of a 863 resource, e.g., storing the changes in a journal. If a condition 864 fails, the notifier MAY send a state differential in the NOTIFY 865 rather than the full state of the event resource. This is only 866 possible if the event package and the subscriber both support a 867 payload format that has this capability. 869 When state differentials are sent, the SIP-ETag header field MUST 870 contain an entity-tag that corresponds to the full resource state. 872 6.5. List Subscriptions 874 The Event Notification Extension for Resource Lists [RFC4662] defines 875 a mechanism for subscribing to a homogeneous list of resources using 876 the SIP events framework. 878 A list subscription delivers event notifications that contain both 879 Resource List Meta-Information (RLMI) documents as well as the 880 resource state of the individual resources on the list. 882 Implementations MUST consider the full resource state of a resource 883 list including RLMI and the entity-header as the entity to which the 884 entity-tag applies. 886 7. Protocol Element Definitions 888 This section describes the protocol extensions required for 889 conditional notification. 891 7.1. 204 (No Notification) Response Code 893 The 204 (No Notification) response code indicates that the request 894 was successful, but the notification associated with the request will 895 not be sent. 897 The response code is added to the "Success" production rule in the 898 SIP [RFC3261] message grammar. 900 7.2. Suppress-If-Match Header Field 902 The Suppress-If-Match header field is added to the definition of the 903 "message-header" rule in the SIP [RFC3261] grammar. Its use is 904 described in Section 5, Section 6.3 and Section 6.2. 906 This header field is allowed to appear in any request, but its 907 behavior is only defined for the SUBSCRIBE request. 909 7.3. Grammar 911 This section defines the formal syntax for extensions described in 912 this memo in Augmented BNF (ABNF) [RFC5234]. The rules defined here 913 augment and reference the syntax defined in RFC3261 [RFC3261] and 914 RFC3903 [RFC3903]. 916 Success =/ "204" ; No Notification 918 ; Success is defined in RFC3261. 920 message-header =/ Suppress-If-Match 922 ; message-header is defined in RFC3261. 924 Suppress-If-Match = "Suppress-If-Match" ":" entity-tag / "*" 926 ; entity-tag is defined in RFC3903. 928 8. IANA Considerations 930 This document registers a new response code and a new header field 931 name. 933 Note to IANA and the RFC editor: please replace all occurrences of 934 RFCXYZ in this section with the RFC number of this specification 935 upon publication. 937 8.1. 204 (No Notification) Response Code 939 This document registers a new response code. This response code is 940 defined by the following information, which has been added to the 941 methods and response-codes sub-registry under 942 http://www.iana.org/assignments/sip-parameters. 944 This information is to be added under "Successful 2xx" category. 946 +---------------------+-----------+ 947 | Response Code | Reference | 948 +---------------------+-----------+ 949 | 204 No Notification | [RFCXYZ] | 950 +---------------------+-----------+ 952 8.2. Suppress-If-Match Header Field 954 This document registers a new SIP header field called Suppress-If- 955 Match. This header field is defined by the following information, 956 which has been added to the header fields sub-registry under 957 http://www.iana.org/assignments/sip-parameters. 959 +-------------------+---------+-----------+ 960 | Header Name | Compact | Reference | 961 +-------------------+---------+-----------+ 962 | Suppress-If-Match | | [RFCXYZ] | 963 +-------------------+---------+-----------+ 965 9. Security Considerations 967 The security considerations for SIP event notification are 968 extensively discussed in RFC 3265 [RFC3265]. This specification 969 introduces an optimization to SIP event notification, which in itself 970 does not alter the security properties of the protocol. 972 10. Acknowledgments 974 The following people have contributed corrections and suggestions to 975 this document: Adam Roach, Sean Olson, Johnny Vrancken, Pekka Pessi, 976 Eva Leppanen, Krisztian Kiss, Peili Xu, Avshalom Houri, David 977 Viamonte, Jonathan Rosenberg, Qian Sun, Dale Worley, Tolga Asveren, 978 Brian Stucker, Eric Rescorla, Arun Arunachalam and the SIP and SIMPLE 979 working groups. 981 11. References 983 11.1. Normative References 985 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 986 Requirement Levels", BCP 14, RFC 2119, March 1997. 988 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 989 A., Peterson, J., Sparks, R., Handley, M., and E. 990 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 991 June 2002. 993 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 994 Event Notification", RFC 3265, June 2002. 996 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 997 for Event State Publication", RFC 3903, October 2004. 999 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1000 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1002 11.2. Informative References 1004 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1005 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1006 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1008 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1009 Method", RFC 3515, April 2003. 1011 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1012 Package for Registrations", RFC 3680, March 2004. 1014 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 1015 Indication Event Package for the Session Initiation 1016 Protocol (SIP)", RFC 3842, August 2004. 1018 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1019 Initiation Protocol (SIP)", RFC 3856, August 2004. 1021 [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", 1022 RFC 3859, August 2004. 1024 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 1025 Initiation Protocol (SIP) Event Notification Extension for 1026 Resource Lists", RFC 4662, August 2006. 1028 Author's Address 1030 Aki Niemi 1031 Nokia 1032 P.O. Box 407 1033 NOKIA GROUP, FIN 00045 1034 Finland 1036 Phone: +358 50 389 1644 1037 Email: aki.niemi@nokia.com