idnits 2.17.1 draft-ietf-sipping-uri-list-message-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 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 37. ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 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 == 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 (July 7, 2004) is 7230 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: '9' is defined on line 400, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 403, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-camarillo-sipping-uri-list-01 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-05) exists of draft-ietf-simple-xcap-list-usage-02 == Outdated reference: A later version (-09) exists of draft-ietf-smime-rfc2633bis-07 == Outdated reference: A later version (-03) exists of draft-camarillo-sipping-exploders-02 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-03) exists of draft-ietf-sip-authid-body-02 Summary: 9 errors (**), 0 flaws (~~), 10 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: January 5, 2005 G. Camarillo 4 Ericsson 5 July 7, 2004 7 Multiple-Recipient MESSAGE Requests in the Session Initiation 8 Protocol (SIP) 9 draft-ietf-sipping-uri-list-message-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 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 January 5, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document specifies how to request a SIP URI-list service to send 42 a copy of a MESSAGE to a set of destinations. The client sends a SIP 43 MESSAGE request with a URI-list to the URI-list service, which sends 44 a similar MESSAGE request to each of the URIs included in the list. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Procedures at the UAC . . . . . . . . . . . . . . . . . . . . 4 51 4. Procedures at the MESSAGE URI-List Service . . . . . . . . . . 5 52 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 54 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 55 8. Change control . . . . . . . . . . . . . . . . . . . . . . . . 8 56 8.1 Changes from draft--sipping-message-exploder-00.txt to 57 draft-ietf-sipping-uri-list-message-00.txt . . . . . . . . 8 58 8.2 Changes from 59 draft-garcia-simple-message-exploder-00.txt to 60 draft-garcia-sipping-message-exploder-00.txt . . . . . . . 9 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 63 9.2 Informational References . . . . . . . . . . . . . . . . . . 10 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 65 Intellectual Property and Copyright Statements . . . . . . . . 11 67 1. Introduction 69 SIP [2] can carry instant messages in MESSAGE [3] requests. The 70 Advanced Instant Messaging Requirements for SIP [8] mentions the need 71 for sending a MESSAGE request to multiple receipients: 73 "REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc 74 group, where the identities of the recipients are carried in the 75 message itself." 77 To meet this requirement, we allow SIP MESSAGE requests carry 78 URI-lists in "uri-list" body parts, as specified in [4]. A SIP 79 URI-list service, which is a specialized application server, receives 80 the request and sends a similar MESSAGE request to each of the URIs 81 in the list. Each of these MESSAGE requests contains a copy of the 82 body included in the original MESSAGE request. 84 The UAC (User Agent Client) needs to be configured with the SIP URI 85 of the application server that provides the functionality. 86 Discovering and provisioning of this URI to the UAC is outside the 87 scope of this document. 89 2. Terminology 91 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 92 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 93 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 94 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 95 compliant implementations. 97 'MESSAGE URI-list service': SIP application server that receives a 98 MESSAGE request with a URI-list and sends a similar MESSAGE request 99 to each URI in the list. MESSAGE URI-list services behave effectively 100 as specialised B2BUAs (Back-To-Back-User-Agents). A MESSAGE URI-list 101 service can also offer URI-list services for other methods, although 102 this functionality is outside the scope of this document. In this 103 document we only discuss MESSAGE URI-list services. 105 'Incoming MESSAGE request': A SIP MESSAGE request that a UAC creates 106 and addresses to a MESSAGE URI-list service. Besides the regular 107 instant message payload, an incoming MESSAGE request contains a 108 URI-list. 110 'Outgoing MESSAGE request': A SIP MESSAGE request that a MESSAGE 111 URI-list service creates and addresses to a UAS (User Agent Server). 112 It contains the regular instant message payload. 114 3. Procedures at the UAC 116 A client that wants to create a multiple-recipient MESSAGE request 117 adds a body part, whose disposition type is "uri-list", which 118 contains a URI-list with the recipients of the MESSAGE. 120 Multiple-recipient MESSAGE requests typically contain a multipart 121 body that contains the body carrying the list and the actual instant 122 message payload. In some cases, the MESSAGE request may contain 123 bodies other than the text and the list bodies (e.g., when the 124 request is protected with S/MIME [6]). 126 Typically, the MESSAGE URI-list service will copy all the significant 127 header fields in the outgoing MESSAGE request. However, there might 128 be cases where the SIP UA wants the MESSAGE URI-list service to add a 129 particular header field with a particular value, even if the header 130 field wasn't present in the MESSAGE request sent by the UAC. In this 131 case, the UAC MAY use the "?" mechanism described in Section 19.1.1 132 of RFC 3261 [2] to encode extra information in any URI in the list. 133 However, the UAC MUST NOT use the special "body" hname (see Section 134 19.1.1 of RFC 3261 [2]) to encode a body, since the body is present 135 in the MESSAGE request itself. 137 The following is an example of a URI that uses the "?" mechanism: 139 sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22 141 The previous URI requests the MESSAGE URI-list service to add the 142 following header field to a MESSAGE request to be sent to 143 bob@example.com: 145 Accept-Contact: *;mobility="mobile" 147 As described in [4], the default format for URI-lists in SIP is the 148 XCAP resource list format [5]. Still, specific services need to 149 describe which information clients should include in their URI lists, 150 as described in [4] 152 UAs generating multiple recipient MESSAGEs SHOULD use flat lists 153 (i.e., no hierarchical lists), SHOULD NOT use any entry's attributes 154 but "uri", and SHOULD NOT include any elements inside entries but 155 "display-name" elements. 157 A MESSAGE URI-list service receiving a URI-list with more information 158 than what we have just described SHOULD discard all the extra 159 information. 161 4. Procedures at the MESSAGE URI-List Service 163 On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list 164 service SHOULD answer to the UAC with a 202 Accepted response. Note 165 that the status code in the response to the MESSAGE does not provide 166 any information about whether or not the MESSAGEs generated by the 167 URI-list service were successfully delivered to the URIs in the list. 168 That is, a 202 Accepted means that the MESSAGE URI-list service has 169 received the MESSAGE and that it will try to send a similar MESSAGE 170 to the URIs in the list. Designing a mechanism to inform a client 171 about the delivery status of an instant message is outside the scope 172 of this document. 174 On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list 175 service SHOULD create as many new MESSAGE requests as URIs the list 176 contains, except when two of those URIs are equivalent (section 177 19.1.4 of RFC 3261 [2] defines equivalent URIs), in which case the 178 MESSAGE URI-list service SHOULD create only one outgoing MESSAGE 179 request per URI. 181 When creating the body of each of the outgoing MESSAGE requests, the 182 MESSAGE URI-list service tries to keep the relevant bodies of the 183 incoming MESSAGE request and copies them to the outgoing MESSAGE 184 request. The following guidelines are provided: 186 o The incoming MESSAGE request typically contains a URI-list body 187 [4] with the actual list of recipients. The MESSAGE URI-list 188 service need not copy the URI-list body to each of the outgoing 189 MESSAGE requests, although it MAY do it. 190 NOTE: This document does not provide any semantics associated to a 191 URI-list body included in an outgoing MESSAGE request. Future 192 extensions may indicate actions at a UAS when it receives that 193 body. 194 o A MESSAGE request received at a MESSAGE URI-list service can 195 contain one or more security bodies encrypted with the public key 196 of the MESSAGE URI-list service. These bodies are deemed to be 197 read by the URI-list service rather than the recipient of the 198 outgoing MESSAGE request (which will not be able to decrypt them). 199 Therefore, a MESSAGE URI-list service MUST NOT copy any security 200 body (such as an S/MIME encrypted body) addressed to the MESSAGE 201 URI-list service to the outgoing MESSAGE request. This includes 202 bodies encrypted with the public key of the URI-list service. 203 o An exception to this rule is the URI-list itself: as mentioned in 204 Section 4, a MESSAGE URI-list service need not, but MAY, copy the 205 URI-list into each of the outgoing MESSAGE requests; on doing so, 206 a MESSAGE URI-list service SHOULD use S/MIME [6] to encrypt the 207 URI-list with the public key of the receiver. 209 o The MESSAGE URI-list service SHOULD copy all the rest of the 210 message bodies (e.g., text messages, images, etc.) to the outgoing 211 MESSAGE request. 212 o If there is only one body left, the MESSAGE URI-list service MUST 213 remove the multipart/mixed wrapper in the outgoing MESSAGE 214 request. 216 The rest of the MESSAGE request corresponding to a given URI in the 217 list MUST be created following the rules in Section 19.1.5 "Forming 218 Requests from a URI" of RFC 3261 [2]. In particular, Section 19.1.5 219 of RFC 3261 [2] states: 221 "An implementation SHOULD treat the presence of any headers or body 222 parts in the URI as a desire to include them in the message, and 223 choose to honor the request on a per-component basis." 225 SIP allows to append a "method" parameter to a URI. Therefore, it is 226 legitimate that an the "uri" attribute of the "entry" element in the 227 XCAP resource list contains a "method" parameter. MESSAGE URI-list 228 services MUST generate only MESSAGE requests, regardless of the 229 "method" parameter that the URIs in the list indicate. Effectively, 230 MESSAGE URI-list services MUST ignore the "method" parameter in each 231 of the URIs present in the URI list. 233 It is RECOMMENDED that the MESSAGE URI-list service copies the From 234 header field of the incoming MESSAGE into the outgoing MESSAGE 235 requests (note that this does not apply to the "tag" parameter). The 236 MESSAGE URI-list service SHOULD also copy into the outgoing MESSAGE 237 request any P-Asserted-Identity header fields present in the incoming 238 MESSAGE request. 240 For each given outgoing MESSAGE request, the MESSAGE URI-list service 241 SHOULD generate a new To header field value which, according to the 242 procedures of RFC 3261 Section 8.1.1.1, should be equal to the 243 Request-URI of the outgoing MESSAGE request. 245 For each given outgoing MESSAGE request, the MESSAGE URI-list service 246 SHOULD initialize the values of the Call-ID, CSeq and Max-Forwards 247 header fields. The MESSAGE URI-list service should also include its 248 own value in the Via header field. 250 5. Examples 252 The following is an example of an incoming MESSAGE request which 253 carries a URI list in its body. 255 MESSAGE sip:list-service.example.com SIP/2.0 256 Via: SIP/2.0/TCP uac.example.com 257 ;branch=z9hG4bKhjhs8ass83 258 Max-Forwards: 70 259 To: MESSAGE URI-List Service 260 From: Carol ;tag=32331 261 Call-ID: d432fa84b4c76e66710 262 CSeq: 1 MESSAGE 263 Content-Type: multipart/mixed;boundary="boundary1" 264 Content-Length: 440 266 --boundary1 267 Content-Type: text/plain 269 Hello World! 271 --boundary1 272 Content-Type: application/resource-lists+xml 273 Content-Disposition: uri-list 275 276 277 278 279 280 281 282 283 --boundary1-- 285 Figure 3: Multiple recipient incoming MESSAGE request 287 The following is an example of one of the outgoing MESSAGE requests 288 that the MESSAGE URI-list service creates. 290 MESSAGE sip:bill@example.com SIP/2.0 291 Via: SIP/2.0/TCP list-service.example.com 292 ;branch=z9hG4bKhjhs8as34sc 293 Max-Forwards: 70 294 To: 295 From: Carol ;tag=210342 296 Call-ID: 39s02sdsl20d9sj2l 297 CSeq: 1 MESSAGE 298 Content-Type: text/plain 299 Content-Length: 13 301 Hello World! 303 Figure 4: Outgoing MESSAGE request 305 6. Security Considerations 307 The Security Considerations Section of the Requirements and Framework 308 for SIP URI-List Services [7] discusses issues related to SIP 309 URI-list services. Implementations of MESSAGE URI-list services MUST 310 follow the security-related rules in [7]. These rules include 311 mandatory authentication and authorization of clients, and opt-in 312 lists. 314 If the contents of the instant message needs to be kept private, the 315 user agent client SHOULD use S/MIME [6] to prevent a third party from 316 viewing this information. In this case, the user agent client SHOULD 317 encrypt the instant message body with a content encryption key. Then, 318 for each receiver in the list, the UAC SHOULD encrypt the content 319 encryption key with the public key of the receiver, and attach it to 320 the MESSAGE request. 322 7. Acknowledgements 324 Duncan Mills supported the idea of having 1 to n MESSAGEs. Ben 325 Campbell, Paul Kyzivat, and Cullen Jennings provided helpful 326 comments. 328 8. Change control 330 8.1 Changes from draft--sipping-message-exploder-00.txt to 331 draft-ietf-sipping-uri-list-message-00.txt 333 Clarified that the MESSAGE exploder should not distribute a body that 334 has been encrypted with the public key of the exploder. The exception 335 is the URI list, which can be distributed by the exploder, providing 336 that is encrypted with the public key of the receiver. 338 The security considerations section describes how to encrypt the list 339 and how to encrypt the instant message payload. 341 Terminology aligned with the requirements and the framework for 342 URI-list services (e.g., the term "exploder" has been deprecated). 344 8.2 Changes from draft-garcia-simple-message-exploder-00.txt to 345 draft-garcia-sipping-message-exploder-00.txt 347 The MESSAGE exploder may or may not copy the URI list body to the 348 outgoing MESSAGE request. This allows to extend the mechanism with a 349 Reply-to-all feature. 351 It is clarified that the MESSAGE exploder must not include a list in 352 the outgoing MESSAGE requests. This avoids loops or requires a 353 MESSAGE exploder functionality in the next hop. 355 The MESSAGE exploder must remove the multipart/mixed wrapper if there 356 is only one body left in the outgoing MESSAGE request. 358 Filename changed due to focus on the SIPPING WG. 360 9. References 362 9.1 Normative References 364 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 365 Levels", BCP 14, RFC 2119, March 1997. 367 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 368 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 369 Session Initiation Protocol", RFC 3261, June 2002. 371 [3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. 372 Gurle, "Session Initiation Protocol (SIP) Extension for Instant 373 Messaging", RFC 3428, December 2002. 375 [4] Camarillo, G., "Providing a Session Initiation Protocol (SIP) 376 Application Server with a List of URIs", 377 draft-camarillo-sipping-uri-list-01 (work in progress), February 378 2004. 380 [5] Rosenberg, J., "An Extensible Markup Language (XML) 381 Configuration Access Protocol (XCAP) Usage for Presence Lists", 382 draft-ietf-simple-xcap-list-usage-02 (work in progress), 383 February 2004. 385 [6] Ramsdell, B., "S/MIME Version 3.1 Message Specification", 386 draft-ietf-smime-rfc2633bis-07 (work in progress), February 387 2004. 389 [7] Camarillo, G., "Requirements for Session Initiation Protocol 390 (SIP) Exploder Invocation", draft-camarillo-sipping-exploders-02 391 (work in progress), February 2004. 393 9.2 Informational References 395 [8] Rosenberg, J., "Advanced Instant Messaging Requirements for the 396 Session Initiation Protocol (SIP)", 397 draft-rosenberg-simple-messaging-requirements-01 (work in 398 progress), February 2004. 400 [9] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", 401 draft-ietf-sip-authid-body-02 (work in progress), July 2003. 403 [10] Jennings, C., Peterson, J. and M. Watson, "Private Extensions 404 to 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 IETF's procedures with respect to rights in IETF Documents can 434 be 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.