idnits 2.17.1 draft-ietf-sipcore-refer-explicit-subscription-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 : ---------------------------------------------------------------------------- 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 (June 25, 2015) is 3199 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 June 25, 2015 5 Expires: December 27, 2015 7 Explicit Subscriptions for the REFER Method 8 draft-ietf-sipcore-refer-explicit-subscription-03 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 December 27, 2015. 37 Copyright Notice 39 Copyright (c) 2015 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 . . . . . . . . . . . . . . . 9 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 . . . . . . . 12 79 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 10.1. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 12 81 10.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . 12 82 10.3. -sparks- 02 to -ietf- 00 . . . . . . . . . . . . . . . . 12 83 10.4. -sparks- 01 to 02 . . . . . . . . . . . . . . . . . . . 13 84 10.5. -sparks- 00 to 01 . . . . . . . . . . . . . . . . . . . 13 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 87 11.2. Informative References . . . . . . . . . . . . . . . . . 13 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 90 1. Conventions and Definitions 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. Introduction 98 REFER as defined by [RFC3515] triggers an implicit SIP-Specific Event 99 Framework subscription. Sending a REFER within a dialog established 100 by an INVITE results in dialog reuse and the associated problems 101 described in [RFC5057]. The SIP-Specific Event Notification 102 framework definition [RFC6665] disallows such dialog reuse. Call 103 transfer, as defined in [RFC5589], thus requires sending a REFER 104 request on a new dialog, associating it with an existing dialog using 105 the 'Target-Dialog' mechanism defined in [RFC4538]. 107 Because there is no explicit SUBSCRIBE request, the tools for 108 negotiating subscription details are unavailable for REFER 109 subscriptions. This includes negotiating subscription duration and 110 providing information through Event header field parameters. The use 111 of the SIP 'Supported' and 'Require' extension mechanisms [RFC3261] 112 is complicated by the implicit subscription. It is unclear whether 113 the extension applies to handling the REFER request itself, or to the 114 messages in the subscription created by the REFER, or both. Avoiding 115 this confusion requires careful specification in each extension. 116 Existing extensions do not provide this clarity. 118 This document defines two mechanisms that remove the implicit 119 subscription, one of which replaces it with an explicit one. The 120 benefits of doing so include: 122 o Allowing REFER to be used within INVITE-created dialogs without 123 creating dialog reuse. 125 o Allowing standard subscription parameter negotiation. 127 o Allowing standard negotiation of SIP extensions. 129 There are limitations on when it is appropriate to use the extension 130 that allows an explicit subscription, related directly to definition 131 of non-INVITE transaction handling SIP. These limitations are 132 discussed in Section 4.1. 134 3. Overview 136 This section provides a non-normative overview of the behaviors 137 defined in subsequent sections. 139 3.1. Explicit Subscriptions 141 A SIP User-Agent (UA) that wishes to issue a REFER request that will 142 not create an implicit subscription, but will allow an explicit one, 143 will include a new option tag, 'explicitsub', in the Require header 144 field of the REFER request. This REFER could be sent either within 145 an existing dialog, or as an out-of-dialog request. 147 If the recipient of the REFER accepts the request, it will begin 148 managing the 'refer' event state described in RFC 3515, and will 149 provide a URI that will reach an event server that will service 150 subscriptions to that state. (In many cases, the recipient of the 151 REFER will perform the role of event server itself.) That URI is 152 returned in a new header field in the REFER response named 'Refer- 153 Events-At'. 155 The UA that issued the REFER can now subscribe to the 'refer' event 156 at the provided URI, using a SUBSCRIBE request with a new dialog 157 identifier. The full range of negotiation mechanisms is available 158 for its use in that request. As detailed in RFC 6665 and RFC 3515, 159 the event server accepting the subscription will send an immediate 160 NOTIFY with the current refer event state, additional NOTIFY messages 161 as the refer state changes, and a terminal NOTIFY message when the 162 referred action is complete. It is, of course, possible that the 163 initial NOTIFY is also the terminal NOTIFY. 165 It is possible that the referred action is completed before the 166 SUBSCRIBE arrives at the event server. The server needs to retain 167 the final refer event state for some period of time to include in the 168 terminal NOTIFY that will be sent for such subscriptions. It is also 169 possible that a SUBSCRIBE will never arrive. 171 This extension makes it possible to separate the event server that 172 will handle subscriptions from the UA that accepted the REFER. Such 173 a UA could use mechanisms such as PUBLISH [RFC3903] to convey the 174 refer event state to the event server. This extension also makes it 175 possible to allow more than one subscription to the refer event 176 state. 178 3.2. No Subscriptions 180 A UA that wishes to issue a REFER request that will not create an 181 implicit subscription, and tell the recipient that it is not 182 interested in creating an explicit subscription, will include a new 183 option tag, 'nosub', in the Require header field of the REFER 184 request. This REFER could be sent either within an existing dialog 185 or as an out-of-dialog request. 187 If the recipient of the REFER accepts the request, it knows not to 188 create an implicit subscription, and that no explicit subscription 189 will be forthcoming. The recipient will continue to process the 190 request indicated in the Refer-To header field as specified in RFC 191 3515, but it can avoid the cost of preparing to handle any 192 subscriptions to the state of handling that request. 194 4. The Explicit Subscription Extension 196 4.1. Sending a REFER 198 To suppress the creation of any implicit subscription, and allow for 199 an explicit one, a UA forming a REFER request will include the option 200 tag 'explicitsub' in the "Require" header field of the request. The 201 REFER request is otherwise formed following the requirements of 202 [RFC3515]. Since this REFER has no chance of creating an implicit 203 subscription, the UA MAY send the REFER request within an existing 204 dialog or out-of-dialog. 206 Note that if the REFER forks (see [RFC3261]), only one final response 207 will be returned to the issuing UA. If it is important that the UA 208 be able to subscribe to any refer state generated by accepting this 209 request, the UA needs to form the request so that it will only be 210 acepted in one place. This can be achieved by sending the REFER 211 request within an existing dialog, or by using the Target-Dialog 212 mechanism defined in [RFC4538]. If it is possible for the request to 213 be accepted in more than one location, and things would go wrong if 214 the UA did not learn about each location that the request was 215 accepted, using this extension is not appropriate. 217 4.2. Processing a REFER Response 219 The UA will process responses to the REFER request as specified in 220 [RFC3515] (and, consequently, [RFC3261]). In particular, if the 221 REFER was sent to an element that does not support or is unwilling to 222 use this extension, the response will contain a 420 Bad Extension 223 response code (see section 8.1.3.5 of [RFC3261]). As that document 224 states, the UA can retry the request without using this extension. 226 If the UA receives a 2xx-class response, it will contain a Refer- 227 Events-At header field (Section 4.8) with a single URI as its value. 228 If the UA is interested in the state of the referenced action, it 229 will subscribe to the 'refer' event at that URI. 231 4.3. Processing a Received REFER 233 An element receiving a REFER request requiring the 'explicitsub' 234 extension will use the same admissions policies that would be used 235 without the extension, with the addition that it is acceptable to 236 admit an in-dialog REFER request requiring this extension since it 237 can not create another usage inside that dialog. In particular, see 238 section 5.2 of [RFC3515]. 240 Accepting a REFER request that requires 'explicitsub' does not create 241 a dialog, or a new usage within an existing dialog. The element MUST 242 NOT create an implicit subscription when accepting the REFER request. 244 If the REFER request was received within an existing dialog, the 245 accepting element will not be acting as a SIP-Events notifier in the 246 context of that dialog. If it is not otherwise subject to becoming a 247 notifier in the context of the dialog, none of the requirements in 248 RFC6665, particularly the requirement to provide a GRUU as the local 249 contact, apply to the message accepting the REFER request. 251 An element that accepts a REFER request with 'explicitsub' in its 252 Require header field MUST return a 200 response containing a sip: or 253 sips: URI in the Refer-Events-At header field that can be used to 254 subscribe to the refer event state associated with this REFER 255 request. This URI MUST uniquely identify this refer event state. 256 The URI needs to reach the event server when used in a SUBSCRIBE 257 request from the element that sent the REFER. One good way to ensure 258 the URI provided has that property is to use a GRUU [RFC5627] for the 259 event server. As discussed in Section 8, possession of this URI is 260 often the only requirement for authorizing a subscription to it. 261 Implementations SHOULD provide a URI constructed in a way that is 262 hard to guess. Again, using a GRUU (specifically, a temporary GRUU) 263 is one good way to achieve this property. 265 The accepting element will otherwise proceed with the processing 266 defined in [RFC3515]. 268 The event server identified by the Refer-Events-At URI could receive 269 SUBSCRIBE requests at any point after the response containing the 270 Refer-Events-At header is sent. Implementations should take care to 271 ensure the event server is ready to receive those SUBSCRIBE requests 272 before sending the REFER response, but as with all non-INVITE 273 responses, the response should be sent as soon as possible (see 274 [RFC4321]). It is also possible that the referred action may 275 complete before any SUBSCRIBE request arrives. The event server will 276 need to maintain the final refer event state for a period of time 277 after the action completes in order to serve such subscriptions (see 278 Section 4.6). 280 4.4. Subscribing to the 'refer' Event 282 A UA that possesses a URI obtained from a Refer-Events-At header 283 field, MAY subscribe to the refer event state at that URI. It does 284 so following the requirements of [RFC6665], placing the token 'refer' 285 in the Event: header field and the URI in the Request-URI of the 286 SUBSCRIBE request. The SUBSCRIBE request MUST NOT reuse any existing 287 dialog identifiers. 289 Subsequent handling of the subscription MUST follow the requirements 290 of [RFC6665] and [RFC3515]. In particular, as discussed in section 291 2.4.6, the NOTIFY messages in the subscription might include an id 292 parameter in their Event header fields. Subsequent SUBSCRIBE 293 requests used to refresh or terminate this subscription MUST contain 294 this id parameter. Note that the rationale for the id parameter 295 provided in that section is not relevant when this extension is used. 296 The URI returned in the Refer-Events-At header field uniquely 297 identifies appropriate state, making the id parameter redundant. 298 However, this behavioral requirement is preserved to reduce the 299 number of changes to existing implementations in order to support 300 this extension, and to make it more likely that existing diagnostic 301 tools will work with little or no modification. 303 4.5. Processing a Received SUBSCRIBE 305 An event server receiving a SUBSCRIBE request will process it 306 according to the requirements of [RFC6665]. The event server MAY 307 choose to authorize the SUBSCRIBE request based on the Request-URI 308 corresponding to existing refer event state. It MAY also require 309 further authorization as discussed in Section 8. 311 When accepting a subscription, the event server will establish the 312 initial subscription duration using the guidance in section 3.4 of 313 [RFC3515]. 315 4.6. Sending a NOTIFY 317 NOTIFY messages within a subscription are formed and sent following 318 the requirements in [RFC3515]. See, in particular, section 2.4.5 of 319 that document. 321 4.7. Managing 'refer' Event State 323 As described in [RFC3515], an element creates the state for event 324 'refer' when it accepts a REFER request. It updates that state as 325 the referred request proceeds, ultimately reaching a state where the 326 request has completed, and the final state is known. 328 In RFC 3515 implementations, it was a reasonable design choice to 329 destroy the refer event state immediately after sending the NOTIFY 330 that terminated the implicit subscription. This is not the case when 331 using this extension. It is possible for the referenced request to 332 complete very quickly, perhaps sooner than the time it takes the 333 response to the REFER to traverse the network to the UA that sent the 334 request, and the time it takes that agent to send the SUBSCRIBE 335 request for the event state to the URI the response provides. Thus 336 the event server MUST retain the final refer event state for a 337 reasonable period of time, which SHOULD be at least 2*64*T1 (that is, 338 64 seconds), representing an upper-bound estimate of the time it 339 would take to complete two non-INVITE transactions: the REFER, and an 340 immediate SUBSCRIBE. 342 If an otherwise acceptable SUBSCRIBE arrives during this retention 343 period, the subscription would be accepted, and immediately 344 terminated with a NOTIFY containing the final event state with a 345 Subscription-State of terminated with a reason value of "noresource". 347 4.8. The Refer-Events-At Header Field 349 The 'Refer-Events-At' header field is an extension-header as defined 350 by [RFC3261]. Its ABNF is as follows: 352 Refer-Events-At = "Refer-Events-At" HCOLON 353 LAQUOT ( SIP-URI / SIPS-URI ) RAQUOT 354 *( SEMI generic-param ) 356 See [RFC3261] for the definition of the elements used in that 357 production. 359 Note that this rule does not allow a full addr-spec as defined in RFC 360 3261, and it mandates the use of the angle brackets. That is: 362 Refer-Events-At: 364 is well formed, but 366 Refer-Events-At: sip:wsXa9mkHtPcGu8@example.com 368 is invalid. 370 The 'Refer-Events-At' header field is only meaningful in a 2xx-class 371 response to a REFER request. If it appears in the header of any 372 other SIP message, its meaning is undefined and it MUST be ignored. 374 5. The No Subscription Extension 376 5.1. Sending a REFER 378 To suppress the creation of any implicit subscription, and signal 379 that no explicit subscription will be forthcoming, a UA forming a 380 REFER request will include the option tag 'nosub' in the "Require" 381 header field of the request. The REFER request is otherwise formed 382 following the requirements of [RFC3515]. Since this REFER has no 383 chance of creating an implicit subscription, the UA MAY send the 384 REFER request within an existing dialog or out-of-dialog. 386 5.2. Processing a REFER Response 388 The UA will process responses to the REFER request as specified in 389 [RFC3515] (and, consequently, [RFC3261]). In particular, if the 390 REFER was sent to an element that does not support or is unwilling to 391 use this extension, the response will contain a 420 Bad Extension 392 response code (see section 8.1.3.5 of [RFC3261]). As that document 393 states, the UA can retry the request without using this extension. 395 5.3. Processing a Received REFER 397 An element receiving a REFER request requiring the 'nosub' extension 398 will use the same admissions policies that would be used without the 399 extension, with the addition that it is acceptable to admit an in- 400 dialog REFER request requiring this extension since it can not create 401 another usage inside that dialog. In particular, see section 5.2 of 402 [RFC3515]. 404 Accepting a REFER request that requires 'nosub' does not create a 405 dialog, or a new usage within an existing dialog. The element MUST 406 NOT create an implicit subscription when accepting the REFER request. 407 Futhermore, the element accepting the REFER request is not required 408 to maintain any state for serving refer event subscriptions. 410 If the REFER is received within an existing dialog, the accepting 411 element will not be acting as a SIP-Events notifier in the context of 412 that dialog. If it is not otherwise subject to becoming a notifier 413 in the context of the dialog, none of the requirements in RFC6665, 414 particularly the requirement to provide a GRUU as the local contact, 415 apply to the message accepting the REFER request. 417 The accepting element will otherwise proceed with the processing 418 defined in [RFC3515]. 420 6. The 'explicitsub' and 'nosub' Option Tags 422 This document defines the 'explicitsub' option tag, used to signal 423 the use of the extension defined in Section 4, and the 'nosub' option 424 tag, used to signal the use of the extension defined in Section 5. 426 The use of either option tag in a Require header field is only 427 defined when it appears in a REFER request or a response to a REFER 428 request. A UA MUST NOT include the 'explicitsub' or 'nosub' option 429 tag in the Require header field of any request other than REFER. A 430 UA MUST NOT include the 'explicitsub' or 'nosub' option tag in the 431 Require header field of any SIP response other than a 200 or 421 432 response to a REFER request. 434 The 'explicitsub' and 'nosub' option tags MAY appear in the Supported 435 header field of SIP messages, and in sip.extensions feature tag 436 defined in [RFC3840]. This signals only that the UA including the 437 value is aware of the extensions. In particular, a UA can only 438 invoke the use of one of the extensions in a request. A UA MUST NOT 439 include either option tag in the Require header field of a 200 440 response to a REFER request if that tag was not present in the 441 Require header field of the request. A User-Agent Server (UAS) that 442 is processing a REFER request that lists 'explicitsub' or 'nosub' in 443 its Supported header field and wishes to use one of those extensions 444 will return a 421 response indicating which extension is required. 446 7. Updates to RFC 3515 448 The requirement in section 2.4.4 of [RFC3515] to reject out-of-dialog 449 SUBSCRIBE requests to event 'refer' is removed. An element MAY 450 accept a SUBSCRIBE request to event 'refer', following the 451 requirements and guidance in this document. REFER is no longer the 452 only mechanism that can create a subscription to event 'refer'. 454 8. Security Considerations 456 The considerations of [RFC3515] all still apply to a REFER request 457 using this extension. The considerations there for the implicit 458 subscription apply to any explicit subscription for the 'refer' 459 event. 461 This update to RFC 3515 introduces a new authorization consideration. 462 An element receiving an initial SUBSCRIBE request to the 'refer' 463 event needs to decide whether the subscriber should be allowed to see 464 the refer event state. In RFC 3515, this decision was conflated with 465 accepting the REFER request, and the only possible subscriber was the 466 element that sent the REFER. With this update, there may be multiple 467 subscribers to any given refer event state. 469 This document allows an element to accept an initial SUBSCRIBE 470 request based on having a Request-URI that identifies existing refer 471 event state. (Such a URI will have previously been sent in the 472 Refer-Events-At header field in a successful REFER response). The 473 element retrieving that URI from the response, and any elements that 474 element shares the URI with are authorized to SUBSCRIBE to the event 475 state. Consequently, the URI should be constructed so that it is not 476 easy to guess, and should be protected against eavesdroppers when 477 transmitted. [RFC3261] details mechanisms for providing such 478 protection, such as sending SIP messages over TLS or DTLS. See the 479 security considerations section of [RFC3261] for considerations when 480 using other security mechanisms. An event server receiving a REFER 481 request over an unprotected transport can redirect the requester to 482 use a protected transport before accepting the request. A good way 483 to ensure that subscriptions use a protected transport is to only 484 construct sips: URIs. The event server can also require any of the 485 additional authorization mechanisms allowed for any SIP request. For 486 example, the event server could require a valid assertion of the 487 subscriber's identity using [RFC4474]. 489 The URI provided in a 'Refer-Events-At' header field will be used as 490 the Request-URI of SUBSCRIBE requests. A malicious agent could take 491 advantage of being able to choose this URI in ways similar to the 492 ways an agent sending a REFER request can take advantage of the 493 Refer-To URI, as described in the security considerations section of 494 RFC 3515. In particular, the malicious agent could cause a SIP 495 SUBSCRIBE to be sent as raw traffic towards a victim. If the victim 496 is not SIP aware, and the SUBSCRIBE is sent over UDP, there is (at 497 most) a factor of 11 amplification due to retransmissions of the 498 request. The potential for abuse in this situation is lower than 499 that of the Refer-To URI, since the URI can only have a sip: or sips: 500 scheme, and is only provided in a REFER response. A malicious agent 501 would have to first receive a REFER request to take advantage of 502 providing a Refer-Events-At URI. 504 9. IANA Considerations 506 9.1. Register the 'explicitsub' Option Tag 508 The option tag 'explicitsub' is registered in the 'Option Tag' 509 subregistry of the 'Session Initiation Protocol (SIP) Parameters' 510 registry by adding a row with these values: 512 Name: explicitsub 514 Description: This option tag identifies an extension to REFER to 515 suppress the implicit subscription, and provide a URI for an explicit 516 subscription. 518 Reference: (this document) 520 9.2. Register the 'nosub' Option Tag 522 The option tag 'nosub' is registered in the 'Option Tag' subregistry 523 of the 'Session Initiation Protocol (SIP) Parameters' registry by 524 adding a row with these values: 526 Name: nosub 527 Description: This option tag identifies an extension to REFER to 528 suppress the implicit subscription, and indicate that no explicit 529 subscription is forthcoming. 531 Reference: (this document) 533 9.3. Register the 'Refer-Events-At' Header Field 535 The header field described in Section 4.8 is registered in the 536 'Header Fields' subregistry of the 'Session Initiation Protocol (SIP) 537 Parameters' registry by adding a row with these values: 539 Header Name: Refer-Events-At 541 compact: (none: the entry in this column should be blank) 543 Reference: (this document) 545 10. Changelog 547 RFC Editor - please remove this section when formatting this document 548 as an RFC. 550 10.1. -01 to -02 552 1. Corrected ABNF per Paul Kyzivat's review. 554 10.2. -00 to -01 556 1. Added pointer to rfc3261 for considerations when using security 557 mechanisms other than TLS or DTLS. 559 10.3. -sparks- 02 to -ietf- 00 561 1. Incorporated the change to section 6 discussed on list 563 2. Changed "only meaningful in 200" to "only meaningful in 2xx- 564 class" 566 3. Explicitly stated that the RFC6665 rules on populating Contact 567 when becoming a notifier do not apply to the message accepting a 568 REFER request requiring either of these extensions 570 4. Pointed out that _temporary_ GRUUs are what have the good 571 security property discussed in the security considerations 572 section 574 10.4. -sparks- 01 to 02 576 1. Added the 'nosub' option tag 578 2. Added text calling out the limitations on explicitsub when the 579 REFER might be accepted in more than one place. 581 10.5. -sparks- 00 to 01 583 1. Replaced strawman proposal with a formal definition of the 584 mechanism. Added an overview, and detailed security 585 considerations. 587 11. References 589 11.1. Normative References 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, March 1997. 594 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 595 A., Peterson, J., Sparks, R., Handley, M., and E. 596 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 597 June 2002. 599 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 600 Method", RFC 3515, April 2003. 602 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 603 "Indicating User Agent Capabilities in the Session 604 Initiation Protocol (SIP)", RFC 3840, August 2004. 606 [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, 607 July 2012. 609 11.2. Informative References 611 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 612 for Event State Publication", RFC 3903, October 2004. 614 [RFC4321] Sparks, R., "Problems Identified Associated with the 615 Session Initiation Protocol's (SIP) Non-INVITE 616 Transaction", RFC 4321, January 2006. 618 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 619 Authenticated Identity Management in the Session 620 Initiation Protocol (SIP)", RFC 4474, August 2006. 622 [RFC4538] Rosenberg, J., "Request Authorization through Dialog 623 Identification in the Session Initiation Protocol (SIP)", 624 RFC 4538, June 2006. 626 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 627 Initiation Protocol", RFC 5057, November 2007. 629 [RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session 630 Initiation Protocol (SIP) Call Control - Transfer", BCP 631 149, RFC 5589, June 2009. 633 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 634 Agent URIs (GRUUs) in the Session Initiation Protocol 635 (SIP)", RFC 5627, October 2009. 637 Author's Address 639 Robert Sparks 640 Oracle 641 7460 Warren Parkway 642 Suite 300 643 Frisco, Texas 75034 644 US 646 Email: rjsparks@nostrum.com