SIPPING Working Group                                       G. Camarillo
Internet-Draft                                                  Ericsson
Expires: January 5, 2005                                        A. Niemi
                                                            H. Khartabil
                                                              M. Isomaki
                                                        M. Garcia-Martin
                                                                   Nokia
                                                            July 7, 2004


   Refering to Multiple Resources in the Session Initiation Protocol
                                 (SIP)
                draft-ietf-sipping-multiple-refer-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 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.

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

Copyright Notice

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

Abstract

   This document defines extensions to the SIP REFER method so that this
   method can be used to refer servers to multiple resources. These
   extensions include the use of pointers to URI-lists in the Refer-To
   header field and the multiple-refer SIP option-tag.




Camarillo, et al.       Expires January 5, 2005                 [Page 1]


Internet-Draft               Multiple REFER                    July 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview of operation  . . . . . . . . . . . . . . . . . . . .  3
   4.  The multiple-refer SIP Option-Tag  . . . . . . . . . . . . . .  4
   5.  Suppressing REFER's Implicit Subscription  . . . . . . . . . .  4
   6.  Behavior of SIP User Agents  . . . . . . . . . . . . . . . . .  5
     6.1   Behavior of SIP REFER-Issuers  . . . . . . . . . . . . . .  5
     6.2   Behavior of REFER-Recipients . . . . . . . . . . . . . . .  5
   7.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . .  7
   10.1  Normative References . . . . . . . . . . . . . . . . . . . .  7
   10.2  Informational References . . . . . . . . . . . . . . . . . .  8
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  8
       Intellectual Property and Copyright Statements . . . . . . . . 10

































Camarillo, et al.       Expires January 5, 2005                 [Page 2]


Internet-Draft               Multiple REFER                    July 2004


1.  Introduction

   The SIP REFER method [5] allows a user agent to request a server to
   send a request to a third party. Still, a number of applications need
   to request a server to initiate transactions towards a set of
   destinations. In one example, the moderator of a conference may want
   the conference server to send BYE requests to a group of
   participants. In another example, the same moderator may want the
   conference server to INVITE a set of new participants.

   We define an extension to REFER so that REFER can be used to refer
   servers to multiple destinations. In addition, we use the REFER
   extension defined in [7] which suppresses REFER's implicit
   subscription.

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.

   We define the following three new terms:

      REFER-Issuer: the user agent issuing the REFER request.
      REFER-Recipient: the user agent receiving the REFER request.
      REFER-Target: the user agent designated in the Refer-To URI.

3.  Overview of operation

   This document defines an extension to the SIP REFER method [5] that
   allows a SIP UAC to include a list of REFER-Targets in a REFER
   request and send it to a server. The server will create a new request
   for each entry in the list of REFER-Target URIs.

   We represent the multiple REFER-Targets of a REFER using the URI-list
   format specified in [8]. A UAC (User Agent Client) that wants to
   refer a server to a set of destinations creates a SIP REFER request.
   The Refer-To header contains a pointer to a URI-list, which is
   included in a body part, and two option-tags in the Required header
   field: "multiple-refer" and "norefersub". The former indicates the
   requirement to support the functionality described in this
   specification and the latter removes the implicit subscription
   associated to REFER requests by default.

   When the server receives such request it creates a new request per
   destination and sends them.



Camarillo, et al.       Expires January 5, 2005                 [Page 3]


Internet-Draft               Multiple REFER                    July 2004


   This document does not provide any mechanism for UACs to find out
   about the results of a REFER with multiple REFER-Targets.
   Furthermore, we do not provide support for the implicit subscription
   mechanism that is part of the SIP REFER method. The way UACs are kept
   informed about the results of a REFER is service specific. For
   example, a UAC sending a REFER to INVITE a set of participants to a
   conference may discover which participants were successfully brought
   in into the conference by using the conference package [10]

4.  The multiple-refer SIP Option-Tag

   We define a new SIP option-tag for the Require and Supported header
   fields: "multiple-refer".

   A user agent including the "multiple-refer" option-tag in a Supported
   header indicates compliance with this specification.

   A user agent generating a REFER with a pointer to a URI-list in its
   Refer-To header field MUST include the "multiple-refer" option-tag in
   the Require header field of the REFER.

5.  Suppressing REFER's Implicit Subscription

   REFER requests with a single REFER-Target establish a subscription
   implicitly. The REFER-Issuer is informed about the result of the
   transaction towards the REFER-Target through this implicit
   subscription.

   In the case of a REFER-Issuer that generates a REFER with multiple
   REFER-targets, the REFER-Issuer is typically already subscribed to
   other event package that can provide the information about the result
   of the transactions towards the REFER-Targets. For example, a
   moderator instructing a conference server to send a BYE request to a
   set of participants is usually subscribed to the conference state
   event package for the conference. Notifications to this event package
   will keep the moderator and the rest of the subscribers informed of
   the current list of conference participant.

   Consequently, we have decided to remove the implicit subscription
   from a multiple REFER request. So, a SIP REFER-Issuer generating a
   REFER request with multiple REFER-Targets MUST include the
   'norefersub' option-tag in a Require header field to indicate that no
   notifications about the requests should be sent to the REFER-Issue.
   The 'norefersub' SIP option-tag is defined in [7] and suppresses the
   REFER's implicit subscription.






Camarillo, et al.       Expires January 5, 2005                 [Page 4]


Internet-Draft               Multiple REFER                    July 2004


6.  Behavior of SIP User Agents

   Implementations of this specification MUST suppot the transfer
   mechanism for URI-lists defined in [8].

6.1  Behavior of SIP REFER-Issuers

   As indicated in Section 4 and Section 5 a SIP REFER-Issuer that
   creates a REFER request with multiple REFER-Targets includes a
   "multiple-refer" and a "norefersub" option-tags in the Require header
   field.

   The Refer-To header field of a REFER request with multiple
   REFER-Targets MUST contain a pointer (i.e., a Content-ID URL [2])
   that points to the body part (whose disposition type is "uri-list")
   that carries the URI-list.

   As described in [8], the default format for URI-lists in SIP is the
   XCAP resource list format [6]. Still, specific services need to
   describe which information clients should include in their URI lists,
   as described in [8].

   SIP REFER-Issuers generating REFERs with multiple REFER-Targets
   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.

6.2  Behavior of REFER-Recipients

   A REFER-Recipient receiving a URI-list with more information than
   what we have described in Section 6.1 SHOULD discard all the extra
   information.

   The REFER-Recipient follows the rules in Section 2.4.2 of RFC 3515
   [5] to determine the status code of the response to the REFER.

7.  Example

   The following is an example of a REFER request with multiple
   REFER-Targets. The REFER's Refer-To header field carries a pointer to
   the message body, which carries a list with the URIs of the
   REFER-Targets. The REFER's Require header field carries both the
   "multiple-refer" and the "norefersub" option-tags.








Camarillo, et al.       Expires January 5, 2005                 [Page 5]


Internet-Draft               Multiple REFER                    July 2004


   REFER sip:conf-123@example.com
   SIP/2.0 Via: SIP/2.0/TCP client.chicago.example.com
           ;branch=z9hG4bKhjhs8ass83
   Max-Forwards: 70
   To: Conference 123 <sip:conf-123@example.com>
   From: Carol <sip:carol@chicago.example.com>;tag=32331
   Call-ID: d432fa84b4c76e66710
   CSeq: 2 REFER
   Contact: <sip:carol@client.chicago.example.com>
   Refer-To: <cid:cn35t8jf02@example.com>
   Require: multiple-refer, norefersub
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
   Allow-Events: dialog
   Accept: application/sdp, message/sipfrag
   Content-Type: application/resource-lists+xml
   Content-Disposition: uri-list
   Content-Length: 307
   Content-ID: <cn35t8jf02@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?method=BYE" />
       <entry uri="sip:joe@example.org?method=BYE" />
       <entry uri="sip:ted@example.net?method=BYE" />
     </list>
   </resource-lists>

          Figure 1: REFER request with multiple REFER-Targets


8.  Security Considerations

   The Security Considerations Section of the Requirements and Framework
   for SIP URI-List Services [9] discusses issues related to SIP
   URI-list services. Given that a server accepting REFERs with multiple
   REFER-targets acts as an URI-list service, implementations of this
   type of server MUST follow the security-related rules in [9]. These
   rules include mandatory authentication and authorization of clients,
   and opt-in lists.

   Additionally, servers SHOULD only accept REFER requests within the
   context of an application the server understands (e.g., a
   conferencing application). This implies that servers MUST NOT accept
   REFERs for methods they do not understand. The idea behind these two
   rules is that servers are not used as dumb servers whose only
   function is to fan-out random messages they do not understand.




Camarillo, et al.       Expires January 5, 2005                 [Page 6]


Internet-Draft               Multiple REFER                    July 2004


9.  IANA Considerations

   This document defines a SIP option-tag (multiple-refer) in Section 4.
   This option-tag should be registered in the SIP parameter registry
   (http://www.iana.org/assignments/sip-parameters).

   SIP user agents that place the multiple-refer option-tag in a
   Supported header field understand REFER requests with multiple
   REFER-Targets.

10.  References

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

   [4]  Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
        November 2002.

   [5]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
        Method", RFC 3515, April 2003.

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

   [7]  Olson, S., "Extended-REFER framework and other REFER
        extensions", draft-olson-sipping-refer-extensions-01 (work in
        progress), February 2004.

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

   [9]  Camarillo, G., "Requirements for Session Initiation Protocol
        (SIP) Exploder Invocation", draft-camarillo-sipping-exploders-02
        (work in progress), February 2004.




Camarillo, et al.       Expires January 5, 2005                 [Page 7]


Internet-Draft               Multiple REFER                    July 2004


10.2  Informational References

   [10]  Rosenberg, J. and H. Schulzrinne, "A Session Initiation
         Protocol (SIP) Event Package for Conference State",
         draft-ietf-sipping-conference-package-03 (work in progress),
         February 2004.

   [11]  Camarillo, G., "A Transaction Event Package for the Session
         Initiation Protocol (SIP)",
         draft-camarillo-sipping-transac-package-00 (work in progress),
         February 2004.


Authors' Addresses

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com


   Aki Niemi
   Nokia
   P.O. Box 321
   NOKIA GROUP, FIN 00045
   Finland

   EMail: Aki.Niemi@nokia.com


   Hisham Khartabil
   Nokia
   P.O. Box 321
   NOKIA GROUP, FIN 00045
   Finland

   EMail: Hisham.Khartabil@nokia.com











Camarillo, et al.       Expires January 5, 2005                 [Page 8]


Internet-Draft               Multiple REFER                    July 2004


   Markus Isomaki
   Nokia
   Itamerenkatu 11-13
   Helsinki  00180
   Finland

   EMail: Markus.Isomaki@nokia.com


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

   EMail: miguel.an.garcia@nokia.com



































Camarillo, et al.       Expires January 5, 2005                 [Page 9]


Internet-Draft               Multiple REFER                    July 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.




Camarillo, et al.       Expires January 5, 2005                [Page 10]