SIPPING Working Group                                   M. Garcia-Martin
Internet-Draft                                                     Nokia
Expires: January 5, April 14, 2005                                     G. Camarillo
                                                                Ericsson
                                                            July 7,
                                                        October 14, 2004

     Multiple-Recipient MESSAGE Requests in the Session Initiation
                             Protocol (SIP)
               draft-ietf-sipping-uri-list-message-00.txt
               draft-ietf-sipping-uri-list-message-01.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, I certify each
   author represents that any applicable patent or other IPR claims of
   which I am he or she is aware have been or will be disclosed, and any of
   which I he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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.
   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 January 5, April 14, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

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 URI-list service, which sends
   a similar MESSAGE request to each of the URIs included in the list.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Procedures at the UAC   Overview . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.   URI-List document  . . . . . . . . . . . . . . . . . . . . .   4
     4.1  Extension to the resource lists data format  . . . . . . .   5
     4.2  URI-list example . . . . . . . . . . . . . . . . . . . . .   6
   5.   Procedures at the User Agent Client  . . . . . . . . . . . .   7
   6.   Procedures at the MESSAGE URI-List Service . . . . . . . . .   8
     6.1  Determining the intended recipient . . .  5
   5.  Examples . . . . . . . . .   8
     6.2  Creating an outgoing MESSAGE request . . . . . . . . . . .   8
     6.3  Composing bodies in the outgoing MESSAGE request . . . . .   9
   7.   Procedures at the UAS  . . . . . . . . . . . . . .  6
   6. . . . . .  11
   8.   Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   9.   Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  14
   10.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  15
   11.  Change control . . . . . . . . . . . . . . . . . . . . . . .  15
     11.1   Changes from
            draft-ietf-sipping-uri-list-message-00.txt . . .  8
     8.1 . . . .  15
     11.2   Changes from draft--sipping-message-exploder-00.txt
            draft-ietf-sipping-message-exploder-00.txt to
            draft-ietf-sipping-uri-list-message-00.txt . . . . . . . .  8
     8.2  15
     11.3   Changes from
            draft-garcia-simple-message-exploder-00.txt to
            draft-garcia-sipping-message-exploder-00.txt . . . . . . .  9
   9.  15
   12.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   9.1  16
   12.1   Normative References . . . . . . . . . . . . . . . . . . . .  9
   9.2  16
   12.2   Informational References . . . . . . . . . . . . . . . . . . 10  17
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10  17
        Intellectual Property and Copyright Statements . . . . . . . . 11  18

1.  Introduction

   SIP [2] [4] can carry instant messages in MESSAGE [3] [7] requests.  The
   Advanced Instant Messaging Requirements for SIP [8] [11] mentions the
   need for sending a MESSAGE request to multiple receipients: 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."

   To meet this requirement, we allow SIP MESSAGE requests carry
   URI-lists in "uri-list" body parts, as specified in [4]. A SIP
   URI-list service, which

   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
   pager-mode instant message to an ad-hoc group, without entering 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 URI-lists in 'recipient-list- body parts,
   as specified in the framework for URI-list services [10].  A SIP
   URI-list service, which is a specialized application server, 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 UAC (User Agent Client) that sends a MESSAGE request to a URI
   list service needs to be configured with the SIP URI of the application server service
   that provides the functionality.  Discovering and provisioning of
   this URI to the UAC is outside the scope of this document.

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

   MESSAGE URI-list service': service: SIP application server 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
   service
      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

   Incoming MESSAGE request': 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

   Outgoing MESSAGE request': 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.

3.  Procedures at

   Intended recipient: The intended final recipient of the UAC

   A client that wants request to create be
      generated by MESSAGE URI-list service.

3.  Overview

   A UAC creates a multiple-recipient MESSAGE request
   adds a body part, whose disposition type is "uri-list", which that contains a URI-list with the recipients of the MESSAGE.

   Multiple-recipient MESSAGE requests typically contain a multipart body that contains the body carrying the
   including a list of URIs (intended recipients) and the actual an instant
   message payload. In some cases, the
   message.  The UAC sends this MESSAGE request may contain
   bodies other than the text and the list bodies (e.g., when to the
   request is protected with S/MIME [6]).

   Typically, MESSAGE URI-List
   service.  On reception of this incoming MESSAGE request, the MESSAGE
   URI-list service will copy all the significant
   header fields creates a MESSAGE request per intended recipient
   (listed in the outgoing MESSAGE request. However, there might
   be cases where URI list) and copies the SIP UA wants instant message payload to
   each of those MESSAGES.  Then the MESSAGE URI-list service sends each
   of the created outgoing MESSAGE request to add the respective receiver.

   The mechanism reuses the XML format for representing resource lists
   [8] 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
   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 for URI-list services [10],
   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 [8] .  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 <entry-ref>
   elements.

   Section 4.1 defines an extension to the XML format for representing
   resource lists [8].  This extension allows to provide an 'capacity'
   attribute to a resource.  UAs (User Agents) and servers handling
   'recipient-list' bodies MUST support that 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.

4.1  Extension to the resource lists data format

   An extension to indicate the capacity of a resource is included.  We
   define a new <capacity> element that can take the values "to", "cc"
   and "bcc".  A "to" value 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> element MUST be treated as if the capacity
   was set to "bcc".

   The <capacity> element SHOULD be included as a child element of any
   of the elements included in the <list> element of a resource list.

   Figure 1 describes the format of the capacity element.
   Implementations according to this specification MUST support this XML
   Schema.

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:capacity"
       xmlns="urn:ietf:params:xml:ns:capacity"
       xmlns:rls="urn:ietf:params:xml:ns:resource-lists"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       elementFormDefault="qualified"
       attributeFormDefault="unqualified">

       <xs:annotation>
         <xs:documentation xml:lang="en">
            Adds the capacity element to a resource list.
         </xs:documentation>
       </xs:annotation>

       <xs:element name="capacity">
          <xs:simpleType>
             <xs:restriction base="xs:string">
                <xs:enumeration value="to"/>
                <xs:enumeration value="cc"/>
                <xs:enumeration value="bcc"/>
             </xs:restriction>
          </xs:simpleType>
       </xs:element>
   </xs:schema>

         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.

   <?xml version="1.0" encoding="UTF-8"?>
   <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
             xmlns:cp="urn:ietf:params:xml:ns:capacity"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <list>
       <entry uri="sip:bill@example.com">
          <cp:capacity>to</cp:capacity>
       </entry>
       <entry uri="sip:joe@example.org">
          <cp:capacity>cc</cp:capacity>
       </entry>
       <entry uri="sip:ted@example.net">
          <cp:capacity>bcc</cp:capacity>
       </entry>
     </list>
   </resource-lists>

                           Figure 2: URI-List

5.  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 [7] Section 4.  The
   UAC SHOULD add a body part, whose Content-Disposition type is
   "recipient-list", which contains a URI-list with the recipients of
   the MESSAGE.  The URI-list MAY also include the "capacity" extension
   to the URI-list specified in Section 4.1.

   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 [9]).

   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 [4] 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 [4]) 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"

6.  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.

6.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 [4] defines
   equivalent URIs), the MESSAGE URI-list SHOULD consider a single
   intended recipient.

6.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 [7] and the following procedures:

   o  A MESSAGE URI-list service MUST include a
   particular From header field with a particular value, even if whose
      value is the same as the From header field wasn't present included in the
      incoming MESSAGE request sent by the UAC. In this
   case, the UAC MAY use request, subject to the "?" mechanism described in Section 19.1.1
   of privacy requirements (see
      RFC 3261 [2] to encode extra information in any URI 3323 [5] and RFC 3325 [6]) expressed in the list.
   However, incoming MESSAGE
      request.  Note that this does not apply to the UAC MUST NOT use "tag" parameter.
   o  A MESSAGE URI-list service SHOULD generate a new To header field
      value set to the special "body" hname (see Section
   19.1.1 intended recipient URI.  According to the
      procedures of RFC 3261 [2]) Section 8.1.1.1, this value should also be
      equal to encode a body, since the body is Request-URI of the outgoing MESSAGE request
   o  A MESSAGE URI-list service SHOULD create a new Call-ID header
      field value.
   o  If a P-Asserted-Identity header field was present in the incoming
      MESSAGE request itself.

   The following is an example of and the request was received from a URI that uses trusted
      source, as specified in RFC 3325 [6], and the "?" mechanism:

   sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22

   The previous URI requests first hop of the
      outgoing MESSAGE request is also trusted, a MESSAGE URI-list
      service to add the
   following MUST include a P-Asserted-Identity header field to a in the
      outgoing MESSAGE request to be sent to
   bob@example.com:

   Accept-Contact: *;mobility="mobile"

   As described in [4], with the default format for URI-lists in SIP is same received value.  However,
      if the
   XCAP resource list format [5]. Still, specific services need to
   describe which information clients should include in their URI lists,
   as described in [4]

   UAs generating multiple recipient MESSAGEs SHOULD use flat lists
   (i.e., no hierarchical lists), SHOULD NOT use any entry's attributes
   but "uri", first hop of the outgoing MESSAGE request is not trusted
      and SHOULD NOT include any elements inside entries but
   "display-name" elements.

   A the incoming MESSAGE URI-list service receiving request included a URI-list Privacy header field
      with more information a value different than what we have just described SHOULD discard all the extra
   information.

4.  Procedures at 'none', the MESSAGE URI-List Service

   On reception of URI-list service
      MUST NOT include a P-Asserted-Identity header field in the
      outgoing MESSAGE request with a URI-list, request.
   o  If a MESSAGE URI-list service SHOULD answer is able to assert the UAC with identity of a 202 Accepted response. Note
      user (e.g., using HTTP Digest authentication scheme [3], S/MIME
      [9], 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 status code privacy requirements expressed in the response to incoming
      MESSAGE request (see RFC 3323 [5], the MESSAGE does not provide
   any information about whether 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 not
      Proxy-Authorization header fields whose realm is set to the MESSAGEs generated by
      MESSAGE URI-List server's realm, then the
   URI-list MESSAGE URI-List service were successfully delivered
      SHOULD NOT copy it to the URIs in outgoing MESSAGE request; otherwise
      (i.e., if the list.
   That is, Authorization or Proxy-Authorization header field of
      incoming MESSAGE request contains a 202 Accepted means that different realm), the MESSAGE URI-list
      URI-List service has
   received MUST copy the MESSAGE and that it will try to send a similar MESSAGE value to the URIs in respective header
      field of the list. Designing a mechanism to inform outgoing MESSAGE request.
   o  A MESSAGE URI-List service SHOULD create a client
   about separate count for the delivery status
      CSeq header field of an instant message is outside the scope outgoing MESSAGE request.
   o  A MESSAGE URI-list service SHOULD initialize the value of this document.

   On reception the
      Max-Forward header field of a the outgoing MESSAGE request with a URI-list, a request.
   o  A MESSAGE URI-list service MUST include its own value in the Via
      header field.
   o  A MESSAGE URI-list URI-List service SHOULD create as many new MESSAGE requests as URIs include any other header field
      expressed with the list
   contains, except when two of those URIs are equivalent (section
   19.1.4 "?" mechanism described in Section 19.1.1 of
      RFC 3261 [2] defines equivalent URIs), [4] and encoded in which case the intended recipient URI of the URI
      list.
   o  A MESSAGE URI-list URI-List service SHOULD create only one preserve to the outgoing MESSAGE
      request any other header field not explicitly indicated in the
      above paragraphs.

6.3  Composing bodies in the outgoing MESSAGE request per URI.

   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  The incoming MESSAGE request typically contains a URI-list body
      [4] with the actual list of recipients. The MESSAGE URI-list
      service need not copy the URI-list body to each of the outgoing
      MESSAGE requests, although it MAY do it.
      NOTE: This document does not provide any semantics associated to a
         URI-list body included in an outgoing MESSAGE request. Future
         extensions may indicate actions at a UAS when it receives that
         body.
   o  A MESSAGE request received at a MESSAGE URI-list service can
      contain one or more security bodies (e.g., S/MIME [9]) 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 [9] 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  An exception to this rule is  If the URI-list itself: as mentioned of the incoming MESSAGE request include resources
      tagged with the <capacity> value of "to" or "cc", the URI-list
      service SHOULD include a URI-list in each of the outgoing MESSAGE
      requests.  The format of such list SHOULD BE according to the XML
      format for representing resource lists [8] and the capacity
      extension specified in Section 4, 4.1.  This resource list MUST
      contain those elements categorized with the "to" or "cc" capacity
      and MUST NOT contain those resources categorized are "bcc" or
      lacking the capacity element.
   o  If a MESSAGE URI-list service need not, but MAY, copy includes a URI-list in an outgoing
      MESSAGE request, it SHOULD use S/MIME [9] to encrypt the URI-list into each
      with the public key of the outgoing receiver.
   o  The incoming MESSAGE requests; on doing so, request typically contains a URI-list body or
      reference [10] with the actual list of recipients.  Section 6.2
      contains procedures that determine when the MESSAGE URI-list
      service SHOULD use S/MIME [6] to encrypt the should include a URI-list with the public key of body in the receiver. outgoing MESSAGE
      request.
   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
   list MUST be created following the rules in Section 19.1.5 "Forming
   Requests from a URI" of RFC 3261 [2]. [4].  In particular, Section 19.1.5
   of RFC 3261 [2] [4] 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
   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.

   It is RECOMMENDED that the MESSAGE URI-list service copies the From
   header field of the incoming MESSAGE into URI-list.

7.  Procedures at the outgoing MESSAGE
   requests (note that UAS

   A UAS (in this does not apply to the "tag" parameter). The
   MESSAGE URI-list service SHOULD specification, also copy into the outgoing known as intended recipient UAS)
   that receives a MESSAGE request any P-Asserted-Identity header fields present from the URI-list service behaves as
   specified in RFC 3428 [7] Section 7.

   If the incoming
   MESSAGE request.

   For each given outgoing MESSAGE request, UAS supports this specification and the MESSAGE URI-list service
   SHOULD generate request
   contains a new To body with a Content-Disposition header field value which, according set to
   'recipient-list', then the
   procedures of RFC 3261 Section 8.1.1.1, should UAS will be equal able to determine who are the
   Request-URI
   other intended recipients (visible) of the outgoing MESSAGE request.

   For each given outgoing MESSAGE request,  This
   allows the MESSAGE URI-list service
   SHOULD initialize user to create a reply request (e.g., MESSAGE, INVITE) to
   the values sender and the rest of the Call-ID, CSeq and Max-Forwards
   header fields. visible recipients.

8.  Examples

   Figure 5 shows an example of operation.  A SIP UAC issuer sends a
   MESSAGE request.  The MESSAGE URI-list service should also include its
   own value in answers with a 202
   Accepted message and sends a MESSAGE request to each of the Via header field.

5.  Examples

   The following is an example intended
   recipients.

   +--------+        +---------+      +--------+ +--------+ +--------+
   |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 5: Example of an incoming operation

   The MESSAGE request which
   carries a URI list in its body. F1 is as follows:

   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: Carol <sip:carol@example.com>;tag=32331
   Call-ID: d432fa84b4c76e66710
   CSeq: 1 MESSAGE
   Content-Type: multipart/mixed;boundary="boundary1"
   Content-Length: 440 501

   --boundary1
   Content-Type: text/plain

   Hello World!

   --boundary1
   Content-Type: application/resource-lists+xml
   Content-Disposition: uri-list 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:capacity"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <list>
       <entry uri="sip:bill@example.com" /> uri="sip:bill@example.com">
          <cp:capacity>to</cp:capacity>
       </entry>
       <entry uri="sip:joe@example.org" /> uri="sip:joe@example.org">
          <cp:capacity>cc</cp:capacity>
       </entry>
       <entry uri="sip:ted@example.net" /> uri="sip:ted@example.net">
          <cp:capacity>bcc</cp:capacity>
       </entry>
     </list>
   </resource-lists>
   --boundary1--

         Figure 3: Multiple recipient incoming MESSAGE request

   The following is

   Messages F4, 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.  We show an example of one of the outgoing MESSAGE requests
   that the MESSAGE URI-list service creates. 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: Carol <sip:carol@uac.example.com>;tag=210342
   Call-ID: 39s02sdsl20d9sj2l
   CSeq: 1 MESSAGE
   Content-Type: text/plain multipart/mixed;boundary="boundary1"
   Content-Length: 13 501

   --boundary1
   Content-Type: text/plain

   Hello World!

                   Figure 4: Outgoing MESSAGE request

6.

   --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:capacity"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <list>
       <entry uri="sip:bill@example.com">
          <cp:capacity>to</cp:capacity>
       </entry>
       <entry uri="sip:joe@example.org">
          <cp:capacity>cc</cp:capacity>
       </entry>
     </list>
   </resource-lists>
   --boundary1--

9.  Security Considerations

   The Framework and Security Considerations Section of the Requirements and Framework for SIP URI-List Services [7]
   [10] discusses issues related to SIP URI-list services.
   Implementations of MESSAGE URI-list services MUST follow the
   security-related rules in [7]. the framework for URI-list services [10].
   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 [6] [9] 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.

7.

10.  Acknowledgements

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

8.

11.  Change control

8.1

11.1  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.

11.2  Changes from draft--sipping-message-exploder-00.txt 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, 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
   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).

8.2

11.3  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 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.

9.

12.  References

9.1

12.1  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Levinson, E., "Content-ID and Message-ID Uniform Resource
         Locators", RFC 2392, August 1998.

   [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]   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.

   [3]

   [5]   Peterson, J., "A Privacy Mechanism for the Session Initiation
         Protocol (SIP)", RFC 3323, November 2002.

   [6]   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.

   [7]   Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and
         D. Gurle, "Session Initiation Protocol (SIP) Extension for
         Instant Messaging", RFC 3428, December 2002.

   [4]  Camarillo, G., "Providing a Session Initiation Protocol (SIP)
        Application Server with a  List of URIs",
        draft-camarillo-sipping-uri-list-01 (work in progress), February
        2004.

   [5]

   [8]   Rosenberg, J., "An Extensible "Extensible Markup Language (XML)
        Configuration Access Protocol (XCAP)  Usage Formats for Presence
         Representing Resource Lists",
        draft-ietf-simple-xcap-list-usage-02
         draft-ietf-simple-xcap-list-usage-03 (work in progress),
        February July
         2004.

   [6]

   [9]   Ramsdell, B., "S/MIME Version 3.1 Message Specification",
        draft-ietf-smime-rfc2633bis-07
         draft-ietf-smime-rfc2633bis-09 (work in progress), February April 2004.

   [7]

   [10]  Camarillo, G., "Requirements and Framework for Session
         Initiation Protocol
        (SIP) Exploder Invocation", draft-camarillo-sipping-exploders-02 (SIP)Uniform  Resource Identifier
         (URI)-List Services", draft-ietf-sipping-uri-services-00 (work
         in progress), February July 2004.

9.2

12.2  Informational References

   [8]

   [11]  Rosenberg, J., "Advanced Instant Messaging Requirements for the
         Session Initiation Protocol  (SIP)",
         draft-rosenberg-simple-messaging-requirements-01 (work in
         progress), February 2004.

   [9]

   [12]  Peterson, J., "SIP "Session Initiation Protocol (SIP) Authenticated
         Identity Body (AIB) Format",
         draft-ietf-sip-authid-body-02 (work in progress), July 2003.

   [10]  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. 3893, September 2004.

Authors' Addresses

   Miguel A. Garcia-Martin
   Nokia
   P.O.Box 407
   NOKIA GROUP, FIN  00045
   Finland

   EMail: miguel.an.garcia@nokia.com

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com

Intellectual Property Statement

   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 IETF's procedures with respect to rights in IETF Documents 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.

Disclaimer of Validity

   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.

Copyright Statement

   Copyright (C) The Internet Society (2004).  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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.