idnits 2.17.00 (12 Aug 2021) /tmp/idnits48183/draft-sun-sipping-multiple-reply-01.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 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 482. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 493. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 506. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 12, 2007) is 5334 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: draft-ietf-sipping-uri-services has been published as RFC 5363 ** Obsolete normative reference: RFC 4346 (ref. '5') (Obsoleted by RFC 5246) -- Duplicate reference: RFC4346, mentioned in '6', was also mentioned in '5'. ** Obsolete normative reference: RFC 4346 (ref. '6') (Obsoleted by RFC 5246) == Outdated reference: draft-ietf-sipping-capacity-attribute has been published as RFC 5364 == Outdated reference: draft-ietf-sip-uri-list-message has been published as RFC 5365 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Sun 3 Internet-Draft L. Tian 4 Expires: April 14, 2008 D. Ren 5 Huawei Technologies 6 October 12, 2007 8 Multiple Reply to MESSAGE requests in the Session Initiation Protocol 9 (SIP) 10 draft-sun-sipping-multiple-reply-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 14, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document defines a multiple target address extension to the 44 Reply-To header field for the SIP MESSAGE method. The extension 45 includes the use of a pointer to a Uniform Resource Identifier (URI)- 46 list in the Reply-To header field. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 3. URI-List Document Format . . . . . . . . . . . . . . . . . . . 6 53 4. Procedures at the Reply-Issuer . . . . . . . . . . . . . . . . 8 54 5. Procedures at the Reply-Recipient . . . . . . . . . . . . . . 9 55 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 56 6.1. Reply-Recipient uses MESSAGE URI-List service to send 57 reply MESSAGE requests . . . . . . . . . . . . . . . . . . 10 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 60 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 62 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 63 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 65 Intellectual Property and Copyright Statements . . . . . . . . . . 18 67 1. Introduction 69 RFC 3261 [2] defines a Reply-To header field containing a logical 70 return URI that may be different from the From header field. For 71 example, the URI MAY be used to return missed calls or unestablished 72 sessions. 74 RFC 3428 [3] further defines the Reply-To as an optional header field 75 that can be used and present in MESSAGE requests and responses. This 76 allows a Reply-Issuer to provide the Reply-Recipient with one User 77 Agent (UA) as the target of a reply MESSAGE request. 79 However, in some scenarios, the Reply-Issuer may want the Reply- 80 Recipient to send reply MESSAGE requests to a list of UAs, as opposed 81 to just one UA. For example, a manager sends a message to request a 82 secretary to prepare meeting arrangements. In the message, the 83 manager provides a list of meeting attendees. When the secretary 84 schedules the meeting, the secretary sends the meeting information in 85 a reply MESSAGE to the list of attendees. Another use case may be 86 for an application to send a notification to a user to respond with 87 certain information, such as a project report, to a list of users. 88 As with the previous example, the original message itself is not 89 meaningful for the intended recipients. 91 At present, there is no mechanism to convey a list of users to which 92 a UAC can respond. This specification extends the Reply-To mechanism 93 to fulfill the requirement by defining the use of a URI-List in the 94 Reply-to header. With this specification, the Reply-Issuer sends to 95 a Reply-Recipient a MESSAGE request with a Reply-To header pointing 96 to a Uniform Resource List (URI-list) containing the targets of a 97 reply MESSAGE request. Another possible solution is to define a new 98 SIP header field e.g. "Addtional-Reply-To" which is able to carry 99 mutiple reply targets. This seems much simpler, but can not indicate 100 more elaborate intention e.g. "bcc". 102 The Reply-Recipient can create a reply MESSAGE request for each entry 103 in the URI-List and send them respectively, or can send a reply 104 MESSAGE to a MESSAGE URI-list service [9] to distribute the reply 105 MESSAGE requests. The Reply-Recipient may modify the provided list 106 to add or remove recipients. 108 The requirements to support Multiple Reply to MESSAGE requests may be 109 summarized as follows: 111 REQ-1: It MUST be possible for a Reply-Issuer to specify multiple 112 reply targets in a MESSAGE request, where the identities of the 113 reply targets are carried in the request itself. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [1]. 121 This document defines the following new terms: 123 Reply-Issuer: the user agent issuing the SIP request with Reply-To 124 header field. 126 Reply-Recipient: the user agent receiving the SIP request with 127 Reply-To header field. 129 3. URI-List Document Format 131 As described in the Framework and Security Considerations for SIP 132 URI-List Services [4] , specifications of individual URI-list 133 services, need to specify a default format for 'recipient-list' 134 bodies used within the particular service. 136 The default format for 'recipient-list' bodies for multiple reply is 137 XML Resource Lists [7] extended with Copy Control Attribute [8] . 138 Reply-Issuer and Reply-Recipient MUST support both these formats and 139 MAY support other formats. 141 As described in Copy Control Attribute [8] , each URI can be tagged 142 with a 'copyControl' attribute set to either "to", "cc", or "bcc", 143 indicating the role in which the recipient will receive the reply 144 MESSAGE request. Additionally, URIs can be tagged with the 145 'anonymize' attribute to prevent that the Reply-Recipient (UAS) from 146 disclosing the target URI in a URI-list. 148 In addition, the XML Resource Lists [7] defines a 'recipient-list- 149 history' body that contains the list of recipients. The default 150 format for 'recipient-list-history' bodies for UAs is also the XML 151 Resource Lists [7] extended with the Copy Control Attribute [8] . If 152 the Reply-Recipient sends reply MESSAGE requests to each entry in the 153 URI-List, it may provide a 'recipient-list-history' body in the reply 154 MESSAGE requests. In this case the Reply-Recipient MAY support these 155 formats and MAY support others. If the Reply-Recipient sends a reply 156 MESSAGE request to a MESSAGE URI-list service [9] , it does not need 157 to support these formats. UAs able to understand 'recipient-list- 158 history' MUST support these formats and MAY support others. 160 The XML Resource Lists [7] provides features, such as hierarchical 161 lists and the ability to include entries by reference relative to the 162 XCAP root URI or by external reference; however, these are not needed 163 by the reply mechanism defined in this specification. The reply 164 mechanism defined herein only needs to transfer a flat list of URIs 165 between the Reply-Issuer and the Reply-Recipient. Therefore, when 166 using the default resource list document, UAs SHOULD use flat lists 167 (i.e., no hierarchical lists) and SHOULD NOT use references. A 168 Reply-Recipient receiving a URI-list with more information than what 169 has just been described MAY discard the additional information. 171 Figure 1 shows an example of a flat URI-List that follows XML 172 Resource Lists [7] extended with Copy Control Attribute [8] ). 174 175 177 178 179 180 181 182 184 Figure 1: Example for XML Resource List Document 186 4. Procedures at the Reply-Issuer 188 A Reply-Issuer that wants to specify multiple reply addresses MUST 189 use formatting according to Section 4 of RFC 3428 [3] . The Reply- 190 Issuer populates the Request-URI of the MESSAGE request with the SIP 191 or SIPS URI of the Reply-Recipient. In addition to the regular 192 MESSAGE request body, the Reply-Issuer adds a recipient-list body 193 whose Content-Disposition type is 'recipient-list' as defined in 194 Framework and Security Considerations for SIP URI-List Services [4] . 195 This body contains a URI-list with the recipients of the reply 196 MESSAGE request from the Reply-Recipient. Target URIs in this body 197 MAY also be tagged with the 'copyControl' and 'anonymize' attributes 198 specified in the Copy Control Attribute [8] . The Reply-Issuer MUST 199 provide an appropriate Content-ID for the recipient-list body and 200 populates the Reply-To with the value of Content-ID that identifies 201 the list of intended recipient of the reply MESSAGE requests. 203 The Reply-Issuer MAY use the "?" mechanism described in Section 204 19.1.1 of RFC 3261 [2] to encode extra information in any URI of the 205 list. The following is an example of a URI that uses the "?" 206 mechanism: 207 sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22 209 The previous URI requests the Reply-Recipient to add the following 210 header field to a reply MESSAGE request to be sent to 211 bob@example.com: Accept-Contact: *;mobility="mobile" 213 5. Procedures at the Reply-Recipient 215 A Reply-Recipient that receives a MESSAGE request with a Reply-To 216 header field and 'recipient-list' body processes it and responds 217 following the procedure in section 7 of RFC 3428 [3] 219 There are two possibilities for a Reply-Recipient to send reply 220 MESSAGE requests to intended recipients: 222 o The Reply-Recipient creates a reply MESSAGE request for each entry 223 in the URI-List and sends them respectively. If it supports the 224 'recipient-list-history' Content-Disposition type, it MAY provide 225 a 'recipient-list-history' body in the reply MESSAGE requests for 226 each intended recipient following the procedure defined in Copy 227 Control Attribute [8] . 229 o The Reply-Recipient sends a reply MESSAGE request that includes 230 the payload along with the URI-list to a MESSAGE URI-list service 231 [9] to distribute simliar reply MESSAGE requests to each of the 232 URIs included in the list. The Reply-Recipient MAY modify the 233 URI-list from the Reply-Issuer so as to add or remove recipients. 235 6. Examples 237 6.1. Reply-Recipient uses MESSAGE URI-List service to send reply 238 MESSAGE requests 240 Figure 1 shows an example flow where a Reply-Issuer sends a MESSAGE 241 request with Reply-To header field pointing to a URI list to a Reply- 242 Recipient. The Reply-Recipient sends a reply MESSAGE with the URI 243 list to MESSAGE URI-list service. 245 +--------+ +--------+ +---------+ +--------+ +--------+ 246 | Reply- | | Reply- | | MESSAGE | | reply | | reply | 247 | Issuer | | Recip. | | URI-List| | target | | target | 248 | | | | | server | | 1 | | 2 | 249 +--------+ +--------+ +---------+ +--------+ +--------+ 250 | | | | | 251 | F1:MESSAGE with Reply-To pointing to a URI-List | 252 |------------>| | | | 253 | F2:200 OK | | | | 254 |<------------| | | | 255 | | F3:MESSAGE | | | 256 | |-------------->| | | 257 | | F4:202 Accepted | | 258 | |<--------------| | | 259 | | | F5:MESSAGE | | 260 | | | --------------->| | 261 | | | F6:MESSAGE | | 262 | | | -------------------------->| 263 | | | F8:200 OK | | 264 | | |<--------------- | | 265 | | | F9:200 OK | | 266 | | |<-------------------------- | 267 | | | | | 269 Figure 1: Example flow for Reply-To pointing to multiple addresses 271 Figure 2 shows an example of the MESSAGE request F1, which carries a 272 'multipart/mixed' body composed of two other bodies: 274 o 'text/plain' body: contains the instant message payload; 276 o 'application/resource-lists+xml' body: contains the intended 277 recipients receiving the reply MESSAGE request from Reply- 278 Recipient. 280 The Reply-To header field has the same value of Content-ID pointing 281 to the URI-List which contains the intended recipients. 283 MESSAGE sip:tom@example.com SIP/2.0 284 Via: SIP/2.0/TCP uac1.example.com 285 ;branch=z9hG4bKhjhs8as34sc 286 Max-Forwards: 70 287 To: 288 From: Alice ;tag=210342 289 Call-ID: 39s02sdsl20d9sj2l 290 CSeq: 1 MESSAGE 291 Reply-To: 292 Content-Type: multipart/mixed;boundary="boundary1" 293 Content-Length: xxx 295 --boundary1 296 Content-Type: text/plain 298 Please reply the team with the deadline! 300 --boundary1 301 Content-Type: application/resource-lists+xml 302 Content-Disposition: recipient-list 303 Content-ID: 305 306 308 309 310 312 314 315 317 318 319 320 321 --boundary1-- 323 Figure 2: MESSAGE with Reply-To header field pointing to a URI list 325 Figure 3 shows an example of the MESSAGE request F3, which carries a 326 'multipart/mixed' body composed of two other bodies: 328 o 'text/plain' body: contains the instant message payload; 329 o 'application/resource-lists+xml' body: contains the list of 330 recipients. This list is the same with F1. 332 MESSAGE sip:list-service.example.com SIP/2.0 333 Via: SIP/2.0/TCP uac1.example.com 334 ;branch=z9hG4bKhjhs8as34sc 335 Max-Forwards: 70 336 To: MESSAGE URI-list Service 337 From: Alice ;tag=32331 338 Call-ID: d432fa84b4c76e66710 339 CSeq: 1 MESSAGE 340 Content-Type: multipart/mixed;boundary="boundary1" 341 Content-Length: xxx 343 --boundary1 344 Content-Type: text/plain 346 The deadline is 14:00 GMT October 10, 2007. 348 --boundary1 349 Content-Type: application/resource-lists+xml 350 Content-Disposition: recipient-list 352 353 355 356 357 359 361 362 364 365 366 367 368 --boundary1-- 370 Figure 3: MESSAGE request received at the MESSAGE URI-list server 372 7. Security Considerations 374 URI-lists may contain private information, such as SIP URIs. It is, 375 therefore, not desirable that these URI-lists are known by third 376 parties. Eavesdroppers are able to watch URI-lists contained in SIP 377 MESSAGE requests unless the MESSAGE requests are sent over a secured 378 channel, by using any of the available SIP mechanisms, such as 379 Transport Layer Security (TLS) [5] , or unless the URI-list body 380 itself is encrypted with, e.g., S/MIME [6] . Therefore, it is 381 RECOMMENDED that URI-list bodies are encrypted with S/MIME [6] or 382 that the SIP request is encrypted with TLS [5] or any other suitable 383 encryption mechanism. 385 8. IANA Considerations 387 There are no IANA considerations. 389 9. Acknowledgements 391 The authors would like to thank Tom Hiller, Henning Schulzrinne, 392 Jonathan Rosenberg and Spencer Dawkins for their valuable comments 393 and contributions. 395 10. References 397 10.1. Normative References 399 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 400 Levels", RFC 2119, March 1997. 402 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 403 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 404 Session Initiation Protocol", RFC 3261, June 2002. 406 [3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 407 D. Gurle, "Session Initiation Protocol (SIP) Extension for 408 Instant Messaging", RFC 3428, December 2002. 410 [4] Camarillo, G. and A. Roach, "Framework and Security 411 Considerations for Session Initiation Protocol (SIP) Uniform 412 Resource Identifier (URI)-List Services", 413 draft-ietf-sipping-uri-services-06.txt (work in progress), 414 September 2006. 416 [5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 417 Protocol Version 1.1", RFC 4346, April 2006. 419 [6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 420 (S/MIME) Version 3.1 Message Specification", RFC 4346, January 421 1999. 423 [7] Rosenberg, J., "Extensible Markup Language (XML) Formats for 424 Representing Resource Lists", RFC 4826, May 2007. 426 [8] Garcia-Martin, M. and G. Camarillo, "Extensible Markup Language 427 (XML) Format Extension for Representing Copy Control Attributes 428 in Resource Lists", 429 draft-ietf-sipping-capacity-attribute-04.txt (work in 430 progress), March 2007. 432 10.2. Informative References 434 [9] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE 435 Requests in the Session Initiation Protocol (SIP)", 436 draft-ietf-sip-uri-list-message-01.txt (work in progress), 437 January 2007. 439 Authors' Addresses 441 Qian Sun 442 Huawei Technologies 443 Bantian Longgang 444 Shenzhen, Guandong 518129 445 P.R China 447 Phone: +86 755 28780808 448 Email: sunqian@huawei.com 450 Linyi Tian 451 Huawei Technologies 452 Bantian Longgang 453 Shenzhen, Guandong 518129 454 P.R China 456 Phone: +86 755 28780808 457 Email: tianlinyi@huawei.com 459 Daqi Ren 460 Huawei Technologies 461 Bantian Longgang 462 Shenzhen, Guandong 518129 463 P.R China 465 Phone: +86 755 28780808 466 Email: dren@huawei.com 468 Full Copyright Statement 470 Copyright (C) The IETF Trust (2007). 472 This document is subject to the rights, licenses and restrictions 473 contained in BCP 78, and except as set forth therein, the authors 474 retain all their rights. 476 This document and the information contained herein are provided on an 477 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 478 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 479 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 480 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 481 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 482 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 484 Intellectual Property 486 The IETF takes no position regarding the validity or scope of any 487 Intellectual Property Rights or other rights that might be claimed to 488 pertain to the implementation or use of the technology described in 489 this document or the extent to which any license under such rights 490 might or might not be available; nor does it represent that it has 491 made any independent effort to identify any such rights. Information 492 on the procedures with respect to rights in RFC documents can be 493 found in BCP 78 and BCP 79. 495 Copies of IPR disclosures made to the IETF Secretariat and any 496 assurances of licenses to be made available, or the result of an 497 attempt made to obtain a general license or permission for the use of 498 such proprietary rights by implementers or users of this 499 specification can be obtained from the IETF on-line IPR repository at 500 http://www.ietf.org/ipr. 502 The IETF invites any interested party to bring to its attention any 503 copyrights, patents or patent applications, or other proprietary 504 rights that may cover technology that may be required to implement 505 this standard. Please address the information to the IETF at 506 ietf-ipr@ietf.org. 508 Acknowledgment 510 Funding for the RFC Editor function is provided by the IETF 511 Administrative Support Activity (IASA).