idnits 2.17.1 draft-camarillo-sipping-exploders-solution-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 a Security Considerations section. ** 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.) ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 22, 2003) is 7432 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: '5' is defined on line 207, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-simple-event-list-04 == Outdated reference: A later version (-03) exists of draft-camarillo-sipping-exploders-00 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Expires: May 22, 2004 A. Niemi 5 H. Khartabil 6 M. Isomaki 7 Nokia 8 November 22, 2003 10 Session Initiation Protocol (SIP) Exploder Invocation 11 draft-camarillo-sipping-exploders-solution-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as 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 http:// 28 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 May 22, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This document defined the SIP EXPLODE method, which is used to 42 instruct user agents to send a request to a set of destinations. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. The EXPLODE Method . . . . . . . . . . . . . . . . . . . . . . . 3 49 4. The Template Disposition-Type . . . . . . . . . . . . . . . . . 3 50 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 Normative References . . . . . . . . . . . . . . . . . . . . . . 5 52 Informational References . . . . . . . . . . . . . . . . . . . . 6 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 54 Intellectual Property and Copyright Statements . . . . . . . . . 8 56 1. Introduction 58 The need for exploders in SIP is described in [6]. Mechanisms to 59 invoke exploders in SIP need to meet the requirements listed there. 61 The SIP REFER method [4] allows a user agent to request another user 62 agent to send a request to a third party. Still, we need to define a 63 new method due to the following two reasons: 65 1. REFER allows only a single destination (i.e., a single Refer-To 66 URI.) 68 2. REFER's implicit subscriptions are problematic in certain 69 scenarios. 71 We introduce a new method called EXPLODE that carries a set of 72 destinations in a URI list. The Request-URI of an EXPLODE method 73 carries a URI in a list parameter that points to the URI list. The 74 URI may be carried in the EXPLODE request itself or may be fetched 75 from somewhere (e.g., using XCAP.) 77 EXPLODE methods do not establish any type of subscription. If a user 78 agent sending a EXPLODE request is interested in some aspect of the 79 explosion, it can send a SUBSCRIBE request to the URI received in the 80 response to the EXPLODE. 82 2. Terminology 84 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 85 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 86 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 87 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 88 compliant implementations. 90 3. The EXPLODE Method 92 EXPLODE is a SIP method as defined by RFC 3261 [2]. The EXPLODE 93 method indicates that the recipient (identified by the Request-URI) 94 should contact a set of third parties using the contact information 95 provided in the URI list that the list parameter of the Request-URI 96 points to. 98 The protocol for emitting and responding to an EXPLODE request is 99 identical to that for a BYE request in RFC 3261 [2]. 101 4. The Template Disposition-Type 103 When using REFER, the new request to be sent is described using URI 104 parameters. For example, the following Refer-To header field contains 105 the values of the Accept-Contact and Call-ID header fields of the new 106 request. 108 Refer-To: 111 Exploders typically generate several similar requests towards 112 different destinations. So, although it is possible to add the same 113 URI parameters to all the URIs in the definition of the URI list, it 114 is not an efficient way to encode that information. 116 We define a new disposition-type: template. Bodies of this 117 disposition-type (typically sipfrag bodies as defined in RFC 3420 118 [3]) provide the exploder with a template for the messages to be 119 sent. 121 The following example shows a body whose disposition-type is 122 template. It indicates that the requests to be sent should be 123 MESSAGEs carrying the text "Hello world." 125 Content-Disposition: template 126 Content-type: message/sipfrag 127 Content-Length: xxx 129 MESSAGE sip:whoever.invalid SIP/2.0 130 Content-Type: text/plain 131 Content-Length: 12 133 Hello World. 135 If any of the URIs in a Explode-To header field has a URI parameter 136 indicating a different value for a header field than the one 137 indicated in the template, the exploder MUST use the value in the URI 138 parameter. 140 Note that in order to include the method in a sipfrag body, it is 141 necessary to include the Request-URI as well (the whole Request-line 142 needs to be included as specified in RFC 3420 [3]. If the Explode-To 143 header field only contains one URI, this URI SHOULD be placed in the 144 Request-URI of the template body. Otherwise, it is RECOMMENDED that 145 the Request-URI in the template body is an invalid URI. 147 5. Example 149 We need to add the whole call flow. 151 EXPLODE sip:exploder@example.com;list=cid:cn35t8jf02@example.com SIP/2.0 152 Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bK74bf9 153 Max-Forwards: 70 154 From: Alice ;tag=9fxced76sl 155 To: Exploder 156 Call-ID: 3848276298220188511@client.example.com 157 CSeq: 1 EXPLODE 158 Contact: 159 Conten-Type: multipart/mixed;boundary="boundary1" 160 Content-Length: xxx 162 --boundary1 163 Content-Disposition: template 164 Content-type: message/sipfrag 165 Content-Length: xxx 167 MESSAGE sip:whoever.invalid SIP/2.0 168 Content-Type: text/plain 169 Content-Length: 12 171 Hello World. 173 --boundary1 174 Content-Type: application/resource-lists+xml 175 Content-Length: xxx 176 Content-ID: 178 179 180 181 182 183 184 185 186 188 --boundary1-- 190 Normative References 192 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 193 Levels", BCP 14, RFC 2119, March 1997. 195 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 196 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 197 Session Initiation Protocol", RFC 3261, June 2002. 199 [3] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 200 November 2002. 202 Informational References 204 [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer 205 Method", RFC 3515, April 2003. 207 [5] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation 208 Protocol (SIP) Event Notification Extension for Resource 209 Lists", draft-ietf-simple-event-list-04 (work in progress), June 210 2003. 212 [6] Camarillo, G., "Requirements for Session Initiation Protocol 213 (SIP) Exploder Invocation", draft-camarillo-sipping-exploders-00 214 (work in progress), September 2003. 216 Authors' Addresses 218 Gonzalo Camarillo 219 Ericsson 220 Hirsalantie 11 221 Jorvas 02420 222 Finland 224 EMail: Gonzalo.Camarillo@ericsson.com 226 Aki Niemi 227 Nokia 228 P.O. Box 321 229 NOKIA GROUP, FIN 00045 230 Finland 232 EMail: Aki.Niemi@nokia.com 234 Hisham Khartabil 235 Nokia 236 P.O. Box 321 237 NOKIA GROUP, FIN 00045 238 Finland 240 EMail: Hisham.Khartabil@nokia.com 241 Markus Isomaki 242 Nokia 243 Itamerenkatu 11-13 244 Helsinki 00180 245 Finland 247 EMail: Markus.Isomaki@nokia.com 249 Intellectual Property Statement 251 The IETF takes no position regarding the validity or scope of any 252 intellectual property or other rights that might be claimed to 253 pertain to the implementation or use of the technology described in 254 this document or the extent to which any license under such rights 255 might or might not be available; neither does it represent that it 256 has made any effort to identify any such rights. Information on the 257 IETF's procedures with respect to rights in standards-track and 258 standards-related documentation can be found in BCP-11. Copies of 259 claims of rights made available for publication and any assurances of 260 licenses to be made available, or the result of an attempt made to 261 obtain a general license or permission for the use of such 262 proprietary rights by implementors or users of this specification can 263 be obtained from the IETF Secretariat. 265 The IETF invites any interested party to bring to its attention any 266 copyrights, patents or patent applications, or other proprietary 267 rights which may cover technology that may be required to practice 268 this standard. Please address the information to the IETF Executive 269 Director. 271 Full Copyright Statement 273 Copyright (C) The Internet Society (2003). All Rights Reserved. 275 This document and translations of it may be copied and furnished to 276 others, and derivative works that comment on or otherwise explain it 277 or assist in its implementation may be prepared, copied, published 278 and distributed, in whole or in part, without restriction of any 279 kind, provided that the above copyright notice and this paragraph are 280 included on all such copies and derivative works. However, this 281 document itself may not be modified in any way, such as by removing 282 the copyright notice or references to the Internet Society or other 283 Internet organizations, except as needed for the purpose of 284 developing Internet standards in which case the procedures for 285 copyrights defined in the Internet Standards process must be 286 followed, or as required to translate it into languages other than 287 English. 289 The limited permissions granted above are perpetual and will not be 290 revoked by the Internet Society or its successors or assignees. 292 This document and the information contained herein is provided on an 293 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 294 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 295 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 296 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 297 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 299 Acknowledgment 301 Funding for the RFC Editor function is currently provided by the 302 Internet Society.