Request for Comments: 4662 B. Campbell
Category: Standards Track Estacado Systems
J. Rosenberg
Cisco Systems
August 2006
A Session Initiation Protocol (SIP) Event Notification Extension
for Resource Lists
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document presents an extension to the Session Initiation
Protocol (SIP)-Specific Event Notification mechanism for subscribing
to a homogeneous list of resources. Instead of sending a SUBSCRIBE
for each resource individually, the subscriber can subscribe to an
entire list and then receive notifications when the state of any of
the resources in the list changes.
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview of Operation ...........................................4
4. Operation of List Subscriptions .................................5
4.1. Negotiation of Support for Resource Lists ..................6
4.2. Subscription Duration ......................................7
4.3. NOTIFY Bodies ..............................................7
4.4. RLS Processing of SUBSCRIBE Requests .......................7
4.5. RLS Generation of NOTIFY Requests ..........................7
4.6. Subscriber Processing of NOTIFY Requests ...................9
4.7. Handling of Forked Requests ...............................10
4.8. Rate of Notifications .....................................10
5. Using multipart/related to Convey Aggregate State ..............10
5.1. XML Syntax ................................................11
5.2. List Attributes ...........................................13
5.3. Resource Attributes .......................................14
5.4. Name Attributes ...........................................14
5.5. Instance Attributes .......................................14
5.6. Constructing Coherent Resource State ......................16
5.6.1. Processing Full State Notifications ................17
5.6.2. Processing Partial State Notifications .............17
6. Example ........................................................18
7. Security Considerations ........................................31
7.1. Authentication ............................................31
7.1.1. RLS and Subscriber in the Same Domain ..............31
7.1.2. RLS and Subscriber in Different Domains ............32
7.2. Risks of Improper Aggregation .............................33
7.3. Signing and Sealing .......................................33
7.4. Infinite Loops ............................................34
8. IANA Considerations ............................................34
8.1. New SIP Option Tag: eventlist .............................34
8.2. New MIME type for Resource List Meta-Information ..........34
8.3. URN Sub-Namespace .........................................35
9. Acknowledgements ...............................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................37
1. Introduction
The SIP-specific event notification mechanism [2] allows a user (the
subscriber) to request to be notified of changes in the state of a
particular resource. This is accomplished by the subscriber
generating a SUBSCRIBE request for the resource, which is processed
by a notifier that represents the resource.
In many cases, a subscriber has a list of resources they are
interested in. Without some aggregating mechanism, this will require
the subscriber to generate a SUBSCRIBE request for each resource
about which they want information. For environments in which
bandwidth is limited, such as wireless networks, subscribing to each
resource individually is problematic. Some specific problems are:
o Doing so generates substantial message traffic, in the form of the
initial SUBSCRIBE requests for each resource and the refreshes of
each individual subscription.
o The notifier may insist on low refresh intervals, in order to
avoid a long-lived subscription state. This means that the
subscriber may need to generate SUBSCRIBE refreshes faster than it
would like to or has the capacity to.
o The notifier may generate NOTIFY requests more rapidly than the
subscriber desires, causing NOTIFY traffic at a greater volume
than is desired by the subscriber.
To solve these problems, this specification defines an extension to
RFC 3265 [2] that allows for requesting and conveying notifications
for lists of resources. A resource list is identified by a URI, and
it represents a list of zero or more URIs. Each of these URIs is an
identifier for an individual resource for which the subscriber wants
to receive information. In many cases, the URI used to identify the
resource list will be a SIP URI [1]; however, the use of other
schemes (such as pres: [10]) is also foreseen.
The notifier for the list is called a "resource list server", or RLS.
In order to determine the state of the entire list, the RLS will act
as if it has generated a subscription to each resource in the list.
The resource list is not restricted to be inside the domain of the
subscriber. Similarly, the resources in the list are not constrained
to be in the domain of the resource list server.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [5].
The following terms are used throughout the remainder of this
document.
Back-End Subscription: Any subscription (SIP or otherwise) that an
RLS creates to learn of the state of a resource. An RLS will
create back-end subscriptions to learn of the state of a resource
about which the RLS is not an authority. For back-end
subscriptions, RLSes act as a subscriber.
List Subscription: A subscription to a resource list. In list
subscriptions, RLSes act as the notifier.
Resource: A resource is any logical entity that has a state or
states that can be subscribed to. Resources are identified by
URIs.
Resource List: A list of zero or more resources that can have their
individual states subscribed to with a single subscription.
RLMI: Resource List Meta-Information. RLMI is a document that
describes the state of the virtual subscriptions associated with a
list subscription.
RLS: Resource List Server. RLSes accept subscriptions to resource
lists and send notifications to update subscribers of the state of
the resources in a resource list.
Virtual Subscription: A Virtual Subscription is a logical construct
within an RLS that represents subscriptions to the resources in a
resource list. For each list subscription it services, an RLS
creates at least one virtual subscription for every resource in
the resource list being subscribed to. In some cases, such as
when the RLS is not the authority for the state of the resource,
this virtual subscription will be associated with a back-end
subscription. In other cases, such as when the RLS is the
authority for the state of the resource, the virtual subscription
will not have a corresponding back-end subscription.
3. Overview of Operation
This section provides an overview of the typical mode of operation of
this extension. It is not normative.
When users wish to subscribe to the resource of a list of resources,
they can use the mechanisms described in this specification. The
first step is the creation of a resource list. This resource list is
represented by a SIP URI. The list contains a set of URIs, each of
which represents a resource for which the subscriber wants to receive
information. The resource list can exist in any domain. The list
could be manipulated through a web page, through a voice response
system, or through some other protocol. The specific means by which
the list is created and maintained is outside the scope of this
specification.
To learn the resource state of the set of elements on the list, the
user sends a single SUBSCRIBE request targeted to the URI of the
list. This will be routed to an RLS for that URI. The RLS acts as a
notifier, authenticates the subscriber, and accepts the subscription.
The RLS may have direct information about some or all of the
resources specified by the list. If it does not, it could subscribe
to any non-local resources specified by the list resource.
Note that subscriptions to non-local resources may or may not be SIP
subscriptions; any mechanism for determining such information may be
employed. This document uses the term "back-end subscription" to
refer to such a subscription, regardless of whether SIP is used to
establish and service it.
As the state of resources in the list change, the RLS generates
notifications to the list subscribers. The RLS can, at its
discretion, buffer notifications of resource changes and send the
resource information to the subscriber in batches, rather than
individually. This allows the RLS to provide rate limiting for the
subscriber.
The list notifications contain a body of type multipart/related. The
root section of the multipart/related content is an XML document that
provides meta-information about each resource present in the list.
The remaining sections contain the actual state information for each
resource.
4. Operation of List Subscriptions
The event list extension acts, in many ways, like an event template
package. In particular, any single list subscription must be
homogeneous with respect to the underlying event package. In other
words, a single list subscription can apply only one event package to
all the resources in the resource list.
Note that it is perfectly valid for an RLS to allow multiple
subscriptions to the same list to use differing event packages.
The key difference between a list subscription and templates in
general is that support for list subscriptions indicates support for
arbitrary nesting of list subscriptions. In other words, elements
within the list may be atomic elements, or they may be lists
themselves.
The consequence of this is that subscription to a URI that represents
a list actually results in several virtual subscriptions to a tree of
resources. The leaf nodes of this tree are virtual subscriptions of
the event type given in the "Event" header field; all other nodes in
the tree are list subscriptions that are serviced as described in
this section and its subsections.
Keep in mind that these virtual subscriptions are not literal SIP
subscriptions (although they may result in SIP subscriptions,
depending on the RLS implementation).
4.1. Negotiation of Support for Resource Lists
This specification uses the SIP option tag mechanism for negotiating
support for the extension defined herein. Refer to RFC 3261 [1] for
the normative description of processing of the "Supported" and
"Require" header fields and the 421 (Extension Required) response
code.
A non-normative description of the implications of the use of
option tags follows.
Any client that supports the event list extension will include an
option tag of "eventlist" in a "Supported" header field of every
SUBSCRIBE message for a subscription for which it is willing to
process a list. If the subscription is made to a URI that
represents a list, the RLS will include "eventlist" in a "Require"
header field of the response to the SUBSCRIBE, and in all NOTIFY
messages within that subscription.
Use of "Require: eventlist" in NOTIFY messages is applied by the
notifier to satisfy the RFC 3261 requirement that a UAC MUST
insert a Require header field into a request if the UAC wishes to
insist that a UAS understand an extension in order to process the
request. Because the NOTIFY would not be usable without applying
the eventlist option, the notifier is obligated to include it.
Including "eventlist" in a "Require" header field in a SUBSCRIBE
request serves no purpose except to break interoperability in certain
cases, and is consequently NOT RECOMMENDED.
Sending of "Supported: eventlist" in a NOTIFY message is meaningless
and silly. Implementations SHOULD NOT include "Supported: eventlist"
in any requests except for SUBSCRIBE.
There is nothing in a SIP URI that indicates whether it represents a
list of resources or a single resource. Therefore, if a subscriber
sends a request to a URI that represents a list resource but does not
include a Supported header field listing the "eventlist" token, the
notifier will typically return a 421 (Extension Required) response
code. RFC 3261 [1] advises that servers avoid returning a 421 and
instead attempt to process the request without the extension.
However, in this case, the URI fundamentally represents a list
resource, and therefore the subscription cannot proceed without this
extension.
4.2. Subscription Duration
Since the primary benefit of the resource list server is to reduce
the overall messaging volume to a subscriber, it is RECOMMENDED that
the subscription duration to a list be reasonably long. The default,
when no duration is specified, is taken from the underlying event
package. Of course, the standard techniques [2] can be used to
increase or reduce this amount.
4.3. NOTIFY Bodies
An implementation compliant to this specification MUST support the
multipart/related and application/rlmi+xml MIME types. These types
MUST be included in an Accept header sent in a SUBSCRIBE message, in
addition to any other types supported by the client (including any
types required by the event package being used).
4.4. RLS Processing of SUBSCRIBE Requests
Once the subscriber is authenticated, the RLS performs authorization
per its local policy. In many cases, each resource list is
associated with a particular user (the one who created it and manages
the set of elements in it), and only that user will be allowed to
subscribe. Of course, this mode of operation is not inherent in the
use of resource lists, and an RLS can use any authorization policy it
chooses.
4.5. RLS Generation of NOTIFY Requests
This specification leaves the choice about how and when to generate
NOTIFY requests at the discretion of the implementor. One of the
differentiators between various RLS implementations is the means by
which they aggregate, rate-limit, or optimize the way in which
notifications are generated. As a baseline behavior, the RLS MAY
generate a NOTIFY to the RLS subscriber whenever the state of any
resource on the list changes.
It is important to understand that any given subscription is a
subscription either to a single resource or to a list of resources.
This nature (single resource versus list of resources) cannot change
during the duration of a single subscription. In particular, this
means that RLSes MUST NOT send NOTIFY messages that do not contain
RLMI for a subscription if they have previously sent NOTIFY messages
in that subscription containing RLMI. Similarly, RLSes MUST NOT send
NOTIFY messages that do contain RLMI for a subscription if they have
previously sent NOTIFY messages in that subscription which do not.
List representations necessarily contain RLMI documents for two
reasons. Importantly, they identify the resource to which the
event state corresponds. Many state syntaxes do not fully
identify the resource to which the state applies, or they may
identify the resource in a different way than it is represented in
the list; for example, PIDF documents may contain resource URIs
that are not identical to the URI used to retrieve them. Further,
RLMI documents serve to disambiguate multiple instances of a
single resource.
See Section 5 for a detailed definition of the syntax used to convey
the state of resource lists. For the purposes of the following
discussion, it is important to know that the overall list contains
zero or more resources, and that the resources contain zero or more
instances. Each instance has a state associated with it (pending,
active, or terminating) representing the state of the virtual
subscription.
Notifications contain a multipart document, the first part of which
always contains meta-information about the list (e.g., membership,
state of the virtual subscription to the resource). Remaining parts
are used to convey the actual state of the resources listed in the
meta-information.
The "state" attribute of each instance of a resource in the
meta-information is set according to the state of the virtual
subscription. The meanings of the "state" attribute are described in
RFC 3265 [2].
If an instance of a resource was previously reported to the
subscriber but is no longer available (i.e., the virtual subscription
to that instance has been terminated), the resource list server
SHOULD include that resource instance in the meta-information in the
first NOTIFY message sent to the subscriber following the instance’s
unavailability. The RLS MAY continue to do so for future
notifications.
When sending information for a terminated resource instance, the RLS
indicates a state of "terminated" and an appropriate reason value.
Valid reason values and their meanings are described in RFC 3265 [2].
If the RLS will attempt to recover the resource state again at some
point in the future (e.g., when the reason in the meta-information is
"probation"), then the instance of the resource SHOULD remain in the
meta-information until the instance state is available, or until the
RLS gives up on making such state available.
When the first SUBSCRIBE message for a particular subscription is
received by an RLS, the RLS will often not know state information for
all the resources specified by the resource list. For any resource
for which state information is not known, the corresponding "uri"
attribute will be set appropriately, and no <instance> elements will
be present for the resource.
For an initial notification, sections corresponding to resources for
which the RLS does have state will be populated with appropriate data
(subject, of course, to local policy decisions). This will often
occur if the resource list server is co-located with the server for
one or more of the resources specified on the list.
Immediate notifications triggered as a result of subsequent SUBSCRIBE
messages SHOULD include an RLMI document in which the full state is
indicated. The RLS SHOULD also include state information for all
resources in the list for which the RLS has state, subject to policy
restrictions. This allows the subscriber to refresh their state, and
to recover from lost notifications.
4.6. Subscriber Processing of NOTIFY Requests
Notifications for a resource list can convey information about a
subset of the list elements. This means that an explicit algorithm
needs to be defined in order to construct coherent and consistent
state.
The XML document present in the root of the multipart/related
document contains a <resource> element for some or all of the
resources in the list. Each <resource> element contains a URI that
uniquely identifies the resource to which that section corresponds.
When a NOTIFY arrives, it can contain full or partial state (as
indicated by the "fullState" attribute of the top-level <list>
element). If full state is indicated, then the recipient replaces
all state associated with the list with the entities in the NOTIFY
body. If full state is not indicated, the recipient of the NOTIFY
updates information for each identified resource. Information for
any resources that are not identified in the NOTIFY is not changed,
even if they were indicated in previous NOTIFY messages. See
Section 5.6 for more information.
When full state is indicated, note that it applies only to the
RLMI document in which it occurs. In particular, one of the
<resource> elements in the document may in turn refer to another
list of resources. Any such sub-lists will be detailed in their
own RLMI documents, which may or may not have full state
indicated.
Further note that the underlying event package may have its own
rules for compositing partial state notification. When processing
data related to those packages, their rules apply (i.e., the fact
that they were reported as part of a list does not change their
partial notification semantics).
Finally, note that as a consequence of the way in which resource
list subscriptions work, polling of resource state may not be
particularly useful. While such polls will retrieve the resource
list, they will not necessarily contain state for some or all of
the resources on the list.
4.7. Handling of Forked Requests
Forking makes little sense with subscriptions to event lists, since
the whole idea is a centralization of the source of notifications.
Therefore, a subscriber to a list MUST NOT install multiple
subscriptions when the initial request is forked. If multiple
responses are received, they are handled using the techniques
described in Section 4.4.9 of RFC 3265 [2].
4.8. Rate of Notifications
One potential role of the RLS is to perform rate limitations on
behalf of the subscriber. As such, this specification does not
mandate any particular rate limitation, and rather leaves that to the
discretion of the implementation.
5. Using multipart/related to Convey Aggregate State
In order to convey the state of multiple resources, the list
extension uses the "multipart/related" mime type. The syntax for
multipart/related is defined in "The MIME Multipart/Related Content-
type" [4].
5.1. XML Syntax
The root document of the multipart/related body MUST be a Resource
List Meta-Information (RLMI) document. It is of the type
"application/rlmi+xml". This document contains the meta-information
for the resources contained in the notification. The schema for this
XML document is given below.
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:rlmi"
elementFormDefault="qualified"
xmlns="urn:ietf:params:xml:ns:rlmi"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:element name="list">
<xs:complexType>
<xs:sequence>
<xs:element ref="name" minOccurs="0"
maxOccurs="unbounded" />
<xs:element ref="resource" minOccurs="0"
maxOccurs="unbounded" />