Request for Comments: 3856 dynamicsoft
Category: Standards Track August 2004
A Presence Event Package for the Session Initiation Protocol (SIP)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes the usage of the Session Initiation Protocol
(SIP) for subscriptions and notifications of presence. Presence is
defined as the willingness and ability of a user to communicate with
other users on the network. Historically, presence has been limited
to "on-line" and "off-line" indicators; the notion of presence here
is broader. Subscriptions and notifications of presence are
supported by defining an event package within the general SIP event
notification framework. This protocol is also compliant with the
Common Presence Profile (CPP) framework.
Table of Contents
1. Introduction ................................................ 2
2. Terminology ................................................. 3
3. Definitions ................................................. 3
4. Overview of Operation ....................................... 4
5. Usage of Presence URIs ...................................... 6
6. Presence Event Package ...................................... 7
6.1. Package Name .......................................... 8
6.2. Event Package Parameters .............................. 8
6.3. SUBSCRIBE Bodies ...................................... 8
6.4. Subscription Duration ................................. 9
6.5. NOTIFY Bodies ......................................... 9
6.6. Notifier Processing of SUBSCRIBE Requests ............. 9
6.6.1. Authentication ................................. 10
6.6.2. Authorization .................................. 10
6.7. Notifier Generation of NOTIFY Requests ................ 11
6.8. Subscriber Processing of NOTIFY Requests .............. 13
6.9. Handling of Forked Requests ........................... 13
6.10. Rate of Notifications ................................. 14
6.11. State Agents .......................................... 14
6.11.1. Aggregation, Authentication, and Authorization. 14
6.11.2. Migration ..................................... 15
7. Learning Presence State ..................................... 16
7.1. Co-location ........................................... 16
7.2. REGISTER .............................................. 16
7.3. Uploading Presence Documents .......................... 17
8. Example Message Flow ........................................ 17
9. Security Considerations ..................................... 20
9.1. Confidentiality ....................................... 20
9.2. Message Integrity and Authenticity .................... 21
9.3. Outbound Authentication ............................... 22
9.4. Replay Prevention ..................................... 22
9.5. Denial of Service Attacks Against Third Parties ....... 22
9.6. Denial Of Service Attacks Against Servers ............. 23
10. IANA Considerations ......................................... 23
11. Contributors ................................................ 24
12. Acknowledgements ............................................ 25
13. Normative References ........................................ 25
14. Informative References ...................................... 26
15. Author’s Address ............................................ 26
16. Full Copyright Statement .................................... 27
1. Introduction
Presence, also known as presence information, conveys the ability and
willingness of a user to communicate across a set of devices. RFC
2778 [10] defines a model and terminology for describing systems that
provide presence information. In that model, a presence service is a
system that accepts, stores, and distributes presence information to
interested parties, called watchers. A presence protocol is a
protocol for providing a presence service over the Internet or any IP
network.
This document proposes the usage of the Session Initiation Protocol
(SIP) [1] as a presence protocol. This is accomplished through a
concrete instantiation of the general event notification framework
defined for SIP [2], and as such, makes use of the SUBSCRIBE and
NOTIFY methods defined there. Specifically, this document defines an
event package, as described in RFC 3265 [2]. SIP is particularly
well suited as a presence protocol. SIP location services already
contain presence information, in the form of registrations.
Furthermore, SIP networks are capable of routing requests from any
user on the network to the server that holds the registration state
for a user. As this state is a key component of user presence, those
SIP networks can allow SUBSCRIBE requests to be routed to the same
server. This means that SIP networks can be reused to establish
global connectivity for presence subscriptions and notifications.
This event package is based on the concept of a presence agent, which
is a new logical entity that is capable of accepting subscriptions,
storing subscription state, and generating notifications when there
are changes in presence. The entity is defined as a logical one,
since it is generally co-resident with another entity.
This event package is also compliant with the Common Presence Profile
(CPP) framework that has been defined in [3]. This allows SIP for
presence to easily interwork with other presence systems compliant to
CPP.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and
indicate requirement levels for compliant implementations.
3. Definitions
This document uses the terms as defined in RFC 2778 [10].
Additionally, the following terms are defined and/or additionally
clarified:
Presence User Agent (PUA): A Presence User Agent manipulates
presence information for a presentity. This manipulation can
be the side effect of some other action (such as sending a SIP
REGISTER request to add a new Contact) or can be done
explicitly through the publication of presence documents. We
explicitly allow multiple PUAs per presentity. This means that
a user can have many devices (such as a cell phone and Personal
Digital Assistant (PDA)), each of which is independently
generating a component of the overall presence information for
a presentity. PUAs push data into the presence system, but are
outside of it, in that they do not receive SUBSCRIBE messages
or send NOTIFY messages.
Presence Agent (PA): A presence agent is a SIP user agent which is
capable of receiving SUBSCRIBE requests, responding to them,
and generating notifications of changes in presence state. A
presence agent must have knowledge of the presence state of a
presentity. This means that it must have access to presence
data manipulated by PUAs for the presentity. One way to do
this is by co-locating the PA with the proxy/registrar.
Another way is to co-locate it with the presence user agent of
the presentity. However, these are not the only ways, and this
specification makes no recommendations about where the PA
function should be located. A PA is always addressable with a
SIP URI that uniquely identifies the presentity (i.e.,
sip:joe@example.com). There can be multiple PAs for a
particular presentity, each of which handles some subset of the
total subscriptions currently active for the presentity. A PA
is also a notifier (defined in RFC 3265 [2]) that supports the
presence event package.
Presence Server: A presence server is a physical entity that can
act as either a presence agent or as a proxy server for
SUBSCRIBE requests. When acting as a PA, it is aware of the
presence information of the presentity through some protocol
means. When acting as a proxy, the SUBSCRIBE requests are
proxied to another entity that may act as a PA.
Edge Presence Server: An edge presence server is a presence agent
that is co-located with a PUA. It is aware of the presence
information of the presentity because it is co-located with the
entity that manipulates this presence information.
4. Overview of Operation
In this section, we present an overview of the operation of this
event package. The overview describes behavior that is documented in
part here, in part within the SIP event framework [2], and in part in
the SIP specification [1], in order to provide clarity on this
package for readers only casually familiar with those specifications.
However, the detailed semantics of this package require the reader to
be familiar with SIP events and the SIP specification itself.
When an entity, the subscriber, wishes to learn about presence
information from some user, it creates a SUBSCRIBE request. This
request identifies the desired presentity in the Request-URI, using a
SIP URI, SIPS URI [1] or a presence (pres) URI [3]. The SUBSCRIBE
request is carried along SIP proxies as any other SIP request would
be. In most cases, it eventually arrives at a presence server, which
can either generate a response to the request (in which case it acts
as the presence agent for the presentity), or proxy it on to an edge
presence server. If the edge presence server handles the
subscription, it is acting as the presence agent for the presentity.
The decision at a presence server about whether to proxy or terminate
the SUBSCRIBE is a local matter; however, we describe one way to
effect such a configuration, using REGISTER.
The presence agent (whether in the presence server or edge presence
server) first authenticates the subscription, then authorizes it.
The means for authorization are outside the scope of this protocol,
and we expect that many mechanisms will be used. If authorized, a
200 OK response is returned. If authorization could not be obtained
at this time, the subscription is considered "pending", and a 202
response is returned. In both cases, the PA sends an immediate
NOTIFY message containing the state of the presentity and of the
subscription. The presentity state may be bogus in the case of a
pending subscription, indicating offline no matter what the actual
state of the presentity, for example. This is to protect the privacy
of the presentity, who may not want to reveal that they have not
provided authorization for the subscriber. As the state of the
presentity changes, the PA generates NOTIFYs containing those state
changes to all subscribers with authorized subscriptions. Changes in
the state of the subscription itself can also trigger NOTIFY
requests; that state is carried in the Subscription-State header
field of the NOTIFY, and would typically indicate whether the
subscription is active or pending.
The SUBSCRIBE message establishes a "dialog" with the presence agent.
A dialog is defined in RFC 3261 [1], and it represents the SIP state
between a pair of entities to facilitate peer-to-peer message
exchanges. This state includes the sequence numbers for messages in
both directions (SUBSCRIBE from the subscriber, NOTIFY from the
presence agent), in addition to a route set and remote target URI.
The route set is a list of SIP (or SIPS) URIs which identify SIP
proxy servers that are to be visited along the path of SUBSCRIBE
refreshes or NOTIFY requests. The remote target URI is the SIP or
SIPS URI that identifies the target of the message - the subscriber,
in the case of NOTIFY, or the presence agent, in the case of a
SUBSCRIBE refresh.
SIP provides a procedure called record-routing that allows for proxy
servers to request to be on the path of NOTIFY messages and SUBSCRIBE
refreshes. This is accomplished by inserting a URI into the
Record-Route header field in the initial SUBSCRIBE request.
The subscription persists for a duration that is negotiated as part
of the initial SUBSCRIBE. The subscriber will need to refresh the
subscription before its expiration, if they wish to retain the
subscription. This is accomplished by sending a SUBSCRIBE refresh
within the same dialog established by the initial SUBSCRIBE. This
SUBSCRIBE is nearly identical to the initial one, but contains a tag
in the To header field, a higher CSeq header field value, and
possibly a set of Route header field values that identify the path of
proxies the request is to take.
The subscriber can terminate the subscription by sending a SUBSCRIBE,
within the dialog, with an Expires header field (which indicates
duration of the subscription) value of zero. This causes an
immediate termination of the subscription. A NOTIFY request is then
generated by the presence agent with the most recent state. In fact,
behavior of the presence agent for handling a SUBSCRIBE request with
Expires of zero is no different than for any other expiration value;
pending or authorized SUBSCRIBE requests result in a triggered NOTIFY
with the current presentity and subscription state.
The presence agent can terminate the subscription at any time. To do
so, it sends a NOTIFY request with a Subscription-State header field
indicating that the subscription has been terminated. A reason
parameter can be supplied which provides the reason.
It is also possible to fetch the current presence state, resulting in
a one-time notification containing the current state. This is
accomplished by sending a SUBSCRIBE request with an immediate
expiration.
5. Usage of Presence URIs
A presentity is identified in the most general way through a presence
URI [3], which is of the form pres:user@domain. These URIs are
resolved to protocol specific URIs, such as the SIP or SIPS URI,
through domain-specific mapping policies maintained on a server.
It is very possible that a user will have both a SIP (and/or SIPS)
URI and a pres URI to identify both themself and other users. This
leads to questions about how these URI relate and which are to be
used.
In some instances, a user starts with one URI format, such as the
pres URI, and learns a URI in a different format through some
protocol means. As an example, a SUBSCRIBE request sent to a pres
URI will result in learning a SIP or SIPS URI for the presentity from
the Contact header field of the 200 OK to the SUBSCRIBE request. As
another example, a DNS mechanism might be defined that would allow
lookup of a pres URI to obtain a SIP or SIPS URI. In cases where one
URI is learned from another through protocol means, those means will
often provide some kind of scoping that limit the lifetime of the
learned URI. DNS, for example, provides a TTL which would limit the
scope of the URI. These scopes are very useful to avoid stale or
conflicting URIs for identifying the same resource. To ensure that a
user can always determine whether a learned URI is still valid, it is
RECOMMENDED that systems which provide lookup services for presence
URIs have some kind of scoping mechanism.
If a subscriber is only aware of the protocol-independent pres URI
for a presentity, it follows the procedures defined in [5]. These
procedures will result in the placement of the pres URI in the
Request-URI of the SIP request, followed by the usage of the DNS
procedures defined in [5] to determine the host to send the SIP
request to. Of course, a local outbound proxy may alternatively be
used, as specified in RFC 3261 [1]. If the subscriber is aware of
both the protocol-independent pres URI and the SIP or SIPS URI for
the same presentity, and both are valid (as discussed above) it
SHOULD use the pres URI format. Of course, if the subscriber only
knows the SIP URI for the presentity, that URI is used, and standard
RFC 3261 processing will occur. When the pres URI is used, any
proxies along the path of the SUBSCRIBE request which do not
understand the URI scheme will reject the request. As such, it is
expected that many systems will be initially deployed that only
provide users with a SIP URI.
SUBSCRIBE messages also contain logical identifiers that define the
originator and recipient of the subscription (the To and From header
fields). These headers can take either a pres or SIP URI. When the
subscriber is aware of both a pres and SIP URI for its own identity,
it SHOULD use the pres URI in the From header field. Similarly, when
the subscriber is aware of both a pres and a SIP URI for the desired
presentity, it SHOULD use the pres URI in the To header field.
The usage of the pres URI instead of the SIP URI within the SIP
message supports interoperability through gateways to other
CPP-compliant systems. It provides a protocol-independent form of
identification which can be passed between systems. Without such an
identity, gateways would be forced to map SIP URIs into the
addressing format of other protocols. Generally, this is done by
converting the SIP URI to the form <foreign-protocol-scheme>:<encoded
SIP URI>@<gateway>. This is commonly done in email systems, and has
many known problems. The usage of the pres URI is a SHOULD, and not
a MUST, to allow for cases where it is known that there are no
gateways present, or where the usage of the pres URI will cause
interoperability problems with SIP components that do not support the
pres URI.
The Contact, Record-Route and Route fields do not identify logical
entities, but rather concrete ones used for SIP messaging. SIP [1]
specifies rules for their construction.
6. Presence Event Package
The SIP event framework [2] defines a SIP extension for subscribing
to, and receiving notifications of, events. It leaves the definition
of many aspects of these events to concrete extensions, known as
event packages. This document qualifies as an event package. This
section fills in the information required for all event packages by
RFC 3265 [2].
6.1. Package Name
The name of this package is "presence". As specified in RFC 3265
[2], this value appears in the Event header field present in
SUBSCRIBE and NOTIFY requests.
Example:
Event: presence
6.2. Event Package Parameters
The SIP event framework allows event packages to define additional
parameters carried in the Event header field. This package,
presence, does not define any additional parameters.
6.3. SUBSCRIBE Bodies
A SUBSCRIBE request MAY contain a body. The purpose of the body
depends on its type. Subscriptions will normally not contain bodies.
The Request-URI, which identifies the presentity, combined with the
event package name, is sufficient for presence.
One type of body that can be included in a SUBSCRIBE request is a
filter document. These filters request that only certain presence
events generate notifications, or would ask for a restriction on the
set of data returned in NOTIFY requests. For example, a presence
filter might specify that the notifications should only be generated
when the status of the user’s instant inbox [10] changes. It might
also say that the content of these notifications should only contain
the status of the instant inbox. Filter documents are not specified
in this document, and at the time of writing, are expected to be the
subject of future standardization activity.
Honoring of these filters is at the policy discretion of the PA.
If the SUBSCRIBE request does not contain a filter, this tells the PA
that no filter is to be applied. The PA SHOULD send NOTIFY requests
at the discretion of its own policy.
6.4. Subscription Duration
User presence changes as a result of many events. Some examples are:
o Turning on and off of a cell phone
o Modifying the registration from a softphone
o Changing the status on an instant messaging tool
These events are usually triggered by human intervention, and occur
with a frequency on the order of seconds to hours. As such,
subscriptions should have an expiration in the middle of this range,
which is roughly one hour. Therefore, the default expiration time
for subscriptions within this package is 3600 seconds. As per RFC
3265 [2], the subscriber MAY specify an alternate expiration in the
Expires header field.
6.5. NOTIFY Bodies
As described in RFC 3265 [2], the NOTIFY message will contain bodies
that describe the state of the subscribed resource. This body is in
a format listed in the Accept header field of the SUBSCRIBE, or a
package-specific default if the Accept header field was omitted from
the SUBSCRIBE.
In this event package, the body of the notification contains a
presence document. This document describes the presence of the
presentity that was subscribed to. All subscribers and notifiers
MUST support the "application/pidf+xml" presence data format
described in [6]. The subscribe request MAY contain an Accept header
field. If no such header field is present, it has a default value of
"application/pidf+xml". If the header field is present, it MUST
include "application/pidf+xml", and MAY include any other types
capable of representing user presence.
6.6. Notifier Processing of SUBSCRIBE Requests
Based on the proxy routing procedures defined in the SIP
specification, the SUBSCRIBE request will arrive at a presence agent
(PA). This subsection defines package-specific processing at the PA
of a SUBSCRIBE request. General processing rules for requests are
covered in Section 8.2 of RFC 3261 [1], in addition to general
SUBSCRIBE processing in RFC 3265 [2].
User presence is highly sensitive information. Because the
implications of divulging presence information can be severe, strong
requirements are imposed on the PA regarding subscription processing,
especially related to authentication and authorization.
6.6.1. Authentication
A presence agent MUST authenticate all subscription requests. This
authentication can be done using any of the mechanisms defined in RFC
3261 [1]. Note that digest is mandatory to implement, as specified
in RFC 3261.
In single-domain systems, where the subscribers all have shared
secrets with the PA, the combination of digest authentication over
Transport Layer Security (TLS) [7] provides a secure and workable
solution for authentication. This use case is described in Section
26.3.2.1 of RFC 3261 [1].
In inter-domain scenarios, establishing an authenticated identity of
the subscriber is harder. It is anticipated that authentication will
often be established through transitive trust. SIP mechanisms for
network asserted identity can be applied to establish the identity of
the subscriber [11].
A presentity MAY choose to represent itself with a SIPS URI. By
"represent itself", it means that the user represented by the
presentity hands out, on business cards, web pages, and so on, a SIPS
URI for their presentity. The semantics associated with this URI, as
described in RFC 3261 [1], require TLS usage on each hop between the
subscriber and the server in the domain of the URI. This provides
additional assurances (but no absolute guarantees) that identity has
been verified at each hop.