One document matched: draft-roach-sip-list-subscribe-bodies-00.xml
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2387 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2387.xml'>
<!ENTITY rfc3265 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3265.xml'>
<!ENTITY rfc3688 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml'>
<!ENTITY rfc4660 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4660.xml'>
<!ENTITY rfc4662 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4662.xml'>
<!ENTITY rfc4826 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4826.xml'>
<!ENTITY draft-ietf-sip-uri-list-subscribe PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sip-uri-list-subscribe-02.xml'>
<!ENTITY draft-ietf-simple-xcap-diff PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-simple-xcap-diff-09.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc ipr="full3978" docName="draft-roach-sip-list-subscribe-bodies-00">
<front>
<title abbrev="List Subscription Bodies">
Application of Event Package Bodies to Subscriptions to
Lists of Resources in the Session Initiation Protocol (SIP)
</title>
<author initials="A. B." surname="Roach" fullname="Adam Roach">
<organization>Tekelec</organization>
<address>
<postal>
<street>17210 Campbell Rd.</street>
<street>Suite 250</street>
<city>Dallas</city> <region>TX</region> <code>75252</code>
<country>US</country>
</postal>
<email>adam@nostrum.com</email>
</address>
</author>
<date month="July" day="1" year="2008" />
<area>Real Time Applications and Infrastructure</area>
<workgroup>SIP WG</workgroup>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The SIP-specific event notification protocol extension
speficied by RFC 3265 <xref target="RFC3265" /> 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.
</t>
<t>
The extension for susbcriptions to predefined lists of
resoueces <xref target="RFC4662" /> 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.
</t>
<t>
The extension for subscriptions to request-contatined ("ad-hoc")
lists of resources <xref target="I-D.ietf-sip-uri-list-subscribe" />
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.
</t>
<t>
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
<xref target="I-D.ietf-simple-xcap-diff" />, this provides
a complete barrier to operation, as XCAP diff subscriptions
require the presence of SUBSCRIBE bodies to function at all.
</t>
<t>
This document proposes a solution to this situation by the
optional application of a multipart/related <xref target="RFC2387" />
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.
</t>
</section>
<section title="List Subscription Bodies">
<t>
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.
</t>
<section title="Negotitaion of Support">
<t>
[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?]
</t>
</section>
<section title="Extension to the Resource Lists Data Format"
anchor="xml-format">
<t>
This document defines an extension to the XML resource
list data format <xref target="RFC4826" /> 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.
</t>
<t>
The schema for the new "cid" attribute is as follows:
</t>
<figure>
<artwork>
<![CDATA[
<?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>
]]></artwork>
</figure>
<t>
[TODO: I'm not completely certain that this schema is 100% correct
-- how do we indicate that is specific to the <entry> element?]
</t>
</section>
<section title="Application of multipart/related MIME Type">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Examples">
<section title="Subscription to Presence Event Package with Filters">
<t>
This example shows the SUBSCRIBE message for a subscription
to an ad-hoc list of presence information
<xref target="I-D.ietf-simple-xcap-diff" />, with the
application of a single notification filter
<xref target="RFC4660" /> to all of the indicated resources.
</t>
<figure>
<artwork>
<![CDATA[
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--
]]></artwork>
</figure>
</section>
<section title="Subscription to XCAP Diff Event Package">
<t>
This example shows the SUBSCRIBE message for a subscription
to an ad-hoc list of XCAP-diff
<xref target="I-D.ietf-simple-xcap-diff" />
resources. This would be
applicable, for example, if a client wants to monitor resources
on multiple XCAP servers through a single subscription.
</t>
<figure>
<artwork>
<![CDATA[
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--
]]></artwork>
</figure>
</section>
</section>
<!-- ================================================================= -->
<section title="Security Considerations">
<t>
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.
</t>
</section>
<section title="IANA Considerations">
<section title="XML Namespace Registration">
<t>
This section registers a new XML namespace in the
IANA XML registry, as described in RFC 3688
<xref target="RFC3688"/>.
</t>
<list style="hanging">
<t hangText="URI:"> urn:ietf:params:xml:ns:rl-cid <vspace blankLines="1"/></t>
<t hangText="Registrant Contact:">
IETF, SIP working group <sip@ietf.org><vspace blankLines="1"/>
</t>
<t hangText="XML:">
<figure>
<artwork>
<![CDATA[
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
]]></artwork>
</figure>
</t>
</list>
</section>
<section title="XML Schema Registration">
<t>
This section registers a new XML Schema in the
IANA XML registry, as described in RFC 3688
<xref target="RFC3688"/>.
</t>
<list style="hanging">
<t hangText="URI:"> urn:ietf:params:xml:ns:rl-cid <vspace blankLines="1"/></t>
<t hangText="Registrant Contact:">
IETF, SIP working group <sip@ietf.org><vspace blankLines="1"/>
</t>
</list>
<t>
The schema for this registration can be found in
<xref target="xml-format"/>.
</t>
</section>
</section>
</middle>
<back>
<references title='References'>
&draft-ietf-sip-uri-list-subscribe;
&draft-ietf-simple-xcap-diff;
&rfc2387;
&rfc3265;
&rfc3688;
&rfc4660;
&rfc4662;
&rfc4826;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:42:22 |