idnits 2.17.1 draft-parameswar-sipping-norefersub-00.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 2 instances of too long lines in the document, the longest one being 49 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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: 2. Session-integrity-req: In the case where the referee (party receiving the REFER method) chooses to, or does not support the suppression of implicit subscription, the session MUST not be affected. This allows the referor to retry the REFER based on the ability or choice of the referee. == 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: If the UAC wishes to leave the decision to create or suppress implicit subscription to event 'refer' in the hands of the UAS (referee) - it SHOULD include the Supported header with the option tag 'norefersub' in the REFER method. The presence of the option tag in the Require header of the 2xx response, indicates whether the UAS has decided to create or suppress the implicit subscription. If the option tag is present in the Require header then the UAC MUST not wait for the NOTIFY, and in the absence of this option-tag it MUST be prepared to receive the NOTIFY message for event 'refer'. -- 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 (October 2002) is 7865 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 74 looks like a reference -- Missing reference section? '2' on line 195 looks like a reference -- Missing reference section? '4' on line 141 looks like a reference -- Missing reference section? '3' on line 238 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING 3 Internet Draft S. Parameswar 4 Document: draft-parameswar-sipping-norefersub-00.txt 5 Expires: April 2003 October 2002 7 Suppressing Refer Implicit Subscription 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [1]. 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 Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 The recipient of the REFER method [1] creates an implicit 32 subscription to the 'refer' event. This subscription causes the REFER 33 recipient to send NOTIFY messages to the sender informing him of the 34 progress of the REFER. This memo provides for the requirements and 35 one potential mechanism to suppress the creation of this implicit 36 subscription, via an option tag - 'norefersub'. This gives the agent 37 sending the REFER control over the creation of the subscription, 38 while being backwards compatible with [1]. 40 Conventions used in this document 42 In examples, "C:" and "S:" indicate lines sent by the client and 43 server respectively. 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC-2119 [2]. 49 This document uses the terms "referor" for the UA that sends the 50 REFER method, and "referee" for the receiving agent. 52 Table of Contents 54 1. Introduction...................................................2 55 1.1 Implicit subscription in REFER.............................2 56 2. Suppressing Implicit subscriptions.............................3 57 2.1 Requirements for suppression of Implicit subscriptions.....4 58 3. Potential mechanisms...........................................4 59 3.1 Immediate Un-subscription..................................4 60 3.2 New Option Tag.............................................5 61 4. Usage of the 'norefersub' tag..................................6 62 4.1 UAS (referee) behavior.....................................6 63 4.2 UAC (referor) behavior.....................................7 64 5. IANA Registration of the 'norefersub' Option Tag...............7 65 Security Considerations...........................................8 66 References........................................................8 67 Acknowledgments...................................................8 68 Author's Addresses................................................8 70 1. Introduction 72 RFC 3265 [2] allows for non-SUBSCRIBE mechanisms to create 73 subscriptions, these are popularly called Implicit subscriptions. 74 This mechanism is used in [1] to create an implicit subscription when 75 a REFER method is received by a UA. The UA responds with an immediate 76 NOTIFY, and may send further NOTIFYs describing the progress till the 77 subscription expires. 79 The referor has no control over the creation of the subscription. 80 There has also been some acknowledgement that the implicit 81 subscription mechanism is not desirable. This memo defines a 82 mechanism to allow the referor control over the creation of the 83 implicit subscription caused by sending the REFER to the referee. 85 1.1 Implicit subscription in REFER 87 Figure 1 below, shows a typical scenario. The REFER (F1) from the 88 referor causes an implicit subscription to be created at the referee. 89 The immediate NOTIFY (F3) is required as stated in RFC 3265[2] and 90 provides the state of the subscription and the status associated with 91 the event. This is followed by one or more NOTIFY messages describing 92 the progresss, till the expiry of the subscription - as indicated by 93 the Subscription-State header in the final NOTIFY. 95 | F1 REFER | 96 |---------------------->| Implicit Subscription 97 | | 98 | F2 202 Accepted | 99 |<----------------------| 100 | | 101 | F3 NOTIFY | 102 |<----------------------| Immediate NOTIFY 103 | | 104 | F4 200 OK | 105 |---------------------->| 106 | |---------> 107 | |(whatever) 108 | |<-------- 109 | F5 NOTIFY | 110 |<----------------------| One or more NOTIFYs 111 | | 112 | F6 200 OK | | 113 |<----------------------| 115 Figure 1. Implicit subscription caused by REFER 117 2. Suppressing Implicit subscriptions 119 As can be seen from Figure 1, the referor is neither in control of 120 the creation of the implicit subscripton on its behalf, nor of the 121 number and rate of NOTIFYs. The matter of rate and number of NOTIFYs 122 may be handled by subscription filters carried in the payload of the 123 REFER method. It must be noted that this topic of subscription 124 filters is a subject of ongoing work. In the case of implicit 125 subscription as it stands today, the referee is in complete control. 127 In addition to the referor control of subscription, there are also 128 some applications that may not need an implicit subscription to be 129 created, either because the referor does not care or the Refer-To 130 resource does not lend itself to providing a notion of success or 131 failure. An example is discussed below to provide a use case: 133 Web-push: The REFER method may be used to push web pages for example 134 the Refer-To header may carry the address http://www.example.com. In 135 this case the referee may not wish to browse the pushed page 136 immediately and a NOTIFY may be delayed or not forthcoming. 138 Attended Transfers: This is a weaker example - - but when applied to an 139 enterprise setting where all parties are served off the same 140 proxy/registrar, the need to suppress implicit subscription exists. 141 In an attended transfer scenario the transferor [4] first informs the 142 transfer target of the impending transfer prior to completing the 143 action. In such cases the transferor is reasonably sure that the 144 REFER will succeed (transfer target contacted and ready, etc.) and 145 the notification may not be required. 147 It must also be noted that control of implicit subscriptions provides 148 the opportunity to provide differentiated services. For example, a 149 service provider may offer Basic Transfer and Enhanced Transfer with 150 Status Notification. 152 2.1 Requirements for suppression of Implicit subscriptions 154 This section looks at the requirements for the suppression of 155 implicit subscriptions caused by REFER. These formally address the 156 requirements that were laid out in Section 2 in an anecdotal fashion. 158 1. Referor-control-req: The referor (party initiating the REFER 159 method) MUST be able to control creation of the implicit 160 subscription. This provides the referor the ability to create or 161 suppress the implicit subscription. 163 2. Session-integrity-req: In the case where the referee (party 164 receiving the REFER method) chooses to, or does not support the 165 suppression of implicit subscription, the session MUST not be 166 affected. This allows the referor to retry the REFER based on the 167 ability or choice of the referee. 169 3. Backwards-compatability-req: Any mechanism that provides for 170 suppression of implicit subscriptions MUST be backwardly compatible. 172 4. Simplicity-req: The mechanism MUST be easy to implement. As such 173 mechanisms that use existing SIP functionality are preferred. 175 5. Congestion-limitation-req: Any mechanism that provides for 176 suppression of implicit subscriptions SHOULD NOT create additional 177 signaling burden on the network. 179 3. Potential mechanisms 181 This section details a couple of potential mechanisms to suppress 182 implicit subscriptions. Each of these mechanisms are discussed in 183 light of the requirements in Section 2.1. 185 3.1 Immediate Un-subscription 186 This section takes a look at immediately un-subscribing, following 187 the first NOTIFY as an alternate to suppressing the implicit 188 subscription mechanism. 190 This is depicted in Figure 2. The REFER (F1) from the referor creates 191 an implicit subscription. This causes the referee to generate an 192 immediate NOTIFY (F3) after sending an acknowledgement to the REFER 193 (F2). The referor not wanting further notification simply sends a 481 194 "Subscription terminated" (F4) as per Section 3.2.2. 'Notifier NOTIFY 195 Behavior' of RFC 3265[2]. The 481 terminates the subscription and the 196 referee will send no further NOTIFYs. 198 However this does not create full control over the implicit 199 subscription and is a waste of bandwidth - which is important in 200 bandwidth-constrained environments such as wireless, low-speed dialup 201 etc. 203 | F1 REFER | 204 |---------------------->| Implicit Subscription 205 | | 206 | F2 202 Accepted | 207 |<----------------------| 208 | | 209 | F3 NOTIFY | 210 |<----------------------| Immediate NOTIFY 211 | | 212 | F4 481 Sub Terminated| 213 |---------------------->| 214 | |---------> 215 | |(whatever) 216 | |<-------- 218 Figure 2. Un-subscribing after immediate NOTIFY 220 This option does not meet all the requirements laid out in Section 221 2.1. The fact that the referor receives a NOTIFY and has to send a 222 481 violates the Referor-control-req and Congestion-limitation-req. 224 3.2 New Option Tag 226 Given the discussion above - the author feels that there is definite 227 value to being able to suppress implicit subscription in the case of 228 the REFER message. This takes the form of a new option-tag 229 "norefersub". In the simplest case the option-tag is sent in a 230 Require header from the referor to the referee in a REFER message. 232 Example usage: 234 Required: norefersub 235 Supported: norefersub 236 Unsupported: norefersub 238 This option-tag may be applied as described in [3]. This memo 239 discusses its use in the REFER method and 2xx messages that 240 acknowledge the REFER method. 242 This mechanism meets all the requirements laid out in Section 2.1. 243 The use of this mechanism is backwards compatible; in the absence of 244 this option-tag the original REFER behavior will result i.e. the 245 implicit subscription is created. This mechanism does not result in 246 additional signaling burden on the network. 248 4. Usage of the 'norefersub' tag 250 A simple example of the use of the 'norefersub' tag is shown in 251 Figure 3. The REFER (F1) carries this tag in the Require header, this 252 causes the suppression of the implicit subscription. 254 | F1 REFER | Require: norefersub 255 |---------------------->| 256 | | 257 | F2 202 Accepted | 258 |<----------------------| Implicit subscription is suppressed. 259 | | 260 | |---------> 261 | |(whatever) 262 | |<-------- 264 Figure 3. Using the option-tag 'norefersub' 266 Message One (F1) 267 REFER sip:b@agentland SIP/2.0 268 Via: SIP/2.0/UDP agenta.agentland;branch=z9hG4bK2293940223 269 To: 270 From: ;tag=193402342 271 Call-ID: 898234234@agenta.agentland 272 CSeq: 93809823 REFER 273 Max-Forwards: 70 274 Refer-To: (whatever URI) 275 Require: norefersub 276 Contact: sip:a@agentland 277 Content-Length: 0 279 4.1 UAS (referee) behavior 281 The UAS MUST suppress implicit subscriptions if the REFER request 282 contained a Require header field with the option tag 'norefersub'. 284 If the UAS is unwilling to do so, it MUST reject the REFER request 285 with a 420 (Bad Extension) and include an Unsupported header field 286 containing the option tag 'norefersub'. 288 If the REFER contained a Supported header with the option tag 289 'norefersub', the UAS (referee) MAY decide to suppress the implicit 290 subscription. In this case the UAS will send the option tag 291 'norefersub' in a Require header of the 2xx response to the REFER. 292 This indicates to the referor that no NOTIFYs are to be expected for 293 this REFER. However in this case if the 2xx does not contain the 294 Require header with the 'norefersub' option-tag, the referor MUST be 295 prepared to receive the NOTIFY messages from the UAS. 297 4.2 UAC (referor) behavior 299 When the UAC (referor) creates a new REFER request, it can insist on 300 suppressing implicit subscription for that request. To do that, it 301 inserts a Require header field with the option tag 'norefersub' into 302 the REFER request. 304 If the UAC wishes to leave the decision to create or suppress 305 implicit subscription to event 'refer' in the hands of the UAS 306 (referee) - it SHOULD include the Supported header with the option 307 tag 'norefersub' in the REFER method. The presence of the option tag 308 in the Require header of the 2xx response, indicates whether the UAS 309 has decided to create or suppress the implicit subscription. If the 310 option tag is present in the Require header then the UAC MUST not 311 wait for the NOTIFY, and in the absence of this option-tag it MUST be 312 prepared to receive the NOTIFY message for event 'refer'. 314 5. IANA Registration of the 'norefersub' Option Tag 316 This memo registers a single option tag, 'norefersub'. The 317 required information for this registration, as specified in RFC 3261, 318 is: 320 Name: norefersub 322 Description: This option tag is for suppression of implicit 323 subscriptions to event 'refer', caused by the reception of a 324 REFER method. When present in a Supported header, it 325 indicates that the UA can support/handle such suppression. 326 When present in a Require header in a REFER request, it 327 indicates that the UAS MUST suppress the implicit 328 subscription. 329 When present in a Require header in a 2xx 330 Response to the REFER, it indicates that the implicit 331 subscription has been suppressed. 333 Security Considerations 335 One of the advantages to implicit subscription is the case of forked 336 REFERs - - of course, a REFER sent within the scope of an existing 337 dialog will not fork. A REFER sent outside the context of a dialog 338 MAY fork and the receipt of multiple NOTIFYs alerts the referor to 339 this fact. 341 The use of implicit subscription suppression is advocated in those 342 cases where the referor does not care about forked REFERs or the 343 service being invoked via the REFER does not lend itself to sending 344 back NOTIFYs. 346 References 348 1 Sparks, R., " The SIP Refer Method", Work In Progress, June 2002. 350 2 Roach, A., " Session Initiation Protocol (SIP)-Specific Event 351 Notification", RFC 3265, June 2002 353 3 Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 354 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 355 Session Initiation Protocol", RFC 3261, June 2002. 357 4 Sparks, R., " SIP Call Control - Transfer", Work In Progress, July 358 2001. 360 Acknowledgments 362 Author gratefully acknowledges comments and support from Robert 363 Sparks. 365 Author's Addresses 367 Sriram Parameswar 368 Phone: 214-929-1608 369 Email: sriramkp@attbi.com