idnits 2.17.1 draft-ietf-sipping-uri-list-message-02.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 810. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (November 30, 2004) is 7086 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 612 == Unused Reference: '3' is defined on line 721, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 767, 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 (-05) exists of draft-ietf-simple-xcap-list-usage-04 == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-01 Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING Working Group M. Garcia-Martin 2 Internet-Draft Nokia 3 Expires: May 31, 2005 G. Camarillo 4 Ericsson 5 November 30, 2004 7 Multiple-Recipient MESSAGE Requests in the Session Initiation 8 Protocol (SIP) 9 draft-ietf-sipping-uri-list-message-02 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 31, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 This document specifies how to request a SIP URI-list service to send 45 a copy of a MESSAGE to a set of destinations. The client sends a SIP 46 MESSAGE request with a URI-list to the MESSAGE URI-list service, 47 which sends a similar MESSAGE request to each of the URIs included in 48 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 4.1 Extension to the resource lists data format . . . . . . . 6 57 4.2 URI-list example . . . . . . . . . . . . . . . . . . . . . 7 58 5. Procedures at the User Agent Client . . . . . . . . . . . . 8 59 6. Procedures at the MESSAGE URI-List Service . . . . . . . . . 9 60 6.1 Determining the intended recipient . . . . . . . . . . . . 9 61 6.2 Creating an outgoing MESSAGE request . . . . . . . . . . . 9 62 6.3 Composing bodies in the outgoing MESSAGE request . . . . . 10 63 7. Procedures at the UAS . . . . . . . . . . . . . . . . . . . 12 64 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 66 10. Security Considerations . . . . . . . . . . . . . . . . . . 16 67 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 68 12. Change control . . . . . . . . . . . . . . . . . . . . . . . 16 69 12.1 Changes from 70 draft-ietf-sipping-uri-list-message-01.txt . . . . . . . 16 71 12.2 Changes from 72 draft-ietf-sipping-uri-list-message-00.txt . . . . . . . 17 73 12.3 Changes from 74 draft-ietf-sipping-message-exploder-00.txt to 75 draft-ietf-sipping-uri-list-message-00.txt . . . . . . . 17 76 12.4 Changes from 77 draft-garcia-simple-message-exploder-00.txt to 78 draft-garcia-sipping-message-exploder-00.txt . . . . . . 17 79 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 13.1 Normative References . . . . . . . . . . . . . . . . . . . 18 81 13.2 Informational References . . . . . . . . . . . . . . . . . 19 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 83 Intellectual Property and Copyright Statements . . . . . . . 20 85 1. Introduction 87 SIP [6] can carry instant messages in MESSAGE [9] requests. The 88 Advanced Instant Messaging Requirements for SIP [13] mentions the 89 need for sending a MESSAGE request to multiple recipients: 91 "REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc 92 group, where the identities of the recipients are carried in the 93 message itself." 95 One possibility to fulfill the above requirement is to establish a 96 session of instant messages with an instant messaging conference 97 server. While this option seems to be reasonable in many cases, in 98 other situations the sending user just want to send a small 99 pager-mode instant message to an ad-hoc group, without entering the 100 burden of setting up a session. This document focuses on sending a 101 pager-mode instant message to a number of intended recipients. 103 To meet the requirement with a pager-mode instant message, we allow 104 SIP MESSAGE requests carry URI-lists in body parts whose 105 Content-Disposition [2] is 'recipient-list', as specified in 106 Framework and Security Considerations for SIP URI-List Services [12]. 107 A SIP MESSAGE URI-list service, which is a specialized application 108 service, receives the request and sends a similar MESSAGE request to 109 each of the URIs in the list. Each of these MESSAGE requests 110 contains a copy of the body included in the original MESSAGE request. 112 The Advanced Instant Messaging Requirements for SIP [13] also 113 includes a requirement that allows to provide a "Reply-to-All" 114 functionality: 116 "REQ-GROUP-4: It MUST be possible for the recipient of a group IM 117 to send a message to all other participants that received the same 118 group IM (i.e., Reply-To-All)." 120 To meet this requirement, we provide a mechanism whereby the MESSAGE 121 URI-list service can include the received URI-list along the instant 122 message payload in each of the instant messages sent to the 123 recipients. 125 The UAC (User Agent Client) that sends a MESSAGE request to a MESSAGE 126 URI-list service needs to be configured with the SIP URI of the 127 service that provides the functionality. Discovering and 128 provisioning of this URI to the UAC is outside the scope of this 129 document. 131 2. Terminology 133 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 134 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 135 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 136 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 137 compliant implementations. 139 MESSAGE URI-list service: SIP application service that receives a 140 MESSAGE request with a URI-list and sends a similar MESSAGE 141 request to each URI in the list. In this context, similar 142 indicates that some SIP header fields can change, but the MESSAGE 143 URI-list service will not change the instant message payload. 144 MESSAGE URI-list services behave effectively as specialised B2BUAs 145 (Back-To-Back-User-Agents). A server providing MESSAGE URI-list 146 services can also offer URI-list services for other methods, 147 although this functionality is outside the scope of this document. 148 In this document we only discuss MESSAGE URI-list services. 150 Incoming MESSAGE request: A SIP MESSAGE request that a UAC creates 151 and addresses to a MESSAGE URI-list service. Besides the regular 152 instant message payload, an incoming MESSAGE request contains a 153 URI-list. 155 Outgoing MESSAGE request: A SIP MESSAGE request that a MESSAGE 156 URI-list service creates and addresses to a UAS (User Agent 157 Server). It contains the regular instant message payload. 159 Intended recipient: The intended final recipient of the request to be 160 generated by MESSAGE URI-list service. 162 3. Overview 164 A UAC creates a MESSAGE request that contains a multipart body 165 including a list of URIs (intended recipients) and an instant 166 message. The UAC sends this MESSAGE request to the MESSAGE URI-List 167 service. On reception of this incoming MESSAGE request, the MESSAGE 168 URI-list service creates a MESSAGE request per intended recipient 169 (listed in the URI-list) and copies the instant message payload to 170 each of those MESSAGES. Then the MESSAGE URI-list service sends each 171 of the created outgoing MESSAGE request to the respective receiver. 173 The mechanism reuses the XML format for representing resource lists 174 [10] to include the list of intended recipients. We define an 175 extension to that list to indicate the capacity of each resource, 176 which can be To, Cc or Bcc (in an analogy to e-mail). The MESSAGE 177 URI-list service can include a resource list in the outgoing MESSAGE 178 request that contain those resources tagged with a To or Cc 179 capacities (and not Bcc capacities). This allows the creator of the 180 incoming MESSAGE request to identify if a resource should be 181 receiving a copy of the MESSAGE request as a capacity of recipient 182 (to), carbon copy (cc) or blind carbon copy (bcc). It also allows 183 some the intended recipients to reply to the initial sender and all 184 the visible recipients of the MESSAGE request. 186 4. URI-List document 188 As described in the Framework and Security Considerations for SIP 189 URI-List Services [12], specifications of individual URI-list 190 services, like the MESSAGE URI-list service described here, need to 191 specify a default format for 'recipient-list' bodies used within the 192 particular service. 194 The default format for recipient-list bodies for MESSAGE URI-list 195 services is the resource list document format [10] . UAs (User 196 Agents) and servers handling recipient-list bodies MUST support this 197 format and MAY support other formats. 199 Nevertheless, the Extensible Markup Language (XML) Configuration 200 Access Protocol (XCAP) resource list document provides features, such 201 as hierarchical lists and the ability to include entries by reference 202 relative to the XCAP root URI, that are not needed by the MESSAGE 203 URI-list service defined in this document, which only needs to 204 transfer a flat list of URIs between a UA and the server. Therefore, 205 when using the default resource list document, UAs SHOULD use flat 206 lists (i.e., no hierarchical lists) and SHOULD NOT use 207 elements. 209 Section 4.1 defines an extension to the XML format for representing 210 resource lists [10]. This extension allows us to characterize a 211 resource with a 'capacity' attribute. UACs (User Agent Clients) and 212 MESSAGE URI-list services handling 'recipient-list' bodies MUST 213 support 'capacity' extension. 215 A MESSAGE URI-list service receiving a URI-list with more information 216 than what has just been described MAY discard all the extra 217 information. 219 Additionally, this document defines a new mail disposition type value 220 to be included in a Content-Disposition [2] header field of a SIP 221 MESSAGE request. The value of this new disposition type is 222 'recipient-list-history' and its purpose is to indicate a list of 223 recipients that a MESSAGE was sent to. A body whose 224 Content-Disposition type is 'recipient-list-history' contains a 225 URI-list with the visible recipients of the MESSAGE. The 226 element in the URI-list MAY also include a 'capacity' attribute, as 227 specified in Section 4.1. MESSAGE URI-list services MUST implement 228 support for this Content-Disposition type. User Agent Servers (UAS) 229 MAY implement support for the resource-list document format [10] and 230 the 'recipient-list-history' Content-Disposition type. 232 4.1 Extension to the resource lists data format 234 This document defines an extension to indicate the capacity of a 235 resource. We define a new 'capacity' attribute to the 236 element. The 'capacity' attribute has similar semantics to the type 237 of destination address in e-mail systems. It can take the values 238 "to", "cc" and "bcc". A "to" value of the 'capacity' attribute 239 indicates that the resource is considered the recipient of the 240 MESSAGE request. A "cc" value indicates that the resource receives a 241 carbon copy of the MESSAGE request. A "bcc" value indicates that the 242 resource receives a blind carbon copy of the MESSAGE request. The 243 default 'capacity' value is "bcc", that is, the absence of a 244 'capacity' attribute MUST be treated as if the 'capacity' was set to 245 "bcc". 247 The 'capacity' attribute SHOULD be included as a modifier of any of 248 the child elements included in the element of a resource list 249 (e.g., an attribute of the or elements). 251 Figure 1 describes the format of the 'capacity' attribute. 252 Implementations according to this specification MUST support this XML 253 Schema. 255 256 263 264 265 Adds the capacity attribute to URIs included 266 in a resource list. 267 268 270 271 272 273 274 275 276 277 278 279 281 Figure 1: Extension to the resource lists data format 283 4.2 URI-list example 285 Figure 2 shows an example of a flat list that follows the resource 286 list data format. Each resource indicates the capacity of a 287 resource. 289 290 293 294 295 296 297 298 300 Figure 2: URI-List 302 5. Procedures at the User Agent Client 304 A UAC that wants to create a multiple-recipient MESSAGE request MUST 305 create a MESSAGE request according to RFC 3428 [9] Section 4. The 306 UAC SHOULD populate the Request-URI with the SIP or SIPS URI of the 307 MESSAGE URI-list service. In addition to the regular instant message 308 body, the UAC SHOULD add a URI-list body whose Content-Disposition 309 type is 'recipient-list', specifed in the Framework and Security 310 Considerations for SIP URI-list Services [12]. This body contains a 311 URI-list with the recipients of the MESSAGE. The URI-list body MAY 312 also include the 'capacity' extension to the URI-list specified in 313 Section 4.1. 315 Multiple-recipient MESSAGE requests contain a multipart body that 316 contains the body carrying the list and the actual instant message 317 payload. In some cases, the MESSAGE request may contain bodies other 318 than the text and the list bodies (e.g., when the request is 319 protected with S/MIME [11]). 321 Typically, the MESSAGE URI-list service will copy all the significant 322 header fields in the outgoing MESSAGE request. However, there might 323 be cases where the SIP UA wants the MESSAGE URI-list service to add a 324 particular header field with a particular value, even if the header 325 field wasn't present in the MESSAGE request sent by the UAC. In this 326 case, the UAC MAY use the "?" mechanism described in Section 19.1.1 327 of RFC 3261 [6] to encode extra information in any URI in the list. 328 However, the UAC MUST NOT use the special "body" hname (see Section 329 19.1.1 of RFC 3261 [6]) to encode a body, since the body is present 330 in the MESSAGE request itself. 332 The following is an example of a URI that uses the "?" mechanism: 334 sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22 335 The previous URI requests the MESSAGE URI-list service to add the 336 following header field to a MESSAGE request to be sent to 337 bob@example.com: 339 Accept-Contact: *;mobility="mobile" 341 6. Procedures at the MESSAGE URI-List Service 343 On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list 344 service SHOULD answer to the UAC with a 202 Accepted response. Note 345 that the status code in the response to the MESSAGE does not provide 346 any information about whether or not the MESSAGEs generated by the 347 URI-list service were successfully delivered to the URIs in the list. 348 That is, a 202 Accepted means that the MESSAGE URI-list service has 349 received the MESSAGE and that it will try to send a similar MESSAGE 350 to the URIs in the list. Designing a mechanism to inform a client 351 about the delivery status of an instant message is outside the scope 352 of this document. 354 6.1 Determining the intended recipient 356 On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list 357 service SHOULD determine the list of intended recipients, by 358 inspecting the URI-list contained in the body. In case two of those 359 URIs are equivalent (section 19.1.4 of RFC 3261 [6] defines 360 equivalent URIs), the MESSAGE URI-list SHOULD consider a single 361 intended recipient. 363 6.2 Creating an outgoing MESSAGE request 365 Since the MESSAGE URI-list behaves as a UAC for outgoing MESSAGE 366 requests, for each of the intended recipients, the MESSAGE URI-list 367 service creates a new MESSAGE request according to the procedures 368 described in Section 4 of RFC 3428 [9] and the following procedures: 370 o A MESSAGE URI-list service MUST include a From header field whose 371 value is the same as the From header field included in the 372 incoming MESSAGE request, subject to the privacy requirements (see 373 RFC 3323 [7] and RFC 3325 [8]) expressed in the incoming MESSAGE 374 request. Note that this does not apply to the "tag" parameter. 375 o A MESSAGE URI-list service SHOULD generate a new To header field 376 value set to the intended recipient URI. According to the 377 procedures of RFC 3261 Section 8.1.1.1, this value should also be 378 equal to the Request-URI of the outgoing MESSAGE request. 379 o A MESSAGE URI-list service SHOULD create a new Call-ID header 380 field value. 382 o If a P-Asserted-Identity header field was present in the incoming 383 MESSAGE request and the request was received from a trusted 384 source, as specified in RFC 3325 [8], and the first hop of the 385 outgoing MESSAGE request is also trusted, a MESSAGE URI-list 386 service MUST include a P-Asserted-Identity header field in the 387 outgoing MESSAGE request with the same received value. However, 388 if the first hop of the outgoing MESSAGE request is not trusted 389 and the incoming MESSAGE request included a Privacy header field 390 with a value different than 'none', the MESSAGE URI-list service 391 MUST NOT include a P-Asserted-Identity header field in the 392 outgoing MESSAGE request. 393 o If a MESSAGE URI-list service is able to assert the identity of a 394 user (e.g., using HTTP Digest authentication scheme [4], S/MIME 395 [11], etc.) and the service implements a mechanism where it can 396 map that authentication scheme to a user's SIP or SIPS URI, and 397 subject to the privacy requirements expressed in the incoming 398 MESSAGE request (see RFC 3323 [7], the MESSAGE URI-list MAY insert 399 a P-Asserted-Identity header with the value of the user's asserted 400 URI. 401 o If the incoming MESSAGE request contains an Authorization or 402 Proxy-Authorization header fields whose realm is set to the 403 MESSAGE URI-list server's realm, then the MESSAGE URI-list service 404 SHOULD NOT copy it to the outgoing MESSAGE request; otherwise 405 (i.e., if the Authorization or Proxy-Authorization header field of 406 incoming MESSAGE request contains a different realm), the MESSAGE 407 URI-list service MUST copy the value to the respective header 408 field of the outgoing MESSAGE request. 409 o A MESSAGE URI-list service SHOULD create a separate count for the 410 CSeq header field of the outgoing MESSAGE request. 411 o A MESSAGE URI-list service SHOULD initialize the value of the 412 Max-Forward header field of the outgoing MESSAGE request. 413 o A MESSAGE URI-list service MUST include its own value in the Via 414 header field. 415 o A MESSAGE URI-list service SHOULD include any other header field 416 expressed with the "?" mechanism described in Section 19.1.1 of 417 RFC 3261 [6] and encoded in the intended recipient URI of the 418 URI-list. 419 o A MESSAGE URI-list service SHOULD preserve to the outgoing MESSAGE 420 request any other header field not explicitly indicated in the 421 above paragraphs. 423 6.3 Composing bodies in the outgoing MESSAGE request 425 When creating the body of each of the outgoing MESSAGE requests, the 426 MESSAGE URI-list service tries to keep the relevant bodies of the 427 incoming MESSAGE request and copies them to the outgoing MESSAGE 428 request. The following guidelines are provided: 430 o A MESSAGE request received at a MESSAGE URI-list service can 431 contain one or more security bodies (e.g., S/MIME [11]) encrypted 432 with the public key of the MESSAGE URI-list service. These bodies 433 are deemed to be read by the URI-list service rather than the 434 recipient of the outgoing MESSAGE request (which will not be able 435 to decrypt them). Therefore, a MESSAGE URI-list service MUST NOT 436 copy any security body (such as an S/MIME [11] encrypted body) 437 addressed to the MESSAGE URI-list service to the outgoing MESSAGE 438 request. This includes bodies encrypted with the public key of 439 the URI-list service. 440 o If the URI-list of the incoming MESSAGE request include resources 441 tagged with the 'capacity' attribute set with a value of "to" or 442 "cc", the URI-list service SHOULD include a URI-list in each of 443 the outgoing MESSAGE requests. The format of such list SHOULD BE 444 according to the XML format for representing resource lists [10] 445 and the capacity extension specified in Section 4.1. This 446 resource list MUST contain those elements categorized with the 447 "to" or "cc" capacity attribute and MUST NOT contain those 448 resources categorized with the "bcc" or lacking the capacity 449 attribute. 450 o If the MESSAGE URI-list service includes a URI-list in an outgoing 451 MESSAGE request, it MUST include a Content-Disposition header 452 field [2] with the value set to 'recipient-list-history' and a 453 'handling' parameter [5] set to "optional". 454 o If a MESSAGE URI-list service includes a URI-list in an outgoing 455 MESSAGE request, it SHOULD use S/MIME [11] to encrypt the URI-list 456 with the public key of the receiver. 457 o The incoming MESSAGE request typically contains a URI-list body or 458 reference [12] with the actual list of recipients. Section 6.2 459 contains procedures that determine when the MESSAGE URI-list 460 service should include a URI-list body in the outgoing MESSAGE 461 request. 462 o The MESSAGE URI-list service SHOULD copy all the rest of the 463 message bodies (e.g., text messages, images, etc.) to the outgoing 464 MESSAGE request. 465 o If there is only one body left, the MESSAGE URI-list service MUST 466 remove the multipart/mixed wrapper in the outgoing MESSAGE 467 request. 469 The rest of the MESSAGE request corresponding to a given URI in the 470 URI-list MUST be created following the rules in Section 19.1.5 471 "Forming Requests from a URI" of RFC 3261 [6]. In particular, 472 Section 19.1.5 of RFC 3261 [6] states: 474 "An implementation SHOULD treat the presence of any headers or body 475 parts in the URI as a desire to include them in the message, and 476 choose to honor the request on a per-component basis." 477 SIP allows to append a "method" parameter to a URI. Therefore, it is 478 legitimate that an the 'uri' attribute of the element in the 479 XCAP resource list contains a 'method' parameter. MESSAGE URI-list 480 services MUST generate only MESSAGE requests, regardless of the 481 'method' parameter that the URIs in the list indicate. Effectively, 482 MESSAGE URI-list services MUST ignore the 'method' parameter in each 483 of the URIs present in the URI-list. 485 7. Procedures at the UAS 487 A UAS (in this specification, also known as intended recipient UAS) 488 that receives a MESSAGE request from the URI-list service behaves as 489 specified in RFC 3428 [9] Section 7. 491 If the UAS supports this specification and the MESSAGE request 492 contains a body with a Content-Disposition header field [2] set to 493 'recipient-list-history', then the UAS will be able to determine who 494 are the other intended visible recipients of the MESSAGE request. 495 This allows the user to create a reply request (e.g., MESSAGE, 496 INVITE) to the sender and the rest of the visible recipients. 498 8. Examples 500 Figure 5 shows an example of operation. A SIP UAC issuer sends a 501 MESSAGE request. The MESSAGE URI-list service answers with a 202 502 Accepted message and sends a MESSAGE request to each of the intended 503 recipients. 505 +--------+ +---------+ +--------+ +--------+ +--------+ 506 |SIP UAC | | MESSAGE | |intended| |intended| |intended| 507 | issuer | | URI-list| | recip. | | recip. | | recip. | 508 | | | service | | 1 | | 2 | | 3 | 509 +--------+ +---------+ +--------+ +--------+ +--------+ 510 | | | | | 511 | F1. MESSAGE | | | | 512 | ---------------->| | | | 513 | F2. 202 Accepted | | | | 514 |<---------------- | F3. MESSAGE | | | 515 | | ------------->| | | 516 | | F4. MESSAGE | | | 517 | | ------------------------>| | 518 | | F5. MESSAGE | | | 519 | | ----------------------------------->| 520 | | F6. 200 OK | | | 521 | |<------------- | | | 522 | | F7. 200 OK | | | 523 | |<------------------------ | | 524 | | F8. 200 OK | | | 525 | |<----------------------------------- | 526 | | | | | 527 | | | | | 528 | | | | | 530 Figure 5: Example of operation 532 The MESSAGE request F1 is as follows: 534 MESSAGE sip:list-service.example.com SIP/2.0 535 Via: SIP/2.0/TCP uac.example.com 536 ;branch=z9hG4bKhjhs8ass83 537 Max-Forwards: 70 538 To: MESSAGE URI-list Service 539 From: Carol ;tag=32331 540 Call-ID: d432fa84b4c76e66710 541 CSeq: 1 MESSAGE 542 Content-Type: multipart/mixed;boundary="boundary1" 543 Content-Length: 501 545 --boundary1 546 Content-Type: text/plain 548 Hello World! 550 --boundary1 551 Content-Type: application/resource-lists+xml 552 Content-Disposition: recipient-list 554 555 558 559 560 562 563 564 --boundary1-- 566 Messages F4, F4 and F5 are similar in nature. Especially the bodies 567 are exactly the same for all of them, since they include the instant 568 message payload and a URI-list that contains the resources tagged 569 with the "to" and "cc" capacity attribute. We show an example of F3: 571 MESSAGE sip:bill@example.com SIP/2.0 572 Via: SIP/2.0/TCP list-service.example.com 573 ;branch=z9hG4bKhjhs8as34sc 574 Max-Forwards: 70 575 To: 576 From: Carol ;tag=210342 577 Call-ID: 39s02sdsl20d9sj2l 578 CSeq: 1 MESSAGE 579 Content-Type: multipart/mixed;boundary="boundary1" 580 Content-Length: 501 582 --boundary1 583 Content-Type: text/plain 585 Hello World! 587 --boundary1 588 Content-Type: application/resource-lists+xml 589 Content-Disposition: recipient-list-history; handling=optional 591 592 595 596 597 598 599 600 --boundary1-- 602 9. IANA Considerations 604 Section 4 defines a new 'recipient-list-history' value of the Mail 605 Content Disposition Values registry. This value should be registered 606 in the IANA registry of Mail Content Disposition Values with the 607 following registration data: 609 +------------------------+------------------------------+-----------+ 610 | Name | Description | Reference | 611 +------------------------+------------------------------+-----------+ 612 | recipient-list-history | the body contains a list of | [RFCXXXX] | 613 | | URIs that indicates the | | 614 | | recipients of the message | | 615 +------------------------+------------------------------+-----------+ 617 Table 1: Registration of the 'recipient-list-history' Mail Content 618 Disposition Value 620 Note to IANA and the RFC editor: replace RFCXXXX above with the RFC 621 number of this specification. 623 10. Security Considerations 625 The Framework and Security Considerations for SIP URI-List Services 626 [12] discusses issues related to SIP URI-list services. 627 Implementations of MESSAGE URI-list services MUST follow the 628 security-related rules in the Framework and Security Considerations 629 for SIP URI-List Services [12]. These rules include mandatory 630 authentication and authorization of clients, and opt-in lists. 632 If the contents of the instant message needs to be kept private, the 633 user agent client SHOULD use S/MIME [11] to prevent a third party 634 from viewing this information. In this case, the user agent client 635 SHOULD encrypt the instant message body with a content encryption 636 key. Then, for each receiver in the list, the UAC SHOULD encrypt the 637 content encryption key with the public key of the receiver, and 638 attach it to the MESSAGE request. 640 11. Acknowledgements 642 Duncan Mills supported the idea of having 1 to n MESSAGEs. Ben 643 Campbell, Paul Kyzivat, Cullen Jennings, and Jonathan Rosenberg 644 provided helpful comments. 646 12. Change control 648 12.1 Changes from draft-ietf-sipping-uri-list-message-01.txt 650 Added a reference to missing REQ-GROUP-4 in the Advanced Instant 651 Messaging Requirements for SIP document. 653 Since the resource list allows now attribute extensibility, the 654 former element has been replaced by a 'capacity' 655 attribute, which allows a more compact representation of the URI. 657 Added a new Content-Disposition disposition type 658 'recipient-list-history'. It is used in the MESSAGE request that the 659 MESSAGE URI-list service sends to each of the recipients. This 660 allows the UAS to differentiate it from a 'recipient-list', which has 661 a separate meaning. 663 12.2 Changes from draft-ietf-sipping-uri-list-message-00.txt 665 Revision of the treatment of headers the MESSAGE URI-list service, on 666 a header by header basis. 668 Added an overview section. 670 Added functionality that allows the sender of the incoming MESSAGE 671 request to tag each of the intended recipients with the "to", "cc", 672 or "bcc" capacity. If there are resources tagged as "to" or "cc", 673 the URI-list service will include a URI-list in each of the outgoing 674 MESSAGE request including those resources. 676 Procedures at the UAS included. 678 Better example including a flow. 680 12.3 Changes from draft-ietf-sipping-message-exploder-00.txt to 681 draft-ietf-sipping-uri-list-message-00.txt 683 Clarified that the MESSAGE exploder should not distribute a body that 684 has been encrypted with the public key of the exploder. The 685 exception is the URI-list, which can be distributed by the exploder, 686 providing that is encrypted with the public key of the receiver. 688 The security considerations section describes how to encrypt the list 689 and how to encrypt the instant message payload. 691 Terminology aligned with the requirements and the framework for 692 URI-list services (e.g., the term "exploder" has been deprecated). 694 12.4 Changes from draft-garcia-simple-message-exploder-00.txt to 695 draft-garcia-sipping-message-exploder-00.txt 697 The MESSAGE exploder may or may not copy the URI-list body to the 698 outgoing MESSAGE request. This allows to extend the mechanism with a 699 Reply-to-all feature. 701 It is clarified that the MESSAGE exploder must not include a list in 702 the outgoing MESSAGE requests. This avoids loops or requires a 703 MESSAGE exploder functionality in the next hop. 705 The MESSAGE exploder must remove the multipart/mixed wrapper if there 706 is only one body left in the outgoing MESSAGE request. 708 Filename changed due to focus on the SIPPING WG. 710 13. References 712 13.1 Normative References 714 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 715 Levels", BCP 14, RFC 2119, March 1997. 717 [2] Troost, R., Dorner, S. and K. Moore, "Communicating 718 Presentation Information in Internet Messages: The 719 Content-Disposition Header Field", RFC 2183, August 1997. 721 [3] Levinson, E., "Content-ID and Message-ID Uniform Resource 722 Locators", RFC 2392, August 1998. 724 [4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 725 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 726 Basic and Digest Access Authentication", RFC 2617, June 1999. 728 [5] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., 729 Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG 730 Objects", RFC 3204, December 2001. 732 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 733 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 734 Session Initiation Protocol", RFC 3261, June 2002. 736 [7] Peterson, J., "A Privacy Mechanism for the Session Initiation 737 Protocol (SIP)", RFC 3323, November 2002. 739 [8] Jennings, C., Peterson, J. and M. Watson, "Private Extensions 740 to the Session Initiation Protocol (SIP) for Asserted Identity 741 within Trusted Networks", RFC 3325, November 2002. 743 [9] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and 744 D. Gurle, "Session Initiation Protocol (SIP) Extension for 745 Instant Messaging", RFC 3428, December 2002. 747 [10] Rosenberg, J., "Extensible Markup Language (XML) Formats for 748 Representing Resource Lists", 749 draft-ietf-simple-xcap-list-usage-04 (work in progress), 750 October 2004. 752 [11] Ramsdell, B., "S/MIME Version 3.1 Message Specification", 753 draft-ietf-smime-rfc2633bis-09 (work in progress), April 2004. 755 [12] Camarillo, G., "Requirements and Framework for Session 756 Initiation Protocol (SIP)Uniform Resource Identifier 757 (URI)-List Services", draft-ietf-sipping-uri-services-01 (work 758 in progress), October 2004. 760 13.2 Informational References 762 [13] Rosenberg, J., "Advanced Instant Messaging Requirements for the 763 Session Initiation Protocol (SIP)", 764 draft-rosenberg-simple-messaging-requirements-01 (work in 765 progress), February 2004. 767 [14] Peterson, J., "Session Initiation Protocol (SIP) Authenticated 768 Identity Body (AIB) Format", RFC 3893, September 2004. 770 Authors' Addresses 772 Miguel A. Garcia-Martin 773 Nokia 774 P.O.Box 407 775 NOKIA GROUP, FIN 00045 776 Finland 778 EMail: miguel.an.garcia@nokia.com 780 Gonzalo Camarillo 781 Ericsson 782 Hirsalantie 11 783 Jorvas 02420 784 Finland 786 EMail: Gonzalo.Camarillo@ericsson.com 788 Intellectual Property Statement 790 The IETF takes no position regarding the validity or scope of any 791 Intellectual Property Rights or other rights that might be claimed to 792 pertain to the implementation or use of the technology described in 793 this document or the extent to which any license under such rights 794 might or might not be available; nor does it represent that it has 795 made any independent effort to identify any such rights. Information 796 on the procedures with respect to rights in RFC documents can be 797 found in BCP 78 and BCP 79. 799 Copies of IPR disclosures made to the IETF Secretariat and any 800 assurances of licenses to be made available, or the result of an 801 attempt made to obtain a general license or permission for the use of 802 such proprietary rights by implementers or users of this 803 specification can be obtained from the IETF on-line IPR repository at 804 http://www.ietf.org/ipr. 806 The IETF invites any interested party to bring to its attention any 807 copyrights, patents or patent applications, or other proprietary 808 rights that may cover technology that may be required to implement 809 this standard. Please address the information to the IETF at 810 ietf-ipr@ietf.org. 812 Disclaimer of Validity 814 This document and the information contained herein are provided on an 815 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 816 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 817 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 818 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 819 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 820 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 822 Copyright Statement 824 Copyright (C) The Internet Society (2004). This document is subject 825 to the rights, licenses and restrictions contained in BCP 78, and 826 except as set forth therein, the authors retain all their rights. 828 Acknowledgment 830 Funding for the RFC Editor function is currently provided by the 831 Internet Society.