[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
SIPPING Working Group                                   M. Garcia-Martin
Internet-Draft                                                     Nokia
Expires: September 28, 2004                                 G. Camarillo
                                                                Ericsson
                                                          March 30, 2004


     Multiple recipient MESSAGE requests in the Session Initiation
                             Protocol (SIP)
              draft-garcia-simple-message-exploder-00.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3667.

   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 September 28, 2004.

Copyright Notice

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

Abstract

   This document specifies how to request a MESSAGE exploder 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 exploder, which sends
   a similar MESSAGE request to each of URIs included in the list.







Garcia-Martin & Camarillo    Expires September 28, 2004         [Page 1]


Internet-Draft             MESSAGE exploders                  March 2004


Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2. Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3. Procedures at the UAC  . . . . . . . . . . . . . . . . . . . .   3
   4. Procedures at the MESSAGE Exploder . . . . . . . . . . . . . .   4
   5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6. Security Considerations  . . . . . . . . . . . . . . . . . . .   7
   7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .   8
      Normative References . . . . . . . . . . . . . . . . . . . . .   8
      Informational References . . . . . . . . . . . . . . . . . . .   8
      Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .   9
      Intellectual Property and Copyright Statements . . . . . . . .  10






































Garcia-Martin & Camarillo    Expires September 28, 2004         [Page 2]


Internet-Draft             MESSAGE exploders                  March 2004


1. Introduction

   SIP [2] can carry instant messages in MESSAGE [3] requests. The
   Advanced Instant Messaging Requirements for SIP [6] mention the need
   for exploders for MESSAGE transactions:

   "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 an URI
   list as specified in [4]. The Request-URI of the MESSAGE request
   contains a "list" URI parameter that points to a body part that
   carries the URI list. On reception of such a request, the MESSAGE
   exploder sends a similar MESSAGE request that includes a copy of the
   body (except the list itself) to each URI in the list.

   The UAC needs to be configured with the SIP URI of the MESSAGE
   exploder. Provisioning of the MESSAGE exploder 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 exploder': SIP application server that receives a MESSAGE
   request with a URI list and sends a similar MESSAGE request to each
   URI in the list. MESSAGE exploders behave effectively as B2BUAs
   (Back-To-Back-User-Agents).

   'Incoming MESSAGE request': A SIP MESSAGE request that a UAC creates
   and addresses to a SIP MESSAGE exploder. Besides the regular instant
   message payload, an incoming MESSAGE request contains a URI list.

   'Outgoing MESSAGE request': A SIP MESSAGE request that a MESSAGE
   exploder and addresses to a UAS. It contains the regular instant
   message payload.

3. Procedures at the UAC

   A client that wants to create a multiple recipient MESSAGE request
   SHOULD add a "list" parameter (specified in [4]) to the MESSAGE
   exploder's URI and MUST place the resulting URI in the Request-URI of
   the MESSAGE request. The "list" parameter MUST contain a pointer to a



Garcia-Martin & Camarillo    Expires September 28, 2004         [Page 3]


Internet-Draft             MESSAGE exploders                  March 2004


   URI list that contains the recipients of the MESSAGE. The following
   is an example of a Request-URI with a "list" parameter.

   sip:message-exploder.example.com;list=cid:cn35t8jf@uac.example.com

   Multiple recipient MESSAGE requests will typically contain a
   multiparty body that contains the body carrying the list and the
   actual instant message payload. In some cases, the MESSAGE request
   will contain bodies other than the text and the list bodies, for
   instance, when the request is protected with S/MIME.

   Typically the MESSAGE exploder will copy all the significant header
   fields in the exploded MESSAGE request. However, there might be cases
   where the SIP UA wants the MESSAGE exploder to add a particular
   header field with a particular value, when 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 [2]
   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
   [2]) 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 "?" mechanisms:

   sip:message-exploder.example.com;list=cid:cn35t8jf@uac.example.com?
   Accept-Contact=*%3bmobility%3d%22mobile%22

   The previous URI requests the exploder to add the following header
   field to a MESSAGE request:

   Accept-Contact: *;mobility="mobile"

   As described in [4], the default format for URI lists in SIP is the
   XCAP resource list format [5]. User Agents compliant to this
   specification MUST support the XCAP resource list format  [5] and MAY
   support other formats.

   UAs generating multiple recipient MESSAGEs SHOULD use flat lists
   (i.e., no hierarchical lists), SHOULD NOT use any entry's attributes
   but "uri", and SHOULD NOT include any elements inside entries but
   "display-name" elements.

4. Procedures at the MESSAGE Exploder

   On receiving a MESSAGE request that contains a "list" parameter in
   the Request-URI as described in [4], a MESSAGE exploder 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



Garcia-Martin & Camarillo    Expires September 28, 2004         [Page 4]


Internet-Draft             MESSAGE exploders                  March 2004


   whether or not the MESSAGEs generated by the exploder were
   successfully delivered to the URIs in the list. That is, a 202
   Accepted means that the MESSAGE exploder 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.

   On receiving a MESSAGE request that contains a "list" parameter in
   the Request-URI as described [4], a MESSAGE exploder SHOULD create as
   many new MESSAGEs as URIs the list contains. The body of these new
   MESSAGEs SHOULD contain the same bodies as the incoming MESSAGE
   carried, except the body carrying the list, which MUST NOT be present
   in the outgoing MESSAGE request. This behaviour allows the MESSAGE
   exploder to transfer all the relevant bodies included in the request,
   e.g., text message, images, etc.

   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]. In particular, Section 19.1.5
   of RFC 3261 [2] 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 exploders
   MUST generate only MESSAGE requests, regardless of the "method"
   parameter that the URIs in the list indicate. Effectively, MESSAGE
   exploders MUST ignore the "method" parameter in each of the URIs
   present in the URI list.

   It is RECOMMENDED that the MESSAGE exploder copies the value From
   header field of the incoming MESSAGE into the outgoing MESSAGE
   requests (note that this need not apply to the "tag" parameter). The
   MESSAGE exploder SHOULD also copy to the outgoing MESSAGE request any
   P-Asserted-Identity header fields that can be present in the incoming
   MESSAGE request.

      OPEN ISSUE: What should the exploder do with a possible
      P-Asserted-Identity? Copying the contents of the incoming MESSAGE
      request or generate a new "unasserted" value to the outgoing
      MESSAGE request?

   On each given outgoing MESSAGE request, the MESSAGE exploder SHOULD
   generate a new To header field value which, according to the
   procedures of RFC 3261 Section 8.1.1.1, should be equal to the



Garcia-Martin & Camarillo    Expires September 28, 2004         [Page 5]


Internet-Draft             MESSAGE exploders                  March 2004


   Request-URI of the outgoing MESSAGE request.

   On each given outgoing MESSAGE request, the MESSAGE exploder SHOULD
   initialize the values of the Call-ID, CSeq and Max-Forwards header
   fields. The MESSAGE exploder should also include its own value in the
   Via header field.

   A MESSAGE exploder receiving a URI list with more information than
   what we have just described SHOULD discard all the extra information.

   As described in [4], the default format for URI lists in SIP is the
   XCAP resource list format [5]. MESSAGE exploders compliant to this
   specification MUST support the XCAP resource list format [5] and MAY
   support other formats.

5. Examples

   The following is an example of an incoming MESSAGE request which
   carries a URI list in its body.

   MESSAGE sip:exploder.example.com;list=cid:cn35t8jf@uac.example.com
           SIP/2.0
   Via: SIP/2.0/TCP uac.example.com
       ;branch=z9hG4bKhjhs8ass83
   Max-Forwards: 70
   To: MESSAGE Exploder <sip:exploder.example.com>
   From: Carol <sip:carol@example.com>;tag=32331
   Call-ID: d432fa84b4c76e66710
   CSeq: 1 MESSAGE
   Content-Type: multipart/mixed;boundary="boundary1"
   Content-Length: xxx

   --boundary1
   Content-Type: text/plain
   Content-Length: 13

   Hello World!

   --boundary1
   Content-Type: application/resource-lists+xml
   Content-Length: 315
   Content-ID: <cn35t8jf@uac.example.com>

   <?xml version="1.0" encoding="UTF-8"?>
   <resource-lists xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <list>
       <entry uri="sip:bill@example.com" />
       <entry uri="sip:joe@example.com" />



Garcia-Martin & Camarillo    Expires September 28, 2004         [Page 6]


Internet-Draft             MESSAGE exploders                  March 2004


       <entry uri="sip:ted@example.com" />
       <entry uri="sip:bob@example.com" />
     </list>
   </resource-lists>
   --boundary1--

         Figure 4: Multiple recipient incoming MESSAGE request

   The following is an example of one of the outgoing MESSAGE requests
   that the MESSAGE exploder creates.

   MESSAGE sip:bill@example.com SIP/2.0
   Via: SIP/2.0/TCP exploder.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
   Content-Length: 13

   Hello World!

                   Figure 5: Outgoing MESSAGE request


6. Security Considerations

   If MESSAGE exploders are not implemented properly, they could  become
   a SPAM amplification tool. The SPAMMER would have the exploder, which
   will generally have a higher access bandwidth and more processing
   power, send a SPAM message to a large set of destinations. This
   section provides guidelines to prevent SPAM amplifications in
   particular, and DoS attacks in general. In addition, we describe how
   to provide content confidentiality and integrity.

   MESSAGE exploders MUST authenticate and authorize any user agent
   sending a multiple recipient MESSAGE. Additionally, MESSAGE exploders
   MAY have policies that limit the number of URIs in the list, as a
   very long list could be used in a DoS attack to place a large burden
   on the exploder to send a large number of MESSAGEs or to perform an
   amplification attack.

   In case an exploder is used to send unsolicited instant messages
   (i.e., SPAM), it should be possible to track down the sender of such
   messages. To do that, MESSAGE exploders MAY provide information about
   the identity of the original sender of the MESSAGE in their outgoing



Garcia-Martin & Camarillo    Expires September 28, 2004         [Page 7]


Internet-Draft             MESSAGE exploders                  March 2004


   MESSAGE requests. Exploders can use Authenticated Identity Bodies
   (AIB) [7] or P-Asserted-Identity header fields [8] to provide this
   information. Furthermore, it is RECOMMENDED that MESSAGE exploders
   keep a log of all the transactions they handle (for a reasonable
   period of time), so that SPAMMERS can be tracked down.

   It is RECOMMENDED that user agents using MESSAGE exploders integrity
   protect the contents of their instant messages and the list of
   recipients using S/MIME. If the contents of the instant message or
   the list of recipients needs to be kept private, the user agent
   SHOULD also use S/MIME to prevent a third party from viewing this
   information.

7. Acknowledgements

   Duncan Mills supported the idea of having 1 to n MESSAGEs.

Normative References

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

   [2]  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]  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-00 (work in progress), November
        2003.

   [5]  Rosenberg, J., "An Extensible Markup Language (XML)
        Configuration Access Protocol (XCAP)  Usage for Presence Lists",
        draft-ietf-simple-xcap-list-usage-01 (work in progress), October
        2003.

Informational References

   [6]  Rosenberg, J., "Advanced Instant Messaging Requirements for the
        Session Initiation Protocol  (SIP)",
        draft-rosenberg-simple-messaging-requirements-00 (work in
        progress), December 2002.

   [7]  Peterson, J., "SIP Authenticated Identity Body (AIB) Format",



Garcia-Martin & Camarillo    Expires September 28, 2004         [Page 8]


Internet-Draft             MESSAGE exploders                  March 2004


        draft-ietf-sip-authid-body-02 (work in progress), July 2003.

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


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


























Garcia-Martin & Camarillo    Expires September 28, 2004         [Page 9]


Internet-Draft             MESSAGE exploders                  March 2004


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




Garcia-Martin & Camarillo    Expires September 28, 2004        [Page 10]