idnits 2.17.1 draft-ietf-sip-subnot-etags-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1039. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1050. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1057. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1063. 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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2008) is 5736 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 944, but not defined == Unused Reference: 'RFC4660' is defined on line 1006, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 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 July 14, 2008 5 Intended status: Standards Track 6 Expires: January 15, 2009 8 An Extension to Session Initiation Protocol (SIP) Events for Conditional 9 Event Notification 10 draft-ietf-sip-subnot-etags-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 15, 2009. 37 Abstract 39 The Session Initiation Protocol (SIP) events framework enables 40 receiving asynchronous notification of various events from other SIP 41 user agents. This framework defines the procedures for creating, 42 refreshing and terminating subscriptions, as well as fetching and 43 periodic polling of resource state. These procedures have a serious 44 deficiency in that they provide no tools to avoid replaying event 45 notifications that have already been received by a user agent. This 46 memo defines an extension to SIP events that allows the subscriber to 47 condition the subscription request to whether the state has changed 48 since the previous notification was received. When such a condition 49 is true, either the body of a resulting event notification or the 50 entire notification message is suppressed. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Document Conventions . . . . . . . . . . . . . . . . . . . 4 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Motivations and Background . . . . . . . . . . . . . . . . . . 4 58 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Problem Description . . . . . . . . . . . . . . . . . . . 4 60 2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 62 4. Resource Model for Entity-Tags . . . . . . . . . . . . . . . . 10 63 5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 12 64 5.1. Detecting Support for Conditional Notification . . . . . . 12 65 5.2. Generating SUBSCRIBE Requests . . . . . . . . . . . . . . 13 66 5.3. Receiving NOTIFY Requests . . . . . . . . . . . . . . . . 14 67 5.4. Polling or Fetching Resource State . . . . . . . . . . . . 14 68 5.5. Resuming a Subscription . . . . . . . . . . . . . . . . . 16 69 5.6. Refreshing a Subscription . . . . . . . . . . . . . . . . 16 70 5.7. Terminating a Subscription . . . . . . . . . . . . . . . . 17 71 5.8. Handling Transient Errors . . . . . . . . . . . . . . . . 18 72 6. Notifier Behavior . . . . . . . . . . . . . . . . . . . . . . 18 73 6.1. Generating Entity-tags . . . . . . . . . . . . . . . . . . 18 74 6.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 19 75 6.3. Suppressing NOTIFY Requests . . . . . . . . . . . . . . . 19 76 6.4. State Differentials . . . . . . . . . . . . . . . . . . . 19 77 6.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 20 78 7. Protocol Element Definitions . . . . . . . . . . . . . . . . . 20 79 7.1. 204 (No Notification) Response Code . . . . . . . . . . . 20 80 7.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 20 81 7.3. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 83 8.1. 204 (No Notification) Response Code . . . . . . . . . . . 21 84 8.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 22 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 86 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 89 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 Intellectual Property and Copyright Statements . . . . . . . . . . 24 93 1. Introduction 95 The Session Initiation Protocol (SIP) events framework provides an 96 extensible facility for requesting notification of certain events 97 from other SIP user agents. This framework includes procedures for 98 creating, refreshing and terminating of subscriptions, as well as the 99 possibility to fetch or periodically poll the event resource. 101 Several instantiations of this framework, called event packages have 102 been defined, e.g., for presence [RFC3856], message waiting 103 indications [RFC3842] and registrations [RFC3680]. 105 By default, every SUBSCRIBE request generates a NOTIFY request 106 containing the latest event state. Typically, a SUBSCRIBE request is 107 issued by the subscriber whenever it needs a subscription to be 108 installed, periodically refreshed or terminated. Once the 109 subscription has been installed, the majority of the NOTIFYs 110 generated by the subscription refreshes are superfluous; the 111 subscriber usually is in possession of the event state already, 112 except in the unlikely case where a state change exactly coincides 113 with the periodic subscription refresh. In most cases, the final 114 event state generated upon terminating the subscription similarly 115 contains resource state that the subscriber already has. 117 Fetching or polling of resource state behaves in a similarly 118 suboptimal way in cases where the state has not changed since the 119 previous poll occurred. In general, the problem lies in with the 120 inability to persist state across a SUBSCRIBE request. 122 This memo defines an extension to optimize the SIP events framework. 123 This extension allows a notifier to tag notifications (called entity- 124 tags hereafter), and the subscriber to condition its subsequent 125 SUBSCRIBE requests for actual changes since a notification carrying 126 that entity-tag was issued. The solution is almost identical to 127 conditional requests defined in the HyperText Transfer Protocol 128 (HTTP) [RFC2616], and follows the mechanism already defined for the 129 PUBLISH [RFC3903] method for issuing conditional event publications. 131 This memo is structured as follows. Section 2 explains the 132 backround, motivations and requirements for the work; Section 3 gives 133 a general overview of the mechanism; Section 4 explains the 134 underlying model for resources and entities as they apply to 135 conditional notification; Section 5 defines the subscriber behavior; 136 Section 6 defines the notifier behavior; Section 7 includes the 137 protocol element definitions; Section 8 includes the IANA 138 considerations; and Section 9 includes the security considerations. 140 1.1. Document Conventions 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in BCP 14, RFC 2119 145 [RFC2119] and indicate requirement levels for compliant 146 implementations. 148 1.2. Terminology 150 In addition to the terminology introduced in [RFC3261], [RFC3265] and 151 [RFC3903], this specification uses these additional terms to describe 152 the objects of conditional notification: 154 resource 155 An object identified by a URI, whose resource state can be 156 accessed using the SIP Event Notification framework. There is a 157 single authoritative notifier responsible for communicating the 158 resource state. 160 entity 161 The representation of resource state. An entity consists of the 162 event data carried in the body of a NOTIFY message, as well as 163 related meta-data in the message header. There may be many 164 versions of an entity, one current and the others stale. Each 165 version of an entity is identified by an entity-tag, which is 166 guaranteed to be unique accross all versions of all entities for a 167 resource and event package. 169 2. Motivations and Background 171 2.1. Overview 173 A SUBSCRIBE request creates a subscription with a finite lifetime. 174 This lifetime is negotiated using the Expires header field, and 175 unless the subscription is refreshed by the subscriber before the 176 expiration is met, the subscription is terminated. The frequency of 177 these subscription refreshes depends on the event package, and 178 typically ranges from minutes to hours. 180 2.2. Problem Description 182 In spite of being somewhat distinct operations, the SIP events 183 framework does not include different protocol methods for initiating 184 and terminating of subscriptions, subscription refreshes and fetches 185 inside and outside of the SIP dialog. Instead, the SUBSCRIBE method 186 is overloaded to perform all of these functions, and the notifier 187 behavior is identical in each of them; each SUBSCRIBE request 188 generates a NOTIFY request containing the latest resource state. In 189 fact, the only difference between a fetch that does not create a 190 (lasting) subscription, and a SUBSCRIBE that creates one is in the 191 Expires header field value of the SUBSCRIBE; a zero-expiry SUBSCRIBE 192 only generates a single NOTIFY, after which the subscription 193 immediately terminates. 195 Some subscriber implementations may choose to operate in semi- 196 stateless mode, in which they immediately upon receiving and 197 processing the NOTIFY forget the resource state. This operation 198 necessarily needs every NOTIFY to carry the full resource state. 199 However, for an implementation that stores the resource state 200 locally, this mode of operation is inefficient. 202 There are certain conditions that aggravate the problem. Such 203 conditions usually entail such things as: 205 o Large entity bodies in the payloads of notifications 207 o High rate of subscription refreshes 209 o Relatively low rate of notifications triggered by state changes 211 In effect, for an event package that generates few state changes, and 212 is refreshed relatively often the majority of traffic generated may 213 be related to subscription maintenance. Especially in networks where 214 bandwidth consumption and traffic count is at a premium, the high 215 overhead of subscription maintenance becomes a barrier for 216 deployment. 218 The same problem affects fetching and polling of resource state as 219 well. As a benchmark, if we look at the performance of HTTP 220 [RFC2616] in similar scenarios, it performs substantially better 221 using conditional requests. When resources are tagged with an 222 entity-tag, and each GET is a conditional one using the "If-None- 223 Match" header field, the entity body need not be sent more than once; 224 if the resource has not changed between successive polls, an error 225 response is returned indicating this fact, and the resource entity is 226 not transmitted again. 228 The SIP PUBLISH [RFC3903] method also contains a similar feature, 229 where a refresh of a publication is done by reference to its assigned 230 entity-tag, instead of retransmitting the event state each time the 231 publication expiration is extended. 233 2.3. Requirements 235 As a summary, here is the required functionality to solve the 236 presented issues: 238 REQ1: It must be possible to suppress the NOTIFY request (or at a 239 minimum the event body therein) if the subscriber is already 240 in possession of the latest event state of the resource. 242 REQ2: This mechanism must apply to initial subscriptions, in which 243 the subscriber is attempting to "resume" an earlier 244 subscription. 246 REQ3: This mechanism must apply to refreshing a subscription. 248 REQ4: This mechanism must apply to terminating a subscription 249 (i.e., an unsubscribe). 251 REQ5: This mechanism must apply to fetching or polling of resource 252 state. 254 3. Overview of Operation 256 Whenever a subscriber initiates a subscription, it issues a SUBSCRIBE 257 request. The SUBSCRIBE request is sent, routed and processed by the 258 notifier normally, i.e., according to RFC3261 [RFC3261], RFC3265 259 [RFC3265]. 261 If the notifier receiving the SUBSCRIBE request supports conditional 262 subscriptions, it generates a unique entity tag for the event 263 notification, and includes it in a SIP-ETag header field of the 264 NOTIFY request. The entity tag is unique accross all versions of all 265 entities for a resource and event package. More on this in 266 Section 4. 268 Entity-tags are independent of subscriptions; the notifier remembers 269 the entity-tags of all versions of entities for a resource regardless 270 of whether or not there are any active subscription to that resource. 271 This allows notifications generated to a fetch or a poll to have 272 valid entity-tags even across subsequent fetches or polls. 274 The subscriber will store the entity-tag received in the notification 275 along with the resource state. It can then later use this entity-tag 276 to make a SUBSCRIBE contain a condition in the form of a "Suppress- 277 If-Match" header field. Unlike the "If-Match" condition in a PUBLISH 278 [RFC3903] request, which applies to whether the PUBLISH succeeds or 279 returns an error, this condition applies to the stream of 280 notifications that are sent after the SUBSCRIBE request has been 281 processed. 283 The "Suppress-If-Match" header field contains the last entity-tag 284 seen by the subscriber. This condition, if true, instructs the 285 notifier to suppress either the body of a subsequent notification, or 286 the entire notification. 288 The condition is evaluated by matching the value of the header field 289 against the current entity-tag of the resource state. There is also 290 a wildcard entity-tag with a special value of "*" that always 291 matches. 293 Subscriber Notifier 294 ---------- -------- 296 (1) SUBSCRIBE --------> 297 Expires: 3600 298 <-------- (2) 200 (or 202) 300 <-------- (3) NOTIFY 301 Subscription-State: active 302 SIP-ETag: ffee2 303 (4) 200 --------> 305 ... time passes ... 307 (5) SUBSCRIBE --------> \ if "ffee2" 308 Suppress-If-Match: ffee2 | matches 309 Expires: 3600 | local 310 | entity-tag 311 | 312 <-------- (6) 204 / then 314 ... time passes ... 316 <-------- (7) NOTIFY 317 Subscription-State: active 318 SIP-ETag: ca89a 319 (8) 200 --------> 321 ... time passes ... 323 (9) SUBSCRIBE --------> \ if "ca89" 324 Suppress-If-Match: ca89a | matches 325 Expires: 0 | local 326 | entity-tag 327 | 328 <-------- (10) 204 / then 330 Figure 1: Example Message Flow 332 Figure 1 describes a typical message flow for conditional 333 notification: 335 1. The subscriber initiates a subscription by sending a SUBSCRIBE 336 request for a resource. 338 2. After proper authentication and authorization, the notifier 339 accepts the subscription. 341 3. The notifier then immediately sends the initial event 342 notification, including a unique entity-tag in a SIP-ETag header 343 field. 345 4. The subscriber accepts the notification and stores the entity- 346 tag value along with the resource state. 348 5. Later, the subscriber refreshes the subscription, and includes 349 an entity-tag in a Suppress-If-Match header field. 351 6. The notifier evaluates the condition by matching its local 352 entity-tag value for the resource against the value of the 353 Suppress-If-Match header field. If the condition evaluates to 354 true, the notifier informs the subscriber that the notification 355 will not be sent. 357 7. At some point, the state of the resource changes, e.g., the 358 presence status of a user changes from online to busy. This 359 triggers an event notification with a new value in the SIP-ETag 360 header field. 362 8. The subscriber accepts the notification and stores the new 363 entity-tag along with the resource state. 365 9. After a while, the subscriber decides to terminate the 366 subscription. It adds a condition for Suppress-If-Match, and 367 includes the entity-tag it received in the previous NOTIFY. 369 10. The notifier evaluates the condition by matching its entity-tag 370 for the resource against the value of the Suppress-If-Match 371 header field. If the condition evaluates to true, the notifier 372 informs the subscriber that no notification will be sent. This 373 concludes the subscription. 375 The benefit of using conditional notification in this example is in 376 the reduction of the number of NOTIFY requests the subscriber can 377 expect to receive. Each event notification that the subscriber has 378 already seen is suppressed by the notifier. This example illustrates 379 only one use case for the mechanism; the same principles can be used 380 to optimize the flow of messages related to other event notification 381 use cases. 383 4. Resource Model for Entity-Tags 385 The key to understanding how conditional notification works is 386 understanding the underlying resource model of event notification. 387 In general, this model is similar to the resource model of HTTP with 388 some key differences. This section explains in detail the model as 389 it applies to SIP events. Figure 2 illustrates the model. 391 +-----+ 392 ............ | | 393 . . | URI | 394 . Represen . | | 395 . tation . +-----+ 396 . . |* 397 ............ | 398 . | 399 . V 400 . +----------+ +---------+ 401 composition | |* | Event | 402 +------<>| Resource |----------->| Package |<----. 403 | | | | | | 404 | +----------+ +----.----+ | 405 | /_\ | 406 |* | classification 407 +--------+ | | 408 | | .----------------.------' | 409 | Entity | | | | 410 | | | | |* 411 +--------+ +----------+ +------------+ +----------+ 412 ^ | | | | | | 413 | | Presence | | Conference | | Template | 414 | | | | | | | 415 |1..* +----------+ +------------+ +----.-----+ 416 +---------+ /_\ 417 | | | 418 | Version | | 419 | | +---------+ 420 +---------+ | Watcher | 421 |1 | Info | 422 | | | 423 | +---------+ 424 V 425 +---------+ 426 | Entity- | 427 | Tag | 428 | | 429 +---------+ 430 Figure 2: Resource Model Diagram 432 For a given event package, there is a single authoritative agent 433 responsible for zero or more resources. That is, even for a 434 distributed agent, the resource state is uniform across all 435 instances. The resource itself can be a list of resources [RFC4662]. 436 Conditional notification for list subscriptions is addressed in 437 Section 6.5. 439 A resource is identified by zero or more URIs, which can be SIP URIs, 440 pres URIs [RFC3859] or similar. Subscribers use this URI to 441 subscribe to the resource for certain types of events, identified by 442 the event package. 444 With a successful subscription, a subscriber receives event 445 notifications that communicate the resource state and the changes 446 thereto. Each event notification carries a representation of the 447 current resource state. This representation is influenced by many 448 factors, e.g., authorization and filtering rules, and the event 449 composition rules of the notifier. 451 This representation is realized in what is called an entity. Each 452 resource may be associated with zero or more entities; however, an 453 entity is only valid for a single resource. 455 Note that, as can be seen from the illustration, the association 456 between a resource and an entity follows the typical composition 457 relationship, i.e., an entity may belong to only one resource, and 458 it is expected to only exist with that resource. 460 An entity consists of the data carried in the body of a NOTIFY 461 message, and related meta-data in the message header. This meta-data 462 includes, but is not limited to the following SIP header fields: 464 entity-header = Content-Disposition ; defined in RFC 3261 465 / Content-Encoding ; defined in RFC 3261 466 / Content-Language ; defined in RFC 3261 467 / Content-Length ; defined in RFC 3261 468 / Content-Type ; defined in RFC 3261 469 / Event ; defined in RFC 3265 470 / extension-header ; defined in RFC 3261 472 Note that the Subscription-State is explicitly not part of the 473 entity. Event packages may in the future define additional fields 474 that implementations need to consider as part of the entity. 476 An entity has one or more versions of which only one is current and 477 all others stale. Each version has an entity-tag, which uniquely 478 identifies it accross all versions of all entities pertaining to a 479 single resource and event package. 481 Note that two entity-tags being equal does not indicate identical 482 entities. In other words, if an entity-tag is received that matches 483 a previously seen entity-tag, the subscriber cannot assume the event 484 state to be identical to that received earlier. 486 With partial event notification, the NOTIFY message only carries the 487 delta state, or the set of changes to the previous version of the 488 entity. In that case, implementations MUST consider the full event 489 state as the version of the entity to which the entity-tag in the 490 NOTIFY message applies. 492 The conditional notification mechanism is independent of the way in 493 which subscriptions are installed. In other words, the mechanism 494 supports implicit subscriptions, such as those associated with the 495 REFER method [RFC3515]. 497 It is possible that the same resource is in some shape or form 498 accessible through another mechanism in addition to SIP Event 499 Notification, e.g., HTTP or the SIP PUBLISH method. In general, 500 implementations MUST NOT expect the entity-tags to be shared between 501 the mechanisms, unless event packages or specific applications of SIP 502 Events explicitly define such dependencies. 504 5. Subscriber Behavior 506 This section augments the subscriber behavior defined in RFC3265 507 [RFC3265]. It first discusses general issues related to indicating 508 support for the mechanism (Section 5.1) and creating conditions in 509 SUBSCRIBE requests (Section 5.2); it then describes the workflows for 510 the main three use cases for making the subscription conditional. 512 5.1. Detecting Support for Conditional Notification 514 The mechanism defined in this memo is backwards compatible with SIP 515 events [RFC3265] in that a notifier supporting this mechanism will 516 insert a SIP entity-tag in its NOTIFY requests, and a subscriber that 517 understands this mechanism will know how to use it in creating a 518 conditional request. 520 Unaware subscribers will simply ignore the entity-tag, make requests 521 without conditions and receive the default treatment from the 522 notifier. Unaware notifiers will simply ignore the conditional 523 header fields, and continue normal operation. 525 5.2. Generating SUBSCRIBE Requests 527 When creating a conditional SUBSCRIBE request, the subscriber MUST 528 include a single conditional header field including an entity-tag in 529 the request. The condition is evaluated by comparing the entity-tag 530 of the subscribed resource with the entity-tag carried in the 531 conditional header field. If they match, the condition evaluates to 532 true. 534 Unlike the condition introduced for the SIP PUBLISH [RFC3903] method, 535 these conditions do not apply to the SUBSCRIBE request itself, but to 536 the resulting NOTIFY requests. When true, the condition drives the 537 notifier to change its behavior with regards to sending the 538 notifications after the SUBSCRIBE. 540 This specification defines a new header field called "Suppress-If- 541 Match". This header field introduces a condition to the SUBSCRIBE 542 request. If true, it instructs the notifier to suppress (i.e., 543 block) the first NOTIFY request following the SUBSCRIBE, and return a 544 204 (No Notification) response to the SUBSCRIBE request. As long as 545 the condition remains true, it also instructs the notifier to either 546 suppress any subsequent NOTIFY request, or if there are reportable 547 changes in the NOTIFY header, e.g., the Subscription-State has 548 changed, suppress the body of any subsequent NOTIFY request. 550 If the condition is false, the notifier follows its default 551 behaviour. 553 If the subscriber receives a 204 (No Notification) response to 554 SUBSCRIBE, it MUST consider the subscription handshake as completed. 555 That is, the subscriber can clear any handle that it may have had 556 pending on a NOTIFY to conclude establishing the subsctiption. 558 The value of the "Suppress-If-Match" header field is an entity-tag, 559 which is an opaque token that the subscriber simply copies from a 560 previously received NOTIFY request. 562 Example: 564 Suppress-If-Match: b4cf7 566 The header field can also be wildcarded using the special "*" entity- 567 tag value. Such a condition always evaluates to true regardless of 568 the value of the current entity-tag for the resource. 570 Example: 572 Suppress-If-Match: * 574 Such a wildcard condition effectively quenches a subscription; the 575 only notifications received are those reporting changes to the 576 subscription state. Such notifications will also not contain a body. 578 A subscription with a wildcard "Suppress-If-Match" condition is 579 useful in scenarios where the subscriber wants to temporarily put 580 a subscription in dormant mode. For example, a host may want to 581 conserve bandwidth and power when it detects from screen or input 582 device inactivity that the user isn't actively monitoring the 583 presence statuses of contacts. 585 5.3. Receiving NOTIFY Requests 587 When a subscriber receives a NOTIFY request that contains a SIP-ETag 588 header field, it MUST store the entity-tag if it wishes to make use 589 of the conditional notification mechanism. The subscriber MUST be 590 prepared to receive a NOTIFY with any entity-tag value, including a 591 value that matches any previous value that the subscriber might have 592 seen. 594 The subscriber MUST NOT infer any meaning from the value of an 595 entity-tag; specifically, the subscriber MUST NOT assume identical 596 entities (i.e., event state) for NOTIFYs with identical entity-tag 597 values. 599 Note that there are valid cases for which identical entity-tag 600 values indeed imply identical event state. For example, it is 601 possible to generate entity-tag values using a one-way hash 602 function. 604 5.4. Polling or Fetching Resource State 606 Polling with conditional notification allows a user agent to 607 efficiently poll resource state. This is accomplished using the 608 Suppress-If-Match condition: 610 Subscriber Notifier 611 ---------- -------- 613 (1) SUBSCRIBE --------> 614 Expires: 0 615 <-------- (2) 202 617 <-------- (3) NOTIFY 618 Subscription-State: terminated 619 SIP-ETag: f2e45 621 (4) 200 --------> 623 ... poll interval elapses ... 625 (5) SUBSCRIBE --------> 626 Suppress-If-Match: f2e45 627 Expires: 0 629 <-------- (6) 204 631 Figure 3: Polling Resource State 633 1. The subscriber polls for resource state by sending a SUBSCRIBE 634 with zero expiry (expires immediately). 636 2. The notifier accepts the SUBSCRIBE with a 202 (Accepted) 637 response. 639 3. The notifier then immediately sends a first (and last) NOTIFY 640 request with the current resource state, and the current entity- 641 tag in the SIP-ETag header field. 643 4. The subsciber accepts the notification with a 200 (OK) response. 645 5. After some arbitrary poll interval, the subscriber sends another 646 SUBSCRIBE with a Suppress-If-Match header field that includes the 647 entity-tag received in the previous NOTIFY. 649 6. Since the resource state has not changed since the previous poll 650 occurred, the notifier sends a 204 (No Notification) response, 651 which concludes the poll. 653 5.5. Resuming a Subscription 655 Resuming a subscription means the ability to continue an earlier 656 subscription that either closed abruptly, or was explicitly 657 terminated. When resuming, the subscription is established without 658 transmitting the resource state. This is accomplished with 659 conditional notification and the Suppress-If-Match header field: 661 Subscriber Notifier 662 ---------- -------- 664 (1) SUBSCRIBE --------> 665 Suppress-If-Match: ega23 666 Expires: 3600 667 <-------- (2) 202 669 <-------- (3) NOTIFY 670 Subscription-State: active 671 SIP-ETag: ega23 672 Content-Length: 0 673 (4) 200 --------> 675 Figure 4: Resuming a Subscription 677 1. The subscriber attempts to resume an earlier subscription by 678 including a Suppress-If-Match header field with the entity-tag it 679 last received. 681 2. The notifier accepts the subscription after proper authentication 682 and authorization, by sending a 202 (Accepted) response. 684 3. Since the condition is true, the notifier then immediately sends 685 an initial NOTIFY request that has no body. It also mirrors the 686 current entity-tag of the resource in the SIP-ETag header field. 688 4. The subscriber accepts the NOTIFY and sends a 200 (OK) response. 690 Had the entity-tag not been valid any longer, the condition would 691 have evaluated to false, and the NOTIFY would have had a body 692 containing the latest resource state. 694 5.6. Refreshing a Subscription 696 To refresh a subscription using conditional notification, the 697 subscriber creates a subscription refresh before the subscription is 698 about to expire, and uses the Suppress-If-Match header field: 700 Subscriber Notifier 701 ---------- -------- 703 (1) SUBSCRIBE --------> 704 Suppress-If-Match: aba91 705 Expires: 3600 707 <-------- (2) 204 708 Expires: 3600 710 Figure 5: Refreshing a Subscription 712 1. Before the subscription is about to expire, the subscriber sends 713 a SUBSCRIBE request that includes the Suppress-If-Match header 714 field with the latest entity-tag it has seen. 716 2. If the condition evaluates to true, the notifier sends a 204 (No 717 Notification) response and sends no NOTIFY request. The Expires 718 header field of the 204 (No Notification) indicates the new 719 expiry time. 721 5.7. Terminating a Subscription 723 To terminate a subscription using conditional notification, the 724 subscriber creates a SUBSCRIBE request with a Suppress-If-Match 725 condition: 727 Subscriber Notifier 728 ---------- -------- 730 (1) SUBSCRIBE --------> 731 Suppress-If-Match: ega23 732 Expires: 0 734 <-------- (2) 204 736 Figure 6: Terminating a Subscription 738 1. The subscriber decides to terminate the subscription and sends a 739 SUBSCRIBE request with the Suppress-If-Match condition with the 740 entity-tag it has last seen. 742 2. If the condition evaluates to true, the notifier sends a 204 (No 743 Notification) response, which concludes the subscription, and the 744 subscriber can clear all state related to the subscription. 746 5.8. Handling Transient Errors 748 This section is non-normative. 750 In some deployments, there may be Back-to-Back User Agent (B2BUA) 751 devices that track SIP dialogs such as subscription dialogs. These 752 devices may be unaware of the conditional notification mechanism. 754 It is possible that such B2BUAs always expect to see a NOTIFY method 755 to conclude the dialog establishment as specified in SIP Events 756 [RFC3265], and if this NOTIFY request is suppressed, may terminate or 757 block the subscription. Other problems may also arise, e.g., it is 758 possible that some B2BUA devices treat a NOTIFY with suppressed body 759 as an error. 761 In general, there is very little that an endpoint can do to recover 762 from such transient errors. The most that can be done is to try to 763 detect such errors, and define a fall back behavior. 765 If subscribers encounter transient errors in conditional 766 notification, they should disable the feature and fall back to normal 767 subscription behavior. 769 6. Notifier Behavior 771 This section augments the notifier behavior as specified in RFC3265 772 [RFC3265]. 774 6.1. Generating Entity-tags 776 A notifier MUST generate entity-tags for event notifications of all 777 resources it is responsible for. The entity-tag MUST be unique 778 across all versions of all entities for a resource and event package. 780 An entity-tag is a token carried in the SIP-ETag header field, and it 781 is opaque to the client. The notifier is free to decide on any means 782 for generating the entity-tag. It can have any value, except for 783 "*". For example, one possible method is to implement the entity-tag 784 as a simple counter, incrementing it by one for each generated 785 notification per resource. 787 An entity-tag is considered valid for as long as the entity is valid. 788 An entity becomes stale when its version is no longer the current 789 one. The notifier MUST remember the entity-tag of an entity as long 790 as the version of the entity is current. The notifier MAY remember 791 the entity-tag longer than this, e.g., for implementing journaled 792 state differentials (Section 6.4). 794 The entity tag values used in publications are not necessarily shared 795 with the entity tag values used in subscriptions. This is because 796 there may not always be a one-to-one mapping between a publication 797 and a notification; there may be several sources to the event 798 composition process. 800 6.2. Suppressing NOTIFY Bodies 802 When a condition in a SUBSCRIBE request for suppressing notifications 803 is true, i.e., the local entity-tag for the resource state and the 804 entity-tag in a Suppress-If-Match header field match, but there are 805 reportable changes in the NOTIFY header, e.g., the Subscription-State 806 has changed, the notifier MUST suppress the body of the NOTIFY 807 request. That is, the resulting NOTIFY contains no Content-Type 808 header field, the Content-Length is set to zero, and no payload is 809 attached to the message. 811 Suppressing the entity body of a NOTIFY does not change the current 812 entity-tag of the resource. Hence, the NOTIFY MUST contain a SIP- 813 Etag header field that contains the unchanged entity-tag of the 814 resource state. 816 A Suppress-If-Match header field that includes an entity-tag with the 817 value of "*" MUST always evaluate to true. 819 6.3. Suppressing NOTIFY Requests 821 When a condition in a SUBSCRIBE request to suppress notifications is 822 true, i.e., the local entity-tag of the resource and the entity-tag 823 in a Suppress-If-Match header field match, the notifier MUST suppress 824 the resulting NOTIFY request, and generate a 204 (No Notification) 825 response. As long as the condition remains true, and there are no 826 reportable changes in the NOTIFY header, all subsequent NOTIFY 827 requests MUST also be suppressed. 829 A successful conditional SUBSCRIBE request MUST extend the 830 subscription expiry time. 832 Suppressing the entire NOTIFY has no effect on the entity-tag of the 833 resource. In other words, it remains unchanged. 835 A Suppress-If-Match header field that includes an entity-tag with the 836 value of "*" MUST always evaluate to true. 838 6.4. State Differentials 840 Some event packages may support a scheme where notifications contain 841 state differentials, or state deltas [RFC3265] instead of complete 842 resource state. 844 A notifier can optionally keep track of the state changes of a 845 resource, e.g., storing the changes in a journal. If a condition 846 fails, the notifier MAY send a state differential in the NOTIFY 847 rather than the full state of the event resource. This is only 848 possible if the event package and the subscriber both support a 849 payload format that has this capability. 851 When state differentials are sent, the SIP-ETag header field MUST 852 contain an entity-tag that corresponds to the full resource state. 854 6.5. List Subscriptions 856 The Event Notification Extension for Resource Lists [RFC4662] defines 857 a mechanism for subscribing to a homogeneous list of resources using 858 the SIP events framework. 860 A list subscription delivers event notifications that contain both 861 Resource List Meta-Information (RLMI) documents as well as the 862 resource state of the individual resources on the list. 864 Implementations MUST consider the full resource state of a resource 865 list including RLMI and the entity-header as the entity to which the 866 entity-tag applies. 868 7. Protocol Element Definitions 870 This section describes the protocol extensions required for 871 conditional notification. 873 7.1. 204 (No Notification) Response Code 875 The 204 (No Notification) response code indicates that the request 876 was successful, but the notification associated with the request will 877 not be sent. 879 The response code is added to the "Success" production rule in the 880 SIP [RFC3261] message grammar. 882 7.2. Suppress-If-Match Header Field 884 The Suppress-If-Match header field is added to the definition of the 885 "message-header" rule in the SIP [RFC3261] grammar. Its use is 886 described in Section 5, Section 6.3 and Section 6.2. 888 This header field is allowed to appear in any request, but its 889 behavior is only defined for the SUBSCRIBE request. 891 7.3. Grammar 893 This section defines the formal syntax for extensions described in 894 this memo in Augmented BNF (ABNF) [RFC4234]. The rules defined here 895 augment and reference the syntax defined in RFC3261 [RFC3261] and 896 RFC3903 [RFC3903]. 898 Success =/ "204" ; No Notification 900 ; Success is defined in RFC3261. 902 message-header =/ Suppress-If-Match 904 ; message-header is defined in RFC3261. 906 Suppress-If-Match = "Suppress-If-Match" ":" entity-tag / "*" 908 ; entity-tag is defined in RFC3903. 910 8. IANA Considerations 912 This document registers a new response code and a new header field 913 name. 915 Note to IANA and the RFC editor: please replace all occurrences of 916 RFCXYZ in this section with the RFC number of this specification 917 upon publication. 919 8.1. 204 (No Notification) Response Code 921 This document registers a new response code. This response code is 922 defined by the following information, which has been added to the 923 methods and response-codes sub-registry under 924 http://www.iana.org/assignments/sip-parameters. 926 This information is to be added under "Successful 2xx" category. 928 +---------------------+-----------+ 929 | Response Code | Reference | 930 +---------------------+-----------+ 931 | 204 No Notification | [RFCXYZ] | 932 +---------------------+-----------+ 934 8.2. Suppress-If-Match Header Field 936 This document registers a new SIP header field called Suppress-If- 937 Match. This header field is defined by the following information, 938 which has been added to the header fields sub-registry under 939 http://www.iana.org/assignments/sip-parameters. 941 +-------------------+---------+-----------+ 942 | Header Name | Compact | Reference | 943 +-------------------+---------+-----------+ 944 | Suppress-If-Match | | [RFCXYZ] | 945 +-------------------+---------+-----------+ 947 9. Security Considerations 949 The security considerations for SIP event notification are 950 extensively discussed in RFC 3265 [RFC3265]. This specification 951 introduces an optimization to SIP event notification, which in itself 952 does not alter the security properties of the protocol. 954 10. Acknowledgments 956 The following people have contributed corrections and suggestions to 957 this document: Adam Roach, Sean Olson, Johnny Vrancken, Pekka Pessi, 958 Eva Leppanen, Krisztian Kiss, Peili Xu, Avshalom Houri, David 959 Viamonte, Jonathan Rosenberg, Qian Sun, Dale Worley, Tolga Asveren, 960 Brian Stucker, Eric Rescorla, Arun Arunachalam and the SIP and SIMPLE 961 working groups. 963 11. References 965 11.1. Normative References 967 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 968 Requirement Levels", BCP 14, RFC 2119, March 1997. 970 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 971 A., Peterson, J., Sparks, R., Handley, M., and E. 972 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 973 June 2002. 975 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 976 Event Notification", RFC 3265, June 2002. 978 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 979 for Event State Publication", RFC 3903, October 2004. 981 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 982 Specifications: ABNF", RFC 4234, October 2005. 984 11.2. Informative References 986 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 987 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 988 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 990 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 991 Method", RFC 3515, April 2003. 993 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 994 Package for Registrations", RFC 3680, March 2004. 996 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 997 Indication Event Package for the Session Initiation 998 Protocol (SIP)", RFC 3842, August 2004. 1000 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1001 Initiation Protocol (SIP)", RFC 3856, August 2004. 1003 [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", 1004 RFC 3859, August 2004. 1006 [RFC4660] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 1007 Requena, "Functional Description of Event Notification 1008 Filtering", RFC 4660, September 2006. 1010 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 1011 Initiation Protocol (SIP) Event Notification Extension for 1012 Resource Lists", RFC 4662, August 2006. 1014 Author's Address 1016 Aki Niemi 1017 Nokia 1018 P.O. Box 407 1019 NOKIA GROUP, FIN 00045 1020 Finland 1022 Phone: +358 50 389 1644 1023 Email: aki.niemi@nokia.com 1025 Full Copyright Statement 1027 Copyright (C) The IETF Trust (2008). 1029 This document is subject to the rights, licenses and restrictions 1030 contained in BCP 78, and except as set forth therein, the authors 1031 retain all their rights. 1033 This document and the information contained herein are provided on an 1034 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1035 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1036 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1037 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1038 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1039 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1041 Intellectual Property 1043 The IETF takes no position regarding the validity or scope of any 1044 Intellectual Property Rights or other rights that might be claimed to 1045 pertain to the implementation or use of the technology described in 1046 this document or the extent to which any license under such rights 1047 might or might not be available; nor does it represent that it has 1048 made any independent effort to identify any such rights. Information 1049 on the procedures with respect to rights in RFC documents can be 1050 found in BCP 78 and BCP 79. 1052 Copies of IPR disclosures made to the IETF Secretariat and any 1053 assurances of licenses to be made available, or the result of an 1054 attempt made to obtain a general license or permission for the use of 1055 such proprietary rights by implementers or users of this 1056 specification can be obtained from the IETF on-line IPR repository at 1057 http://www.ietf.org/ipr. 1059 The IETF invites any interested party to bring to its attention any 1060 copyrights, patents or patent applications, or other proprietary 1061 rights that may cover technology that may be required to implement 1062 this standard. Please address the information to the IETF at 1063 ietf-ipr@ietf.org.