idnits 2.17.1 draft-sparks-sipcore-refer-explicit-subscription-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2014) is 3475 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) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Sparks 3 Internet-Draft Oracle 4 Intended status: Standards Track October 21, 2014 5 Expires: April 24, 2015 7 Explicit Subscriptions for the REFER Method 8 draft-sparks-sipcore-refer-explicit-subscription-02 10 Abstract 12 The Session Initiation Protocol (SIP) REFER request, as defined by 13 RFC3515, triggers an implicit SIP-Specific Event Notification 14 framework subscription. Conflating the start of the subscription 15 with handling the REFER request makes negotiating SUBSCRIBE 16 extensions impossible, and complicates avoiding SIP dialog sharing. 17 This document defines extensions to REFER to remove the implicit 18 subscription and, if desired, replace it with an explicit one. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 24, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Explicit Subscriptions . . . . . . . . . . . . . . . . . 3 58 3.2. No Subscriptions . . . . . . . . . . . . . . . . . . . . 4 59 4. The Explicit Subscription Extension . . . . . . . . . . . . . 5 60 4.1. Sending a REFER . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. Processing a REFER Response . . . . . . . . . . . . . . . 5 62 4.3. Processing a Received REFER . . . . . . . . . . . . . . . 5 63 4.4. Subscribing to the 'refer' Event . . . . . . . . . . . . 6 64 4.5. Processing a Received SUBSCRIBE . . . . . . . . . . . . . 7 65 4.6. Sending a NOTIFY . . . . . . . . . . . . . . . . . . . . 7 66 4.7. Managing 'refer' Event State . . . . . . . . . . . . . . 7 67 4.8. The Refer-Events-At Header Field . . . . . . . . . . . . 8 68 5. The No Subscription Extension . . . . . . . . . . . . . . . . 8 69 5.1. Sending a REFER . . . . . . . . . . . . . . . . . . . . . 8 70 5.2. Processing a REFER Response . . . . . . . . . . . . . . . 8 71 5.3. Processing a Received REFER . . . . . . . . . . . . . . . 9 72 6. The 'explicitsub' and 'nosub' Option Tags . . . . . . . . . . 9 73 7. Updates to RFC 3515 . . . . . . . . . . . . . . . . . . . . . 10 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 9.1. Register the 'explicitsub' Option Tag . . . . . . . . . . 11 77 9.2. Register the 'nosub' Option Tag . . . . . . . . . . . . . 11 78 9.3. Register the 'Refer-Events-At' Header Field . . . . . . . 11 79 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 10.1. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 12 81 10.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 12 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 84 11.2. Informative References . . . . . . . . . . . . . . . . . 13 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Conventions and Definitions 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. Introduction 95 REFER as defined by [RFC3515] triggers an implicit SIP-Specific Event 96 Framework subscription. Sending a REFER within a dialog established 97 by an INVITE results in dialog reuse and the associated problems 98 described in [RFC5057]. The SIP-Specific Event Notification 99 framework definition [RFC6665] disallows such dialog reuse. Call 100 transfer, as defined in [RFC5589], thus requires sending a REFER 101 request on a new dialog, associating it with an existing dialog using 102 the 'Target-Dialog' mechanism defined in [RFC4538]. 104 Because there is no explicit SUBSCRIBE request, the tools for 105 negotiating subscription details are unavailable for REFER 106 subscriptions. This includes negotiating subscription duration and 107 providing information through Event header field parameters. The use 108 of the SIP 'Supported' and 'Require' extension mechanisms [RFC3261] 109 is complicated by the implicit subscription. It is unclear whether 110 the extension applies to handling the REFER request itself, or to the 111 messages in the subscription created by the REFER, or both. Avoiding 112 this confusion requires careful specification in each extension. 113 Existing extensions do not provide this clarity. 115 This document defines two mechanisms that remove the implicit 116 subscription, one of which replaces it with an explicit one. The 117 benefits of doing so include: 119 o Allowing REFER to be used within INVITE-created dialogs without 120 creating dialog reuse. 122 o Allowing standard subscription parameter negotiation. 124 o Allowing standard negotiation of SIP extensions. 126 There are limitations on when it is appropriate to use the extension 127 that allows an explicit subscription, related directly to definition 128 of non-INVITE transaction handling SIP. These limitations are 129 discussed in Section 4.1. 131 3. Overview 133 This section provides a non-normative overview of the behaviors 134 defined in subsequent sections. 136 3.1. Explicit Subscriptions 138 A SIP User-Agent (UA) that wishes to issue a REFER request that will 139 not create an implicit subscription, but will allow an explicit one, 140 will include a new option tag, 'explicitsub', in the Require header 141 field of the REFER request. This REFER could be sent either within 142 an existing dialog, or as an out-of-dialog request. 144 If the recipient of the REFER accepts the request, it will begin 145 managing the 'refer' event state described in RFC 3515, and will 146 provide a URI that will reach an event server that will service 147 subscriptions to that state. (In many cases, the recipient of the 148 REFER will perform the role of event server itself.) That URI is 149 returned in a new header field in the REFER response named 'Refer- 150 Events-At'. 152 The UA that issued the REFER can now subscribe to the 'refer' event 153 at the provided URI, using a SUBSCRIBE request with a new dialog 154 identifier. The full range of negotiation mechanisms is available 155 for its use in that request. As detailed in RFC 6665 and RFC 3515, 156 the event server accepting the subscription will send an immediate 157 NOTIFY with the current refer event state, additional NOTIFY messages 158 as the refer state changes, and a terminal NOTIFY message when the 159 referred action is complete. It is, of course, possible that the 160 initial NOTIFY is also the terminal NOTIFY. 162 It is possible that the referred action is completed before the 163 SUBSCRIBE arrives at the event server. The server needs to retain 164 the final refer event state for some period of time to include in the 165 terminal NOTIFY that will be sent for such subscriptions. It is also 166 possible that a SUBSCRIBE will never arrive. 168 This extension makes it possible to separate the event server that 169 will handle subscriptions from the UA that accepted the REFER. Such 170 a UA could use mechanisms such as PUBLISH [RFC3903] to convey the 171 refer event state to the event server. This extension also makes it 172 possible to allow more than one subscription to the refer event 173 state. 175 3.2. No Subscriptions 177 A UA that wishes to issue a REFER request that will not create an 178 implicit subscription, and tell the recipient that it is not 179 interested in creating an explicit subscription, will include a new 180 option tag, 'nosub', in the Require header field of the REFER 181 request. This REFER could be sent either within an existing dialog 182 or as an out-of-dialog request. 184 If the recipient of the REFER accepts the request, it knows not to 185 create an implicit subscription, and that no explicit subscription 186 will be forthcoming. The recipient will continue to process the 187 request indicated in the Refer-To header field as specified in RFC 188 3515, but it can avoid the cost of preparing to handle any 189 subscriptions to the state of handling that request. 191 4. The Explicit Subscription Extension 193 4.1. Sending a REFER 195 To suppress the creation of any implicit subscription, and allow for 196 an explicit one, a UA forming a REFER request will include the option 197 tag 'explicitsub' in the "Require" header field of the request. The 198 REFER request is otherwise formed following the requirements of 199 [RFC3515]. Since this REFER has no chance of creating an implicit 200 subscription, the UA MAY send the REFER request within an existing 201 dialog or out-of-dialog. 203 Note that if the REFER forks (see [RFC3261]), only one final response 204 will be returned to the issuing UA. If it is important that the UA 205 be able to subscribe to any refer state generated by accepting this 206 request, the request needs to be formed to limit the number of places 207 that it will be accepted to one. This can be achieved by sending the 208 REFER request within an existing dialog, or by using the Target- 209 Dialog mechanism defined in [RFC4538]. If it is possible for the 210 request to be accepted in more than one location, and things would go 211 wrong if the UA did not learn about each location that the request 212 was accepted, using this extension is not appropriate. 214 4.2. Processing a REFER Response 216 The UA will process responses to the REFER request as specified in 217 [RFC3515] (and, consequently, [RFC3261]). In particular, if the 218 REFER was sent to an element that does not support or is unwilling to 219 use this extension, the response will contain a 420 Bad Extension 220 response code (see section 8.1.3.5 of [RFC3261]). As that document 221 states, the UA can retry the request without using this extension. 223 If the UA receives a 2xx-class response, it will contain a Refer- 224 Events-At header field (Section 4.8) with a single URI as its value. 225 If the UA is interested in the state of the referenced action, it 226 will subscribe to the 'refer' event at that URI. 228 4.3. Processing a Received REFER 230 An element receiving a REFER request requiring the 'explicitsub' 231 extension will use the same admissions policies that would be used 232 without the extension, with the addition that it is acceptable to 233 admit an in-dialog REFER request requiring this extension since it 234 can not create another usage inside that dialog. In particular, see 235 section 5.2 of [RFC3515]. 237 Accepting a REFER request that requires 'explicitsub' does not create 238 a dialog, or a new usage within an existing dialog. The element MUST 239 NOT create an implicit subscription when accepting the REFER request. 241 An element that accepts a REFER request with 'explicitsub' in its 242 Require header field MUST return a 200 response containing a sip: or 243 sips: URI that can be used to subscribe to the refer event state 244 associated with this REFER request. This URI MUST uniquely identify 245 this refer event state. The URI needs to reach the event server when 246 used in a SUBSCRIBE request from the element that sent the REFER. 247 One good way to ensure the URI provided has that property is to use a 248 GRUU [RFC5627] for the event server. As discussed in Section 8, 249 possession of this URI is often the only requirement for authorizing 250 a subscription to it. Implementations may wish to provide a URI 251 constructed in a way that is hard to guess. Again, using a GRUU is 252 one good way to achieve this property. 254 The accepting element will otherwise proceed with the processing 255 defined in [RFC3515]. 257 The event server identified by the Refer-Events-At URI could receive 258 SUBSCRIBE requests at any point after the response containing the 259 Refer-Events-At header is sent. Implementations should take care to 260 ensure the event server is ready to receive those SUBSCRIBE requests 261 before sending the REFER response, but as with all non-INVITE 262 responses, the response should be sent as soon as possible (see 263 [RFC4321]). It is also possible that the referred action may 264 complete before any SUBSCRIBE request arrives. The event server will 265 need to maintain the final refer event state for a period of time 266 after the action completes in order to serve such subscriptions (see 267 Section 4.6). 269 4.4. Subscribing to the 'refer' Event 271 A UA that possesses a URI obtained from a Refer-Events-At header 272 field, MAY subscribe to the refer event state at that URI. It does 273 so following the requirements of [RFC6665], placing the token 'refer' 274 in the Event: header field and the URI in the Request-URI of the 275 SUBSCRIBE request. The SUBSCRIBE request MUST NOT reuse any existing 276 dialog identifiers. 278 Subsequent handling of the subscription MUST follow the requirements 279 of [RFC6665] and [RFC3515]. In particular, as discussed in section 280 2.4.6, the NOTIFY messages in the subscription might include an id 281 parameter in their Event header fields. Subsequent SUBSCRIBE 282 requests used to refresh or terminate this subscription MUST contain 283 this id parameter. Note that the rationale for the id parameter 284 provided in that section is not relevant when this extension is used. 286 The URI returned in the Refer-Events-At header field uniquely 287 identifies appropriate state, making the id parameter redundant. 288 However, this behavioral requirement is preserved to reduce the 289 number of changes to existing implementations in order to support 290 this extension, and to make it more likely that existing diagnostic 291 tools will work with little or no modification. 293 4.5. Processing a Received SUBSCRIBE 295 An event server receiving a SUBSCRIBE request will process it 296 according to the requirements of [RFC6665]. The event server MAY 297 choose to authorize the SUBSCRIBE request based on the Request-URI 298 corresponding to existing refer event state. It MAY also require 299 further authorization as discussed in Section 8. 301 When accepting a subscription, the event server will establish the 302 initial subscription duration using the guidance in section 3.4 of 303 [RFC3515]. 305 4.6. Sending a NOTIFY 307 NOTIFY messages within a subscription are formed and sent following 308 the requirements in [RFC3515]. See, in particular, section 2.4.5 of 309 that document. 311 4.7. Managing 'refer' Event State 313 As described in [RFC3515], an element creates the state for event 314 'refer' when it accepts a REFER request. It updates that state as 315 the referred request proceeds, ultimately reaching a state where the 316 request has completed, and the final state is known. 318 In RFC 3515 implementations, it was a reasonable design choice to 319 destroy the refer event state immediately after sending the NOTIFY 320 that terminated the implicit subscription. This is not the case when 321 using this extension. It is possible for the referenced request to 322 complete very quickly, perhaps sooner than the time it takes the 323 response to the REFER to traverse the network to the UA that sent the 324 request, and the time it takes that agent to send the SUBSCRIBE 325 request for the event state to the URI the response provides. Thus 326 the event server MUST retain the final refer event state for a 327 reasonable period of time, which SHOULD be at least 2*64*T1 (that is, 328 64 seconds), representing an upper-bound estimate of the time it 329 would take to complete two non-INVITE transactions: the REFER, and an 330 immediate SUBSCRIBE. 332 If an otherwise acceptable SUBSCRIBE arrives during this retention 333 period, the subscription would be accepted, and immediately 334 terminated with a NOTIFY containing the final event state with a 335 Subscription-State of terminated with a reason value of "noresource". 337 4.8. The Refer-Events-At Header Field 339 The 'Refer-Events-At' header field is an extension-header as defined 340 by [RFC3261]. Its ABNF is as follows: 342 Refer-Events-At: "Refer-Events-At" HCOLON 343 LAQUOT ( SIP-URI / SIPS-URI ) RAQUOT 344 * ( SEMI generic-param ) 346 See [RFC3261] for the definition of the elements used in that 347 production. 349 Note that this rule does not allow a full addr-spec as defined in RFC 350 3261, and it mandates the use of the angle brackets. That is: 352 Refer-Events-At: 354 is well formed, but 356 Refer-Events-At: sip:wsXa9mkHtPcGu8@example.com 358 is invalid. 360 The 'Refer-Events-At' header field is only meaningful in a 200 361 response to a REFER request. If it appears in the header of any 362 other SIP message, its meaning is undefined and it MUST be ignored. 364 5. The No Subscription Extension 366 5.1. Sending a REFER 368 To suppress the creation of any implicit subscription, and signal 369 that no explicit subscription will be forthcoming, a UA forming a 370 REFER request will include the option tag 'nosub' in the "Require" 371 header field of the request. The REFER request is otherwise formed 372 following the requirements of [RFC3515]. Since this REFER has no 373 chance of creating an implicit subscription, the UA MAY send the 374 REFER request within an existing dialog or out-of-dialog. 376 5.2. Processing a REFER Response 378 The UA will process responses to the REFER request as specified in 379 [RFC3515] (and, consequently, [RFC3261]). In particular, if the 380 REFER was sent to an element that does not support or is unwilling to 381 use this extension, the response will contain a 420 Bad Extension 382 response code (see section 8.1.3.5 of [RFC3261]). As that document 383 states, the UA can retry the request without using this extension. 385 5.3. Processing a Received REFER 387 An element receiving a REFER request requiring the 'nosub' extension 388 will use the same admissions policies that would be used without the 389 extension, with the addition that it is acceptable to admit an in- 390 dialog REFER request requiring this extension since it can not create 391 another usage inside that dialog. In particular, see section 5.2 of 392 [RFC3515]. 394 Accepting a REFER request that requires 'nosub' does not create a 395 dialog, or a new usage within an existing dialog. The element MUST 396 NOT create an implicit subscription when accepting the REFER request. 397 Futhermore, the element accepting the REFER request is not required 398 to maintain any state for serving refer event subscriptions. 400 The accepting element will otherwise proceed with the processing 401 defined in [RFC3515]. 403 6. The 'explicitsub' and 'nosub' Option Tags 405 This document defines the 'explicitsub' option tag, used to signal 406 the use of the extension defined in Section 4, and the 'nosub' option 407 tag, used to signal the use of the extension defined in Section 5. 409 The use of either option tag in a Require header field is only 410 defined when it appears in a REFER request. A UA MUST NOT include 411 the 'explicitsub' or 'nosub' option tag in the Require header field 412 of any request other than REFER. A UA MUST NOT include the 413 'explicitsub' or 'nosub' option tag in the Require header field of 414 any SIP response other than a 421 response to a REFER request. 416 The 'explicitsub' and 'nosub' option tags MAY appear in the Supported 417 header field of SIP messages, and in sip.extensions feature tag 418 defined in [RFC3840]. This signals only that the UA including the 419 value is aware of the extensions. In particular, a UA can only 420 invoke the use of one of the extensions in a request. A User-Agent 421 Server (UAS) that is processing a REFER request that lists 422 'explicitsub' or 'nosub' in its Supported header field and wishes to 423 use one of those extensions will return a 421 response indicating 424 which extension is required. 426 OPEN ISSUE: This description of the use of 421 is not yet perfectly 427 aligned with RFC3261's definition. 429 7. Updates to RFC 3515 431 The requirement in section 2.4.4 of [RFC3515] to reject out-of-dialog 432 SUBSCRIBE requests to event 'refer' is removed. An element MAY 433 accept a SUBSCRIBE request to event 'refer', following the 434 requirements and guidance in this document. REFER is no longer the 435 only mechanism that can create a subscription to event 'refer'. 437 [RFC6665] section 8.3.1 deprecates the 202 Accepted response code. 438 New implementations of REFER, whether using the 'explicitsub' 439 extension or not, will never emit a 202 response code. Where RFC 440 3515 specifies using 202, new implementations MUST use 200 instead. 442 8. Security Considerations 444 The considerations of [RFC3515] all still apply to a REFER request 445 using this extension. The considerations there for the implicit 446 subscription apply to any explicit subscription for the 'refer' 447 event. 449 This update to RFC 3515 introduces a new authorization consideration. 450 An element receiving an initial SUBSCRIBE request to the 'refer' 451 event needs to decide whether the subscriber should be allowed to see 452 the refer event state. In RFC 3515, this decision was conflated with 453 accepting the REFER request, and the only possible subscriber was the 454 element that sent the REFER. With this update, there may multiple 455 subscribers to any given refer event state. 457 This document allows an element to accept an initial SUBSCRIBE 458 request based on having a Request-URI that identifies existing refer 459 event state. (Such a URI will have previously been sent in the 460 Refer-Events-At header field in a successful REFER response). The 461 element retrieving that URI from the response, and any elements that 462 element shares the URI with are authorized to SUBSCRIBE to the event 463 state. Consequently, the URI should be constructed so that it is not 464 easy to guess, and should be protected against eavesdroppers when 465 transmitted. For instance, SIP messages containing this URI SHOULD 466 be sent using TLS or DTLS. An event server receiving a REFER request 467 over an unprotected transport can redirect the requester to use a 468 protected transport before accepting the request. A good way to 469 ensure that subscriptions use a protected transport is to only 470 construct sips: URIs. The event server can also require any of the 471 additional authorization mechanisms allowed for any SIP request. For 472 example, the event server could require a valid assertion of the 473 subscriber's identity using [RFC4474]. 475 The URI provided in a 'Refer-Events-At' header field will be used as 476 the Request-URI of SUBSCRIBE requests. A malicious agent could take 477 advantage of being able to choose this URI in ways similar to the 478 ways an agent sending a REFER request can take advantage of the 479 Refer-To URI, as described in the security considerations section of 480 RFC 3515. In particular, the malicious agent could cause a SIP 481 SUBSCRIBE to be sent as raw traffic towards a victim. If the victim 482 is not SIP aware, and the SUBSCRIBE is sent over UDP, there is (at 483 most) a factor of 11 amplification due to retransmissions of the 484 request. The potential for abuse in this situation is lower than 485 that of the Refer-To URI, since the URI can only have a sip: or sips: 486 scheme, and is only provided in a REFER response. A malicious agent 487 would have to first receive a REFER request to take advantage of 488 providing a Refer-Events-At URI. 490 9. IANA Considerations 492 9.1. Register the 'explicitsub' Option Tag 494 The option tag 'explicitsub' is registered in the 'Option Tag' 495 subregistry of the 'Session Initiation Protocol (SIP) Parameters' 496 registry by adding a row with these values: 498 Name: explicitsub 500 Description: This option tag identifies an extension to REFER to 501 suppress the implicit subscription, and provide a URI for an explicit 502 subscription. 504 Reference: (this document) 506 9.2. Register the 'nosub' Option Tag 508 The option tag 'nosub' is registered in the 'Option Tag' subregistry 509 of the 'Session Initiation Protocol (SIP) Parameters' registry by 510 adding a row with these values: 512 Name: nosub 514 Description: This option tag identifies an extension to REFER to 515 suppress the implicit subscription, and indicate that no explicit 516 subscription is forthcoming. 518 Reference: (this document) 520 9.3. Register the 'Refer-Events-At' Header Field 522 The header field described in Section 4.8 is registered in the 523 'Header Fields' subregistry of the 'Session Initiation Protocol (SIP) 524 Parameters' registry by adding a row with these values: 526 Header Name: Refer-Events-At 528 compact: (none: the entry in this column should be blank) 530 Reference: (this document) 532 10. Changelog 534 RFC Editor - please remove this section when formatting this document 535 as an RFC. 537 10.1. 01 to 02 539 1. Added the 'nosub' option tag 541 2. Added text calling out the limitations on explicitsub when the 542 REFER might be accepted in more than one place. 544 10.2. 00 to 01 546 1. Replaced strawman proposal with a formal definition of the 547 mechanism. Added an overview, and detailed security 548 considerations. 550 11. References 552 11.1. Normative References 554 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 555 Requirement Levels", BCP 14, RFC 2119, March 1997. 557 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 558 A., Peterson, J., Sparks, R., Handley, M., and E. 559 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 560 June 2002. 562 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 563 Method", RFC 3515, April 2003. 565 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 566 "Indicating User Agent Capabilities in the Session 567 Initiation Protocol (SIP)", RFC 3840, August 2004. 569 [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, 570 July 2012. 572 11.2. Informative References 574 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 575 for Event State Publication", RFC 3903, October 2004. 577 [RFC4321] Sparks, R., "Problems Identified Associated with the 578 Session Initiation Protocol's (SIP) Non-INVITE 579 Transaction", RFC 4321, January 2006. 581 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 582 Authenticated Identity Management in the Session 583 Initiation Protocol (SIP)", RFC 4474, August 2006. 585 [RFC4538] Rosenberg, J., "Request Authorization through Dialog 586 Identification in the Session Initiation Protocol (SIP)", 587 RFC 4538, June 2006. 589 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 590 Initiation Protocol", RFC 5057, November 2007. 592 [RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session 593 Initiation Protocol (SIP) Call Control - Transfer", BCP 594 149, RFC 5589, June 2009. 596 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 597 Agent URIs (GRUUs) in the Session Initiation Protocol 598 (SIP)", RFC 5627, October 2009. 600 Author's Address 602 Robert Sparks 603 Oracle 604 7460 Warren Parkway 605 Suite 300 606 Frisco, Texas 75034 607 US 609 Email: rjsparks@nostrum.com