Application of Event Package Bodies to Subscriptions to Lists of Resources in the Session Initiation Protocol (SIP)
draft-roach-sip-list-subscribe-bodies-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 3, 2009.

Abstract

This document specifies a mechanism by which subscriptions to the state of request-contained ("ad-hoc") lists of resources can have event-package-defined bodies applied to each of the contained resources.

Table of Contents

1.  Introduction
2.  List Subscription Bodies
    2.1.  Negotitaion of Support
    2.2.  Extension to the Resource Lists Data Format
    2.3.  Application of multipart/related MIME Type
3.  Examples
    3.1.  Subscription to Presence Event Package with Filters
    3.2.  Subscription to XCAP Diff Event Package
4.  Security Considerations
5.  IANA Considerations
    5.1.  XML Namespace Registration
    5.2.  XML Schema Registration
6.  References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

The SIP-specific event notification protocol extension speficied by RFC 3265 [RFC3265] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) provides the ability for event packages to define bodies for use in SUBSCRIBE messages. These bodies generally provide information that modifies the behavior of the subscription, such as filtering or throttling the information that arrives in subsequent NOTIFY messages.

The extension for susbcriptions to predefined lists of resoueces [RFC4662] (Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” August 2006.) defines a mechanism by which a single SUBSCRIBE message can be used to retrieve the state of multiple resources. This is achieved by defining, via some non-SIP mechanism, a list of resources and associtating these resources with a SIP URI. Subscribers can then subscribe to this single SIP URI and receive state information for each resource in the associated list.

The extension for subscriptions to request-contatined ("ad-hoc") lists of resources [I‑D.ietf‑sip‑uri‑list‑subscribe] (Camarillo, G., Roach, A., and O. Levin, “Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP),” November 2007.) specifies a mechanism for subscribing to a list of resources in SIP, while defining the list of resources at the time the subscription is created. This is performed by including the list of the URIs to which a list subscription is desired in the body of the SUBSCRIBE message.

The current set of mechanisms for subscribing to a list of several resources does not currently provide the means for specification of the body or bodies that are to apply to each of the subscriptions. For certain types of subscriptions, such as presence subscriptions, this creates an inconvenience, as filters cannot be adequately conveyed on a per-resource basis. For other event packages, such as XCAP diff [I‑D.ietf‑simple‑xcap‑diff] (Rosenberg, J. and J. Urpalainen, “An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources,” May 2008.), this provides a complete barrier to operation, as XCAP diff subscriptions require the presence of SUBSCRIBE bodies to function at all.

This document proposes a solution to this situation by the optional application of a multipart/related [RFC2387] (Levinson, E., “The MIME Multipart/Related Content-type,” August 1998.) body in ad-hoc list subscriptions. In this multipart/related document, the root document contains the ad-hoc list of resources to which the subscription is being established, while the additional body parts contain information relevant to the event-package being invoked.

2.  List Subscription Bodies

Subscribers making use of ad-hoc list subscriptions can indicate bodies to be applied to one or more of the resources on the list by using a multipart/related body, as described in the following sections.

2.1.  Negotitaion of Support

[Open Issue: should we simply rely on the normal SIP content-type negotiate here? Or do we need to add yet another option tag to explicitly signal support for this behavior?]

2.2.  Extension to the Resource Lists Data Format

This document defines an extension to the XML resource list data format [RFC4826] (Rosenberg, J., “Extensible Markup Language (XML) Formats for Representing Resource Lists,” May 2007.) that allows binding of resource list elements to body parts in a multipart MIME body. To acheive this, this document adds a new "cid" attribute to the <entry> element of the resource list document format. This "cid" attribute binds the resource to a body part contained within the same multipart MIME document as the resource list itself appears. For resource lists appearing outside of the context of a multipart MIME body, the "cid" attribute has no meaning, and can safely be ignored.

The schema for the new "cid" attribute is as follows:

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

      <xs:import namespace="urn:ietf:params:xml:ns:resource-lists"
        schemaLocation="urn:ietf:params:xml:schema:resource-lists"/>

      <xs:attribute name="cid" type="xs:string"/>
   </xs:schema>

[TODO: I'm not completely certain that this schema is 100% correct -- how do we indicate that is specific to the <entry> element?]

2.3.  Application of multipart/related MIME Type

To apply event-package-defined bodies to a resource in an ad-hoc list subscription, subscribers compose a SUBSCRIBE message with a top-level MIME body type of "multipart/related." The root of this document will be the resource list (of content type "application/resource-lists+xml") that defines the list of resources to which the request pertains. The remaing sections in the multipart/related document will contain bodies that are to be interpreted according to the event package indicated in the SUBSCRIBE message "Event" header field.

Within the resource list document, any <entry> to which an event-package-defined body is to be applied will also contain a "cid" attribute. This "cid" attribute identifies a section within the multipart/related document; this section contains an event-package-specific document that is to be applied to the corresponding resource, according to the rules of the event package.

In many cases, such as when the event-package-specific bodies are filtering the state that is to be sent for a resouce, the body to be applied may be common for several resources. To allow for efficient encoding of these cases, multiple <entry> elements may refer to the same cid. The section indicated by the cid is appplies to every <entry> that references it.

Implementors of the mechanism defined in this document are cautioned to take particular care that Content-Disposition headers are associated with the proper MIME body. For example, the top-level MIME body, of type "multipart/related", will not contain a "Content-Disposition" of "recipient-list"; however, its root document, of type "aapplication/resource-lists+xml", will.

3.  Examples

3.1.  Subscription to Presence Event Package with Filters

This example shows the SUBSCRIBE message for a subscription to an ad-hoc list of presence information [I‑D.ietf‑simple‑xcap‑diff] (Rosenberg, J. and J. Urpalainen, “An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources,” May 2008.), with the application of a single notification filter [RFC4660] (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “Functional Description of Event Notification Filtering,” September 2006.) to all of the indicated resources.

  SUBSCRIBE sip:rls@example.com SIP/2.0
  Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKDlg07GFl
  Max-Forwards: 70
  To: RLS <sip:rls@example.com>
  From: <sip:adam@example.com>;tag=sg83ltmq
  Call-ID: srag0983kgo@terminal.example.com
  CSeq: 1 SUBSCRIBE
  Contact: <sip:terminal.example.com>
  Event: xcap-diff; diff-processing=agregate
  Expires: 7200
  Require: recipient-list-subscribe
  Supported: eventlist
  Accept: application/pidf+xml
  Accept: application/rlmi+xml
  Accept: multipart/related
  Accept: multipart/signed
  Accept: multipart/encrypted
  Content-Type: multipart/related;
      type="application/resource-lists+xml";
      start="<nXYxAE@example.com>";
      boundary="05HOsJ2YFPIYgttHCr0m"
  Content-Length: [TBD]

  --05HOsJ2YFPIYgttHCr0m
  Content-ID: <nXYxAE@example.com>
  Content-Type: application/resource-lists+xml;charset="UTF-8"
  Content-Disposition: recipient-list

  <?xml version="1.0" encoding="UTF-8"?>
  <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
      xmlns:rc="urn:ietf:params:xml:ns:rl-cid"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <list>
      <entry uri="sip:buddies@dallas.example.com"
             rc:cid="bUZBsM@example.com" />
      <entry uri="sip:buddies@tokyo.example.org"
             rc:cid="bUZBsM@example.com" />
    </list>
  </resource-lists>

  --05HOsJ2YFPIYgttHCr0m
  Content-ID: <bUZBsM@example.com>
  Content-Type: application/simple-filter+xml;charset="UTF-8"

  <?xml version="1.0" encoding="UTF-8"?>
  <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
    <ns-bindings>
      <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
    </ns-bindings>
    <filter id="999" uri="sip:sarah@example.com">
      <what>
        <include type="namespace">
          urn:ietf:params:xml:ns:pidf</include>
        <exclude>
          //pidf:tuple/pidf:note</exclude>
      </what>
    </filter>
    <filter id="8439">
      <what>
        <include>
          //pidf:tuple/pidf:status/pidf:basic</include>
      </what>
    </filter>
  </filter-set>

  --05HOsJ2YFPIYgttHCr0m--

3.2.  Subscription to XCAP Diff Event Package

This example shows the SUBSCRIBE message for a subscription to an ad-hoc list of XCAP-diff [I‑D.ietf‑simple‑xcap‑diff] (Rosenberg, J. and J. Urpalainen, “An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources,” May 2008.) resources. This would be applicable, for example, if a client wants to monitor resources on multiple XCAP servers through a single subscription.

  SUBSCRIBE  sip:rls@example.com SIP/2.0
  Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL
  Max-Forwards: 70
  To: RLS <sip:rls@example.com>
  From: <sip:adam@example.com>;tag=ie4hbb8t
  Call-ID: cdB34qLToC@terminal.example.com
  CSeq: 1 SUBSCRIBE
  Contact: <sip:terminal.example.com>
  Event: xcap-diff; diff-processing=agregate
  Expires: 7200
  Require: recipient-list-subscribe
  Supported: eventlist
  Accept: application/xcap-diff+xml
  Accept: application/rlmi+xml
  Accept: multipart/related
  Accept: multipart/signed
  Accept: multipart/encrypted
  Content-Type: multipart/related;
      type="application/resource-lists+xml";
      start="<nXYxAE@example.com>";
      boundary="50UBfW7LSCVLtggUPe5z"
  Content-Length: [TBD]

  --50UBfW7LSCVLtggUPe5z
  Content-ID: <nXYxAE@example.com>
  Content-Type: application/resource-lists+xml;charset="UTF-8"
  Content-Disposition: recipient-list

  <?xml version="1.0" encoding="UTF-8"?>
  <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
      xmlns:rc="urn:ietf:params:xml:ns:rl-cid"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <list>
      <entry uri="sip:xcap@dallas.example.com"
             rc:cid="bUZBsM@example.com" />
      <entry uri="sip:xcap@tokyo.example.org"
             rc:cid="ZvSvkz@example.com" />
    </list>
  </resource-lists>

  --50UBfW7LSCVLtggUPe5z
  Content-ID: <bUZBsM@example.com>
  Content-Type: application/resource-lists+xml;charset="UTF-8"
  Content-Disposition: [!!! XCAP Event still needs to define one !!!]

  <?xml version="1.0" encoding="UTF-8"?>
  <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
   <list>
    <entry uri="tests/users/sip:alice@dallas.example.com/"/>
    <entry uri="tests/users/sip:bob@dallas.example.com/"/>
   </list>
  </resource-lists>

  --50UBfW7LSCVLtggUPe5z
  Content-ID: <ZvSvkz@example.com>
  Content-Type: application/resource-lists+xml;charset="UTF-8"
  Content-Disposition: [!!! XCAP Event still needs to define one !!!]

  <?xml version="1.0" encoding="UTF-8"?>
  <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
   <list>
    <entry uri="tests/users/sip:hiroshi@tokyo.example.org/"/>
    <entry uri="tests/users/sip:keiko@tokyo.example.org/"/>
   </list>
  </resource-lists>

  --50UBfW7LSCVLtggUPe5z--

4.  Security Considerations

The security considerations that apply to SIP list subscriptions also apply to this work, as do the considerations surrounding the use of filters for state subscriptions. The author of this document has not identified any unique security considerations that arise from the combination of these two protocol extensions.

5.  IANA Considerations

5.1.  XML Namespace Registration

This section registers a new XML namespace in the IANA XML registry, as described in RFC 3688 [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI:

urn:ietf:params:xml:ns:rl-cid

Registrant Contact:

IETF, SIP working group <sip@ietf.org>

XML:

  BEGIN
   <?xml version="1.0"?>
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
     "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml">
   <head>
     <meta http-equiv="content-type"
        content="text/html;charset=iso-8859-1"/>
     <title>Resource List CID Attribute</title>
   </head>
   <body>
     <h1>Namespace for a CID attribute in Resource Lists</h1>
     <h2>urn:ietf:params:xml:ns:rl-cid</h2>
     <p>See <a href="[URL of published RFC]">RFCXXXX
     [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with
     the RFC number of this specification.]</a>.</p>
   </body>
   </html>
  END

5.2.  XML Schema Registration

This section registers a new XML Schema in the IANA XML registry, as described in RFC 3688 [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI:

urn:ietf:params:xml:ns:rl-cid

Registrant Contact:

IETF, SIP working group <sip@ietf.org>

The schema for this registration can be found in Section 2.2 (Extension to the Resource Lists Data Format).

6. References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.