idnits 2.17.1 draft-roach-sip-subscribe-notify-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 305: '...TIFY methods, and SHOULD be registered...' RFC 2119 keyword, line 366: '...lity, both SUBSCRIBE and NOTIFY MAY be...' RFC 2119 keyword, line 368: '... NOTIFY requests MUST be completed wit...' RFC 2119 keyword, line 380: '...of subscriptions SHOULD reuse the same...' RFC 2119 keyword, line 394: '...BSCRIBE requests MUST contain an "Expi...' (41 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 284 has weird spacing: '... where proxy...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The "Expires" values present in SUBSCRIBE 200-class responses behave in the same way as they do in REGISTER responses: the server MAY shorten the interval, but MUST not increase it. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: NOTIFY requests MAY contain an "Expires" header which indicates the remaining duration of the subscription. The notifier MAY use this header to adjust the time remaining on the subscription; however, this mechanism MUST not be used to lengthen a subscription, only to shorten it. The notifier may inform a subscriber that a subscription has been removed by sending a NOTIFY message with an "Expires" value of "0." -- 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 (August 2001) is 8284 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) == Unused Reference: '2' is defined on line 1026, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2068 (ref. '6') (Obsoleted by RFC 2616) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Adam Roach 2 Internet Draft Ericsson Inc. 3 Category: Standards Track February 2001 4 Expires August 2001 5 7 Event Notification in SIP 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or cite them other than as "work in 23 progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/lid-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This document is an individual submission to the IETF. Comments 32 should be directed to the authors. 34 Abstract 36 This document describes an extension to the Session Initiation 37 Protocol (SIP). The purpose of this extension is to provide a 38 generic and extensible framework by which SIP nodes can request 39 notification from remote nodes indicating that certain events 40 have occurred. 42 Concrete uses of the mechanism described in this document may be 43 standardized in the future. 45 1. Table of Contents 47 1. Table of Contents...................................... 1 48 2. Introduction........................................... 2 49 2.1. Overview of Operation.................................. 3 50 3. Extension Considerations............................... 3 51 3.1. Appropriateness of Usage............................... 4 52 3.2. Additional Guidelines.................................. 4 53 4. Syntax................................................. 5 54 4.1. New Methods............................................ 5 55 4.1.1. SUBSCRIBE method....................................... 6 56 4.1.2. NOTIFY method.......................................... 7 57 4.2. New Headers............................................ 7 58 4.2.1. "Event" header......................................... 7 59 4.2.2. "Allow-Events" Header.................................. 8 60 4.3. New Response Codes..................................... 8 61 4.3.1. "202 Accepted" Response Code........................... 8 62 4.3.2. "489 Bad Event" Response Code.......................... 8 63 5. Node Behavior.......................................... 8 64 5.1. Description of SUBSCRIBE Behavior...................... 9 65 5.1.1. Correlation to legs, calls, and terminals.............. 9 66 5.1.2. Subscription duration.................................. 9 67 5.1.3. Identification of Subscribed Events and Event Classes.. 10 68 5.1.4. Additional SUBSCRIBE Header Values..................... 11 69 5.1.5. Subscriber SUBSCRIBE Behavior.......................... 11 70 5.1.6. Proxy SUBSCRIBE Behavior............................... 12 71 5.1.7. Notifier SUBSCRIBE Behavior............................ 13 72 5.2. Description of NOTIFY Behavior......................... 15 73 5.2.1. Correlation............................................ 15 74 5.2.2. Identification of reported events, event classes, and c 15 75 5.2.3. Notifier NOTIFY Behavior............................... 16 76 5.2.4. Proxy NOTIFY Behavior.................................. 17 77 5.2.5. Subscriber NOTIFY Behavior............................. 17 78 5.3. Polling Resource State................................. 18 79 5.4. Allow-Events header usage.............................. 18 80 6. Security Considerations................................ 18 81 7. Open Issues............................................ 19 82 7.1. Event Agents........................................... 19 83 7.2. Event Throttling....................................... 19 84 7.3. Resource identification for out-of-band subscriptions.. 20 85 8. Changes................................................ 20 86 8.1. Changes from -02....................................... 20 87 8.2. Changes from -01....................................... 22 88 9. References............................................. 23 89 10. Credits................................................ 23 90 11. Feedback and Discussion................................ 23 91 12. Author's Address....................................... 23 93 2. Introduction 95 The ability to request asynchronous notification of events proves 96 useful in many types of services for which cooperation between 97 end-nodes is required. Examples of such services include 98 automatic callback services (based on terminal state events), 99 buddy lists (based on user presence events), message waiting 100 indications (based on mailbox state change events), and PINT 101 status (based on call state events). 103 The methods described in this document allow a framework by which 104 notification of these events can be ordered. 106 Note that the event notification mechanisms defined herein are 107 NOT intended to be a general-purpose infrastructure for all 108 classes of event subscription and notification. Meeting 109 requirements for the general problem set of subscription and 110 notification is far too complex for a single protocol. Our goal 111 is to provide a general framework for event notification which is 112 not so complex as to be unusable for simple features, but which 113 is still flexible enough to provide powerful services. However, 114 extensions based on this framework may define arbitrarily complex 115 rules which govern the subscription and notification for the 116 events or classes of events they describe. 118 Note that this draft does not describe an extension which may be 119 used directly; it must be extended by other drafts (herein 120 referred to as "extension drafts" and "event packages.") In 121 object-oriented design terminology, it may be thought of as an 122 abstract base class which must be derived into an instantiatable 123 class by further extensions. Guidelines for creating these 124 extensions are described in section 3. 126 2.1. Overview of Operation 128 The general concept is that entities in the network can subscribe 129 to resource or call state for various resources or calls in the 130 network, and those entities (or entities acting on their behalf) 131 can send notifications when those states change. 133 A typical flow of messages would be: 135 Subscriber Notifier 136 |-----SUBSCRIBE---->| Request state subscription 137 |<-------200--------| Acknowledge subscription 138 |<------NOTIFY----- | Return current state information 139 |--------200------->| 140 |<------NOTIFY----- | Return current state information 141 |--------200------->| 143 The subscriber and notifier entities need not necessarily be UAs, 144 but often will be. 146 Subscriptions are expired and must be refreshed in exactly the 147 same manner as registrations (see RFC 2543 [1] ). 149 3. Extension Considerations 151 This section covers several issues which should be taken into 152 consideration when SIP extensions based on SUBSCRIBE and NOTIFY 153 are proposed. 155 3.1. Appropriateness of Usage 157 When using the methods described in this draft for event 158 notification, it is important to consider: is SIP an appropriate 159 mechanism for the problem set? Is SIP being selected because of 160 some unique feature provided by the protocol (e.g. user 161 mobility), or merely because "it can be done?" If you find 162 yourself defining SIP extensions for notifications related to, 163 for example, network management or the temperature inside your 164 car's engine, you may want to reconsider your selection of 165 protocols. 167 Those interested in extending the mechanism defined in this 168 document are urged to read "Guidelines for Authors of SIP 169 Extensions" [3] for further guidance regarding appropriate uses 170 of SIP. 172 Further, it is expected that this mechanism is not to be used in 173 applications where the frequency of reportable events is 174 excessively rapid (e.g. more than about once per second). A SIP 175 network is generally going to be provisioned for a reasonable 176 signalling volume; sending a notification every time a user's GPS 177 position changes by one hundreth of a second could easily 178 overload such a network. 180 3.2. Additional Guidelines 182 When writing extensions based on SUBSCRIBE and NOTIFY, it is 183 important to consider the type of information which will be 184 conveyed during a notification. 186 A natural temptation is to convey merely the event (e.g. "a new 187 voice message just arrived") without accompanying state (e.g. "7 188 total voice messages"). This complicates implementation of 189 subscribing entities (since they have to maintain complete state 190 for the entity to which they have subscribed), and also is 191 particularly susceptible to synchronization problems. 193 It is therefore suggested that extensions are designed so as to 194 notify of new state when an event occurs. In the circumstances 195 that state may not be sufficient for a particular class of 196 events, the extensions should include complete state information 197 along with the event that occurred. (For example, "no customer 198 service representatives available" may not be as useful "no 199 customer service representatives available; representative 200 sip:46@cs.xyz.int just logged off".) 202 4. Syntax 204 This section describes the syntax extensions required for event 205 notification in SIP. Semantics are described in section 5. 207 4.1. New Methods 209 This document describes two new SIP methods: "SUBSCRIBE" and 210 "NOTIFY." 212 This table expands on tables 4 and 5 in RFC 2543 [1] . 214 Header Where SUB NOT 215 ------ ----- --- --- 216 Accept R o o 217 Accept-Encoding R o o 218 Accept-Language R o o 219 Allow 200 - - 220 Allow 405 o o 221 Authorization R o o 222 Call-ID gc m m 223 Contact R m m 224 Contact 1xx m o 225 Contact 2xx m o 226 Contact 3xx m m 227 Contact 485 o o 228 Content-Encoding e o o 229 Content-Length e o o 230 Content-Type e * * 231 CSeq gc m m 232 Date g o o 233 Encryption g o o 234 Expires g m o 235 From gc m m 236 Hide R o o 237 Max-Forwards R o o 238 Organization g o o 239 Priority R o o 240 Proxy-Authenticate 407 o o 241 Proxy-Authorization R o o 242 Proxy-Require R o o 243 Require R o o 244 Retry-After R - - 245 Retry-After 404,480,486 o o 246 Retry-After 503 o o 247 Retry-After 600,603 o o 248 Response-Key R o o 249 Record-Route R o o 250 Record-Route 2xx o o 251 Route R o o 252 Server r o o 253 Subject R o o 254 Timestamp g o o 255 To gc(1) m m 256 Unsupported 420 o o 257 User-Agent g o o 258 Via gc(2) m m 259 Warning r o o 260 WWW-Authenticate 401 o o 262 4.1.1. SUBSCRIBE method 263 "SUBSCRIBE" is added to the definition of the element "Method" in 264 the SIP message grammar. 266 Like all SIP method names, the SUBSCRIBE method name is case 267 sensitive. The SUBSCRIBE method is used to request asynchronous 268 notification of an event or set of events at a later time. 270 4.1.2. NOTIFY method 272 "NOTIFY" is added to the definition of the element "Method" in 273 the SIP message grammar. 275 The NOTIFY method is used to notify a SIP node that an event 276 which has been requested by an earlier SUBSCRIBE method has 277 occurred. It may also provide further details about the event. 279 4.2. New Headers 281 This table expands on tables 4 and 5 in RFC 2543 [1] , as amended 282 by the changes described in section 4.1. 284 Header field where proxy ACK BYE CAN INV OPT REG SUB NOT 285 ----------------------------------------------------------------- 286 Allow-Events g o o o o o o o o 287 Event R - - - - - - m m 288 Event r - - - - - - - - 290 4.2.1. "Event" header 292 The following header is defined for the purposes of this 293 extension. 295 Event = "Event" ":" event-type 296 *(( ";" parameter-name 297 ["=" ( token | quoted-string ) ] ) 298 event-type = token 300 Event is added to the definition of the element "general-header" 301 in the SIP message grammar. 303 This document does not define values for event-types. These 304 values will be defined in further extensions that take advantage 305 of the SUBSCRIBE and NOTIFY methods, and SHOULD be registered 306 with the IANA. 308 Note that experimental event types may be created by prepending 309 the organization's internet domain, with the field order reversed 310 (e.g. "Event: com.ericsson.foo"). 312 Further note that there must be exactly one event type listed per 313 event header. Multiple events per message are disallowed. 315 4.2.2. "Allow-Events" Header 317 The following header is defined for the purposes of this 318 extension. 320 Allow-Events = "Allow-Events" ":" 1#event-type 322 Allow-Events is added to the definition of the element 323 "general-header" in the SIP message grammar. 325 4.3. New Response Codes 327 4.3.1. "202 Accepted" Response Code 329 The 202 response is added to the "Success" header field 330 definition: 332 Success = "200" ; OK 333 | "202" ; Accepted 335 "202 Accepted" has the same meaning as that defined in HTTP/1.1 336 [6] . 338 4.3.2. "489 Bad Event" Response Code 340 The 489 event response is added to the "Client-Error" header 341 field definition: 343 Client-Error = "400" ; Bad Request 344 ... 345 | "489" ; Bad Event 347 "489 Bad Event" is used to indicate that the server did not 348 understand the event package specified in a "Event" header field. 350 5. Node Behavior 352 Unless noted otherwise, SUBSCRIBE and NOTIFY requests follow the 353 same protocol rules governing the usage of tags, Route, 354 Record-Route, Via handling, retransmission, reliability, CSeq 355 handling, Contact handling, provisional responses, and message 356 formatting as those defined in RFC 2543 [1] for BYE. 358 Note that neither SUBSCRIBE nor NOTIFY necessitate the use of 359 "Require" or "Proxy-Require" headers; similarly, there is no 360 token defined for "Supported" headers. If necessary, clients may 361 probe for the support of SUBSCRIBE and NOTIFY using the OPTIONS 362 request defined in RFC2543. Note also that the presence of the 363 "Allow-Events" header in a message is sufficient to indicate 364 support for SUBSCRIBE and NOTIFY. 366 For the purposes of generality, both SUBSCRIBE and NOTIFY MAY be 367 canceled; however, doing so is not recommended. Successfully 368 cancelled SUBSCRIBE and NOTIFY requests MUST be completed with a 369 "487 Request Cancelled" response; the server acts as if the 370 request were never received. In general, since neither SUBSCRIBE 371 nor NOTIFY are allowed to have protracted transactions, attempts 372 to cancel them are expected to fail. 374 5.1. Description of SUBSCRIBE Behavior 376 5.1.1. Correlation to legs, calls, and terminals 378 A subscription is uniquely identified by the combination of the 379 To, From, and Call-ID fields in the SUBSCRIBE request. Refreshes 380 of subscriptions SHOULD reuse the same Call-ID if possible, since 381 subscriptions are uniquely identified at presence servers using 382 the Call-ID. Two subscriptions from the same user, for the same 383 user, but with different Call-IDs, are considered different 384 subscriptions. Note this is exactly the same as usage of Call-ID 385 in registrations. 387 The relation between subscriptions and (INVITE-initiated) 388 sessions sharing the same call leg identification information is 389 undefined. Re-using session leg information for subscriptions is 390 discouraged. 392 5.1.2. Subscription duration 394 SUBSCRIBE requests MUST contain an "Expires" header. This expires 395 value indicates the duration of the subscription. The formatting 396 of these is described in RFC 2543. In order to keep subscriptions 397 effective beyond the duration communicated in the "Expires" 398 header, subscribers need to refresh subscriptions on a periodic 399 basis. This refreshing is performed in the same way as REGISTER 400 refreshes: the To, From, and Call-ID match those in the SUBSCRIBE 401 being refreshed, while the CSeq number is incremented. 403 200-class responses to SUBSCRIBE requests also MUST contain an 404 "Expires" header. The period of time in the response MAY be 405 shorter than specified in the request, but MUST NOT be longer. 406 The period of time in the response is the one which defines the 407 duration of the subscription. 409 Similar to REGISTER requests, SUBSCRIBE requests may be renewed 410 at any time to prevent them from expiring at the end of the 411 "Expires" period. These renewals will contain a the same "To," 412 "From," and "Call-ID" as the original request, and an incremented 413 "CSeq" number. 415 Also similar to REGISTER requests, a natural consequence of this 416 scheme is that a SUBSCRIBE with an "Expires" of 0 constitutes a 417 request to unsubscribe from an event. 419 Notifiers may also wish to cancel subscriptions to events; this 420 is useful, for example, when the resource to which a subscription 421 refers is no longer available. Further details on this mechanism 422 are discussed in section 5.2.3. 424 5.1.3. Identification of Subscribed Events and Event Classes 426 Identification of events is provided by three pieces of 427 information: Request URI, Event Type, and (optionally) message 428 body. 430 The Request URI of a SUBSCRIBE request, most importantly, 431 contains enough information to route the request to the 432 appropriate entity. It also contains enough information to 433 identify the resource for which event notification is desired, 434 but not necessarily enough information to uniquely identify the 435 nature of the event (e.g. "sip:adam.roach@ericsson.com" would be 436 an appropriate URI to subscribe to for my presence state; it 437 would also be an appropriate URI to subscribe to the state of my 438 voice mailbox). 440 Subscribers MUST include exactly one "Event" header in SUBSCRIBE 441 requests, indicating to which event or class of events they are 442 subscribing. The "Event" header will contain a single opaque 443 token which identifies the event or class of events for which a 444 subscription is being requested. This token will be registered 445 with the IANA and will correspond to an extension draft which 446 further describes the semantics of the event or event class. 448 The "Event" header is considered mandatory for the purposes of 449 this document. However, to maintain compatibility with PINT (see 450 [4] ), servers MAY interpret a SUBSCRIBE request with no "Event" 451 header as requesting a subscription to PINT events. If the 452 servers do not support PINT, they SHOULD instead return "400 Bad 453 Request." 455 If the extension draft to which the event token corresponds 456 defines behavior associated with the body of its SUBSCRIBE 457 requests, those semantics apply. It is expected that most, but 458 not all, extension drafts will define syntax and semantics for 459 SUBSCRIBE method bodies; these bodies will typically modify, 460 expand, filter, throttle, and/or set thresholds for the class of 461 events being requested. Designers of extensions are strongly 462 encouraged to re-use existing MIME types for message bodies where 463 practical. 465 5.1.4. Additional SUBSCRIBE Header Values 467 The "Contact:" header in a SUBSCRIBE message will contain 468 information about where resulting NOTIFY requests are to be sent. 469 Each SUBSCRIBE request must have exactly one "Contact:" header. 471 SUBSCRIBE requests MAY contain an "Accept" header. This header, 472 if present, indicates the body formats allowed in subsequent 473 NOTIFY requests. Extensions making use of SUBSCRIBE and NOTIFY 474 MUST define the behavior for SUBSCRIBE requests without "Accept" 475 headers; usually, this will connote a single, default body type. 477 Header values not described in this document are to be 478 interpreted as described in RFC 2543 [1] . 480 5.1.5. Subscriber SUBSCRIBE Behavior 482 5.1.5.1. Requesting a Subscription 484 When a subscriber wishes to subscribe to (or refresh a 485 subscription to) an event class, he forms a SUBSCRIBE message. 487 The call leg information is formed as if for an original INVITE: 488 the Call-ID is a new call ID with the syntax described in RFC 489 2543; the To: field indicates the subscribed resource's 490 persistent address (which will generally match the Request URI 491 used to form the message); and the From: field will indicate the 492 subscriber's persistent address (typically sip:user@machine for 493 UAs, or sip:machine for other entities). 495 This SUBSCRIBE request will be confirmed with a final response. 496 200-class responses indicate that the subscriber will be 497 receiving a confirmation of subscription in the form of a NOTIFY 498 message. A 200 response can be interpreted to mean that the 499 requested subscription has succeeded and that a NOTIFY is to be 500 expected immediately. A 202 response indicates that there may be 501 a sizable delay before a notification is received, pending the 502 actual creation of the subscription. For most implementations, 503 there will be no difference in handling these two response codes. 505 The "Expires" header in a 200-class response to SUBSCRIBE 506 indicates the actual duration for which the subscription will 507 remain active (unless refreshed). 509 Non-200 class final responses indicate that the subscription has 510 not been created, and no subsequent NOTIFY message will be sent. 511 All non-200 class responses (with the exception of "489," 512 described herein) have the same meanings and handling as 513 described in RFC 2543 [1] . 515 5.1.5.2. Refreshing of Subscriptions 517 At any time before a subscription expires, the subscriber may 518 refresh the timer on such a subscription by re-sending a 519 SUBSCRIBE request. The handling for such a request is the same as 520 for the initial creation of a subscription, with the exception 521 that these renewals will contain a the same "To," "From," and 522 "Call-ID" as the original SUBSCRIBE request, and an incremented 523 "CSeq" number. 525 If a SUBSCRIBE request to refresh a subscription fails, the 526 original subscription is still considered valid for the duration 527 of the most recently known "Expires" value as negotiated by 528 SUBSCRIBE and its response, or as communicated by NOTIFY. 530 5.1.5.3. Unsubscribing 532 Unsubscribing is handled in the same way as refreshing of a 533 subscription, with the "Expires" header set to "0." Note that a 534 successful unsubscription will also trigger a final "NOTIFY". 536 5.1.5.4. Confirmation of Subscription Creation 538 The subscriber can expect to receive a NOTIFY message from each 539 node which has registered a successful subscription or 540 subscription refresh. Until the first NOTIFY message(s) arrive, 541 the subscriber should consider the state of the subscribed 542 resource to be in an undefined state. Extension drafts which 543 define new event packages MUST define this "undefined state" in 544 such a way that makes sense for their application. 546 Due to the potential for both out-of-order messages and forking, 547 the subscriber MUST be prepared to receive NOTIFY messages before 548 the SUBSCRIBE transaction has completed. 550 Except as noted above, processing of this NOTIFY is the same as 551 in section 5.2.5. 553 5.1.6. Proxy SUBSCRIBE Behavior 555 Proxies need no additional behavior beyond that described in RFC 556 2543 [1] to support SUBSCRIBE. Note that SIP proxies may also act 557 as subscribers or notifiers, as appropriate; under these 558 circumstances, they will act as described in 5.1.5. and 5.1.7. 560 5.1.7. Notifier SUBSCRIBE Behavior 562 5.1.7.1. SUBSCRIBE Transaction Processing 564 In no case should a SUBSCRIBE transaction extend for any longer 565 than the time necessary for automated processing. In particular, 566 notifiers MUST NOT wait for a user response before returning a 567 final response to a SUBSCRIBE request. 569 The notifier SHOULD check that the event package specified in the 570 "Event" header is understood. If not, the notifier SHOULD return 571 a "489 Bad Event" response to indicate that the specified 572 event/event class is not understood. 574 The notifier SHOULD also perform any necessary authentication and 575 authorization per its local policy. See section 5.1.7.3. 577 If the notifier is able to immediately determine that it 578 understands the event package, that the authenticated subscriber 579 is authorized to subscribe, and that there are no other barriers 580 to creating the subscriptions, it creates the subscription and 581 returns a "200 OK" response. 583 If the notifier cannot immediately create the subscription (e.g. 584 it needs to wait for user input for authorization, or is acting 585 for another node which is not currently reachable), it will 586 return a "202 Accepted" response. This response indicates that 587 the request has been received and understood, but that no action 588 has yet taken place. 590 The "Expires" values present in SUBSCRIBE 200-class responses 591 behave in the same way as they do in REGISTER responses: the 592 server MAY shorten the interval, but MUST not increase it. 594 200-class responses to SUBSCRIBE requests will not generally 595 contain any useful information beyond subscription duration; 596 their primary purpose is to serve as a reliability mechanism. 597 State information will be communicated via a subsequent NOTIFY 598 request from the notifier. 600 The other response codes defined in RFC 2543 may be used in 601 response to SUBSCRIBE requests, as appropriate. 603 5.1.7.2. Confirmation of Subscription Creation/Refreshing 605 Upon successful creation or refreshing of a subscription, 606 notifiers MUST send a NOTIFY message as soon as practical to 607 communicate the current resource state to the subscriber. If the 608 resource has no meaningful state at the time that the SUBSCRIBE 609 message is processed, this NOTIFY message MAY contain an empty 610 body. See section 5.2.3. for further details on NOTIFY message 611 generation. 613 If the response to the SUBSCRIBE message was 202, this initial 614 NOTIFY will serve as indication that the subscription has finally 615 been processed. In the case that the subscription has not been 616 created (e.g. the notifier was waiting for authorization and such 617 authorization failed), the notifier SHOULD indicate to the 618 subscriber that the subscription does has not been created by 619 setting the "Expires" header to "0" in this initial NOTIFY 620 response. 622 5.1.7.3. Authentication/Authorization of SUBSCRIBE requests 624 Note that privacy concerns may require that notifiers either use 625 access lists or ask the notifier owner, on a per-subscription 626 basis, whether a particular remote node is authorized to 627 subscribe to a certain set of events. In general, authorization 628 of users prior to authentication is not particularly useful. 630 SIP authentication mechanisms are discussed in RFC2543 [1] . Note 631 that, even if the notifier node typically acts as a proxy, 632 authentication for SUBSCRIBE requests will always be performed 633 via a "401" response, not a "407;" notifiers always act as a user 634 agents when accepting subscriptions and sending notifications. 636 If authorization fails based on an access list or some other 637 automated mechanism (i.e. it can be automatically authoritatively 638 determined that the subscriber is not authorized to subscribe), 639 the notifier SHOULD reply to the request with a "403 Forbidden" 640 or "603 Decline" response, as appropriate. Depending on the 641 situation, such a response may have security implications; see 642 section 6. 644 If the notifier owner is interactively queried to determine 645 whether a subscription is allowed, a "202 Accept" response is 646 returned immediately, and the subsequent NOTIFY request is 647 suppressed until the notifier owner responds. 649 5.1.7.4. Refreshing of Subscriptions 651 When a notifier receives a subscription refresh, assuming that 652 the subscriber is still authorized, the notifier updates the 653 expiration time for the "Contact:" address present in the 654 SUBSCRIBE. As with the initial subscription, the server MAY lower 655 the amount of time until expiration, but MUST NOT increase it. 656 The final expiration time is placed in the Expires header in the 657 response. 659 If no refresh for a notification address is received before its 660 expiration time, that address is removed from the list of 661 addresses. When removing a contact, the notifier MAY send a 662 NOTIFY message to that contact with an "Expires" value of "0" to 663 inform it that the subscription is being removed. If all 664 notification addresses are removed, the entire subscription is 665 deleted. 667 5.2. Description of NOTIFY Behavior 669 Note that a NOTIFY does not cancel its corresponding 670 subscription; in other words, a single SUBSCRIBE request may 671 trigger several NOTIFY requests. 673 5.2.1. Correlation 675 NOTIFY requests MUST contain the same Call-ID, local URI, and 676 remote URI as the SUBSCRIBE request which ordered them. This is 677 the same set of criteria that define a call leg. 679 The From field of a NOTIFY request MUST contain a tag; this 680 allows for the subscriber to differentiate between events from 681 different notifiers. 683 Note that successful SUBSCRIBE requests will receive only one 684 200-class response; however, due to forking, the subscription may 685 have been accepted by multiple nodes. The subscriber MUST 686 therefore be prepared to receive NOTIFY requests with "From:" 687 tags which differ from the "To:" tag received in the SUBSCRIBE 688 200-class response. 690 As expected, CSeq spaces are unique for each node; in other 691 words, the notifier uses a different CSeq space than the 692 subscriber and any other notifiers. 694 5.2.2. Identification of reported events, event classes, and current 695 state 697 Identification of events being reported in a notification is very 698 similar to that described for subscription to events (see section 699 5.1.3. ). 701 The Request URI of a NOTIFY request contains enough information 702 to route the request to the party which is subscribed to receive 703 notifications. It is derived from the "Contact" header present in 704 the corresponding SUBSCRIBE request. 706 If the same events for different resources are being subscribed 707 to, implementors are expected to use different "Call Legs" (To, 708 From, Call-ID) in order to be able to differentiate between 709 notifications for them, unless the body for the event contains 710 enough information for this correlation. 712 As in SUBSCRIBE requests, NOTIFY "Event" headers will contain a 713 single opaque token which identifies the event or class of events 714 for which a notification is being generated. 716 If the extension draft to which the event token corresponds 717 defines behavior associated with the body of its NOTIFY requests, 718 those semantics apply. This information is expected to provide 719 additional details about the nature of the event which has 720 occurred and the resultant resource state. 722 When present, the body of the NOTIFY request MUST be formatted 723 into one of the body formats specified in the "Accept" header of 724 the corresponding SUBSCRIBE request. The formatting rules and 725 behavior when no "Accept" header is present are expected to be 726 defined by the document which describes the relevant event 727 package. 729 Note that NOTIFY requests MAY be sent without a matching 730 SUBSCRIBE under certain circumstances. It may make sense, for 731 example, to set up a subscription using an out-of-band mechanism 732 (e.g. HTTP, static provisioning). A subscriber which is designed 733 to operate in this fashion MUST be prepared to receive NOTIFY 734 requests without a corresponding call leg. 736 5.2.3. Notifier NOTIFY Behavior 738 When a SUBSCRIBE request is successfully processed or a relevant 739 change in the subscribed state occurs, the notifier will 740 construct and send a NOTIFY request to the subscriber(s), as 741 specified in the "Contact" field of the SUBSCRIBE request. Such a 742 message should be sent in as timely a manner as is practical. 744 If the notifier is able, through any means, to determine that the 745 subscriber is no longer available to receive notifications, it 746 MAY elect to not send a notification. An example of a method by 747 which such information may be known is the "SIP for Presence" 748 event set (see [5] ). 750 If the original subscription contained a "Record-Route" header, 751 notifications are sent according to the rules outlined in RFC 752 2543 [1] , as if the SUBSCRIBE were an INVITE, and the NOTIFY 753 were any subsequent message (e.g. BYE). 755 Notify requests MUST contain a "Contact" header. This contact 756 header is used by the subscriber in building "Route" headers for 757 subsequent subscriptions (i.e. refreshes). 759 A NOTIFY request is considered failed if the response times out, 760 or a non-200 class response code is received which has no 761 "Retry-After" header and no implied further action which can be 762 taken to retry the request (e.g. "401 Authorization Required.") 764 If the response to a NOTIFY request fails, the notifier MUST 765 remove the contact from the appropriate subscription. If removal 766 of the contact leaves no remaining contacts, the entire 767 subscription is removed. 769 NOTIFY requests MAY contain an "Expires" header which indicates 770 the remaining duration of the subscription. The notifier MAY use 771 this header to adjust the time remaining on the subscription; 772 however, this mechanism MUST not be used to lengthen a 773 subscription, only to shorten it. The notifier may inform a 774 subscriber that a subscription has been removed by sending a 775 NOTIFY message with an "Expires" value of "0." 777 5.2.4. Proxy NOTIFY Behavior 779 Proxies need no additional behavior beyond that described in RFC 780 2543 [1] to support NOTIFY. 782 5.2.5. Subscriber NOTIFY Behavior 784 Upon receiving a NOTIFY request, the subscriber should check that 785 it matches at least one of its outstanding subscriptions; if not, 786 it SHOULD return a "481 Call leg/transaction does not exist" 787 response. 789 A notable exception to the above behavior will occur when clients 790 are designed to receive NOTIFY messages for subscriptions set up 791 via any means other than a SUBSCRIBE message (e.g. HTTP requests, 792 static provisioning). Such clients will need to, under certain 793 circumstances, process unmatched NOTIFY requests as if they had 794 previous knowledge of the subscription. 796 If, for some reason, the event package designated in the "Event" 797 header of the NOTIFY request is not supported, the subscriber 798 should respond with a "489 Bad Event" response. 800 To prevent spoofing of events, NOTIFY requests MAY be 801 authenticated, using any defined SIP authentication mechanism. 803 NOTIFY requests may contain "Expires" headers which indicate the 804 time remaining on the subscription. If this header is present, 805 the subscriber SHOULD take it as the authoritative duration and 806 adjust accordingly. If an expires value of "0" is present, the 807 subscriber should consider the subscription terminated. 809 Once the notification is deemed acceptable to the subscriber, the 810 subscriber SHOULD return a 200 response. In general, it is not 811 expected that NOTIFY responses will contain bodies; however, they 812 MAY, if the NOTIFY request contained an "Accept" header. 814 Other responses defined in RFC 2543 [1] may also be returned, as 815 appropriate. 817 Extension drafts should describe appropriate handling for the 818 situation in which NOTIFY requests are received from multiple 819 notifiers. In general, such handling will involve a simple 820 merging of the received notifications into a single, overall 821 state. 823 5.3. Polling Resource State 825 A natural consequence of the behavior described in the preceding 826 sections is that an immediate fetch without a persistent 827 subscription may be effected by sending an appropriate SUBSCRIBE 828 with an "Expires" of 0. 830 Of course, an immediate fetch while a subscription is active may 831 be effected by sending an appropriate SUBSCRIBE with an "Expires" 832 greater than 0. 834 Upon receipt of this SUBSCRIBE request, the notifier (or 835 notifiers, if the SUBSCRIBE request was forked) will send a 836 NOTIFY request containing resource state to the address in the 837 SUBSCRIBE "Contact" field. 839 5.4. Allow-Events header usage 841 The "Allow-Events" header, if present, includes a list of tokens 842 which indicate the event packages supported by the client (if 843 sent in a request) or server (if sent in a response). 845 Any node implementing one or more event packages SHOULD include 846 an appropriate "Allow-Events" header indicating all supported 847 events in INVITE requests and responses, OPTIONS responses, and 848 REGISTER requests. "Allow-Events" headers MAY be included in any 849 other type of request or response. 851 This information is very useful, for example, in allowing user 852 agents to render particular interface elements appropriately 853 according to whether the events required to implement the 854 features they represent are supported by the appropriate nodes. 856 6. Security Considerations 857 The ability to accept subscriptions should be under the direct 858 control of the user, since many types of events may be considered 859 sensitive for the purposes of privacy. Similarly, the user agent 860 should have the ability to selectively reject subscriptions based 861 on the calling party (using either a white-list or black-list 862 functionality), and/or using standard SIP authentication 863 mechanisms. 865 The mere act of returning a "403 Forbidden" or "603 Decline" 866 response code to a SUBSCRIBE request may, under certain very rare 867 circumstances, pose privacy concerns. In these cases, the 868 notifier may elect to return a 200 or 202 response and send a 869 NOTIFY message with (possibly erroneous) state. Note that this 870 behavior is a rare exception, and should not be exhibited without 871 justification. 873 7. Open Issues 875 7.1. Event Agents 877 The SIP for Presence draft (draft-rosenberg-impp-presence-00.txt) 878 describes a mechanism by which presentities having access to 879 registration information can accept registrations on behalf of 880 user agents incapable of processing SUBSCRIBE requests. This is a 881 very useful concept; however, it does not seem to be 882 generalizable to all classes of events. Should this draft make 883 explicit provisions for this capability, or should it remain 884 defined in the SIP for Presence draft as behavior specific to the 885 "presence" event package? 887 The only comments I've received on this issue so far favor 888 deciding that this premise is not generally applicable, removing 889 it as an open issue. 891 7.2. Event Throttling 893 Is the concept of throttling events (e.g. "never inform me of 894 events more frequently than once every n seconds, no matter 895 what") useful enough across all event types that we should define 896 a top-level mechanism for this, or do we let extension drafts 897 that might benefit from this sort of scheme define their own 898 throttles? 900 The comments I've received on this topic are split between 901 suggesting that event packages should define their own throttles, 902 if appropriate, and suggesting that a general-purpose throttle 903 mechanism would save event-package creators unnecessary 904 re-invention of the same concepts. Supporting arguments for both 905 viewpoints should be taken to the sip-events mailing list, please 906 (see section 11. ) 908 7.3. Resource identification for out-of-band subscriptions 910 In this draft, we explicitly allow subscriptions to be put into 911 place via a mechanism other than a SUBSCRIBE request. Many people 912 believe that sanctioning of such behavior in the base draft is 913 important. It raises an interesting issue, however, that is 914 probably not completely appropriate for this draft to solve. For 915 documentation purposes, the problem is this: In a SUBSCRIBE 916 request, the request URI is used to identify the resource 917 (although not the event) to which a subscription is requested; If 918 there is no explicit SUBSCRIBE, this information doesn't really 919 exist anywhere. 921 I get the general feeling that this problem isn't well understood 922 by the community, and that it deserves a great deal more thought 923 than it's receiving. 925 8. Changes 927 8.1. Changes from -02 929 - Clarification under "Notifier SUBSCRIBE behavior" which 930 indicates that the first NOTIFY message (sent immediately 931 in response to a SUBSCRIBE) may contain an empty body, if 932 resource state doesn't make sense at that point in time. 934 - Text on message flow in overview section corrected 936 - Removed suggestion that clients attempt to unsubscribe 937 whenever they receive a NOTIFY for an unknown event. 938 Such behavior opens up DOS attacks, and will lead to 939 message loops unless additional precautions are taken. 940 The 481 response to the NOTIFY should serve the same 941 purpose. 943 - Changed processing of non-200 responses to NOTIFY from 944 "SHOULD remove contact" to "MUST remove contact" to support 945 the above change. 947 - Re-added discussion of out-of-band subscription mechanisms 948 (including open issue of resource identification). 950 - Added text specifying that SUBSCRIBE transactions are not 951 to be prolonged. This is based on the consensus that non-INVITE 952 transactions should never be prolonged; such consensus within 953 the SIP working group was reached at the 49th IETF. 955 - Added "202 Accepted" response code to support the above 956 change. The behavior of this 202 response code is a 957 generalization of that described in the presence draft [5] . 959 - Updated to specify that the response to an unauthorized 960 SUBSCRIBE request is 603 or 403. 962 - Level-4 subheadings added to particularly long sections to 963 break them up into logical units. This helps make the 964 behavior description seem somewhat less rambling. This also 965 caused some re-ordering of these paragraphs (hopefully in a 966 way that makes them more readable). 968 - Some final mopping up of old text describing "call related" 969 and "third party" subscriptions (deprecated concepts). 971 - Duplicate explanation of subscription duration removed from 972 subscriber SUBSCRIBE behavior section. 974 - Other text generally applicable to SUBSCRIBE (instead of just 975 subscriber handling of SUBSCRIBE) moved to parent section. 977 - Updated header table to reflect mandatory usage of "Expires" 978 header in SUBSCRIBE requests and responses 980 - Removed "Event" header usage in responses 982 - Added sentence suggesting that notifiers may notify 983 subscribers when a subscription has timed out. 985 - Clarified that a failed attempt to refresh a subscription 986 does not imply that the original subscription has been 987 cancelled. 989 - Clarified that 489 is a valid response to "NOTIFY" requests. 991 - Minor editorial changes to clean up awkward and/or unclear 992 grammar in several places 994 8.2. Changes from -01 996 - Multiple contacts per SUBSCRIBE message disallowed. 998 - Contact header now required in NOTIFY messages. 1000 - Distinction between third party/call member events removed. 1002 - Distinction between call-related/resource-related events removed. 1004 - Clarified that subscribers must expect NOTIFY messages before 1005 the SUBSCRIBE transaction completes 1007 - Added immediate NOTIFY message after successful SUBSCRIBE; 1008 this solves a myriad of issues, most having to do with forking. 1010 - Added discussion of "undefined state" (before a NOTIFY arrives). 1012 - Added mechanism for notifiers to shorten/cancel outstanding 1013 subscriptions. 1015 - Removed open issue about appropriateness of new "489" response. 1017 - Removed all discussion of out-of-band subscriptions. 1019 - Added brief discussion of event state polling. 1021 9. References 1023 [1] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: 1024 Session Initiation Protocol", RFC 2543, IETF; March 1999. 1026 [2] Adam Roach, "Automatic Call Back Service in SIP", Internet 1027 Draft , IETF; March 2000. Work in 1028 progress. 1030 [3] J. Rosenberg, H. Schulzrinne, "Guidelines for Authors of SIP 1031 Extensions", , IETF; July 1032 2000. Work in progress. 1034 [4] S. Petrack, L. Conroy, "The PINT Service Protocol", RFC 2848, 1035 IETF; June 2000. 1037 [5] J. Rosenberg et. al., "SIP Extensions for Presence", 1038 , IETF; June 2000. Work 1039 in progress. 1041 [6] R. Fielding et. al., "Hypertext Transfer Protocol -- 1042 HTTP/1.1", RFC2068, IETF, January 1997. 1044 10. Credits 1046 Thanks to the participants in the Events BOF at the 48th IETF 1047 meeting in Pittsburgh, as well as those who gave ideas and 1048 suggestions on the SIP Events mailing list. In particular, I wish 1049 to thank Henning Schulzrinne of Columbia University for coming up 1050 with the final three-tiered event identification scheme, Sean 1051 Olson of Ericsson for miscellaneous guidance, and the authors of 1052 the "SIP Extensions for Presence" draft for their input to 1053 SUBSCRIBE and NOTIFY request semantics. 1055 11. Feedback and Discussion 1057 Comments regarding this draft are welcomed at the address listed 1058 below. 1060 General-purpose discussion of asynchronous event topics, 1061 including this draft, should be taken on the sip-events mailing 1062 list (and NOT the general-purpose SIP mailing list). To 1063 subscribe, go to http://groups.yahoo.com/group/sip-events 1065 12. Author's Address 1067 Adam Roach 1068 Ericsson Inc. 1069 Mailstop L-04 1070 851 International Pkwy. 1072 Richardson, TX 75081 1073 USA 1074 Phone: +1 972 583 7594 1075 Fax: +1 972 669 0154 1076 E-Mail: adam.roach@ericsson.com