idnits 2.17.1 draft-garcia-sipping-message-exploder-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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 457. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 447. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 463), 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 313 has weird spacing: '...y could becom...' == 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 (May 11, 2004) is 7288 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 (-02) exists of draft-camarillo-sipping-uri-list-00 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-05) exists of draft-ietf-simple-xcap-list-usage-01 == Outdated reference: A later version (-01) exists of draft-rosenberg-simple-messaging-requirements-00 == Outdated reference: A later version (-03) exists of draft-ietf-sip-authid-body-02 Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING Working Group M. Garcia-Martin 2 Internet-Draft Nokia 3 Expires: November 9, 2004 G. Camarillo 4 Ericsson 5 May 11, 2004 7 Multiple recipient MESSAGE requests in the Session Initiation 8 Protocol (SIP) 9 draft-garcia-sipping-message-exploder-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I 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 29 http://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 November 9, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document specifies how to request a MESSAGE exploder to send a 43 copy of a MESSAGE to a set of destinations. The client sends a SIP 44 MESSAGE request with a URI list to the MESSAGE exploder, which sends 45 a similar MESSAGE request to each of URIs included in the list. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Procedures at the UAC . . . . . . . . . . . . . . . . . . . . 4 52 4. Procedures at the MESSAGE exploder . . . . . . . . . . . . . . 5 53 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 55 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 56 8. Change control . . . . . . . . . . . . . . . . . . . . . . . . 9 57 8.1 Changes from 58 draft-garcia-simple-message-exploder-00.txt to 59 draft-garcia-sipping-message-exploder-00.txt . . . . . . . 9 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 62 9.2 Informational References . . . . . . . . . . . . . . . . . . 10 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 64 Intellectual Property and Copyright Statements . . . . . . . . 11 66 1. Introduction 68 SIP [2] can carry instant messages in MESSAGE [3] requests. The 69 Advanced Instant Messaging Requirements for SIP [6] mentions the need 70 for sending a MESSAGE request to multiple receipients: 72 "REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc 73 group, where the identities of the recipients are carried in the 74 message itself." 76 To meet this requirement, we allow SIP MESSAGE requests carry an URI 77 list as specified in [4]. The Request-URI of the MESSAGE request 78 contains a "list" URI parameter that points to a body part that 79 carries the URI list. A specialized application server receives the 80 request and sends a similar MESSAGE request to each of the URIs in 81 the list. Each of these MESSAGE requests contains a copy of the body 82 included in the original MESSAGE request. 84 The UAC needs to be configured with the SIP URI of the application 85 server that provides the functionality. Discovering and provisioning 86 of this URI to the UAC is outside the scope of this document. 88 2. Terminology 90 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 91 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 92 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 93 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 94 compliant implementations. 96 'MESSAGE exploder': SIP application server that receives a MESSAGE 97 request with a URI list and sends a similar MESSAGE request to each 98 URI in the list. MESSAGE exploders behave effectively as specialised 99 B2BUAs (Back-To-Back-User-Agents). A MESSAGE exploder can be 100 modelled as a fractional function of a B2BUA that can offer other 101 exploder functionality (e.g., for other SIP methods), although that 102 other exploder functionality is outside the scope of this document. 103 In this document we only discuss the explosion of SIP MESSAGE 104 requests. 106 'Incoming MESSAGE request': A SIP MESSAGE request that a UAC creates 107 and addresses to a SIP MESSAGE exploder. Besides the regular instant 108 message payload, an incoming MESSAGE request contains a URI list. 110 'Outgoing MESSAGE request': A SIP MESSAGE request that a MESSAGE 111 exploder creates and addresses to a UAS. It contains the regular 112 instant message payload. 114 3. Procedures at the UAC 116 A client that wants to create a multiple recipient MESSAGE request 117 SHOULD add a "list" parameter (specified in [4]) to the MESSAGE 118 exploder's URI and MUST place the resulting URI in the Request-URI of 119 the MESSAGE request. The "list" parameter MUST contain a pointer to 120 a URI list that contains the recipients of the MESSAGE. The 121 following is an example of a Request-URI with a "list" parameter. 123 sip:message-exploder.example.com;list=cid:cn35t8jf@uac.example.com 125 Multiple recipient MESSAGE requests will typically contain a 126 multiparty body that contains the body carrying the list and the 127 actual instant message payload. In some cases, the MESSAGE request 128 will contain bodies other than the text and the list bodies, for 129 instance, when the request is protected with S/MIME. 131 Typically the MESSAGE exploder will copy all the significant header 132 fields in the exploded MESSAGE request. However, there might be 133 cases where the SIP UA wants the MESSAGE exploder to add a particular 134 header field with a particular value, when the header field wasn't 135 present in the MESSAGE request sent by the UAC. In this case the UAC 136 MAY use the "?" mechanism described in Section 19.1.1 of RFC 3261 [2] 137 to encode extra information in any URI in the list. However, the UAC 138 MUST NOT use the special "body" hname (see Section 19.1.1 of RFC 3261 139 [2]) to encode a body, since the body is present in the MESSAGE 140 request itself. 142 The following is an example of a URI that uses the "?" mechanism: 144 sip:message-exploder.example.com;list=cid:cn35t8jf@uac.example.com? 145 Accept-Contact=*%3bmobility%3d%22mobile%22 147 The previous URI requests the MESSAGE exploder to add the following 148 header field to a MESSAGE request: 150 Accept-Contact: *;mobility="mobile" 152 As described in [4], the default format for URI lists in SIP is the 153 XCAP resource list format [5]. User Agents compliant to this 154 specification MUST support the XCAP resource list format [5] and MAY 155 support other formats. 157 UAs generating multiple recipient MESSAGEs SHOULD use flat lists 158 (i.e., no hierarchical lists), SHOULD NOT use any entry's attributes 159 but "uri", and SHOULD NOT include any elements inside entries but 160 "display-name" elements. 162 4. Procedures at the MESSAGE exploder 164 On receiving a MESSAGE request that contains a "list" parameter in 165 the Request-URI as described in [4], a MESSAGE exploder SHOULD answer 166 to the UAC with a 202 Accepted response. Note that the status code 167 in the response to the MESSAGE does not provide any information about 168 whether or not the MESSAGEs generated by the exploder were 169 successfully delivered to the URIs in the list. That is, a 202 170 Accepted means that the MESSAGE exploder has received the MESSAGE and 171 that it will try to send a similar MESSAGE to the URIs in the list. 172 Designing a mechanism to inform a client about the delivery status of 173 an instant message is outside the scope of this document. 175 On receiving a MESSAGE request that contains a "list" parameter in 176 the Request-URI as described [4], a MESSAGE exploder SHOULD create as 177 many new MESSAGE requests as URIs the list contains, except when two 178 of those URIs are equivalent (section 19.1.4 of RFC 3261 [2] defines 179 equivalent URIs), in which case the MESSAGE exploder SHOULD create 180 only one outgoing MESSAGE request per URI. 182 The Request-URI of each of the outgoing MESSAGE requests MUST NOT 183 include any "list" parameters. This avoids loops in exploding 184 MESSAGE requests. It also avoids the implementation a MESSAGE 185 exploder functionality in the UAS, that otherwise, would be required. 187 On creating the body of each of the outgoing MESSAGE requests, the 188 MESSAGE exploder tries to keep the relevant bodies of the incoming 189 MESSAGE request and copies them to the outgoing MESSAGE request. The 190 following guidelines are provided: 192 o The incoming MESSAGE request typically contains a URI list body 193 [4] with the actual list of recipients. The MESSAGE exploder need 194 not copy the URI list body to the outgoing MESSAGE request, 195 although it MAY do it. 196 NOTE: This document does not provide any semantics associated to a 197 URI list body included in an outgoing MESSAGE request. Future 198 extensions can indicate actions at a UAS when it receives that 199 body. 200 o The MESSAGE exploder MUST NOT copy any security body (such as an 201 S/MIME signed body) addressed to the MESSAGE exploder to the 202 outgoing MESSAGE request. This includes, e.g., security bodies 203 signed with the public key of the exploder. 204 o The MESSAGE exploder SHOULD copy all the rest of the message 205 bodies (e.g., text messages, images, etc.) to the outgoing MESSAGE 206 request. 207 o If there is only one body left, the MESSAGE exploder MUST remove 208 the multipart/mixed wrapper in the outgoing MESSAGE request. 210 The rest of the MESSAGE request corresponding to a given URI in the 211 list MUST be created following the rules in Section 19.1.5 "Forming 212 Requests from a URI" of RFC 3261 [2]. In particular, Section 19.1.5 213 of RFC 3261 [2] states: 215 "An implementation SHOULD treat the presence of any headers or body 216 parts in the URI as a desire to include them in the message, and 217 choose to honor the request on a per-component basis." 219 SIP allows to append a "method" parameter to a URI. Therefore, it is 220 legitimate that an the "uri" attribute of the "entry" element in the 221 XCAP resource list contains a "method" parameter. MESSAGE exploders 222 MUST generate only MESSAGE requests, regardless of the "method" 223 parameter that the URIs in the list indicate. Effectively, MESSAGE 224 exploders MUST ignore the "method" parameter in each of the URIs 225 present in the URI list. 227 It is RECOMMENDED that the MESSAGE exploder copies the value From 228 header field of the incoming MESSAGE into the outgoing MESSAGE 229 requests (note that this need not apply to the "tag" parameter). The 230 MESSAGE exploder SHOULD also copy to the outgoing MESSAGE request any 231 P-Asserted-Identity header fields that can be present in the incoming 232 MESSAGE request. 234 On each given outgoing MESSAGE request, the MESSAGE exploder SHOULD 235 generate a new To header field value which, according to the 236 procedures of RFC 3261 Section 8.1.1.1, should be equal to the 237 Request-URI of the outgoing MESSAGE request. 239 On each given outgoing MESSAGE request, the MESSAGE exploder SHOULD 240 initialize the values of the Call-ID, CSeq and Max-Forwards header 241 fields. The MESSAGE exploder should also include its own value in 242 the Via header field. 244 A MESSAGE exploder receiving a URI list with more information than 245 what we have just described SHOULD discard all the extra information. 247 As described in [4], the default format for URI lists in SIP is the 248 XCAP resource list format [5]. MESSAGE exploders compliant to this 249 specification MUST support the XCAP resource list format [5] and MAY 250 support other formats. 252 5. Examples 254 The following is an example of an incoming MESSAGE request which 255 carries a URI list in its body. 257 MESSAGE sip:exploder.example.com;list=cid:cn35t8jf@uac.example.com 258 SIP/2.0 259 Via: SIP/2.0/TCP uac.example.com 260 ;branch=z9hG4bKhjhs8ass83 261 Max-Forwards: 70 262 To: MESSAGE Exploder 263 From: Carol ;tag=32331 264 Call-ID: d432fa84b4c76e66710 265 CSeq: 1 MESSAGE 266 Content-Type: multipart/mixed;boundary="boundary1" 267 Content-Length: xxx 269 --boundary1 270 Content-Type: text/plain 271 Content-Length: 13 273 Hello World! 275 --boundary1 276 Content-Type: application/resource-lists+xml 277 Content-Length: 315 278 Content-ID: 280 281 282 283 284 285 286 287 288 289 --boundary1-- 291 Figure 4: Multiple recipient incoming MESSAGE request 293 The following is an example of one of the outgoing MESSAGE requests 294 that the MESSAGE exploder creates. 296 MESSAGE sip:bill@example.com SIP/2.0 297 Via: SIP/2.0/TCP exploder.example.com 298 ;branch=z9hG4bKhjhs8as34sc 299 Max-Forwards: 70 300 To: 301 From: Carol ;tag=210342 302 Call-ID: 39s02sdsl20d9sj2l 303 CSeq: 1 MESSAGE 304 Content-Type: text/plain 305 Content-Length: 13 307 Hello World! 309 Figure 5: Outgoing MESSAGE request 311 6. Security Considerations 313 If MESSAGE exploders are not implemented properly, they could become 314 a SPAM amplification tool. The SPAMMER would have the exploder, 315 which will generally have a higher access bandwidth and more 316 processing power, send a SPAM message to a large set of destinations. 317 This section provides guidelines to prevent SPAM amplifications in 318 particular, and DoS attacks in general. In addition, we describe how 319 to provide content confidentiality and integrity. 321 MESSAGE exploders MUST authenticate and authorize any user agent 322 sending a multiple recipient MESSAGE. Additionally, MESSAGE 323 exploders MAY have policies that limit the number of URIs in the 324 list, as a very long list could be used in a DoS attack to place a 325 large burden on the exploder to send a large number of MESSAGEs or to 326 perform an amplification attack. 328 In case an exploder is used to send unsolicited instant messages 329 (i.e., SPAM), it should be possible to track down the sender of such 330 messages. To do that, MESSAGE exploders MAY provide information 331 about the identity of the original sender of the MESSAGE in their 332 outgoing MESSAGE requests. Exploders can use Authenticated Identity 333 Bodies (AIB) [7] or P-Asserted-Identity header fields [8] to provide 334 this information. Furthermore, it is RECOMMENDED that MESSAGE 335 exploders keep a log of all the transactions they handle (for a 336 reasonable period of time), so that SPAMMERS can be tracked down. 338 It is RECOMMENDED that user agents using MESSAGE exploders integrity 339 protect the contents of their instant messages and the list of 340 recipients using S/MIME. If the contents of the instant message or 341 the list of recipients needs to be kept private, the user agent 342 SHOULD also use S/MIME to prevent a third party from viewing this 343 information. 345 7. Acknowledgements 347 Duncan Mills supported the idea of having 1 to n MESSAGEs. Ben 348 Campbell and Paul Kyzivat provided helpful comments. 350 8. Change control 352 8.1 Changes from draft-garcia-simple-message-exploder-00.txt to 353 draft-garcia-sipping-message-exploder-00.txt 355 The MESSAGE exploder may or may not copy the URI list body to the 356 outgoing MESSAGE request. This allows to extend the mechanism with a 357 Reply-to-all feature. 359 It is clarified that the MESSAGE exploder must not include a list in 360 the outgoing MESSAGE requests. This avoids loops or requires a 361 MESSAGE exploder functionality in the next hop. 363 The MESSAGE exploder must remove the multipart/mixed wrapper if there 364 is only one body left in the outgoing MESSAGE request. 366 Filename changed due to focus on the SIPPING WG. 368 9. References 370 9.1 Normative References 372 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 373 Levels", BCP 14, RFC 2119, March 1997. 375 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 376 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 377 Session Initiation Protocol", RFC 3261, June 2002. 379 [3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. 380 Gurle, "Session Initiation Protocol (SIP) Extension for Instant 381 Messaging", RFC 3428, December 2002. 383 [4] Camarillo, G., "Providing a Session Initiation Protocol (SIP) 384 Application Server with a List of URIs", 385 draft-camarillo-sipping-uri-list-00 (work in progress), November 386 2003. 388 [5] Rosenberg, J., "An Extensible Markup Language (XML) 389 Configuration Access Protocol (XCAP) Usage for Presence Lists", 390 draft-ietf-simple-xcap-list-usage-01 (work in progress), October 391 2003. 393 9.2 Informational References 395 [6] Rosenberg, J., "Advanced Instant Messaging Requirements for the 396 Session Initiation Protocol (SIP)", 397 draft-rosenberg-simple-messaging-requirements-00 (work in 398 progress), December 2002. 400 [7] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", 401 draft-ietf-sip-authid-body-02 (work in progress), July 2003. 403 [8] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to 404 the Session Initiation Protocol (SIP) for Asserted Identity 405 within Trusted Networks", RFC 3325, November 2002. 407 Authors' Addresses 409 Miguel A. Garcia-Martin 410 Nokia 411 P.O.Box 407 412 NOKIA GROUP, FIN 00045 413 Finland 415 EMail: miguel.an.garcia@nokia.com 417 Gonzalo Camarillo 418 Ericsson 419 Hirsalantie 11 420 Jorvas 02420 421 Finland 423 EMail: Gonzalo.Camarillo@ericsson.com 425 Intellectual Property Statement 427 The IETF takes no position regarding the validity or scope of any 428 Intellectual Property Rights or other rights that might be claimed to 429 pertain to the implementation or use of the technology described in 430 this document or the extent to which any license under such rights 431 might or might not be available; nor does it represent that it has 432 made any independent effort to identify any such rights. Information 433 on the procedures with respect to rights in RFC documents can be 434 found in BCP 78 and BCP 79. 436 Copies of IPR disclosures made to the IETF Secretariat and any 437 assurances of licenses to be made available, or the result of an 438 attempt made to obtain a general license or permission for the use of 439 such proprietary rights by implementers or users of this 440 specification can be obtained from the IETF on-line IPR repository at 441 http://www.ietf.org/ipr. 443 The IETF invites any interested party to bring to its attention any 444 copyrights, patents or patent applications, or other proprietary 445 rights that may cover technology that may be required to implement 446 this standard. Please address the information to the IETF at 447 ietf-ipr@ietf.org. 449 Disclaimer of Validity 451 This document and the information contained herein are provided on an 452 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 453 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 454 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 455 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 456 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 457 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 459 Copyright Statement 461 Copyright (C) The Internet Society (2004). This document is subject 462 to the rights, licenses and restrictions contained in BCP 78, and 463 except as set forth therein, the authors retain all their rights. 465 Acknowledgment 467 Funding for the RFC Editor function is currently provided by the 468 Internet Society.