idnits 2.17.1 draft-ietf-sipping-uri-list-message-01.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 747. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 724. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 731. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 737. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (October 14, 2004) is 7127 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) == Unused Reference: '2' is defined on line 652, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 694, but no explicit reference was found in the text ** 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. '6') == Outdated reference: A later version (-05) exists of draft-ietf-simple-xcap-list-usage-03 == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-00 Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 7 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: April 14, 2005 G. Camarillo 4 Ericsson 5 October 14, 2004 7 Multiple-Recipient MESSAGE Requests in the Session Initiation 8 Protocol (SIP) 9 draft-ietf-sipping-uri-list-message-01.txt 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 April 14, 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 URI-list service, which sends 47 a similar MESSAGE request to each of the URIs included in the list. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. URI-List document . . . . . . . . . . . . . . . . . . . . . 4 55 4.1 Extension to the resource lists data format . . . . . . . 5 56 4.2 URI-list example . . . . . . . . . . . . . . . . . . . . . 6 57 5. Procedures at the User Agent Client . . . . . . . . . . . . 7 58 6. Procedures at the MESSAGE URI-List Service . . . . . . . . . 8 59 6.1 Determining the intended recipient . . . . . . . . . . . . 8 60 6.2 Creating an outgoing MESSAGE request . . . . . . . . . . . 8 61 6.3 Composing bodies in the outgoing MESSAGE request . . . . . 9 62 7. Procedures at the UAS . . . . . . . . . . . . . . . . . . . 11 63 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 9. Security Considerations . . . . . . . . . . . . . . . . . . 14 65 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 66 11. Change control . . . . . . . . . . . . . . . . . . . . . . . 15 67 11.1 Changes from 68 draft-ietf-sipping-uri-list-message-00.txt . . . . . . . 15 69 11.2 Changes from 70 draft-ietf-sipping-message-exploder-00.txt to 71 draft-ietf-sipping-uri-list-message-00.txt . . . . . . . 15 72 11.3 Changes from 73 draft-garcia-simple-message-exploder-00.txt to 74 draft-garcia-sipping-message-exploder-00.txt . . . . . . 15 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 12.1 Normative References . . . . . . . . . . . . . . . . . . . 16 77 12.2 Informational References . . . . . . . . . . . . . . . . . 17 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 79 Intellectual Property and Copyright Statements . . . . . . . 18 81 1. Introduction 83 SIP [4] can carry instant messages in MESSAGE [7] requests. The 84 Advanced Instant Messaging Requirements for SIP [11] mentions the 85 need for sending a MESSAGE request to multiple recipients: 87 "REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc 88 group, where the identities of the recipients are carried in the 89 message itself." 91 One possibility to fulfill the above requirement is to establish a 92 session of instant messages with an instant messaging conference 93 server. While this option seems to be reasonable in many cases, in 94 other situations the sending user just want to send a small 95 pager-mode instant message to an ad-hoc group, without entering the 96 burden of setting up a session. This document focuses on sending a 97 pager-mode instant message to a number of intended recipients. 99 To meet the requirement with a pager-mode instant message, we allow 100 SIP MESSAGE requests carry URI-lists in 'recipient-list- body parts, 101 as specified in the framework for URI-list services [10]. A SIP 102 URI-list service, which is a specialized application service, 103 receives the request and sends a similar MESSAGE request to each of 104 the URIs in the list. Each of these MESSAGE requests contains a copy 105 of the body included in the original MESSAGE request. 107 The UAC (User Agent Client) that sends a MESSAGE request to a URI 108 list service needs to be configured with the SIP URI of the service 109 that provides the functionality. Discovering and provisioning of 110 this URI to the UAC is outside the scope of this document. 112 2. Terminology 114 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 115 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 116 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 117 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 118 compliant implementations. 120 MESSAGE URI-list service: SIP application service that receives a 121 MESSAGE request with a URI-list and sends a similar MESSAGE 122 request to each URI in the list. In this context, similar 123 indicates that some SIP header fields can change, but the MESSAGE 124 URI-list service will not change the instant message payload. 125 MESSAGE URI-list services behave effectively as specialised B2BUAs 126 (Back-To-Back-User-Agents). A server providing MESSAGE URI-list 127 services can also offer URI-list services for other methods, 128 although this functionality is outside the scope of this document. 130 In this document we only discuss MESSAGE URI-list services. 132 Incoming MESSAGE request: A SIP MESSAGE request that a UAC creates 133 and addresses to a MESSAGE URI-list service. Besides the regular 134 instant message payload, an incoming MESSAGE request contains a 135 URI-list. 137 Outgoing MESSAGE request: A SIP MESSAGE request that a MESSAGE 138 URI-list service creates and addresses to a UAS (User Agent 139 Server). It contains the regular instant message payload. 141 Intended recipient: The intended final recipient of the request to be 142 generated by MESSAGE URI-list service. 144 3. Overview 146 A UAC creates a MESSAGE request that contains a multipart body 147 including a list of URIs (intended recipients) and an instant 148 message. The UAC sends this MESSAGE request to the MESSAGE URI-List 149 service. On reception of this incoming MESSAGE request, the MESSAGE 150 URI-list service creates a MESSAGE request per intended recipient 151 (listed in the URI list) and copies the instant message payload to 152 each of those MESSAGES. Then the MESSAGE URI-list service sends each 153 of the created outgoing MESSAGE request to the respective receiver. 155 The mechanism reuses the XML format for representing resource lists 156 [8] to include the list of intended recipients. We define an 157 extension to that list to indicate the capacity of each resource, 158 which can be To, Cc or Bcc (in an analogy to e-mail). The MESSAGE 159 URI list service can include a resource list in the outgoing MESSAGE 160 request that contain those resources tagged with a To or Cc 161 capacities (and not Bcc capacities). This allows the creator of the 162 incoming MESSAGE request to identify if a resource should be 163 receiving a copy of the MESSAGE request as a capacity of recipient 164 (to), carbon copy (cc) or blind carbon copy (bcc). It also allows 165 some the intended recipients to reply to the initial sender and all 166 the visible recipients of the MESSAGE request. 168 4. URI-List document 170 As described in the framework for URI-list services [10], 171 specifications of individual URI-list services, like the MESSAGE 172 URI-list service described here, need to specify a default format for 173 'recipient-list' bodies used within the particular service. 175 The default format for recipient-list bodies for MESSAGE URI-list 176 services is the resource list document format [8] . UAs (User 177 Agents) and servers handling recipient-list bodies MUST support this 178 format and MAY support other formats. 180 Nevertheless, the Extensible Markup Language (XML) Configuration 181 Access Protocol (XCAP) resource list document provides features, such 182 as hierarchical lists and the ability to include entries by reference 183 relative to the XCAP root URI, that are not needed by the MESSAGE 184 URI-list service defined in this document, which only needs to 185 transfer a flat list of URIs between a UA and the server. Therefore, 186 when using the default resource list document, UAs SHOULD use flat 187 lists (i.e., no hierarchical lists) and SHOULD NOT use 188 elements. 190 Section 4.1 defines an extension to the XML format for representing 191 resource lists [8]. This extension allows to provide an 'capacity' 192 attribute to a resource. UAs (User Agents) and servers handling 193 'recipient-list' bodies MUST support that extension. 195 A MESSAGE URI-list service receiving a URI-list with more information 196 than what has just been described MAY discard all the extra 197 information. 199 4.1 Extension to the resource lists data format 201 An extension to indicate the capacity of a resource is included. We 202 define a new element that can take the values "to", "cc" 203 and "bcc". A "to" value indicates that the resource is considered 204 the recipient of the MESSAGE request. A "cc" value indicates that 205 the resource receives a carbon copy of the MESSAGE request. A "bcc" 206 value indicates that the resource receives a blind carbon copy of the 207 MESSAGE request. The default capacity value is "bcc", that is, the 208 absence of a element MUST be treated as if the capacity 209 was set to "bcc". 211 The element SHOULD be included as a child element of any 212 of the elements included in the element of a resource list. 214 Figure 1 describes the format of the capacity element. 215 Implementations according to this specification MUST support this XML 216 Schema. 218 219 226 227 228 Adds the capacity element to a resource list. 229 230 232 233 234 235 236 237 238 239 240 241 243 Figure 1: Extension to the resource lists data format 245 4.2 URI-list example 247 Figure 2 shows an example of a flat list that follows the resource 248 list data format. Each resource indicates the capacity of a 249 resource. 251 252 255 256 257 to 258 259 260 cc 261 262 263 bcc 264 265 266 268 Figure 2: URI-List 270 5. Procedures at the User Agent Client 272 A UAC that wants to create a multiple-recipient MESSAGE request MUST 273 create a MESSAGE request according to RFC 3428 [7] Section 4. The 274 UAC SHOULD add a body part, whose Content-Disposition type is 275 "recipient-list", which contains a URI-list with the recipients of 276 the MESSAGE. The URI-list MAY also include the "capacity" extension 277 to the URI-list specified in Section 4.1. 279 Multiple-recipient MESSAGE requests contain a multipart body that 280 contains the body carrying the list and the actual instant message 281 payload. In some cases, the MESSAGE request may contain bodies other 282 than the text and the list bodies (e.g., when the request is 283 protected with S/MIME [9]). 285 Typically, the MESSAGE URI-list service will copy all the significant 286 header fields in the outgoing MESSAGE request. However, there might 287 be cases where the SIP UA wants the MESSAGE URI-list service to add a 288 particular header field with a particular value, even if the header 289 field wasn't present in the MESSAGE request sent by the UAC. In this 290 case, the UAC MAY use the "?" mechanism described in Section 19.1.1 291 of RFC 3261 [4] to encode extra information in any URI in the list. 292 However, the UAC MUST NOT use the special "body" hname (see Section 293 19.1.1 of RFC 3261 [4]) to encode a body, since the body is present 294 in the MESSAGE request itself. 296 The following is an example of a URI that uses the "?" mechanism: 298 sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22 300 The previous URI requests the MESSAGE URI-list service to add the 301 following header field to a MESSAGE request to be sent to 302 bob@example.com: 304 Accept-Contact: *;mobility="mobile" 306 6. Procedures at the MESSAGE URI-List Service 308 On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list 309 service SHOULD answer to the UAC with a 202 Accepted response. Note 310 that the status code in the response to the MESSAGE does not provide 311 any information about whether or not the MESSAGEs generated by the 312 URI-list service were successfully delivered to the URIs in the list. 313 That is, a 202 Accepted means that the MESSAGE URI-list service has 314 received the MESSAGE and that it will try to send a similar MESSAGE 315 to the URIs in the list. Designing a mechanism to inform a client 316 about the delivery status of an instant message is outside the scope 317 of this document. 319 6.1 Determining the intended recipient 321 On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list 322 service SHOULD determine the list of intended recipients, by 323 inspecting the URI list contained in the body. In case two of those 324 URIs are equivalent (section 19.1.4 of RFC 3261 [4] defines 325 equivalent URIs), the MESSAGE URI-list SHOULD consider a single 326 intended recipient. 328 6.2 Creating an outgoing MESSAGE request 330 Since the MESSAGE URI-list behaves as a UAC for outgoing MESSAGE 331 requests, for each of the intended recipients, the MESSAGE URI-list 332 service creates a new MESSAGE request according to the procedures 333 described in Section 4 of RFC 3428 [7] and the following procedures: 335 o A MESSAGE URI-list service MUST include a From header field whose 336 value is the same as the From header field included in the 337 incoming MESSAGE request, subject to the privacy requirements (see 338 RFC 3323 [5] and RFC 3325 [6]) expressed in the incoming MESSAGE 339 request. Note that this does not apply to the "tag" parameter. 340 o A MESSAGE URI-list service SHOULD generate a new To header field 341 value set to the intended recipient URI. According to the 342 procedures of RFC 3261 Section 8.1.1.1, this value should also be 343 equal to the Request-URI of the outgoing MESSAGE request 345 o A MESSAGE URI-list service SHOULD create a new Call-ID header 346 field value. 347 o If a P-Asserted-Identity header field was present in the incoming 348 MESSAGE request and the request was received from a trusted 349 source, as specified in RFC 3325 [6], and the first hop of the 350 outgoing MESSAGE request is also trusted, a MESSAGE URI-list 351 service MUST include a P-Asserted-Identity header field in the 352 outgoing MESSAGE request with the same received value. However, 353 if the first hop of the outgoing MESSAGE request is not trusted 354 and the incoming MESSAGE request included a Privacy header field 355 with a value different than 'none', the MESSAGE URI-list service 356 MUST NOT include a P-Asserted-Identity header field in the 357 outgoing MESSAGE request. 358 o If a MESSAGE URI-list service is able to assert the identity of a 359 user (e.g., using HTTP Digest authentication scheme [3], S/MIME 360 [9], etc.) and the service implements a mechanism where it can map 361 that authentication scheme to a user's SIP or SIPS URI, and 362 subject to the privacy requirements expressed in the incoming 363 MESSAGE request (see RFC 3323 [5], the MESSAGE URI list MAY insert 364 a P-Asserted-Identity header with the value of the user's asserted 365 URI. 366 o If the incoming MESSAGE request contains an Authorization or 367 Proxy-Authorization header fields whose realm is set to the 368 MESSAGE URI-List server's realm, then the MESSAGE URI-List service 369 SHOULD NOT copy it to the outgoing MESSAGE request; otherwise 370 (i.e., if the Authorization or Proxy-Authorization header field of 371 incoming MESSAGE request contains a different realm), the MESSAGE 372 URI-List service MUST copy the value to the respective header 373 field of the outgoing MESSAGE request. 374 o A MESSAGE URI-List service SHOULD create a separate count for the 375 CSeq header field of the outgoing MESSAGE request. 376 o A MESSAGE URI-list service SHOULD initialize the value of the 377 Max-Forward header field of the outgoing MESSAGE request. 378 o A MESSAGE URI-list service MUST include its own value in the Via 379 header field. 380 o A MESSAGE URI-List service SHOULD include any other header field 381 expressed with the "?" mechanism described in Section 19.1.1 of 382 RFC 3261 [4] and encoded in the intended recipient URI of the URI 383 list. 384 o A MESSAGE URI-List service SHOULD preserve to the outgoing MESSAGE 385 request any other header field not explicitly indicated in the 386 above paragraphs. 388 6.3 Composing bodies in the outgoing MESSAGE request 390 When creating the body of each of the outgoing MESSAGE requests, the 391 MESSAGE URI-list service tries to keep the relevant bodies of the 392 incoming MESSAGE request and copies them to the outgoing MESSAGE 393 request. The following guidelines are provided: 395 o A MESSAGE request received at a MESSAGE URI-list service can 396 contain one or more security bodies (e.g., S/MIME [9]) encrypted 397 with the public key of the MESSAGE URI-list service. These bodies 398 are deemed to be read by the URI-list service rather than the 399 recipient of the outgoing MESSAGE request (which will not be able 400 to decrypt them). Therefore, a MESSAGE URI-list service MUST NOT 401 copy any security body (such as an S/MIME [9] encrypted body) 402 addressed to the MESSAGE URI-list service to the outgoing MESSAGE 403 request. This includes bodies encrypted with the public key of 404 the URI-list service. 405 o If the URI-list of the incoming MESSAGE request include resources 406 tagged with the value of "to" or "cc", the URI-list 407 service SHOULD include a URI-list in each of the outgoing MESSAGE 408 requests. The format of such list SHOULD BE according to the XML 409 format for representing resource lists [8] and the capacity 410 extension specified in Section 4.1. This resource list MUST 411 contain those elements categorized with the "to" or "cc" capacity 412 and MUST NOT contain those resources categorized are "bcc" or 413 lacking the capacity element. 414 o If a MESSAGE URI-list service includes a URI-list in an outgoing 415 MESSAGE request, it SHOULD use S/MIME [9] to encrypt the URI-list 416 with the public key of the receiver. 417 o The incoming MESSAGE request typically contains a URI-list body or 418 reference [10] with the actual list of recipients. Section 6.2 419 contains procedures that determine when the MESSAGE URI-list 420 service should include a URI-list body in the outgoing MESSAGE 421 request. 422 o The MESSAGE URI-list service SHOULD copy all the rest of the 423 message bodies (e.g., text messages, images, etc.) to the outgoing 424 MESSAGE request. 425 o If there is only one body left, the MESSAGE URI-list service MUST 426 remove the multipart/mixed wrapper in the outgoing MESSAGE 427 request. 429 The rest of the MESSAGE request corresponding to a given URI in the 430 list MUST be created following the rules in Section 19.1.5 "Forming 431 Requests from a URI" of RFC 3261 [4]. In particular, Section 19.1.5 432 of RFC 3261 [4] states: 434 "An implementation SHOULD treat the presence of any headers or body 435 parts in the URI as a desire to include them in the message, and 436 choose to honor the request on a per-component basis." 438 SIP allows to append a "method" parameter to a URI. Therefore, it is 439 legitimate that an the "uri" attribute of the "entry" element in the 440 XCAP resource list contains a "method" parameter. MESSAGE URI-list 441 services MUST generate only MESSAGE requests, regardless of the 442 "method" parameter that the URIs in the list indicate. Effectively, 443 MESSAGE URI-list services MUST ignore the "method" parameter in each 444 of the URIs present in the URI-list. 446 7. Procedures at the UAS 448 A UAS (in this specification, also known as intended recipient UAS) 449 that receives a MESSAGE request from the URI-list service behaves as 450 specified in RFC 3428 [7] Section 7. 452 If the UAS supports this specification and the MESSAGE request 453 contains a body with a Content-Disposition header set to 454 'recipient-list', then the UAS will be able to determine who are the 455 other intended recipients (visible) of the MESSAGE request. This 456 allows the user to create a reply request (e.g., MESSAGE, INVITE) to 457 the sender and the rest of the visible recipients. 459 8. Examples 461 Figure 5 shows an example of operation. A SIP UAC issuer sends a 462 MESSAGE request. The MESSAGE URI-list service answers with a 202 463 Accepted message and sends a MESSAGE request to each of the intended 464 recipients. 466 +--------+ +---------+ +--------+ +--------+ +--------+ 467 |SIP UAC | | MESSAGE | |intended| |intended| |intended| 468 | issuer | | URI-list| | recip. | | recip. | | recip. | 469 | | | service | | 1 | | 2 | | 3 | 470 +--------+ +---------+ +--------+ +--------+ +--------+ 471 | | | | | 472 | F1. MESSAGE | | | | 473 | ---------------->| | | | 474 | F2. 202 Accepted | | | | 475 |<---------------- | F3. MESSAGE | | | 476 | | ------------->| | | 477 | | F4. MESSAGE | | | 478 | | ------------------------>| | 479 | | F5. MESSAGE | | | 480 | | ----------------------------------->| 481 | | F6. 200 OK | | | 482 | |<------------- | | | 483 | | F7. 200 OK | | | 484 | |<------------------------ | | 485 | | F8. 200 OK | | | 486 | |<----------------------------------- | 487 | | | | | 488 | | | | | 489 | | | | | 491 Figure 5: Example of operation 493 The MESSAGE request F1 is as follows: 495 MESSAGE sip:list-service.example.com SIP/2.0 496 Via: SIP/2.0/TCP uac.example.com 497 ;branch=z9hG4bKhjhs8ass83 498 Max-Forwards: 70 499 To: MESSAGE URI-List Service 500 From: Carol ;tag=32331 501 Call-ID: d432fa84b4c76e66710 502 CSeq: 1 MESSAGE 503 Content-Type: multipart/mixed;boundary="boundary1" 504 Content-Length: 501 506 --boundary1 507 Content-Type: text/plain 509 Hello World! 511 --boundary1 512 Content-Type: application/resource-lists+xml 513 Content-Disposition: recipient-list 515 516 519 520 521 to 522 523 524 cc 525 526 527 bcc 528 529 530 531 --boundary1-- 533 Messages F4, F4 and F5 are similar in nature. Especially the bodies 534 are exactly the same for all of them, since they include the instant 535 message payload and a URI-list that contains the resources tagged 536 with the "to" and "cc " capacity. We show an example of F3: 538 MESSAGE sip:bill@example.com SIP/2.0 539 Via: SIP/2.0/TCP list-service.example.com 540 ;branch=z9hG4bKhjhs8as34sc 541 Max-Forwards: 70 542 To: 543 From: Carol ;tag=210342 544 Call-ID: 39s02sdsl20d9sj2l 545 CSeq: 1 MESSAGE 546 Content-Type: multipart/mixed;boundary="boundary1" 547 Content-Length: 501 549 --boundary1 550 Content-Type: text/plain 552 Hello World! 554 --boundary1 555 Content-Type: application/resource-lists+xml 556 Content-Disposition: recipient-list 558 559 562 563 564 to 565 566 567 cc 568 569 570 571 --boundary1-- 573 9. Security Considerations 575 The Framework and Security Considerations for SIP URI-List Services 576 [10] discusses issues related to SIP URI-list services. 577 Implementations of MESSAGE URI-list services MUST follow the 578 security-related rules in the framework for URI-list services [10]. 579 These rules include mandatory authentication and authorization of 580 clients, and opt-in lists. 582 If the contents of the instant message needs to be kept private, the 583 user agent client SHOULD use S/MIME [9] to prevent a third party from 584 viewing this information. In this case, the user agent client SHOULD 585 encrypt the instant message body with a content encryption key. 586 Then, for each receiver in the list, the UAC SHOULD encrypt the 587 content encryption key with the public key of the receiver, and 588 attach it to the MESSAGE request. 590 10. Acknowledgements 592 Duncan Mills supported the idea of having 1 to n MESSAGEs. Ben 593 Campbell, Paul Kyzivat, Cullen Jennings, and Jonathan Rosenberg 594 provided helpful comments. 596 11. Change control 598 11.1 Changes from draft-ietf-sipping-uri-list-message-00.txt 600 Revision of the treatment of headers the MESSAGE URI-list service, on 601 a header by header basis. 603 Added an overview section. 605 Added functionality that allows the sender of the incoming MESSAGE 606 request to tag each of the intended recipients with the "to", "cc", 607 or "bcc" capacity. If there are resources tagged as "to" or "cc", 608 the URI-list service will include a URI-list in each of the outgoing 609 MESSAGE request including those resources. 611 Procedures at the UAS included. 613 Better example including a flow. 615 11.2 Changes from draft-ietf-sipping-message-exploder-00.txt to 616 draft-ietf-sipping-uri-list-message-00.txt 618 Clarified that the MESSAGE exploder should not distribute a body that 619 has been encrypted with the public key of the exploder. The 620 exception is the URI-list, which can be distributed by the exploder, 621 providing that is encrypted with the public key of the receiver. 623 The security considerations section describes how to encrypt the list 624 and how to encrypt the instant message payload. 626 Terminology aligned with the requirements and the framework for 627 URI-list services (e.g., the term "exploder" has been deprecated). 629 11.3 Changes from draft-garcia-simple-message-exploder-00.txt to 630 draft-garcia-sipping-message-exploder-00.txt 632 The MESSAGE exploder may or may not copy the URI-list body to the 633 outgoing MESSAGE request. This allows to extend the mechanism with a 634 Reply-to-all feature. 636 It is clarified that the MESSAGE exploder must not include a list in 637 the outgoing MESSAGE requests. This avoids loops or requires a 638 MESSAGE exploder functionality in the next hop. 640 The MESSAGE exploder must remove the multipart/mixed wrapper if there 641 is only one body left in the outgoing MESSAGE request. 643 Filename changed due to focus on the SIPPING WG. 645 12. References 647 12.1 Normative References 649 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 650 Levels", BCP 14, RFC 2119, March 1997. 652 [2] Levinson, E., "Content-ID and Message-ID Uniform Resource 653 Locators", RFC 2392, August 1998. 655 [3] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 656 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 657 Basic and Digest Access Authentication", RFC 2617, June 1999. 659 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 660 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 661 Session Initiation Protocol", RFC 3261, June 2002. 663 [5] Peterson, J., "A Privacy Mechanism for the Session Initiation 664 Protocol (SIP)", RFC 3323, November 2002. 666 [6] Jennings, C., Peterson, J. and M. Watson, "Private Extensions 667 to the Session Initiation Protocol (SIP) for Asserted Identity 668 within Trusted Networks", RFC 3325, November 2002. 670 [7] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and 671 D. Gurle, "Session Initiation Protocol (SIP) Extension for 672 Instant Messaging", RFC 3428, December 2002. 674 [8] Rosenberg, J., "Extensible Markup Language (XML) Formats for 675 Representing Resource Lists", 676 draft-ietf-simple-xcap-list-usage-03 (work in progress), July 677 2004. 679 [9] Ramsdell, B., "S/MIME Version 3.1 Message Specification", 680 draft-ietf-smime-rfc2633bis-09 (work in progress), April 2004. 682 [10] Camarillo, G., "Requirements and Framework for Session 683 Initiation Protocol (SIP)Uniform Resource Identifier 684 (URI)-List Services", draft-ietf-sipping-uri-services-00 (work 685 in progress), July 2004. 687 12.2 Informational References 689 [11] Rosenberg, J., "Advanced Instant Messaging Requirements for the 690 Session Initiation Protocol (SIP)", 691 draft-rosenberg-simple-messaging-requirements-01 (work in 692 progress), February 2004. 694 [12] Peterson, J., "Session Initiation Protocol (SIP) Authenticated 695 Identity Body (AIB) Format", RFC 3893, September 2004. 697 Authors' Addresses 699 Miguel A. Garcia-Martin 700 Nokia 701 P.O.Box 407 702 NOKIA GROUP, FIN 00045 703 Finland 705 EMail: miguel.an.garcia@nokia.com 707 Gonzalo Camarillo 708 Ericsson 709 Hirsalantie 11 710 Jorvas 02420 711 Finland 713 EMail: Gonzalo.Camarillo@ericsson.com 715 Intellectual Property Statement 717 The IETF takes no position regarding the validity or scope of any 718 Intellectual Property Rights or other rights that might be claimed to 719 pertain to the implementation or use of the technology described in 720 this document or the extent to which any license under such rights 721 might or might not be available; nor does it represent that it has 722 made any independent effort to identify any such rights. Information 723 on the procedures with respect to rights in RFC documents can be 724 found in BCP 78 and BCP 79. 726 Copies of IPR disclosures made to the IETF Secretariat and any 727 assurances of licenses to be made available, or the result of an 728 attempt made to obtain a general license or permission for the use of 729 such proprietary rights by implementers or users of this 730 specification can be obtained from the IETF on-line IPR repository at 731 http://www.ietf.org/ipr. 733 The IETF invites any interested party to bring to its attention any 734 copyrights, patents or patent applications, or other proprietary 735 rights that may cover technology that may be required to implement 736 this standard. Please address the information to the IETF at 737 ietf-ipr@ietf.org. 739 Disclaimer of Validity 741 This document and the information contained herein are provided on an 742 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 743 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 744 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 745 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 746 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 747 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 749 Copyright Statement 751 Copyright (C) The Internet Society (2004). This document is subject 752 to the rights, licenses and restrictions contained in BCP 78, and 753 except as set forth therein, the authors retain all their rights. 755 Acknowledgment 757 Funding for the RFC Editor function is currently provided by the 758 Internet Society.