idnits 2.17.1 draft-ietf-sip-uri-list-message-03.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 823. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 834. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 841. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 847. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 (December 21, 2007) is 5965 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) == Missing Reference: 'RFCXXXX' is mentioned on line 708, but not defined ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Downref: Normative reference to an Informational RFC: RFC 3325 ** Obsolete normative reference: RFC 3851 (Obsoleted by RFC 5751) == Outdated reference: A later version (-07) exists of draft-ietf-sipping-capacity-attribute-05 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group M. Garcia-Martin 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track G. Camarillo 5 Expires: June 23, 2008 Ericsson 6 December 21, 2007 8 Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol 9 (SIP) 10 draft-ietf-sip-uri-list-message-03.txt 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 June 23, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document specifies a mechanism that allows a SIP User Agent 44 Client (UAC) to send a SIP MESSAGE request to a set of destinations, 45 by using a SIP URI-list (Uniform Resource Identifier list) service. 46 The UAC sends a SIP MESSAGE request that includes the payload along 47 with the URI list to the MESSAGE URI-list service, which sends a 48 MESSAGE request including the payload to each of the URIs included in 49 the list. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. URI-List document . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Option-tag . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 6. Procedures at the User Agent Client . . . . . . . . . . . . . 7 59 7. Procedures at the MESSAGE URI-List Service . . . . . . . . . . 8 60 7.1. Determining the intended recipient . . . . . . . . . . . . 9 61 7.2. Creating an outgoing MESSAGE request . . . . . . . . . . . 9 62 7.3. Composing bodies in the outgoing MESSAGE request . . . . . 11 63 8. Procedures at the UAS . . . . . . . . . . . . . . . . . . . . 12 64 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 66 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 67 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 68 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 70 13.2. Informative References . . . . . . . . . . . . . . . . . . 18 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 72 Intellectual Property and Copyright Statements . . . . . . . . . . 19 74 1. Introduction 76 RFC 3261 (SIP) [RFC3261] is extended by "SIP Extension for Instant 77 Messaging" [RFC3428] to carry instant messages in MESSAGE requests. 78 SIP-based messaging, as described in RFC 3428 [RFC3428], does not 79 provide a mechanism to send the same request to multiple recipients 80 or replying to all recipients of a SIP MESSAGE request. This memo 81 addresses these functions. 83 A first requirement can be expressed as: 85 REQ-1: It must be possible for a user to send an instant message 86 request to an ad-hoc group, where the identities of the recipients 87 are carried in the message itself. 89 One possibility to fulfill the above requirement is to establish a 90 session of instant messages with an instant messaging conference 91 server, and exchange the messages, for example, using the "Message 92 Session Relay Protocol (MSRP)" [RFC4975]. While this option seems to 93 be reasonable in many cases, in other situations the sending user 94 just wants to send a small pager-mode instant message to an ad-hoc 95 group without the burden of setting up a session. This document 96 focuses on sending a pager-mode instant message to a number of 97 intended recipients. 99 To meet the requirement with a pager-mode instant message, we allow 100 SIP MESSAGE requests carry recipient-list bodies, i.e., URI lists in 101 body parts whose Content-Disposition (RFC 2183) [RFC2183] is 102 'recipient-list', as specified in the Framework and Security 103 Considerations for SIP URI-List Services 104 [I-D.ietf-sipping-uri-services]. A SIP MESSAGE URI-list service, 105 which is a specialized application service, receives the request and 106 sends a MESSAGE request including the received payload to each of the 107 URIs in the list. Each of these MESSAGE requests contains a copy of 108 the body included in the original MESSAGE request. 110 A second requirement addresses the "Reply-To-All" functionality: 112 REQ-2: It MUST be possible for the recipient of a group instant 113 message to send a message to all other participants that received 114 the same group instant message (i.e., Reply-To-All). 116 To meet this requirement, we provide a mechanism whereby the MESSAGE 117 URI-list service also includes a URI list in body parts whose 118 Content-Disposition (RFC 2183) [RFC2183] is 'recipient-list-history', 119 as specified in the "Extended Markup Language (XML) Format Extension 120 for Representing Copy Control Attributes in Resource Lists" 121 [I-D.ietf-sipping-capacity-attribute]. The 'recipient-list-history' 122 body is sent along with the instant message payload in each of the 123 instant messages sent to the recipients. 125 The User Agent Client (UAC) that sends a MESSAGE request to a MESSAGE 126 URI-list service needs to be configured with the SIP URI of the 127 service that provides the functionality. Discovering and 128 provisioning of this URI to the UAC is outside the scope of this 129 document. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in BCP 14, RFC 2119 136 [RFC2119] and indicate requirement levels for compliant 137 implementations. 139 This document reuses the following terminology defined in RFC 3261 140 [RFC3261]: 142 o Address-of-Record (AOR) 143 o User Agent (UA) 144 o User Agent Client (UAC) 145 o User Agent Server (UAS) 147 This document defines the following new terms: 149 MESSAGE URI-list service: A specialized URI-list service that 150 receives a MESSAGE request with a URI list and sends a similar 151 MESSAGE request to each URI in the list. In this context, similar 152 indicates that some SIP header fields can change, but the MESSAGE 153 URI-list service will not change the instant message payload. 154 MESSAGE URI-list services behave effectively as specialised B2BUAs 155 (Back-To-Back-User-Agents). A server providing MESSAGE URI-list 156 services can also offer URI-list services for other methods, 157 although this functionality is outside the scope of this document. 158 In this document we only discuss MESSAGE URI-list services. 160 Incoming MESSAGE request: A SIP MESSAGE request that a UAC creates 161 and addresses to a MESSAGE URI-list service. Besides the regular 162 instant message payload, an incoming MESSAGE request contains a 163 URI list. 165 Outgoing MESSAGE request: A SIP MESSAGE request that a MESSAGE URI- 166 list service creates and addresses to a UAS (User Agent Server). 167 It contains the regular instant message payload. 169 Intended recipient: The intended final recipient of the request to 170 be generated by MESSAGE URI-list service. 172 Reply-To-All: The ability of an intended recipient to receive a 173 MESSAGE request that includes the payload and the list of 174 recipients, and compose a send a MESSAGE request to the sender and 175 the rest of the recipients. The replying entity can use a MESSAGE 176 URI-list service if one is at its disposal or can create a 177 sequence of regular single-recipient MESSAGE requests to each SIP 178 AOR. 180 3. Overview 182 A UAC creates a MESSAGE request that contains a multipart body 183 including a list of URIs (intended recipients) and an instant 184 message. The list of URIs is formatted according to the resource 185 list document format specified in RFC 4826 [RFC4826] and extended 186 with the attributes defined in the "XML Format Extension for 187 Representing Copy Control Attributes in Resource Lists" 188 [I-D.ietf-sipping-capacity-attribute]. The UAC sends this MESSAGE 189 request to the MESSAGE URI-list service. On reception of this 190 incoming MESSAGE request, the MESSAGE URI-list service creates a 191 MESSAGE request per intended recipient (listed in the URI list) and 192 copies the instant message payload to each of those MESSAGES. The 193 MESSAGE URI-list service also manipulates the XML resource list 194 according to the procedures indicated in the "XML Format Extension 195 for Representing Copy Control Attributes in Resource Lists" 196 [I-D.ietf-sipping-capacity-attribute], and attaches the result to 197 each of the MESSAGE requests, along with the instant message payload. 198 Then the MESSAGE URI-list service sends each of the created outgoing 199 MESSAGE request to the respective receiver. 201 The MESSAGE URI-list mechanism allows a sender to specify multiple 202 targets for a MESSAGE request by including an XML resource list 203 document according to RFC 4826 [RFC4826] in the body of the MESSAGE 204 request extended with the attributes defined in the "XML Format 205 Extension for Representing Copy Control Attributes in Resource Lists" 206 [I-D.ietf-sipping-capacity-attribute]. This resource list, whose 207 Content-Disposition (RFC 2183) [RFC2183] is 'recipient-list', as 208 specified in the "Framework and Security Considerations for SIP URI- 209 List Services" [I-D.ietf-sipping-uri-services], includes the URIs of 210 the targets. Each target URI may also be marked to indicate in what 211 role the URI-list service will place the target (e.g., "to", "cc", or 212 "bcc"), and whether the target URI is expected to be anonymized or 213 not, according to the procedures described in the "XML Format 214 Extension for Representing Copy Control Attributes in Resource Lists" 215 [I-D.ietf-sipping-capacity-attribute]. When the MESSAGE URI-list 216 server expands the MESSAGE request to each recipient, it includes 217 (along with the instant message payload) a new URI list (based on the 218 received one), whose Content-Disposition (RFC 2183) [RFC2183] is 219 'recipient-list-history', as specified in the "XML Format Extension 220 for Representing Copy Control Attributes in Resource Lists" 221 [I-D.ietf-sipping-capacity-attribute]. This new URI list includes 222 the list of non-anonymous "to" and "cc" targets, allowing recipients 223 to both get knowledge of other recipients and reply to them. 225 4. URI-List document 227 As described in the "Framework and Security Considerations for SIP 228 URI-List Services" [I-D.ietf-sipping-uri-services], specifications of 229 individual URI-list services, like the MESSAGE URI-list service 230 described here, need to specify a default format for 'recipient-list' 231 bodies used within the particular service. 233 The default format for 'recipient-list' bodies for MESSAGE URI-list 234 services is the resource list document specified in RFC 4826 235 [RFC4826] extended with the "XML Format Extension for Representing 236 Copy Control Attributes in Resource Lists" 237 [I-D.ietf-sipping-capacity-attribute]. UACs and MESSAGE URI-list 238 services handling 'recipient-list' bodies MUST support both of these 239 formats and MAY support other formats. 241 As described in the "XML Format Extension for Representing Copy 242 Control Attributes in Resource Lists" 243 [I-D.ietf-sipping-capacity-attribute], each URI can be tagged with a 244 'copyControl' attribute set to either "to", "cc", or "bcc", 245 indicating the role in which the recipient will get the MESSAGE 246 request. Additionally, URIs can be tagged with the 'anonymize' 247 attribute to prevent that the MESSAGE URI-list server discloses the 248 target URI in a URI list. 250 Additionally, the "XML Format Extension for Representing Copy Control 251 Attributes in Resource Lists" [I-D.ietf-sipping-capacity-attribute] 252 defines a 'recipient-list-history' body that contains the list of 253 intended recipients. The default format for 'recipient-list-history' 254 bodies for MESSAGE URI-list services is also the resource list 255 document specified in RFC 4826 [RFC4826] extended with the "XML 256 Format Extension for Representing Copy Control Attributes in Resource 257 Lists" [I-D.ietf-sipping-capacity-attribute]. MESSAGE URI-list 258 services MUST support both of these formats; UASes MAY support these 259 formats. MESSAGE URI-list servers and UASes MAY support other 260 formats. 262 The resource list document specified in RFC 4826 [RFC4826] provides a 263 number of features that are not needed by the MESSAGE URI-list 264 service defined in this document. The MESSAGE URI-list service needs 265 to transfer a simple flat list of URIs between a UAC and the MESSAGE 266 URI-list server and between the MESSAGE URI-list server and the UAS. 267 The service does not need hierarchical lists or the ability to 268 include entries by reference relative to the Extensible Configuration 269 Access Protocol (XCAP) [RFC4825] root URI. Therefore, the MESSAGE 270 URI-list service specified herein only uses flat resource lists 271 documents that do not contain relative references. 273 5. Option-tag 275 This document defines the 'recipient-list-message' option-tag for use 276 in the Require and Supported SIP header fields. 278 This option-tag is used to ensure that a server can process the 279 'recipient-list' body used in a MESSAGE request. It also provides 280 a mechanism to discover the capability of the server in responses 281 to OPTIONS requests. 283 Section 6 provides normative procedures for the usage of this option 284 tag. 286 6. Procedures at the User Agent Client 288 A UAC that wants to create a multiple-recipient MESSAGE request 289 creates a MESSAGE request that MUST be formatted according to RFC 290 3428 [RFC3428] Section 4. The UAC populates the Request-URI with the 291 SIP or SIPS URI of the MESSAGE URI-list service. In addition to the 292 regular instant message body, the UAC adds a recipient-list body 293 whose Content-Disposition type is 'recipient-list', specified in the 294 "Framework and Security Considerations for SIP URI-List Services" 295 [I-D.ietf-sipping-uri-services]. This body contains a URI list with 296 the recipients of the MESSAGE. Target URIs in this body MAY also be 297 tagged with the 'copyControl' and 'anonymize' attributes specified in 298 the "XML Format Extension for Representing Copy Control Attributes in 299 Resource Lists" [I-D.ietf-sipping-capacity-attribute]. The UAC MUST 300 also include the 'recipient-list-message' option-tag, defined in 301 Section 5, in a Require header field. 303 UACs generating MESSAGE request that carry recipient-list bodies, as 304 described in previous sections, MUST include this option-tag in a 305 Require header field. UAs that are able to receive and process 306 MESSAGEs with a recipient-list body, as described in previous 307 sections, SHOULD include this option-tag in a Supported header field 308 when responding to OPTIONS requests. 310 Multiple-recipient MESSAGE requests contain a multipart body that 311 contains the body carrying the list and the actual instant message 312 payload. In some cases, the MESSAGE request can contain bodies other 313 than the text and the list bodies (e.g., when the request is 314 protected with S/MIME as per RFC 3851 [RFC3851]). 316 Typically, the MESSAGE URI-list service will copy all the significant 317 header fields in the outgoing MESSAGE request. However, there might 318 be cases where the SIP UA wants the MESSAGE URI-list service to add a 319 particular header field with a particular value, even if the header 320 field wasn't present in the MESSAGE request sent by the UAC. In this 321 case, the UAC MAY use the "?" mechanism described in Section 19.1.1 322 of RFC 3261 [RFC3261] to encode extra information in any URI in the 323 list. However, the UAC MUST NOT use the special "body" hname (see 324 Section 19.1.1 of RFC 3261 [RFC3261]) to encode a body, since the 325 body is present in the MESSAGE request itself. 327 The following is an example of a URI that uses the "?" mechanism: 329 sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22 331 The previous URI requests the MESSAGE URI-list service to add the 332 following header field to a MESSAGE request to be sent to 333 bob@example.com: 335 Accept-Contact: *;mobility="mobile" 337 The resource list document format specified in RFC 4826 [RFC4826] 338 provides features, such as hierarchical lists and the ability to 339 include entries by reference relative to the XCAP root URI. However, 340 these features are not needed by the multiple MESSAGE URI-list 341 service defined in this document. Therefore, when using the default 342 resource list document, UAs SHOULD use flat lists (i.e., no 343 hierarchical lists) and SHOULD NOT use elements. 345 7. Procedures at the MESSAGE URI-List Service 347 On reception of a MESSAGE request containing a URI list, the MESSAGE 348 URI-list service answers to the UAC with a 202 (Accepted) response. 350 Note that the status code in the response to the MESSAGE does not 351 provide any information about whether or not the MESSAGEs 352 generated by the URI-list service were successfully delivered to 353 the URIs in the list. That is, a 202 (Accepted) response means 354 that the MESSAGE URI-list service has received the MESSAGE and 355 that it will try to send a similar MESSAGE to the URIs in the 356 list. Designing a mechanism to inform a client about the delivery 357 status of an instant message is outside the scope of this 358 document. 360 Since the MESSAGE URI-list service does not use hierarchical lists 361 nor lists that include entries by reference to the XCAP root URI, a 362 MESSAGE URI-list server receiving a URI list with more information 363 than what has just been described MAY discard all the extra 364 information. 366 If a MESSAGE request contains a Request-URI containing a URI that 367 uses the "?" mechanism (see Section 19.1.1 of RFC 3261 [RFC3261]) and 368 such URI contains the special "body" hname to include an additional 369 body, the MESSAGE URI-list server MAY discard the contents of the 370 "body" parameter. 372 7.1. Determining the intended recipient 374 On reception of a MESSAGE request containing a URI list, a MESSAGE 375 URI-list service determines the list of intended recipients by 376 inspecting the URI list contained in the body. 378 Section 4.1 of the "Framework and Security Considerations for SIP 379 URI-List Services" [I-D.ietf-sipping-uri-services] discusses cases 380 when duplicated URIs are found in a URI list. In order to avoid 381 duplicated requests, MESSAGE URI-list services MUST take those 382 actions specified in "Framework and Security Considerations for SIP 383 URI-List Services" [I-D.ietf-sipping-uri-services] into account to 384 avoid sending duplicated request to the same recipient. 386 7.2. Creating an outgoing MESSAGE request 388 Since the MESSAGE URI-list service behaves as a UAC for outgoing 389 MESSAGE requests, for each of the intended recipients, the MESSAGE 390 URI-list service creates a new MESSAGE request according to the 391 procedures described in Section 4 of RFC 3428 [RFC3428]. 392 Additionally, Section 5.3 of the "Framework and Security 393 Considerations for SIP URI-List Services" 394 [I-D.ietf-sipping-uri-services] provides additional general guidance 395 in creating outgoing requests. This document also specifies the 396 following procedures: 398 o A MESSAGE URI-list service MUST include a From header field whose 399 value is the same as the From header field included in the 400 incoming MESSAGE request, subject to the privacy requirements (see 401 RFC 3323 [RFC3323] and RFC 3325 [RFC3325]) expressed in the 402 incoming MESSAGE request. 404 Note that this does not apply to the "tag" parameter. 406 Failing to copy the From header field of the sender would 407 prevent the recipient to get a hint of the sender's identity. 408 Note also that this requirement does not intend to contradict 409 requirements for additional services running on the same 410 physical node. Specifically, a privacy service (see RFC 3323 411 [RFC3323]) can be co-located with the MESSAGE URI-list service, 412 in which case, the privacy service has precedence over the 413 MESSAGE URI-list service. 415 o A MESSAGE URI-list service SHOULD generate a new To header field 416 value set to the intended recipient's URI. According to the 417 procedures of RFC 3261 [RFC3261] Section 8.1.1.1, this value is 418 also expected to be equal to the Request-URI of the outgoing 419 MESSAGE request. 421 The MESSAGE URI-list service behaves as a User Agent Client, 422 thus, the To header field should be populated with the 423 recipient's URI. 425 o A MESSAGE URI-list service SHOULD create a new Call-ID header 426 field value. 428 A Call-ID header field might contain addressing information 429 that the sender wants to remain private. Since there is no 430 need to keep the same Call-ID on both sides of the MESSAGE URI- 431 list service, and since the MESSAGE URI-list service behaves as 432 a User Agent Client, it is recommended to create a new Call-ID 433 header field value according to the regular SIP procedures. 435 o If a P-Asserted-Identity header field was present in the incoming 436 MESSAGE request and the request was received from a trusted 437 source, as specified in RFC 3325 [RFC3325], and the first hop of 438 the outgoing MESSAGE request is also trusted, a MESSAGE URI-list 439 service MUST include a P-Asserted-Identity header field in the 440 outgoing MESSAGE request with the same received value. However, 441 if the first hop of the outgoing MESSAGE request is not trusted 442 and the incoming MESSAGE request included a Privacy header field 443 with a value different than 'none', the MESSAGE URI-list service 444 MUST NOT include a P-Asserted-Identity header field in the 445 outgoing MESSAGE request. 447 o If a MESSAGE URI-list service is able to assert the identity of a 448 user (e.g., using HTTP Digest authentication scheme as per RFC 449 2617 [RFC2617], S/MIME as per RFC 3851 [RFC3851], etc.) and the 450 service implements a mechanism where it can map that 451 authentication scheme to a user's SIP or SIPS URI, and subject to 452 the privacy requirements expressed in the incoming MESSAGE request 453 (see RFC 3323 [RFC3323], the MESSAGE URI-list service MAY insert a 454 P-Asserted-Identity header with the value of the user's asserted 455 URI. 456 o If the incoming MESSAGE request contains an Authorization or 457 Proxy-Authorization header fields whose realm is set to the 458 MESSAGE URI-list server's realm, then the MESSAGE URI-list service 459 SHOULD NOT copy it to the outgoing MESSAGE request; otherwise 460 (i.e., if the Authorization or Proxy-Authorization header field of 461 incoming MESSAGE request contains a different realm), the MESSAGE 462 URI-list service MUST copy the value to the respective header 463 field of the outgoing MESSAGE request. 464 o A MESSAGE URI-list service SHOULD create a separate count for the 465 CSeq header field of the outgoing MESSAGE request. 466 o A MESSAGE URI-list service SHOULD initialize the value of the Max- 467 Forward header field of the outgoing MESSAGE request. 468 o A MESSAGE URI-list service MUST include its own value in the Via 469 header field. 471 7.3. Composing bodies in the outgoing MESSAGE request 473 When creating the body of each of the outgoing MESSAGE requests, the 474 MESSAGE URI-list service keeps the relevant bodies of the incoming 475 MESSAGE request and copies them to the outgoing MESSAGE request. The 476 following guidelines constitute exceptions to the general body 477 handling: 479 o A MESSAGE request received at a MESSAGE URI-list service can 480 contain one or more security bodies (e.g., S/MIME, RFC 3851 481 [RFC3851]) encrypted with the public key of the MESSAGE URI-list 482 service. These bodies are deemed to be read by the URI-list 483 service rather than the recipient of the outgoing MESSAGE request 484 (which will not be able to decrypt them). Therefore, a MESSAGE 485 URI-list service MUST NOT copy any security body (such as an 486 S/MIME as per RFC 3851 [RFC3851] encrypted body) addressed to the 487 MESSAGE URI-list service to the outgoing MESSAGE request. This 488 includes bodies encrypted with the public key of the URI-list 489 service. 490 o The incoming MESSAGE request typically contains a recipient-list 491 body or reference, as indicated in the "Framework and Security 492 Considerations for SIP URI-List Services" 493 [I-D.ietf-sipping-uri-services] with the actual list of 494 recipients. If this URI list includes resources tagged with the 495 'copyControl' attribute set to a value of "to" or "cc", the URI- 496 list service SHOULD include a URI list in each of the outgoing 497 MESSAGE requests. This list SHOULD be formatted according to the 498 resource list document format specified in RFC 4826 [RFC4826] and 499 the copyControl extension specified in the "XML Format Extension 500 for Representing Copy Control Attributes in Resource Lists" 501 [I-D.ietf-sipping-capacity-attribute]. The MESSAGE URI-list 502 service MUST follow the procedures specified in "XML Format for 503 Representing Resource Lists" [I-D.ietf-sipping-capacity-attribute] 504 with respect handling of the 'anonymize', 'count' and 505 'copyControl' attributes. 506 o If the MESSAGE URI-list service includes a URI list in an outgoing 507 MESSAGE request, it MUST include a Content-Disposition header 508 field as per RFC 2183 [RFC2183] with the value set to 'recipient- 509 list-history' and a 'handling' parameter as per RFC 3204 [RFC3204] 510 set to "optional". 511 o If a MESSAGE URI-list service includes a URI list in an outgoing 512 MESSAGE request, it SHOULD use S/MIME (RFC 3851) [RFC3851] to 513 encrypt the URI list with the public key of the receiver. 514 o The MESSAGE URI-list service SHOULD copy all the remaining message 515 bodies (e.g., text messages, images, etc.) of the incoming MESSAGE 516 request to the outgoing MESSAGE request. 517 o If there is only one body left, the MESSAGE URI-list service MUST 518 remove the multipart/mixed wrapper in the outgoing MESSAGE 519 request. 521 The rest of the MESSAGE request corresponding to a given URI in the 522 URI list MUST be created following the rules in Section 19.1.5 523 "Forming Requests from a URI" of RFC 3261 [RFC3261]. In particular, 524 Section 19.1.5 of RFC 3261 [RFC3261] states: 526 "An implementation SHOULD treat the presence of any headers or 527 body parts in the URI as a desire to include them in the message, 528 and choose to honor the request on a per-component basis." 530 SIP allows to append a "method" parameter to a URI. Therefore, it is 531 legitimate that an the 'uri' attribute of the element in the 532 XML resource list contains a 'method' parameter. MESSAGE URI-list 533 services MUST generate only MESSAGE requests, regardless of the 534 'method' parameter that the URIs in the list indicate. Effectively, 535 MESSAGE URI-list services MUST ignore the 'method' parameter in each 536 of the URIs present in the URI list. 538 8. Procedures at the UAS 540 A UAS (in this specification, also known as intended recipient UAS) 541 that receives a MESSAGE request from the MESSAGE URI-list service 542 behaves as specified in RFC 3428 [RFC3428] Section 7. 544 If the UAS supports this specification and the MESSAGE request 545 contains a body with a Content-Disposition header field as per RFC 546 2183 [RFC2183] set to 'recipient-list-history', then the UAS will be 547 able to determine the SIP Address-of-Record (AOR) of the other 548 intended recipients of the MESSAGE request. This allows the user to 549 create a reply request (e.g., MESSAGE, INVITE) to the sender and the 550 rest of the recipients included in the URI list. 552 9. Examples 554 Figure 1 shows an example of operation. A SIP UAC issuer sends a 555 MESSAGE request. The MESSAGE URI-list service answers with a 202 556 (Accepted) response and sends a MESSAGE request to each of the 557 intended recipients. 559 +--------+ +---------+ +--------+ +--------+ +--------+ 560 |SIP UAC | | MESSAGE | |intended| |intended| |intended| 561 | issuer | | URI-list| | recip. | | recip. | | recip. | 562 | | | service | | 1 | | 2 | | n | 563 +--------+ +---------+ +--------+ +--------+ +--------+ 564 | | | | | 565 | F1. MESSAGE | | | | 566 | ---------------->| | | | 567 | F2. 202 Accepted | | | | 568 |<---------------- | F3. MESSAGE | | | 569 | | ------------->| | | 570 | | F4. MESSAGE | | | 571 | | ------------------------>| | 572 | | F5. MESSAGE | | | 573 | | ----------------------------------->| 574 | | F6. 200 OK | | | 575 | |<------------- | | | 576 | | F7. 200 OK | | | 577 | |<------------------------ | | 578 | | F8. 200 OK | | | 579 | |<----------------------------------- | 580 | | | | | 581 | | | | | 582 | | | | | 584 Figure 1: Example of operation 586 The MESSAGE request F1 (shown in Figure 2) contains a multipart/mixed 587 body that is composed of two bodies: a text/plain body containing the 588 instant message payload and an application/resource-lists+xml body 589 containing the list of recipients. 591 MESSAGE sip:list-service.example.com SIP/2.0 592 Via: SIP/2.0/TCP uac.example.com 593 ;branch=z9hG4bKhjhs8ass83 594 Max-Forwards: 70 595 To: MESSAGE URI-list service 596 From: Alice ;tag=32331 597 Call-ID: d432fa84b4c76e66710 598 CSeq: 1 MESSAGE 599 Require: recipient-list-message 600 Content-Type: multipart/mixed;boundary="boundary1" 601 Content-Length: 501 603 --boundary1 604 Content-Type: text/plain 606 Hello World! 608 --boundary1 609 Content-Type: application/resource-lists+xml 610 Content-Disposition: recipient-list 612 613 615 616 617 619 621 622 624 625 626 627 628 --boundary1-- 630 Figure 2: MESSAGE request received at the MESSAGE URI-list server 632 The MESSAGE requests F3, F4 and F5 are similar in nature. All those 633 MESSAGE requests contain a multipart/mixed body which is composed of 634 two other bodies: a text/plain body containing the instant message 635 payload and an application/resource-lists+xml containing the list of 636 recipients. Unlike the text/plain body the application/ 637 resource-lists+xml body is not equal to the application/ 638 resource-lists+xml included in the incoming MESSAGE request F1, 639 because the URI-list service has anonymized those URIs tagged with 640 the 'anonymize' attribute and has removed those URIs tagged with a 641 "bcc" 'copyControl' attribute. Figure 3 shows an examples of the 642 message F3. 644 MESSAGE sip:bill@example.com SIP/2.0 645 Via: SIP/2.0/TCP list-service.example.com 646 ;branch=z9hG4bKhjhs8as34sc 647 Max-Forwards: 70 648 To: 649 From: Alice ;tag=210342 650 Call-ID: 39s02sdsl20d9sj2l 651 CSeq: 1 MESSAGE 652 Content-Type: multipart/mixed;boundary="boundary1" 653 Content-Length: 501 655 --boundary1 656 Content-Type: text/plain 658 Hello World! 660 --boundary1 661 Content-Type: application/resource-lists+xml 662 Content-Disposition: recipient-list-history; handling=optional 664 665 667 668 669 671 672 674 675 676 --boundary1-- 678 Figure 3: MESSAGE request sent by the MESSAGE URI-list server 680 10. Security Considerations 682 The "Framework and Security Considerations for SIP URI-List Services" 683 [I-D.ietf-sipping-uri-services] discusses issues related to SIP URI- 684 list services. Implementations of MESSAGE URI-list services MUST 685 follow the security-related rules in the "Framework and Security 686 Considerations for SIP URI-List Services" 687 [I-D.ietf-sipping-uri-services]. These rules include mandatory 688 authentication and authorization of clients, and opt-in lists. 690 If the contents of the instant message needs to be kept private, the 691 user agent client SHOULD use S/MIME as per RFC 3851 [RFC3851] to 692 prevent a third party from viewing this information. In this case, 693 the user agent client SHOULD encrypt the instant message body with a 694 content encryption key. Then, for each receiver in the list, the UAC 695 SHOULD encrypt the content encryption key with the public key of the 696 receiver, and attach it to the MESSAGE request. 698 11. IANA Considerations 700 This document defines the SIP option tag 'recipient-list-message' 702 The following row shall be added to the "Option Tags" section of the 703 SIP Parameter Registry: 705 +------------------------+------------------------------+-----------+ 706 | Name | Description | Reference | 707 +------------------------+------------------------------+-----------+ 708 | recipient-list-message | The body contains a list of | [RFCXXXX] | 709 | | URIs that indicates the | | 710 | | recipients of the SIP | | 711 | | MESSAGE request | | 712 +------------------------+------------------------------+-----------+ 714 Table 1: Registration of the 'recipient-list-message' Option-Tag in 715 SIP 717 Note to IANA and the RFC editor: replace RFCXXXX above with the RFC 718 number of this specification. 720 12. Acknowledgements 722 Duncan Mills supported the idea of having 1 to n MESSAGEs. Ben 723 Campbell, Paul Kyzivat, Cullen Jennings, Jonathan Rosenberg, Dean 724 Willis, and Keith Drage provided helpful comments. 726 13. References 727 13.1. Normative References 729 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 730 Requirement Levels", BCP 14, RFC 2119, March 1997. 732 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 733 Presentation Information in Internet Messages: The 734 Content-Disposition Header Field", RFC 2183, August 1997. 736 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 737 Leach, P., Luotonen, A., and L. Stewart, "HTTP 738 Authentication: Basic and Digest Access Authentication", 739 RFC 2617, June 1999. 741 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 742 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 743 and QSIG Objects", RFC 3204, December 2001. 745 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 746 A., Peterson, J., Sparks, R., Handley, M., and E. 747 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 748 June 2002. 750 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 751 Initiation Protocol (SIP)", RFC 3323, November 2002. 753 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 754 Extensions to the Session Initiation Protocol (SIP) for 755 Asserted Identity within Trusted Networks", RFC 3325, 756 November 2002. 758 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 759 and D. Gurle, "Session Initiation Protocol (SIP) Extension 760 for Instant Messaging", RFC 3428, December 2002. 762 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 763 Extensions (S/MIME) Version 3.1 Message Specification", 764 RFC 3851, July 2004. 766 [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats 767 for Representing Resource Lists", RFC 4826, May 2007. 769 [I-D.ietf-sipping-uri-services] 770 Camarillo, G. and A. Roach, "Framework and Security 771 Considerations for Session Initiation Protocol (SIP) 772 Uniform Resource Identifier (URI)-List Services", 773 draft-ietf-sipping-uri-services-07 (work in progress), 774 November 2007. 776 [I-D.ietf-sipping-capacity-attribute] 777 Garcia-Martin, M. and G. Camarillo, "Extensible Markup 778 Language (XML) Format Extension for Representing Copy 779 Control Attributes in Resource Lists", 780 draft-ietf-sipping-capacity-attribute-05 (work in 781 progress), November 2007. 783 13.2. Informative References 785 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 786 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 788 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 789 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 791 Authors' Addresses 793 Miguel A. Garcia-Martin 794 Nokia Siemens Networks 795 P.O.Box 6 796 Nokia Siemens Networks, FIN 02022 797 Finland 799 Email: miguel.garcia@nsn.com 801 Gonzalo Camarillo 802 Ericsson 803 Hirsalantie 11 804 Jorvas 02420 805 Finland 807 Email: Gonzalo.Camarillo@ericsson.com 809 Full Copyright Statement 811 Copyright (C) The IETF Trust (2007). 813 This document is subject to the rights, licenses and restrictions 814 contained in BCP 78, and except as set forth therein, the authors 815 retain all their rights. 817 This document and the information contained herein are provided on an 818 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 819 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 820 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 821 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 822 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 823 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 825 Intellectual Property 827 The IETF takes no position regarding the validity or scope of any 828 Intellectual Property Rights or other rights that might be claimed to 829 pertain to the implementation or use of the technology described in 830 this document or the extent to which any license under such rights 831 might or might not be available; nor does it represent that it has 832 made any independent effort to identify any such rights. Information 833 on the procedures with respect to rights in RFC documents can be 834 found in BCP 78 and BCP 79. 836 Copies of IPR disclosures made to the IETF Secretariat and any 837 assurances of licenses to be made available, or the result of an 838 attempt made to obtain a general license or permission for the use of 839 such proprietary rights by implementers or users of this 840 specification can be obtained from the IETF on-line IPR repository at 841 http://www.ietf.org/ipr. 843 The IETF invites any interested party to bring to its attention any 844 copyrights, patents or patent applications, or other proprietary 845 rights that may cover technology that may be required to implement 846 this standard. Please address the information to the IETF at 847 ietf-ipr@ietf.org. 849 Acknowledgment 851 Funding for the RFC Editor function is provided by the IETF 852 Administrative Support Activity (IASA).