A Session Initiation Protocol (SIP) Event
Notification Extension for Resource Lists
dynamicsoft5100 Tennyson PkwySuite 1200PlanoTX75024USadam@dynamicsoft.comdynamicsoft600 Lanidex PlazaParsippanyNJ07054-2711USjdrosen@dynamicsoft.comdynamicsoft5100 Tennyson PkwySuite 1200PlanoTX75024USbcampbell@dynamicsoft.com
Transport
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.
The SIP-specific event notification mechanism
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:
Doing so generates substantial message traffic, in the form
of the
initial SUBSCRIBE requests for each resource, and the
refreshes of each individual subscription.
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.
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
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 ;
however, the use of other schemes (such as pres: ) 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.
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
.
The following terms are used throughout the remainder of this document.
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.
A subscription to a resource list. In list subscriptions,
RLSes act a the notifier.
A resource is any logical entity that has a state or states
that can be subscribed to. Resources are identified by
URIs.
A list of zero or more resources that can have their
individual states subscribed to with a single subscription.
Resource List Meta-Information. RLMI is a document that
describes the state of the virtual subscriptions associated
with a list subscription.
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 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.
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.
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).
This specification uses the SIP option tag mechanism for negotiating
support for the extension defined herein. Refer to RFC3261
for the normative description of processing of the "Supported"
and "Require" header fields and the 421 (Extension Required)
response code.
A non-normative description of the implications
of the use of option tags follows.
Any client that supports the event list extension will
include an option tag of "eventlist" in a "Supported"
header field of every SUBSCRIBE message for a subscription
for which it is willing to process a list.
If the subscription is made to a URI that represents a list,
the RLS will include "eventlist" in a "Require" header field
of the response to the SUBSCRIBE, and in all NOTIFY
messages within that subscription.
Use of "Require: eventlist" in NOTIFY messages
is applied by the notifier to satisfy the 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
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.
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
can be
used to increase or reduce this amount.
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).
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.
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 for a detailed definition
of the
syntax used to convey the state of resource lists. For the purposes of
the following discussion, it is important to know that
the overall list contains zero or more resources,
and that the resources contains zero or more instances.
Each instance has a state associated with it (pending, active,
or terminating), representing the state of the
virtual subscription.
Notifications contain a multipart document, the first
part of which always contains meta-information about the list
(e.g. membership, state of the virtual subscription
to the resource). Remaining parts are used to convey
the actual state of the resources listed in the meta-information.
The "state" attribute of each instance of a resource
in the meta-information is set according to the
state of the virtual subscription. The meanings
of the "state" attribute are described in
RFC 3265 .
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 .
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 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.
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 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 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.
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.
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.
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"
.
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.
]]>An example of a document formatted using this schema follows.
]]>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" 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 for an example.
The resource list contains one <resource> element
for each resource being reported in the notification.
These resource elements contain attributes that identify
meta-data associated 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.
Each resource element contains zero 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.
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 .
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 .
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.
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.
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 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
corresponding 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 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.
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.
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.
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.
The list subscriber SHOULD also generate
a refresh request to trigger a full state notification.
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.
This section gives an example call flow. It is not normative.
If a conflict arises between this call flow 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
.
In this example, the RLS has information to
service some of the resources on the list, but must
consult other servers to retrieve information for others.
The implementation of the RLS in this example uses
the SIP SUBSCRIBE/NOTIFY mechanism to retrieve such
information.
| | |
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------>| | |
]]>
We initiate 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.
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:
From: ;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.example.com
CSeq: 322723822 SUBSCRIBE
Contact:
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
]]>
The Local RLS completes the SUBSCRIBE transaction.
Note that authentication and authorization would
normally take place at this point in the call flow.
Those steps are omitted for brevity.
Terminal
SIP/2.0 200 OK
Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL
To: ;tag=zpNctbZq
From: ;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.example.com
CSeq: 322723822 SUBSCRIBE
Contact:
Expires: 7200
Require: eventlist
Content-Length: 0
]]>
As is required by RFC 3265 ,
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 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.
Terminal
NOTIFY sip:terminal.example.com SIP/2.0
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMgRenTETmm
Max-Forwards: 70
From: ;tag=zpNctbZq
To: ;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.example.com
CSeq: 997935768 NOTIFY
Contact:
Event: presence
Subscription-State: active;expires=7200
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";
start="";boundary="50UBfW7LSCVLtggUPe5z"
Content-Length: 1560
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/rlmi+xml;charset="UTF-8"
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/cpim-pidf+xml;charset="UTF-8"
opensip:bob@example.com
--50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/cpim-pidf+xml;charset="UTF-8"
closed
--50UBfW7LSCVLtggUPe5z--
]]>
The terminal completes the transaction.
Local RLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMgRenTETmm
From: ;tag=zpNctbZq
To: ;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.example.com
CSeq: 997935768 NOTIFY
Contact:
Content-Length: 0
]]>
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 "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.
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:
From: ;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.example.com
CSeq: 870936068 SUBSCRIBE
Contact:
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
]]>
The Presence Server in example.net completes the SUBSCRIBE transaction.
Note that authentication would
normally take place at this point in the call flow.
Those steps are omitted for brevity.
Local RLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKMEyGjdG1LH
To: ;tag=e45TmHTh
From: ;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.example.com
CSeq: 870936068 SUBSCRIBE
Contact:
Expires: 3600
Content-Length: 0
]]>
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.
Local RLS
NOTIFY sip:pres.example.com SIP/2.0
Via: SIP/2.0/TCP pres.example.net;branch=z9hG4bKfwpklPxmrW
Max-Forwards: 70
From: ;tag=e45TmHTh
To: ;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.example.com
CSeq: 1002640632 NOTIFY
Contact:
Subscription-State: pending;expires=3600
Event: presence
Require: eventlist
Content-Length: 0
]]>
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.
Presence Server in example.net
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.net;branch=z9hG4bKfwpklPxmrW
From: ;tag=e45TmHTh
To: ;tag=aM5icQu9
Call-ID: Ugwz5ARxNw@pres.example.com
CSeq: 1002640632 NOTIFY
Contact:
Content-Length: 0
]]>
The Local RLS subscribes to the state of
the other non-local resource.
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:
From: ;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.example.com
CSeq: 980774491 SUBSCRIBE
Contact:
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
]]>
The RLS in example.org completes the SUBSCRIBE transaction.
Note that authentication and would
normally take place at this point in the call flow.
Those steps are omitted for brevity.
Local RLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bKFSrAF8CZFL
To: ;tag=JenZ40P3
From: ;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.example.com
CSeq: 980774491 SUBSCRIBE
Contact:
Expires: 3600
Content-Length: 0
]]>
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
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.
Local RLS
NOTIFY sip:pres.example.com SIP/2.0
Via: SIP/2.0/TCP pres.example.org;branch=z9hG4bKmGL1nyZfQI
Max-Forwards: 70
From: ;tag=JenZ40P3
To: ;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.example.com
CSeq: 294444656 NOTIFY
Contact:
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: binary
Content-ID:
Content-Type: multipart/related;type="application/rlmi+xml";
start="";boundary="tuLLl3lDyPZX0GMr2YOo"
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/rlmi+xml;charset="UTF-8"
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/cpim-pidf+xml;charset="UTF-8"
opensip:joe@example.org
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/cpim-pidf+xml;charset="UTF-8"
closed
--tuLLl3lDyPZX0GMr2YOo--
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/pkcs7-signature
[PKCS #7 signature here]
--l3WMZaaL8NpQWGnQ4mlU--
]]>
The Local RLS completes the NOTIFY transaction.
RLS in example.org
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.org;branch=z9hG4bKmGL1nyZfQI
From: ;tag=JenZ40P3
To: ;tag=a12eztNf
Call-ID: kBq5XhtZLN@pres.example.com
CSeq: 294444656 NOTIFY
Contact:
Content-Length: 0
]]>
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.
Terminal
NOTIFY sip:terminal.example.com SIP/2.0
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1
Max-Forwards: 70
From: ;tag=zpNctbZq
To: ;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.example.com
CSeq: 997935769 NOTIFY
Contact:
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: binary
Content-ID: <2BEI83@pres.example.com>
Content-Type: application/rlmi+xml;charset="UTF-8"
--TfZxoxgAvLqgj4wRWPDL
Content-Transfer-Encoding: binary
Content-ID: <1KQhyE@pres.example.com>
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1;boundary="l3WMZaaL8NpQWGnQ4mlU"
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: multipart/related;type="application/rlmi+xml";
start="";boundary="tuLLl3lDyPZX0GMr2YOo"
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/rlmi+xml;charset="UTF-8"
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/cpim-pidf+xml;charset="UTF-8"
opensip:joe@example.org
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/cpim-pidf+xml;charset="UTF-8"
closed
--tuLLl3lDyPZX0GMr2YOo--
--l3WMZaaL8NpQWGnQ4mlU
Content-Transfer-Encoding: binary
Content-ID:
Content-Type: application/pkcs7-signature
[PKCS #7 signature here]
--l3WMZaaL8NpQWGnQ4mlU--
--TfZxoxgAvLqgj4wRWPDL--
]]>
The terminal completes the NOTIFY transaction.
Local RLS
SIP/2.0 200 OK
Via: SIP/2.0/TCP pres.example.com;branch=z9hG4bK4EPlfSFQK1
From: ;tag=zpNctbZq
To: ;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.example.com
CSeq: 997935769 NOTIFY
Contact:
Content-Length: 0
]]>
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.
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
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
to provide an
authenticated identity to the notifiers for the resource.
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 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
authorization 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.
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 implementation of encryption and signing
by the RLS is not necessary to be able to pass through
signed and/or encrypted bodies.
One risk introduced by the ability to nest
resource lists is the possibility of creating
lists which ultimately contain themselves
as a sub-list. Detection and handling of
such a case is trivial when the RLS services
all of the virtual subscriptions internally.
When back-end subscriptions are created to
service virtual subscriptions, however,
detection of such situations becomes a more
difficult problem.
Implementors of RLSes that create back-end
subscriptions MUST implement safeguards
to prevent such nestings
from creating an infinite loop of subscriptions.
Typically, such mechanisms will require support
in the back-end subscription protocol. In particular,
applying filters to the back-end subscriptions
can be an effective way to preclude such problems.
This section defines a new option tag for
the registry established by section 27.1 of
RFC 3261. eventlistExtension to allow subscriptions to
lists of resourcesRFC xxxx [[Note to RFC editor:
replace xxxx with the RFC number of this document when published]]applicationrlmi+xmlNonecharsetSee
RFC 3023
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.8-bit textSecurity 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
and
RFC 3023
discuss security issues common to all uses of XML.The use of
this MIME body is intended to be generally interoperable. No
unique considerations have been identified.RFC xxxx [[Note to RFC editor:
replace xxxx with the RFC number of this document when published]]This
media type is used to convey meta-information for the state of
lists of resources within a Session Initiation
Protocol (SIP) subscription.None.None.None.None.Limited UseNone.Adam Roachadam@dynamicsoft.com
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.
urn:ietf:params:xml:ns:rlmi
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.
Adam Roachadam@dynamicsoft.com
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.
Namespace for SIP Event Resource List
Meta-Information
Namespace for SIP Event Resource List
Meta-Information
END
]]>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, Keith Drage
and Robert Sparks for their careful reviews of and comments
on this document.
SIP: Session Initiation ProtocolSession Initiation Protocol (SIP)-Specific Event NotificationMIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message BodiesBellcore445 South St.MRE 2D-296MorristownNJ07962-1910US+1 201 829 4270+1 201 829 7019nsb@bellcore.comInnosoft International, Inc.250 West First StreetSuite 240ClaremontCA91711US+1 909 624 7907+1 909 621 5319The MIME Multipart/Related Content-type47 Clive StreetMetuchenNJ 08840-1060USA+1 908 494 1606XIson@cnj.digex.com
Applications
content-typemultipurpose internet mail extensions
The Multipart/Related content-type provides a common mechanism for
representing objects that are aggregates of related MIME body parts.
This document defines the Multipart/Related content-type and provides
examples of its use.
Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864-
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
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.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
A Presence Event Package for the Session Initiation Protocol (SIP)
Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted NetworksEnhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)A Mechanism for Content Indirection in Session Initiation Protocol (SIP) MessagesCommon Profile for Presence (CPP)SGML Media TypesAccurate Information Systems, Inc.2 Industrial WayEatontownNJ07724USELevinson@Accurate.comThis document proposes new media sub-types of Text/SGML and Application/SGML. These media types can be used in the exchange of SGML documents and their entities. Specific details for the exchange or encapsulation of groups of related SGML entities using MIME are currently being considered by the mimesgml Working Group sgml-internet@ebt.com.XML Media TypesS/MIME Version 3 Message SpecificationWorldtalk17720 NE 65th StreetSuite 201RedmondWA98052US+1 425 376 0225blaker@deming.comSecurity Multiparts for MIME: Multipart/Signed and Multipart/EncryptedTrusted Information Systems3060 Washington RoadGlenwoodMD21738US+1 301 854 6889+1 301 854 5363galvin@tis.comTrusted Information Systems3060 Washington RoadGlenwoodMD21738US+1 301 854 6889+1 301 854 5363sandy@tis.comCyberCash, Inc.2086 Hunters Crest WayViennaVA22181US+1 703 620 1222+1 703 391 2651crocker@cybercash.comInnosoft International, Inc.1050 East Garvey Avenue SouthWest CovinaCA91790US+1 818 919 3600+1 818 919 3614ned@innosoft.comThis document defines a framework within which security services may be applied to MIME body parts. MIME, an acronym for "Multipurpose Internet Mail Extensions", defines the format of the contents of Internet mail messages and provides for multi-part textual and non-textual message bodies. The new content types are subtypes of multipart: signed and encrypted. Each will contain two body parts: one for the protected data and one for the control information necessary to remove the protection. The type and contents of the control information body parts are determined by the value of the protocol parameter of the enclosing multipart/signed or multipart/encrypted content type, which is required to be present.HTTP Over TLSNote that this section will be removed before publication as
an RFC.Removed some leftover cruft from the section on constructing
coherent resource state
Changed Content-Encoding in examples from 8bit to binary.
Adjusted formatting to comply with RFC 2223.
Added discussion in security section about infinite
loops.
Fixed several places where the document said "one or more"
instead of "zero or more", when referring
to the number of resources that can appear in a list and
the number of instances that can appear in a resource.
Tiny editorial cleanup (mostly spelling gaffes).
Several editorial updates. Change "collection" to "list"
everywhere.
Added terminology section.
Added restriction that cid attributes can only point to
documents at the same level as the RLMI document in
which they appear.
Clarified description of how to construct resource
state by splitting discussion of full state
notifications apart from discussion of partial-state
notifications.
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.
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.
Added "cid" attribute to <list> elements.
Reworked XML schema definition for meta-information.
Added IANA registration for XML namespace.
Minor editorial fixes
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.