idnits 2.17.1 draft-ietf-sipcore-rfc3265bis-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3261, but the abstract doesn't seem to directly say this. It does mention RFC3261 though, so this could be OK. -- The abstract seems to indicate that this document updates RFC4660, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- 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 (April 30, 2012) is 4372 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: 'Roach' is mentioned on line 1804, but not defined ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) -- Duplicate reference: RFC4660, mentioned in 'RFC4660', was also mentioned in 'RFC 4660'. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. B. Roach 3 Internet-Draft Tekelec 4 Obsoletes: 3265 (if approved) April 30, 2012 5 Updates: 3261, 4660 6 (if approved) 7 Intended status: Standards Track 8 Expires: November 1, 2012 10 SIP-Specific Event Notification 11 draft-ietf-sipcore-rfc3265bis-09 13 Abstract 15 This document describes an extension to the Session Initiation 16 Protocol (SIP) defined by RFC 3261. The purpose of this extension is 17 to provide an extensible framework by which SIP nodes can request 18 notification from remote nodes indicating that certain events have 19 occurred. 21 Note that the event notification mechanisms defined herein are NOT 22 intended to be a general-purpose infrastructure for all classes of 23 event subscription and notification. 25 This document represents a backwards-compatible improvement on the 26 original mechanism described by RFC 3265, taking into account several 27 years of implementation experience. Accordingly, this document 28 obsoletes RFC 3265. This document also updates RFC 4660 slightly to 29 accommodate some small changes to the mechanism that were discussed 30 in that document. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 1, 2012. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1.1. Overview of Operation . . . . . . . . . . . . . . . . . . 5 68 1.2. Documentation Conventions . . . . . . . . . . . . . . . . 6 69 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3. SIP Methods for Event Notification . . . . . . . . . . . . . . 7 71 3.1. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.1.1. Subscription Duration . . . . . . . . . . . . . . . . 7 73 3.1.2. Identification of Subscribed Events and Event 74 Classes . . . . . . . . . . . . . . . . . . . . . . . 8 75 3.1.3. Additional SUBSCRIBE Header Field Values . . . . . . . 9 76 3.2. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 3.2.1. Identification of Reported Events, Event Classes, 78 and Current State . . . . . . . . . . . . . . . . . . 9 79 4. Node Behavior . . . . . . . . . . . . . . . . . . . . . . . . 10 80 4.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 10 81 4.1.1. Detecting Support for SIP Events . . . . . . . . . . . 10 82 4.1.2. Creating and Maintaining Subscriptions . . . . . . . . 10 83 4.1.3. Receiving and Processing State Information . . . . . . 14 84 4.1.4. Forking of SUBSCRIBE Requests . . . . . . . . . . . . 16 85 4.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 17 86 4.2.1. Subscription Establishment and Maintenance . . . . . . 17 87 4.2.2. Sending State Information to Subscribers . . . . . . . 20 88 4.2.3. PINT Compatibility . . . . . . . . . . . . . . . . . . 23 89 4.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 23 90 4.4. Common Behavior . . . . . . . . . . . . . . . . . . . . . 23 91 4.4.1. Dialog Creation and Termination . . . . . . . . . . . 24 92 4.4.2. Notifier Migration . . . . . . . . . . . . . . . . . . 24 93 4.4.3. Polling Resource State . . . . . . . . . . . . . . . . 25 94 4.4.4. Allow-Events header field usage . . . . . . . . . . . 26 95 4.5. Targeting Subscriptions at Devices . . . . . . . . . . . . 26 96 4.5.1. Using GRUUs to Route to Devices . . . . . . . . . . . 27 97 4.5.2. Sharing Dialogs . . . . . . . . . . . . . . . . . . . 27 98 4.6. CANCEL Requests for SUBSCRIBE and NOTIFY Transactions . . 29 99 5. Event Packages . . . . . . . . . . . . . . . . . . . . . . . . 29 100 5.1. Appropriateness of Usage . . . . . . . . . . . . . . . . . 30 101 5.2. Event Template-packages . . . . . . . . . . . . . . . . . 30 102 5.3. Amount of State to be Conveyed . . . . . . . . . . . . . . 31 103 5.3.1. Complete State Information . . . . . . . . . . . . . . 31 104 5.3.2. State Deltas . . . . . . . . . . . . . . . . . . . . . 32 105 5.4. Event Package Responsibilities . . . . . . . . . . . . . . 32 106 5.4.1. Event Package Name . . . . . . . . . . . . . . . . . . 33 107 5.4.2. Event Package Parameters . . . . . . . . . . . . . . . 33 108 5.4.3. SUBSCRIBE Request Bodies . . . . . . . . . . . . . . . 33 109 5.4.4. Subscription Duration . . . . . . . . . . . . . . . . 33 110 5.4.5. NOTIFY Request Bodies . . . . . . . . . . . . . . . . 34 111 5.4.6. Notifier processing of SUBSCRIBE requests . . . . . . 34 112 5.4.7. Notifier generation of NOTIFY requests . . . . . . . . 34 113 5.4.8. Subscriber processing of NOTIFY requests . . . . . . . 34 114 5.4.9. Handling of forked requests . . . . . . . . . . . . . 34 115 5.4.10. Rate of notifications . . . . . . . . . . . . . . . . 35 116 5.4.11. State Aggregation . . . . . . . . . . . . . . . . . . 35 117 5.4.12. Examples . . . . . . . . . . . . . . . . . . . . . . . 36 118 5.4.13. Use of URIs to Retrieve State . . . . . . . . . . . . 36 119 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 120 6.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 36 121 6.2. Notifier Privacy Mechanism . . . . . . . . . . . . . . . . 36 122 6.3. Denial-of-Service attacks . . . . . . . . . . . . . . . . 37 123 6.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 37 124 6.5. Man-in-the middle attacks . . . . . . . . . . . . . . . . 37 125 6.6. Confidentiality . . . . . . . . . . . . . . . . . . . . . 38 126 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 127 7.1. Event Packages . . . . . . . . . . . . . . . . . . . . . . 38 128 7.1.1. Registration Information . . . . . . . . . . . . . . . 39 129 7.1.2. Registration Template . . . . . . . . . . . . . . . . 40 130 7.2. Reason Codes . . . . . . . . . . . . . . . . . . . . . . . 40 131 7.3. Header Field Names . . . . . . . . . . . . . . . . . . . . 41 132 7.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . 41 133 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 134 8.1. New Methods . . . . . . . . . . . . . . . . . . . . . . . 42 135 8.1.1. SUBSCRIBE method . . . . . . . . . . . . . . . . . . . 42 136 8.1.2. NOTIFY method . . . . . . . . . . . . . . . . . . . . 42 137 8.2. New Header Fields . . . . . . . . . . . . . . . . . . . . 42 138 8.2.1. "Event" Header Field . . . . . . . . . . . . . . . . . 42 139 8.2.2. "Allow-Events" Header Field . . . . . . . . . . . . . 43 140 8.2.3. "Subscription-State" Header Field . . . . . . . . . . 43 141 8.3. New Response Codes . . . . . . . . . . . . . . . . . . . . 43 142 8.3.1. "202 Accepted" Response Code . . . . . . . . . . . . . 43 143 8.3.2. "489 Bad Event" Response Code . . . . . . . . . . . . 44 145 8.4. Augmented BNF Definitions . . . . . . . . . . . . . . . . 44 146 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 147 9.1. Normative References . . . . . . . . . . . . . . . . . . . 45 148 9.2. Informative References . . . . . . . . . . . . . . . . . . 46 149 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 47 150 Appendix B. Changes from RFC 3265 . . . . . . . . . . . . . . . . 48 151 B.1. Bug 666: Clarify use of expires=xxx with terminated . . . 48 152 B.2. Bug 667: Reason code for unsub/poll not clearly 153 spelled out . . . . . . . . . . . . . . . . . . . . . . . 48 154 B.3. Bug 669: Clarify: SUBSCRIBE for a duration might be 155 answered with a NOTIFY/expires=0 . . . . . . . . . . . . . 48 156 B.4. Bug 670: Dialog State Machine needs clarification . . . . 48 157 B.5. Bug 671: Clarify timeout-based removal of subscriptions . 48 158 B.6. Bug 672: Mandate expires= in NOTIFY . . . . . . . . . . . 48 159 B.7. Bug 673: INVITE 481 response effect clarification . . . . 49 160 B.8. Bug 677: SUBSCRIBE response matching text in error . . . . 49 161 B.9. Bug 695: Document is not explicit about response to 162 NOTIFY at subscription termination . . . . . . . . . . . . 49 163 B.10. Bug 696: Subscription state machine needs clarification . 49 164 B.11. Bug 697: Unsubscription behavior could be clarified . . . 49 165 B.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh 166 requests . . . . . . . . . . . . . . . . . . . . . . . . . 49 167 B.13. Bug 722: Inconsistent 423 reason phrase text . . . . . . . 49 168 B.14. Bug 741: guidance needed on when to not include 169 Allow-Events . . . . . . . . . . . . . . . . . . . . . . . 49 170 B.15. Bug 744: 5xx to NOTIFY terminates a subscription, but 171 should not . . . . . . . . . . . . . . . . . . . . . . . . 50 172 B.16. Bug 752: Detection of forked requests is incorrect . . . . 50 173 B.17. Bug 773: Reason code needs IANA registry . . . . . . . . . 50 174 B.18. Bug 774: Need new reason for terminating subscriptions 175 to resources that never change . . . . . . . . . . . . . . 50 176 B.19. Clarify handling of Route/Record-Route in NOTIFY . . . . . 50 177 B.20. Eliminate implicit subscriptions . . . . . . . . . . . . . 50 178 B.21. Deprecate dialog re-use . . . . . . . . . . . . . . . . . 50 179 B.22. Rationalize dialog creation . . . . . . . . . . . . . . . 50 180 B.23. Refactor behavior sections . . . . . . . . . . . . . . . . 51 181 B.24. Clarify sections that need to be present in event 182 packages . . . . . . . . . . . . . . . . . . . . . . . . . 51 183 B.25. Make CANCEL handling more explicit . . . . . . . . . . . . 51 184 B.26. Remove State Agent Terminology . . . . . . . . . . . . . . 51 185 B.27. Miscellanous Changes . . . . . . . . . . . . . . . . . . . 52 186 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53 188 1. Introduction 190 The ability to request asynchronous notification of events proves 191 useful in many types of SIP services for which cooperation between 192 end-nodes is required. Examples of such services include automatic 193 callback services (based on terminal state events), buddy lists 194 (based on user presence events), message waiting indications (based 195 on mailbox state change events), and PSTN and Internet 196 Internetworking (PINT) [RFC2848] status (based on call state events). 198 The methods described in this document provide a framework by which 199 notification of these events can be ordered. 201 The event notification mechanisms defined herein are NOT intended to 202 be a general-purpose infrastructure for all classes of event 203 subscription and notification. Meeting requirements for the general 204 problem set of subscription and notification is far too complex for a 205 single protocol. Our goal is to provide a SIP-specific framework for 206 event notification which is not so complex as to be unusable for 207 simple features, but which is still flexible enough to provide 208 powerful services. Note, however, that event packages based on this 209 framework may define arbitrarily elaborate rules which govern the 210 subscription and notification for the events or classes of events 211 they describe. 213 This document does not describe an extension which may be used 214 directly; it must be extended by other documents (herein referred to 215 as "event packages"). In object-oriented design terminology, it may 216 be thought of as an abstract base class which must be derived into an 217 instantiatable class by further extensions. Guidelines for creating 218 these extensions are described in Section 5. 220 1.1. Overview of Operation 222 The general concept is that entities in the network can subscribe to 223 resource or call state for various resources or calls in the network, 224 and those entities (or entities acting on their behalf) can send 225 notifications when those states change. 227 A typical flow of messages would be: 229 Subscriber Notifier 230 |-----SUBSCRIBE---->| Request state subscription 231 |<-------200--------| Acknowledge subscription 232 |<------NOTIFY----- | Return current state information 233 |--------200------->| 234 |<------NOTIFY----- | Return current state information 235 |--------200------->| 237 Subscriptions are expired and must be refreshed by subsequent 238 SUBSCRIBE requests. 240 1.2. Documentation Conventions 242 There are several paragraphs throughout this document which provide 243 motivational or clarifying text. Such passages are non-normative, 244 and are provided only to assist with reader comprehension. These 245 passages are set off from the remainder of the text by being indented 246 thus: 248 This is an example of non-normative explanatory text. It does not 249 form part of the specification, and is used only for 250 clarification. 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 254 document are to be interpreted as described in [RFC2119]. 256 In particular, implementors need to take careful note of the meaning 257 of "SHOULD" defined in RFC 2119. To rephrase: violation of SHOULD- 258 strength requirements requires careful analysis and clearly 259 enumerable reasons. It is a protocol violation to fail to comply 260 with "SHOULD"-strength requirements whimsically or for ease of 261 implementation. 263 The use of quotation marks next to periods and commas follows the 264 convention used by the American Mathematical Society; although 265 contrary to traditional American English convention, this usage lends 266 clarity to certain passages. 268 2. Definitions 270 Event Package: An event package is an additional specification which 271 defines a set of state information to be reported by a notifier to 272 a subscriber. Event packages also define further syntax and 273 semantics based on the framework defined by this document required 274 to convey such state information. 276 Event Template-Package: An event template-package is a special kind 277 of event package which defines a set of states which may be 278 applied to all possible event packages, including itself. 280 Notification: Notification is the act of a notifier sending a NOTIFY 281 request to a subscriber to inform the subscriber of the state of a 282 resource. 284 Notifier: A notifier is a user agent which generates NOTIFY requests 285 for the purpose of notifying subscribers of the state of a 286 resource. Notifiers typically also accept SUBSCRIBE requests to 287 create subscriptions. 289 Subscriber: A subscriber is a user agent which receives NOTIFY 290 requests from notifiers; these NOTIFY requests contain information 291 about the state of a resource in which the subscriber is 292 interested. Subscribers typically also generate SUBSCRIBE 293 requests and send them to notifiers to create subscriptions. 295 Subscription: A subscription is a set of application state 296 associated with a dialog. This application state includes a 297 pointer to the associated dialog, the event package name, and 298 possibly an identification token. Event packages will define 299 additional subscription state information. By definition, 300 subscriptions exist in both a subscriber and a notifier. 302 Subscription Migration: Subscription migration is the act of moving 303 a subscription from one notifier to another notifier. 305 3. SIP Methods for Event Notification 307 3.1. SUBSCRIBE 309 The SUBSCRIBE method is used to request current state and state 310 updates from a remote node. SUBSCRIBE requests are target refresh 311 requests, as that term is defined in [RFC3261]. 313 3.1.1. Subscription Duration 315 SUBSCRIBE requests SHOULD contain an "Expires" header field (defined 316 in [RFC3261]). This expires value indicates the duration of the 317 subscription. In order to keep subscriptions effective beyond the 318 duration communicated in the "Expires" header field, subscribers need 319 to refresh subscriptions on a periodic basis using a new SUBSCRIBE 320 request on the same dialog as defined in [RFC3261]. 322 If no "Expires" header field is present in a SUBSCRIBE request, the 323 implied default MUST be defined by the event package being used. 325 200-class responses to SUBSCRIBE requests also MUST contain an 326 "Expires" header field. The period of time in the response MAY be 327 shorter but MUST NOT be longer than specified in the request. The 328 notifier is explicitly allowed to shorten the duration to zero. The 329 period of time in the response is the one which defines the duration 330 of the subscription. 332 An "expires" parameter on the "Contact" header field has no semantics 333 for the SUBSCRIBE method and is explicitly not equivalent to an 334 "Expires" header field in a SUBSCRIBE request or response. 336 A natural consequence of this scheme is that a SUBSCRIBE request with 337 an "Expires" of 0 constitutes a request to unsubscribe from the 338 matching subscription. 340 In addition to being a request to unsubscribe, a SUBSCRIBE request 341 with "Expires" of 0 also causes a fetch of state; see 342 Section 4.4.3. 344 Notifiers may also wish to cancel subscriptions to events; this is 345 useful, for example, when the resource to which a subscription refers 346 is no longer available. Further details on this mechanism are 347 discussed in Section 4.2.2. 349 3.1.2. Identification of Subscribed Events and Event Classes 351 Identification of events is provided by three pieces of information: 352 Request URI, Event Type, and (optionally) message body. 354 The Request URI of a SUBSCRIBE request, most importantly, contains 355 enough information to route the request to the appropriate entity per 356 the request routing procedures outlined in [RFC3261]. It also 357 contains enough information to identify the resource for which event 358 notification is desired, but not necessarily enough information to 359 uniquely identify the nature of the event (e.g., 360 "sip:adam@example.com" would be an appropriate URI to subscribe to 361 for my presence state; it would also be an appropriate URI to 362 subscribe to the state of my voice mailbox). 364 Subscribers MUST include exactly one "Event" header field in 365 SUBSCRIBE requests, indicating to which event or class of events they 366 are subscribing. The "Event" header field will contain a token which 367 indicates the type of state for which a subscription is being 368 requested. This token will be registered with the IANA and will 369 correspond to an event package which further describes the semantics 370 of the event or event class. 372 If the event package to which the event token corresponds defines 373 behavior associated with the body of its SUBSCRIBE requests, those 374 semantics apply. 376 Event packages may also define parameters for the Event header field; 377 if they do so, they must define the semantics for such parameters. 379 3.1.3. Additional SUBSCRIBE Header Field Values 381 Because SUBSCRIBE requests create a dialog usage as defined in 382 [RFC3261], they MAY contain an "Accept" header field. This header 383 field, if present, indicates the body formats allowed in subsequent 384 NOTIFY requests. Event packages MUST define the behavior for 385 SUBSCRIBE requests without "Accept" header fields; usually, this will 386 connote a single, default body type. 388 Header values not described in this document are to be interpreted as 389 described in [RFC3261]. 391 3.2. NOTIFY 393 NOTIFY requests are sent to inform subscribers of changes in state to 394 which the subscriber has a subscription. Subscriptions are created 395 using the SUBSCRIBE method. In legacy implementations, it is 396 possible that other means of subscription creation have been used. 397 However, this specification does not allow the creation of 398 subscriptions except through SUBSCRIBE requests and (for backwards- 399 compatibility) REFER requests [RFC3515]. 401 NOTIFY is a target refresh request, as that term is defined in 402 [RFC3261]. 404 A NOTIFY request does not terminate its corresponding subscription; 405 in other words, a single SUBSCRIBE request may trigger several NOTIFY 406 requests. 408 3.2.1. Identification of Reported Events, Event Classes, and Current 409 State 411 Identification of events being reported in a notification is very 412 similar to that described for subscription to events (see 413 Section 3.1.2). 415 As in SUBSCRIBE requests, NOTIFY request "Event" header fields MUST 416 contain a single event package name for which a notification is being 417 generated. The package name in the "Event" header field MUST match 418 the "Event" header field in the corresponding SUBSCRIBE request. 420 Event packages may define semantics associated with the body of their 421 NOTIFY requests; if they do so, those semantics apply. NOTIFY 422 request bodies are expected to provide additional details about the 423 nature of the event which has occurred and the resultant resource 424 state. 426 When present, the body of the NOTIFY request MUST be formatted into 427 one of the body formats specified in the "Accept" header field of the 428 corresponding SUBSCRIBE request (or the default type according to the 429 event package description, if no Accept header field was specified). 430 This body will contain either the state of the subscribed resource or 431 a pointer to such state in the form of a URI (see Section 5.4.13). 433 4. Node Behavior 435 4.1. Subscriber Behavior 437 4.1.1. Detecting Support for SIP Events 439 The extension described in this document does not make use of the 440 "Require" or "Proxy-Require" header fields; similarly, there is no 441 token defined for "Supported" header fields. Potential subscribers 442 may probe for the support of SIP Events using the OPTIONS request 443 defined in [RFC3261]. 445 The presence of "SUBSCRIBE" in the "Allow" header field of any 446 request or response indicates support for SIP Events; further, in the 447 absence of an "Allow" header field, the simple presence of an "Allow- 448 Events" header field is sufficient to indicate that the node that 449 sent the message is capable of acting as a notifier (see 450 Section 4.4.4). 452 The "methods" parameter for Contact may also be used to 453 specifically announce support for SUBSCRIBE and NOTIFY requests 454 when registering. (See [RFC3840] for details on the "methods" 455 parameter). 457 4.1.2. Creating and Maintaining Subscriptions 459 From the subscriber's perspective, a subscription proceeds according 460 to the following state diagram. Events which result in a transition 461 back to the same state are not represented in this diagram. 463 +-------------+ 464 | init |<-----------------------+ 465 +-------------+ | 466 | Retry-after 467 Send SUBSCRIBE expires 468 | | 469 V Timer N Fires; | 470 +-------------+ SUBSCRIBE failure | 471 +------------| notify_wait |-- response; --------+ | 472 | +-------------+ or NOTIFY, | | 473 | | state=terminated | | 474 | | | | 475 ++========|===================|============================|==|====++ 476 || | | V | || 477 || Receive NOTIFY, Receive NOTIFY, +-------------+ || 478 || state=active state=pending | terminated | || 479 || | | +-------------+ || 480 || | | Re-subscription A A || 481 || | V times out; | | || 482 || | +-------------+ Receive NOTIFY, | | || 483 || | | pending |-- state=terminated; --+ | || 484 || | +-------------+ or 481 response | || 485 || | | to SUBSCRIBE | || 486 || | Receive NOTIFY, refresh | || 487 || | state=active | || 488 || | | Re-subscription | || 489 || | V times out; | || 490 || | +-------------+ Receive NOTIFY, | || 491 || +----------->| active |-- state=terminated; -----+ || 492 || +-------------+ or 481 response || 493 || to SUBSCRIBE || 494 || Subscription refresh || 495 ++=================================================================++ 497 In the state diagram, "Re-subscription times out" means that an 498 attempt to refresh or update the subscription using a new SUBSCRIBE 499 request does not result in a NOTIFY request before the corresponding 500 Timer N expires. 502 Any transition from "notify_wait" into a "pending" or "active" state 503 results in a new subscription. Note that multiple subscriptions can 504 be generated as the result of a single SUBSCRIBE request (see 505 Section 4.4.1). Each of these new subscriptions exists in its own 506 independent state machine, and runs its own set of timers. 508 4.1.2.1. Requesting a Subscription 510 SUBSCRIBE is a dialog-creating method, as described in [RFC3261]. 512 When a subscriber wishes to subscribe to a particular state for a 513 resource, it forms a SUBSCRIBE request. If the initial SUBSCRIBE 514 request represents a request outside of a dialog (as it typically 515 will), its construction follows the procedures outlined in [RFC3261] 516 for UAC request generation outside of a dialog. 518 This SUBSCRIBE request will be confirmed with a final response. 200- 519 class responses indicate that the subscription has been accepted, and 520 that a NOTIFY request will be sent immediately. 522 The "Expires" header field in a 200-class response to SUBSCRIBE 523 request indicates the actual duration for which the subscription will 524 remain active (unless refreshed). The received value might be 525 smaller than the value indicated in the SUBSCRIBE request, but cannot 526 be larger; see Section 4.2.1 for details. 528 Non-200 class final responses indicate that no subscription or new 529 dialog usage has been created, and no subsequent NOTIFY request will 530 be sent. All non-200 class responses (with the exception of "489", 531 described herein) have the same meanings and handling as described in 532 [RFC3261]. For the sake of clarity: if a SUBSCRIBE request contains 533 an "Accept" header field, but that field does not indicate a media 534 type that the notifier is capable of generating in its NOTIFY 535 requests, then the proper error response is 406 (Not Acceptable). 537 4.1.2.2. Refreshing of Subscriptions 539 At any time before a subscription expires, the subscriber may refresh 540 the timer on such a subscription by sending another SUBSCRIBE request 541 on the same dialog as the existing subscription. The handling for 542 such a request is the same as for the initial creation of a 543 subscription except as described below. 545 If a SUBSCRIBE request to refresh a subscription receives a 404, 405, 546 410, 416, 480-485, 489, 501, or 604 response, the subscriber MUST 547 consider the subscription terminated. (See [RFC5057] for further 548 details and notes about the effect of error codes on dialogs and 549 usages within dialog, such as subscriptions). If the subscriber 550 wishes to re-subscribe to the state, he does so by composing an 551 unrelated initial SUBSCRIBE request with a freshly-generated Call-ID 552 and a new, unique "From" tag (see Section 4.1.2.1.) 554 If a SUBSCRIBE request to refresh a subscription fails with any error 555 code other than those listed above, the original subscription is 556 still considered valid for the duration of the most recently known 557 "Expires" value as negotiated by the most recent successful SUBSCRIBE 558 transaction, or as communicated by a NOTIFY request in its 559 "Subscription-State" header field "expires" parameter. 561 Note that many such errors indicate that there may be a problem 562 with the network or the notifier such that no further NOTIFY 563 requests will be received. 565 When refreshing a subscription, a subscriber starts Timer N, set to 566 64*T1, when it sends the SUBSCRIBE request. If this Timer N expires 567 prior to the receipt of a NOTIFY request, the subscriber considers 568 the subscription terminated. If the subscriber receives a success 569 response to the SUBSCRIBE request that indicates that no NOTIFY 570 request will be generated -- such as the 204 response defined for use 571 with the optional extension described in [RFC5839] -- then it MUST 572 cancel Timer N. 574 4.1.2.3. Unsubscribing 576 Unsubscribing is handled in the same way as refreshing of a 577 subscription, with the "Expires" header field set to "0". Note that 578 a successful unsubscription will also trigger a final NOTIFY request. 580 The final NOTIFY request may or may not contain information about the 581 state of the resource; subscribers need to be prepared to receive 582 final NOTIFY requests both with and without state. 584 4.1.2.4. Confirmation of Subscription Creation 586 The subscriber can expect to receive a NOTIFY request from each node 587 which has processed a successful subscription or subscription 588 refresh. To ensure that subscribers do not wait indefinitely for a 589 subscription to be established, a subscriber starts a Timer N, set to 590 64*T1, when it sends a SUBSCRIBE request. If this Timer N expires 591 prior to the receipt of a NOTIFY request, the subscriber considers 592 the subscription failed, and cleans up any state associated with the 593 subscription attempt. 595 Until Timer N expires, several NOTIFY requests may arrive from 596 different destinations (see Section 4.4.1). Each of these requests 597 establish a new dialog usage and a new subscription. After the 598 expiration of Timer N, the subscriber SHOULD reject any such NOTIFY 599 requests that would otherwise establish a new dialog usage with a 600 "481" response code. 602 Until the first NOTIFY request arrives, the subscriber should 603 consider the state of the subscribed resource to be in a neutral 604 state. Event package specifications MUST define this "neutral state" 605 in such a way that makes sense for their application (see 606 Section 5.4.7). 608 Due to the potential for out-of-order messages, packet loss, and 609 forking, the subscriber MUST be prepared to receive NOTIFY requests 610 before the SUBSCRIBE transaction has completed. 612 Except as noted above, processing of this NOTIFY request is the same 613 as in Section 4.1.3. 615 4.1.3. Receiving and Processing State Information 617 Subscribers receive information about the state of a resource to 618 which they have subscribed in the form of NOTIFY requests. 620 Upon receiving a NOTIFY request, the subscriber should check that it 621 matches at least one of its outstanding subscriptions; if not, it 622 MUST return a "481 Subscription does not exist" response unless 623 another 400- or 500-class response is more appropriate. The rules 624 for matching NOTIFY requests with subscriptions that create a new 625 dialog usage are described in Section 4.4.1. Notifications for 626 subscriptions which were created inside an existing dialog match if 627 they are in the same dialog and the "Event" header fields match (as 628 described in Section 8.2.1). 630 If, for some reason, the event package designated in the "Event" 631 header field of the NOTIFY request is not supported, the subscriber 632 will respond with a "489 Bad Event" response. 634 To prevent spoofing of events, NOTIFY requests SHOULD be 635 authenticated, using any defined SIP authentication mechanism, such 636 as those described in sections 22.2 and 23 of [RFC3261]. 638 NOTIFY requests MUST contain "Subscription-State" header fields which 639 indicate the status of the subscription. 641 If the "Subscription-State" header field value is "active", it means 642 that the subscription has been accepted and (in general) has been 643 authorized. If the header field also contains an "expires" 644 parameter, the subscriber SHOULD take it as the authoritative 645 subscription duration and adjust accordingly. The "retry-after" and 646 "reason" parameters have no semantics for "active". 648 If the "Subscription-State" value is "pending", the subscription has 649 been received by the notifier, but there is insufficient policy 650 information to grant or deny the subscription yet. If the header 651 field also contains an "expires" parameter, the subscriber SHOULD 652 take it as the authoritative subscription duration and adjust 653 accordingly. No further action is necessary on the part of the 654 subscriber. The "retry-after" and "reason" parameters have no 655 semantics for "pending". 657 If the "Subscription-State" value is "terminated", the subscriber 658 MUST consider the subscription terminated. The "expires" parameter 659 has no semantics for "terminated" -- notifiers SHOULD NOT include an 660 "expires" parameter on a "Subscription-State" header field with a 661 value of "terminated," and subscribers MUST ignore any such 662 parameter, if present. If a reason code is present, the client 663 should behave as described below. If no reason code or an unknown 664 reason code is present, the client MAY attempt to re-subscribe at any 665 time (unless a "retry-after" parameter is present, in which case the 666 client SHOULD NOT attempt re-subscription until after the number of 667 seconds specified by the "retry-after" parameter). The reason codes 668 defined by this document are: 670 deactivated: The subscription has been terminated, but the 671 subscriber SHOULD retry immediately with a new subscription. One 672 primary use of such a status code is to allow migration of 673 subscriptions between nodes. The "retry-after" parameter has no 674 semantics for "deactivated". 676 probation: The subscription has been terminated, but the client 677 SHOULD retry at some later time (as long as the resource's state 678 is still relevant to the client at that time). If a "retry-after" 679 parameter is also present, the client SHOULD wait at least the 680 number of seconds specified by that parameter before attempting to 681 re-subscribe. 683 rejected: The subscription has been terminated due to change in 684 authorization policy. Clients SHOULD NOT attempt to re-subscribe. 685 The "retry-after" parameter has no semantics for "rejected". 687 timeout: The subscription has been terminated because it was not 688 refreshed before it expired. Clients MAY re-subscribe 689 immediately. The "retry-after" parameter has no semantics for 690 "timeout". This reason code is also associated with polling of 691 resource state, as detailed in Section 4.4.3 693 giveup: The subscription has been terminated because the notifier 694 could not obtain authorization in a timely fashion. If a "retry- 695 after" parameter is also present, the client SHOULD wait at least 696 the number of seconds specified by that parameter before 697 attempting to re-subscribe; otherwise, the client MAY retry 698 immediately, but will likely get put back into pending state. 700 noresource: The subscription has been terminated because the 701 resource state which was being monitored no longer exists. 702 Clients SHOULD NOT attempt to re-subscribe. The "retry-after" 703 parameter has no semantics for "noresource". 705 invariant: The subscription has been terminated because the resource 706 state is guaranteed not to change for the foreseeable future. 707 This may be the case, for example, when subscribing to the 708 location information of a fixed-location land-line telephone. 709 When using this reason code, notifiers are advised to include a 710 "retry-after" parameter with a large value (for example, 31536000 711 -- or one year) to prevent older, RFC 3265-compliant clients from 712 periodically resubscribing. Clients SHOULD NOT attempt to 713 resubscribe after receiving a reason code of "invariant," 714 regardless of the presence of or value of a "retry-after" 715 parameter. 717 Other specifications may define new reason codes for use with the 718 "Subscription-State" header field. 720 Once the notification is deemed acceptable to the subscriber, the 721 subscriber SHOULD return a 200 response. In general, it is not 722 expected that NOTIFY responses will contain bodies; however, they 723 MAY, if the NOTIFY request contained an "Accept" header field. 725 Other responses defined in [RFC3261] may also be returned, as 726 appropriate. In no case should a NOTIFY transaction extend for any 727 longer than the time necessary for automated processing. In 728 particular, subscribers MUST NOT wait for a user response before 729 returning a final response to a NOTIFY request. 731 4.1.4. Forking of SUBSCRIBE Requests 733 In accordance with the rules for proxying non-INVITE requests as 734 defined in [RFC3261], successful SUBSCRIBE requests will receive only 735 one 200-class response; however, due to forking, the subscription may 736 have been accepted by multiple nodes. The subscriber MUST therefore 737 be prepared to receive NOTIFY requests with "From:" tags which differ 738 from the "To:" tag received in the SUBSCRIBE 200-class response. 740 If multiple NOTIFY requests are received in different dialogs in 741 response to a single SUBSCRIBE request, each dialog represents a 742 different destination to which the SUBSCRIBE request was forked. 743 Subscriber handling in such situations varies by event package; see 744 Section 5.4.9 for details. 746 4.2. Notifier Behavior 748 4.2.1. Subscription Establishment and Maintenance 750 Notifiers learn about subscription requests by receiving SUBSCRIBE 751 requests from interested parties. Notifiers MUST NOT create 752 subscriptions except upon receipt of a SUBSCRIBE request. However, 753 for historical reasons, the implicit creation of subscriptions as 754 defined in [RFC3515] is still permitted. 756 [RFC3265] allowed the creation of subscriptions using means other 757 than the SUBSCRIBE method. The only standardized use of this 758 mechanism is the REFER method [RFC3515]. Implementation 759 experience with REFER has shown that the implicit creation of a 760 subscription has a number of undesirable effects, such as the 761 inability to signal the success of a REFER request while signaling 762 a problem with the subscription; and difficulty performing one 763 action without the other. Additionally, the proper exchange of 764 dialog identifiers is difficult without dialog re-use (which has 765 its own set of problems; see Section 4.5). 767 4.2.1.1. Initial SUBSCRIBE Transaction Processing 769 In no case should a SUBSCRIBE transaction extend for any longer than 770 the time necessary for automated processing. In particular, 771 notifiers MUST NOT wait for a user response before returning a final 772 response to a SUBSCRIBE request. 774 This requirement is imposed primarily to prevent the non-INVITE 775 transaction timeout timer F (see [RFC3261]) from firing during the 776 SUBSCRIBE transaction, since interaction with a user would often 777 exceed 64*T1 seconds. 779 The notifier SHOULD check that the event package specified in the 780 "Event" header field is understood. If not, the notifier SHOULD 781 return a "489 Bad Event" response to indicate that the specified 782 event/event class is not understood. 784 The notifier SHOULD also perform any necessary authentication and 785 authorization per its local policy. See Section 4.2.1.3. 787 The notifier MAY also check that the duration in the "Expires" header 788 field is not too small. If and only if the expiration interval is 789 greater than zero AND smaller than one hour AND less than a notifier- 790 configured minimum, the notifier MAY return a "423 Interval Too 791 Brief" error which contains a "Min-Expires" header field field. The 792 "Min-Expires" header field is described in [RFC3261]. 794 Once the notifier determines that it has enough information to create 795 the subscription (i.e., it understands the event package, the 796 subscription pertains to a known resource, and there are no other 797 barriers to creating the subscription), it creates the subscription 798 and a dialog usage, and returns a 200 (OK) response. 800 When a subscription is created in the notifier, it stores the event 801 package name as part of the subscription information. 803 The "Expires" values present in SUBSCRIBE 200-class responses behave 804 in the same way as they do in REGISTER responses: the server MAY 805 shorten the interval, but MUST NOT lengthen it. 807 If the duration specified in a SUBSCRIBE request is unacceptably 808 short, the notifier may be able to send a 423 response, as 809 described earlier in this section. 811 200-class responses to SUBSCRIBE requests will not generally contain 812 any useful information beyond subscription duration; their primary 813 purpose is to serve as a reliability mechanism. State information 814 will be communicated via a subsequent NOTIFY request from the 815 notifier. 817 The other response codes defined in [RFC3261] may be used in response 818 to SUBSCRIBE requests, as appropriate. 820 4.2.1.2. Confirmation of Subscription Creation/Refreshing 822 Upon successfully accepting or refreshing a subscription, notifiers 823 MUST send a NOTIFY request immediately to communicate the current 824 resource state to the subscriber. This NOTIFY request is sent on the 825 same dialog as created by the SUBSCRIBE response. If the resource 826 has no meaningful state at the time that the SUBSCRIBE request is 827 processed, this NOTIFY request MAY contain an empty or neutral body. 828 See Section 4.2.2 for further details on NOTIFY request generation. 830 Note that a NOTIFY request is always sent immediately after any 200- 831 class response to a SUBSCRIBE request, regardless of whether the 832 subscription has already been authorized. 834 4.2.1.3. Authentication/Authorization of SUBSCRIBE Requests 836 Privacy concerns may require that notifiers apply policy to determine 837 whether a particular subscriber is authorized to subscribe to a 838 certain set of events. Such policy may be defined by mechanisms such 839 as access control lists or real-time interaction with a user. In 840 general, authorization of subscribers prior to authentication is not 841 particularly useful. 843 SIP authentication mechanisms are discussed in [RFC3261]. Note that, 844 even if the notifier node typically acts as a proxy, authentication 845 for SUBSCRIBE requests will always be performed via a "401" response, 846 not a "407". Notifiers always act as a user agents when accepting 847 subscriptions and sending notifications. 849 Of course, when acting as a proxy, a node will perform normal 850 proxy authentication (using 407). The foregoing explanation is a 851 reminder that notifiers are always UAs, and as such perform UA 852 authentication. 854 If authorization fails based on an access list or some other 855 automated mechanism (i.e., it can be automatically authoritatively 856 determined that the subscriber is not authorized to subscribe), the 857 notifier SHOULD reply to the request with a "403 Forbidden" or "603 858 Decline" response, unless doing so might reveal information that 859 should stay private; see Section 6.2. 861 If the notifier owner is interactively queried to determine whether a 862 subscription is allowed, a 200 (OK) response is returned immediately. 863 Note that a NOTIFY request is still formed and sent under these 864 circumstances, as described in the previous section. 866 If subscription authorization was delayed and the notifier wishes to 867 convey that such authorization has been declined, it may do so by 868 sending a NOTIFY request containing a "Subscription-State" header 869 field with a value of "terminated" and a reason parameter of 870 "rejected". 872 4.2.1.4. Refreshing of Subscriptions 874 When a notifier receives a subscription refresh, assuming that the 875 subscriber is still authorized, the notifier updates the expiration 876 time for subscription. As with the initial subscription, the server 877 MAY shorten the amount of time until expiration, but MUST NOT 878 increase it. The final expiration time is placed in the "Expires" 879 header field in the response. If the duration specified in a 880 SUBSCRIBE request is unacceptably short, the notifier SHOULD respond 881 with a "423 Interval Too Brief" response. 883 If no refresh for a notification address is received before its 884 expiration time, the subscription is removed. When removing a 885 subscription, the notifier SHOULD send a NOTIFY request with a 886 "Subscription-State" value of "terminated" to inform it that the 887 subscription is being removed. If such a request is sent, the 888 "Subscription-State" header field SHOULD contain a "reason=timeout" 889 parameter. 891 Clients can cause a subscription to be terminated immediately by 892 sending a SUBSCRIBE request with an "Expires" header field set to 893 '0'. Notifiers largely treat this the same way as any other 894 subscription expiration: they send a NOTIFY request containing a 895 "Subscription-State" of "terminated", with a reason code of 896 "timeout." For consistency with state polling (see Section 4.4.3) 897 and subscription refreshes, the notifier may choose to include 898 resource state in this final NOTIFY request. However, in some cases, 899 including such state makes no sense. Under such circumstances, the 900 notifier may choose to omit state information from the terminal 901 NOTIFY request. 903 The sending of a NOTIFY request when a subscription expires allows 904 the corresponding dialog usage to be terminated, if appropriate. 906 4.2.2. Sending State Information to Subscribers 908 Notifiers use the NOTIFY method to send information about the state 909 of a resource to subscribers. The notifier's view of a subscription 910 is shown in the following state diagram. Events which result in a 911 transition back to the same state are not represented in this 912 diagram. 914 +-------------+ 915 | init | 916 +-------------+ 917 | 918 Receive SUBSCRIBE, 919 Send NOTIFY 920 | 921 V NOTIFY failure, 922 +-------------+ subscription expires, 923 +------------| resp_wait |-- or terminated ----+ 924 | +-------------+ per local policy | 925 | | | 926 | | | 927 | | V 928 Policy grants Policy needed +-------------+ 929 permission | | terminated | 930 | | +-------------+ 931 | | A A 932 | V NOTIFY failure, | | 933 | +-------------+ subscription expires,| | 934 | | pending |-- or terminated -------+ | 935 | +-------------+ per local policy | 936 | | | 937 | Policy changed to | 938 | grant permission | 939 | | | 940 | V NOTIFY failure, | 941 | +-------------+ subscription expires, | 942 +----------->| active |-- or terminated ---------+ 943 +-------------+ per local policy 945 When a SUBSCRIBE request is answered with a 200-class response, the 946 notifier MUST immediately construct and send a NOTIFY request to the 947 subscriber. When a change in the subscribed state occurs, the 948 notifier SHOULD immediately construct and send a NOTIFY request, 949 unless the state transition is caused by a NOTIFY transaction 950 failure. The sending of this NOTIFY message is also subject to 951 authorization, local policy, and throttling considerations. 953 If the NOTIFY request fails due to expiration of SIP Timer F 954 (transaction timeout), the notifier SHOULD remove the subscription. 956 This behavior prevents unnecessary transmission of state 957 information for subscribers who have crashed or disappeared from 958 the network. Because such transmissions will be sent multiple 959 times, per the retransmission algorithm defined in [RFC3261] 960 (instead of the typical single transmission for functioning 961 clients), continuing to service them when no client is available 962 to acknowledge them could place undue strain on a network. Upon 963 client restart or reestablishment of a network connection, it is 964 expected that clients will send SUBSCRIBE requests to refresh 965 potentially stale state information; such requests will re-install 966 subscriptions in all relevant nodes. 968 If the NOTIFY transaction fails due to the receipt of a 404, 405, 969 410, 416, 480-485, 489, 501, or 604 response to the NOTIFY request, 970 the notifier MUST remove the corresponding subscription. See 971 [RFC5057] for further details and notes about the effect of error 972 codes on dialogs and usages within dialog (such as subscriptions). 974 A notify error response would generally indicate that something 975 has gone wrong with the subscriber or with some proxy on the way 976 to the subscriber. If the subscriber is in error, it makes the 977 most sense to allow the subscriber to rectify the situation (by 978 re-subscribing) once the error condition has been handled. If a 979 proxy is in error, the periodic sending of SUBSCRIBE requests to 980 refresh the expiration timer will re-install subscription state 981 once the network problem has been resolved. 983 NOTIFY requests MUST contain a "Subscription-State" header field with 984 a value of "active", "pending", or "terminated". The "active" value 985 indicates that the subscription has been accepted and has been 986 authorized (in most cases; see Section 6.2). The "pending" value 987 indicates that the subscription has been received, but that policy 988 information is insufficient to accept or deny the subscription at 989 this time. The "terminated" value indicates that the subscription is 990 not active. 992 If the value of the "Subscription-State" header field is "active" or 993 "pending", the notifier MUST also include in the "Subscription-State" 994 header field an "expires" parameter which indicates the time 995 remaining on the subscription. The notifier MAY use this mechanism 996 to shorten a subscription; however, this mechanism MUST NOT be used 997 to lengthen a subscription. 999 Including expiration information for active and pending 1000 subscriptions is necessary in case the SUBSCRIBE request forks, 1001 since the response to a forked SUBSCRIBE request may not be 1002 received by the subscriber. [RFC3265] allowed the notifier some 1003 discretion in the inclusion of this parameter, so subscriber 1004 implementations are warned to handle the lack of an "expires" 1005 parameter gracefully. Note well that this "expires" value is a 1006 parameter on the "Subscription-State" header field, NOT an 1007 "Expires" header field. 1009 The period of time for a subscription can be shortened to zero by 1010 the notifier. In other words, it is perfectly valid for a 1011 SUBSCRIBE request with a non-zero expires to be answered with a 1012 NOTIFY request that contains "Subscription-Status: 1013 terminated;reason=expired". This merely means that the notifier 1014 has shortened the subscription timeout to zero, and the 1015 subscription has expired instantaneously. The body may contain 1016 valid state, or it may contain a neutral state (see 1017 Section 5.4.7). 1019 If the value of the "Subscription-State" header field is 1020 "terminated", the notifier SHOULD also include a "reason" parameter. 1021 The notifier MAY also include a "retry-after" parameter, where 1022 appropriate. For details on the value and semantics of the "reason" 1023 and "retry-after" parameters, see Section 4.1.3. 1025 4.2.3. PINT Compatibility 1027 The "Event" header field is considered mandatory for the purposes of 1028 this document. However, to maintain compatibility with PINT (see 1029 [RFC2848]), notifiers MAY interpret a SUBSCRIBE request with no 1030 "Event" header field as requesting a subscription to PINT events. If 1031 a notifier does not support PINT, it SHOULD return "489 Bad Event" to 1032 any SUBSCRIBE requests without an "Event" header field. 1034 4.3. Proxy Behavior 1036 Proxies need no additional behavior beyond that described in 1037 [RFC3261] to support SUBSCRIBE and NOTIFY transactions. If a proxy 1038 wishes to see all of the SUBSCRIBE and NOTIFY requests for a given 1039 dialog, it MUST add a Record-Route header field to the initial 1040 SUBSCRIBE request and all NOTIFY requests. It MAY choose to include 1041 Record-Route in subsequent SUBSCRIBE requests; however, these 1042 requests cannot cause the dialog's route set to be modified. 1044 Proxies that did not add a Record-Route header field to the initial 1045 SUBSCRIBE request MUST NOT add a Record-Route header field to any of 1046 the associated NOTIFY requests. 1048 Note that subscribers and notifiers may elect to use S/MIME 1049 encryption of SUBSCRIBE and NOTIFY requests; consequently, proxies 1050 cannot rely on being able to access any information that is not 1051 explicitly required to be proxy-readable by [RFC3261]. 1053 4.4. Common Behavior 1054 4.4.1. Dialog Creation and Termination 1056 Dialogs usages are created upon completion of a NOTIFY transaction 1057 for a new subscription, unless the NOTIFY request contains a 1058 "Subscription-State" of "terminated." 1060 Because the dialog usage is established by the NOTIFY request, the 1061 route set at the subscriber is taken from the NOTIFY request itself, 1062 as opposed to the route set present in the 200-class response to the 1063 SUBSCRIBE request. 1065 NOTIFY requests are matched to such SUBSCRIBE requests if they 1066 contain the same "Call-ID", a "To" header field "tag" parameter which 1067 matches the "From" header field "tag" parameter of the SUBSCRIBE 1068 request, and the same "Event" header field. Rules for comparisons of 1069 the "Event" header fields are described in Section 8.2.1. 1071 A subscription is destroyed after a notifier sends a NOTIFY request 1072 with a "Subscription-State" of "terminated," or in certain error 1073 situations described elsewhere in this document. The subscriber will 1074 generally answer such final requests with a "200 OK" response (unless 1075 a condition warranting an alternate response has arisen). Except 1076 when the mechanism described in Section 4.5.2 is used, the 1077 destruction of a subscription results in the termination of its 1078 associated dialog. 1080 A subscriber may send a SUBSCRIBE request with an "Expires" header 1081 field of 0 in order to trigger the sending of such a NOTIFY 1082 request; however, for the purposes of subscription and dialog 1083 lifetime, the subscription is not considered terminated until the 1084 NOTIFY transaction with a "Subscription-State" of "terminated" 1085 completes. 1087 4.4.2. Notifier Migration 1089 It is often useful to allow migration of subscriptions between 1090 notifiers. Such migration may be effected by sending a NOTIFY 1091 request with a "Subscription-State" header field of "terminated", and 1092 a reason parameter of "deactivated". This NOTIFY request is 1093 otherwise normal, and is formed as described in Section 4.2.2. 1095 Upon receipt of this NOTIFY request, the subscriber SHOULD attempt to 1096 re-subscribe (as described in the preceding sections). Note that 1097 this subscription is established on a new dialog, and does not re-use 1098 the route set from the previous subscription dialog. 1100 The actual migration is effected by making a change to the policy 1101 (such as routing decisions) of one or more servers to which the 1102 SUBSCRIBE request will be sent in such a way that a different node 1103 ends up responding to the SUBSCRIBE request. This may be as simple 1104 as a change in the local policy in the notifier from which the 1105 subscription is migrating so that it serves as a proxy or redirect 1106 server instead of a notifier. 1108 Whether, when, and why to perform notifier migrations may be 1109 described in individual event packages; otherwise, such decisions are 1110 a matter of local notifier policy, and are left up to individual 1111 implementations. 1113 4.4.3. Polling Resource State 1115 A natural consequence of the behavior described in the preceding 1116 sections is that an immediate fetch without a persistent subscription 1117 may be effected by sending a SUBSCRIBE with an "Expires" of 0. 1119 Of course, an immediate fetch while a subscription is active may be 1120 effected by sending a SUBSCRIBE request with an "Expires" equal to 1121 the number of seconds remaining in the subscription. 1123 Upon receipt of this SUBSCRIBE request, the notifier (or notifiers, 1124 if the SUBSCRIBE request was forked) will send a NOTIFY request 1125 containing resource state in the same dialog. 1127 Note that the NOTIFY requests triggered by SUBSCRIBE requests with 1128 "Expires" header fields of 0 will contain a "Subscription-State" 1129 value of "terminated", and a "reason" parameter of "timeout". 1131 Polling of event state can cause significant increases in load on the 1132 network and notifiers; as such, it should be used only sparingly. In 1133 particular, polling SHOULD NOT be used in circumstances in which it 1134 will typically result in more network messages than long-running 1135 subscriptions. 1137 When polling is used, subscribers SHOULD attempt to cache 1138 authentication credentials between polls so as to reduce the number 1139 of messages sent. 1141 Due to the requirement on notifiers to send a NOTIFY request 1142 immediately upon receipt of a SUBSCRIBE request, the state 1143 provided by polling is limited to the information that the 1144 notifier has immediate local access to when it receives the 1145 SUBSCRIBE request. If, for example, the notifier generally needs 1146 to retrieve state from another network server, then that state 1147 will be absent from the NOTIFY request that results from polling. 1149 4.4.4. Allow-Events header field usage 1151 The "Allow-Events" header field, if present, MUST include a 1152 comprehensive and inclusive list of tokens which indicates the event 1153 packages for which the User Agent can act as a notifier. In other 1154 words, a user agent sending an "Allow-Events" header field is 1155 advertising that it can process SUBSCRIBE requests and generate 1156 NOTIFY requests for all of the event packages listed in that header 1157 field. 1159 Any user agent that can act as a notifier for one or more event 1160 packages SHOULD include an appropriate "Allow-Events" header field 1161 indicating all supported events in all methods which initiate dialogs 1162 and their responses (such as INVITE) and OPTIONS responses. 1164 This information is very useful, for example, in allowing user 1165 agents to render particular interface elements appropriately 1166 according to whether the events required to implement the features 1167 they represent are supported by the appropriate nodes. 1168 On the other hand, it doesn't necessarily make much sense to 1169 indicate supported events inside a dialog established by a NOTIFY 1170 request if the only event package supported is the one associated 1171 with that subscription. 1173 Note that "Allow-Events" header fields MUST NOT be inserted by 1174 proxies. 1176 The "Allow-Events" header field does not include a list of the event 1177 template packages supported by an implementation. If a subscriber 1178 wishes to determine which event template packages are supported by a 1179 notifier, it can probe for such support by attempting to subscribe to 1180 the event template packages it wishes to use. 1182 For example: to check for support for the templatized package 1183 "presence.winfo", a client may attempt to subscribe to that event 1184 package for a known resource, using an "Expires" header value of 1185 0. if the response is a 489 error code, then the client can deduce 1186 that "presence.winfo" is unsupported. 1188 4.5. Targeting Subscriptions at Devices 1190 [RFC3265] defined a mechanism by which subscriptions could share 1191 dialogs with invite usages and with other subscriptions. The purpose 1192 of this behavior was to allow subscribers to ensure that a 1193 subscription arrived at the same device as an established dialog. 1194 Unfortunately, the re-use of dialogs has proven to be exceedingly 1195 confusing. [RFC5057] attempted to clarify proper behavior in a 1196 variety of circumstances; however, the ensuing rules remain confusing 1197 and prone to implementation error. At the same time, the mechanism 1198 described in [RFC5627] now provides a far more elegant and 1199 unambiguous means to achieve the same goal. 1201 Consequently, the dialog re-use technique described in RFC 3265 is 1202 now deprecated. 1204 This dialog-sharing technique has also historically been used as a 1205 means for targeting an event package at a dialog. This usage can be 1206 seen, for example, in certain applications of the REFER method 1207 [RFC3515]. With the removal of dialog re-use, an alternate (and more 1208 explicit) means of targeting dialogs needs to be used for this type 1209 of correlation. The appropriate means of such targeting is left up 1210 to the actual event packages. Candidates include the "Target-Dialog" 1211 header field [RFC4538], the "Join" header field [RFC3911], and the 1212 "Replaces" header field [RFC3891], depending on the semantics 1213 desired. Alternately, if the semantics of those header fields do not 1214 match the event package's purpose for correlation, event packages can 1215 devise their own means of identifying dialogs. For an example of 1216 this approach, see the Dialog Event Package [RFC4235]. 1218 4.5.1. Using GRUUs to Route to Devices 1220 Notifiers MUST implement the Globally Routable User-Agent URI (GRUU) 1221 extension defined in [RFC5627], and MUST use a GRUU as their local 1222 target. This allows subscribers to explicitly target desired 1223 devices. 1225 If a subscriber wishes to subscribe to a resource on the same device 1226 as an established dialog, it should check whether the remote contact 1227 in that dialog is a GRUU (i.e., whether it contains a "gr" URI 1228 parameter). If so, the subscriber creates a new dialog, using the 1229 GRUU as the request URI for the new SUBSCRIBE request. 1231 Because GRUUs are guaranteed to route to a a specific device, this 1232 ensures that the subscription will be routed to the same place as 1233 the established dialog. 1235 4.5.2. Sharing Dialogs 1237 For compatibility with older clients, subscriber and notifier 1238 implementations may choose to allow dialog sharing. The behavior of 1239 multiple usages within a dialog are described in [RFC5057]. 1241 Subscribers MUST NOT attempt to re-use dialogs whose remote target is 1242 a GRUU. 1244 Note that the techniques described in this section are included 1245 for backwards compatibility purposes only. Because subscribers 1246 cannot re-use dialogs with a GRUU for their remote target, and 1247 because notifiers must use GRUUs as their local target, any two 1248 implementations that conform to this specification will 1249 automatically use the mechanism described in Section 4.5.1. 1251 Further note that the prohibition on re-using dialogs does not 1252 exempt implicit subscriptions created by the REFER method. This 1253 means that implementations complying with this specification are 1254 required to use the "Target-Dialog" mechanism described in 1255 [RFC4538] when the remote target is a GRUU. 1257 If a subscriber wishes to subscribe to a resource on the same device 1258 as an established dialog and the remote contact is not a GRUU, it MAY 1259 revert to dialog sharing behavior. Alternately, it MAY choose to 1260 treat the remote party as incapable of servicing the subscription 1261 (i.e., the same way it would behave if the remote party did not 1262 support SIP events at all). 1264 If a notifier receives a SUBSCRIBE request for a new subscription on 1265 an existing dialog, it MAY choose to implement dialog sharing 1266 behavior. Alternately, it may choose to fail the SUBSCRIBE request 1267 with a 403 response. The error text of such 403 responses SHOULD 1268 indicate that dialog sharing is not supported. 1270 To implement dialog sharing, subscribers and notifiers perform the 1271 following additional processing: 1273 o When subscriptions exist in dialogs associated with INVITE-created 1274 application state and/or other subscriptions, these sets of 1275 application state do not interact beyond the behavior described 1276 for a dialog (e.g., route set handling). In particular, multiple 1277 subscriptions within a dialog are expire independently, and 1278 require independent subscription refreshes. 1280 o If a subscription's destruction leaves no other application state 1281 associated with the dialog, the dialog terminates. The 1282 destruction of other application state (such as that created by an 1283 INVITE) will not terminate the dialog if a subscription is still 1284 associated with that dialog. This means that, when dialog are re- 1285 used, then a dialog created with an INVITE does not necessarily 1286 terminate upon receipt of a BYE. Similarly, in the case that 1287 several subscriptions are associated with a single dialog, the 1288 dialog does not terminate until all the subscriptions in it are 1289 destroyed. 1291 o Subscribers MAY include an "id" parameter in SUBSCRIBE request 1292 "Event" header field to allow differentiation between multiple 1293 subscriptions in the same dialog. This "id" parameter, if 1294 present, contains an opaque token which identifies the specific 1295 subscription within a dialog. An "id" parameter is only valid 1296 within the scope of a single dialog. 1298 o If an "id" parameter is present in the SUBSCRIBE request used to 1299 establish a subscription, that "id" parameter MUST also be present 1300 in all corresponding NOTIFY requests. 1302 o When a subscriber refreshes a the subscription timer, the 1303 SUBSCRIBE request MUST contain the same "Event" header field "id" 1304 parameter as was present in the SUBSCRIBE request that created the 1305 subscription. (Otherwise, the notifier will interpret the 1306 SUBSCRIBE request as a request for a new subscription in the same 1307 dialog). 1309 o When a subscription is created in the notifier, it stores any 1310 "Event" header field "id" parameter as part of the subscription 1311 information (along with the event package name). 1313 o If an initial SUBSCRIBE request is sent on a pre-existing dialog, 1314 a matching NOTIFY request merely creates a new subscription 1315 associated with that dialog. 1317 4.6. CANCEL Requests for SUBSCRIBE and NOTIFY Transactions 1319 Neither SUBSCRIBE nor NOTIFY requests can be canceled. If a UAS 1320 receives a CANCEL request that matches a known SUBSCRIBE or NOTIFY 1321 transaction, it MUST respond to the CANCEL request, but otherwise 1322 ignore it. In particular, the CANCEL request MUST NOT affect 1323 processing of the SUBSCRIBE or NOTIFY request in any way. 1325 UACs SHOULD NOT send CANCEL requests for SUBSCRIBE or NOTIFY 1326 transactions. 1328 5. Event Packages 1330 This section covers several issues which should be taken into 1331 consideration when event packages based on the SUBSCRIBE and NOTIFY 1332 methods are proposed. 1334 5.1. Appropriateness of Usage 1336 When designing an event package using the methods described in this 1337 document for event notification, it is important to consider: is SIP 1338 an appropriate mechanism for the problem set? Is SIP being selected 1339 because of some unique feature provided by the protocol (e.g., user 1340 mobility), or merely because "it can be done?" If you find yourself 1341 defining event packages for notifications related to, for example, 1342 network management or the temperature inside your car's engine, you 1343 may want to reconsider your selection of protocols. 1345 Those interested in extending the mechanism defined in this 1346 document are urged to follow the development of "Guidelines for 1347 Authors of SIP Extensions" [RFC4485] for further guidance 1348 regarding appropriate uses of SIP. 1350 Further, it is expected that this mechanism is not to be used in 1351 applications where the frequency of reportable events is excessively 1352 rapid (e.g., more than about once per second). A SIP network is 1353 generally going to be provisioned for a reasonable signaling volume; 1354 sending a notification every time a user's GPS position changes by 1355 one hundredth of a second could easily overload such a network. 1357 5.2. Event Template-packages 1359 Normal event packages define a set of state applied to a specific 1360 type of resource, such as user presence, call state, and messaging 1361 mailbox state. 1363 Event template-packages are a special type of package which define a 1364 set of state applied to other packages, such as statistics, access 1365 policy, and subscriber lists. Event template-packages may even be 1366 applied to other event template-packages. 1368 To extend the object-oriented analogy made earlier, event template- 1369 packages can be thought of as templatized C++ packages which must be 1370 applied to other packages to be useful. 1372 The name of an event template-package as applied to a package is 1373 formed by appending a period followed by the event template-package 1374 name to the end of the package. For example, if a template-package 1375 called "winfo" were being applied to a package called "presence", the 1376 event token used in the "Event" header field would be 1377 "presence.winfo". 1379 This scheme may be arbitrarily extended. For example, application 1380 of the "winfo" package to the the "presence.winfo" state of a 1381 resource would be represented by the name "presence.winfo.winfo". 1382 It naturally follows from this syntax that the order in which 1383 templates are specified is significant. 1385 For example: consider a theoretical event template-package called 1386 "list". The event "presence.winfo.list" would be the application 1387 of the "list" template to "presence.winfo", which would presumably 1388 be a list of winfo state associated with presence. On the other 1389 hand, the event "presence.list.winfo" would represent the 1390 application of winfo to "presence.list", which would be represent 1391 the winfo state of a list of presence information. 1393 Event template-packages must be defined so that they can be applied 1394 to any arbitrary package. In other words, event template-packages 1395 cannot be specifically tied to one or a few "parent" packages in such 1396 a way that they will not work with other packages. 1398 5.3. Amount of State to be Conveyed 1400 When designing event packages, it is important to consider the type 1401 of information which will be conveyed during a notification. 1403 A natural temptation is to convey merely the event (e.g., "a new 1404 voice message just arrived") without accompanying state (e.g., "7 1405 total voice messages"). This complicates implementation of 1406 subscribing entities (since they have to maintain complete state for 1407 the entity to which they have subscribed), and also is particularly 1408 susceptible to synchronization problems. 1410 There are two possible solutions to this problem that event packages 1411 may choose to implement. 1413 5.3.1. Complete State Information 1415 In general, event packages need to be able to convey a well-defined 1416 and complete state, rather than just a stream of events. If it is 1417 not possible to describe complete system state for transmission in 1418 NOTIFY requests, then the problem set is not a good candidate for an 1419 event package. 1421 For packages which typically convey state information that is 1422 reasonably small (on the order of 1 KB or so), it is suggested that 1423 event packages are designed so as to send complete state information 1424 whenever an event occurs. 1426 In some circumstances, conveying the current state alone may be 1427 insufficient for a particular class of events. In these cases, the 1428 event packages should include complete state information along with 1429 the event that occurred. For example, conveying "no customer service 1430 representatives available" may not be as useful as conveying "no 1431 customer service representatives available; representative 1432 sip:46@cs.xyz.int just logged off". 1434 5.3.2. State Deltas 1436 In the case that the state information to be conveyed is large, the 1437 event package may choose to detail a scheme by which NOTIFY requests 1438 contain state deltas instead of complete state. 1440 Such a scheme would work as follows: any NOTIFY request sent in 1441 immediate response to a SUBSCRIBE request contains full state 1442 information. NOTIFY requests sent because of a state change will 1443 contain only the state information that has changed; the subscriber 1444 will then merge this information into its current knowledge about the 1445 state of the resource. 1447 Any event package that supports delta changes to states MUST include 1448 a version number that increases by exactly one for each NOTIFY 1449 transaction in a subscription. Note that the state version number 1450 appears in the body of the message, not in a SIP header field. 1452 If a NOTIFY request arrives that has a version number that is 1453 incremented by more than one, the subscriber knows that a state delta 1454 has been missed; it ignores the NOTIFY request containing the state 1455 delta (except for the version number, which it retains to detect 1456 message loss), and re-sends a SUBSCRIBE request to force a NOTIFY 1457 request containing a complete state snapshot. 1459 5.4. Event Package Responsibilities 1461 Event packages are not required to reiterate any of the behavior 1462 described in this document, although they may choose to do so for 1463 clarity or emphasis. In general, though, such packages are expected 1464 to describe only the behavior that extends or modifies the behavior 1465 described in this document. 1467 Note that any behavior designated with "SHOULD" or "MUST" in this 1468 document is not allowed to be weakened by extension documents; 1469 however, such documents may elect to strengthen "SHOULD" requirements 1470 to "MUST" strength if required by their application. 1472 In addition to the normal sections expected in standards-track RFCs 1473 and SIP extension documents, authors of event packages need to 1474 address each of the issues detailed in the following subsections. 1476 For clarity: well-formed event package definitions contain sections 1477 addressing each of these issues, ideally in the same order and with 1478 the same titles as these subsections. 1480 5.4.1. Event Package Name 1482 This section, which MUST be present, defines the token name to be 1483 used to designate the event package. It MUST include the information 1484 which appears in the IANA registration of the token. For information 1485 on registering such types, see Section 7. 1487 5.4.2. Event Package Parameters 1489 If parameters are to be used on the "Event" header field to modify 1490 the behavior of the event package, the syntax and semantics of such 1491 header fields MUST be clearly defined. 1493 Any "Event" header field parameters defined by an event package MUST 1494 be registered in the "Header Field Parameters and Parameter Values" 1495 registry defined by [RFC3968]. An "Event" header field parameter, 1496 once registered in conjunction with an event package, MUST NOT be re- 1497 used with any other event package. Non-event-package specifications 1498 MAY define "Event" header field parameters that apply across all 1499 event packages (with emphasis on "all", as opposed to "several"), 1500 such as the "id" parameter defined in this document. The restriction 1501 of a parameter to use with a single event package only applies to 1502 parameters that are defined in conjunction with an event package. 1504 5.4.3. SUBSCRIBE Request Bodies 1506 It is expected that most, but not all, event packages will define 1507 syntax and semantics for SUBSCRIBE request bodies; these bodies will 1508 typically modify, expand, filter, throttle, and/or set thresholds for 1509 the class of events being requested. Designers of event packages are 1510 strongly encouraged to re-use existing media types for message bodies 1511 where practical. See [RFC4288] for information on media type 1512 specification and registration. 1514 This mandatory section of an event package defines what type or types 1515 of event bodies are expected in SUBSCRIBE requests (or specify that 1516 no event bodies are expected). It should point to detailed 1517 definitions of syntax and semantics for all referenced body types. 1519 5.4.4. Subscription Duration 1521 It is RECOMMENDED that event packages give a suggested range of times 1522 considered reasonable for the duration of a subscription. Such 1523 packages MUST also define a default "Expires" value to be used if 1524 none is specified. 1526 5.4.5. NOTIFY Request Bodies 1528 The NOTIFY request body is used to report state on the resource being 1529 monitored. Each package MUST define what type or types of event 1530 bodies are expected in NOTIFY requests. Such packages MUST specify 1531 or cite detailed specifications for the syntax and semantics 1532 associated with such event body. 1534 Event packages also MUST define which media type is to be assumed if 1535 none are specified in the "Accept" header field of the SUBSCRIBE 1536 request. 1538 5.4.6. Notifier processing of SUBSCRIBE requests 1540 This section describes the processing to be performed by the notifier 1541 upon receipt of a SUBSCRIBE request. Such a section is required. 1543 Information in this section includes details of how to authenticate 1544 subscribers and authorization issues for the package. 1546 5.4.7. Notifier generation of NOTIFY requests 1548 This section of an event package describes the process by which the 1549 notifier generates and sends a NOTIFY request. This includes 1550 detailed information about what events cause a NOTIFY request to be 1551 sent, how to compute the state information in the NOTIFY, how to 1552 generate neutral or fake state information to hide authorization 1553 delays and decisions from users, and whether state information is 1554 complete or deltas for notifications; see Section 5.3. Such a 1555 section is required. 1557 This section may optionally describe the behavior used to process the 1558 subsequent response. 1560 5.4.8. Subscriber processing of NOTIFY requests 1562 This section of an event package describes the process followed by 1563 the subscriber upon receipt of a NOTIFY request, including any logic 1564 required to form a coherent resource state (if applicable). 1566 5.4.9. Handling of forked requests 1568 Each event package MUST specify whether forked SUBSCRIBE requests are 1569 allowed to install multiple subscriptions. 1571 If such behavior is not allowed, the first potential dialog- 1572 establishing message will create a dialog. All subsequent NOTIFY 1573 requests which correspond to the SUBSCRIBE request (i.e., match "To", 1574 "From", "From" header field "tag" parameter, "Call-ID", "Event", and 1575 "Event" header field "id" parameter) but which do not match the 1576 dialog would be rejected with a 481 response. Note that the 200- 1577 class response to the SUBSCRIBE request can arrive after a matching 1578 NOTIFY request has been received; such responses might not correlate 1579 to the same dialog established by the NOTIFY request. Except as 1580 required to complete the SUBSCRIBE transaction, such non-matching 1581 200-class responses are ignored. 1583 If installing of multiple subscriptions by way of a single forked 1584 SUBSCRIBE request is allowed, the subscriber establishes a new dialog 1585 towards each notifier by returning a 200-class response to each 1586 NOTIFY request. Each dialog is then handled as its own entity, and 1587 is refreshed independent of the other dialogs. 1589 In the case that multiple subscriptions are allowed, the event 1590 package MUST specify whether merging of the notifications to form a 1591 single state is required, and how such merging is to be performed. 1592 Note that it is possible that some event packages may be defined in 1593 such a way that each dialog is tied to a mutually exclusive state 1594 which is unaffected by the other dialogs; this MUST be clearly stated 1595 if it is the case. 1597 5.4.10. Rate of notifications 1599 Each event package is expected to define a requirement (SHOULD or 1600 MUST strength) which defines an absolute maximum on the rate at which 1601 notifications are allowed to be generated by a single notifier. 1603 Each package MAY further define a throttle mechanism which allows 1604 subscribers to further limit the rate of notification. 1606 5.4.11. State Aggregation 1608 Many event packages inherently work by collecting information about a 1609 resource from a number of other sources -- either through the use of 1610 PUBLISH [RFC3903], by subscribing to state information, or through 1611 other state gathering mechanisms. 1613 Event packages that involve retrieval of state information for a 1614 single resource from more than one source need to consider how 1615 notifiers aggregate information into a single, coherent state. Such 1616 packages MUST specify how notifiers aggregate information and how 1617 they provide authentication and authorization. 1619 5.4.12. Examples 1621 Event packages SHOULD include several demonstrative message flow 1622 diagrams paired with several typical, syntactically correct, and 1623 complete messages. 1625 It is RECOMMENDED that documents describing event packages clearly 1626 indicate that such examples are informative and not normative, with 1627 instructions that implementors refer to the main text of the document 1628 for exact protocol details. 1630 5.4.13. Use of URIs to Retrieve State 1632 Some types of event packages may define state information which is 1633 potentially too large to reasonably send in a SIP message. To 1634 alleviate this problem, event packages may include the ability to 1635 convey a URI instead of state information; this URI will then be used 1636 to retrieve the actual state information. 1638 [RFC4483] defines a mechanism that can be used by event packages to 1639 convey information in such a fashion. 1641 6. Security Considerations 1643 6.1. Access Control 1645 The ability to accept subscriptions should be under the direct 1646 control of the notifier's user, since many types of events may be 1647 considered sensitive for the purposes of privacy. Similarly, the 1648 notifier should have the ability to selectively reject subscriptions 1649 based on the subscriber identity (based on access control lists), 1650 using standard SIP authentication mechanisms. The methods for 1651 creation and distribution of such access control lists is outside the 1652 scope of this document. 1654 6.2. Notifier Privacy Mechanism 1656 The mere act of returning certain 4xx and 6xx responses to SUBSCRIBE 1657 requests may, under certain circumstances, create privacy concerns by 1658 revealing sensitive policy information. In these cases, the notifier 1659 SHOULD always return a 200 (OK) response. While the subsequent 1660 NOTIFY request may not convey true state, it MUST appear to contain a 1661 potentially correct piece of data from the point of view of the 1662 subscriber, indistinguishable from a valid response. Information 1663 about whether a user is authorized to subscribe to the requested 1664 state is never conveyed back to the original user under these 1665 circumstances. 1667 Individual packages and their related documents for which such a mode 1668 of operation makes sense can further describe how and why to generate 1669 such potentially correct data. For example, such a mode of operation 1670 is mandated by [RFC2779] for user presence information. 1672 6.3. Denial-of-Service attacks 1674 The current model (one SUBSCRIBE request triggers a SUBSCRIBE 1675 response and one or more NOTIFY requests) is a classic setup for an 1676 amplifier node to be used in a smurf attack. 1678 Also, the creation of state upon receipt of a SUBSCRIBE request can 1679 be used by attackers to consume resources on a victim's machine, 1680 rendering it unusable. 1682 To reduce the chances of such an attack, implementations of notifiers 1683 SHOULD require authentication. Authentication issues are discussed 1684 in [RFC3261]. 1686 6.4. Replay Attacks 1688 Replaying of either SUBSCRIBE or NOTIFY requests can have detrimental 1689 effects. 1691 In the case of SUBSCRIBE requests, attackers may be able to install 1692 any arbitrary subscription which it witnessed being installed at some 1693 point in the past. Replaying of NOTIFY requests may be used to spoof 1694 old state information (although a good versioning mechanism in the 1695 body of the NOTIFY requests may help mitigate such an attack). Note 1696 that the prohibition on sending NOTIFY requests to nodes which have 1697 not subscribed to an event also aids in mitigating the effects of 1698 such an attack. 1700 To prevent such attacks, implementations SHOULD require 1701 authentication with anti-replay protection. Authentication issues 1702 are discussed in [RFC3261]. 1704 6.5. Man-in-the middle attacks 1706 Even with authentication, man-in-the-middle attacks using SUBSCRIBE 1707 requests may be used to install arbitrary subscriptions, hijack 1708 existing subscriptions, terminate outstanding subscriptions, or 1709 modify the resource to which a subscription is being made. To 1710 prevent such attacks, implementations SHOULD provide integrity 1711 protection across "Contact", "Route", "Expires", "Event", and "To" 1712 header fields of SUBSCRIBE requests, at a minimum. If SUBSCRIBE 1713 request bodies are used to define further information about the state 1714 of the call, they SHOULD be included in the integrity protection 1715 scheme. 1717 Man-in-the-middle attacks may also attempt to use NOTIFY requests to 1718 spoof arbitrary state information and/or terminate outstanding 1719 subscriptions. To prevent such attacks, implementations SHOULD 1720 provide integrity protection across the "Call-ID", "CSeq", and 1721 "Subscription-State" header fields and the bodies of NOTIFY requests. 1723 Integrity protection of message header fields and bodies is discussed 1724 in [RFC3261]. 1726 6.6. Confidentiality 1728 The state information contained in a NOTIFY request has the potential 1729 to contain sensitive information. Implementations MAY encrypt such 1730 information to ensure confidentiality. 1732 While less likely, it is also possible that the information contained 1733 in a SUBSCRIBE request contains information that users might not want 1734 to have revealed. Implementations MAY encrypt such information to 1735 ensure confidentiality. 1737 To allow the remote party to hide information it considers sensitive, 1738 all implementations SHOULD be able to handle encrypted SUBSCRIBE and 1739 NOTIFY requests. 1741 The mechanisms for providing confidentiality are detailed in 1742 [RFC3261]. 1744 7. IANA Considerations 1746 (This section is not applicable until this document is published as 1747 an RFC.) 1749 With the exception of Section 7.2, the subsections here are for 1750 current reference, carried over from the original specification. The 1751 only IANA actions requested here are updating all registry references 1752 that point to RFC 3265 to instead indicate this document, and 1753 creating the new "reason code" registry described in Section 7.2. 1755 7.1. Event Packages 1757 This document defines an event-type namespace which requires a 1758 central coordinating body. The body chosen for this coordination is 1759 the Internet Assigned Numbers Authority (IANA). 1761 There are two different types of event-types: normal event packages, 1762 and event template-packages; see Section 5.2. To avoid confusion, 1763 template-package names and package names share the same namespace; in 1764 other words, an event template-package are forbidden from sharing a 1765 name with a package. 1767 Policies for registration of SIP event packages and SIP event package 1768 templates are defined in section 4.1 of [RFC5727]. 1770 Registrations with the IANA are required to include the token being 1771 registered and whether the token is a package or a template-package. 1772 Further, packages must include contact information for the party 1773 responsible for the registration and/or a published document which 1774 describes the event package. Event template-package token 1775 registrations are also required to include a pointer to the published 1776 RFC which defines the event template-package. 1778 Registered tokens to designate packages and template-packages are 1779 disallowed from containing the character ".", which is used to 1780 separate template-packages from packages. 1782 7.1.1. Registration Information 1784 As this document specifies no package or template-package names, the 1785 initial IANA registry for event types will be empty. The remainder 1786 of the text in this section gives an example of the type of 1787 information to be maintained by the IANA; it also demonstrates all 1788 five possible permutations of package type, contact, and reference. 1790 The table below lists the event packages and template-packages 1791 defined in "SIP-Specific Event Notification" [RFC xxxx]. Each name 1792 is designated as a package or a template-package under "Type". 1794 Package Name Type Contact Reference 1795 ------------ ---- ------- --------- 1796 example1 package [Roach] 1797 example2 package [Roach] [RFC xxxx] 1798 example3 package [RFC xxxx] 1799 example4 template [Roach] [RFC xxxx] 1800 example5 template [RFC xxxx] 1802 PEOPLE 1803 ------ 1804 [Roach] Adam Roach 1806 REFERENCES 1807 ---------- 1808 [RFC xxxx] A.B. Roach, "SIP-Specific Event Notification", RFC XXXX, 1809 Monthname 20XX 1811 7.1.2. Registration Template 1813 To: ietf-sip-events@iana.org 1814 Subject: Registration of new SIP event package 1816 Package Name: 1818 (Package names must conform to the syntax described in 1819 Section 8.2.1.) 1821 Is this registration for a Template Package: 1823 (indicate yes or no) 1825 Published Specification(s): 1827 (Template packages require a published RFC. Other packages may 1828 reference a specification when appropriate). 1830 Person & email address to contact for further information: 1832 7.2. Reason Codes 1834 This document further defines "reason" codes for use in the 1835 "Subscription-State" header field (see Section 4.1.3). 1837 Following the policies outlined in "Guidelines for Writing an IANA 1838 Considerations Section in RFCs" [RFC5226], new reason codes require a 1839 Standards Action. 1841 Registrations with the IANA include the reason code being registered 1842 and a reference to a published document which describes the event 1843 package. Insertion of such values takes place as part of the RFC 1844 publication process or as the result of inter-SDO liaison activity, 1845 the result of which will be publication of an associated RFC. New 1846 reason codes must conform to the syntax of the ABNF "token" element 1847 defined in [RFC3261]. 1849 [RFC4660] defined a new reason code prior to the establishment of an 1850 IANA registry. We include its reason code ("badfilter") in the 1851 initial list of reason codes to ensure a complete registry. 1853 The IANA registry for reason code will be initialized with the 1854 following values: 1856 Reason Code Reference 1857 ----------- --------- 1858 deactivated [RFC xxxx] 1859 probation [RFC xxxx] 1860 rejected [RFC xxxx] 1861 timeout [RFC xxxx] 1862 giveup [RFC xxxx] 1863 noresource [RFC xxxx] 1864 invariant [RFC xxxx] 1865 badfilter [RFC 4660] 1867 REFERENCES 1868 ---------- 1869 [RFC xxxx] A.B. Roach, "SIP-Specific Event Notification", RFC XXXX, 1870 Monthname 20XX 1872 [RFC 4660] Khartabil, H., Leppanen, E., Lonnfors, M., and 1873 J. Costa-Requena, "Functional Description of Event 1874 Notification Filtering", September 2006. 1876 7.3. Header Field Names 1878 This document registers three new header field names, described 1879 elsewhere in this document. These header fields are defined by the 1880 following information, which is to be added to the header field sub- 1881 registry under http://www.iana.org/assignments/sip-parameters. 1883 Header Name: Allow-Events 1884 Compact Form: u 1886 Header Name: Subscription-State 1887 Compact Form: (none) 1889 Header Name: Event 1890 Compact Form: o 1892 7.4. Response Codes 1894 This document registers two new response codes. These response codes 1895 are defined by the following information, which is to be added to the 1896 method and response-code sub-registry under 1897 http://www.iana.org/assignments/sip-parameters. 1899 Response Code Number: 202 1900 Default Reason Phrase: Accepted 1902 Response Code Number: 489 1903 Default Reason Phrase: Bad Event 1905 8. Syntax 1907 This section describes the syntax extensions required for event 1908 notification in SIP. Semantics are described in Section 4. Note 1909 that the formal syntax definitions described in this document are 1910 expressed in the ABNF format used in [RFC3261], and contain 1911 references to elements defined therein. 1913 8.1. New Methods 1915 This document describes two new SIP methods: SUBSCRIBE and NOTIFY. 1917 8.1.1. SUBSCRIBE method 1919 "SUBSCRIBE" is added to the definition of the element "Method" in the 1920 SIP message grammar. 1922 Like all SIP method names, the SUBSCRIBE method name is case 1923 sensitive. The SUBSCRIBE method is used to request asynchronous 1924 notification of an event or set of events at a later time. 1926 8.1.2. NOTIFY method 1928 "NOTIFY" is added to the definition of the element "Method" in the 1929 SIP message grammar. 1931 The NOTIFY method is used to notify a SIP node that an event which 1932 has been requested by an earlier SUBSCRIBE method has occurred. It 1933 may also provide further details about the event. 1935 8.2. New Header Fields 1937 8.2.1. "Event" Header Field 1939 Event is added to the definition of the element "message-header 1940 field" in the SIP message grammar. 1942 For the purposes of matching NOTIFY requests with SUBSCRIBE requests, 1943 the event-type portion of the "Event" header field is compared byte- 1944 by-byte, and the "id" parameter token (if present) is compared byte- 1945 by-byte. An "Event" header field containing an "id" parameter never 1946 matches an "Event" header field without an "id" parameter. No other 1947 parameters are considered when performing a comparison. SUBSCRIBE 1948 responses are matched per the transaction handling rules in 1949 [RFC3261]. 1951 Note that the forgoing text means that "Event: foo; id=1234" would 1952 match "Event: foo; param=abcd; id=1234", but not "Event: foo" (id 1953 does not match) or "Event: Foo; id=1234" (event portion does not 1954 match). 1956 This document does not define values for event-types. These values 1957 will be defined by individual event packages, and MUST be registered 1958 with the IANA. 1960 There MUST be exactly one event type listed per event header field. 1961 Multiple events per message are disallowed. 1963 The "Event" header field is defined only for use in SUBSCRIBE and 1964 NOTIFY requests, and other requests whose definition explicitly calls 1965 for its use. It MUST NOT appear in any other SIP requests, and MUST 1966 NOT appear in responses. 1968 8.2.2. "Allow-Events" Header Field 1970 Allow-Events is added to the definition of the element "general- 1971 header field" in the SIP message grammar. Its usage is described in 1972 Section 4.4.4. 1974 User Agents MAY include the "Allow-Events" header field in any 1975 request or response, as long as its contents comply with the behavior 1976 described in Section 4.4.4. 1978 8.2.3. "Subscription-State" Header Field 1980 Subscription-State is added to the definition of the element 1981 "request-header field" in the SIP message grammar. Its usage is 1982 described in Section 4.1.3. "Subscription-State" header fields are 1983 defined for use in NOTIFY requests only. They MUST NOT appear in 1984 other SIP requests or responses. 1986 8.3. New Response Codes 1988 8.3.1. "202 Accepted" Response Code 1990 For historical purposes, the 202 (Accepted) response code is added to 1991 the "Success" header field definition. 1993 This document does not specify the use of the 202 response code in 1994 conjunction with the SUBSCRIBE or NOTIFY methods. Previous versions 1995 of the SIP Events Framework assigned specific meaning to the 202 1996 response code. 1998 Due to response handling in forking cases, any 202 response to a 1999 SUBSCRIBE request may be absorbed by a proxy, and thus it can never 2000 be guaranteed to be received by the UAC. Furthermore, there is no 2001 actual processing difference for a 202 as compared to a 200; a NOTIFY 2002 request is sent after the subscription is processed, and it conveys 2003 the correct state. SIP interoperability tests found that 2004 implementations were handling 202 differently from 200, leading to 2005 incompatibilities. Therefore, the 202 response is being deprecated 2006 to make it clear there is no such difference and 202 should not be 2007 handled differently than 200. 2009 Implementations conformant with the current specification MUST treat 2010 an incoming 202 response as identical to a 200 response, and MUST NOT 2011 generate 202 response codes to SUBSCRIBE or NOTIFY requests. 2013 This document also updates [RFC4660], which reiterates the 202-based 2014 behavior in several places. Implementations compliant with the 2015 present document MUST NOT send a 202 response to a SUBSCRIBE request, 2016 and will send an alternate success response (such as 200) in its 2017 stead. 2019 8.3.2. "489 Bad Event" Response Code 2021 The 489 event response is added to the "Client-Error" header field 2022 field definition. "489 Bad Event" is used to indicate that the server 2023 did not understand the event package specified in a "Event" header 2024 field. 2026 8.4. Augmented BNF Definitions 2028 The Augmented BNF definitions for the various new and modified syntax 2029 elements follows. The notation is as used in [RFC3261], and any 2030 elements not defined in this section are as defined in SIP and the 2031 documents to which it refers. 2033 SUBSCRIBEm = %x53.55.42.53.43.52.49.42.45 ; SUBSCRIBE in caps 2034 NOTIFYm = %x4E.4F.54.49.46.59 ; NOTIFY in caps 2035 extension-method = SUBSCRIBEm / NOTIFYm / token 2037 Event = ( "Event" / "o" ) HCOLON event-type 2038 *( SEMI event-param ) 2039 event-type = event-package *( "." event-template ) 2040 event-package = token-nodot 2041 event-template = token-nodot 2042 token-nodot = 1*( alphanum / "-" / "!" / "%" / "*" 2043 / "_" / "+" / "`" / "'" / "~" ) 2045 ; The use of the "id" parameter is deprecated; it is included 2046 ; for backwards compatibility purposes only. 2047 event-param = generic-param / ( "id" EQUAL token ) 2049 Allow-Events = ( "Allow-Events" / "u" ) HCOLON event-type 2050 *(COMMA event-type) 2052 Subscription-State = "Subscription-State" HCOLON substate-value 2053 *( SEMI subexp-params ) 2054 substate-value = "active" / "pending" / "terminated" 2055 / extension-substate 2056 extension-substate = token 2057 subexp-params = ("reason" EQUAL event-reason-value) 2058 / ("expires" EQUAL delta-seconds) 2059 / ("retry-after" EQUAL delta-seconds) 2060 / generic-param 2061 event-reason-value = "deactivated" 2062 / "probation" 2063 / "rejected" 2064 / "timeout" 2065 / "giveup" 2066 / "noresource" 2067 / "invariant" 2068 / event-reason-extension 2069 event-reason-extension = token 2071 9. References 2073 9.1. Normative References 2075 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2076 Requirement Levels", BCP 14, RFC 2119, March 1997. 2078 [RFC2848] Petrack, S. and L. Conroy, "The PINT Service Protocol: 2079 Extensions to SIP and SDP for IP Access to Telephone Call 2080 Services", RFC 2848, June 2000. 2082 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2083 A., Peterson, J., Sparks, R., Handley, M., and E. 2084 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2085 June 2002. 2087 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 2088 Event Notification", RFC 3265, June 2002. 2090 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 2091 (IANA) Header Field Parameter Registry for the Session 2092 Initiation Protocol (SIP)", BCP 98, RFC 3968, 2093 December 2004. 2095 [RFC4483] Burger, E., "A Mechanism for Content Indirection in 2096 Session Initiation Protocol (SIP) Messages", RFC 4483, 2097 May 2006. 2099 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2100 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2101 May 2008. 2103 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 2104 Agent URIs (GRUUs) in the Session Initiation Protocol 2105 (SIP)", RFC 5627, October 2009. 2107 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 2108 for the Session Initiation Protocol (SIP) and the Real- 2109 time Applications and Infrastructure Area", BCP 67, 2110 RFC 5727, March 2010. 2112 9.2. Informative References 2114 [RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant 2115 Messaging / Presence Protocol Requirements", RFC 2779, 2116 February 2000. 2118 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 2119 Method", RFC 3515, April 2003. 2121 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2122 "Indicating User Agent Capabilities in the Session 2123 Initiation Protocol (SIP)", RFC 3840, August 2004. 2125 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 2126 Protocol (SIP) "Replaces" Header", RFC 3891, 2127 September 2004. 2129 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 2130 for Event State Publication", RFC 3903, October 2004. 2132 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol 2133 (SIP) "Join" Header", RFC 3911, October 2004. 2135 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 2136 Initiated Dialog Event Package for the Session Initiation 2137 Protocol (SIP)", RFC 4235, November 2005. 2139 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 2140 Registration Procedures", BCP 13, RFC 4288, December 2005. 2142 [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors 2143 of Extensions to the Session Initiation Protocol (SIP)", 2144 RFC 4485, May 2006. 2146 [RFC4538] Rosenberg, J., "Request Authorization through Dialog 2147 Identification in the Session Initiation Protocol (SIP)", 2148 RFC 4538, June 2006. 2150 [RFC4660] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 2151 Requena, "Functional Description of Event Notification 2152 Filtering", RFC 4660, September 2006. 2154 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 2155 Initiation Protocol", RFC 5057, November 2007. 2157 [RFC5839] Niemi, A. and D. Willis, "An Extension to Session 2158 Initiation Protocol (SIP) Events for Conditional Event 2159 Notification", RFC 5839, May 2010. 2161 Appendix A. Acknowledgements 2163 Thanks to the participants in the Events BOF at the 48th IETF meeting 2164 in Pittsburgh, as well as those who gave ideas and suggestions on the 2165 SIP Events mailing list. In particular, I wish to thank Henning 2166 Schulzrinne of Columbia University for coming up with the final 2167 three-tiered event identification scheme, Sean Olson for 2168 miscellaneous guidance, Jonathan Rosenberg for a thorough scrubbing 2169 of the -00 draft, and the authors of the "SIP Extensions for 2170 Presence" document for their input to SUBSCRIBE and NOTIFY request 2171 semantics. 2173 I also owe a debt of gratitude to all the implementors who have 2174 provided feedback on areas of confusion or difficulty in the original 2175 specification. In particular, Robert Sparks' Herculean efforts 2176 organizing, running, and collecting data from the SIPit events have 2177 proven invaluable in shaking out specification bugs. Robert Sparks 2178 is also responsible for untangling the dialog usage mess, in the form 2179 of RFC 5057 [RFC5057]. 2181 Appendix B. Changes from RFC 3265 2183 This document represents several changes from the mechanism 2184 originally described in RFC 3265. This section summarizes those 2185 changes. Bug numbers refer to the identifiers for the bug reports 2186 kept on file at http://bugs.sipit.net/. 2188 B.1. Bug 666: Clarify use of expires=xxx with terminated 2190 Strengthened language in Section 4.1.3 to clarify that expires should 2191 not be sent with terminated, and must be ignored if received. 2193 B.2. Bug 667: Reason code for unsub/poll not clearly spelled out 2195 Clarified description of "timeout" in Section 4.1.3. (n.b., the text 2196 in Section 4.4.3 is actually pretty clear about this). 2198 B.3. Bug 669: Clarify: SUBSCRIBE for a duration might be answered with 2199 a NOTIFY/expires=0 2201 Added clarifying text to Section 4.2.2 explaining that shortening a 2202 subscription to zero seconds is valid. Also added sentence to 2203 Section 3.1.1 explicitly allowing shortening to zero. 2205 B.4. Bug 670: Dialog State Machine needs clarification 2207 The issues associated with the bug deal exclusively with the handling 2208 of multiple usages with a dialog. This behavior has been deprecated 2209 and moved to Section 4.5.2. This section, in turn, cites [RFC5057], 2210 which addresses all of the issues in Bug 670. 2212 B.5. Bug 671: Clarify timeout-based removal of subscriptions 2214 Changed Section 4.2.2 to specifically cite Timer F (so as to avoid 2215 ambiguity between transaction timeouts and retransmission timeouts). 2217 B.6. Bug 672: Mandate expires= in NOTIFY 2219 Changed strength of including of "expires" in a NOTIFY from SHOULD to 2220 MUST in Section 4.2.2. 2222 B.7. Bug 673: INVITE 481 response effect clarification 2224 This bug was addressed in [RFC5057]. 2226 B.8. Bug 677: SUBSCRIBE response matching text in error 2228 Fixed Section 8.2.1 to remove incorrect "...responses and..." -- 2229 explicitly pointed to SIP for transaction response handling. 2231 B.9. Bug 695: Document is not explicit about response to NOTIFY at 2232 subscription termination 2234 Added text to Section 4.4.1 indicating that the typical response to a 2235 terminal NOTIFY is a "200 OK". 2237 B.10. Bug 696: Subscription state machine needs clarification 2239 Added state machine diagram to Section 4.1.2 with explicit handling 2240 of what to do when a SUBSCRIBE never shows up. Added definition of 2241 and handling for new Timer N to Section 4.1.2.4. Added state machine 2242 to Section 4.2.2 to reinforce text. 2244 B.11. Bug 697: Unsubscription behavior could be clarified 2246 Added text to Section 4.2.1.4 encouraging (but not requiring) full 2247 state in final NOTIFY request. Also added text to Section 4.1.2.3 2248 warning subscribers that full state may or may not be present in the 2249 final NOTIFY. 2251 B.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh requests 2253 Added text to both Section 3.1 and Section 3.2 explicitly indicating 2254 that SUBSCRIBE and NOTIFY are target refresh methods. 2256 B.13. Bug 722: Inconsistent 423 reason phrase text 2258 Changed reason code to "Interval Too Brief" in Section 4.2.1.1 and 2259 Section 4.2.1.4, to match 423 reason code in SIP [RFC3261]. 2261 B.14. Bug 741: guidance needed on when to not include Allow-Events 2263 Added non-normative clarification to Section 4.4.4 regarding 2264 inclusion of Allow-Events in a NOTIFY for the one-and-only package 2265 supported by the notifier. 2267 B.15. Bug 744: 5xx to NOTIFY terminates a subscription, but should not 2269 Issue of subscription (usage) termination versus dialog termination 2270 is handled in [RFC5057]. The text in Section 4.2.2 has been updated 2271 to summarize the behavior described by 5057, and cites it for 2272 additional detail and rationale. 2274 B.16. Bug 752: Detection of forked requests is incorrect 2276 Removed erroneous "CSeq" from list of matching criteria in 2277 Section 5.4.9. 2279 B.17. Bug 773: Reason code needs IANA registry 2281 Added Section 7.2 to create and populate IANA registry. 2283 B.18. Bug 774: Need new reason for terminating subscriptions to 2284 resources that never change 2286 Added new "invariant" reason code to Section 4.1.3, ABNF syntax. 2288 B.19. Clarify handling of Route/Record-Route in NOTIFY 2290 Changed text in Section 4.3 mandating Record-Route in initial 2291 SUBSCRIBE and all NOTIFY requests, and adding "MAY" level statements 2292 for subsequent SUBSCRIBE requests. 2294 B.20. Eliminate implicit subscriptions 2296 Added text to Section 4.2.1 explaining some of the problems 2297 associated with implicit subscriptions, normative language 2298 prohibiting them. Removed language from Section 3.2 describing "non- 2299 SUBSCRIBE" mechanisms for creating subscriptions. Simplified 2300 language in Section 4.2.2, now that the soft-state/non-soft-state 2301 distinction is unnecessary. 2303 B.21. Deprecate dialog re-use 2305 Moved handling of dialog re-use and "id" handling to Section 4.5.2. 2306 It is documented only for backwards-compatibility purposes. 2308 B.22. Rationalize dialog creation 2310 Section 4.4.1 has been updated to specify that dialogs should be 2311 created when the NOTIFY arrives. Previously, the dialog was 2312 established by the SUBSCRIBE 200, or by the NOTIFY transaction. This 2313 was unnecessarily complicated; the newer rules are easier to 2314 implement (and result in effectively the same behavior on the wire). 2316 B.23. Refactor behavior sections 2318 Reorganized Section 4 to consolidate behavior along role lines 2319 (subscriber/notifier/proxy) instead of method lines. 2321 B.24. Clarify sections that need to be present in event packages 2323 Added sentence to Section 5 clarifying that event packages are 2324 expected to include explicit sections covering the issues discussed 2325 in this section. 2327 B.25. Make CANCEL handling more explicit 2329 Text in Section 4.6 now clearly calls out behavior upon receipt of a 2330 CANCEL. We also echo the "...SHOULD NOT send..." requirement from 2331 [RFC3261]. 2333 B.26. Remove State Agent Terminology 2335 As originally planned, we anticipated a fairly large number of event 2336 packages that would move back and forth between end-user devices and 2337 servers in the network. In practice, this has ended up not being the 2338 case. Certain events, like dialog state, are inherently hosted at 2339 end-user devices; others, like presence, are almost always hosted in 2340 the network (due to issues like composition, and the ability to 2341 deliver information when user devices are offline). Further, the 2342 concept of State Agents is the most misunderstood by event package 2343 authors. In my expert review of event packages, I have yet to find 2344 one that got the concept of State Agents completely correct -- and 2345 most of them start out with the concept being 100% backwards from the 2346 way RFC 3265 described it. 2348 Rather than remove the ability to perform the actions previously 2349 attributed to the widely misunderstood term "State Agent," we have 2350 simply eliminated this term. Instead, we talk about the behaviors 2351 required to create state agents (state aggregation, subscription 2352 notification) without defining a formal term to describe the servers 2353 that exhibit these behaviors. In effect, this is an editorial change 2354 to make life easier for event package authors; the actual protocol 2355 does not change as a result. 2357 The definition of "State Agent" has been removed from Section 2. 2358 Section 4.4.2 has been retooled to discuss migration of subscription 2359 in general, without calling out the specific example of state agents. 2360 Section 5.4.11 has been focused on state aggregation in particular, 2361 instead of state aggregation as an aspect of state agents. 2363 B.27. Miscellanous Changes 2365 The following changes are relatively minor revisions to the document 2366 that resulted primarily from review of this document in the working 2367 group and IESG, rather than implementation reports. 2369 o Clarified scope of Event header field parameters. In RFC3265, the 2370 scope is ambiguous, which causes problems with the RFC3968 2371 registry. The new text ensures that Event header field parameters 2372 are unique across all event packages. 2374 o Removed obsoleted language around IANA registration policies for 2375 event packages. Instead, we now cite RFC5727, which supersedes 2376 RFC3265, and is authoritative on event package registration 2377 policy. 2379 o Several editorial updates after input from working group, 2380 including proper designation of "dialog usage" rather than 2381 "dialog" where appropriate. 2383 o Clarified two normative statements about subscription termination 2384 by changing from plain English prose to RFC2119 language. 2386 o Removed "Table 2" expansions, per WG consensus on how SIP table 2 2387 is to be handled. 2389 o Removed 202 response code. 2391 o Clarified that "Allow-Events" does not list event template 2392 packages. 2394 o Added clarification about proper response when the SUBSCRIBE 2395 indicates an unknown media type in its Accept header field. 2397 o Minor clarifications to Route and Record-Route behavior. 2399 o Added non-normative warning about the limitations of state 2400 polling. 2402 o Added information about targeting subscriptions at specific 2403 dialogs. 2405 o Added RFC 3261 to list of documents updated by this one (rather 2406 than the "2543" indicated by RFC3265). 2408 o Clarified text in Section 3.1.1 explaining the meaning of 2409 "Expires: 0". 2411 o Changed text in definition of "probation" reason code to indicate 2412 that subscribers don't need to re-subscribe if the associated 2413 state is no longer of use to them. 2415 o Specified that the termination of a subscription due to a NOTIFY 2416 transaction failure does not require sending another NOTIFY 2417 message. 2419 o Clarified how order of template application affects the meaning of 2420 an Event header field value. (e.g., "foo.bar.baz" is different 2421 than "foo.baz.bar"). 2423 Author's Address 2425 Adam Roach 2426 Tekelec 2427 17210 Campbell Rd. 2428 Suite 250 2429 Dallas, TX 75252 2430 US 2432 Email: adam@nostrum.com