idnits 2.17.1 draft-ietf-sipcore-refer-clarifications-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3515, but the abstract doesn't seem to directly say this. It does mention RFC3515 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3515, updated by this document, for RFC5378 checks: 2001-08-28) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 22, 2015) is 3291 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) -- Possible downref: Normative reference to a draft: ref. 'I-D.roach-sipcore-6665-clarification' == Outdated reference: A later version (-03) exists of draft-ietf-sipcore-refer-explicit-subscription-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 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 Updates: 3515 (if approved) A. Roach 5 Intended status: Standards Track Mozilla 6 Expires: October 24, 2015 April 22, 2015 8 Clarifications for the use of REFER with RFC6665 9 draft-ietf-sipcore-refer-clarifications-04 11 Abstract 13 The SIP REFER method relies on the SIP-Specific Event Notification 14 Framework. That framework was revised by RFC6665. This document 15 highlights the implications of the requirement changes in RFC6665, 16 and updates the definition of the REFER method, RFC3515, to clarify 17 and disambiguate the impact of those changes. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 24, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Use of GRUU is mandatory . . . . . . . . . . . . . . . . . . 3 56 4. Dialog reuse is prohibited . . . . . . . . . . . . . . . . . 3 57 5. The 202 response code is deprecated . . . . . . . . . . . . . 4 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 61 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 10.2. Informative References . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Conventions and Definitions 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in [RFC2119]. 73 2. Introduction 75 The SIP REFER method relies on the SIP-Specific Event Notification 76 Framework. That framework was revised by [RFC6665]. This document 77 highlights the implications of the requirement changes in RFC6665, 78 and updates [RFC3515] to clarify and disambiguate the impact of those 79 changes. 81 Accepting a REFER request (without invoking extensions) results in an 82 implicit SIP-Events subscription. If that REFER was part of an 83 existing dialog, the implicit subscription creates a new, problematic 84 dialog-usage within that dialog [RFC5057]. The "norefersub" 85 extension defined in [RFC4488] asks to suppress this implicit 86 subscription, but cannot prevent its creation. 88 There are implementations in some known specialized environments 89 (such as 3gpp) that use out-of-signalling agreements to ensure that 90 in-dialog REFER requests using the RFC4488 extension do not create a 91 new subscription inside that dialog. In the 3gpp environment, the 92 behavior is based on capabilities advertised using media feature 93 tags. That mechanism does not, however, prevent additional dialog 94 usages when interoperating with implementations that do not support 95 the mechanism. The extensions in 97 [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized 98 mechanism that allows avoiding any additional dialog usage. 100 3. Use of GRUU is mandatory 102 Section 4.5.1 of [RFC6665] makes GRUU [RFC5627] mandatory for 103 notifiers to implement and use as the local target in the 104 subscription created by the REFER request. 106 A user agent accepting a REFER that creates a subscription MUST 107 populate its Contact header field with a GRUU. 109 A UA that might possibly become a notifier (e.g. by accepting a REFER 110 request that creates a subscription) needs to include a GRUU in the 111 Contact header field of dialog-forming and target-refresh methods 112 (such as INVITE) [I-D.roach-sipcore-6665-clarification]. This 113 ensures that out-of-dialog REFER requests corresponding to any 114 resulting INVITE dialogs arrive at this UA. Future extensions (such 115 as [I-D.ietf-sipcore-refer-explicit-subscription]) might relax this 116 requirement by defining a REFER request that cannot create an 117 implicit subscription, thus not causing the accepting UA to become an 118 RFC6665 notifier in the context of this dialog. 120 4. Dialog reuse is prohibited 122 If a peer in an existing dialog has provided a GRUU as its Contact, 123 sending a REFER that might result in an additional dialog usage 124 within that dialog is prohibited. This is a direct consequence of 125 [RFC6665] requiring the use of GRUU, and the requirements in section 126 4.5.2 of that document. 128 A user agent constructing a REFER request that could result in an 129 implicit subscription in a dialog MUST build it as an out-of-dialog 130 message as defined in [RFC3261], unless the remote endpoint is an 131 older, pre-RFC6665 implementation (as determined by the absence of a 132 GRUU in the remote target). Thus, the REFER request will have no tag 133 parameter in its To: header field. 135 Using the "norefersub" option tag [RFC4488] does not change this 136 requirement, even if used in a "Require" header field. Even if the 137 recipient supports the "norefersub" mechanism, and accepts the 138 request with the option tag in the "Require" header field, it is 139 allowed to return a "Refer-Sub" header field with a value of "true" 140 in the response, and create an implicit subscription. 142 A user agent wishing to identify an existing dialog (such as for call 143 transfer as defined in [RFC5589]) MUST use the "Target-Dialog" 144 extension defined in [RFC4538] to do so, and user agents accepting 145 REFER MUST be able to process that extension in requests they 146 receive. 148 If a user agent can be certain that no implicit subscription will be 149 created as a result of sending a REFER request (such as by requiring 150 an extension that disallows any such subscription 151 [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request 152 MAY be sent within an existing dialog (whether or not the remote 153 target is a GRUU). Such a REFER will be constructed with its Contact 154 header field populated with the dialog's Local URI as specified in 155 section 12 of [RFC3261]. 157 As described in section 4.5.2 of [RFC6665], there are cases where a 158 user agent may fall back to sharing existing dialogs for backwards- 159 compatibility purposes. This applies to REFER only when the peer has 160 not provided a GRUU as its Contact in the existing dialog (i.e. when 161 the peer is a pre-RFC6665 implementation). 163 5. The 202 response code is deprecated 165 Section 8.3.1 of [RFC6665] requires that elements do not send a 202 166 response code to a subscribe request, but use the 200 response code 167 instead. Any 202 response codes received to a subscribe request are 168 treated as 200s. These changes also apply to REFER. Specifically, 169 an element accepting a REFER request MUST NOT reply with a 202 170 response code and MUST treat any 202 responses received as identical 171 to a 200 response. Wherever [RFC3515] requires sending a 202 172 response code, a 200 response code MUST be sent instead. 174 6. Security Considerations 176 This document introduces no new security considerations directly. 177 The updated considerations in [RFC6665] apply to the implicit 178 subscription created by an accepted REFER request. 180 7. IANA Considerations 182 This document has no actions for IANA. 184 8. Acknowledgements 186 Christer Holmberg provided the formulation for the final paragraph of 187 the introduction. Christer Holmberg and Ivo Sedlacek provided 188 detailed comments during working group discussion of the document. 190 9. Changelog 192 RFC Editor - please remove this section when formatting this document 193 as an RFC 195 -03 to -04 197 Added section on deprecating 202. 199 -02 to -03 201 Reinforced that the MAY send in-dialog applied no matter what 202 the remote target URI contained. 204 -01 to -02 206 Tweaked the third paragraph of section 3 per list discussion. 207 (Note the subject line of that discussion said -explicit- 208 subscription) 210 -00 to -01 212 Added the 3rd paragraph to the introduction per extensive list 213 discussion 215 draft-sparks-sipcore-refer-clarifications-05 to draft-ietf- 216 sipcore-refer-clarifications-00 218 Attempted to improve the accuracy of the Abstract and 219 Introduction without diluting the essential point of the 220 document. 222 Added an informative reference to RFC5057. 224 Adjusted text to more reflect what RFC6665 (as clarified by 225 draft-roach-sipcore-6665-clarification) actually requires, and 226 added a normative reference to that clarification draft. 228 Specifically, the requirement for the _sender_ of a REFER to 229 use a GRUU as its local target was removed. 231 Clarified why the explicit-subscription extensions relieve an 232 in-dialog REFERer from the 6665 requirements for using GRUU as 233 its contact in the INVITE dialog. 235 10. References 237 10.1. Normative References 239 [I-D.roach-sipcore-6665-clarification] 240 Roach, A., "A clarification on the use of Globally 241 Routable User Agent URIs (GRUUs) in the Session Initiation 242 Protocol (SIP) Event Notification Framework", draft-roach- 243 sipcore-6665-clarification-00 (work in progress), October 244 2014. 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, March 1997. 249 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 250 A., Peterson, J., Sparks, R., Handley, M., and E. 251 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 252 June 2002. 254 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 255 Method", RFC 3515, April 2003. 257 [RFC4538] Rosenberg, J., "Request Authorization through Dialog 258 Identification in the Session Initiation Protocol (SIP)", 259 RFC 4538, June 2006. 261 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 262 Agent URIs (GRUUs) in the Session Initiation Protocol 263 (SIP)", RFC 5627, October 2009. 265 [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, 266 July 2012. 268 10.2. Informative References 270 [I-D.ietf-sipcore-refer-explicit-subscription] 271 Sparks, R., "Explicit Subscriptions for the REFER Method", 272 draft-ietf-sipcore-refer-explicit-subscription-00 (work in 273 progress), November 2014. 275 [RFC4488] Levin, O., "Suppression of Session Initiation Protocol 276 (SIP) REFER Method Implicit Subscription", RFC 4488, May 277 2006. 279 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 280 Initiation Protocol", RFC 5057, November 2007. 282 [RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session 283 Initiation Protocol (SIP) Call Control - Transfer", BCP 284 149, RFC 5589, June 2009. 286 Authors' Addresses 288 Robert Sparks 289 Oracle 290 7460 Warren Parkway 291 Suite 300 292 Frisco, Texas 75034 293 US 295 Email: rjsparks@nostrum.com 297 Adam Roach 298 Mozilla 299 Dallas, TX 300 US 302 Phone: +1 650 903 0800 x863 303 Email: adam@nostrum.com