TOC 
SIP Working GroupM. Garcia-Martin
Internet-DraftNokia Siemens Networks
Intended status: Standards TrackG. Camarillo
Expires: June 23, 2008Ericsson
 December 21, 2007


Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)
draft-ietf-sip-uri-list-message-03.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 June 23, 2008.

Abstract

This document specifies a mechanism that allows a SIP User Agent Client (UAC) to send a SIP MESSAGE request to a set of destinations, by using a SIP URI-list (Uniform Resource Identifier list) service. The UAC sends a SIP MESSAGE request that includes the payload along with the URI list to the MESSAGE URI-list service, which sends a MESSAGE request including the payload to each of the URIs included in the list.


Table of Contents

1.  Introduction
2.  Terminology
3.  Overview
4.  URI-List document
5.  Option-tag
6.  Procedures at the User Agent Client
7.  Procedures at the MESSAGE URI-List Service
    7.1.  Determining the intended recipient
    7.2.  Creating an outgoing MESSAGE request
    7.3.  Composing bodies in the outgoing MESSAGE request
8.  Procedures at the UAS
9.  Examples
10.  Security Considerations
11.  IANA Considerations
12.  Acknowledgements
13.  References
    13.1.  Normative References
    13.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements



 TOC 

1.  Introduction

RFC 3261 (SIP) (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] is extended by "SIP Extension for Instant Messaging" (Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, “Session Initiation Protocol (SIP) Extension for Instant Messaging,” December 2002.) [RFC3428] to carry instant messages in MESSAGE requests. SIP-based messaging, as described in RFC 3428 (Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, “Session Initiation Protocol (SIP) Extension for Instant Messaging,” December 2002.) [RFC3428], does not provide a mechanism to send the same request to multiple recipients or replying to all recipients of a SIP MESSAGE request. This memo addresses these functions.

A first requirement can be expressed as:

REQ-1: It must be possible for a user to send an instant message request 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, and exchange the messages, for example, using the "Message Session Relay Protocol (MSRP)" (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.) [RFC4975]. While this option seems to be reasonable in many cases, in other situations the sending user just wants to send a small pager-mode instant message to an ad-hoc group without the burden of setting up a session. This document focuses on sending a pager-mode instant message to a number of intended recipients.

To meet the requirement with a pager-mode instant message, we allow SIP MESSAGE requests carry recipient-list bodies, i.e., URI lists in body parts whose Content-Disposition (RFC 2183) (Troost, R., Dorner, S., and K. Moore, “Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field,” August 1997.) [RFC2183] is 'recipient-list', as specified in the Framework and Security Considerations for SIP URI-List Services (Camarillo, G. and A. Roach, “Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services,” November 2007.) [I‑D.ietf‑sipping‑uri‑services]. A SIP MESSAGE URI-list service, which is a specialized application service, receives the request and sends a MESSAGE request including the received payload 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.

A second requirement addresses the "Reply-To-All" functionality:

REQ-2: It MUST be possible for the recipient of a group instant message to send a message to all other participants that received the same group instant message (i.e., Reply-To-All).

To meet this requirement, we provide a mechanism whereby the MESSAGE URI-list service also includes a URI list in body parts whose Content-Disposition (RFC 2183) (Troost, R., Dorner, S., and K. Moore, “Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field,” August 1997.) [RFC2183] is 'recipient-list-history', as specified in the "Extended Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists" (Garcia, M. and G. Camarillo, “Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists,” August 2008.) [I‑D.ietf‑sipping‑capacity‑attribute]. The 'recipient-list-history' body is sent along with the instant message payload in each of the instant messages sent to the recipients.

The User Agent Client (UAC) 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.


 TOC 

2.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119] and indicate requirement levels for compliant implementations.

This document reuses the following terminology defined in RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261]:

  • Address-of-Record (AOR)
  • User Agent (UA)
  • User Agent Client (UAC)
  • User Agent Server (UAS)

This document defines the following new terms:

MESSAGE URI-list service:
A specialized URI-list 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.
Reply-To-All:
The ability of an intended recipient to receive a MESSAGE request that includes the payload and the list of recipients, and compose a send a MESSAGE request to the sender and the rest of the recipients. The replying entity can use a MESSAGE URI-list service if one is at its disposal or can create a sequence of regular single-recipient MESSAGE requests to each SIP AOR.


 TOC 

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 list of URIs is formatted according to the resource list document format specified in RFC 4826 (Rosenberg, J., “Extensible Markup Language (XML) Formats for Representing Resource Lists,” May 2007.) [RFC4826] and extended with the attributes defined in the "XML Format Extension for Representing Copy Control Attributes in Resource Lists" (Garcia, M. and G. Camarillo, “Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists,” August 2008.) [I‑D.ietf‑sipping‑capacity‑attribute]. 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. The MESSAGE URI-list service also manipulates the XML resource list according to the procedures indicated in the "XML Format Extension for Representing Copy Control Attributes in Resource Lists" (Garcia, M. and G. Camarillo, “Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists,” August 2008.) [I‑D.ietf‑sipping‑capacity‑attribute], and attaches the result to each of the MESSAGE requests, along with the instant message payload. Then the MESSAGE URI-list service sends each of the created outgoing MESSAGE request to the respective receiver.

The MESSAGE URI-list mechanism allows a sender to specify multiple targets for a MESSAGE request by including an XML resource list document according to RFC 4826 (Rosenberg, J., “Extensible Markup Language (XML) Formats for Representing Resource Lists,” May 2007.) [RFC4826] in the body of the MESSAGE request extended with the attributes defined in the "XML Format Extension for Representing Copy Control Attributes in Resource Lists" (Garcia, M. and G. Camarillo, “Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists,” August 2008.) [I‑D.ietf‑sipping‑capacity‑attribute]. This resource list, whose Content-Disposition (RFC 2183) (Troost, R., Dorner, S., and K. Moore, “Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field,” August 1997.) [RFC2183] is 'recipient-list', as specified in the "Framework and Security Considerations for SIP URI-List Services" (Camarillo, G. and A. Roach, “Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services,” November 2007.) [I‑D.ietf‑sipping‑uri‑services], includes the URIs of the targets. Each target URI may also be marked to indicate in what role the URI-list service will place the target (e.g., "to", "cc", or "bcc"), and whether the target URI is expected to be anonymized or not, according to the procedures described in the "XML Format Extension for Representing Copy Control Attributes in Resource Lists" (Garcia, M. and G. Camarillo, “Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists,” August 2008.) [I‑D.ietf‑sipping‑capacity‑attribute]. When the MESSAGE URI-list server expands the MESSAGE request to each recipient, it includes (along with the instant message payload) a new URI list (based on the received one), whose Content-Disposition (RFC 2183) (Troost, R., Dorner, S., and K. Moore, “Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field,” August 1997.) [RFC2183] is 'recipient-list-history', as specified in the "XML Format Extension for Representing Copy Control Attributes in Resource Lists" (Garcia, M. and G. Camarillo, “Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists,” August 2008.) [I‑D.ietf‑sipping‑capacity‑attribute]. This new URI list includes the list of non-anonymous "to" and "cc" targets, allowing recipients to both get knowledge of other recipients and reply to them.


 TOC 

4.  URI-List document

As described in the "Framework and Security Considerations for SIP URI-List Services" (Camarillo, G. and A. Roach, “Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services,” November 2007.) [I‑D.ietf‑sipping‑uri‑services], 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 specified in RFC 4826 (Rosenberg, J., “Extensible Markup Language (XML) Formats for Representing Resource Lists,” May 2007.) [RFC4826] extended with the "XML Format Extension for Representing Copy Control Attributes in Resource Lists" (Garcia, M. and G. Camarillo, “Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists,” August 2008.) [I‑D.ietf‑sipping‑capacity‑attribute]. UACs and MESSAGE URI-list services handling 'recipient-list' bodies MUST support both of these formats and MAY support other formats.

As described in the "XML Format Extension for Representing Copy Control Attributes in Resource Lists" (Garcia, M. and G. Camarillo, “Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists,” August 2008.) [I‑D.ietf‑sipping‑capacity‑attribute], each URI can be tagged with a 'copyControl' attribute set to either "to", "cc", or "bcc", indicating the role in which the recipient will get the MESSAGE request. Additionally, URIs can be tagged with the 'anonymize' attribute to prevent that the MESSAGE URI-list server discloses the target URI in a URI list.

Additionally, the "XML Format Extension for Representing Copy Control Attributes in Resource Lists" (Garcia, M. and G. Camarillo, “Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists,” August 2008.) [I‑D.ietf‑sipping‑capacity‑attribute] defines a 'recipient-list-history' body that contains the list of intended recipients. The default format for 'recipient-list-history' bodies for MESSAGE URI-list services is also the resource list document specified in RFC 4826 (Rosenberg, J., “Extensible Markup Language (XML) Formats for Representing Resource Lists,” May 2007.) [RFC4826] extended with the "XML Format Extension for Representing Copy Control Attributes in Resource Lists" (Garcia, M. and G. Camarillo, “Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists,” August 2008.) [I‑D.ietf‑sipping‑capacity‑attribute]. MESSAGE URI-list services MUST support both of these formats; UASes MAY support these formats. MESSAGE URI-list servers and UASes MAY support other formats.

The resource list document specified in RFC 4826 (Rosenberg, J., “Extensible Markup Language (XML) Formats for Representing Resource Lists,” May 2007.) [RFC4826] provides a number of features that are not needed by the MESSAGE URI-list service defined in this document. The MESSAGE URI-list service needs to transfer a simple flat list of URIs between a UAC and the MESSAGE URI-list server and between the MESSAGE URI-list server and the UAS. The service does not need hierarchical lists or the ability to include entries by reference relative to the Extensible Configuration Access Protocol (XCAP) (Rosenberg, J., “The Extensible Markup Language (XML) Configuration Access Protocol (XCAP),” May 2007.) [RFC4825] root URI. Therefore, the MESSAGE URI-list service specified herein only uses flat resource lists documents that do not contain relative references.


 TOC 

5.  Option-tag

This document defines the 'recipient-list-message' option-tag for use in the Require and Supported SIP header fields.

This option-tag is used to ensure that a server can process the 'recipient-list' body used in a MESSAGE request. It also provides a mechanism to discover the capability of the server in responses to OPTIONS requests.

Section 6 (Procedures at the User Agent Client) provides normative procedures for the usage of this option tag.


 TOC 

6.  Procedures at the User Agent Client

A UAC that wants to create a multiple-recipient MESSAGE request creates a MESSAGE request that MUST be formatted according to RFC 3428 (Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, “Session Initiation Protocol (SIP) Extension for Instant Messaging,” December 2002.) [RFC3428] Section 4. The UAC populates 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 adds a recipient-list body whose Content-Disposition type is 'recipient-list', specified in the "Framework and Security Considerations for SIP URI-List Services" (Camarillo, G. and A. Roach, “Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services,” November 2007.) [I‑D.ietf‑sipping‑uri‑services]. This body contains a URI list with the recipients of the MESSAGE. Target URIs in this body MAY also be tagged with the 'copyControl' and 'anonymize' attributes specified in the "XML Format Extension for Representing Copy Control Attributes in Resource Lists" (Garcia, M. and G. Camarillo, “Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists,” August 2008.) [I‑D.ietf‑sipping‑capacity‑attribute]. The UAC MUST also include the 'recipient-list-message' option-tag, defined in Section 5 (Option-tag), in a Require header field.

UACs generating MESSAGE request that carry recipient-list bodies, as described in previous sections, MUST include this option-tag in a Require header field. UAs 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.

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 can contain bodies other than the text and the list bodies (e.g., when the request is protected with S/MIME as per RFC 3851 (Ramsdell, B., “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification,” July 2004.) [RFC3851]).

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 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] 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 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261]) 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

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"

The resource list document format specified in RFC 4826 (Rosenberg, J., “Extensible Markup Language (XML) Formats for Representing Resource Lists,” May 2007.) [RFC4826] provides features, such as hierarchical lists and the ability to include entries by reference relative to the XCAP root URI. However, these features are not needed by the multiple MESSAGE URI-list service defined in this document. Therefore, when using the default resource list document, UAs SHOULD use flat lists (i.e., no hierarchical lists) and SHOULD NOT use <entry-ref> elements.


 TOC 

7.  Procedures at the MESSAGE URI-List Service

On reception of a MESSAGE request containing a URI list, the MESSAGE URI-list service answers 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) response 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.

Since the MESSAGE URI-list service does not use hierarchical lists nor lists that include entries by reference to the XCAP root URI, a MESSAGE URI-list server receiving a URI list with more information than what has just been described MAY discard all the extra information.

If a MESSAGE request contains a Request-URI containing a URI that uses the "?" mechanism (see Section 19.1.1 of RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261]) and such URI contains the special "body" hname to include an additional body, the MESSAGE URI-list server MAY discard the contents of the "body" parameter.


 TOC 

7.1.  Determining the intended recipient

On reception of a MESSAGE request containing a URI list, a MESSAGE URI-list service determines the list of intended recipients by inspecting the URI list contained in the body.

Section 4.1 of the "Framework and Security Considerations for SIP URI-List Services" (Camarillo, G. and A. Roach, “Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services,” November 2007.) [I‑D.ietf‑sipping‑uri‑services] discusses cases when duplicated URIs are found in a URI list. In order to avoid duplicated requests, MESSAGE URI-list services MUST take those actions specified in "Framework and Security Considerations for SIP URI-List Services" (Camarillo, G. and A. Roach, “Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services,” November 2007.) [I‑D.ietf‑sipping‑uri‑services] into account to avoid sending duplicated request to the same recipient.


 TOC 

7.2.  Creating an outgoing MESSAGE request

Since the MESSAGE URI-list service 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 (Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, “Session Initiation Protocol (SIP) Extension for Instant Messaging,” December 2002.) [RFC3428]. Additionally, Section 5.3 of the "Framework and Security Considerations for SIP URI-List Services" (Camarillo, G. and A. Roach, “Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services,” November 2007.) [I‑D.ietf‑sipping‑uri‑services] provides additional general guidance in creating outgoing requests. This document also specifies the following procedures:


 TOC 

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 keeps the relevant bodies of the incoming MESSAGE request and copies them to the outgoing MESSAGE request. The following guidelines constitute exceptions to the general body handling:

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 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261]. In particular, Section 19.1.5 of RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] 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 <entry> element in the XML 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.


 TOC 

8.  Procedures at the UAS

A UAS (in this specification, also known as intended recipient UAS) that receives a MESSAGE request from the MESSAGE URI-list service behaves as specified in RFC 3428 (Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, “Session Initiation Protocol (SIP) Extension for Instant Messaging,” December 2002.) [RFC3428] Section 7.

If the UAS supports this specification and the MESSAGE request contains a body with a Content-Disposition header field as per RFC 2183 (Troost, R., Dorner, S., and K. Moore, “Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field,” August 1997.) [RFC2183] set to 'recipient-list-history', then the UAS will be able to determine the SIP Address-of-Record (AOR) of the other intended 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 recipients included in the URI list.


 TOC 

9.  Examples

Figure 1 (Example of operation) shows an example of operation. A SIP UAC issuer sends a MESSAGE request. The MESSAGE URI-list service answers with a 202 (Accepted) response and sends a MESSAGE request to each of the intended recipients. 


+--------+        +---------+      +--------+ +--------+ +--------+
|SIP UAC |        | MESSAGE |      |intended| |intended| |intended|
| issuer |        | URI-list|      | recip. | | recip. | | recip. |
|        |        | service |      |   1    | |   2    | |   n    |
+--------+        +---------+      +--------+ +--------+ +--------+
    |                  |               |          |          |
    | F1. MESSAGE      |               |          |          |
    | ---------------->|               |          |          |
    | F2. 202 Accepted |               |          |          |
    |<---------------- |  F3. MESSAGE  |          |          |
    |                  | ------------->|          |          |
    |                  |  F4. MESSAGE  |          |          |
    |                  | ------------------------>|          |
    |                  |  F5. MESSAGE  |          |          |
    |                  | ----------------------------------->|
    |                  |  F6. 200 OK   |          |          |
    |                  |<------------- |          |          |
    |                  |  F7. 200 OK   |          |          |
    |                  |<------------------------ |          |
    |                  |  F8. 200 OK   |          |          |
    |                  |<----------------------------------- |
    |                  |               |          |          |
    |                  |               |          |          |
    |                  |               |          |          |
 Figure 1: Example of operation 

The MESSAGE request F1 (shown in Figure 2 (MESSAGE request received at the MESSAGE URI-list server)) contains a multipart/mixed body that is composed of two bodies: a text/plain body containing the instant message payload and an application/resource-lists+xml body containing the list of recipients. 


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 <sip:list-service.example.com>
From: Alice <sip:alice@example.com>;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

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
          xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
  <list>
    <entry uri="sip:bill@example.com" cp:copyControl="to" />
    <entry uri="sip:randy@example.net" cp:copyControl="to"
                                       cp:anonymize="true"/>
    <entry uri="sip:eddy@example.com" cp:copyControl="to"
                                      cp:anonymize="true"/>
    <entry uri="sip:joe@example.org" cp:copyControl="cc" />
    <entry uri="sip:carol@example.net" cp:copyControl="cc"
                                       cp:anonymize="true"/>
    <entry uri="sip:ted@example.net" cp:copyControl="bcc" />
    <entry uri="sip:andy@example.com" cp:copyControl="bcc" />
  </list>
</resource-lists>
--boundary1--
 Figure 2: MESSAGE request received at the MESSAGE URI-list server 

The MESSAGE requests F3, F4 and F5 are similar in nature. All those MESSAGE requests contain a multipart/mixed body which is composed of two other bodies: a text/plain body containing the instant message payload and an application/resource-lists+xml containing the list of recipients. Unlike the text/plain body the application/resource-lists+xml body is not equal to the application/resource-lists+xml included in the incoming MESSAGE request F1, because the URI-list service has anonymized those URIs tagged with the 'anonymize' attribute and has removed those URIs tagged with a "bcc" 'copyControl' attribute. Figure 3 (MESSAGE request sent by the MESSAGE URI-list server) shows an examples of the message F3. 


MESSAGE sip:bill@example.com SIP/2.0
Via: SIP/2.0/TCP list-service.example.com
    ;branch=z9hG4bKhjhs8as34sc
Max-Forwards: 70
To: <sip:bill@example.com>
From: Alice <sip:alice@example.com>;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

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
          xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
  <list>
    <entry uri="sip:bill@example.com" cp:copyControl="to" />
    <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to"
                                                 cp:count="2"/>
    <entry uri="sip:joe@example.org" cp:copyControl="cc" />
    <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc"
                                                 cp:count="1"/>
  </list>
</resource-lists>
--boundary1--
 Figure 3: MESSAGE request sent by the MESSAGE URI-list server 

 TOC 

10.  Security Considerations

The "Framework and Security Considerations for SIP URI-List Services" (Camarillo, G. and A. Roach, “Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services,” November 2007.) [I‑D.ietf‑sipping‑uri‑services] 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" (Camarillo, G. and A. Roach, “Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services,” November 2007.) [I‑D.ietf‑sipping‑uri‑services]. 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 as per RFC 3851 (Ramsdell, B., “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification,” July 2004.) [RFC3851] 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.


 TOC 

11.  IANA Considerations

This document defines the SIP option tag 'recipient-list-message'

The following row shall be added to the "Option Tags" section of the SIP Parameter Registry:


NameDescriptionReference
recipient-list-message The body contains a list of URIs that indicates the recipients of the SIP MESSAGE request [RFCXXXX]

 Table 1: Registration of the 'recipient-list-message' Option-Tag in SIP 

Note to IANA and the RFC editor: replace RFCXXXX above with the RFC number of this specification.


 TOC 

12.  Acknowledgements

Duncan Mills supported the idea of having 1 to n MESSAGEs. Ben Campbell, Paul Kyzivat, Cullen Jennings, Jonathan Rosenberg, Dean Willis, and Keith Drage provided helpful comments.


 TOC 

13.  References


 TOC 

13.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2183] Troost, R., Dorner, S., and K. Moore, “Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field,” RFC 2183, August 1997 (TXT, HTML, XML).
[RFC2617] 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 (TXT, HTML, XML).
[RFC3204] 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 (TXT).
[RFC3261] 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 (TXT).
[RFC3323] Peterson, J., “A Privacy Mechanism for the Session Initiation Protocol (SIP),” RFC 3323, November 2002 (TXT).
[RFC3325] 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 (TXT).
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, “Session Initiation Protocol (SIP) Extension for Instant Messaging,” RFC 3428, December 2002 (TXT).
[RFC3851] Ramsdell, B., “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification,” RFC 3851, July 2004 (TXT).
[RFC4826] Rosenberg, J., “Extensible Markup Language (XML) Formats for Representing Resource Lists,” RFC 4826, May 2007 (TXT).
[I-D.ietf-sipping-uri-services] 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-07 (work in progress), November 2007 (TXT).
[I-D.ietf-sipping-capacity-attribute] Garcia, M. and G. Camarillo, “Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists,” draft-ietf-sipping-capacity-attribute-07 (work in progress), August 2008 (TXT).

 TOC 

13.2. Informative References

[RFC4825] Rosenberg, J., “The Extensible Markup Language (XML) Configuration Access Protocol (XCAP),” RFC 4825, May 2007 (TXT).
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” RFC 4975, September 2007 (TXT).

 TOC 

Authors' Addresses

  Miguel A. Garcia-Martin
  Nokia Siemens Networks
  P.O.Box 6
  Nokia Siemens Networks, FIN 02022
  Finland
Email:  miguel.garcia@nsn.com
  
  Gonzalo Camarillo
  Ericsson
  Hirsalantie 11
  Jorvas 02420
  Finland
Email:  Gonzalo.Camarillo@ericsson.com

 TOC 

Full Copyright Statement

Copyright © The IETF Trust (2007).

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, THE IETF TRUST 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 ietf-ipr@ietf.org.