The SIP-specific event notification protocol extension speficied by RFC 3265 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 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 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 , 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 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.

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.

[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?]

This document defines an extension to the XML resource list data format 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:

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

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.

This example shows the SUBSCRIBE message for a subscription to an ad-hoc list of presence information , with the application of a single notification filter to all of the indicated resources.

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 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 --05HOsJ2YFPIYgttHCr0m-- ]]>

This example shows the SUBSCRIBE message for a subscription to an ad-hoc list of XCAP-diff resources. This would be applicable, for example, if a client wants to monitor resources on multiple XCAP servers through a single subscription.

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

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.

This section registers a new XML namespace in the IANA XML registry, as described in RFC 3688 . urn:ietf:params:xml:ns:rl-cid IETF, SIP working group <sip@ietf.org>

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

This section registers a new XML Schema in the IANA XML registry, as described in RFC 3688 . urn:ietf:params:xml:ns:rl-cid IETF, SIP working group <sip@ietf.org> The schema for this registration can be found in .