Network Working Group A. B. Roach
Internet-Draft J. Rosenberg
Expires: August 18, 2003 B. Campbell
dynamicsoft
February 17, 2003
A Session Initiation Protocol (SIP) Event Notification Extension for
Collections
draft-ietf-simple-event-list-00
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 August 18, 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 homogenous collection of event packages. Instead of the
subscriber sending a SUBSCRIBE for each resource individually, the
subscriber can subscribe to an entire collection, and then receive
notifications when the state of any of the resources in the
collection changes.
Roach, et al. Expires August 18, 2003 [Page 1]
Internet-Draft SIP Event Lists February 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Operation . . . . . . . . . . . . . . . . . . . 4
3. Operation of List Subscriptions . . . . . . . . . . . . . . 6
3.1 Negotiation of Support for Resource Lists . . . . . . . . . 6
3.2 Event Header Parameters . . . . . . . . . . . . . . . . . . 7
3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Subscription Duration . . . . . . . . . . . . . . . . . . . 7
3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 7
3.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . . 7
3.7 Notifier Generation of NOTIFY requests . . . . . . . . . . . 8
3.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 9
3.9 Handling of Forked Requests . . . . . . . . . . . . . . . . 10
3.10 Rate of Notifications . . . . . . . . . . . . . . . . . . . 10
3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Using multipart/related to Convey Aggregate State . . . . . 12
4.1 XML Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 List Attributes . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Resource Attributes . . . . . . . . . . . . . . . . . . . . 13
4.4 Instance Attributes . . . . . . . . . . . . . . . . . . . . 14
4.5 Constructing Coherent Resource State . . . . . . . . . . . . 15
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . 30
6.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 30
6.2 Risks of Improper Aggregation . . . . . . . . . . . . . . . 30
6.3 Signing and Sealing . . . . . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32
7.1 New SIP Option Tag: eventlist . . . . . . . . . . . . . . . 32
7.2 New MIME type for Resource List Meta-Information . . . . . . 32
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 34
Normative References . . . . . . . . . . . . . . . . . . . . 35
Non-Normative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 36
Full Copyright Statement . . . . . . . . . . . . . . . . . . 38
Roach, et al. Expires August 18, 2003 [Page 2]
Internet-Draft SIP Event Lists February 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 collection of resources they are interested in.
For environments in which bandwidth is limited, such as wireless
networks, subscribing to each resource individually is problematic.
The 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 subscriptions 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.
o If a subscriber has only intermittent connectivity, and generally
polls for state rather than simply subscribing, the latency to
obtain the state of the entire resource can be large. The
messaging required for each poll can also be substantial.
To solve these problems, this specification defines an extension that
allows for requesting and conveying notifications for collections 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:) is also forseen.
The notifier for the collection 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 typically 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
contstrained to be in the domain of the resource list server.
Roach, et al. Expires August 18, 2003 [Page 3]
Internet-Draft SIP Event Lists February 2003
2. Overview of Operation
This section provides an overview of the typical mode of operation of
this extension. It is not normative.
When a user wishes to subscribe to the resource of a list of
resources, they create 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. Typically,
the user who creates the list (and subsequently subscribes to it)
will have a trust relationship with the domain that hosts the list.
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 such a subscription will typically be SIP subscription; however,
any mechanism for determining such information may be employed).
Since the RLS is acting on behalf of the user, it will need a
mechanism for authenticating the user so that appropriate policy can
be applied. In the simplest case, the user can provide credentials
to the RLS ahead of time; this requires a trust relationship between
the user and RLS. Additional approaches can be formulated using the
mechanisms defined in "Private Extensions to the Session Initiation
Protocol (SIP) for Asserted Identity within Trusted Networks" [6] and
"Enhancements for Authenticated Identity Management in the Session
Initiation Protocol (SIP)" [7].
As notifications arrive from individual resources, the RLS accepts
them, extracts the resource information, and generates a notification
to the subscriber. The RLS can, at its discretion, buffer
notifications that it receives, 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.
Roach, et al. Expires August 18, 2003 [Page 4]
Internet-Draft SIP Event Lists February 2003
The remaining sections contain the actual state information for each
resource.
Joe RLS User A User B
| | | |
|(1) SUBSCRIBE | | |
|---------------->| | |
|(2) 200 OK | | |
|<----------------| | |
|(3) NOTIFY | | |
|<----------------| | |
|(4) 200 OK | | |
|---------------->| | |
| |(5) SUBSCRIBE a | |
| |---------------->| |
| |(6) SUBSCRIBE b | |
| |---------------------------------->|
| |(7) 200 OK | |
| |<----------------| |
| |(8) 200 OK | |
| |<----------------------------------|
| |(9) NOTIFY | |
| |<----------------| |
| |(10) 200 OK | |
| |---------------->| |
|(11) NOTIFY | | |
| a's state | | |
|<----------------| | |
|(12) 200 OK | | |
|---------------->| | |
| |(13) NOTIFY | |
| |<----------------------------------|
| |(14) 200 OK | |
| |---------------------------------->|
|(15) NOTIFY | | |
| b's state | | |
|<----------------| | |
|(16) 200 OK | | |
|---------------->| | |
As an example, consider a resource list with two resources,
sip:userA@a.com and sip:userB@b.com. A typical flow for a
subscription to this resource list is shown above.
Roach, et al. Expires August 18, 2003 [Page 5]
Internet-Draft SIP Event Lists February 2003
3. Operation of List Subscriptions
A list subscription acts, in many ways, like an event template
package. In particular, any single list subscription MUST be
homogenous with respect to the underlying event package. In other
words, a single list subscription cannot contain subscriptions to
different kinds of 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 subscription to a tree of resources. The
leaf nodes of this tree are subscriptions of the event type given in
the "Event" header; 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, although the overall system is
specified in terms that imply that such subscriptions are literal SIP
subscriptions on separate servers, servers are free to implement in
any way that provides equivalent functionality as viewed from the
interface towards the subscriber. In particular, it is expected that
notifiers for list subscriptions will often have direct information
about some of the resources in the list; they will presumably not
send SUBSCRIBE requests to themselves in order to service such list
subscriptions.
3.1 Negotiation of Support for Resource Lists
This specification uses the SIP option tag mechanism for negotiating
support of the extension defined herein. Refer to RFC3261 [1] for
the normative description of processing of the "Supported" and
"Require" headers and the 421 (Extension Required) response code.
Any client that supports the event list extension will include an
option tag of "eventlist" in a "Supported" header 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 of the response to the
SUBSCRIBE, and in all NOTIFY messages within that subscription. Note
that including "eventlist" in a "Require" header in a SUBSCRIBE
request serves no purpose, and is consequently NOT RECOMMENDED.
As described in RFC3265 [2], a subscription to a particular state of
Roach, et al. Expires August 18, 2003 [Page 6]
Internet-Draft SIP Event Lists February 2003
a resource is identified by the Request-URI and the event package
used. Because it is quite reasonable for an RLS to contain a
resource that is inherantly a list (e.g.
"sip:buddylist@example.com"), it is perfectly reasonable to expect
that RLSes will return a 421 (Extension Required) response code if
the "eventlist" option tag is not indicated in a request to subscribe
to that resource. Because of the forgoing situation, this
specification relaxes the "NOT RECOMMENED" provision described in
RFC3261 [1], section 8.2.4.
3.2 Event Header Parameters
This specification does not define any parameters on the Event
header. Any parameters that are present on the Event header,
however, are applied to the underlying leaf subscriptions. If a new
subscription is generated to learn about this resource state, this
generally means that such parameters are propagated to any SUBSCRIBE
messages generated for the resources in the list.
3.3 SUBSCRIBE Bodies
The SUBSCRIBE message MAY contain a body whose purpose is to define
filters on the individual leaf subscriptions. If a new subscription
is generated to learn about this resource state, this means that such
bodies are propagated to any SUBSCRIBE messages generated for the
resources in the list.
3.4 Subscription Duration
Since the primary benefit of the resource list server is to reduce
the overall messaging volume to a handset, it is RECOMMENDED that the
subscription duration to a list be reasonably long. The default,
when no duration is specified, is two hours, which reduces the need
to refresh too frequently. Of course, the standard techniques [2]
can be used to increase or reduce this amount.
3.5 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.
3.6 Notifier Processing of SUBSCRIBE Requests
All subscriptions for resource lists SHOULD be authenticated. The
use of the SIP HTTP Digest mechanism [1] over TLS is RECOMMENDED.
Roach, et al. Expires August 18, 2003 [Page 7]
Internet-Draft SIP Event Lists February 2003
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 a notifier can use any authorization
policy it chooses.
3.7 Notifier 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.
See Section 4 for a definition of the syntax used to convey 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 of the resource.
Each instance of the resource has a state associated with it
(pending, active, or terminating), representing the state of the
subscription.
As a baseline behavior, if the RLS acts as a subscriber to determine
the state of the resources on the resource list, it MAY generate a
NOTIFY to the RLS subscriber whenever it receives a NOTIFY about a
state change in one or more resources.
If a subscription to a resource is terminated by the notifier and the
RLS is unable to re-establish the subscription by the recovery
mechanisms described in SIP Events [2], that resource is still
present in resource list NOTIFY messages as appropriate. The "state"
attribute is set to "terminated", and the "reason" attribute is
copied from the "reason" parameter from the "Subscription-State" in
the NOTIFY received from the resource.
If a SUBSCRIBE to a resource is refused with a response code that
cannot be recovered from, that resource is still present in resource
list NOTIFY messages as appropriate. The resource will be reported
with a a "state" of "terminated," and a "reason" parmeter of
"rejected".
Note that the forgoing explanation is given in term of a back-end
subscription to resources in the list. In practice, such
subscriptions may not actually exist. In these cases, the RLS sets
the "state" and "reason" attributes in such as was as would be
consistent with such back-end subscriptions.
Roach, et al. Expires August 18, 2003 [Page 8]
Internet-Draft SIP Event Lists February 2003
When the first SUBSCRIBE message for a particular subscription is
received by a resource list notifier, the notifier will often not
know state information for 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 resource list notifier 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
colocated 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 result in full meta-information about the list of
resources. The RLS will also include state information for all
resources in the list for which the RLS has state. This allows the
subscriber to refresh their state, and to recover from lost
notifications.
Note that a consequence of the way in which resource list
subscriptions work, polling of resource state will often not be
particularly useful. While such polls will retrieve the resource
list (and potentially even some of the states if a resource on the
list is colocated with the resource list server), they will often not
contain state for some or all of the resources on the list.
Because the notifications delivered by this mechanism have a tendency
to be large, implementors are directed towards "A Mechanism for
Content Indirection in Session Initiation Protocol (SIP) Messages"
[8].
3.8 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 each resource 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
Roach, et al. Expires August 18, 2003 [Page 9]
Internet-Draft SIP Event Lists February 2003
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 mesages. See section Section 4.5 for more
information.
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 collection does not change their partial
notification semantics).
3.9 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 MUST create just a single dialog as a result
of a single subscription request, using the techniques described in
RFC 3265[2].
If the resource list server generates subscriptions to packages that
allow forking, and multiple subscriptions are established as the
result of sending a single SUBSCRIBE message, the RLS maintains both
subscriptions (as described in [2]), and includes the resource state
information for all the subscriptions. This will result in having
multiple <instance> elements in the corresponding <resource> element
in the root part of the multipart/related body. See section Section
4 and its subsections for details.
3.10 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.
3.11 State Agents
Effectively, a resource list server is nothing more than a state
agent for the resource event type.
The usage of an RLS does introduce some security considerations. 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
Roach, et al. Expires August 18, 2003 [Page 10]
Internet-Draft SIP Event Lists February 2003
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 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.
The RLS would authenticate the subscriber, and then MAY use the SIP
extensions for network asserted identity (see [6] and [7]) to provide
an authenticated identity to any downstream servers. It is even
conceivable that the subscriber may provide an authenticated ID in
its original subscribe request for use by the RLS for the dual
purpose of local authentication and use in any generated SUBSCRIBE
messages.
Roach, et al. Expires August 18, 2003 [Page 11]
Internet-Draft SIP Event Lists February 2003
4. Using multipart/related to Convey Aggregate State
In order to convey the state of multiple resources, the list template
package uses the "multipart/related" mime type. The syntax for
multipart/related is defined in "The MIME Multipart/Related Content-
type" [4].
4.1 XML Syntax
The root document of the multipart/related body is always a Resource
List Meta-Information (RLMI) document. It is of type "application/
rlmi+xml". This document containes the metadata 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 xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="instance">
<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:element>
<xs:element name="resource">
<xs:complexType>
<xs:element ref="instance" minOccurs="0" maxOccurs="unbounded"/>
<xs:attribute name="uri" type="xs:string" use="required"/>
<xs:attribute name="name" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="list">
<xs:complexType>
<xs:element ref="resource" minOccurs="0" maxOccurs="unbounded"/>
<xs:attribute name="uri" type="xs:string" 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:complexType>
</xs:element>
</xs:schema>
An example of a document formatted using this schema follows.
Roach, et al. Expires August 18, 2003 [Page 12]
Internet-Draft SIP Event Lists February 2003
<list 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>
4.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 (typically in response to a
SUBSCRIBE request), and MUST increase by exactly one for each
subsequent NOTIFY sent within a subscription.
The third mandatory attribute is "fullState". The "fullState"
attribute indicates whether the NOTIFY message contains information
for every resource in the collection. If it does, the value of the
attribute is "true" (or "1"); otherwise, it is "false" (or "0").
Note that 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 can contain 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.
4.3 Resource Attributes
The resource list contains one <resource> element for each resource
Roach, et al. Expires August 18, 2003 [Page 13]
Internet-Draft SIP Event Lists February 2003
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.
4.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
subscriptions corresponding to a single resource are represented by
including multiple instance elements in the corresponding resource
element. For subscriptions in which forking does not occur, only one
instance will be present in the resource.
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. Composition of this string is
an implementation decision. One viable method for constructing the
instance id would be copying the "From:" header "tag" parameter from
the NOTIFY message received from the instance of the resource. Any
other mechanism for generating this string is equally 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 in
SIP Events [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 in SIP Events [2]. Note that the reason
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
Roach, et al. Expires August 18, 2003 [Page 14]
Internet-Draft SIP Event Lists February 2003
conveying state. This cid is Content-ID the corresponding section.
Note that the expiration durations of the underlying subscriptions
(if any) are not propagated into the aggregated state in any way.
4.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.
The processing of the resource list notification depends on whether
it contains full or partial state. If it contains full state,
indicated by the value of the <list> attribute "fullState", the
contents of the resource-list table are flushed. They are
repopulated from the document. A new row in the table is created for
each "resource" element.
First, 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.
Roach, et al. Expires August 18, 2003 [Page 15]
Internet-Draft SIP Event Lists February 2003
If the resource list document contains partial state, the
notification is used to update the table. 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 August 18, 2003 [Page 16]
Internet-Draft SIP Event Lists February 2003
5. 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 [5].
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 a list.
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.
Roach, et al. Expires August 18, 2003 [Page 17]
Internet-Draft SIP Event Lists February 2003
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 SIP Events [2], the RLS sends a NOTIFY
immediately upon accepting the subscription. In this example,
we are asserting 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
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"
Roach, et al. Expires August 18, 2003 [Page 18]
Internet-Draft SIP Event Lists February 2003
<?xml version="1.0" encoding="UTF-8"?>
<list 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"
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--
Roach, et al. Expires August 18, 2003 [Page 19]
Internet-Draft SIP Event Lists February 2003
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.com". Since the local RLS knows how to receive
notifications for list subscriptions, it includes the
"Supported: eventlist" header 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"
headers 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.
Roach, et al. Expires August 18, 2003 [Page 20]
Internet-Draft SIP Event Lists February 2003
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 and would normally take
place at this point in the callflow. Those steps are omitted
for brevity.
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>
Event: presence
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
Roach, et al. Expires August 18, 2003 [Page 21]
Internet-Draft SIP Event Lists February 2003
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.com;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.
Local RLS -> Presence Server in example.net
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.com;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>
Event: presence
Content-Length: 0
9. The Local RLS subscribes to the state of the other non-local
resource.
Roach, et al. Expires August 18, 2003 [Page 22]
Internet-Draft SIP Event Lists February 2003
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.
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>
Event: presence
Expires: 3600
Content-Length: 0
11. In this example, we are asserting 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 PGP sign [11] the body of the
NOTIFY message.
Roach, et al. Expires August 18, 2003 [Page 23]
Internet-Draft SIP Event Lists February 2003
RLS in example.org -> Local RLS
NOTIFY sip:pres.example.com SIP/2.0
Via: SIP/2.0/TCP pres.example.com;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: pending
Require: eventlist
Content-Type: multipart/signed;protocol="application/pgp-signature";
micalc="pgp-md5";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"
--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 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">
Roach, et al. Expires August 18, 2003 [Page 24]
Internet-Draft SIP Event Lists February 2003
<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/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
HOxEa44b+EI=
=ndaj
-----END PGP MESSAGE-----
--l3WMZaaL8NpQWGnQ4mlU--
12. The Local RLS completes the NOTIFY transaction.
Roach, et al. Expires August 18, 2003 [Page 25]
Internet-Draft SIP Event Lists February 2003
Local RLS -> RLS in example.org
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.com;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>
Event: presence
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".
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
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 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">
Roach, et al. Expires August 18, 2003 [Page 26]
Internet-Draft SIP Event Lists February 2003
<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/pgp-signature";
micalc="pgp-md5";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 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>
Roach, et al. Expires August 18, 2003 [Page 27]
Internet-Draft SIP Event Lists February 2003
</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/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
HOxEa44b+EI=
=ndaj
-----END PGP MESSAGE-----
--l3WMZaaL8NpQWGnQ4mlU--
--TfZxoxgAvLqgj4wRWPDL--
14. The terminal completes the NOTIFY transaction.
Roach, et al. Expires August 18, 2003 [Page 28]
Internet-Draft SIP Event Lists February 2003
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 August 18, 2003 [Page 29]
Internet-Draft SIP Event Lists February 2003
6. Security Considerations
6.1 Authentication
The usage of the RLS does introduce some security considerations.
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 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.
The RLS would authenticate the subscriber, and then MAY use the SIP
extensions for network asserted identity [6][7] to provide an
authenticated identity to the PA.
6.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 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 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 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 beleived possible,
this mode of operation is NOT RECOMMENDED.
6.3 Signing and Sealing
Implementors should keep in mind that any section of the MIME body
Roach, et al. Expires August 18, 2003 [Page 30]
Internet-Draft SIP Event Lists February 2003
may be signed and/or encrypted as necessary. Resource List Servers
should take care not to modify any MIME bodies they receive from
other notifiers, 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, if the subscriber includes them in the
initial SUBSCRIBE message. Not doing so may actually result in
resources refusling 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 August 18, 2003 [Page 31]
Internet-Draft SIP Event Lists February 2003
7. IANA Considerations
7.1 New SIP Option Tag: eventlist
Option Tag Name: eventlist
Description: Extension to allow subscriptions to collections of
resources
Published specification: RFC xxxx [[Note to RFC editor: replace xxxx
with the RFC number of this document when published]]
7.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 [10] 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 [9] and RFC 3023 [10] 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 metadata for the state of collections of resources within a
Session Initiation Protocol (SIP) subscription.
Additional information:
Roach, et al. Expires August 18, 2003 [Page 32]
Internet-Draft SIP Event Lists February 2003
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.
Roach, et al. Expires August 18, 2003 [Page 33]
Internet-Draft SIP Event Lists February 2003
8. Open Issues
o RFC 3265 allows event packages to include bodies in their
SUBSCRIBE requests to filter notifications. It would be natural
to merely copy the body from the SUBSCRIBE in a list subscription
to any SUBSCRIBE messages generated to additional entities, so
that they would take the appropriate actions. Would that be
correct behavior, or do we need to define some other way to handle
this (e.g. including the filter documents as part of the
provisioned data that is considered part of the list).
Roach, et al. Expires August 18, 2003 [Page 34]
Internet-Draft SIP Event Lists February 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.
Roach, et al. Expires August 18, 2003 [Page 35]
Internet-Draft SIP Event Lists February 2003
Non-Normative References
[5] Rosenberg, J., "Session Initiation Protocol (SIP) Extensions
for Presence", draft-ietf-simple-presence-07 (work in
progress), May 2002.
[6] Watson, M., Peterson, J. and C. Jennings, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", draft-ietf-sip-asserted-identity-02
(work in progress), August 2002.
[7] Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)", draft-
peterson-sip-identity-01 (work in progress), July 2002.
[8] Olson, S., "A Mechanism for Content Indirection in Session
Initiation Protocol (SIP) Messages", draft-ietf-sip-content-
indirect-mech-01 (work in progress), November 2002.
[9] Levinson, E., "SGML Media Types", RFC 1874, December 1995.
[10] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[11] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME
Security with OpenPGP", RFC 3156, August 2001.
[12] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, October 1995.
Authors' Addresses
Adam Roach
dynamicsoft
5100 Tennyson Pkwy
Suite 1200
Plano, TX 75024
US
EMail: adam@dynamicsoft.com
Roach, et al. Expires August 18, 2003 [Page 36]
Internet-Draft SIP Event Lists February 2003
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Ave.
First Floor
East Hanover, NJ 07936
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 August 18, 2003 [Page 37]
Internet-Draft SIP Event Lists February 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 August 18, 2003 [Page 38]
