idnits 2.17.1 draft-olson-sipping-refer-extensions-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 304. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 310. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 326), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 5) being 72 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 16 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 18, 2004) is 7222 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 247, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 261, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (ref. '4') (Obsoleted by RFC 6665) == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-02 Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING S. Olson 2 Internet-Draft O. Levin 3 Expires: January 16, 2005 Microsoft Corporation 4 July 18, 2004 6 REFER extensions 7 draft-olson-sipping-refer-extensions-02 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 16, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 The REFER extensions presented in this draft are usage of Feature 43 parameters with REFER and the ability to suppress an implicit 44 subscription with REFER. The extensions have been discussed in 45 SIPPING WG and are targeted to become SIP WG items. 47 Table of Contents 49 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Using Feature Parameters with REFER . . . . . . . . . . . . . 5 52 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.2 Definition . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3.3.1 isfocus Usage . . . . . . . . . . . . . . . . . . . . 5 56 3.3.2 Media Type Usage . . . . . . . . . . . . . . . . . . . 5 57 4. Suppressing the REFER Implicit Subscription . . . . . . . . . 6 58 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.3 Definition . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.4 Preventing Forking of REFER Requests . . . . . . . . . . . 7 62 4.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 68 Intellectual Property and Copyright Statements . . . . . . . . 12 70 1. Terminology 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119 [1]. 76 To simplify discussions of the REFER method and its extensions, three 77 new terms are being used throughout the document: 78 o REFER-Issuer: the UA issuing the REFER request 79 o REFER-Recipient: the UA receiving the REFER request 80 o REFER-Target: the UA designated in the Refer-To URI 82 2. Introduction 84 The REFER extensions presented in this draft are usage of Feature 85 parameters with REFER and the ability to suppress an implicit 86 subscription with REFER. The extensions have been discussed in 87 SIPPING WG and are targeted to become SIP WG items. 89 3. Using Feature Parameters with REFER 91 3.1 Introduction 93 This document extends REFER method defined in RFC-3515 [3] to be used 94 with feature parameters defined in [5]. 96 3.2 Definition 98 The Refer-To BNF from RFC-3515: 100 Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) * (SEMI generic-param) 102 is extended to: 104 Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) * (SEMI refer-param) 105 refer-param = generic-param / feature-param 107 where feature-param is defined in Section 9 of [5]. 109 3.3 Examples 111 3.3.1 isfocus Usage 113 The syntax below shows how the "isfocus" feature parameter can be 114 used by REFER-Issuer to tell the REFER-Recipient that the 115 REFER-Target is a conference focus and, consequently, sending an 116 INVITE will bring the REFER-Recipient into the conference: 118 Refer-To: sip:conf44@example.com;isfocus 120 3.3.2 Media Type Usage 122 The syntax below shows how a REFER-Issuer can tell the 123 REFER-Recipient that the REFER-Target supports audio and video and, 124 consequently, that a video and audio session can be established by 125 sending an INVITE to the REFER-Target: 127 Refer-To: sip:videophone@example.com;audio;video 129 4. Suppressing the REFER Implicit Subscription 131 4.1 Introduction 133 The REFER specification specifies that every REFER creates an 134 implicit subscription between the REFER-Issuer and the 135 REFER-Recipient. This document defines a new option tag, 136 "norefersub", which specifies that an implicit subscription for event 137 package refer should not be created as a result of accepting this 138 REFER request. 140 4.2 Motivation 142 The REFER specification mandates that every REFER creates an implicit 143 subscription between the REFER-Issuer and the REFER-Recipient. This 144 subscription results in at least one NOTIFY being sent from the 145 REFER-Recipient to the REFER-Issuer. The REFER-Recipient may choose 146 to cancel the implicit subscription with this NOTIFY. The 147 REFER-Issuer may choose to cancel this implicit subscription with an 148 explicit SUBSCRIBE (Expires: 0) after receipt of the initial NOTIFY 149 or by sending a 481 response to this initial NOTIFY request. 151 One purpose of requiring the implicit subscription and initial NOTIFY 152 is to allow for the situation where the REFER request gets forked and 153 the REFER-Issuer needs a way to see the multiple dialogs that may be 154 established as a result of the forked REFER. This is the same 155 approach used to handle forking of SUBSCRIBE [4] requests. Where the 156 REFER-Issuer explicitly specifies that forking not occur, the 157 requirement that an implicit subscription be established is 158 unnecessary. 160 Another purpose of the NOTIFY is to inform the REFER-Issuer of the 161 progress of the SIP transaction that results from the REFER at the 162 REFER-Recipient. In the case where the REFER-Issuer is already aware 163 of the progress of the requested operation, such as when the 164 REFER-Issuer has an explicit subscription to the dialog event package 165 at the REFER-Recipient, the implicit subscription and resultant 166 NOTIFY traffic related to the REFER can create an unnecessary network 167 overhead. 169 4.3 Definition 171 This document defines a new option tag, "norefersub", which specifies 172 that an implicit subscription for event package refer should not be 173 created as a result of accepting this REFER request. 175 The "norefersub" option tag MUST be used by the REFER-Issuer only 176 when the REFER-Issuer can be certain that the REFER request will not 177 be forked. 179 The REFER-Issuer can place the "norefersub" option tag either in the 180 Require header or in the Supported header of the REFER request, 181 subject to application requirements. 183 If the REFER-Issuer inserts the option tag in the Supported header 184 but the REFER-Recipient doesn't grant the suggestion, an implicit 185 subscription is created as in default case. 187 If the REFER-Issuer inserts the option tag in the Require header but 188 the REFER-Recipient is not willing to grant the request, the REFER 189 request is rejected. 191 If the REFER-Recipient is willing to grant the "norefersub" behavior 192 for the issued REFER request, it MUST insert a Supported: norefersub 193 header in the 2xx response to the REFER-Issuer. In this case no 194 dialog is created. 196 4.4 Preventing Forking of REFER Requests 198 The REFER specification allows for the possibility of forking a REFER 199 request which is sent outside of an existing dialog. The 200 REFER-Issuer can ensure that REFER doesn't get forked by sending 201 REFER to a REFER-Recipient which has GRUU properties according to 202 definitions of [7]. 204 4.5 Example 206 An example of REFER which suppresses the implicit subscription is 207 shown below: 209 REFER sip:pc-b@tradewind.com SIP/2.0 210 Via: SIP/2.0/TCP issuer.tradewind.com;branch=z9hG4bK-a-1 211 From: ;tag=1a 212 To: 213 Call-ID: 1@issuer.tradewind.com 214 CSeq: 234234 REFER 215 Max-Forwards: 70 216 Refer-To: 217 Require: norefersub 218 Accept-Contact: *;audio;require 219 Contact: sip:a@issuer.tradewind.com 220 Content-Type: message/sipfrag 221 Content-Id: <1239103912039@issuer.tradewind.com> 222 Content-Length: ... 224 5. IANA Considerations 226 This document defines a new option tag, "norefersub", which specifies 227 that an implicit subscription for event package refer should not be 228 created as a result of accepting this REFER request. This option tag 229 is only meaningful for the REFER request defined in RFC3515. 231 6. Security Considerations 233 This extension doesn't introduce new security threads beyond those 234 identified and addressed in the core SIP specifications. 236 7. Acknowledgements 238 The authors would like to thank Sriram Parameswar for his ideas being 239 originally presented in draft-parameswar-sipping-norefersub-00 and 240 incorporated in this document. 242 8 References 244 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 245 Levels", BCP 14, RFC 2119, March 1997. 247 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 248 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 249 Session Initiation Protocol", RFC 3261, June 2002. 251 [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer 252 Method", RFC 3515, April 2003. 254 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 255 Notification", RFC 3265, June 2002. 257 [5] Rosenberg, J., "Indicating User Agent Capabilities in the 258 Session Initiation Protocol (SIP)", 259 draft-ietf-sip-callee-caps-03 (work in progress), January 2004. 261 [6] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller 262 Preferences for the Session Initiation Protocol (SIP)", 263 draft-ietf-sip-callerprefs-10 (work in progress), October 2003. 265 [7] Rosenberg, J., "Obtaining and Using Globally Routable User Agent 266 (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", 267 draft-ietf-sip-gruu-02 (work in progress), July 2004. 269 Authors' Addresses 271 Sean Olson 272 Microsoft Corporation 273 One Microsoft Way 274 Redmond, WA 98052 275 USA 277 Phone: +1-425-707-2846 278 EMail: seanol@microsoft.com 279 Orit Levin 280 Microsoft Corporation 281 One Microsoft Way 282 Redmond, WA 98052 283 USA 285 Phone: +1-425-722-2225 286 EMail: oritl@microsoft.com 288 Intellectual Property Statement 290 The IETF takes no position regarding the validity or scope of any 291 Intellectual Property Rights or other rights that might be claimed to 292 pertain to the implementation or use of the technology described in 293 this document or the extent to which any license under such rights 294 might or might not be available; nor does it represent that it has 295 made any independent effort to identify any such rights. Information 296 on the procedures with respect to rights in RFC documents can be 297 found in BCP 78 and BCP 79. 299 Copies of IPR disclosures made to the IETF Secretariat and any 300 assurances of licenses to be made available, or the result of an 301 attempt made to obtain a general license or permission for the use of 302 such proprietary rights by implementers or users of this 303 specification can be obtained from the IETF on-line IPR repository at 304 http://www.ietf.org/ipr. 306 The IETF invites any interested party to bring to its attention any 307 copyrights, patents or patent applications, or other proprietary 308 rights that may cover technology that may be required to implement 309 this standard. Please address the information to the IETF at 310 ietf-ipr@ietf.org. 312 Disclaimer of Validity 314 This document and the information contained herein are provided on an 315 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 316 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 317 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 318 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 319 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 320 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 322 Copyright Statement 324 Copyright (C) The Internet Society (2004). This document is subject 325 to the rights, licenses and restrictions contained in BCP 78, and 326 except as set forth therein, the authors retain all their rights. 328 Acknowledgment 330 Funding for the RFC Editor function is currently provided by the 331 Internet Society.