idnits 2.17.1 draft-ietf-sipcore-rfc3265bis-03.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 obsoletes RFC3265, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4660, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4660, updated by this document, for RFC5378 checks: 2004-02-06) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 5, 2011) is 4651 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 1760, but not defined ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Duplicate reference: RFC4660, mentioned in 'RFC4660', was also mentioned in 'RFC 4660'. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 5 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) July 5, 2011 5 Updates: 4660 (if approved) 6 Intended status: Standards Track 7 Expires: January 6, 2012 9 SIP-Specific Event Notification 10 draft-ietf-sipcore-rfc3265bis-03 12 Abstract 14 This document describes an extension to the Session Initiation 15 Protocol (SIP). The purpose of this extension is to provide an 16 extensible framework by which SIP nodes can request notification from 17 remote nodes indicating that certain events have occurred. 19 Note that the event notification mechanisms defined herein are NOT 20 intended to be a general-purpose infrastructure for all classes of 21 event subscription and notification. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 6, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.1. Overview of Operation . . . . . . . . . . . . . . . . . . 5 59 1.2. Documentation Conventions . . . . . . . . . . . . . . . . 6 60 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. SIP Methods for Event Notification . . . . . . . . . . . . . . 7 62 3.1. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.1.1. Subscription Duration . . . . . . . . . . . . . . . . 7 64 3.1.2. Identification of Subscribed Events and Event 65 Classes . . . . . . . . . . . . . . . . . . . . . . . 8 66 3.1.3. Additional SUBSCRIBE Header Field Values . . . . . . . 9 67 3.2. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.2.1. Identification of Reported Events, Event Classes, 69 and Current State . . . . . . . . . . . . . . . . . . 9 70 4. Node Behavior . . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 10 72 4.1.1. Detecting Support for SIP Events . . . . . . . . . . . 10 73 4.1.2. Creating and Maintaining Subscriptions . . . . . . . . 10 74 4.1.3. Receiving and Processing State Information . . . . . . 14 75 4.1.4. Forking of SUBSCRIBE Requests . . . . . . . . . . . . 16 76 4.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 17 77 4.2.1. Subscription Establishment and Maintenance . . . . . . 17 78 4.2.2. Sending State Information to Subscribers . . . . . . . 20 79 4.2.3. PINT Compatibility . . . . . . . . . . . . . . . . . . 23 80 4.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 23 81 4.4. Common Behavior . . . . . . . . . . . . . . . . . . . . . 23 82 4.4.1. Dialog Creation and Termination . . . . . . . . . . . 24 83 4.4.2. Notifier Migration . . . . . . . . . . . . . . . . . . 24 84 4.4.3. Polling Resource State . . . . . . . . . . . . . . . . 25 85 4.4.4. Allow-Events header field usage . . . . . . . . . . . 26 86 4.5. Targeting Subscriptions at Devices . . . . . . . . . . . . 26 87 4.5.1. Using GRUUs to Route to Devices . . . . . . . . . . . 27 88 4.5.2. Sharing Dialogs . . . . . . . . . . . . . . . . . . . 27 89 4.6. CANCEL Requests for SUBSCRIBE and NOTIFY Transactions . . 29 90 5. Event Packages . . . . . . . . . . . . . . . . . . . . . . . . 29 91 5.1. Appropriateness of Usage . . . . . . . . . . . . . . . . . 29 92 5.2. Event Template-packages . . . . . . . . . . . . . . . . . 30 93 5.3. Amount of State to be Conveyed . . . . . . . . . . . . . . 30 94 5.3.1. Complete State Information . . . . . . . . . . . . . . 31 95 5.3.2. State Deltas . . . . . . . . . . . . . . . . . . . . . 31 97 5.4. Event Package Responsibilities . . . . . . . . . . . . . . 32 98 5.4.1. Event Package Name . . . . . . . . . . . . . . . . . . 32 99 5.4.2. Event Package Parameters . . . . . . . . . . . . . . . 32 100 5.4.3. SUBSCRIBE Request Bodies . . . . . . . . . . . . . . . 32 101 5.4.4. Subscription Duration . . . . . . . . . . . . . . . . 33 102 5.4.5. NOTIFY Request Bodies . . . . . . . . . . . . . . . . 33 103 5.4.6. Notifier processing of SUBSCRIBE requests . . . . . . 33 104 5.4.7. Notifier generation of NOTIFY requests . . . . . . . . 33 105 5.4.8. Subscriber processing of NOTIFY requests . . . . . . . 34 106 5.4.9. Handling of forked requests . . . . . . . . . . . . . 34 107 5.4.10. Rate of notifications . . . . . . . . . . . . . . . . 34 108 5.4.11. State Aggregation . . . . . . . . . . . . . . . . . . 35 109 5.4.12. Examples . . . . . . . . . . . . . . . . . . . . . . . 35 110 5.4.13. Use of URIs to Retrieve State . . . . . . . . . . . . 35 111 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 112 6.1. Access Control . . . . . . . . . . . . . . . . . . . . . . 35 113 6.2. Notifier Privacy Mechanism . . . . . . . . . . . . . . . . 36 114 6.3. Denial-of-Service attacks . . . . . . . . . . . . . . . . 36 115 6.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 36 116 6.5. Man-in-the middle attacks . . . . . . . . . . . . . . . . 37 117 6.6. Confidentiality . . . . . . . . . . . . . . . . . . . . . 37 118 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 119 7.1. Event Packages . . . . . . . . . . . . . . . . . . . . . . 38 120 7.1.1. Registration Information . . . . . . . . . . . . . . . 38 121 7.1.2. Registration Template . . . . . . . . . . . . . . . . 39 122 7.2. Reason Codes . . . . . . . . . . . . . . . . . . . . . . . 39 123 7.3. Header Field Names . . . . . . . . . . . . . . . . . . . . 40 124 7.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . 41 125 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 126 8.1. New Methods . . . . . . . . . . . . . . . . . . . . . . . 41 127 8.1.1. SUBSCRIBE method . . . . . . . . . . . . . . . . . . . 41 128 8.1.2. NOTIFY method . . . . . . . . . . . . . . . . . . . . 41 129 8.2. New Header Fields . . . . . . . . . . . . . . . . . . . . 42 130 8.2.1. "Event" Header Field . . . . . . . . . . . . . . . . . 42 131 8.2.2. "Allow-Events" Header Field . . . . . . . . . . . . . 42 132 8.2.3. "Subscription-State" Header Field . . . . . . . . . . 42 133 8.3. New Response Codes . . . . . . . . . . . . . . . . . . . . 42 134 8.3.1. "202 Accepted" Response Code . . . . . . . . . . . . . 42 135 8.3.2. "489 Bad Event" Response Code . . . . . . . . . . . . 43 136 8.4. Augmented BNF Definitions . . . . . . . . . . . . . . . . 43 137 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 138 9.1. Normative References . . . . . . . . . . . . . . . . . . . 44 139 9.2. Informative References . . . . . . . . . . . . . . . . . . 45 140 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 46 141 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 47 142 B.1. Changes from draft-ietf-sipcore-rfc3265bis-02 to 143 draft-ietf-sipcore-rfc3265bis-03 . . . . . . . . . . . . . 47 144 B.2. Changes from draft-ietf-sipcore-rfc3265bis-01 to 145 draft-ietf-sipcore-rfc3265bis-02 . . . . . . . . . . . . . 47 146 B.3. Changes from draft-ietf-sipcore-rfc3265bis-00 to 147 draft-ietf-sipcore-rfc3265bis-01 . . . . . . . . . . . . . 47 148 B.4. Changes from draft-roach-sipcore-rfc3265bis-00 to 149 draft-ietf-sipcore-rfc3265bis-00 . . . . . . . . . . . . . 48 150 B.5. Changes since RFC 3265 . . . . . . . . . . . . . . . . . . 48 151 B.5.1. Bug 666: Clarify use of expires=xxx with terminated . 48 152 B.5.2. Bug 667: Reason code for unsub/poll not clearly 153 spelled out . . . . . . . . . . . . . . . . . . . . . 48 154 B.5.3. Bug 669: Clarify: SUBSCRIBE for a duration might 155 be answered with a NOTIFY/expires=0 . . . . . . . . . 48 156 B.5.4. Bug 670: Dialog State Machine needs clarification . . 48 157 B.5.5. Bug 671: Clarify timeout-based removal of 158 subscriptions . . . . . . . . . . . . . . . . . . . . 48 159 B.5.6. Bug 672: Mandate expires= in NOTIFY . . . . . . . . . 48 160 B.5.7. Bug 673: INVITE 481 response effect clarification . . 49 161 B.5.8. Bug 677: SUBSCRIBE response matching text in error . . 49 162 B.5.9. Bug 695: Document is not explicit about response 163 to NOTIFY at subscription termination . . . . . . . . 49 164 B.5.10. Bug 696: Subscription state machine needs 165 clarification . . . . . . . . . . . . . . . . . . . . 49 166 B.5.11. Bug 697: Unsubscription behavior could be clarified . 49 167 B.5.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh 168 requests . . . . . . . . . . . . . . . . . . . . . . . 49 169 B.5.13. Bug 722: Inconsistent 423 reason phrase text . . . . . 49 170 B.5.14. Bug 741: guidance needed on when to not include 171 Allow-Events . . . . . . . . . . . . . . . . . . . . . 49 172 B.5.15. Bug 744: 5xx to NOTIFY terminates a subscription, 173 but should not . . . . . . . . . . . . . . . . . . . . 50 174 B.5.16. Bug 752: Detection of forked requests is incorrect . . 50 175 B.5.17. Bug 773: Reason code needs IANA registry . . . . . . . 50 176 B.5.18. Bug 774: Need new reason for terminating 177 subscriptions to resources that never change . . . . . 50 178 B.5.19. Clarify handling of Route/Record-Route in NOTIFY . . . 50 179 B.5.20. Eliminate implicit subscriptions . . . . . . . . . . . 50 180 B.5.21. Deprecate dialog re-use . . . . . . . . . . . . . . . 50 181 B.5.22. Rationalize dialog creation . . . . . . . . . . . . . 50 182 B.5.23. Refactor behavior sections . . . . . . . . . . . . . . 51 183 B.5.24. Clarify sections that need to be present in event 184 packages . . . . . . . . . . . . . . . . . . . . . . . 51 185 B.5.25. Make CANCEL handling more explicit . . . . . . . . . . 51 186 B.5.26. Remove State Agent Terminology . . . . . . . . . . . . 51 187 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 52 189 1. Introduction 191 The ability to request asynchronous notification of events proves 192 useful in many types of SIP services for which cooperation between 193 end-nodes is required. Examples of such services include automatic 194 callback services (based on terminal state events), buddy lists 195 (based on user presence events), message waiting indications (based 196 on mailbox state change events), and PSTN and Internet 197 Internetworking (PINT) [RFC2848] status (based on call state events). 199 The methods described in this document provide a framework by which 200 notification of these events can be ordered. 202 The event notification mechanisms defined herein are NOT intended to 203 be a general-purpose infrastructure for all classes of event 204 subscription and notification. Meeting requirements for the general 205 problem set of subscription and notification is far too complex for a 206 single protocol. Our goal is to provide a SIP-specific framework for 207 event notification which is not so complex as to be unusable for 208 simple features, but which is still flexible enough to provide 209 powerful services. Note, however, that event packages based on this 210 framework may define arbitrarily elaborate rules which govern the 211 subscription and notification for the events or classes of events 212 they describe. 214 This document does not describe an extension which may be used 215 directly; it must be extended by other documents (herein referred to 216 as "event packages"). In object-oriented design terminology, it may 217 be thought of as an abstract base class which must be derived into an 218 instantiatable class by further extensions. Guidelines for creating 219 these extensions are described in Section 5. 221 1.1. Overview of Operation 223 The general concept is that entities in the network can subscribe to 224 resource or call state for various resources or calls in the network, 225 and those entities (or entities acting on their behalf) can send 226 notifications when those states change. 228 A typical flow of messages would be: 230 Subscriber Notifier 231 |-----SUBSCRIBE---->| Request state subscription 232 |<-------200--------| Acknowledge subscription 233 |<------NOTIFY----- | Return current state information 234 |--------200------->| 235 |<------NOTIFY----- | Return current state information 236 |--------200------->| 238 Subscriptions are expired and must be refreshed by subsequent 239 SUBSCRIBE requests. 241 1.2. Documentation Conventions 243 There are several paragraphs throughout this document which provide 244 motivational or clarifying text. Such passages are non-normative, 245 and are provided only to assist with reader comprehension. These 246 passages are set off from the remainder of the text by being indented 247 thus: 249 This is an example of non-normative explanatory text. It does not 250 form part of the specification, and is used only for 251 clarification. 253 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 254 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 255 document are to be interpreted as described in [RFC2119]. 257 In particular, implementors need to take careful note of the meaning 258 of "SHOULD" defined in RFC 2119. To rephrase: violation of SHOULD- 259 strength requirements requires careful analysis and clearly 260 enumerable reasons. It is inappropriate to fail to comply with 261 "SHOULD"-strength requirements whimsically or for ease of 262 implementation. 264 The use of quotation marks next to periods and commas follows the 265 convention used by the American Mathematical Society; although 266 contrary to traditional American English convention, this usage lends 267 clarity to certain passages. 269 2. Definitions 271 Event Package: An event package is an additional specification which 272 defines a set of state information to be reported by a notifier to 273 a subscriber. Event packages also define further syntax and 274 semantics based on the framework defined by this document required 275 to convey such state information. 277 Event Template-Package: An event template-package is a special kind 278 of event package which defines a set of states which may be 279 applied to all possible event packages, including itself. 281 Notification: Notification is the act of a notifier sending a NOTIFY 282 request to a subscriber to inform the subscriber of the state of a 283 resource. 285 Notifier: A notifier is a user agent which generates NOTIFY requests 286 for the purpose of notifying subscribers of the state of a 287 resource. Notifiers typically also accept SUBSCRIBE requests to 288 create subscriptions. 290 Subscriber: A subscriber is a user agent which receives NOTIFY 291 requests from notifiers; these NOTIFY requests contain information 292 about the state of a resource in which the subscriber is 293 interested. Subscribers typically also generate SUBSCRIBE 294 requests and send them to notifiers to create subscriptions. 296 Subscription: A subscription is a set of application state 297 associated with a dialog. This application state includes a 298 pointer to the associated dialog, the event package name, and 299 possibly an identification token. Event packages will define 300 additional subscription state information. By definition, 301 subscriptions exist in both a subscriber and a notifier. 303 Subscription Migration: Subscription migration is the act of moving 304 a subscription from one notifier to another notifier. 306 3. SIP Methods for Event Notification 308 3.1. SUBSCRIBE 310 The SUBSCRIBE method is used to request current state and state 311 updates from a remote node. SUBSCRIBE requests are target refresh 312 requests, as that term is defined in [RFC3261]. 314 3.1.1. Subscription Duration 316 SUBSCRIBE requests SHOULD contain an "Expires" header field (defined 317 in [RFC3261]). This expires value indicates the duration of the 318 subscription. In order to keep subscriptions effective beyond the 319 duration communicated in the "Expires" header field, subscribers need 320 to refresh subscriptions on a periodic basis using a new SUBSCRIBE 321 request on the same dialog as defined in [RFC3261]. 323 If no "Expires" header field is present in a SUBSCRIBE request, the 324 implied default MUST be defined by the event package being used. 326 200-class responses to SUBSCRIBE requests also MUST contain an 327 "Expires" header field. The period of time in the response MAY be 328 shorter but MUST NOT be longer than specified in the request. The 329 notifier is explicitly allowed to shorten the duration to zero. The 330 period of time in the response is the one which defines the duration 331 of the subscription. 333 An "expires" parameter on the "Contact" header field has no semantics 334 for the SUBSCRIBE method and is explicitly not equivalent to an 335 "Expires" header field in a SUBSCRIBE request or response. 337 A natural consequence of this scheme is that a SUBSCRIBE request with 338 an "Expires" of 0 constitutes a request to unsubscribe from an event. 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. This body will contain either the 429 state of the subscribed resource or a pointer to such state in the 430 form of a URI (see Section 5.4.13). 432 4. Node Behavior 434 4.1. Subscriber Behavior 436 4.1.1. Detecting Support for SIP Events 438 The extension described in this document does not make use of the use 439 of "Require" or "Proxy-Require" header fields; similarly, there is no 440 token defined for "Supported" header fields. Potential subscribers 441 may probe for the support of SIP Events using the OPTIONS request 442 defined in [RFC3261]. 444 The presence of "SUBSCRIBE" in the "Allow" header field of any 445 request or response indicates support for SIP Events; further, in the 446 absence of an "Allow" header field, the simple presence of an "Allow- 447 Events" header field is sufficient to indicate that the node that 448 sent the message is capable of acting as a notifier (see 449 Section 4.4.4. 451 The "methods" parameter for Contact may also be used to 452 specifically announce support for SUBSCRIBE and NOTIFY requests 453 when registering. (See [RFC3840] for details on the "methods" 454 parameter). 456 4.1.2. Creating and Maintaining Subscriptions 458 From the subscriber's perspective, a subscription proceeds according 459 to the following state diagram: 461 +-------------+ 462 | init |<-----------------------+ 463 +-------------+ | 464 | Retry-after 465 Send SUBSCRIBE expires 466 | | 467 V Timer N Fires; | 468 +-------------+ SUBSCRIBE failure | 469 +------------| notify_wait |-- response; --------+ | 470 | +-------------+ or NOTIFY, | | 471 | | state=terminated | | 472 | | | | 473 ++========|===================|============================|==|====++ 474 || | | V | || 475 || Receive NOTIFY, Receive NOTIFY, +-------------+ || 476 || state=active state=pending | terminated | || 477 || | | +-------------+ || 478 || | | Re-subscription A A || 479 || | V times out; | | || 480 || | +-------------+ Receive NOTIFY, | | || 481 || | | pending |-- state=terminated; --+ | || 482 || | +-------------+ or 481 response | || 483 || | | to SUBSCRIBE | || 484 || | Receive NOTIFY, refresh | || 485 || | state=active | || 486 || | | Re-subscription | || 487 || | V times out; | || 488 || | +-------------+ Receive NOTIFY, | || 489 || +----------->| active |-- state=terminated; -----+ || 490 || +-------------+ or 481 response || 491 || to SUBSCRIBE || 492 || Subscription refresh || 493 ++=================================================================++ 495 In the state diagram, "Re-subscription times out" means that an 496 attempt to refresh or update the subscription using a new SUBSCRIBE 497 request does not result in a NOTIFY request before the corresponding 498 Timer N expires. 500 Any transition from "notify_wait" into a "pending" or "active" state 501 results in a new subscription. Note that multiple subscriptions can 502 be generated as the result of a single SUBSCRIBE request (see 503 Section 4.4.1). Each of these new subscriptions exists in its own 504 independent state machine, and runs its own set of timers. 506 4.1.2.1. Requesting a Subscription 508 SUBSCRIBE is a dialog-creating method, as described in [RFC3261]. 510 When a subscriber wishes to subscribe to a particular state for a 511 resource, it forms a SUBSCRIBE request. If the initial SUBSCRIBE 512 request represents a request outside of a dialog (as it typically 513 will), its construction follows the procedures outlined in [RFC3261] 514 for UAC request generation outside of a dialog. 516 This SUBSCRIBE request will be confirmed with a final response. 200- 517 class responses indicate that the subscription has been accepted, and 518 that a NOTIFY request will be sent immediately. 520 The "Expires" header field in a 200-class response to SUBSCRIBE 521 request indicates the actual duration for which the subscription will 522 remain active (unless refreshed). 524 Non-200 class final responses indicate that no subscription or new 525 dialog usage has been created, and no subsequent NOTIFY request will 526 be sent. All non-200 class responses (with the exception of "489", 527 described herein) have the same meanings and handling as described in 528 [RFC3261]. For the sake of clarity: if a SUBSCRIBE request contains 529 an "Accept" header field, but that field does not indicate a MIME 530 type that the notifier is capable of generating in its NOTIFY 531 requests, then the proper error response is 406 (Not Acceptable). 533 4.1.2.2. Refreshing of Subscriptions 535 At any time before a subscription expires, the subscriber may refresh 536 the timer on such a subscription by sending another SUBSCRIBE request 537 on the same dialog as the existing subscription. The handling for 538 such a request is the same as for the initial creation of a 539 subscription except as described below. 541 If a SUBSCRIBE request to refresh a subscription receives a 404, 405, 542 410, 416, 480-485, 489, 501, or 604 response, the subscriber MUST 543 consider the subscription terminated. (See [RFC5057] for further 544 details and notes about the effect of error codes on dialogs and 545 usages within dialog, such as subscriptions). If the subscriber 546 wishes to re-subscribe to the state, he does so by composing an 547 unrelated initial SUBSCRIBE request with a freshly-generated Call-ID 548 and a new, unique "From" tag (see Section 4.1.2.1.) 550 If a SUBSCRIBE request to refresh a subscription fails with any error 551 code other than those listed above, the original subscription is 552 still considered valid for the duration of the most recently known 553 "Expires" value as negotiated by the most recent successful SUBSCRIBE 554 transaction, or as communicated by a NOTIFY request in its 555 "Subscription-State" header field "expires" parameter. 557 Note that many such errors indicate that there may be a problem 558 with the network or the notifier such that no further NOTIFY 559 requests will be received. 561 When refreshing a subscription, a subscriber starts Timer N, set to 562 64*T1, when it sends the SUBSCRIBE request. If this Timer N expires 563 prior to the receipt of a NOTIFY request, the subscriber considers 564 the subscription terminated. If the subscriber receives a success 565 response to the SUBSCRIBE request that indicates that no NOTIFY 566 request will be generated -- such as the 204 response defined for use 567 with the optional extension described in [RFC5839] -- then it MUST 568 cancel Timer N. 570 4.1.2.3. Unsubscribing 572 Unsubscribing is handled in the same way as refreshing of a 573 subscription, with the "Expires" header field set to "0". Note that 574 a successful unsubscription will also trigger a final NOTIFY request. 576 The final NOTIFY request may or may not contain information about the 577 state of the resource; subscribers need to be prepared to receive 578 final NOTIFY requests both with and without state. 580 4.1.2.4. Confirmation of Subscription Creation 582 The subscriber can expect to receive a NOTIFY request from each node 583 which has processed a successful subscription or subscription 584 refresh. To ensure that subscribers do not wait indefinitely for a 585 subscription to be established, a subscriber starts a Timer N, set to 586 64*T1, when it sends a SUBSCRIBE request. If this Timer N expires 587 prior to the receipt of a NOTIFY request, the subscriber considers 588 the subscription failed, and cleans up any state associated with the 589 subscription attempt. 591 Until Timer N expires, several NOTIFY requests may arrive from 592 different destinations (see Section 4.4.1). Each of these requests 593 establish a new dialog usage and a new subscription. After the 594 expiration of Timer N, the subscriber SHOULD reject any such NOTIFY 595 requests that would otherwise establish a new dialog usage with a 596 "481" response code. 598 Until the first NOTIFY request arrives, the subscriber should 599 consider the state of the subscribed resource to be in a neutral 600 state. Event package specifications MUST define this "neutral state" 601 in such a way that makes sense for their application (see 602 Section 5.4.7). 604 Due to the potential for both out-of-order messages and forking, the 605 subscriber MUST be prepared to receive NOTIFY requests before the 606 SUBSCRIBE transaction has completed. 608 Except as noted above, processing of this NOTIFY request is the same 609 as in Section 4.1.3. 611 4.1.3. Receiving and Processing State Information 613 Subscribers receive information about the state of a resource to 614 which they have subscribed in the form of NOTIFY requests. 616 Upon receiving a NOTIFY request, the subscriber should check that it 617 matches at least one of its outstanding subscriptions; if not, it 618 MUST return a "481 Subscription does not exist" response unless 619 another 400- or 500-class response is more appropriate. The rules 620 for matching NOTIFY requests with subscriptions that create a new 621 dialog usage are described in Section 4.4.1. Notifications for 622 subscriptions which were created inside an existing dialog match if 623 they are in the same dialog and the "Event" header fields match (as 624 described in Section 8.2.1). 626 If, for some reason, the event package designated in the "Event" 627 header field of the NOTIFY request is not supported, the subscriber 628 will respond with a "489 Bad Event" response. 630 To prevent spoofing of events, NOTIFY requests SHOULD be 631 authenticated, using any defined SIP authentication mechanism. 633 NOTIFY requests MUST contain "Subscription-State" header fields which 634 indicate the status of the subscription. 636 If the "Subscription-State" header field value is "active", it means 637 that the subscription has been accepted and (in general) has been 638 authorized. If the header field also contains an "expires" 639 parameter, the subscriber SHOULD take it as the authoritative 640 subscription duration and adjust accordingly. The "retry-after" and 641 "reason" parameters have no semantics for "active". 643 If the "Subscription-State" value is "pending", the subscription has 644 been received by the notifier, but there is insufficient policy 645 information to grant or deny the subscription yet. If the header 646 field also contains an "expires" parameter, the subscriber SHOULD 647 take it as the authoritative subscription duration and adjust 648 accordingly. No further action is necessary on the part of the 649 subscriber. The "retry-after" and "reason" parameters have no 650 semantics for "pending". 652 If the "Subscription-State" value is "terminated", the subscriber 653 MUST consider the subscription terminated. The "expires" parameter 654 has no semantics for "terminated" -- notifiers SHOULD NOT include an 655 "expires" parameter on a "Subscription-State" header field with a 656 value of "terminated," and subscribers MUST ignore any such 657 parameter, if present. If a reason code is present, the client 658 should behave as described below. If no reason code or an unknown 659 reason code is present, the client MAY attempt to re-subscribe at any 660 time (unless a "retry-after" parameter is present, in which case the 661 client SHOULD NOT attempt re-subscription until after the number of 662 seconds specified by the "retry-after" parameter). The reason codes 663 defined by this document are: 665 deactivated: The subscription has been terminated, but the 666 subscriber SHOULD retry immediately with a new subscription. One 667 primary use of such a status code is to allow migration of 668 subscriptions between nodes. The "retry-after" parameter has no 669 semantics for "deactivated". 671 probation: The subscription has been terminated, but the client 672 SHOULD retry at some later time. If a "retry-after" parameter is 673 also present, the client SHOULD wait at least the number of 674 seconds specified by that parameter before attempting to re- 675 subscribe. 677 rejected: The subscription has been terminated due to change in 678 authorization policy. Clients SHOULD NOT attempt to re-subscribe. 679 The "retry-after" parameter has no semantics for "rejected". 681 timeout: The subscription has been terminated because it was not 682 refreshed before it expired. Clients MAY re-subscribe 683 immediately. The "retry-after" parameter has no semantics for 684 "timeout". This reason code is also associated with polling of 685 resource state, as detailed in Section 4.4.3 687 giveup: The subscription has been terminated because the notifier 688 could not obtain authorization in a timely fashion. If a "retry- 689 after" parameter is also present, the client SHOULD wait at least 690 the number of seconds specified by that parameter before 691 attempting to re-subscribe; otherwise, the client MAY retry 692 immediately, but will likely get put back into pending state. 694 noresource: The subscription has been terminated because the 695 resource state which was being monitored no longer exists. 696 Clients SHOULD NOT attempt to re-subscribe. The "retry-after" 697 parameter has no semantics for "noresource". 699 invariant: The subscription has been terminated because the resource 700 state is guaranteed not to change for the foreseeable future. 701 This may be the case, for example, when subscribing to the 702 location information of a fixed-location land-line telephone. 703 When using this reason code, notifiers are advised to include a 704 "retry-after" parameter with a large value (for example, 31536000 705 -- or one year) to prevent older, RFC 3265-compliant clients from 706 periodically resubscribing. Clients SHOULD NOT attempt to 707 resubscribe after receiving a reason code of "invariant," 708 regardless of the presence of or value of a "retry-after" 709 parameter. 711 Other specifications may define new reason codes for use with the 712 "Subscription-State" header field. 714 Once the notification is deemed acceptable to the subscriber, the 715 subscriber SHOULD return a 200 response. In general, it is not 716 expected that NOTIFY responses will contain bodies; however, they 717 MAY, if the NOTIFY request contained an "Accept" header field. 719 Other responses defined in [RFC3261] may also be returned, as 720 appropriate. In no case should a NOTIFY transaction extend for any 721 longer than the time necessary for automated processing. In 722 particular, subscribers MUST NOT wait for a user response before 723 returning a final response to a NOTIFY request. 725 4.1.4. Forking of SUBSCRIBE Requests 727 In accordance with the rules for proxying non-INVITE requests as 728 defined in [RFC3261], successful SUBSCRIBE requests will receive only 729 one 200-class response; however, due to forking, the subscription may 730 have been accepted by multiple nodes. The subscriber MUST therefore 731 be prepared to receive NOTIFY requests with "From:" tags which differ 732 from the "To:" tag received in the SUBSCRIBE 200-class response. 734 If multiple NOTIFY requests are received in different dialogs in 735 response to a single SUBSCRIBE request, each dialog represents a 736 different destination to which the SUBSCRIBE request was forked. 737 Subscriber handling in such situations varies by event package; see 738 Section 5.4.9 for details. 740 4.2. Notifier Behavior 742 4.2.1. Subscription Establishment and Maintenance 744 Notifiers learn about subscription requests by receiving SUBSCRIBE 745 requests from interested parties. Notifiers MUST NOT create 746 subscriptions except upon receipt of a SUBSCRIBE request. However, 747 for historical reasons, the implicit creation of subscriptions as 748 defined in [RFC3515] is still permitted. 750 [RFC3265] allowed the creation of subscriptions using means other 751 than the SUBSCRIBE method. The only standardized use of this 752 mechanism is the REFER method [RFC3515]. Implementation 753 experience with REFER has shown that the implicit creation of a 754 subscription has a number of undesirable effects, such as the 755 inability to signal the success of a REFER request while signaling 756 a problem with the subscription; and difficulty performing one 757 action without the other. Additionally, the proper exchange of 758 dialog identifiers is difficult without dialog re-use (which has 759 its own set of problems; see Section 4.5). 761 4.2.1.1. Initial SUBSCRIBE Transaction Processing 763 In no case should a SUBSCRIBE transaction extend for any longer than 764 the time necessary for automated processing. In particular, 765 notifiers MUST NOT wait for a user response before returning a final 766 response to a SUBSCRIBE request. 768 This requirement is imposed primarily to prevent the non-INVITE 769 transaction timeout timer F (see [RFC3261]) from firing during the 770 SUBSCRIBE transaction, since interaction with a user would often 771 exceed 64*T1 seconds. 773 The notifier SHOULD check that the event package specified in the 774 "Event" header field is understood. If not, the notifier SHOULD 775 return a "489 Bad Event" response to indicate that the specified 776 event/event class is not understood. 778 The notifier SHOULD also perform any necessary authentication and 779 authorization per its local policy. See Section 4.2.1.3. 781 The notifier MAY also check that the duration in the "Expires" header 782 field is not too small. If and only if the expiration interval is 783 greater than zero AND smaller than one hour AND less than a notifier- 784 configured minimum, the notifier MAY return a "423 Interval Too 785 Brief" error which contains a "Min-Expires" header field field. The 786 "Min-Expires" header field is described in [RFC3261]. 788 Once the notifier determines that it has enough information to create 789 the subscription (i.e., it understands the event package, the 790 subscription pertains to a known resource, and there are no other 791 barriers to creating the subscription), it creates the subscription 792 and a dialog usage, and returns a 200 (OK) response. 794 When a subscription is created in the notifier, it stores the event 795 package name as part of the subscription information. 797 The "Expires" values present in SUBSCRIBE 200-class responses behave 798 in the same way as they do in REGISTER responses: the server MAY 799 shorten the interval, but MUST NOT lengthen it. 801 If the duration specified in a SUBSCRIBE request is unacceptably 802 short, the notifier may be able to send a 423 response, as 803 described earlier in this section. 805 200-class responses to SUBSCRIBE requests will not generally contain 806 any useful information beyond subscription duration; their primary 807 purpose is to serve as a reliability mechanism. State information 808 will be communicated via a subsequent NOTIFY request from the 809 notifier. 811 The other response codes defined in [RFC3261] may be used in response 812 to SUBSCRIBE requests, as appropriate. 814 4.2.1.2. Confirmation of Subscription Creation/Refreshing 816 Upon successfully accepting or refreshing a subscription, notifiers 817 MUST send a NOTIFY request immediately to communicate the current 818 resource state to the subscriber. This NOTIFY request is sent on the 819 same dialog as created by the SUBSCRIBE response. If the resource 820 has no meaningful state at the time that the SUBSCRIBE request is 821 processed, this NOTIFY request MAY contain an empty or neutral body. 822 See Section 4.2.2 for further details on NOTIFY request generation. 824 Note that a NOTIFY request is always sent immediately after any 200- 825 class response to a SUBSCRIBE request, regardless of whether the 826 subscription has already been authorized. 828 4.2.1.3. Authentication/Authorization of SUBSCRIBE Requests 830 Privacy concerns may require that notifiers apply policy to determine 831 whether a particular subscriber is authorized to subscribe to a 832 certain set of events. Such policy may be defined by mechanisms such 833 as access control lists or real-time interaction with a user. In 834 general, authorization of subscribers prior to authentication is not 835 particularly useful. 837 SIP authentication mechanisms are discussed in [RFC3261]. Note that, 838 even if the notifier node typically acts as a proxy, authentication 839 for SUBSCRIBE requests will always be performed via a "401" response, 840 not a "407;" notifiers always act as a user agents when accepting 841 subscriptions and sending notifications. 843 Of course, when acting as a proxy, a node will perform normal 844 proxy authentication (using 407). The foregoing explanation is a 845 reminder that notifiers are always UAs, and as such perform UA 846 authentication. 848 If authorization fails based on an access list or some other 849 automated mechanism (i.e., it can be automatically authoritatively 850 determined that the subscriber is not authorized to subscribe), the 851 notifier SHOULD reply to the request with a "403 Forbidden" or "603 852 Decline" response, unless doing so might reveal information that 853 should stay private; see Section 6.2. 855 If the notifier owner is interactively queried to determine whether a 856 subscription is allowed, a 200 (OK) response is returned immediately. 857 Note that a NOTIFY request is still formed and sent under these 858 circumstances, as described in the previous section. 860 If subscription authorization was delayed and the notifier wishes to 861 convey that such authorization has been declined, it may do so by 862 sending a NOTIFY request containing a "Subscription-State" header 863 field with a value of "terminated" and a reason parameter of 864 "rejected". 866 4.2.1.4. Refreshing of Subscriptions 868 When a notifier receives a subscription refresh, assuming that the 869 subscriber is still authorized, the notifier updates the expiration 870 time for subscription. As with the initial subscription, the server 871 MAY shorten the amount of time until expiration, but MUST NOT 872 increase it. The final expiration time is placed in the "Expires" 873 header field in the response. If the duration specified in a 874 SUBSCRIBE request is unacceptably short, the notifier SHOULD respond 875 with a "423 Interval Too Brief" response. 877 If no refresh for a notification address is received before its 878 expiration time, the subscription is removed. When removing a 879 subscription, the notifier SHOULD send a NOTIFY request with a 880 "Subscription-State" value of "terminated" to inform it that the 881 subscription is being removed. If such a request is sent, the 882 "Subscription-State" header field SHOULD contain a "reason=timeout" 883 parameter. 885 Clients can cause a subscription to be terminated immediately by 886 sending a SUBSCRIBE request with an "Expires" header field set to 887 '0'. Notifiers largely treat this the same way as any other 888 subscription expiration: they send a NOTIFY request containing a 889 "Subscription-State" of "terminated", with a reason code of 890 "timeout." For consistency with state polling (see Section 4.4.3) 891 and subscription refreshes, the notifier may choose to include 892 resource state in this final NOTIFY request. However, in some cases, 893 including such state makes no sense. Under such circumstances, the 894 notifier may choose to omit state information from the terminal 895 NOTIFY request. 897 The sending of a NOTIFY request when a subscription expires allows 898 the corresponding dialog usage to be terminated, if appropriate. 900 4.2.2. Sending State Information to Subscribers 902 Notifiers use the NOTIFY method to send information about the state 903 of a resource to subscribers. The notifier's view of a subscription 904 is shown in the following state diagram: 906 +-------------+ 907 | init | 908 +-------------+ 909 | 910 Receive SUBSCRIBE, 911 Send NOTIFY 912 | 913 V NOTIFY failure, 914 +-------------+ subscription expires, 915 +------------| resp_wait |-- or terminated ----+ 916 | +-------------+ per local policy | 917 | | | 918 | | | 919 | | V 920 Policy grants Policy needed +-------------+ 921 permission | | terminated | 922 | | +-------------+ 923 | | A A 924 | V NOTIFY failure, | | 925 | +-------------+ subscription expires,| | 926 | | pending |-- or terminated -------+ | 927 | +-------------+ per local policy | 928 | | | 929 | Policy changed to | 930 | grant permission | 931 | | | 932 | V NOTIFY failure, | 933 | +-------------+ subscription expires, | 934 +----------->| active |-- or terminated ---------+ 935 +-------------+ per local policy 937 When a SUBSCRIBE request is answered with a 200-class response, the 938 notifier MUST immediately construct and send a NOTIFY request to the 939 subscriber. When a change in the subscribed state occurs, the 940 notifier SHOULD immediately construct and send a NOTIFY request, 941 subject to authorization, local policy, and throttling 942 considerations. 944 If the NOTIFY request fails due to expiration of SIP Timer F 945 (transaction timeout), the notifier SHOULD remove the subscription. 947 This behavior prevents unnecessary transmission of state 948 information for subscribers who have crashed or disappeared from 949 the network. Because such transmissions will be sent multiple 950 times, per the retransmission algorithm defined in [RFC3261] 951 (instead of the typical single transmission for functioning 952 clients), continuing to service them when no client is available 953 to acknowledge them could place undue strain on a network. Upon 954 client restart or reestablishment of a network connection, it is 955 expected that clients will send SUBSCRIBE requests to refresh 956 potentially stale state information; such requests will re-install 957 subscriptions in all relevant nodes. 959 If the NOTIFY transaction fails due to the receipt of a 404, 405, 960 410, 416, 480-485, 489, 501, or 604 response to the NOTIFY request, 961 the notifier MUST remove the corresponding subscription. See 962 [RFC5057] for further details and notes about the effect of error 963 codes on dialogs and usages within dialog (such as subscriptions). 965 A notify error response would generally indicate that something 966 has gone wrong with the subscriber or with some proxy on the way 967 to the subscriber. If the subscriber is in error, it makes the 968 most sense to allow the subscriber to rectify the situation (by 969 re-subscribing) once the error condition has been handled. If a 970 proxy is in error, the periodic sending of SUBSCRIBE requests to 971 refresh the expiration timer will re-install subscription state 972 once the network problem has been resolved. 974 NOTIFY requests MUST contain a "Subscription-State" header field with 975 a value of "active", "pending", or "terminated". The "active" value 976 indicates that the subscription has been accepted and has been 977 authorized (in most cases; see Section 6.2). The "pending" value 978 indicates that the subscription has been received, but that policy 979 information is insufficient to accept or deny the subscription at 980 this time. The "terminated" value indicates that the subscription is 981 not active. 983 If the value of the "Subscription-State" header field is "active" or 984 "pending", the notifier MUST also include in the "Subscription-State" 985 header field an "expires" parameter which indicates the time 986 remaining on the subscription. The notifier MAY use this mechanism 987 to shorten a subscription; however, this mechanism MUST NOT be used 988 to lengthen a subscription. 990 Including expiration information for active and pending 991 subscriptions is necessary in case the SUBSCRIBE request forks, 992 since the response to a forked SUBSCRIBE request may not be 993 received by the subscriber. [RFC3265] allowed the notifier some 994 discretion in the inclusion of this parameter, so subscriber 995 implementations are warned to handle the lack of an "expires" 996 parameter gracefully. Note well that this "expires" value is a 997 parameter on the "Subscription-State" header field, NOT an 998 "Expires" header field. 1000 The period of time for a subscription can be shortened to zero by 1001 the notifier. In other words, it is perfectly valid for a 1002 SUBSCRIBE request with a non-zero expires to be answered with a 1003 NOTIFY request that contains "Subscription-Status: 1004 terminated;reason=expired". This merely means that the notifier 1005 has shortened the subscription timeout to zero, and the 1006 subscription has expired instantaneously. The body may contain 1007 valid state, or it may contain a neutral state (see 1008 Section 5.4.7). 1010 If the value of the "Subscription-State" header field is 1011 "terminated", the notifier SHOULD also include a "reason" parameter. 1012 The notifier MAY also include a "retry-after" parameter, where 1013 appropriate. For details on the value and semantics of the "reason" 1014 and "retry-after" parameters, see Section 4.1.3. 1016 4.2.3. PINT Compatibility 1018 The "Event" header field is considered mandatory for the purposes of 1019 this document. However, to maintain compatibility with PINT (see 1020 [RFC2848]), notifiers MAY interpret a SUBSCRIBE request with no 1021 "Event" header field as requesting a subscription to PINT events. If 1022 a notifier does not support PINT, it SHOULD return "489 Bad Event" to 1023 any SUBSCRIBE requests without an "Event" header field. 1025 4.3. Proxy Behavior 1027 Proxies need no additional behavior beyond that described in 1028 [RFC3261] to support SUBSCRIBE and NOTIFY transactions. If a proxy 1029 wishes to see all of the SUBSCRIBE and NOTIFY requests for a given 1030 dialog, it MUST add a Record-Route header field to the initial 1031 SUBSCRIBE request and all NOTIFY requests. It MAY choose to include 1032 Record-Route in subsequent SUBSCRIBE requests; however, these 1033 requests cannot cause the dialog's route set to be modified. 1035 Proxies that did not add a Record-Route header field to the initial 1036 SUBSCRIBE request MUST NOT add a Record-Route header field to any of 1037 the associated NOTIFY requests. 1039 Note that subscribers and notifiers may elect to use S/MIME 1040 encryption of SUBSCRIBE and NOTIFY requests; consequently, proxies 1041 cannot rely on being able to access any information that is not 1042 explicitly required to be proxy-readable by [RFC3261]. 1044 4.4. Common Behavior 1045 4.4.1. Dialog Creation and Termination 1047 Dialogs usages are created upon completion of a NOTIFY transaction 1048 for a new subscription, unless the NOTIFY request contains a 1049 "Subscription-State" of "terminated." 1051 Because the dialog usage is established by the NOTIFY request, the 1052 route set at the subscriber is taken from the NOTIFY request itself, 1053 as opposed to the route set present in the 200-class response to the 1054 SUBSCRIBE request. 1056 NOTIFY requests are matched to such SUBSCRIBE requests if they 1057 contain the same "Call-ID", a "To" header field "tag" parameter which 1058 matches the "From" header field "tag" parameter of the SUBSCRIBE 1059 request, and the same "Event" header field. Rules for comparisons of 1060 the "Event" header fields are described in Section 8.2.1. 1062 A subscription is destroyed after a notifier sends a NOTIFY request 1063 with a "Subscription-State" of "terminated," or in certain error 1064 situations described elsewhere in this document. The subscriber will 1065 generally answer such final requests with a "200 OK" response (unless 1066 a condition warranting an alternate response has arisen). Except 1067 when the mechanism described in Section 4.5.2 is used, the 1068 destruction of a subscription results in the termination of its 1069 associated dialog. 1071 A subscriber may send a SUBSCRIBE request with an "Expires" header 1072 field of 0 in order to trigger the sending of such a NOTIFY 1073 request; however, for the purposes of subscription and dialog 1074 lifetime, the subscription is not considered terminated until the 1075 NOTIFY transaction with a "Subscription-State" of "terminated" 1076 completes. 1078 4.4.2. Notifier Migration 1080 It is often useful to allow migration of subscriptions between 1081 notifiers. Such migration may be effected by sending a NOTIFY 1082 request with a "Subscription-State" header field of "terminated", and 1083 a reason parameter of "deactivated". This NOTIFY request is 1084 otherwise normal, and is formed as described in Section 4.2.2. 1086 Upon receipt of this NOTIFY request, the subscriber SHOULD attempt to 1087 re-subscribe (as described in the preceding sections). Note that 1088 this subscription is established on a new dialog, and does not re-use 1089 the route set from the previous subscription dialog. 1091 The actual migration is effected by making a change to the policy 1092 (such as routing decisions) of one or more servers to which the 1093 SUBSCRIBE request will be sent in such a way that a different node 1094 ends up responding to the SUBSCRIBE request. This may be as simple 1095 as a change in the local policy in the notifier from which the 1096 subscription is migrating so that it serves as a proxy or redirect 1097 server instead of a notifier. 1099 Whether, when, and why to perform notifier migrations may be 1100 described in individual event packages; otherwise, such decisions are 1101 a matter of local notifier policy, and are left up to individual 1102 implementations. 1104 4.4.3. Polling Resource State 1106 A natural consequence of the behavior described in the preceding 1107 sections is that an immediate fetch without a persistent subscription 1108 may be effected by sending a SUBSCRIBE with an "Expires" of 0. 1110 Of course, an immediate fetch while a subscription is active may be 1111 effected by sending a SUBSCRIBE request with an "Expires" equal to 1112 the number of seconds remaining in the subscription. 1114 Upon receipt of this SUBSCRIBE request, the notifier (or notifiers, 1115 if the SUBSCRIBE request was forked) will send a NOTIFY request 1116 containing resource state in the same dialog. 1118 Note that the NOTIFY requests triggered by SUBSCRIBE requests with 1119 "Expires" header fields of 0 will contain a "Subscription-State" 1120 value of "terminated", and a "reason" parameter of "timeout". 1122 Polling of event state can cause significant increases in load on the 1123 network and notifiers; as such, it should be used only sparingly. In 1124 particular, polling SHOULD NOT be used in circumstances in which it 1125 will typically result in more network messages than long-running 1126 subscriptions. 1128 When polling is used, subscribers SHOULD attempt to cache 1129 authentication credentials between polls so as to reduce the number 1130 of messages sent. 1132 Due to the requirement on notifiers to send a NOTIFY request 1133 immediately upon receipt of a SUBSCRIBE request, the state 1134 provided by polling is limited to the information that the 1135 notifier has immediate local access to when it receives the 1136 SUBSCRIBE request. If, for example, the notifier generally needs 1137 to retrieve state from another network server, then that state 1138 will be absent from the NOTIFY request that results from polling. 1140 4.4.4. Allow-Events header field usage 1142 The "Allow-Events" header field, if present, includes a list of 1143 tokens which indicates the event packages supported by a notifier. 1144 In other words, a user agent sending an "Allow-Events" header field 1145 is advertising that it can process SUBSCRIBE requests and generate 1146 NOTIFY requests for all of the event packages listed in that header 1147 field. 1149 Any user agent that can act as a notifier for one or more event 1150 packages SHOULD include an appropriate "Allow-Events" header field 1151 indicating all supported events in all methods which initiate dialogs 1152 and their responses (such as INVITE) and OPTIONS responses. 1154 This information is very useful, for example, in allowing user 1155 agents to render particular interface elements appropriately 1156 according to whether the events required to implement the features 1157 they represent are supported by the appropriate nodes. 1158 On the other hand, it doesn't necessarily make much sense to 1159 indicate supported events inside a dialog established by a NOTIFY 1160 request if the only event package supported is the one associated 1161 with that subscription. 1163 Note that "Allow-Events" header fields MUST NOT be inserted by 1164 proxies. 1166 The "Allow-Events" header field does not include a list of the event 1167 template packages supported by an implementation. If a subscriber 1168 wishes to determine which event template packages are supported by a 1169 notifier, it can probe for such support by attempting to subscribe to 1170 the event template packages it wishes to use. 1172 4.5. Targeting Subscriptions at Devices 1174 [RFC3265] defined a mechanism by which subscriptions could share 1175 dialogs with invite usages and with other subscriptions. The purpose 1176 of this behavior was to allow subscribers to ensure that a 1177 subscription arrived at the same device as an established dialog. 1178 Unfortunately, the re-use of dialogs has proven to be exceedingly 1179 confusing. [RFC5057] attempted to clarify proper behavior in a 1180 variety of circumstances; however, the ensuing rules remain confusing 1181 and prone to implementation error. At the same time, the mechanism 1182 described in [RFC5627] now provides a far more elegant and 1183 unambiguous means to achieve the same goal. 1185 Consequently, the dialog re-use technique described in RFC 3265 is 1186 now deprecated. 1188 This dialog-sharing technique has also historically been used as a 1189 means for targeting an event package at a dialog. This usage can be 1190 seen, for example, in certain applications of the REFER method 1191 [RFC3515]. With the removal of dialog re-use, an alternate (and more 1192 explicit) means of targeting dialogs needs to be used for this type 1193 of correlation. The appropriate means of such targeting is left up 1194 to the actual event packages. Candidates include the "Target-Dialog" 1195 header field [RFC4538], the "Join" header field [RFC3911], and the 1196 "Replaces" header field [RFC3891], depending on the semantics 1197 desired. Alternately, if the semantics of those header fields do not 1198 match the event package's purpose for correlation, event packages can 1199 devise their own means of identifying dialogs. For an example of 1200 this approach, see the Dialog Event Package [RFC4235]. 1202 4.5.1. Using GRUUs to Route to Devices 1204 Notifiers MUST implement the Globally Routable User-Agent URI (GRUU) 1205 extension defined in [RFC5627], and MUST use a GRUU as their local 1206 target. This allows subscribers to explicitly target desired 1207 devices. 1209 If a subscriber wishes to subscribe to a resource on the same device 1210 as an established dialog, it should check whether the remote contact 1211 in that dialog is a GRUU (i.e., whether it contains a "gr" URI 1212 parameter). If so, the subscriber creates a new dialog, using the 1213 GRUU as the request URI for the new SUBSCRIBE request. 1215 Because GRUUs are guaranteed to route to a a specific device, this 1216 ensures that the subscription will be routed to the same place as 1217 the established dialog. 1219 4.5.2. Sharing Dialogs 1221 For compatibility with older clients, subscriber and notifier 1222 implementations may choose to allow dialog sharing. The behavior of 1223 multiple usages within a dialog are described in [RFC5057]. 1225 Subscribers MUST NOT attempt to re-use dialogs whose remote target is 1226 a GRUU. 1228 Note that the techniques described in this section are included 1229 for backwards compatibility purposes only. Because subscribers 1230 cannot re-use dialogs with a GRUU for their remote target, and 1231 because notifiers must use GRUUs as their local target, any two 1232 implementations that conform to this specification will 1233 automatically use the mechanism described in Section 4.5.1. 1235 If a subscriber wishes to subscribe to a resource on the same device 1236 as an established dialog and the remote contact is not a GRUU, it MAY 1237 revert to dialog sharing behavior. Alternately, it MAY choose to 1238 treat the remote party as incapable of servicing the subscription 1239 (i.e., the same way it would behave if the remote party did not 1240 support SIP events at all). 1242 If a notifier receives a SUBSCRIBE request for a new subscription on 1243 an existing dialog, it MAY choose to implement dialog sharing 1244 behavior. Alternately, it may choose to fail the SUBSCRIBE request 1245 with a 403 response. The error text of such 403 responses SHOULD 1246 indicate that dialog sharing is not supported. 1248 To implement dialog sharing, subscribers and notifiers perform the 1249 following additional processing: 1251 o When subscriptions exist in dialogs associated with INVITE-created 1252 application state and/or other subscriptions, these sets of 1253 application state do not interact beyond the behavior described 1254 for a dialog (e.g., route set handling). In particular, multiple 1255 subscriptions within a dialog are expire independently, and 1256 require independent subscription refreshes. 1258 o If a subscription's destruction leaves no other application state 1259 associated with the dialog, the dialog terminates. The 1260 destruction of other application state (such as that created by an 1261 INVITE) will not terminate the dialog if a subscription is still 1262 associated with that dialog. This means that, when dialog are re- 1263 used, then a dialog created with an INVITE does not necessarily 1264 terminate upon receipt of a BYE. Similarly, in the case that 1265 several subscriptions are associated with a single dialog, the 1266 dialog does not terminate until all the subscriptions in it are 1267 destroyed. 1269 o Subscribers MAY include an "id" parameter in SUBSCRIBE request 1270 "Event" header field to allow differentiation between multiple 1271 subscriptions in the same dialog. This "id" parameter, if 1272 present, contains an opaque token which identifies the specific 1273 subscription within a dialog. An "id" parameter is only valid 1274 within the scope of a single dialog. 1276 o If an "id" parameter is present in the SUBSCRIBE request used to 1277 establish a subscription, that "id" parameter MUST also be present 1278 in all corresponding NOTIFY requests. 1280 o When a subscriber refreshes a the subscription timer, the 1281 SUBSCRIBE request MUST contain the same "Event" header field "id" 1282 parameter as was present in the SUBSCRIBE request that created the 1283 subscription. (Otherwise, the notifier will interpret the 1284 SUBSCRIBE request as a request for a new subscription in the same 1285 dialog). 1287 o When a subscription is created in the notifier, it stores any 1288 "Event" header field "id" parameter as part of the subscription 1289 information (along with the event package name). 1291 o If an initial SUBSCRIBE request is sent on a pre-existing dialog, 1292 a matching NOTIFY request merely creates a new subscription 1293 associated with that dialog. 1295 4.6. CANCEL Requests for SUBSCRIBE and NOTIFY Transactions 1297 Neither SUBSCRIBE nor NOTIFY requests can be canceled. If a UAS 1298 receives a CANCEL request that matches a known SUBSCRIBE or NOTIFY 1299 transaction, it MUST respond to the CANCEL request, but otherwise 1300 ignore it. In particular, the CANCEL request MUST NOT affect 1301 processing of the SUBSCRIBE or NOTIFY request in any way. 1303 UACs SHOULD NOT send CANCEL requests for SUBSCRIBE or NOTIFY 1304 transactions. 1306 5. Event Packages 1308 This section covers several issues which should be taken into 1309 consideration when event packages based on the SUBSCRIBE and NOTIFY 1310 methods are proposed. Event package definitions contain sections 1311 addressing each of these issues, ideally in the same order and with 1312 the same titles as the following sections. 1314 5.1. Appropriateness of Usage 1316 When designing an event package using the methods described in this 1317 document for event notification, it is important to consider: is SIP 1318 an appropriate mechanism for the problem set? Is SIP being selected 1319 because of some unique feature provided by the protocol (e.g., user 1320 mobility), or merely because "it can be done?" If you find yourself 1321 defining event packages for notifications related to, for example, 1322 network management or the temperature inside your car's engine, you 1323 may want to reconsider your selection of protocols. 1325 Those interested in extending the mechanism defined in this 1326 document are urged to follow the development of "Guidelines for 1327 Authors of SIP Extensions" [RFC4485] for further guidance 1328 regarding appropriate uses of SIP. 1330 Further, it is expected that this mechanism is not to be used in 1331 applications where the frequency of reportable events is excessively 1332 rapid (e.g., more than about once per second). A SIP network is 1333 generally going to be provisioned for a reasonable signaling volume; 1334 sending a notification every time a user's GPS position changes by 1335 one hundredth of a second could easily overload such a network. 1337 5.2. Event Template-packages 1339 Normal event packages define a set of state applied to a specific 1340 type of resource, such as user presence, call state, and messaging 1341 mailbox state. 1343 Event template-packages are a special type of package which define a 1344 set of state applied to other packages, such as statistics, access 1345 policy, and subscriber lists. Event template-packages may even be 1346 applied to other event template-packages. 1348 To extend the object-oriented analogy made earlier, event template- 1349 packages can be thought of as templatized C++ packages which must be 1350 applied to other packages to be useful. 1352 The name of an event template-package as applied to a package is 1353 formed by appending a period followed by the event template-package 1354 name to the end of the package. For example, if a template-package 1355 called "winfo" were being applied to a package called "presence", the 1356 event token used in "Event" and "Allow-Events" would be 1357 "presence.winfo". 1359 Event template-packages must be defined so that they can be applied 1360 to any arbitrary package. In other words, event template-packages 1361 cannot be specifically tied to one or a few "parent" packages in such 1362 a way that they will not work with other packages. 1364 5.3. Amount of State to be Conveyed 1366 When designing event packages, it is important to consider the type 1367 of information which will be conveyed during a notification. 1369 A natural temptation is to convey merely the event (e.g., "a new 1370 voice message just arrived") without accompanying state (e.g., "7 1371 total voice messages"). This complicates implementation of 1372 subscribing entities (since they have to maintain complete state for 1373 the entity to which they have subscribed), and also is particularly 1374 susceptible to synchronization problems. 1376 There are two possible solutions to this problem that event packages 1377 may choose to implement. 1379 5.3.1. Complete State Information 1381 In general, event packages need to be able to convey a well-defined 1382 and complete state, rather than just a stream of events. If it is 1383 not possible to describe complete system state for transmission in 1384 NOTIFY requests, then the problem set is not a good candidate for an 1385 event package. 1387 For packages which typically convey state information that is 1388 reasonably small (on the order of 1 KB or so), it is suggested that 1389 event packages are designed so as to send complete state information 1390 whenever an event occurs. 1392 In some circumstances, conveying the current state alone may be 1393 insufficient for a particular class of events. In these cases, the 1394 event packages should include complete state information along with 1395 the event that occurred. For example, conveying "no customer service 1396 representatives available" may not be as useful as conveying "no 1397 customer service representatives available; representative 1398 sip:46@cs.xyz.int just logged off". 1400 5.3.2. State Deltas 1402 In the case that the state information to be conveyed is large, the 1403 event package may choose to detail a scheme by which NOTIFY requests 1404 contain state deltas instead of complete state. 1406 Such a scheme would work as follows: any NOTIFY request sent in 1407 immediate response to a SUBSCRIBE request contains full state 1408 information. NOTIFY requests sent because of a state change will 1409 contain only the state information that has changed; the subscriber 1410 will then merge this information into its current knowledge about the 1411 state of the resource. 1413 Any event package that supports delta changes to states MUST include 1414 a version number that increases by exactly one for each NOTIFY 1415 transaction in a subscription. Note that the state version number 1416 appears in the body of the message, not in a SIP header field. 1418 If a NOTIFY request arrives that has a version number that is 1419 incremented by more than one, the subscriber knows that a state delta 1420 has been missed; it ignores the NOTIFY request containing the state 1421 delta (except for the version number, which it retains to detect 1422 message loss), and re-sends a SUBSCRIBE request to force a NOTIFY 1423 request containing a complete state snapshot. 1425 5.4. Event Package Responsibilities 1427 Event packages are not required to reiterate any of the behavior 1428 described in this document, although they may choose to do so for 1429 clarity or emphasis. In general, though, such packages are expected 1430 to describe only the behavior that extends or modifies the behavior 1431 described in this document. 1433 Note that any behavior designated with "SHOULD" or "MUST" in this 1434 document is not allowed to be weakened by extension documents; 1435 however, such documents may elect to strengthen "SHOULD" requirements 1436 to "MUST" strength if required by their application. 1438 In addition to the normal sections expected in standards-track 1439 RFCs and SIP extension documents, authors of event packages need 1440 to address each of the issues detailed in the following 1441 subsections, whenever applicable. 1443 5.4.1. Event Package Name 1445 This section, which MUST be present, defines the token name to be 1446 used to designate the event package. It MUST include the information 1447 which appears in the IANA registration of the token. For information 1448 on registering such types, see Section 7. 1450 5.4.2. Event Package Parameters 1452 If parameters are to be used on the "Event" header field to modify 1453 the behavior of the event package, the syntax and semantics of such 1454 header fields MUST be clearly defined. 1456 Any "Event" header field parameters defined by an event package MUST 1457 be registered in the "Header Field Parameters and Parameter Values" 1458 registry defined by [RFC3968]. An "Event" header field parameter, 1459 once registered in conjunction with an event package, MUST NOT be re- 1460 used with any other event package. Non-event-package specifications 1461 MAY define "Event" header field parameters that apply across all 1462 event packages (with emphasis on "all", as opposed to "several"), 1463 such as the "id" parameter defined in this document. The restriction 1464 of a parameter to use with a single event package only applies to 1465 parameters that are defined in conjunction with an event package. 1467 5.4.3. SUBSCRIBE Request Bodies 1469 It is expected that most, but not all, event packages will define 1470 syntax and semantics for SUBSCRIBE request bodies; these bodies will 1471 typically modify, expand, filter, throttle, and/or set thresholds for 1472 the class of events being requested. Designers of event packages are 1473 strongly encouraged to re-use existing MIME types for message bodies 1474 where practical. 1476 This mandatory section of an event package defines what type or types 1477 of event bodies are expected in SUBSCRIBE requests (or specify that 1478 no event bodies are expected). It should point to detailed 1479 definitions of syntax and semantics for all referenced body types. 1481 5.4.4. Subscription Duration 1483 It is RECOMMENDED that event packages give a suggested range of times 1484 considered reasonable for the duration of a subscription. Such 1485 packages MUST also define a default "Expires" value to be used if 1486 none is specified. 1488 5.4.5. NOTIFY Request Bodies 1490 The NOTIFY request body is used to report state on the resource being 1491 monitored. Each package MUST define what type or types of event 1492 bodies are expected in NOTIFY requests. Such packages MUST specify 1493 or cite detailed specifications for the syntax and semantics 1494 associated with such event body. 1496 Event packages also MUST define which MIME type is to be assumed if 1497 none are specified in the "Accept" header field of the SUBSCRIBE 1498 request. 1500 5.4.6. Notifier processing of SUBSCRIBE requests 1502 This section describes the processing to be performed by the notifier 1503 upon receipt of a SUBSCRIBE request. Such a section is required. 1505 Information in this section includes details of how to authenticate 1506 subscribers and authorization issues for the package. 1508 5.4.7. Notifier generation of NOTIFY requests 1510 This section of an event package describes the process by which the 1511 notifier generates and sends a NOTIFY request. This includes 1512 detailed information about what events cause a NOTIFY request to be 1513 sent, how to compute the state information in the NOTIFY, how to 1514 generate neutral or fake state information to hide authorization 1515 delays and decisions from users, and whether state information is 1516 complete or deltas for notifications; see Section 5.3. Such a 1517 section is required. 1519 This section may optionally describe the behavior used to process the 1520 subsequent response. 1522 5.4.8. Subscriber processing of NOTIFY requests 1524 This section of an event package describes the process followed by 1525 the subscriber upon receipt of a NOTIFY request, including any logic 1526 required to form a coherent resource state (if applicable). 1528 5.4.9. Handling of forked requests 1530 Each event package MUST specify whether forked SUBSCRIBE requests are 1531 allowed to install multiple subscriptions. 1533 If such behavior is not allowed, the first potential dialog- 1534 establishing message will create a dialog. All subsequent NOTIFY 1535 requests which correspond to the SUBSCRIBE request (i.e., match "To", 1536 "From", "From" header field "tag" parameter, "Call-ID", "Event", and 1537 "Event" header field "id" parameter) but which do not match the 1538 dialog would be rejected with a 481 response. Note that the 200- 1539 class response to the SUBSCRIBE request can arrive after a matching 1540 NOTIFY request has been received; such responses might not correlate 1541 to the same dialog established by the NOTIFY request. Except as 1542 required to complete the SUBSCRIBE transaction, such non-matching 1543 200-class responses are ignored. 1545 If installing of multiple subscriptions by way of a single forked 1546 SUBSCRIBE request is allowed, the subscriber establishes a new dialog 1547 towards each notifier by returning a 200-class response to each 1548 NOTIFY request. Each dialog is then handled as its own entity, and 1549 is refreshed independent of the other dialogs. 1551 In the case that multiple subscriptions are allowed, the event 1552 package MUST specify whether merging of the notifications to form a 1553 single state is required, and how such merging is to be performed. 1554 Note that it is possible that some event packages may be defined in 1555 such a way that each dialog is tied to a mutually exclusive state 1556 which is unaffected by the other dialogs; this MUST be clearly stated 1557 if it is the case. 1559 5.4.10. Rate of notifications 1561 Each event package is expected to define a requirement (SHOULD or 1562 MUST strength) which defines an absolute maximum on the rate at which 1563 notifications are allowed to be generated by a single notifier. 1565 Each package MAY further define a throttle mechanism which allows 1566 subscribers to further limit the rate of notification. 1568 5.4.11. State Aggregation 1570 Many event packages inherently work by collecting information about a 1571 resource from a number of other sources -- either through the use of 1572 PUBLISH [RFC3903], by subscribing to state information, or through 1573 other state gathering mechanisms. 1575 Event packages that involve retrieval of state information for a 1576 single resource from more than one source need to consider how 1577 notifiers aggregate information into a single, coherent state. Such 1578 packages MUST specify how notifiers aggregate information and how 1579 they provide authentication and authorization. 1581 5.4.12. Examples 1583 Event packages SHOULD include several demonstrative message flow 1584 diagrams paired with several typical, syntactically correct, and 1585 complete messages. 1587 It is RECOMMENDED that documents describing event packages clearly 1588 indicate that such examples are informative and not normative, with 1589 instructions that implementors refer to the main text of the document 1590 for exact protocol details. 1592 5.4.13. Use of URIs to Retrieve State 1594 Some types of event packages may define state information which is 1595 potentially too large to reasonably send in a SIP message. To 1596 alleviate this problem, event packages may include the ability to 1597 convey a URI instead of state information; this URI will then be used 1598 to retrieve the actual state information. 1600 [RFC4483] defines a mechanism that can be used by event packages to 1601 convey information in such a fashion. 1603 6. Security Considerations 1605 6.1. Access Control 1607 The ability to accept subscriptions should be under the direct 1608 control of the notifier's user, since many types of events may be 1609 considered sensitive for the purposes of privacy. Similarly, the 1610 notifier should have the ability to selectively reject subscriptions 1611 based on the subscriber identity (based on access control lists), 1612 using standard SIP authentication mechanisms. The methods for 1613 creation and distribution of such access control lists is outside the 1614 scope of this document. 1616 6.2. Notifier Privacy Mechanism 1618 The mere act of returning certain 4xx and 6xx responses to SUBSCRIBE 1619 requests may, under certain circumstances, create privacy concerns by 1620 revealing sensitive policy information. In these cases, the notifier 1621 SHOULD always return a 200 (OK) response. While the subsequent 1622 NOTIFY request may not convey true state, it MUST appear to contain a 1623 potentially correct piece of data from the point of view of the 1624 subscriber, indistinguishable from a valid response. Information 1625 about whether a user is authorized to subscribe to the requested 1626 state is never conveyed back to the original user under these 1627 circumstances. 1629 Individual packages and their related documents for which such a mode 1630 of operation makes sense can further describe how and why to generate 1631 such potentially correct data. For example, such a mode of operation 1632 is mandated by [RFC2779] for user presence information. 1634 6.3. Denial-of-Service attacks 1636 The current model (one SUBSCRIBE request triggers a SUBSCRIBE 1637 response and one or more NOTIFY requests) is a classic setup for an 1638 amplifier node to be used in a smurf attack. 1640 Also, the creation of state upon receipt of a SUBSCRIBE request can 1641 be used by attackers to consume resources on a victim's machine, 1642 rendering it unusable. 1644 To reduce the chances of such an attack, implementations of notifiers 1645 SHOULD require authentication. Authentication issues are discussed 1646 in [RFC3261]. 1648 6.4. Replay Attacks 1650 Replaying of either SUBSCRIBE or NOTIFY requests can have detrimental 1651 effects. 1653 In the case of SUBSCRIBE requests, attackers may be able to install 1654 any arbitrary subscription which it witnessed being installed at some 1655 point in the past. Replaying of NOTIFY requests may be used to spoof 1656 old state information (although a good versioning mechanism in the 1657 body of the NOTIFY requests may help mitigate such an attack). Note 1658 that the prohibition on sending NOTIFY requests to nodes which have 1659 not subscribed to an event also aids in mitigating the effects of 1660 such an attack. 1662 To prevent such attacks, implementations SHOULD require 1663 authentication with anti-replay protection. Authentication issues 1664 are discussed in [RFC3261]. 1666 6.5. Man-in-the middle attacks 1668 Even with authentication, man-in-the-middle attacks using SUBSCRIBE 1669 requests may be used to install arbitrary subscriptions, hijack 1670 existing subscriptions, terminate outstanding subscriptions, or 1671 modify the resource to which a subscription is being made. To 1672 prevent such attacks, implementations SHOULD provide integrity 1673 protection across "Contact", "Route", "Expires", "Event", and "To" 1674 header fields of SUBSCRIBE requests, at a minimum. If SUBSCRIBE 1675 request bodies are used to define further information about the state 1676 of the call, they SHOULD be included in the integrity protection 1677 scheme. 1679 Man-in-the-middle attacks may also attempt to use NOTIFY requests to 1680 spoof arbitrary state information and/or terminate outstanding 1681 subscriptions. To prevent such attacks, implementations SHOULD 1682 provide integrity protection across the "Call-ID", "CSeq", and 1683 "Subscription-State" header fields and the bodies of NOTIFY requests. 1685 Integrity protection of message header fields and bodies is discussed 1686 in [RFC3261]. 1688 6.6. Confidentiality 1690 The state information contained in a NOTIFY request has the potential 1691 to contain sensitive information. Implementations MAY encrypt such 1692 information to ensure confidentiality. 1694 While less likely, it is also possible that the information contained 1695 in a SUBSCRIBE request contains information that users might not want 1696 to have revealed. Implementations MAY encrypt such information to 1697 ensure confidentiality. 1699 To allow the remote party to hide information it considers sensitive, 1700 all implementations SHOULD be able to handle encrypted SUBSCRIBE and 1701 NOTIFY requests. 1703 The mechanisms for providing confidentiality are detailed in 1704 [RFC3261]. 1706 7. IANA Considerations 1708 (This section is not applicable until this document is published as 1709 an RFC.) 1711 7.1. Event Packages 1713 This document defines an event-type namespace which requires a 1714 central coordinating body. The body chosen for this coordination is 1715 the Internet Assigned Numbers Authority (IANA). 1717 There are two different types of event-types: normal event packages, 1718 and event template-packages; see Section 5.2. To avoid confusion, 1719 template-package names and package names share the same namespace; in 1720 other words, an event template-package MUST NOT share a name with a 1721 package. 1723 Policies for registration of SIP event packages and SIP event package 1724 templates are defined in section 4.1 of [RFC5727]. 1726 Registrations with the IANA MUST include the token being registered 1727 and whether the token is a package or a template-package. Further, 1728 packages MUST include contact information for the party responsible 1729 for the registration and/or a published document which describes the 1730 event package. Event template-package token registrations MUST 1731 include a pointer to the published RFC which defines the event 1732 template-package. 1734 Registered tokens to designate packages and template-packages MUST 1735 NOT contain the character ".", which is used to separate template- 1736 packages from packages. 1738 7.1.1. Registration Information 1740 As this document specifies no package or template-package names, the 1741 initial IANA registration for event types will be empty. The 1742 remainder of the text in this section gives an example of the type of 1743 information to be maintained by the IANA; it also demonstrates all 1744 five possible permutations of package type, contact, and reference. 1746 The table below lists the event packages and template-packages 1747 defined in "SIP-Specific Event Notification" [RFC xxxx]. Each name 1748 is designated as a package or a template-package under "Type". 1750 Package Name Type Contact Reference 1751 ------------ ---- ------- --------- 1752 example1 package [Roach] 1753 example2 package [Roach] [RFC xxxx] 1754 example3 package [RFC xxxx] 1755 example4 template [Roach] [RFC xxxx] 1756 example5 template [RFC xxxx] 1758 PEOPLE 1759 ------ 1760 [Roach] Adam Roach 1762 REFERENCES 1763 ---------- 1764 [RFC xxxx] A.B. Roach, "SIP-Specific Event Notification", RFC XXXX, 1765 Monthname 20XX 1767 7.1.2. Registration Template 1769 To: ietf-sip-events@iana.org 1770 Subject: Registration of new SIP event package 1772 Package Name: 1774 (Package names must conform to the syntax described in 1775 Section 8.2.1.) 1777 Is this registration for a Template Package: 1779 (indicate yes or no) 1781 Published Specification(s): 1783 (Template packages require a published RFC. Other packages may 1784 reference a specification when appropriate). 1786 Person & email address to contact for further information: 1788 7.2. Reason Codes 1790 This document further defines "reason" codes for use in the 1791 "Subscription-State" header field (see Section 4.1.3). 1793 Following the policies outlined in "Guidelines for Writing an IANA 1794 Considerations Section in RFCs" [RFC5226], new reason codes require a 1795 Standards Action. 1797 Registrations with the IANA include the reason code being registered 1798 and a reference to a published document which describes the event 1799 package. Insertion of such values takes place as part of the RFC 1800 publication process or as the result of inter-SDO liaison activity. 1801 New reason codes must conform to the syntax of the ABNF "token" 1802 element defined in [RFC3261]. 1804 [RFC4660] defined a new reason code prior to the establishment of an 1805 IANA registry. We include its reason code ("badfilter") in the 1806 initial list of reason codes to ensure a complete registry. 1808 The IANA registry for reason code will be initialized with the 1809 following values: 1811 Reason Code Reference 1812 ----------- --------- 1813 deactivated [RFC xxxx] 1814 probation [RFC xxxx] 1815 rejected [RFC xxxx] 1816 timeout [RFC xxxx] 1817 giveup [RFC xxxx] 1818 noresource [RFC xxxx] 1819 invariant [RFC xxxx] 1820 badfilter [RFC 4660] 1822 REFERENCES 1823 ---------- 1824 [RFC xxxx] A.B. Roach, "SIP-Specific Event Notification", RFC XXXX, 1825 Monthname 20XX 1827 [RFC 4660] Khartabil, H., Leppanen, E., Lonnfors, M., and 1828 J. Costa-Requena, "Functional Description of Event 1829 Notification Filtering", September 2006. 1831 7.3. Header Field Names 1833 This document registers three new header field names, described 1834 elsewhere in this document. These header fields are defined by the 1835 following information, which is to be added to the header field sub- 1836 registry under http://www.iana.org/assignments/sip-parameters. 1838 Header Name: Allow-Events 1839 Compact Form: u 1841 Header Name: Subscription-State 1842 Compact Form: (none) 1844 Header Name: Event 1845 Compact Form: o 1847 7.4. Response Codes 1849 This document registers two new response codes. These response codes 1850 are defined by the following information, which is to be added to the 1851 method and response-code sub-registry under 1852 http://www.iana.org/assignments/sip-parameters. 1854 Response Code Number: 202 1855 Default Reason Phrase: Accepted 1857 Response Code Number: 489 1858 Default Reason Phrase: Bad Event 1860 8. Syntax 1862 This section describes the syntax extensions required for event 1863 notification in SIP. Semantics are described in Section 4. Note 1864 that the formal syntax definitions described in this document are 1865 expressed in the ABNF format used in [RFC3261], and contain 1866 references to elements defined therein. 1868 8.1. New Methods 1870 This document describes two new SIP methods: SUBSCRIBE and NOTIFY. 1872 8.1.1. SUBSCRIBE method 1874 "SUBSCRIBE" is added to the definition of the element "Method" in the 1875 SIP message grammar. 1877 Like all SIP method names, the SUBSCRIBE method name is case 1878 sensitive. The SUBSCRIBE method is used to request asynchronous 1879 notification of an event or set of events at a later time. 1881 8.1.2. NOTIFY method 1883 "NOTIFY" is added to the definition of the element "Method" in the 1884 SIP message grammar. 1886 The NOTIFY method is used to notify a SIP node that an event which 1887 has been requested by an earlier SUBSCRIBE method has occurred. It 1888 may also provide further details about the event. 1890 8.2. New Header Fields 1892 8.2.1. "Event" Header Field 1894 Event is added to the definition of the element "message-header 1895 field" in the SIP message grammar. 1897 For the purposes of matching NOTIFY requests with SUBSCRIBE requests, 1898 the event-type portion of the "Event" header field is compared byte- 1899 by-byte, and the "id" parameter token (if present) is compared byte- 1900 by-byte. An "Event" header field containing an "id" parameter never 1901 matches an "Event" header field without an "id" parameter. No other 1902 parameters are considered when performing a comparison. SUBSCRIBE 1903 responses are matched per the transaction handling rules in 1904 [RFC3261]. 1906 Note that the forgoing text means that "Event: foo; id=1234" would 1907 match "Event: foo; param=abcd; id=1234", but not "Event: foo" (id 1908 does not match) or "Event: Foo; id=1234" (event portion does not 1909 match). 1911 This document does not define values for event-types. These values 1912 will be defined by individual event packages, and MUST be registered 1913 with the IANA. 1915 There MUST be exactly one event type listed per event header field. 1916 Multiple events per message are disallowed. 1918 8.2.2. "Allow-Events" Header Field 1920 Allow-Events is added to the definition of the element "general- 1921 header field" in the SIP message grammar. Its usage is described in 1922 Section 4.4.4. 1924 8.2.3. "Subscription-State" Header Field 1926 Subscription-State is added to the definition of the element 1927 "request-header field" in the SIP message grammar. Its usage is 1928 described in Section 4.1.3. 1930 8.3. New Response Codes 1932 8.3.1. "202 Accepted" Response Code 1934 For historical purposes, the 202 (Accepted) response code is added to 1935 the "Success" header field definition. 1937 This document does not specify the use of the 202 response code in 1938 conjunction with the SUBSCRIBE or NOTIFY methods. Previous versions 1939 of the SIP Events Framework assigned specific semantics to the 202 1940 response code. Implementations conformant with the current 1941 specification MUST treat an incoming 202 response as identical to a 1942 200 response, and MUST NOT generate 202 response codes to SUBSCRIBE 1943 or NOTIFY requests. 1945 This document also updates [RFC4660], which reiterates the 202-based 1946 behavior in several places. Implementations compliant with the 1947 present document MUST NOT send a 202 response to a SUBSCRIBE request, 1948 and will send an alternate success response (such as 200) in its 1949 stead. 1951 8.3.2. "489 Bad Event" Response Code 1953 The 489 event response is added to the "Client-Error" header field 1954 field definition. "489 Bad Event" is used to indicate that the server 1955 did not understand the event package specified in a "Event" header 1956 field. 1958 8.4. Augmented BNF Definitions 1960 The Augmented BNF definitions for the various new and modified syntax 1961 elements follows. The notation is as used in [RFC3261], and any 1962 elements not defined in this section are as defined in SIP and the 1963 documents to which it refers. 1965 SUBSCRIBEm = %x53.55.42.53.43.52.49.42.45 ; SUBSCRIBE in caps 1966 NOTIFYm = %x4E.4F.54.49.46.59 ; NOTIFY in caps 1967 extension-method = SUBSCRIBEm / NOTIFYm / token 1969 Event = ( "Event" / "o" ) HCOLON event-type 1970 *( SEMI event-param ) 1971 event-type = event-package *( "." event-template ) 1972 event-package = token-nodot 1973 event-template = token-nodot 1974 token-nodot = 1*( alphanum / "-" / "!" / "%" / "*" 1975 / "_" / "+" / "`" / "'" / "~" ) 1977 ; The use of the "id" parameter is deprecated; it is included 1978 ; for backwards compatibility purposes only. 1979 event-param = generic-param / ( "id" EQUAL token ) 1981 Allow-Events = ( "Allow-Events" / "u" ) HCOLON event-type 1982 *(COMMA event-type) 1984 Subscription-State = "Subscription-State" HCOLON substate-value 1985 *( SEMI subexp-params ) 1986 substate-value = "active" / "pending" / "terminated" 1987 / extension-substate 1988 extension-substate = token 1989 subexp-params = ("reason" EQUAL event-reason-value) 1990 / ("expires" EQUAL delta-seconds) 1991 / ("retry-after" EQUAL delta-seconds) 1992 / generic-param 1993 event-reason-value = "deactivated" 1994 / "probation" 1995 / "rejected" 1996 / "timeout" 1997 / "giveup" 1998 / "noresource" 1999 / "invariant" 2000 / event-reason-extension 2001 event-reason-extension = token 2003 9. References 2005 9.1. Normative References 2007 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2008 Requirement Levels", BCP 14, RFC 2119, March 1997. 2010 [RFC2848] Petrack, S. and L. Conroy, "The PINT Service Protocol: 2011 Extensions to SIP and SDP for IP Access to Telephone Call 2012 Services", RFC 2848, June 2000. 2014 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2015 A., Peterson, J., Sparks, R., Handley, M., and E. 2016 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2017 June 2002. 2019 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 2020 Event Notification", RFC 3265, June 2002. 2022 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 2023 (IANA) Header Field Parameter Registry for the Session 2024 Initiation Protocol (SIP)", BCP 98, RFC 3968, 2025 December 2004. 2027 [RFC4483] Burger, E., "A Mechanism for Content Indirection in 2028 Session Initiation Protocol (SIP) Messages", RFC 4483, 2029 May 2006. 2031 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2032 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2033 May 2008. 2035 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 2036 Agent URIs (GRUUs) in the Session Initiation Protocol 2037 (SIP)", RFC 5627, October 2009. 2039 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 2040 for the Session Initiation Protocol (SIP) and the Real- 2041 time Applications and Infrastructure Area", BCP 67, 2042 RFC 5727, March 2010. 2044 9.2. Informative References 2046 [RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant 2047 Messaging / Presence Protocol Requirements", RFC 2779, 2048 February 2000. 2050 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 2051 Method", RFC 3515, April 2003. 2053 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2054 "Indicating User Agent Capabilities in the Session 2055 Initiation Protocol (SIP)", RFC 3840, August 2004. 2057 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 2058 Protocol (SIP) "Replaces" Header", RFC 3891, 2059 September 2004. 2061 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 2062 for Event State Publication", RFC 3903, October 2004. 2064 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol 2065 (SIP) "Join" Header", RFC 3911, October 2004. 2067 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 2068 Initiated Dialog Event Package for the Session Initiation 2069 Protocol (SIP)", RFC 4235, November 2005. 2071 [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors 2072 of Extensions to the Session Initiation Protocol (SIP)", 2073 RFC 4485, May 2006. 2075 [RFC4538] Rosenberg, J., "Request Authorization through Dialog 2076 Identification in the Session Initiation Protocol (SIP)", 2077 RFC 4538, June 2006. 2079 [RFC4660] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 2080 Requena, "Functional Description of Event Notification 2081 Filtering", RFC 4660, September 2006. 2083 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 2084 Initiation Protocol", RFC 5057, November 2007. 2086 [RFC5839] Niemi, A. and D. Willis, "An Extension to Session 2087 Initiation Protocol (SIP) Events for Conditional Event 2088 Notification", RFC 5839, May 2010. 2090 Appendix A. Acknowledgements 2092 Thanks to the participants in the Events BOF at the 48th IETF meeting 2093 in Pittsburgh, as well as those who gave ideas and suggestions on the 2094 SIP Events mailing list. In particular, I wish to thank Henning 2095 Schulzrinne of Columbia University for coming up with the final 2096 three-tiered event identification scheme, Sean Olson for 2097 miscellaneous guidance, Jonathan Rosenberg for a thorough scrubbing 2098 of the -00 draft, and the authors of the "SIP Extensions for 2099 Presence" document for their input to SUBSCRIBE and NOTIFY request 2100 semantics. 2102 I also owe a debt of gratitude to all the implementors who have 2103 provided feedback on areas of confusion or difficulty in the original 2104 specification. In particular, Robert Sparks' Herculean efforts 2105 organizing, running, and collecting data from the SIPit events have 2106 proven invaluable in shaking out specification bugs. Robert Sparks 2107 is also responsible for untangling the dialog usage mess, in the form 2108 of RFC 5057 [RFC5057]. 2110 Appendix B. Changes 2112 This section, and all of its subsections, will be consolidated into a 2113 single "Changes Since RFC 3265" section prior to publication. Bug 2114 numbers refer to the identifiers for the bug reports kept on file at 2115 http://bugs.sipit.net/. 2117 B.1. Changes from draft-ietf-sipcore-rfc3265bis-02 to 2118 draft-ietf-sipcore-rfc3265bis-03 2120 o Clarified scope of Event header field parameters. In RFC3265, the 2121 scope is ambiguous, which causes problems with the RFC3968 2122 registry. The new text ensures that Event header field parameters 2123 are unique across all event packages. 2124 o Removed obsoleted language around IANA registration policies for 2125 event packages. Instead, we now cite RFC5727, which supersedes 2126 RFC3265, and is authoritative on event package registration 2127 policy. 2128 o Several editorial updates after input from working group, 2129 including proper designation of "dialog usage" rather than 2130 "dialog" where appropriate. 2131 o Fixed left-over language that allowed implicit subscriptions (in 2132 contradiction to text elsewhere in the document) 2133 o Fixed subscriber state machine handling of Timer N 2134 o Clarified two normative statements about subscription termination 2135 by changing from plain English prose to RFC2119 language. 2137 B.2. Changes from draft-ietf-sipcore-rfc3265bis-01 to 2138 draft-ietf-sipcore-rfc3265bis-02 2140 o Removed "Table 2" expansions, per WG consensus on how SIP table 2 2141 is to be handled. 2142 o Removed 202 response code. 2143 o Clarified that "Allow-Events" does not list event template 2144 packages. 2145 o Clarified that Timer N *does* apply to subscription refreshes. 2147 B.3. Changes from draft-ietf-sipcore-rfc3265bis-00 to 2148 draft-ietf-sipcore-rfc3265bis-01 2150 o Renamed Timer L to Timer N, to avoid a naming conflict. 2151 o Added clarification about proper response when the SUBSCRIBE 2152 indicates an unknown MIME type in its Accept header field. 2154 o Clarification around Route and Record-Route behavior. 2155 o Added non-normative warning about the limitations of state 2156 polling. 2157 o Added information about targeting subscriptions at specific 2158 dialogs. 2159 o Added "Call-Info" header field to RFC 3261 Table 2 expansion. 2161 B.4. Changes from draft-roach-sipcore-rfc3265bis-00 to 2162 draft-ietf-sipcore-rfc3265bis-00 2164 None 2166 B.5. Changes since RFC 3265 2168 B.5.1. Bug 666: Clarify use of expires=xxx with terminated 2170 Strengthened language in Section 4.1.3 to clarify that expires should 2171 not be sent with terminated, and must be ignored if received. 2173 B.5.2. Bug 667: Reason code for unsub/poll not clearly spelled out 2175 Clarified description of "timeout" in Section 4.1.3. (n.b., the text 2176 in Section 4.4.3 is actually pretty clear about this). 2178 B.5.3. Bug 669: Clarify: SUBSCRIBE for a duration might be answered 2179 with a NOTIFY/expires=0 2181 Added clarifying text to Section 4.2.2 explaining that shortening a 2182 subscription to zero seconds is valid. Also added sentence to 2183 Section 3.1.1 explicitly allowing shortening to zero. 2185 B.5.4. Bug 670: Dialog State Machine needs clarification 2187 The issues associated with the bug deal exclusively with the handling 2188 of multiple usages with a dialog. This behavior has been deprecated 2189 and moved to Section 4.5.2. This section, in turn, cites [RFC5057], 2190 which addresses all of the issues in Bug 670. 2192 B.5.5. Bug 671: Clarify timeout-based removal of subscriptions 2194 Changed Section 4.2.2 to specifically cite Timer F (so as to avoid 2195 ambiguity between transaction timeouts and retransmission timeouts). 2197 B.5.6. Bug 672: Mandate expires= in NOTIFY 2199 Changed strength of including of "expires" in a NOTIFY from SHOULD to 2200 MUST in Section 4.2.2. 2202 B.5.7. Bug 673: INVITE 481 response effect clarification 2204 This bug was addressed in [RFC5057]. 2206 B.5.8. Bug 677: SUBSCRIBE response matching text in error 2208 Fixed Section 8.2.1 to remove incorrect "...responses and..." -- 2209 explicitly pointed to SIP for transaction response handling. 2211 B.5.9. Bug 695: Document is not explicit about response to NOTIFY at 2212 subscription termination 2214 Added text to Section 4.4.1 indicating that the typical response to a 2215 terminal NOTIFY is a "200 OK". 2217 B.5.10. Bug 696: Subscription state machine needs clarification 2219 Added state machine diagram to Section 4.1.2 with explicit handling 2220 of what to do when a SUBSCRIBE never shows up. Added definition of 2221 and handling for new Timer N to Section 4.1.2.4. Added state machine 2222 to Section 4.2.2 to reinforce text. 2224 B.5.11. Bug 697: Unsubscription behavior could be clarified 2226 Added text to Section 4.2.1.4 encouraging (but not requiring) full 2227 state in final NOTIFY request. Also added text to Section 4.1.2.3 2228 warning subscribers that full state may or may not be present in the 2229 final NOTIFY. 2231 B.5.12. Bug 699: NOTIFY and SUBSCRIBE are target refresh requests 2233 Added text to both Section 3.1 and Section 3.2 explicitly indicating 2234 that SUBSCRIBE and NOTIFY are target refresh methods. 2236 B.5.13. Bug 722: Inconsistent 423 reason phrase text 2238 Changed reason code to "Interval Too Brief" in Section 4.2.1.1 and 2239 Section 4.2.1.4, to match 423 reason code in SIP [RFC3261]. 2241 B.5.14. Bug 741: guidance needed on when to not include Allow-Events 2243 Added non-normative clarification to Section 4.4.4 regarding 2244 inclusion of Allow-Events in a NOTIFY for the one-and-only package 2245 supported by the notifier. 2247 B.5.15. Bug 744: 5xx to NOTIFY terminates a subscription, but should 2248 not 2250 Issue of subscription (usage) termination versus dialog termination 2251 is handled in [RFC5057]. The text in Section 4.2.2 has been updated 2252 to summarize the behavior described by 5057, and cites it for 2253 additional detail and rationale. 2255 B.5.16. Bug 752: Detection of forked requests is incorrect 2257 Removed erroneous "CSeq" from list of matching criteria in 2258 Section 5.4.9. 2260 B.5.17. Bug 773: Reason code needs IANA registry 2262 Added Section 7.2 to create and populate IANA registry. 2264 B.5.18. Bug 774: Need new reason for terminating subscriptions to 2265 resources that never change 2267 Added new "invariant" reason code to Section 4.1.3, ABNF syntax. 2269 B.5.19. Clarify handling of Route/Record-Route in NOTIFY 2271 Changed text in Section 4.3 mandating Record-Route in initial 2272 SUBSCRIBE and all NOTIFY requests, and adding "MAY" level statements 2273 for subsequent SUBSCRIBE requests. 2275 B.5.20. Eliminate implicit subscriptions 2277 Added text to Section 4.2.1 explaining some of the problems 2278 associated with implicit subscriptions, normative language 2279 prohibiting them. Removed language from Section 3.2 describing "non- 2280 SUBSCRIBE" mechanisms for creating subscriptions. Simplified 2281 language in Section 4.2.2, now that the soft-state/non-soft-state 2282 distinction is unnecessary. 2284 B.5.21. Deprecate dialog re-use 2286 Moved handling of dialog re-use and "id" handling to Section 4.5.2. 2287 It is documented only for backwards-compatibility purposes. 2289 B.5.22. Rationalize dialog creation 2291 Section 4.4.1 has been updated to specify that dialogs should be 2292 created when the NOTIFY arrives. Previously, the dialog was 2293 established by the SUBSCRIBE 200, or by the NOTIFY transaction. This 2294 was unnecessarily complicated; the newer rules are easier to 2295 implement (and result in effectively the same behavior on the wire). 2297 B.5.23. Refactor behavior sections 2299 Reorganized Section 4 to consolidate behavior along role lines 2300 (subscriber/notifier/proxy) instead of method lines. 2302 B.5.24. Clarify sections that need to be present in event packages 2304 Added sentence to Section 5 clarifying that event packages are 2305 expected to include explicit sections covering the issues discussed 2306 in this section. 2308 B.5.25. Make CANCEL handling more explicit 2310 Text in Section 4.6 now clearly calls out behavior upon receipt of a 2311 CANCEL. We also echo the "...SHOULD NOT send..." requirement from 2312 [RFC3261]. 2314 B.5.26. Remove State Agent Terminology 2316 As originally planned, we anticipated a fairly large number of event 2317 packages that would move back and forth between end-user devices and 2318 servers in the network. In practice, this has ended up not being the 2319 case. Certain events, like dialog state, are inherently hosted at 2320 end-user devices; others, like presence, are almost always hosted in 2321 the network (due to issues like composition, and the ability to 2322 deliver information when user devices are offline). Further, the 2323 concept of State Agents is the most misunderstood by event package 2324 authors. In my expert review of event packages, I have yet to find 2325 one that got the concept of State Agents completely correct -- and 2326 most of them start out with the concept being 100% backwards from the 2327 way RFC 3265 described it. 2329 Rather than remove the ability to perform the actions previously 2330 attributed to the widely misunderstood term "State Agent," we have 2331 simply eliminated this term. Instead, we talk about the behaviors 2332 required to create state agents (state aggregation, subscription 2333 notification) without defining a formal term to describe the servers 2334 that exhibit these behaviors. In effect, this is an editorial change 2335 to make life easier for event package authors; the actual protocol 2336 does not change as a result. 2338 The definition of "State Agent" has been removed from Section 2. 2339 Section 4.4.2 has been retooled to discuss migration of subscription 2340 in general, without calling out the specific example of state agents. 2341 Section 5.4.11 has been focused on state aggregation in particular, 2342 instead of state aggregation as an aspect of state agents. 2344 Author's Address 2346 Adam Roach 2347 Tekelec 2348 17210 Campbell Rd. 2349 Suite 250 2350 Dallas, TX 75252 2351 US 2353 Email: adam@nostrum.com