Internet Engineering Task Force SIMPLE WG
Internet Draft Rosenberg et al.
draft-ietf-simple-presence-04.txt Various Places
November 21, 2001
Expires: May 2002
SIP Extensions for Presence
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
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This document describes the usage of SIP for subscriptions and
notifications of user presence. User 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 user presence are supported by
defining an event package within the general SIP event notification
framework. This protocol is also compliant with the Common Presence
and Instant Messaging (CPIM) framework.
1 Introduction
Presence is (indirectly) defined in RFC2778 [1] as subscription to
and notification of changes in the communications state of a user.
Rosenberg et al. [Page 1]
Internet Draft presence November 21, 2001
This communications state consists of the set of communications
means, communications address, and status of that user. A presence
protocol is a protocol for providing such a service over the Internet
or any IP network.
This document proposes the usage of the Session Initiation Protocol
(SIP) [2] for presence. This is accomplished through a concrete
instantiation of the general event notification framework defined for
SIP [3], and as such, makes use of the SUBSCRIBE and NOTIFY methods
defined there. Specifically, this document defines an event package,
as described in [3]. User presence is particularly well suited for
SIP. SIP registrars and location services already hold user presence
information; it is uploaded to these devices through REGISTER
messages, and used to route calls to those users. Furthermore, SIP
networks already route INVITE messages from any user on the network
to the proxy that holds the registration state for a user. As this
state is user presence, those SIP networks can also allow SUBSCRIBE
requests to be routed to the same proxy. 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 user presence. The entity is defined as a logical one,
since it is generally co-resident with another entity, and can even
move around during the lifetime of a subscription.
This event package is also compliant with the Common Presence and
Instant Messaging (CPIM) framework that has been defined in [4]. This
allows SIP for presence to easily interwork with other presence
systems compliant to CPIM.
2 Definitions
This document uses the terms as defined in [1]. 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 PDA), each of which is
independently generating a component of the overall
presence information for a presentity. PUAs push data into
Rosenberg et al. [Page 2]
Internet Draft presence November 21, 2001
the presence system, but are outside of it, in that they do
not receive SUBSCRIBE messages, or send NOTIFY.
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, or the presence user agent of the
presentity. However, this is not the only way, and this
specification makes no recommendations about where the PA
function should be located. A PA is always addressable with
a SIP URL 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 [3] that
supports the presence events 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. This protocol means can be SIP REGISTER
requests, but other mechanisms are allowed. When acting as
a proxy, the SUBSCRIBE requests are proxied to another
entity that may act as a PA.
Presence Client: A presence client is a presence agent that is
colocated 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.
3 Overview of Operation
In this section, we present an overview of the operation of this
event package.
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 URL or a presence URL [4]. The subscription is carried along SIP
proxies as any other request would be. It eventually arrives at a
presence server, which can either terminate the subscription (in
which case it acts as the presence agent for the presentity), or
proxy it on to a presence client. If the presence client handles the
Rosenberg et al. [Page 3]
Internet Draft presence November 21, 2001
subscription, it is effectively acting as the presence agent for the
presentity. The decision 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 presence
client) 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 (this state may be bogus in
the case of a pending subscription). As the state of the presentity
changes, the PA generates NOTIFYs for all subscribers with authorized
subscriptions.
The SUBSCRIBE message effectively establishes a "dialog" with the
presence agent, which persists for some amount of time, and may
involve subsequent messaging (like a refresh or notification). As a
result, the SUBSCRIBE can be record-routed, and rules for tag
handling and Contact processing mirror those for INVITE. Similarly,
the NOTIFY message is handled in much the same way a re-INVITE within
a call leg is handled.
4 Usage of Presence URLs
A presentity is identified in the most general way through a presence
URL [4], which is of the form pres:user@domain. These URLs are
protocol independent. They are resolved to protocol specific URLs,
such as a SIP URL, through DNS procedures defined in [4].
When subscribing to a presentity, the subscription can be addressed
using the protocol independent form or the sip URL form. In the SIP
context, "addressed" refers to the request URI. It is RECOMMENDED
that if the entity sending a SUBSCRIBE is capable of resolving the
protocol independent form to the SIP form, this resolution is done
before sending the request. However, if the entity is incapable of
doing this translation, the protocol independent form is used in the
request URI. Performing the translation as early as possible means
that these requests can be routed by SIP proxies that are not aware
of the presence namespace.
SUBSCRIBE messages also contain logical identifiers that define the
originator and recipient of the subscription (the To and From header
fields). These SHOULD contain SIP URLs whenever possible, but MAY
contain a pres URL if a SIP URL is not known or available.
Rosenberg et al. [Page 4]
Internet Draft presence November 21, 2001
The Contact, Record-Route and Route fields do not identify logical
entities, but rather concrete ones used for SIP messaging. As such,
they MUST use the SIP URL forms in both SUBSCRIBE and NOTIFY.
5 Presence Event Package
The SIP event framework [3] defines an abstract SIP extension for
subscribing to, and receiving notifications of, events. It leaves the
definition of many additional aspects of these events to concrete
extensions, also known as event packages. This document qualifies as
an event package. This section fills in the information required by
[5].
5.1 Package Name
The name of this package is "presence". This name MUST appear within
the Event header in SUBSCRIBE request and NOTIFY request.
Example:
Event: presence
5.2 Event Package Parameters
The SIP Event Framework allows event packages to define additional
parameters carried in the Event header for the specific package. This
package, presence, does not define any additional parameters.
5.3 SUBSCRIBE bodies
The body of 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 user presence.
We anticipate that document formats could be defined to act as
filters for subscriptions. These filters would request that only
certain user presence events that would generate notifies, or 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 users instant message
inbox changes. It might also say that the content of these
notifications should only contain the IM related information.
Rosenberg et al. [Page 5]
Internet Draft presence November 21, 2001
Honoring of these filters is at the policy discretion of the PA.
When no body is present, this specifies to the presence agent that no
filter is being requested. All presence changes SHOULD be conveyed in
NOTIFY requests.
5.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 [3], the
subscriber MAY include an alternate expiration time.
5.5 NOTIFY Bodies
The body of the notification contains a presence document. This
document describes the user presence of the presentity that was
subscribed to. All subscribers MUST support the presence data format
described in [6], and MUST list its MIME type, "application/cpim-
pidf+xml" in an Accept header present in the SUBSCRIBE request.
Other presence data formats might be defined in the future. In that
case, the subscriptions MAY indicate support for other presence
formats. However, they MUST always support and list
"application/cpim-pidf+xml" as an allowed format.
Of course, the notifications generated by the presence agent MUST be
in one of the formats specified in the Accept header in the SUBSCRIBE
request.
5.6 Subscriber Generation of SUBSCRIBE Requests
If a user wishes to subscribe to a user's presence, they formulate a
SIP SUBSCRIBE request. The Request-URI SHOULD contain the SIP URL of
the presentity whose presence is desired, but MAY contain a presence
URL if no SIP URL is known. The To field SHOULD contain the same
value as the Request-URI. The From field MUST be present, and SHOULD
contain a logical identifier for the subscriber (i.e.,
Rosenberg et al. [Page 6]
Internet Draft presence November 21, 2001
sip:joe@yahoo.com as opposed to sip:joe@1.2.3.4). The request MUST
contain a Contact header, Via header, Call-ID header and CSeq header
as defined by SIP [2]. Other header usage is described in [2].
This request is then sent. This MAY be done using the DNS procedures
defined in [2] if the Request-URI contains a SIP URL, else the
request MAY be sent to a configured local outbound proxy. If the
client placed a presence URL in the Request-URI because it was unable
to translate it, it MUST forward the request to a configured local
outbound proxy.
The SUBSCRIBE request is a non-INVITE transaction and follows the
transaction rules defined in [2] as specified for BYE.
A 2xx response to the SUBSCRIBE indicates that the subscription
request has been accepted. A 202 in particular indicates that the
subscription is pending (see below for the definition); however, the
processing rules at the subscriber are independent of the particular
2xx code.
As discussed in [3], any accepted subscription needs to be refreshed
as it is soft-state. When refreshing the subscription, the tag in the
To field SHOULD equal the value of the tag in the To field in the 2xx
response to SUBSCRIBE. Furthermore, the refresh SHOULD follow the
rules in RFC 2543 [2] for request routing (using the Route, Record-
Route, and Contact headers) as if a refresh were a re-INVITE within a
call-leg. This results in efficient usage of proxy resources, ideally
delivering refreshes directly to the PA that sent the 2xx.
5.7 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 processing at the PA of a SUBSCRIBE
request.
If a PA gets a SUBSCRIBE request, and the Request-URI identifies a
user the PA is responsible for, but the To header does not, this
means that the SUBSCRIBE was forwarded for some reason. Whether the
PA is willing to accept subscriptions originally targeted to the user
in the To field is a matter of local policy. If a PA decides not to,
it SHOULD generate a 403 response.
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.
Rosenberg et al. [Page 7]
Internet Draft presence November 21, 2001
A presence agent MUST authenticate all subscription requests. This
authentication can be done using any of the mechanisms defined for
SIP, except that the SIP basic authentication mechanism MUST NOT be
used. It is anticipated that authentication will often be established
through transitive trust. Specifically, when user A generates a
SUBSCRIBE for B@bar.com, his domain (say, foo.com) will use SIP proxy
authentication mechanisms to identify him. The SUBSCRIBE is forwarded
to the target domain over a secure connection, such as TLS. The
nature of the trust relationship between bar.com and foo.com is that
bar.com trusts that foo.com has authenticated all subscribes it
receives over that secure connection. As such, the bar.com server
need only verify that the SUBSCRIBE came over the secure connection.
The SIP extension for caller identity and privacy [7] can be used to
allow one domain to provide the authenticated identity to another,
even while maintaining privacy. These mechanisms apply equally well
to SUBSCRIBE requests for presence.
It is RECOMMENDED that any subscriptions that are not authenticated
do not cause state to be established in the PA. This can be
accomplished by generating a 401 in response to the SUBSCRIBE, and
then discarding all state for that transaction. Retransmissions of
the SUBSCRIBE generate the same response, guaranteeing reliability
even over UDP.
Furthermore, a PA MUST NOT accept a subscription unless authorization
has been provided by the presentity. The means by which authorization
are provided are outside the scope of this document. Authorization
may have been provided ahead of time through access lists, perhaps
specified in a web page. Authorization may have been provided by
means of uploading of some kind of standardized access control list
document. Back end authorization servers, such as a DIAMETER [8],
RADIUS [9], or COPS [10], can also be used. It is also useful to be
able to query the user for authorization following the receipt of a
subscription request for which no authorization information was
present. The "watcherinfo" event sub-package for SIP [11] defines a
means by which a PUA can become aware that a user has attempted to
subscribe to it, and no authorization exists.
Authorization decisions can be very complex. Ultimately, all
authorization decisions can be mapped into one of three states:
rejected, successful, and pending. Any subscription for which the
client is authorized to receive information about some subset of
presence state at some points in time is a successful subscription.
Any subscription for which the client will never receive any
information about any subset of the presence state is a rejected
subscription. Any subscription for which it is not known yet whether
it is successful or rejected is pending. Generally, pending occurs
when the server cannot obtain authorization at this time, and may be
Rosenberg et al. [Page 8]
Internet Draft presence November 21, 2001
able to do so at a later time, when the presentity becomes available.
If a PA wishes to communicate a successful subscription to the
subscriber, it MUST send a 200 OK response to the SUBSCRIBE. If a PA
wishes to communicate a rejected subscription to the subscriber, it
MUST send a 603 response. If a PA wishes to communicate a pending
subscription to the subscriber, it MUST send a 202 response. Note
that the actual state of the subscription need not be what is
communicated to the subscriber.
Any other valid responses, as specified in [2] MAY be used as well.
Any subscription that generates a 2xx response (which includes
pending and successful subscriptions)MUST generate an immediate
NOTIFY request which MAY conntain a presence document in a format
acceptable to the subscriber (based on the Accept header in the
subscription). This document would indicate whatever presence state
the subscriber has been authorized to see; it is interpreted by the
subscriber as the current presence state of the presentity. For
pending subscriptions, the state of the presentity SHOULD include
some kind of textual note that indicates a pending status.
OPEN ISSUE: Once we finalize how subscription status is
conveyed in the NOTIFY, that text will go here.
Polite blocking, as described in [12], is possible by generating a
200 OK to the subscription even though it has been rejected (or
marked pending). Of course, an immediate NOTIFY MUST be sent also.
The contents of the presence document in such a NOTIFY are at the
discretion of the implementor, but SHOULD be constructed in such a
way as to not reveal to the subscriber that their request has
actually been blocked.
In many cases, it is useful for the response to the SUBSCRIBE to
provide the logical identity of the PA which generated the response.
This may not be the same as the user that the SUBSCRIBE was
originally targeted at, because of request forwarding. SIP extensions
have been defined to provide this capability [7].
5.8 Notifier Generation of NOTIFY Requests
If a subscription results in any 2xx response, that response MUST be
followed by an immediate NOTIFY.
OPEN ISSUE: handling of 2xx/NOTIFY race condition?
That NOTIFY request MAY contain a body indicating the state of the
Rosenberg et al. [Page 9]
Internet Draft presence November 21, 2001
presentity. In the case of a pending subscription, when final
authorization is determined, another NOTIFY SHOULD be sent. If the
result of the authorization decision was success, the NOTIFY SHOULD
contain a presence document with the current state of the presentity.
If the subscription is rejected, a NOTIFY MAY be sent, with a
Subscription-Expires of duration zero and a reason code of "refused"
to indicate the failure of the subscription.
For any subscription that is immediately or eventually determined to
be successful, notifications MAY be sent at later times, possibly
when the presence state of the presentity changes.
The body of the NOTIFY MUST be sent using one of the types listed in
the Accept header in the most recent SUBSCRIBE request, or using the
type "application/cpim-pidf+xml" if no Accept header was present.
The times at which the NOTIFY is sent for a particular subscriber,
and the contents of the body within that notification, are subject to
any rules specified by the authorization policy that governs the
subscription. This protocol in no way limits the scope of such
policies. As a baseline, a reasonable policy is to generate
notifications when the state of any of the communications addresses
changes. These notifications contain the complete and current
presence state of the presentity as known to the presence agent.
Future extensions MAY be defined that allow a subscriber to request
that the notifications contain changes in presence information only,
rather than complete state.
The means by which the PA learns the state of the presentity are also
outside the scope of this recommendation. Registrations can provide
one way, although the means (if any) by which a PA uses registrations
to construct a presence document are an implementation choice. If a
PUA wishes to explicitly inform the presence agent of its presence
state, it should explicitly upload the presence document (or its
piece of it) rather than attempting to manipulate their registrations
to achieve the desired result.
For reasons of privacy, it will frequently be necessary to encrypt
the contents of the notifications. This can be accomplished using the
standard SIP encryption mechanisms. The encryption should be
performed using the key of the subscriber as identified in the From
field of the SUBSCRIBE. Similarly, integrity of the notifications is
important to subscribers. As such, the contents of the notifications
SHOULD be authenticated using one of the standardized SIP mechanisms.
Since the NOTIFY are generated by the presence server, which may not
have access to the key of the user represented by the presentity, it
will frequently be the case that the NOTIFY are signed by a third
party. It is RECOMMENDED that the signature be by an authority over
Rosenberg et al. [Page 10]
Internet Draft presence November 21, 2001
domain of the presentity. In other words, for a user
pres:user@example.com, the signator of the NOTIFY SHOULD be the
authority for example.com.
OPEN ISSUE: We should do better here; recommending more
specific things than "standard SIP encryption" - S/MIME,
for example.
5.9 Subscriber Processing of NOTIFY Requests
The NOTIFY requests contain presence documents which describe the
presentity. The subscriber SHOULD reject, with a 481 response, all
NOTIFY requests whose From field tag does not match the tag in the To
field of the 2xx to the SUBSCRIBE. This means that only a single PA
can be active for a particular subscription.
OPEN ISSUE: What if the NOTIFY beats the 2xx back to the
SUBSCRIBER? This is a sip-events issue, but the resolution
affects us.
The presence documents delivered in NOTIFY are ordered through the
CSeq in the NOTIFY requests. The presence document in the NOTIFY
request with the highest CSeq value is the current one.
Assuming the NOTIFY request is valid, and authenticated, a 200
response MUST be sent.
5.10 Handling of Forked Requests
Since SUBSCRIBE is routed by proxies as any other method, it is
possible that a subscription might fork. The result is that it might
arrive at multiple devices which are configured to act as a PA for
the same presentity. Some of these may respond with a 2xx response to
the SUBSCRIBE. Based on the forking rules in SIP, only one of these
responses is passed to the subscriber. However, the subscriber will
receive notifications from each of those PA which accepted the
subscriptions. The SIP event framework allows each package to define
the handling for this case.
The processing in this case is identical to the way INVITE would be
handled. The 2xx response to the SUBSCRIBE will result in the
installation of subscription state in the subscriber. The
subscription is associated with the To and From (both with tags) and
Call-ID from the 2xx. When notifications arrive, those from the PA's
whose 2xx's were discarded in the forking proxy will not match the
subscription ID stored at the subscriber (the From tags will differ).
Rosenberg et al. [Page 11]
Internet Draft presence November 21, 2001
These SHOULD be responded to with a 481. This will disable the
subscriptions from those PA.
The result of this is that a presentity can have multiple PAs active,
but these should be homogeneous, so that each can generate the same
set of notifications for the presentity. Supporting heterogeneous
PAs, each of which generated notifications for a subset of the
presence data, is complex and difficult to manage. Doing so would
require the subscriber to act as the aggregator for presence data.
This aggregation function can only reasonably be performed by agents
representing the presentity. Therefore, if aggregation is needed, it
MUST be done in a PA present in a network server representing the
presentity that has access to the total set of user presence to be
aggregated.
5.11 Rate of Notifications
For reasons of congestion control, it is important that the rate of
notifications not become excessive. As a result, it is RECOMMENDED
that the PA not generate notifications for a single presentity at a
rate faster than once every 5 seconds.
5.12 State Agents and Notifier Migration
It is important to realize that the PA function can be colocated with
several elements:
o It can be co-located with the SIP registrar handling
registrations for the presentity (the co-location of the PA
within the proxy/registrar is known as a presence server). In
this way, the presence server knows the presence of the user
through registrations or other means.
o It can be co-located with a PUA for that presentity (the co-
location of the PA within the PUA is known as a presence
client). In the case of a single PUA per presentity, the PUA
knows the state of the presentity by sheer nature of its co-
location.
o It can be co-located in any server along the call setup path.
That proxy can learn the presence state of the presentity by
generating its own SUBSCRIBE in order to determine it. In this
case, the PA is effectively a B2BUA.
On occassion, it makes sense for the PA function to migrate from one
of these places to another. For example, for reasons of scale, the PA
function may reside in the presence server when the PUA is not
running, but when the PUA connects to the network, the PA decides to
Rosenberg et al. [Page 12]
Internet Draft presence November 21, 2001
migrate subscriptions to it in order to reduce state in the network.
There are three phases to this migration:
o The element currently providing the PA function determines
that another element is capable of handling the subscription.
o That element currently hosting the PA function destroys
subscription state, and inform those subscribers that the
state needs to be re-established with a new SUBSCRIBE.
o When the subscribers re-SUBSCRIBE, the request is proxied,
eventually arriving at the new element performing the PA
function. That element accepts the request and creates a
subscription.
The first of these phases can occur through configuration, or through
dynamic means. One dynamic means for a presence server to discover
that the function can migrate to a PUA is through the REGISTER
message. Specifically, if a PUA wishes to indicate support for the PA
function, it SHOULD include a contact address in its registration
with a caller preferences "methods" parameter listing SUBSCRIBE [13].
This indicates that it is capable of terminating and processing
SUBSCRIBE, and therefore can act as a PA. However, just because a PUA
indicates it can accept subscriptions, does not mean a PA should
migrate the subscriptions there. In particular, a PA SHOULD NOT
migrate the subscription if it is composing aggregated presence
documents from state received from several PUA.
Because of the forking rules described in Section 5.10, a subscriber
will only get presence information from one PA, and this information
has to be complete. Because the "methods" parameter does not convey
the set of event packages for which the PUA can accept SUBSCRIBE, it
is possible that the PUA will begin receiving SUBSCRIBE requests for
other packages, possibly ones it doesn't support. As specified in
[3], the PUA SHOULD reject those requests with a 489.
For the second phase, the PA destroys the subscriptions and then
sends a NOTIFY to each subscriber, with an Subscription-Expires
header with value 0 [3] and a reason code of "migration". This
informs the subscribers that their subscription was destroyed, and
should be re-established with a new SUBSCRIBE (with a new Call-ID). A
PA SHOULD rate limit the notifications, in order to avoid a flood of
simultaneous re-SUBSCRIBEs from all subscribers.
The subscribers then create brand new subscriptions, with a new
Call-ID, no route set and no To tag, and this is sent to recreate the
subscription. In the case where the subscription has migrated to the
Rosenberg et al. [Page 13]
Internet Draft presence November 21, 2001
presence server, the presence server will simply act as a PA for
these new subscriptions. In the case where the subscription has
migrated from the presence server to the PUA, the presence server
MUST operate like a proxy. Furthermore, it SHOULD implement the SIP
Caller preferences extension [13]. Because of the existence of a
registered Contact with a "methods" parameter containing SUBSCRIBE,
the caller preferences extension will cause the proxy to send the
SUBSCRIBEs to that Contact. Assuming it accepts, a 2xx is generated
and forwarded to the subscriber. The subscriber will now receive and
accept notifications from that PA.
Migration of subscriptions will still work if the proxy does not
support the caller preferences extension. However, the proxy will
instead fork the SUBSCRIBE, possibly to Contacts which have not
indicated that they support SUBSCRIBE. The result will be 405
responses from those UAS. However, the one UAS which does support the
method will generate a 2xx class response (assuming the subscription
is accepted), and this will be correctly forwarded towards the
subscriber based on proxy response processing rules [2]. The penalty
of not supporting caller preferences is the additional unneeded SIP
traffic.
6 Publication
The user presence for a presentity can be obtained from any number of
different ways. None of these mechanisms are mandated by this
specification. The discussion here is for informational purposes
only.
6.1 Co-location
When the PA function is co-located with the PUA, user presence is
known directly by the PA.
6.2 REGISTER
Baseline SIP defines a method that is used by all SIP clients - the
REGISTER method. This method allows a UA to inform a SIP network of
its current communications addresses (ie., Contact addresses) .
Furthermore, multiple UA can independently register Contact addresses
for the same SIP URL. These Contact addresses can be SIP URLs, or
they can be any other valid URL.
Usage of REGISTER information to construct presence is only possible
if the PA is co-located with, or shares information with, the SIP
registrar. In this case, the combined PA/registrar/proxy is known as
a presence server.
Rosenberg et al. [Page 14]
Internet Draft presence November 21, 2001
Using the register information for presence is straightforward. The
address of record in the REGISTER (the To field) identifies the
presentity. The Contact headers define communications addresses that
describe the state of the presentity. The use of the SIP caller
preferences extension [13] is RECOMMENDED for use with UAs that are
interested in presence. It provides additional information about the
Contact addresses that can be used to construct a richer presence
document.
The presence of a registered Contact with a "methods" parameter [13]
listing the MESSAGE method implies that the presentity supports
instant messaging as a communications means.
The q values from the Contact header [2] can be used to establish
priorities amongst the various communications addresses in the
Contact headers.
The application of registered contacts to presence increases the
requirements for authenticity. Therefore, REGISTER requests used by
presence user agents SHOULD be authenticated using either SIP
authentication mechanisms, or a hop-by-hop mechanism.
6.3 Uploading Presence Documents
If a means exists to upload presence documents from PUA to the PA,
the PA can act as an aggregator and redistributor of those documents.
The PA, in this case, would take the presence documents received from
each PUA for the same presentity, and merge the communications means
across all of those PUA into a single presence document. Typically,
this aggregation would be accomplished through administrator or user
defined policies about how the aggregation should be done.
The specific means by which a presence document are uploaded to a
presence agent are outside the scope of this specification. When a
PUA wishes to have direct manipulation of the presence that is
distributed to subscribers, direct uploading of presence documents is
RECOMMENDED.
7 Security considerations
There are numerous security considerations for presence. Many are
outlined above; this section considers them issue by issue.
7.1 Firewall and NAT Traversal
It is anticipated that presence services will be used by clients and
presentities that are connected to proxy servers on the other side of
firewalls and NATs. Fortunately, since the SIP presence messages do
Rosenberg et al. [Page 15]
Internet Draft presence November 21, 2001
not establish independent media streams, as INVITE does, firewall and
NAT traversal is straightforward.
Specifically, the SIP extensions for NAT traversal [14] are directly
applicable to SUBSCRIBE and NOTIFY, and will allow operation of the
protocol through NATs. Firewall administrators can set policies that
allow or disallow communications services by opening or closing
access to port 5060 (the default SIP port).
7.2 Privacy
Privacy encompasses many aspects of a presence system:
o Subscribers may not want to reveal the fact that they have
subscribed to certain users
o Users may not want to reveal that they have accepted
subscriptions from certain users
o Notifications (and fetch results) may contain sensitive data
which should not be revealed to anyone but the subscriber
Privacy is provided through a combination of hop by hop encryption
and end to end encryption. The hop by hop mechanisms provide scalable
privacy services, disable attacks involving traffic analysis, and
hide all aspects of presence messages. However, they operate based on
transitivity of trust, and they cause message content to be revealed
to proxies. The end-to-end mechanisms do not require transitivity of
trust, and reveal information only to the desired recipient. However,
end-to-end encryption cannot hide all information, and is susceptible
to traffic analysis. Strong end to end authentication and encryption
also requires that both participants have public keys, which is not
generally the case. Thus, both mechanisms combined are needed for
complete privacy services.
SIP allows any hop by hop encryption scheme. It is RECOMMENDED that
TLS [15] be used between elements to provide this function. The
presence server can determine whether TLS is supported by the
receiving client based on the transport parameter in the Contact
header of its registration. If there is a registered Contact with a
URL that contains a transport parameter with value "tls", it implies
that the PUA supports TLS.
SIP encryption MAY be used end to end for the transmission of both
SUBSCRIBE and NOTIFY requests.
7.3 Message integrity and authenticity
Rosenberg et al. [Page 16]
Internet Draft presence November 21, 2001
It is important for the message recipient to ensure that the message
contents are actually what was sent by the originator, and that the
recipient of the message be able to determine who the originator
really is. This applies to both requests and responses of SUBSCRIBE
and NOTIFY. This is supported in SIP through end to end
authentication and message integrity. SIP provides http basic and
digest authentication. HTTP Basic is NOT RECOMMENDED.
7.4 Outbound authentication
When local proxies are used for transmission of outbound messages,
proxy authentication is RECOMMENDED. This is useful to verify the
identity of the originator, and prevent spoofing and spamming at the
originating network.
7.5 Replay prevention
To prevent the replay of old subscriptions and notifications, all
signed SUBSCRIBE and NOTIFY requests and responses MUST contain a
Date header covered by the message signature. Any message with a date
older than several minutes in the past, or more than several minutes
into the future, SHOULD be discarded.
Furthermore, all signed SUBSCRIBE and NOTIFY requests MUST contain a
Call-ID and CSeq header covered by the message signature. A user
agent or presence server MAY store a list of Call-ID values, and for
each, the higest CSeq seen within that Call-ID. Any message that
arrives for a Call-ID that exists, whose CSeq is lower than the
highest seen so far, is discarded.
Finally, challenge-response authentication MAY be used to prevent
replay attacks.
7.6 Denial of service attacks
Denial of service attacks are a critical problem for an open, inter-
domain, presence protocol. Here, we discuss several possible attacks,
and the steps we have taken to prevent them.
7.6.1 Smurf attacks through false contacts
Unfortunately, presence is a good candidate for smurfing attacks
because of its amplification properties. A single SUBSCRIBE message
could generate a nearly unending stream of notifications, so long as
a suitably dynamic source of presence data can be found. Thus, a
simple way to launch an attack is to send subscriptions to a large
number of users, and in the Contact header (which is where
notifications are sent), place the address of the target.
Rosenberg et al. [Page 17]
Internet Draft presence November 21, 2001
The only reliable way to prevent these attacks is through
authentication and authorization. End users will hopefully not accept
subscriptions from random unrecognized users. Also, the presence
client software could be programmed to warn the user when the Contact
header in a SUBSCRIBE is from a domain which does not match that of
the From field (which identifies the subscriber).
Also, note that as described in [3], if a NOTIFY is not acknowledged
or was not wanted, the subscription that generated it is removed.
This eliminates the amplification properties of providing false
Contact addresses.
8 Example message flows
The following subsections exhibit example message flows, to further
clarify behavior of the protocol. When the value of the Content-
Length header is "..." this means that the value should be whatever
the computed length of the body is.
8.1 Client to Client Subscription with Presentity State Changes
This call flow illustrates subscriptions and notifications that do
not involve a presence server.
The watcher subscribes to the presentity, and the subscription is
authorized, resulting in a 200 OK response. The presentity
subsequently changes state (is on the phone), resulting in a new
notification. The flow finishes with the watcher terminating the
subscription.
Watcher Presentity
------- -----------
| F1 SUBSCRIBE |
| ----------------------------->|
| F2 200 OK |
|<------------------------------|
| F3 NOTIFY |
|<------------------------------|
| F4 200 OK |
|------------------------------>|
| F5 NOTIFY |
|<------------------------------|
| F6 200 OK |
|------------------------------>|
| F7 SUBSCRIBE (unsub) |
Rosenberg et al. [Page 18]
Internet Draft presence November 21, 2001
|------------------------------>|
| F8 200 OK |
|<------------------------------|
| F9 NOTIFY |
|<------------------------------|
| F10 200 OK |
|------------------------------>|
Message Details
F1 SUBSCRIBE watcher -> presentity
SUBSCRIBE sip:presentity@pres.example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>;tag=9988
To: Resource <sip:presentity@example.com>
Call-ID: 3248543@watcherhost.example.com
CSeq : 1 SUBSCRIBE
Expires: 600
Accept: application/cpim-pidf+xml
Event: presence
Contact: sip:user@watcherhost.example.com
Content-Length: 0
F2 200 OK presentity->watcher
SIP/2.0 200 OK
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>;tag=9988
To: Resource <sip:presentity@example.com>;tag=88a7s
Call-ID: 3248543@watcherhost.example.com
Cseq: 1 SUBSCRIBE
Event: presence
Expires: 600
Contact: sip:presentity@pres.example.com
Content-Length: 0
Rosenberg et al. [Page 19]
Internet Draft presence November 21, 2001
F3 NOTIFY Presentity->watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pres.example.com:5060
From: Resource <sip:presentity@example.com>;tag=88a7s
To: User <sip:user@example.com>;tag=9988
Call-ID: 3248543@watcherhost.example.com
CSeq: 1 NOTIFY
Event: presence
Content-Type: application/cpim-pidf+xml
Content-Length: ...
<presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
<tuple name="ph-1">
<status>
<value>open</value>
<detail type="phone"
schema="http://www.ietf.org/dtd/im-type-phone.dtd">on-hook</detail>
</status>
<contact priority="2">sip:user@example.com</contact>
</tuple>
</presence>
F4 200 OK watcher->presentity
SIP/2.0 200 OK
Via: SIP/2.0/UDP pres.example.com:5060
From: Resource <sip:presentity@example.com>;tag=88a7s
To: User <sip:user@example.com>;tag=9988
Call-ID: 3248543@watcherhost.example.com
CSeq: 1 NOTIFY
Content-Length: 0
F5 NOTIFY Presentity->watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pres.example.com:5060
From: Resource <sip:presentity@example.com>;tag=88a7s
To: User <sip:user@example.com>;tag=9988
Call-ID: 3248543@watcherhost.example.com
Rosenberg et al. [Page 20]
Internet Draft presence November 21, 2001
CSeq: 2 NOTIFY
Event: presence
Content-Type: application/cpim-pidf+xml
Content-Length: ...
<presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
<tuple name="ph-1">
<status>
<value>closed</value>
<detail type="phone"
schema="http://www.ietf.org/dtd/im-type-phone.dtd">off-hook</detail>
</status>
<contact priority="2">sip:user@example.com</contact>
</tuple>
</presence>
F6 200 OK watcher->presentity
SIP/2.0 200 OK
Via: SIP/2.0/UDP pres.example.com:5060
From: Resource <sip:presentity@example.com>;tag=88a7s
To: User <sip:user@example.com>;tag=9988
Call-ID: 3248543@watcherhost.example.com
CSeq: 2 NOTIFY
Content-Length: 0
F7 SUBSCRIBE watcher -> presentity
SUBSCRIBE sip:presentity@pres.example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
Call-ID: 3248543@watcherhost.example.com
To: Resource <sip:presentity@example.com>;tag=88a7s
From: User <sip:user@example.com>;tag=9988
Event: presence
CSeq : 2 SUBSCRIBE
Expires: 0
Accept: application/cpim-pidf+xml
Contact: sip:user@watcherhost.example.com
Content-Length: 0
Rosenberg et al. [Page 21]
Internet Draft presence November 21, 2001
F8 200 OK presentity->watcher
SIP/2.0 200 OK
Via: SIP/2.0/UDP watcherhost.example.com:5060
Call-ID: 3248543@watcherhost.example.com
To: Resource <sip:presentity@example.com>;tag=88a7s
From: User <sip:user@example.com>;tag=9988
Event: presence
Cseq: 2 SUBSCRIBE
Expires:0
Contact: sip:presentity@pres.example.com
Content-Length: 0
F9 NOTIFY Presentity->watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pres.example.com:5060
From: Resource <sip:presentity@example.com>;tag=88a7s
To: User <sip:user@example.com>;tag=9988
Call-ID: 3248543@watcherhost.example.com
CSeq: 3 NOTIFY
Event: presence
Content-Type: application/cpim-pidf+xml
Content-Length: ...
<presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
<tuple name="ph-1">
<status>
<value>closed</value>
<detail type="phone"
schema="http://www.ietf.org/dtd/im-type-phone.dtd">off-hook</detail>
</status>
<contact priority="2">sip:user@example.com</contact>
</tuple>
</presence>
F10 200 OK watcher->presentity
SIP/2.0 200 OK
Rosenberg et al. [Page 22]
Internet Draft presence November 21, 2001
Via: SIP/2.0/UDP pres.example.com:5060
From: Resource <sip:presentity@example.com>;tag=88a7s
To: User <sip:user@example.com>;tag=9988
Call-ID: 3248543@watcherhost.example.com
CSeq: 3 NOTIFY
Content-Length: 0
8.2 Presence Server with Client Notifications
This call flow shows the involvement of a presence server in the
handling of subscriptions. In this scenario, the client has indicated
that it will handle subscriptions and thus notifications. The message
flow shows a change of presence state by the client and a
cancellation of the subscription by the watcher.
Presence
Watcher Server PUA
| | F1 REGISTER |
| |<---------------------|
| | F2 200 OK |
| |--------------------->|
| F3 SUBSCRIBE | |
|--------------------->| |
| | F4 SUBSCRIBE |
| |--------------------->|
| | F5 200 |
| |<---------------------|
| F6 200 | |
|<---------------------| |
| F7 NOTIFY | |
|<--------------------------------------------+
| F8 200 OK | |
|-------------------------------------------->|
| | F9 REGISTER |
| |<---------------------|
| | F10 200 OK |
| |--------------------->|
| F11 NOTIFY | |
|<--------------------------------------------+
| F12 200 OK | |
|-------------------------------------------->|
Rosenberg et al. [Page 23]
Internet Draft presence November 21, 2001
Message Details
F1 REGISTER PUA->server
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com>
From: <sip:resource@example.com>
Call-ID: 2818@pua.example.com
CSeq: 1 REGISTER
Contact: <sip:id@pua.example.com>;methods="MESSAGE,SUBSCRIBE"
Expires: 600
Content-Length: 0
F2 200 OK server->PUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com>
From: <sip:resource@example.com>
Call-ID: 2818@pua.example.com
CSeq: 1 REGISTER
Contact: <sip:id@pua.example.com>;methods="MESSAGE,SUBSCRIBE"
Expires: 600
Content-Length: 0
F3 SUBSCRIBE watcher->server
SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>;tag=ggf8
To: Resource <sip:resource@example.com>
Call-ID: 32485@watcherhost.example.com
CSeq : 1 SUBSCRIBE
Expires: 600
Rosenberg et al. [Page 24]
Internet Draft presence November 21, 2001
Event: presence
Accept: application/cpim-pidf+xml
Contact: sip:user@watcherhost.example.com
Content-Length: 0
F4 SUBSCRIBE server->PUA
SUBSCRIBE sip:id@pua.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>;tag=ggf8
To: Resource <sip:resource@example.com>
Call-ID: 32485@watcherhost.example.com
CSeq : 1 SUBSCRIBE
Event: presence
Expires: 600
Accept: application/cpim-pidf+xml
Contact: sip:user@watcherhost.example.com
Content-Length: 0
F5 200 OK PUA->server
SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>;tag=ggf8
To: Resource <sip:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq : 1 SUBSCRIBE
Event: presence
Expires: 600
Contact: sip:id@pua.example.com
Content-Length: 0
Rosenberg et al. [Page 25]
Internet Draft presence November 21, 2001
F6 200 OK server->watcher
SIP/2.0 200 OK
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>;tag=ggf8
To: Resource <sip:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq : 1 SUBSCRIBE
Event: presence
Expires: 600
Contact: sip:id@pua.example.com
Content-Length: 0
F7 NOTIFY PUA->watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: User <sip:user@example.com>;tag=ggf8
From: Resource <sip:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq : 1 NOTIFY
Event: presence
Content-Type: application/cpim-pidf+xml
Content-Length: ...
<presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
<tuple name="im-1">
<status>
<value>open</value>
<detail type="im"
schema="http://www.ietf.org/dtd/im-type-im.dtd">available</detail>
</status>
<contact priority="2">im:user@example.com</contact>
</tuple>
</presence>
F8 200 OK watcher->PUA
Rosenberg et al. [Page 26]
Internet Draft presence November 21, 2001
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To: User <sip:user@example.com>;tag=ggf8
From: Resource <sip:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq : 1 NOTIFY
Content-Length: 0
F9 REGISTER PUA->server
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com>
From: <sip:resource@example.com>
Call-ID: 2818@pua.example.com
CSeq: 2 REGISTER
Contact: <sip:id@pua.example.com>;methods="MESSAGE,SUBCSRIBE"
;q=0.0
Expires: 600
Content-Length: 0
F10 200 OK server->PUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com>
From: <sip:resource@example.com>
Call-ID: 2818@pua.example.com
CSeq: 2 REGISTER
Contact: <sip:id@pua.example.com>;methods="MESSAGE,SUBSCRIBE"
;q=0.0
Expires: 600
Content-Length: 0
Rosenberg et al. [Page 27]
Internet Draft presence November 21, 2001
F11 NOTIFY PUA->watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: User <sip:user@example.com>;tag=ggf8
From: Resource <sip:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq : 2 NOTIFY
Event: presence
Content-Type: application/cpim-pidf+xml
Content-Length: ...
<presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
<tuple name="im-1">
<status>
<value>open</value>
<detail type="im"
schema="http://www.ietf.org/dtd/im-type-im.dtd">available</detail>
</status>
<contact priority="2">im:user@example.com</contact>
</tuple>
</presence>
F12 200 OK watcher->PUA
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To: User <sip:user@example.com> ;tag=ggf8
From: Resource <sip:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq : 2 NOTIFY
Content-Length: 0
8.3 Presence Server Notifications
This message flow illustrates how the presence server can be the
responsible for sending notifications for a presentity. This flow
assumes that the watcher has previously been authorized to subscribe
to this resource at the server.
Rosenberg et al. [Page 28]
Internet Draft presence November 21, 2001
In this flow, the PUA informs the server about the updated presence
information though some non-SIP means.
Watcher Server PUA
| F1 SUBSCRIBE | |
|------------------>| |
| F2 200 OK | |
|<------------------| |
| F3 NOTIFY | |
|<------------------| |
| F4 200 OK | |
|------------------>| |
| | |
| | Update presence |
| |<------------------ |
| | |
| F5 NOTIFY | |
|<------------------| |
| F6 200 OK | |
|------------------>| |
Message Details
F1 SUBSCRIBE watcher->server
SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
To: <sip:resource@example.com>
From: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Event: presence
Accept: application/cpim-pidf+xml
Contact: <sip:user@watcherhost.example.com>
Expires: 600
Content-Length: 0
Rosenberg et al. [Page 29]
Internet Draft presence November 21, 2001
F2 202 OK server->watcher
SIP/2.0 200 OK
Via: SIP/2.0/UDP watcherhost.example.com:5060
To: <sip:resource@example.com>;tag=ffd2
From: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Event: presence
Expires: 600
Contact: sip:example.com
Content-Length: 0
F3 NOTIFY server-> watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
Event: presence
CSeq: 1 NOTIFY
Content-Type: application/cpim-pidf+xml
Content-Length: ..
<presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
<tuple name="im-1">
<status>
<value>open</value>
<detail type="im"
schema="http://www.ietf.org/dtd/im-type-im.dtd">available</detail>
</status>
<contact priority="2">im:user@example.com</contact>
</tuple>
</presence>
F4 200 OK
SIP/2.0 200 OK
Rosenberg et al. [Page 30]
Internet Draft presence November 21, 2001
Via: SIP/2.0/UDP server.example.com:5060
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 1 NOTIFY
Content-Length: 0
F5 NOTIFY
NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 2 NOTIFY
Event: presence
Content-Type: application/cpim-pidf+xml
Content-Length: ...
<presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
<tuple name="im-1">
<status>
<value>closed</value>
<detail type="im"
schema="http://www.ietf.org/dtd/im-type-im.dtd">busy</detail>
</status>
<contact priority="2">im:user@example.com</contact>
</tuple>
</presence>
F6 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 2 NOTIFY
Rosenberg et al. [Page 31]
Internet Draft presence November 21, 2001
Content-Length: 0
o When migrating subscriptions, a PA SHOULD rate limit its
notifications in order to avoid a flood of simultaneous re-
subscriptions.
o Clarified that there can be multiple PAs for a presentity.
o Fixed last of 2xx/200/202 confusions.
o Added text to handle the case where a PUA receives
subscriptions for Event packages it doesn't understand,
because it registered support for the SUBSCRIBE method.
o Alignment with events-01
o Migration recommended only if PA is not generating presence
documents composed from multiple sources.
o No longer calling this document an extension, since its not.
Its an Event Package.
o Clarified migration section so that applies equally well to PS
to PUA, and PUA to PS. Previous text assumed PS to PUA only.
o Changed the default filter to "no filter".
o Removed Section 6.4 on "Call State Subscription" since it is
informational but may confused those not familiar with the
referenced work.
o Removed PGP references since these have been deprecated from
SIP.
o We now allow a proxy to migrate a subscription even if there
are multiple registered contacts supporting SUBSCRIBE. The
text has clarified that a PUA should only register support for
SUBSCRIBE if it has complete state about the presentity.
Rosenberg et al. [Page 32]
Internet Draft presence November 21, 2001
o Complete alignment with draft-ietf-sip-events.
o Removal of non-confirming mode. Instead, just mention that
polite blocking is possible, and how it is done is
implementation specific.
o Removed CPIM sections to a separate specification.
o Added reference to privacy specification for transitive
authentication scenarios.
o Implementation of caller preferneces by presence servers is
now a SHOULD.
o Clarification on the process of subscription migration.
o For subscription migration, the specification now mentions the
Subscription-Expires header as the means for a PA to inform
subscribers that their subscription has expired. This header
has yet to appear in draft-ietf-sip-events.
o Updated section of usage of presence URLs based on consensus
of the IMPP group at IETF 51.
o Construction of presence documents based on REGISTER is now
defined as implementation dependent. If a UA wants to
manipulate its presence, it should upload a presence document
fragment instead.
o Removed bit about recreating subscriptions when a 481 is
received to a SUBSCRIBE request. This should be in draft-
ietf-sip-events instead.
o Removed references to draft-lennox-sip-reg-payload and much of
that discussion. Now, the section talks more generally about
uploading and aggregation of presence documents, and simply
states that the means for such upload is outside the scope of
this spec.
o Updated example flows. Consistent use of From tags,
elimination of pres URL, usage of application/cpim-pidf+xml
types. Fixed caller preferences usage bug.
o Clarified that user presence can be obtained in many ways, not
just SIP.
Rosenberg et al. [Page 33]
Internet Draft presence November 21, 2001
o Defined the default notification content when a filter is not
provided in the body of a SUBSCRIBE.
o Removed text about the inability of a PA to increase a
subscription expiration time (this needs to be reconciled with
draft-ietf-sip-events.
o Removed requirement that authentication be end-to-end only,
and not transitive. This is not practical at all, and
transitive trust is likely to be the only deployable mechanism
initially.
o Removed the Appendix on the watcher info mechanism for
triggering authorization decisions; draft-ietf-simple-winfo-
package is now referenced.
o Defined confirming and non-confirming modes for revealing
authorization information.
o Strengthened the section about how a PA obtains information
about the presentity.
o Updated section on migrating PA function.
o Added requirement that a subscriber generate a new
subscription when a refresh fails with a 481.
o Removed transport mode ESP as the reccommended inter-server
transport. TLS is now consistently recommended.
o Removed insertion of tls transport parameter into Contact
header in 200 OK response to SUBSCRIBE. This is because this
parameter needs to be UDP for interoperability.
Renamed to draft-ietf-simple-presence-00.
The document has been completely rewritten, to reflect the change
from a sales pitch and educational document, to a more formal
protocol specification. It has also been changed to align with the
SIP event architecture and with CPIM. The specific protocol changes
resulting from this rewrite are:
o The Event header must now be used in the SUBSCRIBE and NOTIFY
requests.
Rosenberg et al. [Page 34]
Internet Draft presence November 21, 2001
o The SUBSCRIBE message can only have a single Contact header.
-00 allowed for more than one.
o The From and To headers can contain presence URIs.
o The Request-URI can contain a presence URI.
o Subscriptions are responded to with a 202 if they are pending
or accepted.
o Presence documents are not returned in the body of the
SUBSCRIBE response. Rather, they are sent in a separate
NOTIFY. This more cleanly separates subscription and
notification, and is mandated by alignment with CPIM.
o Authentication is now mandatory at the PA. Authorization is
now mandatory at the PA.
o Fake NOTIFY is sent for pending or rejected subscriptions.
o A rate limit on notifications was introduced.
o Merging of presence data has been removed.
o The subscriber rejects notifications received with tags that
don't match those in the 202 response to the SUBSCRIBE. This
means that only one PA will hold subscription state for a
particular subscriber for a particular presentity.
o IM URLs allowed in Contacts in register
o CPIM mappings defined.
o Persistent connections recommended for firewall traversal.
15 Acknowledgements
We would like to thank the following people for their support and
comments on this draft:
Rick Workman Nortel
Adam Roach Ericsson
Sean Olson Ericsson
Billy Biggs University of Waterloo
Stuart Barkley UUNet
Mauricio Arango SUN
Richard Shockey Shockey Consulting LLC
Rosenberg et al. [Page 35]
Internet Draft presence November 21, 2001
Jorgen Bjorkner Hotsip
Henry Sinnreich MCI Worldcom
Ronald Akers Motorola
16 Authors Addresses
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com
Dean Willis
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, Texas 75024
email: dwillis@dynamicsoft.com
Robert Sparks
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, Texas 75024
email: rsparks@dynamicsoft.com
Ben Campbell
5100 Tennyson Parkway
Suite 1200
Plano, Texas 75024
email: bcampbell@dynamicsoft.com
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
email: schulzrinne@cs.columbia.edu
Jonathan Lennox
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
Rosenberg et al. [Page 36]
Internet Draft presence November 21, 2001
email: lennox@cs.columbia.edu
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
email: huitema@microsoft.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
email: bernarda@microsoft.com
David Gurle
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
email: dgurle@microsoft.com
David Oran
Cisco Systems
170 West Tasman Dr.
San Jose, CA 95134
email: oran@cisco.com
17 Bibliography
[1] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and
instant messaging," Request for Comments 2778, Internet Engineering
Task Force, Feb. 2000.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999.
[3] A. Roach, "SIP-specific event notification," Internet Draft,
Internet Engineering Task Force, Nov. 2001. Work in progress.
[4] D. Crocker et al. , "A common profile for instant messaging
(CPIM)," Internet Draft, Internet Engineering Task Force, Feb. 2001.
Work in progress.
[5] A. Roach, "Event notification in SIP," Internet Draft, Internet
Engineering Task Force, Feb. 2001. Work in progress.
Rosenberg et al. [Page 37]
Internet Draft presence November 21, 2001
[6] H. Sugano and S. Fujimoto, "CPIM presence information data
format," Internet Draft, Internet Engineering Task Force, Aug. 2001.
Work in progress.
[7] B. Marshall et al. , "SIP extensions for caller identity and
privacy," Internet Draft, Internet Engineering Task Force, Mar. 2001.
Work in progress.
[8] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, and G.
Zorn, "Diameter base protocol," Internet Draft, Internet Engineering
Task Force, July 2001. Work in progress.
[9] C. Rigney, S. Willens, A. Rubens, and W. Simpson, "Remote
authentication dial in user service (RADIUS)," Request for Comments
2865, Internet Engineering Task Force, June 2000.
[10] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, and A.
Sastry, "The COPS (common open policy service) protocol," Request for
Comments 2748, Internet Engineering Task Force, Jan. 2000.
[11] J. Rosenberg, "A SIP event sub-package for watcher information,"
Internet Draft, Internet Engineering Task Force, July 2001. Work in
progress.
[12] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant messaging
/ presence protocol requirements," Request for Comments 2779,
Internet Engineering Task Force, Feb. 2000.
[13] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and
callee capabilities," Internet Draft, Internet Engineering Task
Force, Nov. 2000. Work in progress.
[14] J. Rosenberg, J. Weinberger, and H. Schulzrinne, "SIP extensions
for NAT traversal," Internet Draft, Internet Engineering Task Force,
Aug. 2001. Work in progress.
[15] T. Dierks and C. Allen, "The TLS protocol version 1.0," Request
for Comments 2246, Internet Engineering Task Force, Jan. 1999.
Table of Contents
1 Introduction ........................................ 1
Rosenberg et al. [Page 38]
Internet Draft presence November 21, 2001
2 Definitions ......................................... 2
3 Overview of Operation ............................... 3
4 Usage of Presence URLs .............................. 4
5 Presence Event Package .............................. 5
5.1 Package Name ........................................ 5
5.2 Event Package Parameters ............................ 5
5.3 SUBSCRIBE bodies .................................... 5
5.4 Subscription Duration ............................... 6
5.5 NOTIFY Bodies ....................................... 6
5.6 Subscriber Generation of SUBSCRIBE Requests ......... 6
5.7 Notifier Processing of SUBSCRIBE Requests ........... 7
5.8 Notifier Generation of NOTIFY Requests .............. 9
5.9 Subscriber Processing of NOTIFY Requests ............ 11
5.10 Handling of Forked Requests ......................... 11
5.11 Rate of Notifications ............................... 12
5.12 State Agents and Notifier Migration ................. 12
6 Publication ......................................... 14
6.1 Co-location ......................................... 14
6.2 REGISTER ............................................ 14
6.3 Uploading Presence Documents ........................ 15
7 Security considerations ............................. 15
7.1 Firewall and NAT Traversal .......................... 15
7.2 Privacy ............................................. 16
7.3 Message integrity and authenticity .................. 16
7.4 Outbound authentication ............................. 17
7.5 Replay prevention ................................... 17
7.6 Denial of service attacks ........................... 17
7.6.1 Smurf attacks through false contacts ................ 17
8 Example message flows ............................... 18
8.1 Client to Client Subscription with Presentity
State Changes .................................................. 18
8.2 Presence Server with Client Notifications ........... 23
8.3 Presence Server Notifications ....................... 28
9 Changes from draft-ietf-simple-presence-03 .......... 32
10 Changes from draft-ietf-simple-presence-02 .......... 32
11 Changes from draft-ietf-simple-presence-01 .......... 32
12 Changes from draft-ietf-simple-presence-00 .......... 33
13 Changes from draft-rosenberg-impp-presence-01 ....... 34
14 Changes from draft-rosenberg-impp-presence-00 ....... 34
15 Acknowledgements .................................... 35
16 Authors Addresses ................................... 36
17 Bibliography ........................................ 37
Rosenberg et al. [Page 39]
