idnits 2.17.1 draft-camarillo-sipping-exploders-02.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.) 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 (February 6, 2004) is 7385 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) == Outdated reference: A later version (-07) exists of draft-ietf-simple-event-list-04 == Outdated reference: A later version (-01) exists of draft-rosenberg-simple-messaging-requirements-00 Summary: 2 errors (**), 0 flaws (~~), 5 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: August 6, 2004 February 6, 2004 6 Requirements and Framework for Session Initiation Protocol (SIP) 7 Exploder Invocation 8 draft-camarillo-sipping-exploders-02.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-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 http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 6, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This document describes the need for SIP exploders and provides 39 requirements for their invocation. Additionaly, it defines a 40 framework which includes all the SIP extensions needed to meet these 41 requirements. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 4.1 Carrying URI Lists in SIP . . . . . . . . . . . . . . . . . . 5 50 4.2 Managing Ad-Hoc URI Lists . . . . . . . . . . . . . . . . . . 5 51 4.3 Transaction State Information . . . . . . . . . . . . . . . . 5 52 4.4 Multiple REFER Targets . . . . . . . . . . . . . . . . . . . . 6 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 54 6. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 Normative References . . . . . . . . . . . . . . . . . . . . . 6 56 Informational References . . . . . . . . . . . . . . . . . . . 6 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 58 Intellectual Property and Copyright Statements . . . . . . . . 8 60 1. Introduction 62 Some applications require that, at a given moment, a SIP UA performs 63 a similar transaction with a number of remote UAs. For example, an 64 instant messaging application that needs to send a particular message 65 (e.g., "Hello folks") to n receivers needs to send n MESSAGE 66 requests; one to each receiver. 68 When the transacton that needs to be repeated consists of a large 69 request, or the number of recipients is high, or both, the access 70 network of the UA needs to carry a considerable amount of traffic. 71 Completing all the transactions on a low-bandwidth access would 72 require a long time. This is unacceptable for a number of 73 applications. 75 A solution to this problem consists of introducing exploders in the 76 network. The task of an exploder is to receive a request from a UA 77 and send a number of similar requests to a number of destinations. 78 Once the requests are sent, the exploder needs to inform the UA about 79 their status. Effectively, the exploder behaves as a B2BUA. 81 Note that resource lists, as described in [2], already use SIP 82 exploders for SUBSCRIBE transactions. Still, the set of destinations 83 needs to be preconfigured using out-of-band mechanisms (e.g., XCAP). 85 The Advanced Instant Messaging Requirements for SIP [3] also 86 mentions the need for exploders for MESSAGE transactions: 88 "REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc 89 group, where the identities of the recipients are carried in the 90 message itself." 92 The remainder of this document provides requirements to invoke 93 exploders in an efficient manner and a framework that meets these 94 requirements. 96 2. Terminology 98 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 99 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 100 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 101 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 102 compliant implementations. 104 3. Requirements 106 This section contains the requirements: 108 1. The invocation mechanism MUST allow the invoker to provide a 109 list of destination URIs to the exploder. This URI list MAY 110 consist of one or more URIs. 112 2. It MUST be possible to send URI list "deltas" to update the list 113 of URIs handled by the exploder. 115 3. The invocation mechanism MUST NOT be request specific. 117 4. The invocation mechanism SHOULD NOT require more than one RTT. 119 5. An exploder MAY provide services beyond request explosion. That 120 is, exploders can be modelled as application servers. For 121 example, an exploder handling INVITE requests may behave as a 122 conference server and perform media mixing for all the 123 participants. 125 6. The interpretation of the meaning of the URI list sent by the 126 invoker MUST be at the discretion of the application to which 127 the list is sent. 129 7. It MUST be possible for the invoker to find out about the result 130 of the operations performed by the application with the URI 131 list. An invoker may, for instance, be interested in the status 132 of the transactions initiated by the exploder. 134 8. It MUST be possible for the application that makes use of a list 135 of URIs to convey the list of URIs to any recipients of messages 136 created by the application from that list. OPEN ISSUE: do we 137 really need this requirement? 139 9. Exploders MUST NOT perform any request explosion without 140 authenticating the invoker. 142 10. The UA MUST be able to provide credentials to the exploder so 143 that the exploder can use them to prove to the destinations that 144 it is sending requests on behalf of the UA. 146 4. Framework 148 Although Section 3 contains specific requirements for SIP exploders, 149 this framework is not restricted to application servers that only 150 provide request explosion services. We also deal with application 151 servers that provide a particular service that includes a request 152 explosion (e.g., a conference server that INVITEs several 153 participants which are chosen by a user agent). 155 We need to use several SIP extensions to meet the requirements in 156 Section 3. We list these extensions in the following sections and 157 explain which role they play within the framework. 159 4.1 Carrying URI Lists in SIP 161 User agents can send a list of URIs to an application server using 162 the list SIP and SIPS URI parameter defined in 163 (draft-camarillo-sipping-uri-list-01). The user agent adds a list 164 parameter to the Request-URI of the SIP request sent to the 165 application server. This parameter contains a pointer to a URI list, 166 which can be carried in the SIP request itself or can be stored in an 167 external server (e.g., an http URI pointing to an XCAP resource 168 list). The way the application server interprets the URI list 169 received in the request is service specific. 171 4.2 Managing Ad-Hoc URI Lists 173 An application server that receives a request with a URI list (or a 174 pointer to it) creates a so called ad-hoc list, whose lifetime 175 depends on the service provided by the server. Services that involve 176 ad-hoc lists that are valid for a period of time need to allow user 177 agents to modify these lists. 179 A user agent can manage ad-hoc lists at a server in two ways, as 180 described in (draft-camarillo-sipping-adhoc-management-00): using SIP 181 or using an external means (e.g., XCAP). 183 User agents using SIP to manage ad-hoc lists send a new SIP request 184 with a pointer to a new list that will substitute the old list. 186 User agents using an external means to manage ad-hoc lists need to 187 obtain from the server a URI that allows them to manipulate the list 188 (e.g., an http URI pointing to an XCAP resource list). The server 189 provides such a URI in an Associated-List-Manipulation header field 190 in the response to the request that created the ad-hoc list. 192 4.3 Transaction State Information 194 User agents may be interested in the results of the message explosion 195 at the application server. That is, user agents may want to know the 196 result of the transactions that the application server initiated 197 towards the URIs in the URI list provided by the user agent. The 198 transaction state event package defined in 199 (draft-camarillo-sipping-transac-package-00) provides this 200 information to the user agent subscribing to this package. 202 Still, in order to subscribe to the transaction state event package, 203 the user agent needs a URI to subscribe to. The application server 204 provides such a URI in an Associated-Transactions-State header field 205 in the response to the request that triggered the new transactions, 206 as defined in (draft-camarillo-sipping-transac-package-00). 208 4.4 Multiple REFER Targets 210 Building REFER requests with multiple REFER targets requires special 211 considerations, as described in 212 (draft-camarillo-sipping-multiple-refer-00). The Refer-To header 213 field carries a pointer to a URI list, and the NOTIFIES carry 214 transaction state information using the transaction state event 215 package. User agents may use bodies whose disposition type is 216 template to describe the messages to be sent by the application 217 server. 219 A conferencing application is an example of an application that may 220 use REFERs with multiple REFER targets. A user agent may send a REFER 221 to the conferencing server so that the server BYEs a set of users. 223 5. Security Considerations 225 Requirements related to security are considered in Section 3. 227 TBD: this section should be expanded considerably. 229 6. Acknowledges 231 Duncan Mills and Miguel A. Garcia-Martin supported the idea of 1 to n 232 MESSAGEs. 234 Normative References 236 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 237 Levels", BCP 14, RFC 2119, March 1997. 239 Informational References 241 [2] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation 242 Protocol (SIP) Event Notification Extension for Resource 243 Lists", draft-ietf-simple-event-list-04 (work in progress), June 244 2003. 246 [3] Rosenberg, J., "Advanced Instant Messaging Requirements for the 247 Session Initiation Protocol (SIP)", 248 draft-rosenberg-simple-messaging-requirements-00 (work in 249 progress), December 2002. 251 Author's Address 253 Gonzalo Camarillo 254 Ericsson 255 Hirsalantie 11 256 Jorvas 02420 257 Finland 259 EMail: Gonzalo.Camarillo@ericsson.com 261 Intellectual Property Statement 263 The IETF takes no position regarding the validity or scope of any 264 intellectual property or other rights that might be claimed to 265 pertain to the implementation or use of the technology described in 266 this document or the extent to which any license under such rights 267 might or might not be available; neither does it represent that it 268 has made any effort to identify any such rights. Information on the 269 IETF's procedures with respect to rights in standards-track and 270 standards-related documentation can be found in BCP-11. Copies of 271 claims of rights made available for publication and any assurances of 272 licenses to be made available, or the result of an attempt made to 273 obtain a general license or permission for the use of such 274 proprietary rights by implementors or users of this specification can 275 be obtained from the IETF Secretariat. 277 The IETF invites any interested party to bring to its attention any 278 copyrights, patents or patent applications, or other proprietary 279 rights which may cover technology that may be required to practice 280 this standard. Please address the information to the IETF Executive 281 Director. 283 Full Copyright Statement 285 Copyright (C) The Internet Society (2004). All Rights Reserved. 287 This document and translations of it may be copied and furnished to 288 others, and derivative works that comment on or otherwise explain it 289 or assist in its implementation may be prepared, copied, published 290 and distributed, in whole or in part, without restriction of any 291 kind, provided that the above copyright notice and this paragraph are 292 included on all such copies and derivative works. However, this 293 document itself may not be modified in any way, such as by removing 294 the copyright notice or references to the Internet Society or other 295 Internet organizations, except as needed for the purpose of 296 developing Internet standards in which case the procedures for 297 copyrights defined in the Internet Standards process must be 298 followed, or as required to translate it into languages other than 299 English. 301 The limited permissions granted above are perpetual and will not be 302 revoked by the Internet Society or its successors or assignees. 304 This document and the information contained herein is provided on an 305 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 306 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 307 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 308 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 309 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 311 Acknowledgment 313 Funding for the RFC Editor function is currently provided by the 314 Internet Society.