Network Working Group A. B. Roach
Internet-Draft J. Rosenberg
Expires: November 3, 2003 B. Campbell
dynamicsoft
May 5, 2003
A Session Initiation Protocol (SIP) Event Notification Extension for
Resource Lists
draft-ietf-simple-event-list-02
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 November 3, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
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 the subscriber
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.
Roach, et al. Expires November 3, 2003 [Page 1]
Internet-Draft SIP Event Lists May 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Operation . . . . . . . . . . . . . . . . . . . 5
4. Operation of List Subscriptions . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . 8
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 . . . . . 11
5.1 XML Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2 List Attributes . . . . . . . . . . . . . . . . . . . . . . 12
5.3 Resource Attributes . . . . . . . . . . . . . . . . . . . . 13
5.4 Instance Attributes . . . . . . . . . . . . . . . . . . . . 13
5.5 Constructing Coherent Resource State . . . . . . . . . . . . 15
5.5.1 Processing Full State Notifications . . . . . . . . . . . . 16
5.5.2 Processing Partial State Notifications . . . . . . . . . . . 16
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . 30
7.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 30
7.2 Risks of Improper Aggregation . . . . . . . . . . . . . . . 30
7.3 Signing and Sealing . . . . . . . . . . . . . . . . . . . . 31
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32
8.1 New SIP Option Tag: eventlist . . . . . . . . . . . . . . . 32
8.2 New MIME type for Resource List Meta-Information . . . . . . 32
8.3 URN Sub-Namespace . . . . . . . . . . . . . . . . . . . . . 33
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
Normative References . . . . . . . . . . . . . . . . . . . . 36
Non-Normative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37
A. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.1 Changes since -01 . . . . . . . . . . . . . . . . . . . . . 39
A.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . . 39
B. Intellectual Property Statement . . . . . . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . . 41
Roach, et al. Expires November 3, 2003 [Page 2]
Internet-Draft SIP Event Lists May 2003
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 having the subscriber
generate 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 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 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 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.
Roach, et al. Expires November 3, 2003 [Page 3]
Internet-Draft SIP Event Lists May 2003
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 a 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: Virtual Subscriptions are a logical construct
within an RLS that represent 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.
Roach, et al. Expires November 3, 2003 [Page 4]
Internet-Draft SIP Event Lists May 2003
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 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 of 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.
Roach, et al. Expires November 3, 2003 [Page 5]
Internet-Draft SIP Event Lists May 2003
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 of the resources in the resource list.
It is worth noting 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 a 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.
It is important to 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 RFC3261 [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.
Roach, et al. Expires November 3, 2003 [Page 6]
Internet-Draft SIP Event Lists May 2003
Use of "Require: eventlist" in NOTIFY messages is applied by the
notifier to satisfy the RFC3261 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, and is consequently NOT RECOMMENDED.
There is nothing in a SIP URI which 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 servers to 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 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.
Roach, et al. Expires November 3, 2003 [Page 7]
Internet-Draft SIP Event Lists May 2003
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
value propositions of the RLS is the means by which it aggregates,
rate limits, or optimizes 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.
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
one or more resources, and that the resources contains one 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 a RLS, the RLS will often not know state information for
Roach, et al. Expires November 3, 2003 [Page 8]
Internet-Draft SIP Event Lists May 2003
all of 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 with full state 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 which
uniquely identifies the resource to which that section corresponds.
When a NOTIFY arrives, it can contain full or partial state (as
indicate 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 are not changed,
even if they were indicated in previous NOTIFY messages. See Section
5.5 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 underlying event package may have its own rules
for compositing partial state notification. When processing data
Roach, et al. Expires November 3, 2003 [Page 9]
Internet-Draft SIP Event Lists May 2003
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 a consequence of the way in which resource list
subscriptions work is that 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.
Roach, et al. Expires November 3, 2003 [Page 10]
Internet-Draft SIP Event Lists May 2003
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 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:element name="list">
<xs:complexType>
<xs:sequence>
<xs:element ref="resource" minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required" />
<xs:attribute name="version" type="xs:unsignedInt" use="required" />
<xs:attribute name="fullState" type="xs:boolean" use="required" />
<xs:attribute name="name" type="xs:string" use="optional" />
<xs:attribute name="cid" type="xs:string" use="optional" />
<xs:anyAttribute />
</xs:complexType>
</xs:element>
<xs:element name="resource">
<xs:complexType>
<xs:sequence>
<xs:element ref="instance" minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required" />
<xs:attribute name="name" type="xs:string" use="optional" />
<xs:anyAttribute />
</xs:complexType>
</xs:element>
<xs:element name="instance">
<xs:complexType>
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded" />
Roach, et al. Expires November 3, 2003 [Page 11]
Internet-Draft SIP Event Lists May 2003
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required" />
<xs:attribute name="state" type="xs:string" use="required" />
<xs:attribute name="reason" type="xs:string" use="optional" />
<xs:attribute name="cid" type="xs:string use="optional" />
<xs:anyAttribute />
</xs:complexType>
</xs:element>
</xs:schema>
An example of a document formatted using this schema follows.
<?xml version="1.0"?>
<list xmlns="urn:ietf:params:xml:ns:rmli"
uri="sip:adam-friends@lists.example.com" version="7"
name="Buddy List" fullState="true">
<resource uri="sip:bob@example.com" name="Bob Smith">
<instance id="juwigmtboe" state="active" cid="12345.aaa@example.com"/>
</resource>
<resource uri="sip:dave@example.com" name="Dave Jones">
<instance id="hqzsuxtfyq" state="active" cid="12345.aab@example.com"/>
</resource>
<resource uri="sip:jim@example.com" name="Jim">
<instance id="oflzxqzuvg" state="terminated" reason="rejected" />
</resource>
<resource uri="sip:ed@example.com" name="Ed">
<instance id="grqhzsppxb" state="pending"/>
</resource>
</list>
5.2 List Attributes
The <list> element present in a list notification MUST contain three
attributes.
The first mandatory <list> attribute is "uri", which contains the uri
that corresponds to the list. Typically, this is the URI to which
the SUBSCRIBE request was sent.
The second mandatory <list> attribute is "version", which contains a
number from 0 to 2^32-1. This version number MUST be 0 for the first
NOTIFY message sent within a subscription, and MUST increase by
exactly one for each subsequent NOTIFY sent within a subscription.
The third mandatory attribute is "fullState". The "fullState"
Roach, et al. Expires November 3, 2003 [Page 12]
Internet-Draft SIP Event Lists May 2003
attribute indicates whether the NOTIFY message contains information
for every resource in the list. If it does, the value of the
attribute is "true" (or "1"); otherwise, it is "false" (or "0"). The
first NOTIFY sent in a subscription MUST contain full state, as must
the first NOTIFY sent after receipt of a SUBSCRIBE request for the
subscription.
The optional "name" attribute contains a human readable description
or name for the resource list. This attribute is somewhat analogous
to the "Display Name" present in the SIP name-addr element.
Finally, <list> elements MAY contain a "cid" attribute. If present,
the "cid" attribute identifies a section within the multipart/related
body that contains aggregate state information for the resources
contained in the list. The definition of such aggregate information
is outside the scope of this document, and will be defined on a per-
package basis as needed. The cid attribute is the Content-ID for the
corresponding section in the multipart body.
The cid attribute MUST refer only to top-level parts of the
multipart/related document for which the RLMI document in which it
appears is the root. See Section 5.4 for an example.
5.3 Resource Attributes
The resource list contains one <resource> element for each resource
being reported in the notification. These resource elements contain
attributes that identify meta-data assocated with each resource.
The "uri" attribute identifies the resource to which the <resource>
element corresponds. Typically, this will be a SIP URI which, if
subscribed to, would return the state of the resource. This
attribute MUST be present.
The optional "name" attribute can contain a human readable
description or name for the resource. This attribute is somewhat
analogous to the "Display Name" present in the SIP name-addr element.
5.4 Instance Attributes
Each resource element contains one or more instance elements. These
instance elements are used to represent a single notifier for the
resource. For event packages that allow forking, multiple virtual
subscriptions may exist for a given resource. Multiple virtual
subscriptions are represented as multiple instance elements in the
corresponding resource element. For subscriptions in which forking
does not occur, at most one instance will be present for a given
resource.
Roach, et al. Expires November 3, 2003 [Page 13]
Internet-Draft SIP Event Lists May 2003
The "id" attribute contains an opaque string used to uniquely
identify the instance of the resource. The "id" attribute is unique
only within the context of a resource. Construction of this string
is an implementation decision. Any mechanism for generating this
string is valid, as long as uniqueness within the resource is
assured.
The "state" attribute contains the subscription state for the
identified instance of the resource. This attribute contains one of
the values "active", "pending", or "terminated". The meanings for
these values are as defined for the "Subscription-State" header field
in RFC 3265 [2].
If the "state" attribute indicates "terminated", then a "reason"
attribute MUST also be present. This "reason" attribute has the same
values and meanings as given for the "reason" parameter on the
"Subscription-State" header field in RFC 3265 [2]. Note that the
"reason" attribute is included for informational purposes; the list
subscriber is not expected to take any automated actions based on the
reason value.
Finally, the "cid" attribute, which MUST be present if the "state"
attribute is "active", identifies the section within the multipart/
related body that contains the actual resource state. This state is
expressed in the content type defined by the event package for
conveying state. The cid attribute is the Content-ID for the
corresponding section in the multipart body.
The cid attribute MUST refer only to top-level parts of the
multipart/related document for which the RLMI document in which it
appears is the root.
For example, consider a multipart/related document containing
three parts; we'll label these parts A, B, and C. Part A is type
application/rlmi+xml, part B is type multipart/related, and part C
is type application/cpim-pidf+xml. Part B is in turn a document
containing three parts: D, E, and F. Part D is of type
application/rlmi+xml, and parts E and F are of type application/
cpim-pidf+xml.
Roach, et al. Expires November 3, 2003 [Page 14]
Internet-Draft SIP Event Lists May 2003
+-------------------------------------------+
| Top Level Document: multipart/related |
| |
| +---------------------------------------+ |
| | Part A: application/rlmi+xml | |
| +---------------------------------------+ |
| | Part B: multipart/related | |
| | | |
| | +-----------------------------------+ | |
| | | Part D: application/rlmi+xml | | |
| | +-----------------------------------+ | |
| | | Part E: application/cpim-pidf+xml | | |
| | +-----------------------------------+ | |
| | | Part F: application/cpim-pidf+xml | | |
| | +-----------------------------------+ | |
| | | |
| +---------------------------------------+ |
| | Part C: application/cpim-pidf+xml | |
| +---------------------------------------+ |
| |
+-------------------------------------------+
Any "cid" attributes in document A must refer only to parts B or
C. Referring to parts D, E, or F would be illegal. Similarly,
Any "cid" attributes in document D must refer only to parts E or
F. Referring to any other parts would be illegal.
Also note that the subscription durations of any back-end
subscriptions are not propagated into the meta-information state
in any way.
5.5 Constructing Coherent Resource State
The resource list subscriber maintains a table for each resource
list. The table contains a row for each resource in the resource
list. Each row is indexed by the URI for that resource. That URI is
obtained from the "uri" attribute on each <resource> element. The
contents of each row contain the state of that resource as conveyed
in the resource document.
For resources that provide versioning information (which is mandated
by [2] for any formats that allow partial notification), each row
also contains a resource state version number. The version number of
the row is initialized with the version specified in the first
document received, as defined by the corrsponding event package.
This value is used when comparing versions of partial notifications
for a resource.
Roach, et al. Expires November 3, 2003 [Page 15]
Internet-Draft SIP Event Lists May 2003
The processing of the resource list notification depends on whether
it contains full or partial state.
5.5.1 Processing Full State Notifications
If a notification contains full state, indicated by the value of the
<list> attribute "fullState", the notification is used to update the
table. A check is first made to ensure that the "version" attribute
of the <list> attribute in the received message is greater than the
local version number. If not, the received document is discarded
without any further processing. Otherwise, the contents of the
resource-list table are flushed, and repopulated from the contents of
the document. A new row in the table is created for each "resource"
element.
5.5.2 Processing Partial State Notifications
If a notification contains partial state, indicated by the value of
the <list> attribute "fullState", a check is made to ensure that no
list notifications have been lost. The value of the local version
number (the "version" attribute of the <list> element) is compared to
the version number of the new document.
o If the value in the new document is exactly one higher than the
local version number, the local version number is increased by
one, and the document is processed, as described below.
o If the version in the document is more than one higher than the
local version number, the local version number is set to the value
in the new document, and the document is processed as described
below. Further, if the notification does not contain full state
(as indicated by the "fullState" attribute of the <list> element),
the list subscriber SHOULD generate a refresh request to trigger a
full state notification.
o If the version in the document is less than or equal to the local
version, the document is discarded without any further processing.
For each resource listed in the document, the subscriber checks to
see whether a row exists for that resource. This check is done by
comparing the Resource-URI value with the URI associated with the
row. If the resource doesn't exist in the table, a row is added, and
its state is set to the information from that "resource" element. If
the resource does exist, its state is updated to be the information
from that "resource" element, as described in the definition of the
event package. If a row is updated or created such that its state is
now "terminated," that entry MAY be removed from the table at any
time.
Roach, et al. Expires November 3, 2003 [Page 16]
Internet-Draft SIP Event Lists May 2003
6. Example
This section gives an example callflow. It is not normative. If a
conflict arises between this callflow and the normative behavior
described in this or any other document, the normative descriptions
are to be followed.
In this particular example, we request a subscription to a nested
presence list. The subscriber's address-of-record is
"sip:adam@example.com", and the name of the nested list resource that
we are subscribing to is called "sip:adam-buddies@pres.example.com".
The underlying event package is "presence", described by [6].
In this example, the RLS has information to service some of the
resources on the list, but must consult other servers to retrive
information for others. The implementation of the RLS in this
example uses the SIP SUBSCRIBE/NOTIFY mechanism to retrieve such
information.
Terminal pres.example.com pres.example.org
| | pres.example.net |
1 |---SUBSCRIBE--->| | |
2 |<-----200-------| | |
3 |<----NOTIFY-----| | |
4 |------200------>| | |
5 | |---SUBSCRIBE--->| |
6 | |<-----200-------| |
7 | |<----NOTIFY-----| |
8 | |------200------>| |
9 | |------------SUBSCRIBE----------->|
10| |<--------------200---------------|
11| |<-------------NOTIFY-------------|
12| |---------------200-------------->|
13|<----NOTIFY-----| | |
14|------200------>| | |
1. We initate the subscription by sending a SUBSCRIBE message to
our local RLS. (There is no reason that the RLS we contact has
to be in our domain, of course). Note that we must advertise
support for application/rlmi+xml and multipart/related because
we support the eventlist extension, and we must advertise
application/cpim-pidf+xml because we are requesting a
subscription to presence.
Roach, et al. Expires November 3, 2003 [Page 17]
Internet-Draft SIP Event Lists May 2003
Terminal -> Local RLS
SUBSCRIBE sip:adam-buddies@pres.example.com SIP/2.0
Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL
Max-Forwards: 70
To: <sip:adam-buddies@pres.example.com>
From: <sip:adam@example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.example.com
CSeq: 322723822 SUBSCRIBE
Contact: <sip:terminal.example.com>
Event: presence
Expires: 7200
Supported: eventlist
Accept: application/cpim-pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Accept: multipart/signed
Accept: multipart/encrypted
Content-Length: 0
2. The Local RLS completes the SUBSCRIBE transaction. Note that
authentication and authorization would normally take place at
this point in the callflow. Those steps are omitted for
brevity.
Local RLS -> Terminal
SIP/2.0 200 OK
Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL
To: <sip:adam-buddies@pres.example.com>;tag=zpNctbZq
From: <sip:adam@example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.example.com
CSeq: 322723822 SUBSCRIBE
Contact: <sip:pres.example.com>
Expires: 7200
Require: eventlist
Content-Length: 0
3. As is required by RFC 3265 [2], the RLS sends a NOTIFY
immediately upon accepting the subscription. In this example,
we are assuming that the local RLS is also an authority for
presence information for the users in the "example.com" domain.
The NOTIFY contains an RLMI document describing the entire buddy
list (initial notifies require full state), as well as presence
Roach, et al. Expires November 3, 2003 [Page 18]
Internet-Draft SIP Event Lists May 2003
information for the users about which it already knows. Note
that, since the RLS has not yet retrieved information for some
of the entries on the list, those <resource> elements contain no
<instance> elements.
Local RLS -> Terminal
NOTIFY sip:terminal.example.com SIP/2.0
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMgRenTETmm
Max-Forwards: 70
From: <sip:adam-buddies@pres.example.com>;tag=zpNctbZq
To: <sip:adam@example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.example.com
CSeq: 997935768 NOTIFY
Contact: <sip:pres.example.com>
Event: presence
Subscription-State: active;expires=7200
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";
start="<nXYxAE@pres.example.com>";boundary="50UBfW7LSCVLtggUPe5z"
Content-Length: 1560
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: 8bit
Content-ID: <nXYxAE@pres.example.com>
Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rmli"
uri="sip:adam-friends@pres.example.com" version="1"
name="Buddy List at COM" fullState="true">
<resource uri="sip:bob@example.com" name="Bob Smith">
<instance id="juwigmtboe" state="active" cid="bUZBsM@pres.example.com"/>
</resource>
<resource uri="sip:dave@example.com" name="Dave Jones">
<instance id="hqzsuxtfyq" state="active" cid="ZvSvkz@pres.example.com"/>
</resource>
<resource uri="sip:ed@example.net" name="Ed at NET" />
<resource uri="sip:adam-friends@example.org" name="My Friends at ORG" />
</list>
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: 8bit
Content-ID: <bUZBsM@pres.example.com>
Content-Type: application/cpim-pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
Roach, et al. Expires November 3, 2003 [Page 19]
Internet-Draft SIP Event Lists May 2003
entity="sip:bob@example.com">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">sip:bob@example.com</contact>
</tuple>
</presence>
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: 8bit
Content-ID: <ZvSvkz@pres.example.com>
Content-Type: application/cpim-pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
entity="sip:dave@example.com">
<tuple id="slie74">
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>
--50UBfW7LSCVLtggUPe5z--
4. The terminal completes the transaction.
Terminal -> Local RLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMgRenTETmm
From: <sip:adam-buddies@pres.example.com>;tag=zpNctbZq
To: <sip:adam@example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.example.com
CSeq: 997935768 NOTIFY
Contact: <sip:terminal.example.com>
Content-Length: 0
5. In order to service the subscription, the local RLS subscribes
to the state of the resources. In this step, the RLS attempts
to subscribe to the presence state of the resource
"sip:ed@example.net". Since the local RLS knows how to receive
notifications for list subscriptions, it includes the
Roach, et al. Expires November 3, 2003 [Page 20]
Internet-Draft SIP Event Lists May 2003
"Supported: eventlist" header field in its request. Although
the linkage between this subscription and the one sent by the
terminal is left up to the application, this message
demonstrates some reasonable behavior by including "Accept"
header fields for all of the body types it knows the subscriber
(Terminal) supports. This is safe to do, since the local RLS
will only pass these formats through to the subscriber, and does
not need to actually understand them.
Local RLS -> Presence Server in example.net
SUBSCRIBE sip:ed@example.net SIP/2.0
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMEyGjdG1LH
Max-Forwards: 70
To: <sip:ed@example.net>
From: <sip:pres.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.example.com
CSeq: 870936068 SUBSCRIBE
Contact: <sip:pres.example.com>
Event: presence
Expires: 3600
Supported: eventlist
Accept: application/cpim-pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Accept: multipart/signed
Accept: multipart/encrypted
Content-Length: 0
6. The Presence Server in example.net completes the SUBSCRIBE
transaction. Note that authentication would normally take place
at this point in the callflow. Those steps are omitted for
brevity.
Roach, et al. Expires November 3, 2003 [Page 21]
Internet-Draft SIP Event Lists May 2003
Presence Server in example.net -> Local RLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMEyGjdG1LH
To: <sip:ed@example.net>;tag=e45TmHTh
From: <sip:pres.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.example.com
CSeq: 870936068 SUBSCRIBE
Contact: <sip:example.net>
Expires: 3600
Content-Length: 0
7. In this example, we assume that the server at example.net
doesn't have enough authorization information to reject or
accept our subscription. The initial notify, therefore,
contains a "Subscription-State" of "pending". Presumably, the
party responsible for accepting or denying authorization for the
resource is notified of this change; however, those steps are
not included in this call flow for brevity.
Presence Server in example.net -> Local RLS
NOTIFY sip:pres.example.com SIP/2.0
Via: SIP/2.0/TCP pres.example.net;branch=z9hG4bKfwpklPxmrW
Max-Forwards: 70
From: <sip:ed@example.net>;tag=e45TmHTh
To: <sip:pres.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.example.com
CSeq: 1002640632 NOTIFY
Contact: <sip:example.net>
Subscription-State: pending;expires=3600
Event: presence
Require: eventlist
Content-Length: 0
8. The local RLS completes the NOTIFY transaction. Note that, at
this point, the Local RLS has new information to report to the
subscriber. Whether it chooses to report the information
immediately or spool it up for later delivery is completely up
to the application. For this example, we assume that the RLS
will wait for a short period of time before doing so, in order
to allow the subscriptions it sent out sufficient time to
provide useful data.
Roach, et al. Expires November 3, 2003 [Page 22]
Internet-Draft SIP Event Lists May 2003
Local RLS -> Presence Server in example.net
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.net;branch=z9hG4bKfwpklPxmrW
From: <sip:ed@example.net>;tag=e45TmHTh
To: <sip:pres.example.com>;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.example.com
CSeq: 1002640632 NOTIFY
Contact: <sip:pres.example.com>
Content-Length: 0
9. The Local RLS subscribes to the state of the other non-local
resource.
Local RLS -> RLS in example.org
SUBSCRIBE sip:adam-friends@example.org SIP/2.0
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKFSrAF8CZFL
Max-Forwards: 70
To: <sip:adam-friends@example.org>
From: <sip:pres.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.example.com
CSeq: 980774491 SUBSCRIBE
Contact: <sip:pres.example.com>
Event: presence
Expires: 3600
Supported: eventlist
Accept: application/cpim-pidf+xml
Accept: application/rlmi+xml
Accept: multipart/related
Accept: multipart/signed
Accept: multipart/encrypted
Content-Length: 0
10. The RLS in example.org completes the SUBSCRIBE transaction.
Note that authentication and would normally take place at this
point in the callflow. Those steps are omitted for brevity.
Roach, et al. Expires November 3, 2003 [Page 23]
Internet-Draft SIP Event Lists May 2003
RLS in example.org -> Local RLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKFSrAF8CZFL
To: <sip:adam-friends@example.org>;tag=JenZ40P3
From: <sip:pres.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.example.com
CSeq: 980774491 SUBSCRIBE
Contact: <sip:example.org>
Expires: 3600
Content-Length: 0
11. In this example, we are assuming that the RLS in example.org is
also an authority for presence information for the users in the
"example.org" domain. The NOTIFY contains an RLMI document
describing the contained buddy list, as well as presence
information for those users. In this particular case, the RLS
in example.org has chosen to sign [13] the body of the NOTIFY
message. As described in RFC 2633, signing is performed by
creating a multipart/signed document which has two parts. The
first part is the document to be signed (in this example, the
multipart/related document that describes the list resource
states), while the second part is the actual signature.
RLS in example.org -> Local RLS
NOTIFY sip:pres.example.com SIP/2.0
Via: SIP/2.0/TCP pres.example.org;branch=z9hG4bKmGL1nyZfQI
Max-Forwards: 70
From: <sip:adam-friends@example.org>;tag=JenZ40P3
To: <sip:pres.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.example.com
CSeq: 294444656 NOTIFY
Contact: <sip:example.org>
Event: presence
Subscription-State: active;expires=3600
Require: eventlist
Content-Type: multipart/signed;protocol="application/pkcs7-signature";
micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU"
Content-Length: 2038
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: 8bit
Content-ID: <ZPvJHL@example.org>
Content-Type: multipart/related;type="application/rlmi+xml";
start="<Cvjpeo@example.org>";boundary="tuLLl3lDyPZX0GMr2YOo"
Roach, et al. Expires November 3, 2003 [Page 24]
Internet-Draft SIP Event Lists May 2003
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: 8bit
Content-ID: <Cvjpeo@example.org>
Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rmli"
uri="sip:adam-friends@example.org" version="1"
name="Buddy List at ORG" fullState="true">
<resource uri="sip:joe@example.org" name="Joe Thomas">
<instance id="1" state="active" cid="mrEakg@example.org"/>
</resource>
<resource uri="sip:mark@example.org" name="Mark Edwards">
<instance id="1" state="active" cid="KKMDmv@example.org"/>
</resource>
</list>
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: 8bit
Content-ID: <mrEakg@example.org>
Content-Type: application/cpim-pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
entity="sip:joe@example.org">
<tuple id="7823a4">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">sip:joe@example.org</contact>
</tuple>
</presence>
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: 8bit
Content-ID: <KKMDmv@example.org>
Content-Type: application/cpim-pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
entity="sip:mark@example.org">
<tuple id="398075">
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>
Roach, et al. Expires November 3, 2003 [Page 25]
Internet-Draft SIP Event Lists May 2003
--tuLLl3lDyPZX0GMr2YOo--
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: 8bit
Content-ID: <K9LB7k@example.org>
Content-Type: application/pkcs-signature
[PKCS #7 signature here]
--l3WMZaaL8NpQWGnQ4mlU--
12. The Local RLS completes the NOTIFY transaction.
Local RLS -> RLS in example.org
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.org;branch=z9hG4bKmGL1nyZfQI
From: <sip:adam-friends@example.org>;tag=JenZ40P3
To: <sip:pres.example.com>;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.example.com
CSeq: 294444656 NOTIFY
Contact: <sip:pres.example.com>
Content-Length: 0
13. At this point, the Local RLS decides it has collected enough
additional information to warrant sending a new notification to
the user. Although sending a full notification would be
perfectly acceptable, the RLS decides to send a partial
notification instead. The RLMI document contains only
information for the updated resources, as indicated by setting
the "fullState" parameter to "false". To avoid corrupting the
S/MIME signature on the data received from the RLS in
example.org, the local RLS copies the entire application/signed
body as-is into the notification that it sends.
Local RLS -> Terminal
NOTIFY sip:terminal.example.com SIP/2.0
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1
Max-Forwards: 70
From: <sip:adam-buddies@pres.example.com>;tag=zpNctbZq
To: <sip:adam@example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.example.com
CSeq: 997935769 NOTIFY
Roach, et al. Expires November 3, 2003 [Page 26]
Internet-Draft SIP Event Lists May 2003
Contact: <sip:pres.example.com>
Event: presence
Subscription-State: active;expires=7200
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";
start="<2BEI83@pres.example.com>";boundary="TfZxoxgAvLqgj4wRWPDL"
Content-Length: 2862
--TfZxoxgAvLqgj4wRWPDL
Content-Transfer-Encoding: 8bit
Content-ID: <2BEI83@pres.example.com>
Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rmli"
uri="sip:adam-friends@pres.example.com" version="2"
name="Buddy List at COM" fullState="false">
<resource uri="sip:ed@example.net" name="Ed at NET">
<instance id="sdlkmeopdf" state="pending"/>
</resource>
<resource uri="sip:adam-friends@example.org" name="My Friends at ORG">
<instance id="cmpqweitlp" state="active" cid="1KQhyE@pres.example.com"/>
</resource>
</list>
--TfZxoxgAvLqgj4wRWPDL
Content-Transfer-Encoding: 8bit
Content-ID: <1KQhyE@pres.example.com>
Content-Type: multipart/signed;protocol="application/pkcs-signature";
micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU"
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: 8bit
Content-ID: <ZPvJHL@example.org>
Content-Type: multipart/related;type="application/rlmi+xml";
start="<Cvjpeo@example.org>";boundary="tuLLl3lDyPZX0GMr2YOo"
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: 8bit
Content-ID: <Cvjpeo@example.org>
Content-Type: application/rlmi+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rmli"
uri="sip:adam-friends@example.org" version="1"
name="Buddy List at ORG" fullState="true">
<resource uri="sip:joe@example.org" name="Joe Thomas">
<instance id="1" state="active" cid="mrEakg@example.org"/>
Roach, et al. Expires November 3, 2003 [Page 27]
Internet-Draft SIP Event Lists May 2003
</resource>
<resource uri="sip:mark@example.org" name="Mark Edwards">
<instance id="1" state="active" cid="KKMDmv@example.org"/>
</resource>
</list>
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: 8bit
Content-ID: <mrEakg@example.org>
Content-Type: application/cpim-pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
entity="sip:joe@example.org">
<tuple id="7823a4">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">sip:joe@example.org</contact>
</tuple>
</presence>
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: 8bit
Content-ID: <KKMDmv@example.org>
Content-Type: application/cpim-pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
entity="sip:mark@example.org">
<tuple id="398075">
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>
--tuLLl3lDyPZX0GMr2YOo--
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: 8bit
Content-ID: <K9LB7k@example.org>
Content-Type: application/pkcs-signature
[PKCS #7 signature here]
--l3WMZaaL8NpQWGnQ4mlU--
Roach, et al. Expires November 3, 2003 [Page 28]
Internet-Draft SIP Event Lists May 2003
--TfZxoxgAvLqgj4wRWPDL--
14. The terminal completes the NOTIFY transaction.
Terminal -> Local RLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1
From: <sip:adam-buddies@pres.example.com>;tag=zpNctbZq
To: <sip:adam@example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.example.com
CSeq: 997935769 NOTIFY
Contact: <sip:terminal.example.com>
Content-Length: 0
Roach, et al. Expires November 3, 2003 [Page 29]
Internet-Draft SIP Event Lists May 2003
7. Security Considerations
Note that the mechanisms for obtaining state information for
resources in a list are generally left to the RLS implementor. Some
of the security issues below are specific to the the circumstance
that a SIP back-end subscription is used for such a purpose. Non-SIP
mechanisms for obtaining state information of resources in a list
will typically have their own security issues associated with doing
so; however, exhaustively enumerating such access methods is not
possible in this document. Implementors using such mechanisms must
analyze their chosen access methods for relevant security issues.
7.1 Authentication
The usage of the RLS does introduce some security considerations. If
back-end subscriptions are required to retrieve resource state
information, the end user is no longer the direct subscriber to the
state of the resource. If the notifier for the resource demands end-
to-end authentication, the RLS will need to be provided appropriate
credentials to access those resources (e.g. shared secrets for
Digest authentication). This requires a certain level of trust
between the user and their RLS. This specification does not describe
any particular means of providing such credentials to the RLS (such
as uploading a shared secret). However, any such upload mechanism
MUST ensure privacy of the key data; using HTTPS [15] to fill out a
form is a reasonable method.
If the notifier for the resource is using a transitive trust model to
validate the subscriber, then this works well with the RLS concept
and back-end subscriptions. The RLS would authenticate the
subscriber, and then MAY use the SIP extensions for network asserted
identity [7][8] to provide an authenticated identity to the notifiers
for the resource.
7.2 Risks of Improper Aggregation
A resource list server typically serves information to multiple
subscribers at once. In many cases, resources may be present in
several lists; additionally, it is quite possible that resource list
servers will have two users subscribe to the same list.
In these cases, misguided RLS implementations may attempt to minimize
network load by maintaining only one back-end subscription to a
resource in a list, and presenting the result of such a subscription
to more than one user. Of course, doing so circumvents any
authorization policy that the notifier for the resource maintains.
It is important to keep in mind that authorization is often much more
than a simple binary "allowed/not allowed" decision; resources may
Roach, et al. Expires November 3, 2003 [Page 30]
Internet-Draft SIP Event Lists May 2003
render very different -- and even conflicting -- resource states,
depending on the identity of the subscribing user.
Implementations MUST NOT attempt to perform this type of optimization
unless adequate access to complete authorizaton policy can be
guaranteed. Note that this is a very difficult problem to solve
correctly. Even in the cases that such access is believed possible,
this mode of operation is NOT RECOMMENDED.
7.3 Signing and Sealing
Implementors should keep in mind that any section of the MIME body
may be signed and/or encrypted as necessary. Resource List Servers
should take care not to modify any MIME bodies they receive from any
back-end subscriptions, and should not generally rely on being able
to read them.
In order to facilitate security, resource list servers SHOULD pass
along indication for support of "multipart/signed" and "multipart/
encrypted" content types to any SIP back-end subscriptions, if the
subscriber includes them in the initial SUBSCRIBE message. Not doing
so may actually result in resources refusing to divulge state (if
notifier policy requires encryption, but the RLS fails to convey
support), or subscribers discarding valid state (if subscriber policy
requires a signature, but the RLS fails to convey support).
Note that actual implemetation of encryption and signing by the RLS
is not necessary to be able to pass through signed and/or encrypted
bodies.
Roach, et al. Expires November 3, 2003 [Page 31]
Internet-Draft SIP Event Lists May 2003
8. IANA Considerations
8.1 New SIP Option Tag: eventlist
This section defines a new option tag for the registry established by
section 27.1 of RFC 3261[1].
Option Tag Name: eventlist
Description: Extension to allow subscriptions to lists of resources
Published specification: RFC xxxx [[Note to RFC editor: replace xxxx
with the RFC number of this document when published]]
8.2 New MIME type for Resource List Meta-Information
MIME Media Type Name: application
MIME subtype name: rlmi+xml
Required parameters: None
Optional parameters: charset
See RFC 3023 [12] for a discussion of the charset parameter on
XML-derived MIME types. Since this MIME type is used exclusively
in SIP, the use of UTF-8 encoding is strongly encouraged.
Encoding considerations: 8-bit text
Security considerations: Security considerations specific to uses of
this this MIME type are discussed in RFC xxxx [[Note to RFC
editor: replace xxxx with the RFC number of this document when
published]]. RFC 1874 [11] and RFC 3023 [12] discuss security
issues common to all uses of XML.
Interoperability considerations: The use of this MIME body is
intended to be generally interoperable. No unique considerations
have been identified.
Published specification: RFC xxxx [[Note to RFC editor: replace xxxx
with the RFC number of this document when published]]
Applications which use this media type: This media type is used to
convey meta-information for the state of lists of resources within
a Session Initiation Protocol (SIP) subscription.
Roach, et al. Expires November 3, 2003 [Page 32]
Internet-Draft SIP Event Lists May 2003
Additional information:
Magic Number(s): None.
File Extension(s): None.
Macintosh File Type Code(s): None.
Object Identifier(s) or OID(s): None.
Intended usage: Limited Use
Other Information/General Comment: None.
Person to contact for further information:
Name: Adam Roach
E-Mail: adam@dynamicsoft.com
Author/Change Controller: The specification of this MIME type is a
work product of the SIMPLE working group, and was authored by
Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has
change control over its specification.
8.3 URN Sub-Namespace
URI: urn:ietf:params:xml:ns:rlmi
Description: This is the XML namespace URI for XML elements defined
by [RFCXXXX] to describe information about subscriptions when such
subscriptions are aggregated within a single SIP subscription. It
is used in the application/rlmi+xml body type.
Registrant Contact:
Name: Adam Roach
E-Mail: adam@dynamicsoft.com
Author/Change Controller: The specification of this MIME type is a
work product of the SIMPLE working group, and was authored by
Adam Roach, Jonathan Rosenberg, and Ben Campbell. The IETF has
change control over its specification.
XML:
Roach, et al. Expires November 3, 2003 [Page 33]
Internet-Draft SIP Event Lists May 2003
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=utf-8"/>
<title>Namespace for SIP Event Resource List
Meta-Information</title>
</head>
<body>
<h1>Namespace for SIP Event Resource List Meta-Information</h1>
<h2>application/rlmi+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
Roach, et al. Expires November 3, 2003 [Page 34]
Internet-Draft SIP Event Lists May 2003
9. Acknowledgements
Thanks to Sean Olson for a review of and corrections to the usage of
XML in this protocol.
Thanks also to Hisham Khartabil, Paul Kyzivat, and Keith Drage for
their careful reviews of and comments on this document.
Roach, et al. Expires November 3, 2003 [Page 35]
Internet-Draft SIP Event Lists May 2003
Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[3] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC 1521, September
1993.
[4] Levinson, E., "The MIME Multipart/Related Content-type", RFC
2387, August 1998.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Roach, et al. Expires November 3, 2003 [Page 36]
Internet-Draft SIP Event Lists May 2003
Non-Normative References
[6] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
in progress), January 2003.
[7] Jennings, C., Peterson, J. and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[8] Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)", draft-
ietf-sip-identity-01 (work in progress), February 2003.
[9] Olson, S., "A Mechanism for Content Indirection in Session
Initiation Protocol (SIP) Messages", draft-ietf-sip-content-
indirect-mech-02 (work in progress), February 2003.
[10] Crocker, D. and J. Peterson, "Common Profile for Presence
(CPP)", draft-ietf-impp-pres-02 (work in progress), February
2003.
[11] Levinson, E., "SGML Media Types", RFC 1874, December 1995.
[12] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[13] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999.
[14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, October 1995.
[15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
Authors' Addresses
Adam Roach
dynamicsoft
5100 Tennyson Pkwy
Suite 1200
Plano, TX 75024
US
EMail: adam@dynamicsoft.com
Roach, et al. Expires November 3, 2003 [Page 37]
Internet-Draft SIP Event Lists May 2003
Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054-2711
US
EMail: jdrosen@dynamicsoft.com
Ben Campbell
dynamicsoft
5100 Tennyson Pkwy
Suite 1200
Plano, TX 75024
US
EMail: bcampbell@dynamicsoft.com
Roach, et al. Expires November 3, 2003 [Page 38]
Internet-Draft SIP Event Lists May 2003
Appendix A. Changes
Note that this section will be removed before publication as an RFC.
A.1 Changes since -01
o Several editorial updates. Change "collection" to "list"
everywhere.
o Added terminology section.
o Added restriction that cid attributes can only point to documents
at the same level as the RLMI document in which they appear.
o Clarified description of how to construct resource state by
splitting discussion of full state notifications apart from
discussion of partial-state notifications.
A.2 Changes since -00
o Removed text in several places which went into detail about
specific implementations which used SIP SUB/NOT for back-end
subscriptions. Some of this text will probably be published later
as part of an implementors' guide.
o Removed specific semantics for "Event" header field parameters and
SUBSCRIBE bodies. These will be defined on a per-package basis,
probably by the filtering work.
o Added "cid" attribute to <list> elements.
o Reworked XML schema definition for meta-information.
o Added IANA registration for XML namespace.
o Minor editorial fixes
Roach, et al. Expires November 3, 2003 [Page 39]
Internet-Draft SIP Event Lists May 2003
Appendix B. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights.
Information on the IETF's procedures with respect to rights in
standards-track and standards-related documentation can be found in
BCP-11. Copies of claims of rights made available for publication
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 implementors or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Roach, et al. Expires November 3, 2003 [Page 40]
Internet-Draft SIP Event Lists May 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Roach, et al. Expires November 3, 2003 [Page 41]