idnits 2.17.1 draft-ietf-sipping-uri-list-message-05.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 837. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 848. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 855. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 861. ** 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 21 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 (January 17, 2006) is 6673 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 653 ** 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 Summary: 6 errors (**), 0 flaws (~~), 5 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: July 21, 2006 G. Camarillo 5 Ericsson 6 January 17, 2006 8 Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol 9 (SIP) 10 draft-ietf-sipping-uri-list-message-05.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 July 21, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document specifies how to request a SIP URI-list service to send 44 a copy of a MESSAGE to a set of destinations. The client sends a SIP 45 MESSAGE request with a URI-list to the MESSAGE URI-list service, 46 which sends a similar MESSAGE request to each of the URIs included in 47 the list. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. URI-List document . . . . . . . . . . . . . . . . . . . . . . 5 55 4.1. Extension to the resource lists data format . . . . . . . 6 56 4.2. URI-list example . . . . . . . . . . . . . . . . . . . . . 7 57 5. Option-tag . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 6. Procedures at the User Agent Client . . . . . . . . . . . . . 8 59 7. Procedures at the MESSAGE URI-List Service . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 66 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 67 11.1. Disposition Type Registration . . . . . . . . . . . . . . 16 68 11.2. Option-Tag Registration . . . . . . . . . . . . . . . . . 16 69 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 70 13. Change control . . . . . . . . . . . . . . . . . . . . . . . . 16 71 13.1. Changes from draft-ietf-sipping-uri-list-message-02.txt . 17 72 13.2. Changes from draft-ietf-sipping-uri-list-message-01.txt . 17 73 13.3. Changes from draft-ietf-sipping-uri-list-message-00.txt . 17 74 13.4. Changes from 75 draft-ietf-sipping-message-exploder-00.txt to 76 draft-ietf-sipping-uri-list-message-00.txt . . . . . . . . 17 77 13.5. Changes from 78 draft-garcia-simple-message-exploder-00.txt to 79 draft-garcia-sipping-message-exploder-00.txt . . . . . . . 18 80 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 14.1. Normative References . . . . . . . . . . . . . . . . . . . 18 82 14.2. Informational References . . . . . . . . . . . . . . . . . 19 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 84 Intellectual Property and Copyright Statements . . . . . . . . . . 20 86 1. Introduction 88 SIP [5] can carry instant messages in MESSAGE [8] requests. The 89 Advanced Instant Messaging Requirements for SIP [12] mentions the 90 need for sending a MESSAGE request to multiple recipients: 92 "REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc 93 group, where the identities of the recipients are carried in the 94 message itself." 96 One possibility to fulfill the above requirement is to establish a 97 session of instant messages with an instant messaging conference 98 server. While this option seems to be reasonable in many cases, in 99 other situations the sending user just want to send a small page-mode 100 instant message to an ad-hoc group, without entering the burden of 101 setting up a session. This document focuses on sending a page-mode 102 instant message to a number of intended recipients. 104 To meet the requirement with a page-mode instant message, we allow 105 SIP MESSAGE requests carry URI-lists in body parts whose Content- 106 Disposition [2] is 'recipient-list', as specified in the Framework 107 and Security Considerations for SIP URI-List Services [11]. A SIP 108 MESSAGE URI-list service, which is a specialized application service, 109 receives the request and sends a similar MESSAGE request to each of 110 the URIs in the list. Each of these MESSAGE requests contains a copy 111 of the body included in the original MESSAGE request. 113 The Advanced Instant Messaging Requirements for SIP [12] also 114 includes a requirement that allows to provide a "Reply-to-All" 115 functionality: 117 "REQ-GROUP-4: It MUST be possible for the recipient of a group IM 118 to send a message to all other participants that received the same 119 group IM (i.e., Reply-To-All)." 121 To meet this requirement, we provide a mechanism whereby the MESSAGE 122 URI-list service can include the received URI-list along the instant 123 message payload in each of the instant messages sent to the 124 recipients. 126 The UAC (User Agent Client) that sends a MESSAGE request to a MESSAGE 127 URI-list service needs to be configured with the SIP URI of the 128 service that provides the functionality. Discovering and 129 provisioning of this URI to the UAC is outside the scope of this 130 document. 132 2. Terminology 134 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 135 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 136 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 137 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 138 compliant implementations. 140 MESSAGE URI-list service: SIP application service that receives a 141 MESSAGE request with a URI-list and sends a similar MESSAGE 142 request to each URI in the list. In this context, similar 143 indicates that some SIP header fields can change, but the MESSAGE 144 URI-list service will not change the instant message payload. 145 MESSAGE URI-list services behave effectively as specialised B2BUAs 146 (Back-To-Back-User-Agents). A server providing MESSAGE URI-list 147 services can also offer URI-list services for other methods, 148 although this functionality is outside the scope of this document. 149 In this document we only discuss MESSAGE URI-list services. 151 Incoming MESSAGE request: A SIP MESSAGE request that a UAC creates 152 and addresses to a MESSAGE URI-list service. Besides the regular 153 instant message payload, an incoming MESSAGE request contains a 154 URI-list. 156 Outgoing MESSAGE request: A SIP MESSAGE request that a MESSAGE URI- 157 list service creates and addresses to a UAS (User Agent Server). 158 It contains the regular instant message payload. 160 Intended recipient: The intended final recipient of the request to 161 be generated by MESSAGE URI-list service. 163 3. Overview 165 A UAC creates a MESSAGE request that contains a multipart body 166 including a list of URIs (intended recipients) and an instant 167 message. The UAC sends this MESSAGE request to the MESSAGE URI-List 168 service. On reception of this incoming MESSAGE request, the MESSAGE 169 URI-list service creates a MESSAGE request per intended recipient 170 (listed in the URI-list) and copies the instant message payload to 171 each of those MESSAGES. Then the MESSAGE URI-list service sends each 172 of the created outgoing MESSAGE request to the respective receiver. 174 The mechanism reuses the XML format for representing resource lists 175 [9] to include the list of intended recipients. We define an 176 extension to that list to indicate the capacity of each resource, 177 which can be To, Cc or Bcc (in an analogy to e-mail). The MESSAGE 178 URI-list service can include a resource list in the outgoing MESSAGE 179 request that contain those resources tagged with a To or Cc 180 capacities (and not Bcc capacities). This allows the creator of the 181 incoming MESSAGE request to identify if a resource should be 182 receiving a copy of the MESSAGE request as a capacity of recipient 183 (to), carbon copy (cc) or blind carbon copy (bcc). It also allows 184 some the intended recipients to reply to the initial sender and all 185 the visible recipients of the MESSAGE request. 187 4. URI-List document 189 As described in the Framework and Security Considerations for SIP 190 URI-List Services [11], specifications of individual URI-list 191 services, like the MESSAGE URI-list service described here, need to 192 specify a default format for 'recipient-list' bodies used within the 193 particular service. 195 The default format for recipient-list bodies for MESSAGE URI-list 196 services is the resource list document format [9] . UAs (User 197 Agents) and servers handling recipient-list bodies MUST support this 198 format and MAY support other formats. 200 Nevertheless, the Extensible Markup Language (XML) Configuration 201 Access Protocol (XCAP) resource list document provides features, such 202 as hierarchical lists and the ability to include entries by reference 203 relative to the XCAP root URI, that are not needed by the MESSAGE 204 URI-list service defined in this document, which only needs to 205 transfer a flat list of URIs between a UA and the server. Therefore, 206 when using the default resource list document, UAs SHOULD use flat 207 lists (i.e., no hierarchical lists) and SHOULD NOT use 208 elements. 210 Section 4.1 defines an extension to the XML format for representing 211 resource lists [9]. This extension allows us to characterize a 212 resource with a 'capacity' attribute. UACs (User Agent Clients) and 213 MESSAGE URI-list services handling 'recipient-list' bodies MUST 214 support 'capacity' extension. 216 A MESSAGE URI-list service receiving a URI-list with more information 217 than what has just been described MAY discard all the extra 218 information. 220 Additionally, this document defines a new mail disposition type value 221 to be included in a Content-Disposition [2] header field of a SIP 222 MESSAGE request. The value of this new disposition type is 223 'recipient-list-history' and its purpose is to indicate a list of 224 recipients that a MESSAGE was sent to. A body whose Content- 225 Disposition type is 'recipient-list-history' contains a URI-list with 226 the visible recipients of the MESSAGE. The element in the 227 URI-list MAY also include a 'capacity' attribute, as specified in 228 Section 4.1. MESSAGE URI-list services MUST implement support for 229 this Content-Disposition type. User Agent Servers (UAS) MAY 230 implement support for the resource-list document format [9] and the 231 'recipient-list-history' Content-Disposition type. 233 4.1. Extension to the resource lists data format 235 This document defines an extension to indicate the capacity of a 236 resource. We define a new 'capacity' attribute to the 237 element. The 'capacity' attribute has similar semantics to the type 238 of destination address in e-mail systems. It can take the values 239 "to", "cc" and "bcc". A "to" value of the 'capacity' attribute 240 indicates that the resource is considered the recipient of the 241 MESSAGE request. A "cc" value indicates that the resource receives a 242 carbon copy of the MESSAGE request. A "bcc" value indicates that the 243 resource receives a blind carbon copy of the MESSAGE request. The 244 default 'capacity' value is "bcc", that is, the absence of a 245 'capacity' attribute MUST be treated as if the 'capacity' was set to 246 "bcc". 248 The 'capacity' attribute SHOULD be included as a modifier of any of 249 the child elements included in the element of a resource list 250 (e.g., an attribute of the or elements). 252 Figure 1 describes the format of the 'capacity' attribute. 253 Implementations according to this specification MUST support this XML 254 Schema. 256 257 264 265 266 Adds the capacity attribute to URIs included 267 in a resource list. 268 269 271 272 273 274 275 276 277 278 279 280 282 Figure 1: Extension to the resource lists data format 284 4.2. URI-list example 286 Figure 2 shows an example of a flat list that follows the resource 287 list data format. Each resource indicates the capacity of a 288 resource. 290 291 294 295 296 297 298 299 301 Figure 2: URI-List 303 5. Option-tag 305 This document defines the 'recipient-list-message' option-tag for use 306 in the Require and Supported SIP header fields. 308 User agent clients generating a MESSAGE with a recipient-list body, 309 as described in previous sections, MUST include this option-tag in a 310 Require header field. User agents that are able to receive and 311 process MESSAGEs with a recipient-list body, as described in previous 312 sections, SHOULD include this option-tag in a Supported header field 313 when responding to OPTIONS requests. 315 6. Procedures at the User Agent Client 317 A UAC that wants to create a multiple-recipient MESSAGE request MUST 318 create a MESSAGE request according to RFC 3428 [8] Section 4. The 319 UAC SHOULD populate the Request-URI with the SIP or SIPS URI of the 320 MESSAGE URI-list service. In addition to the regular instant message 321 body, the UAC SHOULD add a URI-list body whose Content-Disposition 322 type is 'recipient-list', specifed in the Framework and Security 323 Considerations for SIP URI-list Services [11]. This body contains a 324 URI-list with the recipients of the MESSAGE. The URI-list body MAY 325 also include the 'capacity' extension to the URI-list specified in 326 Section 4.1. The UAC MUST also include the 'recipient-list-message' 327 option-tag, defined in Section 5, in a Require header field. 329 Multiple-recipient MESSAGE requests contain a multipart body that 330 contains the body carrying the list and the actual instant message 331 payload. In some cases, the MESSAGE request may contain bodies other 332 than the text and the list bodies (e.g., when the request is 333 protected with S/MIME [10]). 335 Typically, the MESSAGE URI-list service will copy all the significant 336 header fields in the outgoing MESSAGE request. However, there might 337 be cases where the SIP UA wants the MESSAGE URI-list service to add a 338 particular header field with a particular value, even if the header 339 field wasn't present in the MESSAGE request sent by the UAC. In this 340 case, the UAC MAY use the "?" mechanism described in Section 19.1.1 341 of RFC 3261 [5] to encode extra information in any URI in the list. 342 However, the UAC MUST NOT use the special "body" hname (see Section 343 19.1.1 of RFC 3261 [5]) to encode a body, since the body is present 344 in the MESSAGE request itself. 346 The following is an example of a URI that uses the "?" mechanism: 348 sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22 349 The previous URI requests the MESSAGE URI-list service to add the 350 following header field to a MESSAGE request to be sent to 351 bob@example.com: 353 Accept-Contact: *;mobility="mobile" 355 7. Procedures at the MESSAGE URI-List Service 357 On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list 358 service SHOULD answer to the UAC with a 202 Accepted response. Note 359 that the status code in the response to the MESSAGE does not provide 360 any information about whether or not the MESSAGEs generated by the 361 URI-list service were successfully delivered to the URIs in the list. 362 That is, a 202 Accepted means that the MESSAGE URI-list service has 363 received the MESSAGE and that it will try to send a similar MESSAGE 364 to the URIs in the list. Designing a mechanism to inform a client 365 about the delivery status of an instant message is outside the scope 366 of this document. 368 7.1. Determining the intended recipient 370 On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list 371 service SHOULD determine the list of intended recipients, by 372 inspecting the URI-list contained in the body. In case two of those 373 URIs are equivalent (section 19.1.4 of RFC 3261 [5] defines 374 equivalent URIs), the MESSAGE URI-list SHOULD consider a single 375 intended recipient. 377 7.2. Creating an outgoing MESSAGE request 379 Since the MESSAGE URI-list behaves as a UAC for outgoing MESSAGE 380 requests, for each of the intended recipients, the MESSAGE URI-list 381 service creates a new MESSAGE request according to the procedures 382 described in Section 4 of RFC 3428 [8] and the following procedures: 384 o A MESSAGE URI-list service MUST include a From header field whose 385 value is the same as the From header field included in the 386 incoming MESSAGE request, subject to the privacy requirements (see 387 RFC 3323 [6] and RFC 3325 [7]) expressed in the incoming MESSAGE 388 request. Note that this does not apply to the "tag" parameter. 389 o A MESSAGE URI-list service SHOULD generate a new To header field 390 value set to the intended recipient URI. According to the 391 procedures of RFC 3261 Section 8.1.1.1, this value should also be 392 equal to the Request-URI of the outgoing MESSAGE request. 393 o A MESSAGE URI-list service SHOULD create a new Call-ID header 394 field value. 396 o If a P-Asserted-Identity header field was present in the incoming 397 MESSAGE request and the request was received from a trusted 398 source, as specified in RFC 3325 [7], and the first hop of the 399 outgoing MESSAGE request is also trusted, a MESSAGE URI-list 400 service MUST include a P-Asserted-Identity header field in the 401 outgoing MESSAGE request with the same received value. However, 402 if the first hop of the outgoing MESSAGE request is not trusted 403 and the incoming MESSAGE request included a Privacy header field 404 with a value different than 'none', the MESSAGE URI-list service 405 MUST NOT include a P-Asserted-Identity header field in the 406 outgoing MESSAGE request. 407 o If a MESSAGE URI-list service is able to assert the identity of a 408 user (e.g., using HTTP Digest authentication scheme [3], S/MIME 409 [10], etc.) and the service implements a mechanism where it can 410 map that authentication scheme to a user's SIP or SIPS URI, and 411 subject to the privacy requirements expressed in the incoming 412 MESSAGE request (see RFC 3323 [6], the MESSAGE URI-list MAY insert 413 a P-Asserted-Identity header with the value of the user's asserted 414 URI. 415 o If the incoming MESSAGE request contains an Authorization or 416 Proxy-Authorization header fields whose realm is set to the 417 MESSAGE URI-list server's realm, then the MESSAGE URI-list service 418 SHOULD NOT copy it to the outgoing MESSAGE request; otherwise 419 (i.e., if the Authorization or Proxy-Authorization header field of 420 incoming MESSAGE request contains a different realm), the MESSAGE 421 URI-list service MUST copy the value to the respective header 422 field of the outgoing MESSAGE request. 423 o A MESSAGE URI-list service SHOULD create a separate count for the 424 CSeq header field of the outgoing MESSAGE request. 425 o A MESSAGE URI-list service SHOULD initialize the value of the Max- 426 Forward header field of the outgoing MESSAGE request. 427 o A MESSAGE URI-list service MUST include its own value in the Via 428 header field. 429 o A MESSAGE URI-list service SHOULD include any other header field 430 expressed with the "?" mechanism described in Section 19.1.1 of 431 RFC 3261 [5] and encoded in the intended recipient URI of the URI- 432 list. 433 o A MESSAGE URI-list service SHOULD preserve to the outgoing MESSAGE 434 request any other header field not explicitly indicated in the 435 above paragraphs. 436 o If the URI-list of the incoming MESSAGE request include resources 437 tagged with the 'capacity' attribute set with a value of "to" or 438 "cc", the URI-list service SHOULD include a URI-list in each of 439 the outgoing MESSAGE requests. 441 7.3. Composing bodies in the outgoing MESSAGE request 443 When creating the body of each of the outgoing MESSAGE requests, the 444 MESSAGE URI-list service tries to keep the relevant bodies of the 445 incoming MESSAGE request and copies them to the outgoing MESSAGE 446 request. The following guidelines are provided: 448 o A MESSAGE request received at a MESSAGE URI-list service can 449 contain one or more security bodies (e.g., S/MIME [10]) encrypted 450 with the public key of the MESSAGE URI-list service. These bodies 451 are deemed to be read by the URI-list service rather than the 452 recipient of the outgoing MESSAGE request (which will not be able 453 to decrypt them). Therefore, a MESSAGE URI-list service MUST NOT 454 copy any security body (such as an S/MIME [10] encrypted body) 455 addressed to the MESSAGE URI-list service to the outgoing MESSAGE 456 request. This includes bodies encrypted with the public key of 457 the URI-list service. 458 o The incoming MESSAGE request typically contains a URI-list body or 459 reference [11] with the actual list of recipients. Section 7.2 460 contains procedures that determine when the MESSAGE URI-list 461 service should include a URI-list body in the outgoing MESSAGE 462 request. 463 o If the MESSAGE URI-list service includes a URI-list in an outgoing 464 MESSAGE request, then the list SHOULD be formatted according to 465 the XML format for representing resource lists [9] and the 466 capacity extension specified in Section 4.1. This resource list 467 MUST contain those elements categorized with the "to" or "cc" 468 capacity attribute and MUST NOT contain those resources 469 categorized with the "bcc" or lacking the capacity attribute (the 470 default value for the capacity of resources without a capacity 471 attribute is "bcc"). 472 o If the MESSAGE URI-list service includes a URI-list in an outgoing 473 MESSAGE request, it MUST include a Content-Disposition header 474 field [2] with the value set to 'recipient-list-history' and a 475 'handling' parameter [4] set to "optional". 476 o If a MESSAGE URI-list service includes a URI-list in an outgoing 477 MESSAGE request, it SHOULD use S/MIME [10] to encrypt the URI-list 478 with the public key of the receiver. 479 o The MESSAGE URI-list service SHOULD copy all the rest of the 480 message bodies (e.g., text messages, images, etc.) to the outgoing 481 MESSAGE request. 482 o If there is only one body left, the MESSAGE URI-list service MUST 483 remove the multipart/mixed wrapper in the outgoing MESSAGE 484 request. 486 The rest of the MESSAGE request corresponding to a given URI in the 487 URI-list MUST be created following the rules in Section 19.1.5 488 "Forming Requests from a URI" of RFC 3261 [5]. In particular, 489 Section 19.1.5 of RFC 3261 [5] states: 491 "An implementation SHOULD treat the presence of any headers or body 492 parts in the URI as a desire to include them in the message, and 493 choose to honor the request on a per-component basis." 495 SIP allows to append a "method" parameter to a URI. Therefore, it is 496 legitimate that an the 'uri' attribute of the element in the 497 XCAP resource list contains a 'method' parameter. MESSAGE URI-list 498 services MUST generate only MESSAGE requests, regardless of the 499 'method' parameter that the URIs in the list indicate. Effectively, 500 MESSAGE URI-list services MUST ignore the 'method' parameter in each 501 of the URIs present in the URI-list. 503 8. Procedures at the UAS 505 A UAS (in this specification, also known as intended recipient UAS) 506 that receives a MESSAGE request from the URI-list service behaves as 507 specified in RFC 3428 [8] Section 7. 509 If the UAS supports this specification and the MESSAGE request 510 contains a body with a Content-Disposition header field [2] set to 511 'recipient-list-history', then the UAS will be able to determine who 512 are the other intended visible recipients of the MESSAGE request. 513 This allows the user to create a reply request (e.g., MESSAGE, 514 INVITE) to the sender and the rest of the visible recipients. 516 9. Examples 518 Figure 3 shows an example of operation. A SIP UAC issuer sends a 519 MESSAGE request. The MESSAGE URI-list service answers with a 202 520 Accepted message and sends a MESSAGE request to each of the intended 521 recipients. 523 +--------+ +---------+ +--------+ +--------+ +--------+ 524 |SIP UAC | | MESSAGE | |intended| |intended| |intended| 525 | issuer | | URI-list| | recip. | | recip. | | recip. | 526 | | | service | | 1 | | 2 | | 3 | 527 +--------+ +---------+ +--------+ +--------+ +--------+ 528 | | | | | 529 | F1. MESSAGE | | | | 530 | ---------------->| | | | 531 | F2. 202 Accepted | | | | 532 |<---------------- | F3. MESSAGE | | | 533 | | ------------->| | | 534 | | F4. MESSAGE | | | 535 | | ------------------------>| | 536 | | F5. MESSAGE | | | 537 | | ----------------------------------->| 538 | | F6. 200 OK | | | 539 | |<------------- | | | 540 | | F7. 200 OK | | | 541 | |<------------------------ | | 542 | | F8. 200 OK | | | 543 | |<----------------------------------- | 544 | | | | | 545 | | | | | 546 | | | | | 548 Figure 3: Example of operation 550 The MESSAGE request F1 is as follows: 552 MESSAGE sip:list-service.example.com SIP/2.0 553 Via: SIP/2.0/TCP uac.example.com 554 ;branch=z9hG4bKhjhs8ass83 555 Max-Forwards: 70 556 To: MESSAGE URI-list Service 557 From: Carol ;tag=32331 558 Call-ID: d432fa84b4c76e66710 559 CSeq: 1 MESSAGE 560 Require: recipient-list-message 561 Content-Type: multipart/mixed;boundary="boundary1" 562 Content-Length: 501 564 --boundary1 565 Content-Type: text/plain 567 Hello World! 569 --boundary1 570 Content-Type: application/resource-lists+xml 571 Content-Disposition: recipient-list 573 574 577 578 579 580 581 582 583 --boundary1-- 585 Messages F3, F4 and F5 are similar in nature. Especially the bodies 586 are exactly the same for all of them, since they include the instant 587 message payload and a URI-list that contains the resources tagged 588 with the "to" and "cc" capacity attribute. We show an example of F3: 590 MESSAGE sip:bill@example.com SIP/2.0 591 Via: SIP/2.0/TCP list-service.example.com 592 ;branch=z9hG4bKhjhs8as34sc 593 Max-Forwards: 70 594 To: 595 From: Carol ;tag=210342 596 Call-ID: 39s02sdsl20d9sj2l 597 CSeq: 1 MESSAGE 598 Content-Type: multipart/mixed;boundary="boundary1" 599 Content-Length: 501 601 --boundary1 602 Content-Type: text/plain 604 Hello World! 606 --boundary1 607 Content-Type: application/resource-lists+xml 608 Content-Disposition: recipient-list-history; handling=optional 610 611 614 615 616 617 618 619 --boundary1-- 621 10. Security Considerations 623 The Framework and Security Considerations for SIP URI-List Services 624 [11] discusses issues related to SIP URI-list services. 625 Implementations of MESSAGE URI-list services MUST follow the 626 security-related rules in the Framework and Security Considerations 627 for SIP URI-List Services [11]. These rules include mandatory 628 authentication and authorization of clients, and opt-in lists. 630 If the contents of the instant message needs to be kept private, the 631 user agent client SHOULD use S/MIME [10] to prevent a third party 632 from viewing this information. In this case, the user agent client 633 SHOULD encrypt the instant message body with a content encryption 634 key. Then, for each receiver in the list, the UAC SHOULD encrypt the 635 content encryption key with the public key of the receiver, and 636 attach it to the MESSAGE request. 638 11. IANA Considerations 640 The following sections instruct the IANA to register a new 641 disposition type and a new SIP option-tag. 643 11.1. Disposition Type Registration 645 Section 4 defines a new 'recipient-list-history' value of the Mail 646 Content Disposition Values registry. This value should be registered 647 in the IANA registry of Mail Content Disposition Values with the 648 following registration data: 650 +------------------------+------------------------------+-----------+ 651 | Name | Description | Reference | 652 +------------------------+------------------------------+-----------+ 653 | recipient-list-history | the body contains a list of | [RFCXXXX] | 654 | | URIs that indicates the | | 655 | | recipients of the message | | 656 +------------------------+------------------------------+-----------+ 658 Table 1: Registration of the 'recipient-list-history' Mail Content 659 Disposition Value 661 Note to IANA and the RFC editor: replace RFCXXXX above with the RFC 662 number of this specification. 664 11.2. Option-Tag Registration 666 This document defines the 'recipient-list-message' SIP option-tag in 667 Section 5. It should be registered in the Option Tags subregistry 668 under the SIP parameter registry. The following is the description 669 to be used in the registration. 671 This option-tag is used to ensure that a server can process the 672 'recipient-list' body used in a MESSAGE request. 674 12. Acknowledgements 676 Duncan Mills supported the idea of having 1 to n MESSAGEs. Ben 677 Campbell, Paul Kyzivat, Cullen Jennings, and Jonathan Rosenberg 678 provided helpful comments. 680 13. Change control 681 13.1. Changes from draft-ietf-sipping-uri-list-message-02.txt 683 Typos fixed. 685 'recipient-list-message' option-tag defined and registered with the 686 IANA. 688 13.2. Changes from draft-ietf-sipping-uri-list-message-01.txt 690 Added a reference to missing REQ-GROUP-4 in the Advanced Instant 691 Messaging Requirements for SIP document. 693 Since the resource list allows now attribute extensibility, the 694 former element has been replaced by a 'capacity' 695 attribute, which allows a more compact representation of the URI. 697 Added a new Content-Disposition disposition type 'recipient-list- 698 history'. It is used in the MESSAGE request that the MESSAGE URI- 699 list service sends to each of the recipients. This allows the UAS to 700 differentiate it from a 'recipient-list', which has a separate 701 meaning. 703 13.3. Changes from draft-ietf-sipping-uri-list-message-00.txt 705 Revision of the treatment of headers the MESSAGE URI-list service, on 706 a header by header basis. 708 Added an overview section. 710 Added functionality that allows the sender of the incoming MESSAGE 711 request to tag each of the intended recipients with the "to", "cc", 712 or "bcc" capacity. If there are resources tagged as "to" or "cc", 713 the URI-list service will include a URI-list in each of the outgoing 714 MESSAGE request including those resources. 716 Procedures at the UAS included. 718 Better example including a flow. 720 13.4. Changes from draft-ietf-sipping-message-exploder-00.txt to 721 draft-ietf-sipping-uri-list-message-00.txt 723 Clarified that the MESSAGE exploder should not distribute a body that 724 has been encrypted with the public key of the exploder. The 725 exception is the URI-list, which can be distributed by the exploder, 726 providing that is encrypted with the public key of the receiver. 728 The security considerations section describes how to encrypt the list 729 and how to encrypt the instant message payload. 731 Terminology aligned with the requirements and the framework for URI- 732 list services (e.g., the term "exploder" has been deprecated). 734 13.5. Changes from draft-garcia-simple-message-exploder-00.txt to 735 draft-garcia-sipping-message-exploder-00.txt 737 The MESSAGE exploder may or may not copy the URI-list body to the 738 outgoing MESSAGE request. This allows to extend the mechanism with a 739 Reply-to-all feature. 741 It is clarified that the MESSAGE exploder must not include a list in 742 the outgoing MESSAGE requests. This avoids loops or requires a 743 MESSAGE exploder functionality in the next hop. 745 The MESSAGE exploder must remove the multipart/mixed wrapper if there 746 is only one body left in the outgoing MESSAGE request. 748 Filename changed due to focus on the SIPPING WG. 750 14. References 752 14.1. Normative References 754 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 755 Levels", BCP 14, RFC 2119, March 1997. 757 [2] Troost, R., Dorner, S., and K. Moore, "Communicating 758 Presentation Information in Internet Messages: The Content- 759 Disposition Header Field", RFC 2183, August 1997. 761 [3] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 762 Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: 763 Basic and Digest Access Authentication", RFC 2617, June 1999. 765 [4] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., 766 Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG 767 Objects", RFC 3204, December 2001. 769 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 770 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 771 Session Initiation Protocol", RFC 3261, June 2002. 773 [6] Peterson, J., "A Privacy Mechanism for the Session Initiation 774 Protocol (SIP)", RFC 3323, November 2002. 776 [7] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 777 to the Session Initiation Protocol (SIP) for Asserted Identity 778 within Trusted Networks", RFC 3325, November 2002. 780 [8] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 781 D. Gurle, "Session Initiation Protocol (SIP) Extension for 782 Instant Messaging", RFC 3428, December 2002. 784 [9] Rosenberg, J., "Extensible Markup Language (XML) Formats for 785 Representing Resource Lists", 786 draft-ietf-simple-xcap-list-usage-05 (work in progress), 787 February 2005. 789 [10] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 790 (S/MIME) Version 3.1 Message Specification", RFC 3851, 791 July 2004. 793 [11] Camarillo, G. and A. Roach, "Framework and Security 794 Considerations for Session Initiation Protocol (SIP) Uniform 795 Resource Identifier (URI)-List Services", 796 draft-ietf-sipping-uri-services-04 (work in progress), 797 October 2005. 799 14.2. Informational References 801 [12] Rosenberg, J., "Advanced Instant Messaging Requirements for the 802 Session Initiation Protocol (SIP)", 803 draft-rosenberg-simple-messaging-requirements-01 (work in 804 progress), February 2004. 806 Authors' Addresses 808 Miguel A. Garcia-Martin 809 Nokia 810 P.O.Box 407 811 NOKIA GROUP, FIN 00045 812 Finland 814 Email: miguel.an.garcia@nokia.com 815 Gonzalo Camarillo 816 Ericsson 817 Hirsalantie 11 818 Jorvas 02420 819 Finland 821 Email: Gonzalo.Camarillo@ericsson.com 823 Full Copyright Statement 825 Copyright (C) The Internet Society (2006). 827 This document is subject to the rights, licenses and restrictions 828 contained in BCP 78, and except as set forth therein, the authors 829 retain all their rights. 831 This document and the information contained herein are provided on an 832 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 833 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 834 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 835 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 836 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 837 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 839 Intellectual Property 841 The IETF takes no position regarding the validity or scope of any 842 Intellectual Property Rights or other rights that might be claimed to 843 pertain to the implementation or use of the technology described in 844 this document or the extent to which any license under such rights 845 might or might not be available; nor does it represent that it has 846 made any independent effort to identify any such rights. Information 847 on the procedures with respect to rights in RFC documents can be 848 found in BCP 78 and BCP 79. 850 Copies of IPR disclosures made to the IETF Secretariat and any 851 assurances of licenses to be made available, or the result of an 852 attempt made to obtain a general license or permission for the use of 853 such proprietary rights by implementers or users of this 854 specification can be obtained from the IETF on-line IPR repository at 855 http://www.ietf.org/ipr. 857 The IETF invites any interested party to bring to its attention any 858 copyrights, patents or patent applications, or other proprietary 859 rights that may cover technology that may be required to implement 860 this standard. Please address the information to the IETF at 861 ietf-ipr@ietf.org. 863 Acknowledgment 865 Funding for the RFC Editor function is currently provided by the 866 Internet Society.