SIPPING Working Group M. Garcia-Martin Internet-Draft Nokia Expires: July 21, 2006 G. Camarillo Ericsson January 17, 2006 Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP) draft-ietf-sipping-uri-list-message-05.txt Status of this Memo 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies how to request a SIP URI-list service to send a copy of a MESSAGE to a set of destinations. The client sends a SIP MESSAGE request with a URI-list to the MESSAGE URI-list service, which sends a similar MESSAGE request to each of the URIs included in the list. Garcia-Martin & Camarillo Expires July 21, 2006 [Page 1] Internet-Draft MESSAGE URI-List Service January 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. URI-List document . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Extension to the resource lists data format . . . . . . . 6 4.2. URI-list example . . . . . . . . . . . . . . . . . . . . . 7 5. Option-tag . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Procedures at the User Agent Client . . . . . . . . . . . . . 8 7. Procedures at the MESSAGE URI-List Service . . . . . . . . . . 9 7.1. Determining the intended recipient . . . . . . . . . . . . 9 7.2. Creating an outgoing MESSAGE request . . . . . . . . . . . 9 7.3. Composing bodies in the outgoing MESSAGE request . . . . . 11 8. Procedures at the UAS . . . . . . . . . . . . . . . . . . . . 12 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 11.1. Disposition Type Registration . . . . . . . . . . . . . . 16 11.2. Option-Tag Registration . . . . . . . . . . . . . . . . . 16 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 13. Change control . . . . . . . . . . . . . . . . . . . . . . . . 16 13.1. Changes from draft-ietf-sipping-uri-list-message-02.txt . 17 13.2. Changes from draft-ietf-sipping-uri-list-message-01.txt . 17 13.3. Changes from draft-ietf-sipping-uri-list-message-00.txt . 17 13.4. Changes from draft-ietf-sipping-message-exploder-00.txt to draft-ietf-sipping-uri-list-message-00.txt . . . . . . . . 17 13.5. Changes from draft-garcia-simple-message-exploder-00.txt to draft-garcia-sipping-message-exploder-00.txt . . . . . . . 18 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 14.1. Normative References . . . . . . . . . . . . . . . . . . . 18 14.2. Informational References . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Garcia-Martin & Camarillo Expires July 21, 2006 [Page 2] Internet-Draft MESSAGE URI-List Service January 2006 1. Introduction SIP [5] can carry instant messages in MESSAGE [8] requests. The Advanced Instant Messaging Requirements for SIP [12] mentions the need for sending a MESSAGE request to multiple recipients: "REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc group, where the identities of the recipients are carried in the message itself." One possibility to fulfill the above requirement is to establish a session of instant messages with an instant messaging conference server. While this option seems to be reasonable in many cases, in other situations the sending user just want to send a small page-mode instant message to an ad-hoc group, without entering the burden of setting up a session. This document focuses on sending a page-mode instant message to a number of intended recipients. To meet the requirement with a page-mode instant message, we allow SIP MESSAGE requests carry URI-lists in body parts whose Content- Disposition [2] is 'recipient-list', as specified in the Framework and Security Considerations for SIP URI-List Services [11]. A SIP MESSAGE URI-list service, which is a specialized application service, receives the request and sends a similar MESSAGE request to each of the URIs in the list. Each of these MESSAGE requests contains a copy of the body included in the original MESSAGE request. The Advanced Instant Messaging Requirements for SIP [12] also includes a requirement that allows to provide a "Reply-to-All" functionality: "REQ-GROUP-4: It MUST be possible for the recipient of a group IM to send a message to all other participants that received the same group IM (i.e., Reply-To-All)." To meet this requirement, we provide a mechanism whereby the MESSAGE URI-list service can include the received URI-list along the instant message payload in each of the instant messages sent to the recipients. The UAC (User Agent Client) that sends a MESSAGE request to a MESSAGE URI-list service needs to be configured with the SIP URI of the service that provides the functionality. Discovering and provisioning of this URI to the UAC is outside the scope of this document. Garcia-Martin & Camarillo Expires July 21, 2006 [Page 3] Internet-Draft MESSAGE URI-List Service January 2006 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. MESSAGE URI-list service: SIP application service that receives a MESSAGE request with a URI-list and sends a similar MESSAGE request to each URI in the list. In this context, similar indicates that some SIP header fields can change, but the MESSAGE URI-list service will not change the instant message payload. MESSAGE URI-list services behave effectively as specialised B2BUAs (Back-To-Back-User-Agents). A server providing MESSAGE URI-list services can also offer URI-list services for other methods, although this functionality is outside the scope of this document. In this document we only discuss MESSAGE URI-list services. Incoming MESSAGE request: A SIP MESSAGE request that a UAC creates and addresses to a MESSAGE URI-list service. Besides the regular instant message payload, an incoming MESSAGE request contains a URI-list. Outgoing MESSAGE request: A SIP MESSAGE request that a MESSAGE URI- list service creates and addresses to a UAS (User Agent Server). It contains the regular instant message payload. Intended recipient: The intended final recipient of the request to be generated by MESSAGE URI-list service. 3. Overview A UAC creates a MESSAGE request that contains a multipart body including a list of URIs (intended recipients) and an instant message. The UAC sends this MESSAGE request to the MESSAGE URI-List service. On reception of this incoming MESSAGE request, the MESSAGE URI-list service creates a MESSAGE request per intended recipient (listed in the URI-list) and copies the instant message payload to each of those MESSAGES. Then the MESSAGE URI-list service sends each of the created outgoing MESSAGE request to the respective receiver. The mechanism reuses the XML format for representing resource lists [9] to include the list of intended recipients. We define an extension to that list to indicate the capacity of each resource, which can be To, Cc or Bcc (in an analogy to e-mail). The MESSAGE Garcia-Martin & Camarillo Expires July 21, 2006 [Page 4] Internet-Draft MESSAGE URI-List Service January 2006 URI-list service can include a resource list in the outgoing MESSAGE request that contain those resources tagged with a To or Cc capacities (and not Bcc capacities). This allows the creator of the incoming MESSAGE request to identify if a resource should be receiving a copy of the MESSAGE request as a capacity of recipient (to), carbon copy (cc) or blind carbon copy (bcc). It also allows some the intended recipients to reply to the initial sender and all the visible recipients of the MESSAGE request. 4. URI-List document As described in the Framework and Security Considerations for SIP URI-List Services [11], specifications of individual URI-list services, like the MESSAGE URI-list service described here, need to specify a default format for 'recipient-list' bodies used within the particular service. The default format for recipient-list bodies for MESSAGE URI-list services is the resource list document format [9] . UAs (User Agents) and servers handling recipient-list bodies MUST support this format and MAY support other formats. Nevertheless, the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resource list document provides features, such as hierarchical lists and the ability to include entries by reference relative to the XCAP root URI, that are not needed by the MESSAGE URI-list service defined in this document, which only needs to transfer a flat list of URIs between a UA and the server. Therefore, when using the default resource list document, UAs SHOULD use flat lists (i.e., no hierarchical lists) and SHOULD NOT use elements. Section 4.1 defines an extension to the XML format for representing resource lists [9]. This extension allows us to characterize a resource with a 'capacity' attribute. UACs (User Agent Clients) and MESSAGE URI-list services handling 'recipient-list' bodies MUST support 'capacity' extension. A MESSAGE URI-list service receiving a URI-list with more information than what has just been described MAY discard all the extra information. Additionally, this document defines a new mail disposition type value to be included in a Content-Disposition [2] header field of a SIP MESSAGE request. The value of this new disposition type is 'recipient-list-history' and its purpose is to indicate a list of recipients that a MESSAGE was sent to. A body whose Content- Garcia-Martin & Camarillo Expires July 21, 2006 [Page 5] Internet-Draft MESSAGE URI-List Service January 2006 Disposition type is 'recipient-list-history' contains a URI-list with the visible recipients of the MESSAGE. The element in the URI-list MAY also include a 'capacity' attribute, as specified in Section 4.1. MESSAGE URI-list services MUST implement support for this Content-Disposition type. User Agent Servers (UAS) MAY implement support for the resource-list document format [9] and the 'recipient-list-history' Content-Disposition type. 4.1. Extension to the resource lists data format This document defines an extension to indicate the capacity of a resource. We define a new 'capacity' attribute to the element. The 'capacity' attribute has similar semantics to the type of destination address in e-mail systems. It can take the values "to", "cc" and "bcc". A "to" value of the 'capacity' attribute indicates that the resource is considered the recipient of the MESSAGE request. A "cc" value indicates that the resource receives a carbon copy of the MESSAGE request. A "bcc" value indicates that the resource receives a blind carbon copy of the MESSAGE request. The default 'capacity' value is "bcc", that is, the absence of a 'capacity' attribute MUST be treated as if the 'capacity' was set to "bcc". The 'capacity' attribute SHOULD be included as a modifier of any of the child elements included in the element of a resource list (e.g., an attribute of the or elements). Figure 1 describes the format of the 'capacity' attribute. Implementations according to this specification MUST support this XML Schema. Garcia-Martin & Camarillo Expires July 21, 2006 [Page 6] Internet-Draft MESSAGE URI-List Service January 2006 Adds the capacity attribute to URIs included in a resource list. Figure 1: Extension to the resource lists data format 4.2. URI-list example Figure 2 shows an example of a flat list that follows the resource list data format. Each resource indicates the capacity of a resource. Figure 2: URI-List Garcia-Martin & Camarillo Expires July 21, 2006 [Page 7] Internet-Draft MESSAGE URI-List Service January 2006 5. Option-tag This document defines the 'recipient-list-message' option-tag for use in the Require and Supported SIP header fields. User agent clients generating a MESSAGE with a recipient-list body, as described in previous sections, MUST include this option-tag in a Require header field. User agents that are able to receive and process MESSAGEs with a recipient-list body, as described in previous sections, SHOULD include this option-tag in a Supported header field when responding to OPTIONS requests. 6. Procedures at the User Agent Client A UAC that wants to create a multiple-recipient MESSAGE request MUST create a MESSAGE request according to RFC 3428 [8] Section 4. The UAC SHOULD populate the Request-URI with the SIP or SIPS URI of the MESSAGE URI-list service. In addition to the regular instant message body, the UAC SHOULD add a URI-list body whose Content-Disposition type is 'recipient-list', specifed in the Framework and Security Considerations for SIP URI-list Services [11]. This body contains a URI-list with the recipients of the MESSAGE. The URI-list body MAY also include the 'capacity' extension to the URI-list specified in Section 4.1. The UAC MUST also include the 'recipient-list-message' option-tag, defined in Section 5, in a Require header field. Multiple-recipient MESSAGE requests contain a multipart body that contains the body carrying the list and the actual instant message payload. In some cases, the MESSAGE request may contain bodies other than the text and the list bodies (e.g., when the request is protected with S/MIME [10]). Typically, the MESSAGE URI-list service will copy all the significant header fields in the outgoing MESSAGE request. However, there might be cases where the SIP UA wants the MESSAGE URI-list service to add a particular header field with a particular value, even if the header field wasn't present in the MESSAGE request sent by the UAC. In this case, the UAC MAY use the "?" mechanism described in Section 19.1.1 of RFC 3261 [5] to encode extra information in any URI in the list. However, the UAC MUST NOT use the special "body" hname (see Section 19.1.1 of RFC 3261 [5]) to encode a body, since the body is present in the MESSAGE request itself. The following is an example of a URI that uses the "?" mechanism: sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22 Garcia-Martin & Camarillo Expires July 21, 2006 [Page 8] Internet-Draft MESSAGE URI-List Service January 2006 The previous URI requests the MESSAGE URI-list service to add the following header field to a MESSAGE request to be sent to bob@example.com: Accept-Contact: *;mobility="mobile" 7. Procedures at the MESSAGE URI-List Service On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list service SHOULD answer to the UAC with a 202 Accepted response. Note that the status code in the response to the MESSAGE does not provide any information about whether or not the MESSAGEs generated by the URI-list service were successfully delivered to the URIs in the list. That is, a 202 Accepted means that the MESSAGE URI-list service has received the MESSAGE and that it will try to send a similar MESSAGE to the URIs in the list. Designing a mechanism to inform a client about the delivery status of an instant message is outside the scope of this document. 7.1. Determining the intended recipient On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list service SHOULD determine the list of intended recipients, by inspecting the URI-list contained in the body. In case two of those URIs are equivalent (section 19.1.4 of RFC 3261 [5] defines equivalent URIs), the MESSAGE URI-list SHOULD consider a single intended recipient. 7.2. Creating an outgoing MESSAGE request Since the MESSAGE URI-list behaves as a UAC for outgoing MESSAGE requests, for each of the intended recipients, the MESSAGE URI-list service creates a new MESSAGE request according to the procedures described in Section 4 of RFC 3428 [8] and the following procedures: o A MESSAGE URI-list service MUST include a From header field whose value is the same as the From header field included in the incoming MESSAGE request, subject to the privacy requirements (see RFC 3323 [6] and RFC 3325 [7]) expressed in the incoming MESSAGE request. Note that this does not apply to the "tag" parameter. o A MESSAGE URI-list service SHOULD generate a new To header field value set to the intended recipient URI. According to the procedures of RFC 3261 Section 8.1.1.1, this value should also be equal to the Request-URI of the outgoing MESSAGE request. o A MESSAGE URI-list service SHOULD create a new Call-ID header field value. Garcia-Martin & Camarillo Expires July 21, 2006 [Page 9] Internet-Draft MESSAGE URI-List Service January 2006 o If a P-Asserted-Identity header field was present in the incoming MESSAGE request and the request was received from a trusted source, as specified in RFC 3325 [7], and the first hop of the outgoing MESSAGE request is also trusted, a MESSAGE URI-list service MUST include a P-Asserted-Identity header field in the outgoing MESSAGE request with the same received value. However, if the first hop of the outgoing MESSAGE request is not trusted and the incoming MESSAGE request included a Privacy header field with a value different than 'none', the MESSAGE URI-list service MUST NOT include a P-Asserted-Identity header field in the outgoing MESSAGE request. o If a MESSAGE URI-list service is able to assert the identity of a user (e.g., using HTTP Digest authentication scheme [3], S/MIME [10], etc.) and the service implements a mechanism where it can map that authentication scheme to a user's SIP or SIPS URI, and subject to the privacy requirements expressed in the incoming MESSAGE request (see RFC 3323 [6], the MESSAGE URI-list MAY insert a P-Asserted-Identity header with the value of the user's asserted URI. o If the incoming MESSAGE request contains an Authorization or Proxy-Authorization header fields whose realm is set to the MESSAGE URI-list server's realm, then the MESSAGE URI-list service SHOULD NOT copy it to the outgoing MESSAGE request; otherwise (i.e., if the Authorization or Proxy-Authorization header field of incoming MESSAGE request contains a different realm), the MESSAGE URI-list service MUST copy the value to the respective header field of the outgoing MESSAGE request. o A MESSAGE URI-list service SHOULD create a separate count for the CSeq header field of the outgoing MESSAGE request. o A MESSAGE URI-list service SHOULD initialize the value of the Max- Forward header field of the outgoing MESSAGE request. o A MESSAGE URI-list service MUST include its own value in the Via header field. o A MESSAGE URI-list service SHOULD include any other header field expressed with the "?" mechanism described in Section 19.1.1 of RFC 3261 [5] and encoded in the intended recipient URI of the URI- list. o A MESSAGE URI-list service SHOULD preserve to the outgoing MESSAGE request any other header field not explicitly indicated in the above paragraphs. o If the URI-list of the incoming MESSAGE request include resources tagged with the 'capacity' attribute set with a value of "to" or "cc", the URI-list service SHOULD include a URI-list in each of the outgoing MESSAGE requests. Garcia-Martin & Camarillo Expires July 21, 2006 [Page 10] Internet-Draft MESSAGE URI-List Service January 2006 7.3. Composing bodies in the outgoing MESSAGE request When creating the body of each of the outgoing MESSAGE requests, the MESSAGE URI-list service tries to keep the relevant bodies of the incoming MESSAGE request and copies them to the outgoing MESSAGE request. The following guidelines are provided: o A MESSAGE request received at a MESSAGE URI-list service can contain one or more security bodies (e.g., S/MIME [10]) encrypted with the public key of the MESSAGE URI-list service. These bodies are deemed to be read by the URI-list service rather than the recipient of the outgoing MESSAGE request (which will not be able to decrypt them). Therefore, a MESSAGE URI-list service MUST NOT copy any security body (such as an S/MIME [10] encrypted body) addressed to the MESSAGE URI-list service to the outgoing MESSAGE request. This includes bodies encrypted with the public key of the URI-list service. o The incoming MESSAGE request typically contains a URI-list body or reference [11] with the actual list of recipients. Section 7.2 contains procedures that determine when the MESSAGE URI-list service should include a URI-list body in the outgoing MESSAGE request. o If the MESSAGE URI-list service includes a URI-list in an outgoing MESSAGE request, then the list SHOULD be formatted according to the XML format for representing resource lists [9] and the capacity extension specified in Section 4.1. This resource list MUST contain those elements categorized with the "to" or "cc" capacity attribute and MUST NOT contain those resources categorized with the "bcc" or lacking the capacity attribute (the default value for the capacity of resources without a capacity attribute is "bcc"). o If the MESSAGE URI-list service includes a URI-list in an outgoing MESSAGE request, it MUST include a Content-Disposition header field [2] with the value set to 'recipient-list-history' and a 'handling' parameter [4] set to "optional". o If a MESSAGE URI-list service includes a URI-list in an outgoing MESSAGE request, it SHOULD use S/MIME [10] to encrypt the URI-list with the public key of the receiver. o The MESSAGE URI-list service SHOULD copy all the rest of the message bodies (e.g., text messages, images, etc.) to the outgoing MESSAGE request. o If there is only one body left, the MESSAGE URI-list service MUST remove the multipart/mixed wrapper in the outgoing MESSAGE request. The rest of the MESSAGE request corresponding to a given URI in the URI-list MUST be created following the rules in Section 19.1.5 "Forming Requests from a URI" of RFC 3261 [5]. In particular, Garcia-Martin & Camarillo Expires July 21, 2006 [Page 11] Internet-Draft MESSAGE URI-List Service January 2006 Section 19.1.5 of RFC 3261 [5] states: "An implementation SHOULD treat the presence of any headers or body parts in the URI as a desire to include them in the message, and choose to honor the request on a per-component basis." SIP allows to append a "method" parameter to a URI. Therefore, it is legitimate that an the 'uri' attribute of the element in the XCAP resource list contains a 'method' parameter. MESSAGE URI-list services MUST generate only MESSAGE requests, regardless of the 'method' parameter that the URIs in the list indicate. Effectively, MESSAGE URI-list services MUST ignore the 'method' parameter in each of the URIs present in the URI-list. 8. Procedures at the UAS A UAS (in this specification, also known as intended recipient UAS) that receives a MESSAGE request from the URI-list service behaves as specified in RFC 3428 [8] Section 7. If the UAS supports this specification and the MESSAGE request contains a body with a Content-Disposition header field [2] set to 'recipient-list-history', then the UAS will be able to determine who are the other intended visible recipients of the MESSAGE request. This allows the user to create a reply request (e.g., MESSAGE, INVITE) to the sender and the rest of the visible recipients. 9. Examples Figure 3 shows an example of operation. A SIP UAC issuer sends a MESSAGE request. The MESSAGE URI-list service answers with a 202 Accepted message and sends a MESSAGE request to each of the intended recipients. Garcia-Martin & Camarillo Expires July 21, 2006 [Page 12] Internet-Draft MESSAGE URI-List Service January 2006 +--------+ +---------+ +--------+ +--------+ +--------+ |SIP UAC | | MESSAGE | |intended| |intended| |intended| | issuer | | URI-list| | recip. | | recip. | | recip. | | | | service | | 1 | | 2 | | 3 | +--------+ +---------+ +--------+ +--------+ +--------+ | | | | | | F1. MESSAGE | | | | | ---------------->| | | | | F2. 202 Accepted | | | | |<---------------- | F3. MESSAGE | | | | | ------------->| | | | | F4. MESSAGE | | | | | ------------------------>| | | | F5. MESSAGE | | | | | ----------------------------------->| | | F6. 200 OK | | | | |<------------- | | | | | F7. 200 OK | | | | |<------------------------ | | | | F8. 200 OK | | | | |<----------------------------------- | | | | | | | | | | | | | | | | Figure 3: Example of operation The MESSAGE request F1 is as follows: Garcia-Martin & Camarillo Expires July 21, 2006 [Page 13] Internet-Draft MESSAGE URI-List Service January 2006 MESSAGE sip:list-service.example.com SIP/2.0 Via: SIP/2.0/TCP uac.example.com ;branch=z9hG4bKhjhs8ass83 Max-Forwards: 70 To: MESSAGE URI-list Service From: Carol ;tag=32331 Call-ID: d432fa84b4c76e66710 CSeq: 1 MESSAGE Require: recipient-list-message Content-Type: multipart/mixed;boundary="boundary1" Content-Length: 501 --boundary1 Content-Type: text/plain Hello World! --boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list --boundary1-- Messages F3, F4 and F5 are similar in nature. Especially the bodies are exactly the same for all of them, since they include the instant message payload and a URI-list that contains the resources tagged with the "to" and "cc" capacity attribute. We show an example of F3: Garcia-Martin & Camarillo Expires July 21, 2006 [Page 14] Internet-Draft MESSAGE URI-List Service January 2006 MESSAGE sip:bill@example.com SIP/2.0 Via: SIP/2.0/TCP list-service.example.com ;branch=z9hG4bKhjhs8as34sc Max-Forwards: 70 To: From: Carol ;tag=210342 Call-ID: 39s02sdsl20d9sj2l CSeq: 1 MESSAGE Content-Type: multipart/mixed;boundary="boundary1" Content-Length: 501 --boundary1 Content-Type: text/plain Hello World! --boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list-history; handling=optional --boundary1-- 10. Security Considerations The Framework and Security Considerations for SIP URI-List Services [11] discusses issues related to SIP URI-list services. Implementations of MESSAGE URI-list services MUST follow the security-related rules in the Framework and Security Considerations for SIP URI-List Services [11]. These rules include mandatory authentication and authorization of clients, and opt-in lists. If the contents of the instant message needs to be kept private, the user agent client SHOULD use S/MIME [10] to prevent a third party from viewing this information. In this case, the user agent client SHOULD encrypt the instant message body with a content encryption key. Then, for each receiver in the list, the UAC SHOULD encrypt the content encryption key with the public key of the receiver, and attach it to the MESSAGE request. Garcia-Martin & Camarillo Expires July 21, 2006 [Page 15] Internet-Draft MESSAGE URI-List Service January 2006 11. IANA Considerations The following sections instruct the IANA to register a new disposition type and a new SIP option-tag. 11.1. Disposition Type Registration Section 4 defines a new 'recipient-list-history' value of the Mail Content Disposition Values registry. This value should be registered in the IANA registry of Mail Content Disposition Values with the following registration data: +------------------------+------------------------------+-----------+ | Name | Description | Reference | +------------------------+------------------------------+-----------+ | recipient-list-history | the body contains a list of | [RFCXXXX] | | | URIs that indicates the | | | | recipients of the message | | +------------------------+------------------------------+-----------+ Table 1: Registration of the 'recipient-list-history' Mail Content Disposition Value Note to IANA and the RFC editor: replace RFCXXXX above with the RFC number of this specification. 11.2. Option-Tag Registration This document defines the 'recipient-list-message' SIP option-tag in Section 5. It should be registered in the Option Tags subregistry under the SIP parameter registry. The following is the description to be used in the registration. This option-tag is used to ensure that a server can process the 'recipient-list' body used in a MESSAGE request. 12. Acknowledgements Duncan Mills supported the idea of having 1 to n MESSAGEs. Ben Campbell, Paul Kyzivat, Cullen Jennings, and Jonathan Rosenberg provided helpful comments. 13. Change control Garcia-Martin & Camarillo Expires July 21, 2006 [Page 16] Internet-Draft MESSAGE URI-List Service January 2006 13.1. Changes from draft-ietf-sipping-uri-list-message-02.txt Typos fixed. 'recipient-list-message' option-tag defined and registered with the IANA. 13.2. Changes from draft-ietf-sipping-uri-list-message-01.txt Added a reference to missing REQ-GROUP-4 in the Advanced Instant Messaging Requirements for SIP document. Since the resource list allows now attribute extensibility, the former element has been replaced by a 'capacity' attribute, which allows a more compact representation of the URI. Added a new Content-Disposition disposition type 'recipient-list- history'. It is used in the MESSAGE request that the MESSAGE URI- list service sends to each of the recipients. This allows the UAS to differentiate it from a 'recipient-list', which has a separate meaning. 13.3. Changes from draft-ietf-sipping-uri-list-message-00.txt Revision of the treatment of headers the MESSAGE URI-list service, on a header by header basis. Added an overview section. Added functionality that allows the sender of the incoming MESSAGE request to tag each of the intended recipients with the "to", "cc", or "bcc" capacity. If there are resources tagged as "to" or "cc", the URI-list service will include a URI-list in each of the outgoing MESSAGE request including those resources. Procedures at the UAS included. Better example including a flow. 13.4. Changes from draft-ietf-sipping-message-exploder-00.txt to draft-ietf-sipping-uri-list-message-00.txt Clarified that the MESSAGE exploder should not distribute a body that has been encrypted with the public key of the exploder. The exception is the URI-list, which can be distributed by the exploder, providing that is encrypted with the public key of the receiver. The security considerations section describes how to encrypt the list Garcia-Martin & Camarillo Expires July 21, 2006 [Page 17] Internet-Draft MESSAGE URI-List Service January 2006 and how to encrypt the instant message payload. Terminology aligned with the requirements and the framework for URI- list services (e.g., the term "exploder" has been deprecated). 13.5. Changes from draft-garcia-simple-message-exploder-00.txt to draft-garcia-sipping-message-exploder-00.txt The MESSAGE exploder may or may not copy the URI-list body to the outgoing MESSAGE request. This allows to extend the mechanism with a Reply-to-all feature. It is clarified that the MESSAGE exploder must not include a list in the outgoing MESSAGE requests. This avoids loops or requires a MESSAGE exploder functionality in the next hop. The MESSAGE exploder must remove the multipart/mixed wrapper if there is only one body left in the outgoing MESSAGE request. Filename changed due to focus on the SIPPING WG. 14. References 14.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content- Disposition Header Field", RFC 2183, August 1997. [3] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [4] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001. [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [6] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. Garcia-Martin & Camarillo Expires July 21, 2006 [Page 18] Internet-Draft MESSAGE URI-List Service January 2006 [7] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [8] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [9] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", draft-ietf-simple-xcap-list-usage-05 (work in progress), February 2005. [10] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [11] Camarillo, G. and A. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services", draft-ietf-sipping-uri-services-04 (work in progress), October 2005. 14.2. Informational References [12] Rosenberg, J., "Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP)", draft-rosenberg-simple-messaging-requirements-01 (work in progress), February 2004. Authors' Addresses Miguel A. Garcia-Martin Nokia P.O.Box 407 NOKIA GROUP, FIN 00045 Finland Email: miguel.an.garcia@nokia.com Garcia-Martin & Camarillo Expires July 21, 2006 [Page 19] Internet-Draft MESSAGE URI-List Service January 2006 Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at Garcia-Martin & Camarillo Expires July 21, 2006 [Page 20] Internet-Draft MESSAGE URI-List Service January 2006 ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Garcia-Martin & Camarillo Expires July 21, 2006 [Page 21]