idnits 2.17.1 draft-ietf-sipping-uri-list-message-07.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 on line 732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 743. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 756. ** 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. 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 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 2006) is 6637 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) -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 621 ** Obsolete normative reference: RFC 2617 (ref. '3') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Downref: Normative reference to an Informational RFC: RFC 3325 (ref. '7') ** Obsolete normative reference: RFC 3851 (ref. '10') (Obsoleted by RFC 5751) == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-04 == Outdated reference: A later version (-07) exists of draft-ietf-sipping-capacity-attribute-00 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group M. Garcia-Martin 3 Internet-Draft Nokia 4 Expires: August 26, 2006 G. Camarillo 5 Ericsson 6 February 22, 2006 8 Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol 9 (SIP) 10 draft-ietf-sipping-uri-list-message-07.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 August 26, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document specifies a mechanism that allows a SIP User Agent 44 Client (UAC) to request a SIP URI-list (Uniform Resource Identifier 45 list) service to send a SIP MESSAGE request to a set of destinations. 46 The client sends a SIP MESSAGE request that includes the payload 47 along with the URI-list to the MESSAGE URI-list service, which sends 48 a similar MESSAGE request to each of the URIs included in the list. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. URI-List document . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Option-tag . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 6. Procedures at the User Agent Client . . . . . . . . . . . . . 6 58 7. Procedures at the MESSAGE URI-List Service . . . . . . . . . . 7 59 7.1. Determining the intended recipient . . . . . . . . . . . . 8 60 7.2. Creating an outgoing MESSAGE request . . . . . . . . . . . 8 61 7.3. Composing bodies in the outgoing MESSAGE request . . . . . 9 62 8. Procedures at the UAS . . . . . . . . . . . . . . . . . . . . 11 63 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 65 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 66 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 67 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 69 13.2. Informational References . . . . . . . . . . . . . . . . . 16 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 71 Intellectual Property and Copyright Statements . . . . . . . . . . 16 73 1. Introduction 75 SIP [5] can carry instant messages in MESSAGE [8] requests. The 76 Advanced Instant Messaging Requirements for SIP [13] mentions the 77 need for sending a MESSAGE request to multiple recipients: 79 "REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc 80 group, where the identities of the recipients are carried in the 81 message itself." 83 One possibility to fulfill the above requirement is to establish a 84 session of instant messages with an instant messaging conference 85 server. While this option seems to be reasonable in many cases, in 86 other situations the sending user just wants to send a small page- 87 mode instant message to an ad-hoc group without the burden of setting 88 up a session. This document focuses on sending a page-mode instant 89 message to a number of intended recipients. 91 To meet the requirement with a page-mode instant message, we allow 92 SIP MESSAGE requests carry URI-lists in body parts whose Content- 93 Disposition [2] is 'recipient-list', as specified in the Framework 94 and Security Considerations for SIP URI-List Services [11]. A SIP 95 MESSAGE URI-list service, which is a specialized application service, 96 receives the request and sends a similar MESSAGE request to each of 97 the URIs in the list. Each of these MESSAGE requests contains a copy 98 of the body included in the original MESSAGE request. 100 The Advanced Instant Messaging Requirements for SIP [13] also 101 includes a requirement that allows to provide a "Reply-to-All" 102 functionality: 104 "REQ-GROUP-4: It MUST be possible for the recipient of a group IM 105 to send a message to all other participants that received the same 106 group IM (i.e., Reply-To-All)." 108 To meet this requirement, we provide a mechanism whereby the MESSAGE 109 URI-list service also includes a URI-list in body parts whose 110 Content-Disposition [2] is 'recipient-list-history', as specified in 111 the Extensible Markup Language (XML) Format Extension for 112 Representing Capacity Attributes in Resource Lists [12]. The 113 'recipient-list-history' body is sent along with the instant message 114 payload in each of the instant messages sent to the recipients. 116 The User Agent Client (UAC) that sends a MESSAGE request to a MESSAGE 117 URI-list service needs to be configured with the SIP URI of the 118 service that provides the functionality. Discovering and 119 provisioning of this URI to the UAC is outside the scope of this 120 document. 122 2. Terminology 124 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 125 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 126 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 127 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 128 compliant implementations. 130 MESSAGE URI-list service: SIP application service that receives a 131 MESSAGE request with a URI-list and sends a similar MESSAGE 132 request to each URI in the list. In this context, similar 133 indicates that some SIP header fields can change, but the MESSAGE 134 URI-list service will not change the instant message payload. 135 MESSAGE URI-list services behave effectively as specialised B2BUAs 136 (Back-To-Back-User-Agents). A server providing MESSAGE URI-list 137 services can also offer URI-list services for other methods, 138 although this functionality is outside the scope of this document. 139 In this document we only discuss MESSAGE URI-list services. 141 Incoming MESSAGE request: A SIP MESSAGE request that a UAC creates 142 and addresses to a MESSAGE URI-list service. Besides the regular 143 instant message payload, an incoming MESSAGE request contains a 144 URI-list. 146 Outgoing MESSAGE request: A SIP MESSAGE request that a MESSAGE URI- 147 list service creates and addresses to a UAS (User Agent Server). 148 It contains the regular instant message payload. 150 Intended recipient: The intended final recipient of the request to 151 be generated by MESSAGE URI-list service. 153 3. Overview 155 A UAC creates a MESSAGE request that contains a multipart body 156 including a list of URIs (intended recipients) and an instant 157 message. The list of URIs is formatted according to the XML resource 158 list [9] and extended with the attributes defined in [12]. The UAC 159 sends this MESSAGE request to the MESSAGE URI-list service. On 160 reception of this incoming MESSAGE request, the MESSAGE URI-list 161 service creates a MESSAGE request per intended recipient (listed in 162 the URI-list) and copies the instant message payload to each of those 163 MESSAGES. The MESSAGE URI-list service also manipulates the XML 164 resource list according to the procedures indicated in [12], and 165 attaches the result to each of the MESSAGE requests, along with the 166 instant message payload. Then the MESSAGE URI-list service sends 167 each of the created outgoing MESSAGE request to the respective 168 receiver. 170 The MESSAGE URI-list mechanism allows a sender to specify multiple 171 targets for a MESSAGE request by including an XML resource list [9] 172 in the body of the MESSAGE request extended with the attributes 173 defined in the XML Format Extension for Representing Capacity 174 Attributes in Resource Lists [12]. This resource list, whose 175 Content-Disposition [2] is 'recipient-list', as specified in the 176 Framework and Security Considerations for SIP URI-List Services [11], 177 includes the URIs of the targets. Each target URI may also be marked 178 to indicate in what capacity (or role) the URI-list service will 179 place the target (e.g., "to", "cc", or "bcc"), and whether the target 180 URI should be anonymized or not, according to the procedures 181 described in [12]. When the MESSAGE URI-list server expands the 182 MESSAGE request to each recipient, it includes (along with the 183 instant message payload) a new URI-list (based on the received one), 184 whose Content-Disposition [2] is 'recipient-list-history', as 185 specified in the XML Format Extension for Representing Capacity 186 Attributes in Resource Lists [12]. This new URI-list includes the 187 list of non-anonymous "to" and "cc" targets, allowing recipients to 188 both get knowledge of other recipients and reply to them. 190 4. URI-List document 192 As described in the Framework and Security Considerations for SIP 193 URI-List Services [11], specifications of individual URI-list 194 services, like the MESSAGE URI-list service described here, need to 195 specify a default format for 'recipient-list' bodies used within the 196 particular service. 198 The default format for 'recipient-list' bodies for MESSAGE URI-list 199 services is the XML resource list document format [9] extended with 200 the XML Format Extension for Representing Capacity Attributes in 201 Resource Lists [12]. UACs and MESSAGE URI-list services handling 202 'recipient-list' bodies MUST support both of these formats and MAY 203 support other formats. 205 As described in the XML Format Extension for Representing Capacity 206 Attributes in Resource Lists [12], each URI can be tagged with a 207 'capacity' attribute set to either "to", "cc", or "bcc", indicating 208 the capacity or role in which the recipient will get the MESSAGE 209 request. Additionally, URIs can be tagged with the 'anonymize' 210 attribute to prevent that the MESSAGE URI-list server discloses the 211 target URI in a URI-list. 213 Additionally, the XML Format Extension for Representing Capacity 214 Attributes in Resource Lists [12] defines a 'recipient-list-history' 215 body that contains the list of intended recipients. The default 216 format for 'recipient-list-history' bodies for MESSAGE URI-list 217 services is also the XML resource list document format [9] extended 218 with the XML Format Extension for Representing Capacity Attributes in 219 Resource Lists [12]. MESSAGE URI-list services MUST support both of 220 these formats; UASes MAY support these formats. MESSAGE URI-list 221 servers and UASes MAY support other formats. 223 Nevertheless, the XML resource list document [9] provides features, 224 such as hierarchical lists and the ability to include entries by 225 reference relative to the XCAP root URI, that are not needed by the 226 MESSAGE URI-list service defined in this document, which only needs 227 to transfer a flat list of URIs between a UA (User Agent) and the 228 MESSAGE URI-list server. Therefore, when using the default resource 229 list document, UAs SHOULD use flat lists (i.e., no hierarchical 230 lists) and SHOULD NOT use elements. 232 A MESSAGE URI-list service receiving a URI-list with more information 233 than what has just been described MAY discard all the extra 234 information. 236 5. Option-tag 238 This document defines the 'recipient-list-message' option-tag for use 239 in the Require and Supported SIP header fields. 241 This option-tag is used to ensure that a server can process the 242 'recipient-list' body used in a MESSAGE request. It also provides 243 a mechanism to discover the capability of the server in responses 244 to OPTIONS requests. 246 UACs generating MESSAGE request that carry recipient-list bodies, as 247 described in previous sections, MUST include this option-tag in a 248 Require header field. UAs that are able to receive and process 249 MESSAGEs with a recipient-list body, as described in previous 250 sections, SHOULD include this option-tag in a Supported header field 251 when responding to OPTIONS requests. 253 6. Procedures at the User Agent Client 255 A UAC that wants to create a multiple-recipient MESSAGE request 256 creates a MESSAGE request that MUST be formatted according to RFC 257 3428 [8] Section 4. The UAC populates the Request-URI with the SIP 258 or SIPS URI of the MESSAGE URI-list service. In addition to the 259 regular instant message body, the UAC adds a URI-list body whose 260 Content-Disposition type is 'recipient-list', specified in the 261 Framework and Security Considerations for SIP URI-list Services [11]. 262 This body contains a URI-list with the recipients of the MESSAGE. 263 Target URIs in this body MAY also be tagged with the 'capacity' and 264 'anonymize' attributes specified in the XML Format Extension for 265 Representing Capacity Attributes in Resource Lists [12]. The UAC 266 MUST also include the 'recipient-list-message' option-tag, defined in 267 Section 5, in a Require header field. 269 Multiple-recipient MESSAGE requests contain a multipart body that 270 contains the body carrying the list and the actual instant message 271 payload. In some cases, the MESSAGE request may contain bodies other 272 than the text and the list bodies (e.g., when the request is 273 protected with S/MIME [10]). 275 Typically, the MESSAGE URI-list service will copy all the significant 276 header fields in the outgoing MESSAGE request. However, there might 277 be cases where the SIP UA wants the MESSAGE URI-list service to add a 278 particular header field with a particular value, even if the header 279 field wasn't present in the MESSAGE request sent by the UAC. In this 280 case, the UAC MAY use the "?" mechanism described in Section 19.1.1 281 of RFC 3261 [5] to encode extra information in any URI in the list. 282 However, the UAC MUST NOT use the special "body" hname (see Section 283 19.1.1 of RFC 3261 [5]) to encode a body, since the body is present 284 in the MESSAGE request itself. 286 The following is an example of a URI that uses the "?" mechanism: 288 sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22 290 The previous URI requests the MESSAGE URI-list service to add the 291 following header field to a MESSAGE request to be sent to 292 bob@example.com: 294 Accept-Contact: *;mobility="mobile" 296 7. Procedures at the MESSAGE URI-List Service 298 On reception of a MESSAGE request with a URI-list, the MESSAGE URI- 299 list service answers to the UAC with a 202 (Accepted) response. Note 300 that the status code in the response to the MESSAGE does not provide 301 any information about whether or not the MESSAGEs generated by the 302 URI-list service were successfully delivered to the URIs in the list. 303 That is, a 202 (Accepted) response means that the MESSAGE URI-list 304 service has received the MESSAGE and that it will try to send a 305 similar MESSAGE to the URIs in the list. Designing a mechanism to 306 inform a client about the delivery status of an instant message is 307 outside the scope of this document. 309 7.1. Determining the intended recipient 311 On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list 312 service determines the list of intended recipients by inspecting the 313 URI-list contained in the body. In case two of those URIs are 314 equivalent (section 19.1.4 of RFC 3261 [5] defines equivalent URIs), 315 the MESSAGE URI-list SHOULD consider a single intended recipient 316 rather than sending multiple copies of the MESSAGE to the same 317 destination. 319 7.2. Creating an outgoing MESSAGE request 321 Since the MESSAGE URI-list behaves as a UAC for outgoing MESSAGE 322 requests, for each of the intended recipients, the MESSAGE URI-list 323 service creates a new MESSAGE request according to the procedures 324 described in Section 4 of RFC 3428 [8] and the following procedures: 326 o A MESSAGE URI-list service MUST include a From header field whose 327 value is the same as the From header field included in the 328 incoming MESSAGE request, subject to the privacy requirements (see 329 RFC 3323 [6] and RFC 3325 [7]) expressed in the incoming MESSAGE 330 request. Note that this does not apply to the "tag" parameter. 331 Failing to copy the From header field of the sender would 332 prevent the recipient to get a hint of the sender's identity. 333 Note also that this requirement does not intend to contradict 334 requirements for additional services running on the same 335 physical node. Specifically, a privacy service (see RFC 3323 336 [6]) can be co-located with the MESSAGE URI-list service, in 337 which case, the privacy service has precedence over the MESSAGE 338 URI-list service. 339 o A MESSAGE URI-list service SHOULD generate a new To header field 340 value set to the intended recipient's URI. According to the 341 procedures of RFC 3261 [5] Section 8.1.1.1, this value should also 342 be equal to the Request-URI of the outgoing MESSAGE request. 343 The MESSAGE URI-list service behaves as a User Agent Client, 344 thus, the To header field should be populated with the 345 recipient's URI. 346 o A MESSAGE URI-list service SHOULD create a new Call-ID header 347 field value. 348 A Call-ID header field might contain addressing information 349 that the sender wants to remain private. Since there is no 350 need to keep the same Call-ID on both sides of the MESSAGE URI- 351 list service, and since the MESSAGE URI-list service behaves as 352 a User Agent Client, it is recommended to create a new Call-ID 353 header field value according to the regular SIP procedures. 354 o If a P-Asserted-Identity header field was present in the incoming 355 MESSAGE request and the request was received from a trusted 356 source, as specified in RFC 3325 [7], and the first hop of the 357 outgoing MESSAGE request is also trusted, a MESSAGE URI-list 358 service MUST include a P-Asserted-Identity header field in the 359 outgoing MESSAGE request with the same received value. However, 360 if the first hop of the outgoing MESSAGE request is not trusted 361 and the incoming MESSAGE request included a Privacy header field 362 with a value different than 'none', the MESSAGE URI-list service 363 MUST NOT include a P-Asserted-Identity header field in the 364 outgoing MESSAGE request. 365 o If a MESSAGE URI-list service is able to assert the identity of a 366 user (e.g., using HTTP Digest authentication scheme [3], S/MIME 367 [10], etc.) and the service implements a mechanism where it can 368 map that authentication scheme to a user's SIP or SIPS URI, and 369 subject to the privacy requirements expressed in the incoming 370 MESSAGE request (see RFC 3323 [6], the MESSAGE URI-list MAY insert 371 a P-Asserted-Identity header with the value of the user's asserted 372 URI. 373 o If the incoming MESSAGE request contains an Authorization or 374 Proxy-Authorization header fields whose realm is set to the 375 MESSAGE URI-list server's realm, then the MESSAGE URI-list service 376 SHOULD NOT copy it to the outgoing MESSAGE request; otherwise 377 (i.e., if the Authorization or Proxy-Authorization header field of 378 incoming MESSAGE request contains a different realm), the MESSAGE 379 URI-list service MUST copy the value to the respective header 380 field of the outgoing MESSAGE request. 381 o A MESSAGE URI-list service SHOULD create a separate count for the 382 CSeq header field of the outgoing MESSAGE request. 383 o A MESSAGE URI-list service SHOULD initialize the value of the Max- 384 Forward header field of the outgoing MESSAGE request. 385 o A MESSAGE URI-list service MUST include its own value in the Via 386 header field. 387 o A MESSAGE URI-list service SHOULD include any other header field 388 expressed with the "?" mechanism described in Section 19.1.1 of 389 RFC 3261 [5] and encoded in the intended recipient URI of the URI- 390 list. 391 o A MESSAGE URI-list service SHOULD preserve to the outgoing MESSAGE 392 request any other header field not explicitly indicated in the 393 above paragraphs. 395 7.3. Composing bodies in the outgoing MESSAGE request 397 When creating the body of each of the outgoing MESSAGE requests, the 398 MESSAGE URI-list service tries to keep the relevant bodies of the 399 incoming MESSAGE request and copies them to the outgoing MESSAGE 400 request. The following guidelines are provided: 402 o A MESSAGE request received at a MESSAGE URI-list service can 403 contain one or more security bodies (e.g., S/MIME [10]) encrypted 404 with the public key of the MESSAGE URI-list service. These bodies 405 are deemed to be read by the URI-list service rather than the 406 recipient of the outgoing MESSAGE request (which will not be able 407 to decrypt them). Therefore, a MESSAGE URI-list service MUST NOT 408 copy any security body (such as an S/MIME [10] encrypted body) 409 addressed to the MESSAGE URI-list service to the outgoing MESSAGE 410 request. This includes bodies encrypted with the public key of 411 the URI-list service. 412 o The incoming MESSAGE request typically contains a URI-list body or 413 reference [11] with the actual list of recipients. If this URI- 414 list includes resources tagged with the 'capacity' attribute set 415 to a value of "to" or "cc", the URI-list service SHOULD include a 416 URI-list in each of the outgoing MESSAGE requests. This list 417 SHOULD be formatted according to the XML format for representing 418 resource lists [9] and the capacity extension specified in [12]. 419 The URI-list service MUST follow the procedures specified in XML 420 format for representing resource lists [12] with respect handling 421 of the 'anonymize', 'count' and 'capacity' attributes. 422 o If the MESSAGE URI-list service includes a URI-list in an outgoing 423 MESSAGE request, it MUST include a Content-Disposition header 424 field [2] with the value set to 'recipient-list-history' and a 425 'handling' parameter [4] set to "optional". 426 o If a MESSAGE URI-list service includes a URI-list in an outgoing 427 MESSAGE request, it SHOULD use S/MIME [10] to encrypt the URI-list 428 with the public key of the receiver. 429 o The MESSAGE URI-list service SHOULD copy all the remaining message 430 bodies (e.g., text messages, images, etc.) of the incoming MESSAGE 431 request to the outgoing MESSAGE request. 432 o If there is only one body left, the MESSAGE URI-list service MUST 433 remove the multipart/mixed wrapper in the outgoing MESSAGE 434 request. 436 The rest of the MESSAGE request corresponding to a given URI in the 437 URI-list MUST be created following the rules in Section 19.1.5 438 "Forming Requests from a URI" of RFC 3261 [5]. In particular, 439 Section 19.1.5 of RFC 3261 [5] states: 441 "An implementation SHOULD treat the presence of any headers or body 442 parts in the URI as a desire to include them in the message, and 443 choose to honor the request on a per-component basis." 445 SIP allows to append a "method" parameter to a URI. Therefore, it is 446 legitimate that an the 'uri' attribute of the element in the 447 XML resource list contains a 'method' parameter. MESSAGE URI-list 448 services MUST generate only MESSAGE requests, regardless of the 449 'method' parameter that the URIs in the list indicate. Effectively, 450 MESSAGE URI-list services MUST ignore the 'method' parameter in each 451 of the URIs present in the URI-list. 453 8. Procedures at the UAS 455 A UAS (in this specification, also known as intended recipient UAS) 456 that receives a MESSAGE request from the URI-list service behaves as 457 specified in RFC 3428 [8] Section 7. 459 If the UAS supports this specification and the MESSAGE request 460 contains a body with a Content-Disposition header field [2] set to 461 'recipient-list-history', then the UAS will be able to determine who 462 are the other intended recipients of the MESSAGE request. This 463 allows the user to create a reply request (e.g., MESSAGE, INVITE) to 464 the sender and the rest of the recipients included in the URI-list. 466 9. Examples 468 Figure 1 shows an example of operation. A SIP UAC issuer sends a 469 MESSAGE request. The MESSAGE URI-list service answers with a 202 470 (Accepted) response and sends a MESSAGE request to each of the 471 intended recipients. 473 +--------+ +---------+ +--------+ +--------+ +--------+ 474 |SIP UAC | | MESSAGE | |intended| |intended| |intended| 475 | issuer | | URI-list| | recip. | | recip. | | recip. | 476 | | | service | | 1 | | 2 | | n | 477 +--------+ +---------+ +--------+ +--------+ +--------+ 478 | | | | | 479 | F1. MESSAGE | | | | 480 | ---------------->| | | | 481 | F2. 202 Accepted | | | | 482 |<---------------- | F3. MESSAGE | | | 483 | | ------------->| | | 484 | | F4. MESSAGE | | | 485 | | ------------------------>| | 486 | | F5. MESSAGE | | | 487 | | ----------------------------------->| 488 | | F6. 200 OK | | | 489 | |<------------- | | | 490 | | F7. 200 OK | | | 491 | |<------------------------ | | 492 | | F8. 200 OK | | | 493 | |<----------------------------------- | 494 | | | | | 495 | | | | | 496 | | | | | 498 Figure 1: Example of operation 500 The MESSAGE request F1 (shown in Figure 2) contains a multipart/mixed 501 body that is composed of two bodies: a text/plain body containing the 502 instant message payload and an application/resource-lists+xml body 503 containing the list of recipients. 505 MESSAGE sip:list-service.example.com SIP/2.0 506 Via: SIP/2.0/TCP uac.example.com 507 ;branch=z9hG4bKhjhs8ass83 508 Max-Forwards: 70 509 To: MESSAGE URI-list Service 510 From: Alice ;tag=32331 511 Call-ID: d432fa84b4c76e66710 512 CSeq: 1 MESSAGE 513 Require: recipient-list-message 514 Content-Type: multipart/mixed;boundary="boundary1" 515 Content-Length: 501 517 --boundary1 518 Content-Type: text/plain 520 Hello World! 522 --boundary1 523 Content-Type: application/resource-lists+xml 524 Content-Disposition: recipient-list 526 527 529 530 531 533 535 536 538 539 540 541 542 --boundary1-- 544 Figure 2: MESSAGE request received at the MESSAGE URI-list server 546 The MESSAGE requests F3, F4 and F5 are similar in nature. All those 547 MESSAGE requests contain a multipart/mixed body which is composed of 548 two other bodies: a text/plain body containing the instant message 549 payload and an application/resource-lists+xml containing the list of 550 recipients. Unlike the text/plain body the application/ 551 resource-lists+xml body is not equal to the application/ 552 resource-lists+xml included in the incoming MESSAGE request F1, 553 because the URI-list service has anonymized those URIs tagged with 554 the 'anonymize' attribute and has removed those URIs tagged with a 555 "bcc" 'capacity' attribute. Figure 3 shows an examples of the 556 message F3. 558 MESSAGE sip:bill@example.com SIP/2.0 559 Via: SIP/2.0/TCP list-service.example.com 560 ;branch=z9hG4bKhjhs8as34sc 561 Max-Forwards: 70 562 To: 563 From: Alice ;tag=210342 564 Call-ID: 39s02sdsl20d9sj2l 565 CSeq: 1 MESSAGE 566 Content-Type: multipart/mixed;boundary="boundary1" 567 Content-Length: 501 569 --boundary1 570 Content-Type: text/plain 572 Hello World! 574 --boundary1 575 Content-Type: application/resource-lists+xml 576 Content-Disposition: recipient-list-history; handling=optional 578 579 581 582 583 585 586 588 589 590 --boundary1-- 592 Figure 3: MESSAGE request sent by the MESSAGE URI-list server 594 10. Security Considerations 596 The Framework and Security Considerations for SIP URI-List Services 597 [11] discusses issues related to SIP URI-list services. 598 Implementations of MESSAGE URI-list services MUST follow the 599 security-related rules in the Framework and Security Considerations 600 for SIP URI-List Services [11]. These rules include mandatory 601 authentication and authorization of clients, and opt-in lists. 603 If the contents of the instant message needs to be kept private, the 604 user agent client SHOULD use S/MIME [10] to prevent a third party 605 from viewing this information. In this case, the user agent client 606 SHOULD encrypt the instant message body with a content encryption 607 key. Then, for each receiver in the list, the UAC SHOULD encrypt the 608 content encryption key with the public key of the receiver, and 609 attach it to the MESSAGE request. 611 11. IANA Considerations 613 This document defines the 'recipient-list-message' SIP option-tag in 614 Section 5. IANA should register this option-tag in the Option Tags 615 subregistry under the IANA registry of SIP parameters, with the 616 following registration data: 618 +------------------------+------------------------------+-----------+ 619 | Name | Description | Reference | 620 +------------------------+------------------------------+-----------+ 621 | recipient-list-message | The body contains a list of | [RFCXXXX] | 622 | | URIs that indicates the | | 623 | | recipients of the SIP | | 624 | | MESSAGE request | | 625 +------------------------+------------------------------+-----------+ 627 Table 1: Registration of the 'recipient-list-message' Option-Tag in 628 SIP 630 Note to IANA and the RFC editor: replace RFCXXXX above with the RFC 631 number of this specification. 633 12. Acknowledgements 635 Duncan Mills supported the idea of having 1 to n MESSAGEs. Ben 636 Campbell, Paul Kyzivat, Cullen Jennings, Jonathan Rosenberg, and Dean 637 Willis provided helpful comments. 639 13. References 641 13.1. Normative References 643 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 644 Levels", BCP 14, RFC 2119, March 1997. 646 [2] Troost, R., Dorner, S., and K. Moore, "Communicating 647 Presentation Information in Internet Messages: The Content- 648 Disposition Header Field", RFC 2183, August 1997. 650 [3] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 651 Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: 652 Basic and Digest Access Authentication", RFC 2617, June 1999. 654 [4] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., 655 Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG 656 Objects", RFC 3204, December 2001. 658 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 659 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 660 Session Initiation Protocol", RFC 3261, June 2002. 662 [6] Peterson, J., "A Privacy Mechanism for the Session Initiation 663 Protocol (SIP)", RFC 3323, November 2002. 665 [7] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 666 to the Session Initiation Protocol (SIP) for Asserted Identity 667 within Trusted Networks", RFC 3325, November 2002. 669 [8] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 670 D. Gurle, "Session Initiation Protocol (SIP) Extension for 671 Instant Messaging", RFC 3428, December 2002. 673 [9] Rosenberg, J., "Extensible Markup Language (XML) Formats for 674 Representing Resource Lists", 675 draft-ietf-simple-xcap-list-usage-05 (work in progress), 676 February 2005. 678 [10] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 679 (S/MIME) Version 3.1 Message Specification", RFC 3851, 680 July 2004. 682 [11] Camarillo, G. and A. Roach, "Framework and Security 683 Considerations for Session Initiation Protocol (SIP) Uniform 684 Resource Identifier (URI)-List Services", 685 draft-ietf-sipping-uri-services-04 (work in progress), 686 October 2005. 688 [12] Garcia-Martin, M. and G. Camarillo, "Extensible Markup Language 689 (XML) Format Extension for Representing Capacity Attributes in 690 Resource Lists", draft-ietf-sipping-capacity-attribute-00 (work 691 in progress), February 2006. 693 13.2. Informational References 695 [13] Rosenberg, J., "Advanced Instant Messaging Requirements for the 696 Session Initiation Protocol (SIP)", 697 draft-rosenberg-simple-messaging-requirements-01 (work in 698 progress), February 2004. 700 Authors' Addresses 702 Miguel A. Garcia-Martin 703 Nokia 704 P.O.Box 407 705 NOKIA GROUP, FIN 00045 706 Finland 708 Email: miguel.an.garcia@nokia.com 710 Gonzalo Camarillo 711 Ericsson 712 Hirsalantie 11 713 Jorvas 02420 714 Finland 716 Email: Gonzalo.Camarillo@ericsson.com 718 Full Copyright Statement 720 Copyright (C) The Internet Society (2006). 722 This document is subject to the rights, licenses and restrictions 723 contained in BCP 78, and except as set forth therein, the authors 724 retain all their rights. 726 This document and the information contained herein are provided on an 727 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 728 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 729 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 730 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 731 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 732 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 734 Intellectual Property 736 The IETF takes no position regarding the validity or scope of any 737 Intellectual Property Rights or other rights that might be claimed to 738 pertain to the implementation or use of the technology described in 739 this document or the extent to which any license under such rights 740 might or might not be available; nor does it represent that it has 741 made any independent effort to identify any such rights. Information 742 on the procedures with respect to rights in RFC documents can be 743 found in BCP 78 and BCP 79. 745 Copies of IPR disclosures made to the IETF Secretariat and any 746 assurances of licenses to be made available, or the result of an 747 attempt made to obtain a general license or permission for the use of 748 such proprietary rights by implementers or users of this 749 specification can be obtained from the IETF on-line IPR repository at 750 http://www.ietf.org/ipr. 752 The IETF invites any interested party to bring to its attention any 753 copyrights, patents or patent applications, or other proprietary 754 rights that may cover technology that may be required to implement 755 this standard. Please address the information to the IETF at 756 ietf-ipr@ietf.org. 758 Acknowledgment 760 Funding for the RFC Editor function is currently provided by the 761 Internet Society.