idnits 2.17.1 draft-ietf-sip-refer-with-norefersub-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 250. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 227. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 234. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 240. ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 36 instances of too long lines in the document, the longest one being 1 character 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 (October 17, 2004) is 7124 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 191, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 195, 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: 7 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIP O. Levin 2 Internet-Draft Microsoft Corporation 3 Expires: April 17, 2005 October 17, 2004 5 Suppression of REFER Implicit Subscription 6 draft-ietf-sip-refer-with-norefersub-00 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 17, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). 39 Abstract 41 This specification defines the way to suppress an implicit 42 subscription with REFER method in SIP. 44 Table of Contents 46 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 48 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 4. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 6 50 5. Preventing Forking of REFER Requests . . . . . . . . . . . . 7 51 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 8 52 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 53 8. Security Considerations . . . . . . . . . . . . . . . . . . 10 54 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 55 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 56 10.1 Normative References . . . . . . . . . . . . . . . . . . . 12 57 10.2 Informational References . . . . . . . . . . . . . . . . . 12 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 59 Intellectual Property and Copyright Statements . . . . . . . 13 61 1. Terminology 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC 2119 [1]. 67 To simplify discussions of the REFER method and its extensions, three 68 new terms are being used throughout the document: 69 o REFER-Issuer: the UA issuing the REFER request 70 o REFER-Recipient: the UA receiving the REFER request 71 o REFER-Target: the UA designated in the Refer-To URI 73 2. Introduction 75 The REFER specification specifies that every REFER creates an 76 implicit subscription between the REFER-Issuer and the 77 REFER-Recipient. This document defines a new option tag, 78 "norefersub", which specifies that an implicit subscription for event 79 package refer should not be created as a result of accepting this 80 REFER request. 82 3. Motivation 84 The REFER specification mandates that every REFER creates an implicit 85 subscription between the REFER-Issuer and the REFER-Recipient. This 86 subscription results in at least one NOTIFY being sent from the 87 REFER-Recipient to the REFER-Issuer. The REFER-Recipient may choose 88 to cancel the implicit subscription with this NOTIFY. The 89 REFER-Issuer may choose to cancel this implicit subscription with an 90 explicit SUBSCRIBE (Expires: 0) after receipt of the initial NOTIFY 91 or by sending a 481 response to this initial NOTIFY request. 93 One purpose of requiring the implicit subscription and initial NOTIFY 94 is to allow for the situation where the REFER request gets forked and 95 the REFER-Issuer needs a way to see the multiple dialogs that may be 96 established as a result of the forked REFER. This is the same 97 approach used to handle forking of SUBSCRIBE [4] requests. Where the 98 REFER-Issuer explicitly specifies that forking not occur, the 99 requirement that an implicit subscription be established is 100 unnecessary. 102 Another purpose of the NOTIFY is to inform the REFER-Issuer of the 103 progress of the SIP transaction that results from the REFER at the 104 REFER-Recipient. In the case where the REFER-Issuer is already aware 105 of the progress of the requested operation, such as when the 106 REFER-Issuer has an explicit subscription to the dialog event package 107 at the REFER-Recipient, the implicit subscription and resultant 108 NOTIFY traffic related to the REFER can create an unnecessary network 109 overhead. 111 4. Definition 113 This document defines a new option tag, "norefersub", which specifies 114 that an implicit subscription for event package refer should not be 115 created as a result of accepting this REFER request. 117 The "norefersub" option tag MUST be used by the REFER-Issuer only 118 when the REFER-Issuer can be certain that the REFER request will not 119 be forked. 121 The REFER-Issuer can place the "norefersub" option tag either in the 122 Require header or in the Supported header of the REFER request, 123 subject to application requirements. 125 If the REFER-Issuer inserts the option tag in the Supported header 126 but the REFER-Recipient doesn't grant the suggestion, an implicit 127 subscription is created as in default case. 129 If the REFER-Issuer inserts the option tag in the Require header but 130 the REFER-Recipient is not willing to grant the request, the REFER 131 request is rejected. 133 If the REFER-Recipient is willing to grant the "norefersub" behavior 134 for the issued REFER request, it MUST insert a Supported: norefersub 135 header in the 2xx response to the REFER-Issuer. In this case no 136 dialog is created. 138 5. Preventing Forking of REFER Requests 140 The REFER specification allows for the possibility of forking a REFER 141 request which is sent outside of an existing dialog. The 142 REFER-Issuer can ensure that REFER doesn't get forked by sending 143 REFER to a REFER-Recipient which has GRUU properties according to 144 definitions of [5]. 146 6. Example 148 An example of REFER which suppresses the implicit subscription is 149 shown below: 151 REFER sip:pc-b@tradewind.com SIP/2.0 152 Via: SIP/2.0/TCP issuer.tradewind.com;branch=z9hG4bK-a-1 153 From: ;tag=1a 154 To: 155 Call-ID: 1@issuer.tradewind.com 156 CSeq: 234234 REFER 157 Max-Forwards: 70 158 Refer-To: 159 Require: norefersub 160 Accept-Contact: *;audio;require 161 Contact: sip:a@issuer.tradewind.com 162 Content-Type: message/sipfrag 163 Content-Id: <1239103912039@issuer.tradewind.com> 164 Content-Length: ... 166 7. IANA Considerations 168 This document defines a new option tag, "norefersub", which specifies 169 that no implicit subscription should be created as a result of 170 accepting the REFER request. This option tag is only meaningful for 171 the REFER request defined in RFC3515. 173 8. Security Considerations 175 This extension doesn't introduce new security threads beyond those 176 identified and addressed in the core SIP specifications. 178 9. Acknowledgements 180 The SIP community would like to thank Sriram Parameswar for his ideas 181 being originally presented in draft-parameswar-sipping-norefersub-00 182 and incorporated in this document. 184 10. References 186 10.1 Normative References 188 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 189 Levels", BCP 14, RFC 2119, March 1997. 191 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 192 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 193 Session Initiation Protocol", RFC 3261, June 2002. 195 [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer 196 Method", RFC 3515, April 2003. 198 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 199 Notification", RFC 3265, June 2002. 201 10.2 Informational References 203 [5] Rosenberg, J., "Obtaining and Using Globally Routable User Agent 204 (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", 205 draft-ietf-sip-gruu-02 (work in progress), July 2004. 207 Author's Address 209 Orit Levin 210 Microsoft Corporation 211 One Microsoft Way 212 Redmond, WA 98052 213 USA 215 Phone: +1-425-722-2225 216 EMail: oritl@microsoft.com 218 Intellectual Property Statement 220 The IETF takes no position regarding the validity or scope of any 221 Intellectual Property Rights or other rights that might be claimed to 222 pertain to the implementation or use of the technology described in 223 this document or the extent to which any license under such rights 224 might or might not be available; nor does it represent that it has 225 made any independent effort to identify any such rights. Information 226 on the procedures with respect to rights in RFC documents can be 227 found in BCP 78 and BCP 79. 229 Copies of IPR disclosures made to the IETF Secretariat and any 230 assurances of licenses to be made available, or the result of an 231 attempt made to obtain a general license or permission for the use of 232 such proprietary rights by implementers or users of this 233 specification can be obtained from the IETF on-line IPR repository at 234 http://www.ietf.org/ipr. 236 The IETF invites any interested party to bring to its attention any 237 copyrights, patents or patent applications, or other proprietary 238 rights that may cover technology that may be required to implement 239 this standard. Please address the information to the IETF at 240 ietf-ipr@ietf.org. 242 Disclaimer of Validity 244 This document and the information contained herein are provided on an 245 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 246 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 247 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 248 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 249 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 250 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 252 Copyright Statement 254 Copyright (C) The Internet Society (2004). This document is subject 255 to the rights, licenses and restrictions contained in BCP 78, and 256 except as set forth therein, the authors retain all their rights. 258 Acknowledgment 260 Funding for the RFC Editor function is currently provided by the 261 Internet Society.