SIP WG A. B. Roach Internet-Draft Tekelec Expires: January 2, 2009 July 1, 2008 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 2, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). 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. Roach Expires January 2, 2009 [Page 1] Internet-Draft List Subscription Bodies July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. List Subscription Bodies . . . . . . . . . . . . . . . . . . . 3 2.1. Negotitaion of Support . . . . . . . . . . . . . . . . . . 4 2.2. Extension to the Resource Lists Data Format . . . . . . . 4 2.3. Application of multipart/related MIME Type . . . . . . . . 4 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Subscription to Presence Event Package with Filters . . . 5 3.2. Subscription to XCAP Diff Event Package . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5.1. XML Namespace Registration . . . . . . . . . . . . . . . . 8 5.2. XML Schema Registration . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Roach Expires January 2, 2009 [Page 2] Internet-Draft List Subscription Bodies July 2008 1. Introduction The SIP-specific event notification protocol extension speficied by RFC 3265 [4] 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 [7] 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 [1] 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 [2], 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 [3] 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. Roach Expires January 2, 2009 [Page 3] Internet-Draft List Subscription Bodies July 2008 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 [8] 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 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: [TODO: I'm not completely certain that this schema is 100% correct -- how do we indicate that is specific to the 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 Roach Expires January 2, 2009 [Page 4] Internet-Draft List Subscription Bodies July 2008 field. Within the resource list document, any 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 elements may refer to the same cid. The section indicated by the cid is appplies to every 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 [2], with the application of a single notification filter [6] 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 From: ;tag=sg83ltmq Call-ID: srag0983kgo@terminal.example.com CSeq: 1 SUBSCRIBE Contact: 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 Roach Expires January 2, 2009 [Page 5] Internet-Draft List Subscription Bodies July 2008 Accept: multipart/signed Accept: multipart/encrypted Content-Type: multipart/related; type="application/resource-lists+xml"; start=""; boundary="05HOsJ2YFPIYgttHCr0m" Content-Length: [TBD] --05HOsJ2YFPIYgttHCr0m Content-ID: Content-Type: application/resource-lists+xml;charset="UTF-8" Content-Disposition: recipient-list --05HOsJ2YFPIYgttHCr0m Content-ID: Content-Type: application/simple-filter+xml;charset="UTF-8" urn:ietf:params:xml:ns:pidf //pidf:tuple/pidf:note //pidf:tuple/pidf:status/pidf:basic Roach Expires January 2, 2009 [Page 6] Internet-Draft List Subscription Bodies July 2008 --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 [2] 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 From: ;tag=ie4hbb8t Call-ID: cdB34qLToC@terminal.example.com CSeq: 1 SUBSCRIBE Contact: 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=""; boundary="50UBfW7LSCVLtggUPe5z" Content-Length: [TBD] --50UBfW7LSCVLtggUPe5z Content-ID: Content-Type: application/resource-lists+xml;charset="UTF-8" Content-Disposition: recipient-list --50UBfW7LSCVLtggUPe5z Content-ID: Content-Type: application/resource-lists+xml;charset="UTF-8" Content-Disposition: [!!! XCAP Event still needs to define one !!!] --50UBfW7LSCVLtggUPe5z Content-ID: Content-Type: application/resource-lists+xml;charset="UTF-8" Content-Disposition: [!!! XCAP Event still needs to define one !!!] --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 [5]. Roach Expires January 2, 2009 [Page 8] Internet-Draft List Subscription Bodies July 2008 URI: urn:ietf:params:xml:ns:rl-cid Registrant Contact: IETF, SIP working group XML: BEGIN Resource List CID Attribute

Namespace for a CID attribute in Resource Lists

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

See RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.].

END 5.2. XML Schema Registration This section registers a new XML Schema in the IANA XML registry, as described in RFC 3688 [5]. URI: urn:ietf:params:xml:ns:rl-cid Registrant Contact: IETF, SIP working group The schema for this registration can be found in Section 2.2. 6. References [1] Camarillo, G., Roach, A., and O. Levin, "Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)", draft-ietf-sip-uri-list-subscribe-02 (work in progress), November 2007. [2] Rosenberg, J. and J. Urpalainen, "An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources", Roach Expires January 2, 2009 [Page 9] Internet-Draft List Subscription Bodies July 2008 draft-ietf-simple-xcap-diff-09 (work in progress), May 2008. [3] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998. [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [5] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [6] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, "Functional Description of Event Notification Filtering", RFC 4660, September 2006. [7] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006. [8] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007. Roach Expires January 2, 2009 [Page 10] Internet-Draft List Subscription Bodies July 2008 Author's Address Adam Roach Tekelec 17210 Campbell Rd. Suite 250 Dallas, TX 75252 US Email: adam@nostrum.com Roach Expires January 2, 2009 [Page 11] Internet-Draft List Subscription Bodies July 2008 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 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. 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, 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. Copyright Statement Copyright (C) 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Roach Expires January 2, 2009 [Page 12]