One document matched: draft-roach-sip-list-subscribe-bodies-00.txt
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 <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
Roach Expires January 2, 2009 [Page 4]
Internet-Draft List Subscription Bodies July 2008
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 [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 <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
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="<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>
Roach Expires January 2, 2009 [Page 6]
Internet-Draft List Subscription Bodies July 2008
</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 [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 <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"
Roach Expires January 2, 2009 [Page 7]
Internet-Draft List Subscription Bodies July 2008
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 [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 <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 [5].
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.
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:16:31 |