idnits 2.17.1 draft-ietf-sipcore-subnot-etags-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (January 15, 2010) is 5208 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 1005, 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 D. Willis, Ed. 5 Intended status: Standards Track Softarmor Systems 6 Expires: July 19, 2010 January 15, 2010 8 An Extension to Session Initiation Protocol (SIP) Events for Conditional 9 Event Notification 10 draft-ietf-sipcore-subnot-etags-04 12 Abstract 14 The Session Initiation Protocol (SIP) events framework enables 15 receiving asynchronous notification of various events from other SIP 16 user agents. This framework defines the procedures for creating, 17 refreshing and terminating subscriptions, as well as fetching and 18 periodic polling of resource state. These procedures provide no 19 tools to avoid replaying event notifications that have already been 20 received by a user agent. This memo defines an extension to SIP 21 events that allows the subscriber to condition the subscription 22 request to whether the state has changed since the previous 23 notification was received. When such a condition is true, either the 24 body of a resulting event notification or the entire notification 25 message is suppressed. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on July 19, 2010. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1. Document Conventions . . . . . . . . . . . . . . . . . . . 5 81 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 82 2. Motivations and Background . . . . . . . . . . . . . . . . . . 5 83 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 84 2.2. Problem Description . . . . . . . . . . . . . . . . . . . 5 85 2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 86 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 87 4. Resource Model for Entity-Tags . . . . . . . . . . . . . . . . 10 88 5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 12 89 5.1. Detecting Support for Conditional Notification . . . . . . 13 90 5.2. Generating SUBSCRIBE Requests . . . . . . . . . . . . . . 13 91 5.3. Receiving NOTIFY Requests . . . . . . . . . . . . . . . . 14 92 5.4. Polling or Fetching Resource State . . . . . . . . . . . . 15 93 5.5. Resuming a Subscription . . . . . . . . . . . . . . . . . 17 94 5.6. Refreshing a Subscription . . . . . . . . . . . . . . . . 18 95 5.7. Terminating a Subscription . . . . . . . . . . . . . . . . 18 96 5.8. Handling Transient Errors . . . . . . . . . . . . . . . . 19 97 6. Notifier Behavior . . . . . . . . . . . . . . . . . . . . . . 19 98 6.1. Generating Entity-tags . . . . . . . . . . . . . . . . . . 20 99 6.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 20 100 6.3. Suppressing NOTIFY Requests . . . . . . . . . . . . . . . 21 101 6.4. State Differentials . . . . . . . . . . . . . . . . . . . 21 102 6.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 22 103 7. Protocol Element Definitions . . . . . . . . . . . . . . . . . 22 104 7.1. 204 (No Notification) Response Code . . . . . . . . . . . 22 105 7.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 22 106 7.3. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 22 107 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 108 8.1. 204 (No Notification) Response Code . . . . . . . . . . . 23 109 8.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 23 110 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 111 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 112 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 113 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 114 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 117 1. Introduction 119 The Session Initiation Protocol (SIP) events framework provides an 120 extensible facility for requesting notification of certain events 121 from other SIP user agents. This framework includes procedures for 122 creating, refreshing and terminating of subscriptions, as well as the 123 possibility to fetch or periodically poll the event resource. 125 Several instantiations of this framework, called event packages have 126 been defined, e.g., for presence [RFC3856], message waiting 127 indications [RFC3842] and registrations [RFC3680]. 129 By default, every SUBSCRIBE request generates a NOTIFY request 130 containing the latest event state. Typically, a SUBSCRIBE request is 131 issued by the subscriber whenever it needs a subscription to be 132 installed, periodically refreshed or terminated. Once the 133 subscription has been installed, the majority of the NOTIFYs 134 generated by the subscription refreshes are superfluous; the 135 subscriber usually is in possession of the event state already, 136 except in the unlikely case where a state change exactly coincides 137 with the periodic subscription refresh. In most cases, the final 138 event state generated upon terminating the subscription similarly 139 contains resource state that the subscriber already has. 141 Fetching or polling of resource state behaves in a similarly 142 suboptimal way in cases where the state has not changed since the 143 previous poll occurred. In general, the problem lies in with the 144 inability to persist state across a SUBSCRIBE request. 146 This memo defines an extension to optimize the SIP events framework. 147 This extension allows a notifier to tag notifications (called entity- 148 tags hereafter), and the subscriber to condition its subsequent 149 SUBSCRIBE requests for actual changes since a notification carrying 150 that entity-tag was issued. The solution is similar to conditional 151 requests defined in the Hypertext Transfer Protocol (HTTP) [RFC2616], 152 and follows the mechanism already defined for the PUBLISH [RFC3903] 153 method for issuing conditional event publications. 155 This memo is structured as follows. Section 2 explains the 156 background, motivations and requirements for the work; Section 3 157 gives a general overview of the mechanism; Section 4 explains the 158 underlying model for resources and entities as they apply to 159 conditional notification; Section 5 defines the subscriber behavior; 160 Section 6 defines the notifier behavior; Section 7 includes the 161 protocol element definitions; Section 8 includes the IANA 162 considerations; and Section 9 includes the security considerations. 164 1.1. Document Conventions 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in BCP 14, RFC 2119 169 [RFC2119] and indicate requirement levels for compliant 170 implementations. 172 1.2. Terminology 174 In addition to the terminology introduced in [RFC3261], [RFC3265] and 175 [RFC3903], this specification uses these additional terms to describe 176 the objects of conditional notification: 178 resource 179 An object identified by a URI, whose resource state can be 180 accessed using the SIP Event Notification framework. There is a 181 single authoritative notifier responsible for communicating the 182 resource state. 184 entity 185 The representation of resource state. An entity consists of the 186 state data carried in the body of a NOTIFY message, as well as 187 related meta-data in the message header. There may be many 188 versions of an entity, one current and the others stale. Each 189 version of an entity is identified by an entity-tag, which is 190 guaranteed to be unique across all versions of all entities for a 191 resource and event package. 193 2. Motivations and Background 195 2.1. Overview 197 A SUBSCRIBE request creates a subscription with a finite lifetime. 198 This lifetime is negotiated using the Expires header field, and 199 unless the subscription is refreshed by the subscriber before the 200 expiration is met, the subscription is terminated. The frequency of 201 these subscription refreshes depends on the event package, and 202 typically ranges from minutes to hours. 204 2.2. Problem Description 206 The SIP events framework does not include different protocol methods 207 for initiating and terminating of subscriptions, subscription 208 refreshes and fetches inside and outside of the SIP dialog. The 209 SUBSCRIBE method is overloaded to perform all of these functions The 210 difference between a fetch that does not create a (lasting) 211 subscription, and a SUBSCRIBE that creates one is in the Expires 212 header field value of the SUBSCRIBE; a zero-expiry SUBSCRIBE only 213 generates a single NOTIFY, after which the subscription immediately 214 terminates. Lasting subscriptions typically have relatively short 215 expiry periods, requiring periodic sending of new SUBSCRIBE requests 216 in order to refresh the subscription. 218 Each new SUBSCRIBE request generates a NOTIFY request containing the 219 latest resource state. Even if the state has not changed, it is sent 220 again in response to each poll or subscription refresh. This is very 221 similar to the HTTP [RFC2616] problem of repeated GET operations on a 222 resource. HTTP solves the problem using conditional requests. The 223 server versions each entity with an entity tag that identifies a 224 specific instance of that entity. Clients making GET requests can 225 then include the entity tag for the version of the entity that they 226 currently to be current in an "If-None-Match" header field, and the 227 server can compare this entity tag to the entity it believes to be 228 current and suppress resending the entity in the response if the 229 server believes the client's version matches. In other words, the 230 server doesn't re-send information that the client has already 231 received. 233 The SIP PUBLISH [RFC3903] method uses a similar mechanism, where a 234 refresh of a publication is done by reference to its assigned entity- 235 tag, instead of retransmitting the event state each time the 236 publication expiration is extended. 238 2.3. Requirements 240 As a summary, here is the required functionality to solve the 241 presented issues: 243 REQ1: It must be possible to suppress the NOTIFY request (or at a 244 minimum the event body therein) if the subscriber is already 245 in possession of (or has previously received and discarded) 246 the latest event state of the resource. 248 REQ2: This mechanism must apply to initial subscriptions, in which 249 the subscriber is attempting to resume an earlier 250 subscription that has been paused. 252 REQ3: This mechanism must apply to refreshing a subscription. 254 REQ4: This mechanism must apply to terminating a subscription 255 (i.e., an unsubscribe). 257 REQ5: This mechanism must apply to fetching or polling of resource 258 state. 260 3. Overview of Operation 262 Whenever a subscriber initiates a subscription, it issues a SUBSCRIBE 263 request. The SUBSCRIBE request is sent, routed and processed by the 264 notifier normally, i.e., according to The Session Initiation Protocol 265 [RFC3261], and SIP Specific Event Notification [RFC3265]. 267 If the notifier receiving the SUBSCRIBE request supports conditional 268 subscriptions, it generates an entity tag for the current entity, and 269 includes it in a SIP-ETag header field of the NOTIFY request. The 270 entity tag is unique across all versions of all entities for a 271 resource and event package. More on this in Section 4. 273 Entity-tags are independent of subscriptions. This allows 274 notifications generated to a fetch or a poll to have valid entity- 275 tags even across subsequent fetches or polls. 277 The subscriber will store the entity-tag received in the notification 278 along with the resource state. It can then later use this entity-tag 279 to make a SUBSCRIBE contain a condition in the form of a "Suppress- 280 If-Match" header field. Unlike the "If-Match" condition in a PUBLISH 281 [RFC3903] request, which applies to whether the PUBLISH succeeds or 282 returns an error, this condition applies to the stream of 283 notifications that are sent after the SUBSCRIBE request has been 284 processed. 286 The "Suppress-If-Match" header field contains the last entity-tag 287 seen by the subscriber. This condition, if true, instructs the 288 notifier to suppress either the body of a subsequent notification, or 289 the entire notification. 291 The condition is evaluated by matching the value of the header field 292 against the entity-tag of the entity that would normally be sent in 293 the associated NOTIFY message. There is also a wildcard entity-tag 294 with a special value of "*" that always matches. 296 Subscriber Notifier 297 ---------- -------- 299 (1) SUBSCRIBE --------> 300 Expires: 3600 301 <-------- (2) 200 (or 202) 303 <-------- (3) NOTIFY 304 Subscription-State: active 305 SIP-ETag: ffee2 306 (4) 200 --------> 308 ... time passes ... 310 (5) SUBSCRIBE --------> \ if "ffee2" 311 Suppress-If-Match: ffee2 | matches 312 Expires: 3600 | local 313 | entity-tag 314 | 315 <-------- (6) 204 / then 317 ... time passes and resource state (entity) changes... 319 <-------- (7) NOTIFY 320 Subscription-State: active 321 SIP-ETag: ca89a 322 (8) 200 --------> 324 ... time passes ... 326 (9) SUBSCRIBE --------> \ if "ca89" 327 Suppress-If-Match: ca89a | matches 328 Expires: 0 | local 329 | entity-tag 330 | 331 <-------- (10) 204 / then 333 Figure 1: Example Message Flow 335 Figure 1 describes a typical message flow for conditional 336 notification: 338 1. The subscriber initiates a subscription by sending a SUBSCRIBE 339 request for a resource. 341 2. After proper authentication and authorization, the notifier 342 accepts the subscription. 344 3. The notifier then immediately sends the initial event 345 notification, including a unique entity-tag in a SIP-ETag header 346 field. 348 4. The subscriber accepts the notification and stores the entity- 349 tag value along with the resource state. 351 5. Later, the subscriber refreshes the subscription, and includes 352 an entity-tag in a Suppress-If-Match header field. 354 6. The notifier evaluates the condition by matching its local 355 entity-tag value for the resource against the value of the 356 Suppress-If-Match header field. If the condition evaluates to 357 true, the notifier informs the subscriber that the notification 358 will not be sent. 360 7. At some point, the state of the resource changes, e.g., the 361 presence status of a user changes from online to busy. This 362 triggers an event notification with a new value in the SIP-ETag 363 header field. 365 8. The subscriber accepts the notification and stores the new 366 entity-tag along with the resource state. 368 9. After a while, the subscriber decides to terminate the 369 subscription. It adds a condition for Suppress-If-Match, and 370 includes the entity-tag it received in the previous NOTIFY. 372 10. The notifier evaluates the condition by matching its entity-tag 373 for the resource against the value of the Suppress-If-Match 374 header field. If the condition evaluates to true, the notifier 375 informs the subscriber that no notification will be sent. This 376 concludes the subscription. 378 The benefit of using conditional notification in this example is in 379 the reduction of the number of NOTIFY requests the subscriber can 380 expect to receive. Each event notification that the subscriber has 381 already seen is suppressed by the notifier. This example illustrates 382 only one use case for the mechanism; the same principles can be used 383 to optimize the flow of messages related to other event notification 384 use cases. 386 4. Resource Model for Entity-Tags 388 The key to understanding how conditional notification works is 389 understanding the underlying resource model of event notification. 390 In general, this model is similar to the resource model of HTTP with 391 some key differences. This section explains in detail the model as 392 it applies to SIP events. Figure 2 illustrates the model. 394 +-----+ 395 ............ | | 396 . . | URI | 397 . Represen . | | 398 . tation . +-----+ 399 . . |* 400 ............ | 401 . | 402 . V 403 . +----------+ +---------+ 404 composition | |* | Event | 405 +------<>| Resource |----------->| Package |<----. 406 | | | | | | 407 | +----------+ +----.----+ | 408 | /_\ | 409 |* | classification 410 +--------+ | | 411 | | .----------------.------' | 412 | Entity | | | | 413 | | | | |* 414 +--------+ +----------+ +------------+ +----------+ 415 ^ | | | | | | 416 | | Presence | | Conference | | Template | 417 | | | | | | | 418 |1..* +----------+ +------------+ +----.-----+ 419 +---------+ /_\ 420 | | | 421 | Version | | 422 | | +---------+ 423 +---------+ | Watcher | 424 |1 | Info | 425 | | | 426 | +---------+ 427 V 428 +---------+ 429 | Entity- | 430 | Tag | 431 | | 432 +---------+ 433 Figure 2: Resource Model Diagram 435 For a given event package, there is a single authoritative agent 436 responsible for zero or more resources. That is, even for a 437 distributed agent, the resource state is uniform across all 438 instances. The resource itself can be a list of resources [RFC4662]. 439 Conditional notification for list subscriptions is addressed in 440 Section 6.5. 442 A resource is identified by zero or more URIs, which can be SIP URIs, 443 pres URIs [RFC3859] or similar. Subscribers use this URI to 444 subscribe to the resource for certain types of events, identified by 445 the event package. 447 With a successful subscription, a subscriber receives event 448 notifications that communicate the resource state and the changes 449 thereto. Each event notification carries a representation of the 450 current resource state. This representation is influenced by many 451 factors, e.g., authorization and filtering rules, and the event 452 composition rules of the notifier. 454 This representation is realized in an "entity". Each resource may be 455 associated with zero or more entities. For example, there may be 456 multiple subscribers to the presence information of a single user (a 457 resource), and each subscriber may have a different filtered view of 458 that resource, producing one entity per subscriber. However, each 459 entity is associated with one and only one resource; there is no 460 "compositing" of resources at the entity level. Resources may 461 themselves be made up of information from other resources (be 462 "composite resources"), but this does not change the one-resource- 463 per-entity rule. 465 An entity consists of the data carried in the body of a NOTIFY 466 message, and related meta-data in the message header. Whenever the 467 data in the body or any of the meta-data changes, the notifier MUST 468 produce a new entity-tag. This meta-data MUST include, but is not 469 limited to the following SIP header fields defined in The Session 470 Initiation Protocol [RFC3261] and SIP Specific Event Notification 471 [RFC3265]: 473 1. Content-Disposition 475 2. Content-Encoding 477 3. Content-Language 479 4. Content-Length 480 5. Content-Type 482 6. Event 484 Note that the Subscription-State is explicitly not part of the 485 entity. Event packages may in the future define additional fields 486 that implementations need to consider as part of the entity. 488 An entity has one or more versions of which only one is current and 489 all others stale. Each version has an entity-tag, which uniquely 490 identifies it across all versions of all entities pertaining to a 491 single resource and event package. 493 Note that two entity-tags for different resources being equal does 494 not indicate identical entities. In other words, if an entity-tag 495 received for a subscription to a first resource matches an entity-tag 496 received for a subscription to a second resource, the subscriber 497 cannot assume that the two entity values are equal. 499 With partial event notification, the NOTIFY message only carries the 500 delta state, or the set of changes to the previous version of the 501 entity. In that case, implementations MUST consider the full event 502 state as the version of the entity to which the entity-tag in the 503 NOTIFY message applies. 505 The conditional notification mechanism is independent of the way in 506 which subscriptions are installed. In other words, the mechanism 507 supports implicit subscriptions, such as those associated with the 508 REFER method [RFC3515]. 510 It is possible that the same resource is in some shape or form 511 accessible through another mechanism in addition to SIP Event 512 Notification, e.g., HTTP or the SIP PUBLISH method. In general, 513 implementations MUST NOT expect the entity-tags to be shared between 514 the mechanisms, unless event packages or specific applications of SIP 515 Events explicitly define such dependencies. 517 5. Subscriber Behavior 519 This section augments the subscriber behavior defined in RFC3265 520 [RFC3265]. It first discusses general issues related to indicating 521 support for the mechanism (Section 5.1) and creating conditions in 522 SUBSCRIBE requests (Section 5.2); it then describes the workflows for 523 the main three use cases for making the subscription conditional. 525 5.1. Detecting Support for Conditional Notification 527 The mechanism defined in this memo is backwards compatible with SIP 528 events [RFC3265] in that a notifier supporting this mechanism will 529 insert a SIP entity-tag in its NOTIFY requests, and a subscriber that 530 understands this mechanism will know how to use it in creating a 531 conditional request. 533 Unaware subscribers will simply ignore the entity-tag, make requests 534 without conditions and receive the default treatment from the 535 notifier. Unaware notifiers will simply ignore the conditional 536 header fields, and continue normal operation. 538 5.2. Generating SUBSCRIBE Requests 540 When creating a conditional SUBSCRIBE request, the subscriber MUST 541 include a single conditional header field including an entity-tag in 542 the request. The condition is evaluated by comparing the entity-tag 543 of the subscribed resource with the entity-tag carried in the 544 conditional header field. If they match, the condition evaluates to 545 true. 547 Unlike the condition introduced for the SIP PUBLISH [RFC3903] method, 548 these conditions do not apply to the SUBSCRIBE request itself, but to 549 the resulting NOTIFY requests. When true, the condition drives the 550 notifier to change its behavior with regards to sending the 551 notifications after the SUBSCRIBE. 553 This specification defines a new header field called "Suppress-If- 554 Match". This header field introduces a condition to the SUBSCRIBE 555 request. If true, it instructs the notifier to either omit the body 556 of the resulting NOTIFY message (if the SUBSCRIBE is not sent within 557 an existing dialog), or suppress (i.e., block) the NOTIFY request 558 that would otherwise be triggered the SUBSCRIBE (for an established 559 dialog). In the latter case, the SUBSCRIBE message will be answered 560 with a 204 (No Notification) response. As long as the condition 561 remains true, it also instructs the notifier to either suppress any 562 subsequent NOTIFY request, or if there are reportable changes in the 563 NOTIFY header, e.g., the Subscription-State has changed, suppress the 564 body of any subsequent NOTIFY request. 566 If the condition is false, the notifier follows its default 567 behaviour. 569 If the subscriber receives a 204 (No Notification) to an in-dialog 570 SUBSCRIBE, the subscriber can clear handle that it may have had 571 pending on a NOTIFY in response the SUBSCRIBE message. 573 The value of the "Suppress-If-Match" header field is an entity-tag, 574 which is an opaque token that the subscriber simply copies (bytewise) 575 from a previously received NOTIFY request. Inclusion of an entity- 576 tag in a "Suppress-If-Match" header field of a SUBSCRIBE request 577 indicates that the client either has a copy of, or is capable of re- 578 creating a copy of, the entity associated with that entity-tag. 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 and those in response to a SUBSCRIBE message sent 595 outside of an existing dialog. In both cases, the notifications will 596 not contain a body. 598 A subscription with a wildcard "Suppress-If-Match" condition is 599 useful in scenarios where the subscriber wants to temporarily put 600 a subscription in dormant mode. For example, a host may want to 601 conserve bandwidth and power when it detects from screen or input 602 device inactivity that the user isn't actively monitoring the 603 presence statuses of contacts. 605 5.3. Receiving NOTIFY Requests 607 When a subscriber receives a NOTIFY request that contains a SIP-ETag 608 header field, it MUST store the entity-tag if it wishes to make use 609 of the conditional notification mechanism. The subscriber MUST be 610 prepared to receive a NOTIFY with any entity-tag value, including a 611 value that matches any previous value that the subscriber might have 612 seen. 614 The subscriber MUST NOT infer any meaning from the value of an 615 entity-tag; specifically, the subscriber MUST NOT assume identical 616 entities (i.e., event state) for NOTIFYs with identical entity-tag 617 values when those NOTIFYs result from subscription to different 618 resources. 620 Note that there are valid cases for which identical entity-tag 621 values on different resources may occur. For example, it is 622 possible to generate entity-tag values using a one-way hash 623 function, resulting in the possibility that two different 624 resources having the same entity-value will also have the same 625 entity tag. Clients however MUST NOT assume that this is the 626 case, as the algorithm for the generation of entity tags is 627 notifier-dependent and not negotiated with the subscriber. 628 Consequently, the subscriber cannot differentiate between two 629 entity tags that have the same value because they are similar 630 hashes of identical entities, or because two notifiers happen to 631 have used the same sequential number as an entity tag. Entity 632 tags are only required to be unique for a given resource, not 633 globally unique. 635 5.4. Polling or Fetching Resource State 637 Polling with conditional notification allows a user agent to 638 efficiently poll resource state. This is accomplished using the 639 Suppress-If-Match condition: 641 Subscriber Notifier 642 ---------- -------- 644 (1) SUBSCRIBE --------> 645 Expires: 0 646 <-------- (2) 202 648 <-------- (3) NOTIFY 649 Subscription-State: terminated 650 SIP-ETag: f2e45 651 Content-Length: 17539 653 (4) 200 --------> 655 ... poll interval elapses ... 657 (5) SUBSCRIBE --------> 658 Suppress-If-Match: f2e45 659 Expires: 0 660 <-------- (6) 202 662 <-------- (7) NOTIFY 663 Subscription-State: terminated 664 SIP-ETag: f2e45 665 Content-Length: 0 667 (8) 200 --------> 669 Figure 3: Polling Resource State 671 1. The subscriber polls for resource state by sending a SUBSCRIBE 672 with zero expiry (expires immediately). 674 2. The notifier accepts the SUBSCRIBE with a 202 (Accepted) 675 response. 677 3. The notifier then immediately sends a first (and last) NOTIFY 678 request with the current resource state, and the current entity- 679 tag in the SIP-ETag header field. 681 4. The subscriber accepts the notification with a 200 (OK) response. 683 5. After some arbitrary poll interval, the subscriber sends another 684 SUBSCRIBE with a Suppress-If-Match header field that includes the 685 entity-tag received in the previous NOTIFY. 687 6. The notifier accepts the SUBSCRIBE with a 202 (Accepted) 688 response. (202 would be used to indicate that the subscription 689 request was understood without also indicating that it was 690 authorized, as per section 3.1.6.1 of SIP Specific Event 691 Notification" [RFC3265].) 693 7. Since the resource state has not changed since the previous poll 694 occurred, the notifier sends a NOTIFY message with no body. It 695 also mirrors the current entity-tag of the resource in the SIP- 696 ETag header field. 698 8. The subscriber accepts the notification with a 200 (OK) response. 700 5.5. Resuming a Subscription 702 Resuming a subscription means the ability to continue an earlier 703 subscription that either closed abruptly, or was explicitly 704 terminated. When resuming, the subscription is established without 705 transmitting the resource state. This is accomplished with 706 conditional notification and the Suppress-If-Match header field: 708 Subscriber Notifier 709 ---------- -------- 711 (1) SUBSCRIBE --------> 712 Suppress-If-Match: ega23 713 Expires: 3600 714 <-------- (2) 202 716 <-------- (3) NOTIFY 717 Subscription-State: active 718 SIP-ETag: ega23 719 Content-Length: 0 720 (4) 200 --------> 722 Figure 4: Resuming a Subscription 724 1. The subscriber attempts to resume an earlier subscription by 725 including a Suppress-If-Match header field with the entity-tag it 726 last received. 728 2. The notifier accepts the subscription after proper authentication 729 and authorization, by sending a 202 (Accepted) response. 731 3. Since the condition is true, the notifier then immediately sends 732 an initial NOTIFY request that has no body. It also mirrors the 733 current entity-tag of the resource in the SIP-ETag header field. 735 4. The subscriber accepts the NOTIFY and sends a 200 (OK) response. 737 Had the entity-tag not been valid any longer, the condition would 738 have evaluated to false, and the NOTIFY would have had a body 739 containing the latest resource state. 741 5.6. Refreshing a Subscription 743 To refresh a subscription using conditional notification, the 744 subscriber creates a subscription refresh before the subscription 745 expires, and uses the Suppress-If-Match header field: 747 Subscriber Notifier 748 ---------- -------- 750 (1) SUBSCRIBE --------> 751 Suppress-If-Match: aba91 752 Expires: 3600 754 <-------- (2) 204 755 Expires: 3600 757 Figure 5: Refreshing a Subscription 759 1. Before the subscription expires, the subscriber sends a SUBSCRIBE 760 request that includes the Suppress-If-Match header field with the 761 latest entity-tag it has seen. 763 2. If the condition evaluates to true, the notifier sends a 204 (No 764 Notification) response and sends no NOTIFY request. The Expires 765 header field of the 204 (No Notification) indicates the new 766 expiry time. 768 5.7. Terminating a Subscription 770 To terminate a subscription using conditional notification, the 771 subscriber creates a SUBSCRIBE request with a Suppress-If-Match 772 condition: 774 Subscriber Notifier 775 ---------- -------- 777 (1) SUBSCRIBE --------> 778 Suppress-If-Match: ega23 779 Expires: 0 781 <-------- (2) 204 783 Figure 6: Terminating a Subscription 785 1. The subscriber decides to terminate the subscription and sends a 786 SUBSCRIBE request with the Suppress-If-Match condition with the 787 entity-tag it has last seen. 789 2. If the condition evaluates to true, the notifier sends a 204 (No 790 Notification) response, which concludes the subscription, and the 791 subscriber can clear all state related to the subscription. 793 5.8. Handling Transient Errors 795 This section is non-normative. 797 In some deployments, there may be Back-to-Back User Agent (B2BUA) 798 devices that track SIP dialogs such as subscription dialogs. These 799 devices may be unaware of the conditional notification mechanism. 801 It is possible that some B2BUA devices may treat a NOTIFY with 802 suppressed body as an error, or may expect all SUBSCRIBE messages to 803 have an associated NOTIFY message. 805 In general, there is very little that an endpoint can do to recover 806 from such transient errors. The most that can be done is to try to 807 detect such errors, and define a fall back behavior. 809 If subscribers encounter transient errors in conditional 810 notification, they should disable the feature and fall back to normal 811 subscription behavior. 813 6. Notifier Behavior 815 This section augments the notifier behavior as specified in RFC3265 816 [RFC3265]. 818 6.1. Generating Entity-tags 820 An entity-tag is a token carried in the SIP-ETag header field, and it 821 is opaque to the client. The notifier is free to decide on any means 822 for generating the entity-tag. It can have any value, except for 823 "*". For example, one possible method is to implement the entity-tag 824 as a simple counter, incrementing it by one for each generated 825 notification per resource. 827 A notifier MUST generate entity-tags for event notifications of all 828 resources it is responsible for. The entity-tag MUST be unique 829 across all versions of all entities for each state of a resource as 830 reported by a given event package. Otherwise said, for any 831 subscription or sequence of subscriptions to a specific resource 832 using a singular event package, each entity tag produced MUST map to 833 one and only one presentation of resource state (entity). Two 834 identical entities for a specific resource might or might not have 835 identical entity tags; this decision is left to the notifier. 837 An entity-tag is considered valid for as long as the entity exits. 838 An entity becomes stale when its version is no longer the current 839 one. The notifier MUST remember (or be able to recalculate) the 840 entity-tag of an entity as long as the version of the entity is 841 current. The notifier MAY remember the entity-tag longer than this, 842 e.g., for implementing journaled state differentials (Section 6.4). 844 The entity tag values used in publications are not necessarily shared 845 with the entity tag values used in subscriptions. This is because 846 there may not always be a one-to-one mapping between a publication 847 and a notification of state change; there may be several sources to 848 the event composition process, and a publication into a resource may 849 not affect the resulting entity. 851 6.2. Suppressing NOTIFY Bodies 853 When a condition in a SUBSCRIBE request for suppressing notifications 854 is true (i.e., the local entity-tag for the resource state and the 855 entity-tag in a Suppress-If-Match header field are byte-wise 856 identical) but there are reportable changes in the NOTIFY header 857 (e.g., the Subscription-State has changed), the notifier MUST 858 suppress the body of the NOTIFY request. That is, the resulting 859 NOTIFY contains no Content-Type header field, the Content-Length is 860 set to zero, and no payload is attached to the message. 862 Additionally, when a condition in a SUBSCRIBE request for suppressing 863 notifications is true and the SUBSCRIBE message is not sent within an 864 established dialog, the notifier MUST send a NOTIFY request with a 865 suppressed entity body. 867 Suppressing the entity body of a NOTIFY does not change the current 868 entity-tag of the resource. Hence, the NOTIFY MUST contain a SIP- 869 Etag header field that contains the unchanged entity-tag of the 870 resource state. 872 A Suppress-If-Match header field that includes an entity-tag with the 873 value of "*" MUST always evaluate to true. 875 6.3. Suppressing NOTIFY Requests 877 When a condition in a SUBSCRIBE request to suppress notifications is 878 true (i.e., the local entity-tag of the resource and the entity-tag 879 in a Suppress-If-Match header field match), and the SUBSCRIBE is sent 880 within an established dialog, then the notifier MUST suppress the 881 resulting NOTIFY request, and generate a 204 (No Notification) 882 response. As long as the condition remains true, and there are no 883 reportable changes in the NOTIFY header, all subsequent NOTIFY 884 requests MUST also be suppressed. 886 Notifiers MUST NOT suppress a NOTIFY unless the corresponding 887 SUBSCRIBE message was sent in an established dialog. 889 A successful conditional SUBSCRIBE request MUST extend the 890 subscription expiry time. 892 Suppressing the entire NOTIFY has no effect on the entity-tag of the 893 resource. In other words, it remains unchanged. 895 A Suppress-If-Match header field that includes an entity-tag with the 896 value of "*" MUST always evaluate to true. 898 6.4. State Differentials 900 Some event packages support a scheme where notifications contain 901 state differentials, or state deltas [RFC3265] instead of complete 902 resource state. 904 Further extensions could define means for notifiers to keep track of 905 the state changes of a resource, e.g., storing the changes in a 906 journal. If a condition fails, the notifier would then send a state 907 differential in the NOTIFY rather than the full state of the event 908 resource. This is only possible if the event package and the 909 subscriber both support a payload format that has this capability. 911 When state differentials are sent, the SIP-ETag header field MUST 912 contain an entity-tag that corresponds to the full resource state. 914 6.5. List Subscriptions 916 The Event Notification Extension for Resource Lists [RFC4662] defines 917 a mechanism for subscribing to a homogeneous list of resources using 918 the SIP events framework. 920 A list subscription delivers event notifications that contain both 921 Resource List Meta-Information (RLMI) documents as well as the 922 resource state of the individual resources on the list. 924 Implementations MUST consider the full resource state of a resource 925 list including RLMI and the entity-header as the entity to which the 926 entity-tag applies. 928 7. Protocol Element Definitions 930 This section describes the protocol extensions required for 931 conditional notification. 933 7.1. 204 (No Notification) Response Code 935 The 204 (No Notification) response code indicates that the request 936 was successful, but the notification associated with the request will 937 not be sent. It is valid only in response to a SUBSCRIBE message 938 sent within an established dialog. 940 The response code is added to the "Success" production rule in the 941 SIP [RFC3261] message grammar. 943 7.2. Suppress-If-Match Header Field 945 The Suppress-If-Match header field is added to the definition of the 946 "message-header" rule in the SIP [RFC3261] grammar. Its use is 947 described in Section 5, Section 6.3 and Section 6.2. 949 This header field is allowed to appear in any request, but its 950 behavior is only defined for the SUBSCRIBE request. 952 7.3. Grammar 954 This section defines the formal syntax for extensions described in 955 this memo in Augmented BNF (ABNF) [RFC5234]. The rules defined here 956 augment and reference the syntax defined in RFC3261 [RFC3261] and 957 RFC3903 [RFC3903]. 959 Success =/ "204" ; No Notification 961 ; Success is defined in RFC3261. 963 message-header =/ Suppress-If-Match 965 ; message-header is defined in RFC3261. 967 Suppress-If-Match = "Suppress-If-Match" HCOLON ( entity-tag / "*" ) 969 ; entity-tag is defined in RFC3903. 971 8. IANA Considerations 973 This document registers a new response code and a new header field 974 name. 976 Note to IANA and the RFC editor: please replace all occurrences of 977 RFCXYZ in this section with the RFC number of this specification 978 upon publication. 980 8.1. 204 (No Notification) Response Code 982 This document registers a new response code. This response code is 983 defined by the following information, which has been added to the 984 methods and response-codes sub-registry under 985 http://www.iana.org/assignments/sip-parameters. 987 This information is to be added under "Successful 2xx" category. 989 +---------------------+-----------+ 990 | Response Code | Reference | 991 +---------------------+-----------+ 992 | 204 No Notification | [RFCXYZ] | 993 +---------------------+-----------+ 995 8.2. Suppress-If-Match Header Field 997 This document registers a new SIP header field called Suppress-If- 998 Match. This header field is defined by the following information, 999 which has been added to the header fields sub-registry under 1000 http://www.iana.org/assignments/sip-parameters. 1002 +-------------------+---------+-----------+ 1003 | Header Name | Compact | Reference | 1004 +-------------------+---------+-----------+ 1005 | Suppress-If-Match | | [RFCXYZ] | 1006 +-------------------+---------+-----------+ 1008 9. Security Considerations 1010 The security considerations for SIP event notification are 1011 extensively discussed in RFC 3265 [RFC3265]. This specification 1012 introduces an optimization to SIP event notification, which in itself 1013 does not alter the security properties of the protocol. 1015 10. Acknowledgments 1017 The following people have contributed corrections and suggestions to 1018 this document: Adam Roach, Sean Olson, Johnny Vrancken, Pekka Pessi, 1019 Eva Leppanen, Krisztian Kiss, Peili Xu, Avshalom Houri, David 1020 Viamonte, Jonathan Rosenberg, Qian Sun, Dale Worley, Tolga Asveren, 1021 Brian Stucker, Eric Rescorla, Arun Arunachalam and the SIP and SIMPLE 1022 working groups. 1024 11. References 1026 11.1. Normative References 1028 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1029 Requirement Levels", BCP 14, RFC 2119, March 1997. 1031 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1032 A., Peterson, J., Sparks, R., Handley, M., and E. 1033 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1034 June 2002. 1036 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1037 Event Notification", RFC 3265, June 2002. 1039 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 1040 for Event State Publication", RFC 3903, October 2004. 1042 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1043 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1045 11.2. Informative References 1047 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1048 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1049 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1051 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1052 Method", RFC 3515, April 2003. 1054 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1055 Package for Registrations", RFC 3680, March 2004. 1057 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 1058 Indication Event Package for the Session Initiation 1059 Protocol (SIP)", RFC 3842, August 2004. 1061 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1062 Initiation Protocol (SIP)", RFC 3856, August 2004. 1064 [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", 1065 RFC 3859, August 2004. 1067 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 1068 Initiation Protocol (SIP) Event Notification Extension for 1069 Resource Lists", RFC 4662, August 2006. 1071 Authors' Addresses 1073 Aki Niemi 1074 Nokia 1075 P.O. Box 407 1076 NOKIA GROUP, FIN 00045 1077 Finland 1079 Phone: +358 50 389 1644 1080 Email: aki.niemi@nokia.com 1082 Dean Willis (editor) 1083 Softarmor Systems 1084 3100 Independence Pkwy #311-164 1085 Plano, TX 75075 1086 USA 1088 Phone: +1 214 504 1987 1089 Email: dean.willis@softarmor.com