[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
SIPPING Working Group                                       G. Camarillo
Internet-Draft                                                  Ericsson
Expires: November 30, 2004                                      A. Roach
                                                             dynamicsoft
                                                               June 2004


  Message-Contained URI-Lists in the Session Initiation Protocol (SIP)
                   draft-ietf-sipping-uri-list-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 November 30, 2004.

Copyright Notice

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

Abstract

   This document describes how a user agent can provide another user
   agent with a list of URIs in a SIP message. The way the receiving
   user agent uses the URIs in the list is method or status code
   specific.








Camarillo & Roach      Expires November 30, 2004                [Page 1]


Internet-Draft     Message-Contained URI-Lists in SIP          June 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  The uri-list Disposition Type  . . . . . . . . . . . . . . . .  3
     3.1   Default URI List Format  . . . . . . . . . . . . . . . . .  4
   4.  Pointing to External URI Lists . . . . . . . . . . . . . . . .  4
   5.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
   8.  Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . .  6
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   9.1   Normative References . . . . . . . . . . . . . . . . . . . .  6
   9.2   Informational References . . . . . . . . . . . . . . . . . .  7
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  7
       Intellectual Property and Copyright Statements . . . . . . . .  8



































Camarillo & Roach      Expires November 30, 2004                [Page 2]


Internet-Draft     Message-Contained URI-Lists in SIP          June 2004


1.  Introduction

   Some services require a SIP UA (User Agent) to provide another UA
   (e.g., a SIP URI-list service acting as a UA server) with a set of
   URIs. For example, a UA creating a conference needs to provide the
   conference server with the participants. The same way, a UA
   requesting presence information from a set of users needs to provide
   the resource list server with the URIs of the users that belong to
   the list.

   These lists are typically configured using out-of-band methods. For
   instance, a UA can use XCAP [8] to create a list of URIs and to
   associate this list with a SIP URI (e.g., sip:myfriends@example.com).
   It can, then, send a SIP request (an INVITE or a SUBSCRIBE in our
   previous examples) to that SIP URI.

   Still, there is a need to create lists of URIs and send them directly
   in a SIP message. Transporting the URI list in the SIP message that
   triggers the service usually helps reduce the service establishment
   time, and is useful for UAs that do not have access to a server to
   host their list (and they cannot act as a server themselves).

   In any case, the way the application server interprets the URI list
   received in the request is method specific.

   A UA creating a SIP request or response that needs to carry a URI
   list places the URI list (e.g., an XCAP resource list [4]) in a body
   part whose disposition type is "uri-list". The way the receiving UA
   interprets the URI list received is method specific, or, in the case
   of a response, status code specific.

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.

3.  The uri-list Disposition Type

   We define a new disposition type for the Content-Disposition header
   field: uri-list. Both requests and responses MAY carry uri-list
   bodies.

   Bodies whose disposition type is uri-list carry a list of URIs. The
   way a UA receiving a URI list interprets it is method specific, or,
   in the case of a response, status code specific.



Camarillo & Roach      Expires November 30, 2004                [Page 3]


Internet-Draft     Message-Contained URI-Lists in SIP          June 2004


3.1  Default URI List Format

   The default format for uri-list bodies is the XCAP resource list
   format defined in [4]. So, SIP entities handling uri-list bodies MUST
   support this format.

   Nevertheless, the XCAP resource list format provides features such as
   hierarchical lists and list's attributes that are not needed by many
   services, which only need to transfer a flat list of URIs between two
   UAs. The amount of information that a URI list needs to carry between
   two UAs is method or status code specific. Additionally, the way a
   client and a server negotiate the amount of information needed for a
   particular service is method specific as well.

   A client invoking a particular service SHOULD NOT include more
   information in its URI list than the service requires. A server
   providing a particular service MAY discard any extra information
   which is received in a URI list from the client.

   The following is an example of a flat list without attributes.


   <?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.org" />
       <entry uri="sip:ted@example.net" />
     </list>
   </resource-lists>

                           Figure 1: URI List


4.  Pointing to External URI Lists

   UAs that want to use an external URI list, instead of sending it as a
   body part, SHOULD use the content indirection mechanism defined in
   [5]. Indirected body parts are equivalent and have the same treatment
   as in-line body parts.

5.  Example

   The following is an example of an INVITE request that carries a URI
   list in its body. The Request-URI of this INVITE contains a pointer
   to the body part carrying the list.





Camarillo & Roach      Expires November 30, 2004                [Page 4]


Internet-Draft     Message-Contained URI-Lists in SIP          June 2004


   INVITE sip:conf-fact@example.com SIP/2.0
   Via: SIP/2.0/TCP client.chicago.example.com
       ;branch=z9hG4bKhjhs8ass83
   Max-Forwards: 70
   To: Conf Factory <sip:conf-fact@example.com>
   From: Carol <sip:carol@chicago.example.com>;tag=32331
   Call-ID: d432fa84b4c76e66710
   CSeq: 1 INVITE
   Contact: <sip:carol@client.chicago.example.com>
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
        SUBSCRIBE, NOTIFY
   Allow-Events: dialog
   Accept: application/sdp, message/sipfrag,
   Conten-Type: multipart/mixed;boundary="boundary1"
   Content-Length: 635

   --boundary1
   Content-Type: application/sdp

   v=0
   o=carol 2890844526 2890842807 IN IP4 chicago.example.com
   s=Example Subject
   c=IN IP4 192.0.2.1
   t=0 0
   m=audio 20000 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   m=video 20002 RTP/AVP 31
   a=rtpmap:31 H261/90000

   --boundary1
   Content-Type: application/resource-lists+xml
   Content-Disposition: uri-list

   <?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.org" />
       <entry uri="sip:ted@example.net" />
     </list>
   </resource-lists>
   --boundary1--

                        Figure 2: INVITE request

   Refer to (draft-ietf-sipping-uri-list-conferencing-00.txt) for the
   normative details on how a list can be used with the INVITE method.




Camarillo & Roach      Expires November 30, 2004                [Page 5]


Internet-Draft     Message-Contained URI-Lists in SIP          June 2004


6.  Security Considerations

   This document discusses how to carry URI lists in SIP messages.
   Attackers may attempt to modify URI lists sent between two user
   agents. This would cause a different service behavior than expected
   by the user agents. To prevent this attack, user agents SHOULD
   integrity protect URI lists using mechanisms such as S/MIME, which
   can also provide URI list confidentiality, if needed.

   Some application servers, on reception of a SIP message with a URI
   list, send SIP requests to the URIs in the list. These application
   servers are referred to as SIP URI-list services. The Security
   Considerations Section of the Requirements and Framework for SIP SIP
   URI-List Services [6] discusses issues related to SIP URI-list
   services. Implementations of SIP URI-list services MUST follow the
   security-related rules in [6]. These rules include mandatory
   authentication and authorization of clients, and opt-in lists.

7.  IANA Considerations

   This document defines a new Content-Disposition header field
   disposition type (uri-list) in Section 3. This value should be
   registered in the IANA registry for Content-Dispositions on

   http://www.iana.org/assignments/mail-cont-disp

   with the following description:


            uri-list    the body contains a list of URIs


8.  Acknowledges

   Alan Johnston, Orit Levin, and Cullen Jennings provided useful
   comments on this document.

9.  References

9.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]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.



Camarillo & Roach      Expires November 30, 2004                [Page 6]


Internet-Draft     Message-Contained URI-Lists in SIP          June 2004


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

   [5]  Olson, S., "A Mechanism for Content Indirection in Session
        Initiation Protocol (SIP)  Messages",
        draft-ietf-sip-content-indirect-mech-03 (work in progress), June
        2003.

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

9.2  Informational References

   [7]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies",
        RFC 2045, November 1996.

   [8]  Rosenberg, J., "The Extensible Markup Language (XML)
        Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-02
        (work in progress), February 2004.


Authors' Addresses

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com


   Adam Roach
   dynamicsoft
   5100 Tennyson Pkwy
   Suite 1200
   Plano, TX  75024
   US

   EMail: adam@dynamicsoft.com







Camarillo & Roach      Expires November 30, 2004                [Page 7]


Internet-Draft     Message-Contained URI-Lists in SIP          June 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 & Roach      Expires November 30, 2004                [Page 8]