idnits 2.17.1 draft-ietf-sipping-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 on line 861. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 838. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 845. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 851. ** 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 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 (April 8, 2005) is 6958 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 == Unused Reference: '3' is defined on line 762, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 808, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2617 (ref. '4') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Downref: Normative reference to an Informational RFC: RFC 3325 (ref. '8') == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-02 Summary: 5 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: October 10, 2005 G. Camarillo 5 Ericsson 6 April 8, 2005 8 Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol 9 (SIP) 10 draft-ietf-sipping-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 October 10, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 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 . . . . . 10 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 72 draft-ietf-sipping-uri-list-message-02.txt . . . . . . . 16 73 13.2 Changes from 74 draft-ietf-sipping-uri-list-message-01.txt . . . . . . . 17 75 13.3 Changes from 76 draft-ietf-sipping-uri-list-message-00.txt . . . . . . . 17 77 13.4 Changes from 78 draft-ietf-sipping-message-exploder-00.txt to 79 draft-ietf-sipping-uri-list-message-00.txt . . . . . . . 17 80 13.5 Changes from 81 draft-garcia-simple-message-exploder-00.txt to 82 draft-garcia-sipping-message-exploder-00.txt . . . . . . 18 83 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 14.1 Normative References . . . . . . . . . . . . . . . . . . 18 85 14.2 Informational References . . . . . . . . . . . . . . . . 19 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 87 Intellectual Property and Copyright Statements . . . . . . . 20 89 1. Introduction 91 SIP [6] can carry instant messages in MESSAGE [9] requests. The 92 Advanced Instant Messaging Requirements for SIP [13] mentions the 93 need for sending a MESSAGE request to multiple recipients: 95 "REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc 96 group, where the identities of the recipients are carried in the 97 message itself." 99 One possibility to fulfill the above requirement is to establish a 100 session of instant messages with an instant messaging conference 101 server. While this option seems to be reasonable in many cases, in 102 other situations the sending user just want to send a small page-mode 103 instant message to an ad-hoc group, without entering the burden of 104 setting up a session. This document focuses on sending a page-mode 105 instant message to a number of intended recipients. 107 To meet the requirement with a page-mode instant message, we allow 108 SIP MESSAGE requests carry URI-lists in body parts whose Content- 109 Disposition [2] is 'recipient-list', as specified in the Framework 110 and Security Considerations for SIP URI-List Services [12]. A SIP 111 MESSAGE URI-list service, which is a specialized application service, 112 receives the request and sends a similar MESSAGE request to each of 113 the URIs in the list. Each of these MESSAGE requests contains a copy 114 of the body included in the original MESSAGE request. 116 The Advanced Instant Messaging Requirements for SIP [13] also 117 includes a requirement that allows to provide a "Reply-to-All" 118 functionality: 120 "REQ-GROUP-4: It MUST be possible for the recipient of a group IM 121 to send a message to all other participants that received the same 122 group IM (i.e., Reply-To-All)." 124 To meet this requirement, we provide a mechanism whereby the MESSAGE 125 URI-list service can include the received URI-list along the instant 126 message payload in each of the instant messages sent to the 127 recipients. 129 The UAC (User Agent Client) that sends a MESSAGE request to a MESSAGE 130 URI-list service needs to be configured with the SIP URI of the 131 service that provides the functionality. Discovering and 132 provisioning of this URI to the UAC is outside the scope of this 133 document. 135 2. Terminology 137 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 138 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 139 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 140 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 141 compliant implementations. 143 MESSAGE URI-list service: SIP application service that receives a 144 MESSAGE request with a URI-list and sends a similar MESSAGE 145 request to each URI in the list. In this context, similar 146 indicates that some SIP header fields can change, but the MESSAGE 147 URI-list service will not change the instant message payload. 148 MESSAGE URI-list services behave effectively as specialised B2BUAs 149 (Back-To-Back-User-Agents). A server providing MESSAGE URI-list 150 services can also offer URI-list services for other methods, 151 although this functionality is outside the scope of this document. 152 In this document we only discuss MESSAGE URI-list services. 154 Incoming MESSAGE request: A SIP MESSAGE request that a UAC creates 155 and addresses to a MESSAGE URI-list service. Besides the regular 156 instant message payload, an incoming MESSAGE request contains a 157 URI-list. 159 Outgoing MESSAGE request: A SIP MESSAGE request that a MESSAGE URI- 160 list service creates and addresses to a UAS (User Agent Server). 161 It contains the regular instant message payload. 163 Intended recipient: The intended final recipient of the request to be 164 generated by MESSAGE URI-list service. 166 3. Overview 168 A UAC creates a MESSAGE request that contains a multipart body 169 including a list of URIs (intended recipients) and an instant 170 message. The UAC sends this MESSAGE request to the MESSAGE URI-List 171 service. On reception of this incoming MESSAGE request, the MESSAGE 172 URI-list service creates a MESSAGE request per intended recipient 173 (listed in the URI-list) and copies the instant message payload to 174 each of those MESSAGES. Then the MESSAGE URI-list service sends each 175 of the created outgoing MESSAGE request to the respective receiver. 177 The mechanism reuses the XML format for representing resource lists 178 [10] to include the list of intended recipients. We define an 179 extension to that list to indicate the capacity of each resource, 180 which can be To, Cc or Bcc (in an analogy to e-mail). The MESSAGE 181 URI-list service can include a resource list in the outgoing MESSAGE 182 request that contain those resources tagged with a To or Cc 183 capacities (and not Bcc capacities). This allows the creator of the 184 incoming MESSAGE request to identify if a resource should be 185 receiving a copy of the MESSAGE request as a capacity of recipient 186 (to), carbon copy (cc) or blind carbon copy (bcc). It also allows 187 some the intended recipients to reply to the initial sender and all 188 the visible recipients of the MESSAGE request. 190 4. URI-List document 192 As described in the Framework and Security Considerations for SIP 193 URI-List Services [12], 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 resource list document format [10] . UAs (User 200 Agents) and servers handling recipient-list bodies MUST support this 201 format and MAY support other formats. 203 Nevertheless, the Extensible Markup Language (XML) Configuration 204 Access Protocol (XCAP) resource list document provides features, such 205 as hierarchical lists and the ability to include entries by reference 206 relative to the XCAP root URI, that are not needed by the MESSAGE 207 URI-list service defined in this document, which only needs to 208 transfer a flat list of URIs between a UA and the server. Therefore, 209 when using the default resource list document, UAs SHOULD use flat 210 lists (i.e., no hierarchical lists) and SHOULD NOT use 211 elements. 213 Section 4.1 defines an extension to the XML format for representing 214 resource lists [10]. This extension allows us to characterize a 215 resource with a 'capacity' attribute. UACs (User Agent Clients) and 216 MESSAGE URI-list services handling 'recipient-list' bodies MUST 217 support 'capacity' extension. 219 A MESSAGE URI-list service receiving a URI-list with more information 220 than what has just been described MAY discard all the extra 221 information. 223 Additionally, this document defines a new mail disposition type value 224 to be included in a Content-Disposition [2] header field of a SIP 225 MESSAGE request. The value of this new disposition type is 226 'recipient-list-history' and its purpose is to indicate a list of 227 recipients that a MESSAGE was sent to. A body whose Content- 228 Disposition type is 'recipient-list-history' contains a URI-list with 229 the visible recipients of the MESSAGE. The element in the 230 URI-list MAY also include a 'capacity' attribute, as specified in 231 Section 4.1. MESSAGE URI-list services MUST implement support for 232 this Content-Disposition type. User Agent Servers (UAS) MAY 233 implement support for the resource-list document format [10] and the 234 'recipient-list-history' Content-Disposition type. 236 4.1 Extension to the resource lists data format 238 This document defines an extension to indicate the capacity of a 239 resource. We define a new 'capacity' attribute to the 240 element. The 'capacity' attribute has similar semantics to the type 241 of destination address in e-mail systems. It can take the values 242 "to", "cc" and "bcc". A "to" value of the 'capacity' attribute 243 indicates that the resource is considered the recipient of the 244 MESSAGE request. A "cc" value indicates that the resource receives a 245 carbon copy of the MESSAGE request. A "bcc" value indicates that the 246 resource receives a blind carbon copy of the MESSAGE request. The 247 default 'capacity' value is "bcc", that is, the absence of a 248 'capacity' attribute MUST be treated as if the 'capacity' was set to 249 "bcc". 251 The 'capacity' attribute SHOULD be included as a modifier of any of 252 the child elements included in the element of a resource list 253 (e.g., an attribute of the or elements). 255 Figure 1 describes the format of the 'capacity' attribute. 256 Implementations according to this specification MUST support this XML 257 Schema. 259 260 267 268 269 Adds the capacity attribute to URIs included 270 in a resource list. 271 272 274 275 276 277 278 279 280 281 282 283 285 Figure 1: Extension to the resource lists data format 287 4.2 URI-list example 289 Figure 2 shows an example of a flat list that follows the resource 290 list data format. Each resource indicates the capacity of a 291 resource. 293 294 297 298 299 300 301 302 304 Figure 2: URI-List 306 5. Option-tag 308 This document defines the 'recipient-list-message' option-tag for use 309 in the Require and Supported SIP header fields. 311 User agent clients generating a MESSAGE with a recipient-list body, 312 as described in previous sections, MUST include this option-tag in a 313 Require header field. User agents that are able to receive and 314 process MESSAGEs with a recipient-list body, as described in previous 315 sections, SHOULD include this option-tag in a Supported header field 316 when responding to OPTIONS requests. 318 6. Procedures at the User Agent Client 320 A UAC that wants to create a multiple-recipient MESSAGE request MUST 321 create a MESSAGE request according to RFC 3428 [9] Section 4. The 322 UAC SHOULD populate the Request-URI with the SIP or SIPS URI of the 323 MESSAGE URI-list service. In addition to the regular instant message 324 body, the UAC SHOULD add a URI-list body whose Content-Disposition 325 type is 'recipient-list', specifed in the Framework and Security 326 Considerations for SIP URI-list Services [12]. This body contains a 327 URI-list with the recipients of the MESSAGE. The URI-list body MAY 328 also include the 'capacity' extension to the URI-list specified in 329 Section 4.1. The UAC MUST also include the 'recipient-list-message' 330 option-tag, defined in Section 5, in a Require header field. 332 Multiple-recipient MESSAGE requests contain a multipart body that 333 contains the body carrying the list and the actual instant message 334 payload. In some cases, the MESSAGE request may contain bodies other 335 than the text and the list bodies (e.g., when the request is 336 protected with S/MIME [11]). 338 Typically, the MESSAGE URI-list service will copy all the significant 339 header fields in the outgoing MESSAGE request. However, there might 340 be cases where the SIP UA wants the MESSAGE URI-list service to add a 341 particular header field with a particular value, even if the header 342 field wasn't present in the MESSAGE request sent by the UAC. In this 343 case, the UAC MAY use the "?" mechanism described in Section 19.1.1 344 of RFC 3261 [6] to encode extra information in any URI in the list. 345 However, the UAC MUST NOT use the special "body" hname (see Section 346 19.1.1 of RFC 3261 [6]) to encode a body, since the body is present 347 in the MESSAGE request itself. 349 The following is an example of a URI that uses the "?" mechanism: 351 sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22 353 The previous URI requests the MESSAGE URI-list service to add the 354 following header field to a MESSAGE request to be sent to 355 bob@example.com: 357 Accept-Contact: *;mobility="mobile" 359 7. Procedures at the MESSAGE URI-List Service 361 On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list 362 service SHOULD answer to the UAC with a 202 Accepted response. Note 363 that the status code in the response to the MESSAGE does not provide 364 any information about whether or not the MESSAGEs generated by the 365 URI-list service were successfully delivered to the URIs in the list. 366 That is, a 202 Accepted means that the MESSAGE URI-list service has 367 received the MESSAGE and that it will try to send a similar MESSAGE 368 to the URIs in the list. Designing a mechanism to inform a client 369 about the delivery status of an instant message is outside the scope 370 of this document. 372 7.1 Determining the intended recipient 374 On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list 375 service SHOULD determine the list of intended recipients, by 376 inspecting the URI-list contained in the body. In case two of those 377 URIs are equivalent (section 19.1.4 of RFC 3261 [6] defines 378 equivalent URIs), the MESSAGE URI-list SHOULD consider a single 379 intended recipient. 381 7.2 Creating an outgoing MESSAGE request 383 Since the MESSAGE URI-list behaves as a UAC for outgoing MESSAGE 384 requests, for each of the intended recipients, the MESSAGE URI-list 385 service creates a new MESSAGE request according to the procedures 386 described in Section 4 of RFC 3428 [9] and the following procedures: 388 o A MESSAGE URI-list service MUST include a From header field whose 389 value is the same as the From header field included in the 390 incoming MESSAGE request, subject to the privacy requirements (see 391 RFC 3323 [7] and RFC 3325 [8]) expressed in the incoming MESSAGE 392 request. Note that this does not apply to the "tag" parameter. 393 o A MESSAGE URI-list service SHOULD generate a new To header field 394 value set to the intended recipient URI. According to the 395 procedures of RFC 3261 Section 8.1.1.1, this value should also be 396 equal to the Request-URI of the outgoing MESSAGE request. 397 o A MESSAGE URI-list service SHOULD create a new Call-ID header 398 field value. 399 o If a P-Asserted-Identity header field was present in the incoming 400 MESSAGE request and the request was received from a trusted 401 source, as specified in RFC 3325 [8], and the first hop of the 402 outgoing MESSAGE request is also trusted, a MESSAGE URI-list 403 service MUST include a P-Asserted-Identity header field in the 404 outgoing MESSAGE request with the same received value. However, 405 if the first hop of the outgoing MESSAGE request is not trusted 406 and the incoming MESSAGE request included a Privacy header field 407 with a value different than 'none', the MESSAGE URI-list service 408 MUST NOT include a P-Asserted-Identity header field in the 409 outgoing MESSAGE request. 410 o If a MESSAGE URI-list service is able to assert the identity of a 411 user (e.g., using HTTP Digest authentication scheme [4], S/MIME 412 [11], etc.) and the service implements a mechanism where it can 413 map that authentication scheme to a user's SIP or SIPS URI, and 414 subject to the privacy requirements expressed in the incoming 415 MESSAGE request (see RFC 3323 [7], the MESSAGE URI-list MAY insert 416 a P-Asserted-Identity header with the value of the user's asserted 417 URI. 418 o If the incoming MESSAGE request contains an Authorization or 419 Proxy-Authorization header fields whose realm is set to the 420 MESSAGE URI-list server's realm, then the MESSAGE URI-list service 421 SHOULD NOT copy it to the outgoing MESSAGE request; otherwise 422 (i.e., if the Authorization or Proxy-Authorization header field of 423 incoming MESSAGE request contains a different realm), the MESSAGE 424 URI-list service MUST copy the value to the respective header 425 field of the outgoing MESSAGE request. 426 o A MESSAGE URI-list service SHOULD create a separate count for the 427 CSeq header field of the outgoing MESSAGE request. 428 o A MESSAGE URI-list service SHOULD initialize the value of the Max- 429 Forward header field of the outgoing MESSAGE request. 430 o A MESSAGE URI-list service MUST include its own value in the Via 431 header field. 432 o A MESSAGE URI-list service SHOULD include any other header field 433 expressed with the "?" mechanism described in Section 19.1.1 of 434 RFC 3261 [6] and encoded in the intended recipient URI of the URI- 435 list. 436 o A MESSAGE URI-list service SHOULD preserve to the outgoing MESSAGE 437 request any other header field not explicitly indicated in the 438 above paragraphs. 440 7.3 Composing bodies in the outgoing MESSAGE request 442 When creating the body of each of the outgoing MESSAGE requests, the 443 MESSAGE URI-list service tries to keep the relevant bodies of the 444 incoming MESSAGE request and copies them to the outgoing MESSAGE 445 request. The following guidelines are provided: 447 o A MESSAGE request received at a MESSAGE URI-list service can 448 contain one or more security bodies (e.g., S/MIME [11]) encrypted 449 with the public key of the MESSAGE URI-list service. These bodies 450 are deemed to be read by the URI-list service rather than the 451 recipient of the outgoing MESSAGE request (which will not be able 452 to decrypt them). Therefore, a MESSAGE URI-list service MUST NOT 453 copy any security body (such as an S/MIME [11] encrypted body) 454 addressed to the MESSAGE URI-list service to the outgoing MESSAGE 455 request. This includes bodies encrypted with the public key of 456 the URI-list service. 457 o If the URI-list of the incoming MESSAGE request include resources 458 tagged with the 'capacity' attribute set with a value of "to" or 459 "cc", the URI-list service SHOULD include a URI-list in each of 460 the outgoing MESSAGE requests. The format of such list SHOULD BE 461 according to the XML format for representing resource lists [10] 462 and the capacity extension specified in Section 4.1. This 463 resource list MUST contain those elements categorized with the 464 "to" or "cc" capacity attribute and MUST NOT contain those 465 resources categorized with the "bcc" or lacking the capacity 466 attribute. 467 o If the MESSAGE URI-list service includes a URI-list in an outgoing 468 MESSAGE request, it MUST include a Content-Disposition header 469 field [2] with the value set to 'recipient-list-history' and a 470 'handling' parameter [5] set to "optional". 471 o If a MESSAGE URI-list service includes a URI-list in an outgoing 472 MESSAGE request, it SHOULD use S/MIME [11] to encrypt the URI-list 473 with the public key of the receiver. 474 o The incoming MESSAGE request typically contains a URI-list body or 475 reference [12] with the actual list of recipients. Section 7.2 476 contains procedures that determine when the MESSAGE URI-list 477 service should include a URI-list body in the outgoing MESSAGE 478 request. 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 [6]. In particular, 489 Section 19.1.5 of RFC 3261 [6] 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 [9] 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 [12] 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 [12]. 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 [11] 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 682 13.1 Changes from draft-ietf-sipping-uri-list-message-02.txt 684 Typos fixed. 686 'recipient-list-message' option-tag defined and registered with the 687 IANA. 689 13.2 Changes from draft-ietf-sipping-uri-list-message-01.txt 691 Added a reference to missing REQ-GROUP-4 in the Advanced Instant 692 Messaging Requirements for SIP document. 694 Since the resource list allows now attribute extensibility, the 695 former element has been replaced by a 'capacity' 696 attribute, which allows a more compact representation of the URI. 698 Added a new Content-Disposition disposition type 'recipient-list- 699 history'. It is used in the MESSAGE request that the MESSAGE URI- 700 list service sends to each of the recipients. This allows the UAS to 701 differentiate it from a 'recipient-list', which has a separate 702 meaning. 704 13.3 Changes from draft-ietf-sipping-uri-list-message-00.txt 706 Revision of the treatment of headers the MESSAGE URI-list service, on 707 a header by header basis. 709 Added an overview section. 711 Added functionality that allows the sender of the incoming MESSAGE 712 request to tag each of the intended recipients with the "to", "cc", 713 or "bcc" capacity. If there are resources tagged as "to" or "cc", 714 the URI-list service will include a URI-list in each of the outgoing 715 MESSAGE request including those resources. 717 Procedures at the UAS included. 719 Better example including a flow. 721 13.4 Changes from draft-ietf-sipping-message-exploder-00.txt to 722 draft-ietf-sipping-uri-list-message-00.txt 724 Clarified that the MESSAGE exploder should not distribute a body that 725 has been encrypted with the public key of the exploder. The 726 exception is the URI-list, which can be distributed by the exploder, 727 providing that is encrypted with the public key of the receiver. 729 The security considerations section describes how to encrypt the list 730 and how to encrypt the instant message payload. 732 Terminology aligned with the requirements and the framework for URI- 733 list services (e.g., the term "exploder" has been deprecated). 735 13.5 Changes from draft-garcia-simple-message-exploder-00.txt to 736 draft-garcia-sipping-message-exploder-00.txt 738 The MESSAGE exploder may or may not copy the URI-list body to the 739 outgoing MESSAGE request. This allows to extend the mechanism with a 740 Reply-to-all feature. 742 It is clarified that the MESSAGE exploder must not include a list in 743 the outgoing MESSAGE requests. This avoids loops or requires a 744 MESSAGE exploder functionality in the next hop. 746 The MESSAGE exploder must remove the multipart/mixed wrapper if there 747 is only one body left in the outgoing MESSAGE request. 749 Filename changed due to focus on the SIPPING WG. 751 14. References 753 14.1 Normative References 755 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 756 Levels", BCP 14, RFC 2119, March 1997. 758 [2] Troost, R., Dorner, S., and K. Moore, "Communicating 759 Presentation Information in Internet Messages: The Content- 760 Disposition Header Field", RFC 2183, August 1997. 762 [3] Levinson, E., "Content-ID and Message-ID Uniform Resource 763 Locators", RFC 2392, August 1998. 765 [4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 766 Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: 767 Basic and Digest Access Authentication", RFC 2617, June 1999. 769 [5] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., 770 Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG 771 Objects", RFC 3204, December 2001. 773 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 774 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 775 Session Initiation Protocol", RFC 3261, June 2002. 777 [7] Peterson, J., "A Privacy Mechanism for the Session Initiation 778 Protocol (SIP)", RFC 3323, November 2002. 780 [8] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 781 to the Session Initiation Protocol (SIP) for Asserted Identity 782 within Trusted Networks", RFC 3325, November 2002. 784 [9] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 785 D. Gurle, "Session Initiation Protocol (SIP) Extension for 786 Instant Messaging", RFC 3428, December 2002. 788 [10] Rosenberg, J., "Extensible Markup Language (XML) Formats for 789 Representing Resource Lists", 790 draft-ietf-simple-xcap-list-usage-05 (work in progress), 791 February 2005. 793 [11] Ramsdell, B., "S/MIME Version 3.1 Message Specification", 794 draft-ietf-smime-rfc2633bis-09 (work in progress), April 2004. 796 [12] Camarillo, G. and A. Roach, "Requirements and Framework for 797 Session Initiation Protocol (SIP)Uniform Resource Identifier 798 (URI)-List Services", draft-ietf-sipping-uri-services-02 (work 799 in progress), December 2004. 801 14.2 Informational References 803 [13] Rosenberg, J., "Advanced Instant Messaging Requirements for the 804 Session Initiation Protocol (SIP)", 805 draft-rosenberg-simple-messaging-requirements-01 (work in 806 progress), February 2004. 808 [14] Peterson, J., "Session Initiation Protocol (SIP) Authenticated 809 Identity Body (AIB) Format", RFC 3893, September 2004. 811 Authors' Addresses 813 Miguel A. Garcia-Martin 814 Nokia 815 P.O.Box 407 816 NOKIA GROUP, FIN 00045 817 Finland 819 Email: miguel.an.garcia@nokia.com 821 Gonzalo Camarillo 822 Ericsson 823 Hirsalantie 11 824 Jorvas 02420 825 Finland 827 Email: Gonzalo.Camarillo@ericsson.com 829 Intellectual Property Statement 831 The IETF takes no position regarding the validity or scope of any 832 Intellectual Property Rights or other rights that might be claimed to 833 pertain to the implementation or use of the technology described in 834 this document or the extent to which any license under such rights 835 might or might not be available; nor does it represent that it has 836 made any independent effort to identify any such rights. Information 837 on the procedures with respect to rights in RFC documents can be 838 found in BCP 78 and BCP 79. 840 Copies of IPR disclosures made to the IETF Secretariat and any 841 assurances of licenses to be made available, or the result of an 842 attempt made to obtain a general license or permission for the use of 843 such proprietary rights by implementers or users of this 844 specification can be obtained from the IETF on-line IPR repository at 845 http://www.ietf.org/ipr. 847 The IETF invites any interested party to bring to its attention any 848 copyrights, patents or patent applications, or other proprietary 849 rights that may cover technology that may be required to implement 850 this standard. Please address the information to the IETF at 851 ietf-ipr@ietf.org. 853 Disclaimer of Validity 855 This document and the information contained herein are provided on an 856 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 857 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 858 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 859 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 860 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 861 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 863 Copyright Statement 865 Copyright (C) The Internet Society (2005). This document is subject 866 to the rights, licenses and restrictions contained in BCP 78, and 867 except as set forth therein, the authors retain all their rights. 869 Acknowledgment 871 Funding for the RFC Editor function is currently provided by the 872 Internet Society.