view Side-By-Side changes
Internet Engineering Task Force SIMPLE WG
Internet Draft J. Rosenberg
dynamicsoft
D. Willis
dynamicsoft
H. Schulzrinne
Columbia U.
C. Huitema
Microsoft
B. Aboba
Microsoft
D. Gurle
Microsoft
D. Oran
Cisco
draft-ietf-simple-presence-07.txt
May 20,
draft-ietf-simple-presence-08.txt
December 3, 2002
Expires: November 2002 June 2003
A Presence Event Package for the Session Initiation Protocol (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 the Session Initiation Protocol
(SIP) for subscriptions and notifications of user presence. User
J. Rosenberg et. al. [Page 1]
Internet Draft presence May 20, 2002
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 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) Profile (CPP) framework.
J. Rosenberg et. al. [Page 2] 1]
Internet Draft presence May 20, SIP Presence December 3, 2002
Table of Contents
1 Introduction ........................................ 4 3
2 Terminology ......................................... 4 3
3 Definitions ......................................... 4 3
4 Overview of Operation ............................... 5
5 Usage of Presence URLs URIs .............................. 7 6
6 Presence Event Package .............................. 8 7
6.1 Package Name ........................................ 8 7
6.2 Event Package Parameters ............................ 8 7
6.3 SUBSCRIBE bodies Bodies .................................... 9 8
6.4 Subscription Duration ............................... 9 8
6.5 NOTIFY Bodies ....................................... 9 8
6.6 Notifier Processing of SUBSCRIBE Requests ........... 10 9
6.6.1 Authentication ...................................... 10 9
6.6.2 Authorization ....................................... 11 10
6.7 Notifier Generation of NOTIFY Requests .............. 12 11
6.8 Subscriber Processing of NOTIFY Requests ............ 13 12
6.9 Handling of Forked Requests ......................... 14 12
6.10 Rate of Notifications ............................... 14 13
6.11 State Agents ........................................ 13
6.11.1 Aggregation, Authentication, and Authorization ...... 13
6.11.2 Migration ........................................... 14
7 Publication ......................................... 16 Learning Presence State ............................. 15
7.1 Co-location ......................................... 16 15
7.2 REGISTER ............................................ 16 15
7.3 Uploading Presence Documents ........................ 17 16
8 Example message flow Message Flow ................................ 17 16
9 Security considerations Considerations ............................. 20 19
9.1 Privacy ............................................. 20 Confidentiality ..................................... 19
9.2 Message integrity Integrity and authenticity Authenticity .................. 21 20
9.3 Outbound authentication Authentication ............................. 21 20
9.4 Replay prevention Prevention ................................... 22 21
9.5 Denial of service attacks ........................... 22
9.5.1 Distributed DOS attacks through false contacts ...... Service Attacks Against Third Parties ..... 21
9.6 Denial Of Service Attacks Against Servers ........... 22
10 IANA Consideration .................................. 23 Considerations ................................. 22
11 Contributors ........................................ 23 22
12 Acknowledgements .................................... 23 24
13 Authors Addresses ................................... 24
14 Normative References ................................ 25
15 Informative References .............................. 26 25
J. Rosenberg et. al. [Page 3] 2]
Internet Draft presence May 20, SIP Presence December 3, 2002
1 Introduction
Presence is (indirectly) defined in RFC 2778 [8]
Presence, also known as subscription to
and notification of changes in presence information, conveys the communications state ability and
willingness of a user.
This communications state consists of the user to communicate across a set of communications
means, communications address, devices. RFC
2778 [10] defines a model and status of terminology for describing systems that user.
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 such a presence service over the Internet or any IP
network.
This document proposes the usage of the Session Initiation Protocol
(SIP) [1] for presence. 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]. User presence SIP is particularly well
suited for
SIP. as a presence protocol. SIP registrars and location services already hold aspects contain
presence information, in the form of registrations. Furthermore, SIP
networks are capable of routing requests from any 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 on the network
to the proxy server that holds the registration state for a user. As this
state is a key component of user presence, those SIP networks can also
allow SUBSCRIBE requests to be routed to the same proxy. 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 user 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 and
Instant Messaging (CPIM) Profile
(CPP) framework that has been defined in [3]. This allows SIP for
presence to easily interwork with other presence systems compliant to CPIM.
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 [8]. [10].
Additionally, the following terms are defined and/or additionally
clarified:
J. Rosenberg et. al. [Page 4] 3]
Internet Draft presence May 20, SIP Presence December 3, 2002
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. 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, or
proxy/registrar. Another way is to co-locate it with the
presence user agent of the presentity. However, this is these are
not the only way, 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 events 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
J. Rosenberg et. al. [Page 5] 4]
Internet Draft presence May 20, SIP Presence December 3, 2002
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 events 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, Request-URI, using a
SIP URI, SIPS URI [1] or a presence URL URI [3]. The subscription 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
terminate
generate a response to the subscription 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
effectively 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 actual 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
J. Rosenberg [Page 5]
Internet Draft SIP Presence December 3, 2002
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
J. Rosenberg et. al. [Page 6]
Internet Draft presence May 20, 2002 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/or and SUBSCRIBE
refreshes. This is accomplished by inserting a URI into the
Record-Route Record-
Route header field in the initial SUBSCRIBE request and/or response. 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 termination, its expiration, if they wish to continue. 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 dialog identifier,
different sequence numbers, To header field, a higher CSeq header field value, and
possibly a set of Route headers 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 handing handling a SUBSCRIBE request with Expires
of zero is no different than for any other expiration value; all 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 status, rather than
subscribing to it. 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 URLs URIs
A presentity is identified in the most general way through a presence
URL
URI [3], which is of the form pres:user@domain. These URLs URIs are
J. Rosenberg [Page 6]
Internet Draft SIP Presence December 3, 2002
protocol independent. They are resolved to protocol specific URIs,
such as a SIP or SIPS URI, through DNS procedures defined in [3].
When subscribing to domain-specific mapping policies.
If a subscriber is only aware of the protocol-independent pres URI
for a presentity, it follows the subscription can be addressed
using procedures defined in [5]. These
procedures will result in the protocol independent form or placement of the SIP or SIPS pres URI form. In in the SIP context, "addressed" refers to
Request-URI of the Request-URI. It is
J. Rosenberg et. al. [Page 7]
Internet Draft presence May 20, 2002
RECOMMENDED that if SIP request, followed by the entity sending a SUBSCRIBE is capable usage 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
MAY be used DNS
procedures defined in [5] to determine the Request-URI. In that case, host to send the SIP
request would
typically be sent to to. Of course, a configured local outbound proxy that would perform
the resolution. Performing the translation as early as possible means
that these requests can may alternatively be routed by SIP proxies that are not
used, as specified in RFC 3261 [1]. If the subscriber is aware of
both the presence URL. protocol-independent pres URI and the SIP URI for the same
presentity, it SHOULD use the SIP URI.
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 or SIPS URIs whenever possible, but
MAY contain a pres URL URI if a SIP or SIPS URI is not known or
available.
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 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 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
J. Rosenberg [Page 7]
Internet Draft SIP Presence December 3, 2002
The SIP Event Framework event framework allows event packages to define additional
parameters carried in the Event header for the specific package. field. This package, presence,
does not define any additional parameters.
J. Rosenberg et. al. [Page 8]
Internet Draft presence May 20, 2002
6.3 SUBSCRIBE bodies 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, 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 generate notifies, 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 users user's instant message inbox
[10] changes. It might also say that the content of these
notifications should only contain the Instant Message (IM) related
information. status of the instant inbox.
Honoring of these filters is at the policy discretion of the PA.
When no body is present,
If the SUBSCRIBE request does not contain a body, this specifies to tells the PA
that no filter is
being requested, so that the PA is being requested to be applied. The PA SHOULD send all NOTIFY requests that
at the discretion of its own policy allows. 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 include specify an alternate expiration time. 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
J. Rosenberg [Page 8]
Internet Draft SIP Presence December 3, 2002
format listed in the Accept header field of the SUBSCRIBE, or a package-
specific
package-specific default if the Accept header is omitted. field was omitted from
the SUBSCRIBE.
In this event package, the body of the notification contains a
J. Rosenberg et. al. [Page 9]
Internet Draft presence May 20, 2002
presence document. This document describes the user presence of the
presentity that was subscribed to. All subscribers MUST support the
"application/cpim-pidf+xml" presence data format described in [5]. [6].
The subscribe request MAY contain an Accept header. header field. If no such
header field is present, it has a default value of
"application/cpim-pidf+xml". If the header field is present, it MUST
include "application/cpim-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.
If a PA gets a General processing rules for requests are
covered in Section 8.2 of RFC 3261 [1], in addition to general
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 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].
In single-domain systems, where the subscribers all have shared
secrets with the PA in the domain, PA, the combination of digest authentication over
Transport Layer Security (TLS) [6] [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. Specifically, when
user A generates a SUBSCRIBE for B@bar.com, his domain (say, foo.com)
will use SIP proxy digest authentication, run over a TLS connection,
to identify him (see Section 26.3.2.1 of [1] for an example). The
SUBSCRIBE is forwarded to the target domain over a secure connection,
such as TLS (see Section 26.3.2.2 of [1] for an example of TLS-based
J. Rosenberg et. al. [Page 10]
Internet Draft presence May 20, 2002
inter-domain security). 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. Any future Standard SIP extensions
mechanisms for network asserted identities could identity can be used in this scenario to allow foo.com applied to inform bar.com establish
the identity of the authenticated identity. subscriber [11] [12] [13].
A presentity MAY choose to represent itself with a SIPS URI. By
"represent itself", it means that the user represented by the
J. Rosenberg [Page 9]
Internet Draft SIP Presence December 3, 2002
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.
Another mechanism for authentication is S/MIME. Its usage with SIP is
described fully in RFC 3261 [1]. It provides an end-to-end
authentication mechanism that can be used for a PA to establish the
identity of the subscriber.
6.6.2 Authorization
Once authenticated, the PA makes an authorization decision. 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 [9], RADIUS [10], or COPS
[11], [14] server, 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. has been provided. The
"watcherinfo" event sub-package template package for SIP [12] [8] defines a means by
which a presentity can become aware that a user has attempted to
subscribe to it, so that it can then provide an authorization
decision.
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 known whether
it is successful or rejected is pending. Generally, a pending
subscription occurs
J. Rosenberg et. al. [Page 11]
Internet Draft presence May 20, 2002 when the server cannot obtain authorization at
the time of the subscription, and but may be able to do so at a later
time, perhaps when the presentity becomes available.
The appropriate response codes for conveying a successful, rejected,
or pending subscription (200, 403 or 603, and 202, respectively) are
described in RFC 3265 [2].
The SIP events framework allows the initial NOTIFY to contain no body
if
If the resource is not in a meaningful state. state, RFC 3265 [2] allows the
J. Rosenberg [Page 10]
Internet Draft SIP Presence December 3, 2002
body of the initial NOTIFY to be empty. In the case of presence, that
NOTIFY MAY contain a presence document. 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.
Polite blocking, as described in [13], [15], is possible by generating a
200 OK to the subscription even though it has been rejected (or
marked pending). Of course, an immediate NOTIFY will still be sent.
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. Typically, this is done by indicating
"offline" or equivalent status for a single contact address.
6.7 Notifier Generation of NOTIFY Requests
The SIP Events specification
RFC 3265 details the formatting and structure of NOTIFY messages.
However, it leaves to packages the are mandated to provide detailed information about what events cause a NOTIFY on
when to be sent, send a NOTIFY, how to compute the state information in of the NOTIFY, resource, how
to generate neutral or fake state information to hide authorization delays and decisions
from users, information, and whether state
information is complete or deltas partial. This section describes those
details for
notifications. the presence event package.
A PA MAY send a NOTIFY at any time. Typically, it will send ones for
successful subscriptions one when
the state of the presentity changes. The NOTIFY request MAY contain a
body indicating the state of the presentity. 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 presence tuples changes. These notifications would contain the
complete and current presence state of the presentity as known to the
presence agent. Future extensions can be defined that allow a
subscriber to request
J. Rosenberg et. al. [Page 12]
Internet Draft presence May 20, 2002 that the notifications contain changes in
presence information only, rather than complete state.
In the case of a pending subscription, when final authorization is
determined, a NOTIFY can be sent. If the result of the authorization
decision was success, a NOTIFY SHOULD be sent and SHOULD contain a
presence document with the current state of the presentity. If the
subscription is rejected, a NOTIFY MAY be sent. As described in RFC
3265 [2], the Subscription-State header can indicate field indicates the state of
the subscription.
J. Rosenberg [Page 11]
Internet Draft SIP Presence December 3, 2002
The body of the NOTIFY MUST be sent using one of the types listed in
the Accept header field in the most recent SUBSCRIBE request, or
using the type "application/cpim-pidf+xml" if no Accept header field
was present.
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 a
component of the presentity state. However, 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 publish
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
S/MIME. The encryption can be performed using the key of the
subscriber as identified in the From field of the SUBSCRIBE. SUBSCRIBE request.
Similarly, integrity of the notifications is important to
subscribers. As such, the contents of the notifications MAY provide
authentication and message integrity using S/MIME. Since the NOTIFY
is 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 is signed by a third party. It is
RECOMMENDED that the signature be by an authority over the 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.
6.8 Subscriber Processing of NOTIFY Requests
The SIP Events framework
RFC 3265 [2] leaves it to event packages to describe the process
followed by the subscriber upon receipt of a NOTIFY request,
including any logic required to form a coherent resource state.
In this specification, each NOTIFY contains either no presence
document, or a document representing the complete and coherent state
of the presentity. The Within a dialog, the presence document in the
NOTIFY request with
J. Rosenberg et. al. [Page 13]
Internet Draft presence May 20, 2002 the highest CSeq header field value is the
current one. When no document is present in that NOTIFY, the presence
document present in the NOTIFY with the next highest CSeq value is
used. Extensions which specify the use of partial state for
presentities will need to dictate how coherent state is achieved.
6.9 Handling of Forked Requests
The SIP Events framework
RFC 3265 [2] requires each package to describe handling of forked
SUBSCRIBE requests.
J. Rosenberg [Page 12]
Internet Draft SIP Presence December 3, 2002
This specification only allows a single dialog to be constructed as a
result of emitting an initial SUBSCRIBE request. This guarantees that
only a single PA is generating notifications for a particular
subscription to a particular presentity. 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
generates 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
representing the presentity that has access to the total set presentity.
Section 4.4.9 of user
presence to be aggregated.
The required RFC 3265 [2] describes the processing that is
required to guarantee that only the creation of a single dialog is
established is described in Section 5.4.9 of the SIP Events framework
[2]. response to
a SUBSCRIBE request.
6.10 Rate of Notifications
For reasons of congestion control, it is important that
RFC 3265 [2] requires each package to specify the maximum rate of at
which notifications not become excessive. As a result, it is RECOMMENDED
that the can be sent.
A PA not SHOULD NOT generate notifications for a single presentity at a
rate faster of more than once every 5 five seconds. However, a faster rate MAY
be used if the client explicitly indicates it through an extension of
some sort.
6.11 State Agents
It is important
RFC 3265 [2] requires each package to realize that consider the role of state
agents in the package, and if they are used, to specify how
authentication and authorization are done.
State agents are core to this package. Whenever the PA function can be colocated with
several elements:
o It can be co-located is not co-
located with the SIP registrar handling
registrations PUA for the presentity (the co-location of presentity, the PA
within the proxy/registrar is known acting as a state
agent. It collects presence server). In
this way, the presence server knows the presence of state from the user
through registrations or other means.
J. Rosenberg et. al. [Page 14]
Internet Draft PUA, and aggregates it
into a presence May 20, 2002
o It document. Because there can be co-located with multiple PUA, a PUA for
centralized state agent is needed to perform this aggregation. That
is why state agents are fundamental to presence. Indeed, they have a
specific term that presentity (the co-
location of the PA within describes them - a presence server.
6.11.1 Aggregation, Authentication, and Authorization
The means by which aggregation is done in the PUA state agent is known as an edge presence
server). In purely a
matter of policy. The policy will typically combine the case desires of a single PUA per presentity,
the PUA
knows presentity along with the state desires of the presentity by sheer nature provider. This draft in
no way restricts the set of its co-
location.
o It can policies which may be co-located in any server along applied.
J. Rosenberg [Page 13]
Internet Draft SIP Presence December 3, 2002
However, there is clearly a need for the request path.
That server can learn state agent to have access
to the presence state of the presentity presentity. This state is manipulated by
generating its own SUBSCRIBE the PUA.
One way in order to determine it. In this
case, which the PA state agent can obtain this state is effectively a Back to Back User Agent (B2BUA)
subscribe to it. As a result, if there were 5 PUA manipulating
presence state for presence. a single presentity, the state agent would
generate 5 subscriptions, one to each PUA. For this mechanism to be
effective, all PUA need
to act as PA. Therefore, it is RECOMMENDED that all PUA SHOULD be capable of acting as a PA for the state
that they manipulate, and that they authorize subscriptions that can
be authenticated as coming from the domain of the presentity.
On occasion, it makes sense for the PA
The usage of state agents does not significantly alter the way in
which authentication is done by the PA. Any of the SIP authentication
mechanisms can be used by a state agent. However, digest
authentication will require the state agent to be aware of the shared
secret between the presentity and the subscriber. This will require
some means to securely transfer the shared secrets from the
presentity to the state agent.
The usage of state agents does, however, have a signficiant impact on
authorization. As stated in Section 6.6, a PA is required to
authorize all subscriptions. If no explicit authorization policy has
been defined, the PA will need to query the user for authorization.
In a presence edge server (where the PUA is co-located with the PUA),
this is trivially accomplished. However, when state agents are used
(i.e., a presence server), a means is needed to alert the user that
an authorization decision is required. This is the reason for the
watcherinfo event package [8]. All state agents SHOULD support this
event package.
6.11.2 Migration
On occasion, it makes sense for the PA function to migrate from one
of these places
server 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
migrate migrates subscriptions
to it in order to reduce state in the network. The mechanism for
accomplishing the migration is described in Section
4.3.5 3.3.5 of RFC 3265
[2]. However, packages need to define under what conditions such a
migration would take place.
A PA MAY choose to migrate subscriptions at any time, through
configuration, or through dynamic means. One The REGISTER request
provides one dynamic means for a presence server to discover that the
function can migrate to a PUA is
through the REGISTER message. PUA. Specifically, if a PUA wishes to
indicate support for the PA function, it SHOULD include a contact
address in its registration with a use the caller
preferences "methods"
parameter listing SUBSCRIBE [7]. This indicates specification [9] to indicate that it is capable of
terminating and processing SUBSCRIBE, supports the
SUBSCRIBE request method and therefore may be able to
act as the presence event package. The
combination of these two define a PA. However, just because Of course, a PUA indicates it presence server
J. Rosenberg [Page 14]
Internet Draft SIP Presence December 3, 2002
can accept
subscriptions, does not mean always attempt a PA should migrate the subscriptions
there. In particular, migration without these explicit hints. If it
fails with either a PA SHOULD NOT migrate 405 or 489 response code, the subscription if it
is composing aggregated presence documents from state received from
several PUA.
When server knows that
the PA sends notifications to migrate subscriptions, it should
be wary of PUA does not support the load that this may cause. A PA SHOULD rate limit the
notifications, in order to avoid a flood of simultaneous re-
SUBSCRIBEs from all subscribers. function. In this case, the case where the subscription has migrated to the presence
server, the presence server
itself will simply need to act as a PA for these new
subscriptions. In the case where the that subscription request. Once
such a failure has migrated from occurred, the presence server SHOULD NOT attempt further
migrations to that PUA for the PUA, duration of its registration. However,
to avoid the extra traffic generated by these failed requests, a
presence server MUST operate like
J. Rosenberg et. al. [Page 15]
Internet Draft presence May 20, 2002
a proxy. Furthermore, it SHOULD implement the SIP Caller preferences
extension [7]. Because of the existence of a registered Contact with
a "methods" parameter containing SUBSCRIBE, support 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. Because the "methods" parameter does not convey the set extension.
Furthermore, indication of event packages support for which the PUA can accept SUBSCRIBE, it is
possible that the PUA doesn't understand the presence event package, SUBSCRIBE request and will therefore reject the subscription with a 489. In this case, the
presence server SHOULD act as a PA event package is not sufficient for this subscription and
generate its own response. Furthermore, it migration of
subscriptions. A PA SHOULD NOT migrate any
other subscriptions to this PUA.
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 if it is accepted), and this will be correctly forwarded towards the
subscriber based on proxy response processing rules [1]. The penalty
of not supporting caller preferences is the additional unneeded SIP
traffic.
7 Publication
The user
composing aggregated presence for a presentity can be obtained documents received from any number of
different multiple PUA.
7 Learning Presence State
Presence information can be obtained by the PA in many ways. None of these mechanisms are No
specific mechanism is mandated by this specification. The discussion here is This section
overviews some of the options, for informational purposes only.
7.1 Co-location
When the PA function is co-located with the PUA, user presence is known
directly by the PA.
7.2 REGISTER
Baseline SIP defines a method that is used by all SIP clients -
A UA uses the SIP REGISTER method. This method allows a UA to inform a the SIP network of its
current communications addresses (ie., (i.e., Contact addresses) .
Furthermore, multiple addresses). 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.
address-of-record. This registration state represents an important
piece of the overall presence information for a presentity. It is an
indication of basic reachability for communications.
Usage of REGISTER information to construct presence is only possible
if the PA has access to the registration database, and can be
informed of changes to that database. One way to accomplish that is co-located with, or shares information with,
to co-locate the SIP
J. Rosenberg et. al. [Page 16]
Internet Draft presence May 20, 2002
registrar. In this case, PA with the combined PA/registrar/proxy registrar.
The means by which registration state is known as
a presence server.
Using the register information for converted into presence
state is straightforward. The
address a matter of local policy, and beyond the scope of record this
specification. However, some general guidelines can be provided. The
address-of-record in the REGISTER registration (the To header field)
identifies the presentity. The Each registered Contact headers define header field
identifies a point of communications addresses for that presentity, which can
be modeled using a tuple. Note that
describe the state contact address in the tuple
need not be the same as the registered contact address. Using an
address-of-record instead allows subsequent communications from a
J. Rosenberg [Page 15]
Internet Draft SIP Presence December 3, 2002
watcher to pass through proxies. This is useful for policy processing
on behalf of the presentity. The presentity and the provider.
A PUA that uses registrations to manipulate presence state SHOULD
make use of the SIP caller preferences extension [7] is RECOMMENDED for use [9]. This allows the
PUA to provide the PA with UAs that are
interested in presence. It provides additional richer information about itself. For
example, the
Contact addresses that can be used to construct a richer presence
document.
The presence of a registered Contact with a "methods" the methods parameter [7] listing the MESSAGE method implies that the presentity supports
"MESSAGE" indicates support for instant messaging as a communications means. messaging.
The q values from the Contact header field [1] can be used to
establish relative priorities amongst the various communications
addresses in the Contact headers. header fields.
The application usage of registered contacts registrations to obtain presence information increases
the requirements for authenticity. authenticity and integrity of registrations.
Therefore, REGISTER requests used by presence user agents MUST be authenticated using either SIP
authentication mechanisms, or a hop-by-hop mechanism.
authenticated.
7.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 tuples 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.
8 Example message flow Message Flow
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.
J. Rosenberg et. al. [Page 17]
Internet Draft presence May 20, 2002
In this flow, the PUA informs the server about the updated presence
information though through some non-SIP means.
When the value of the Content-Length header field is "..." this means
that the value should be whatever the computed length of the body is.
J. Rosenberg [Page 16]
Internet Draft SIP Presence December 3, 2002
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->example.com server
SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com;branch=z9hG4bKnashds7
To: <sip:resource@example.com>
From: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 17766 SUBSCRIBE
Max-Forwards: 70
Event: presence
Accept: application/cpim-pidf+xml
Contact: <sip:user@watcherhost.example.com>
Expires: 600
Content-Length: 0
J. Rosenberg et. al. [Page 18]
Internet Draft presence May 20, 2002
F2 200 OK example.com server->watcher
SIP/2.0 200 OK
Via: SIP/2.0/UDP watcherhost.example.com;branch=z9hG4bKnashds7
;received=192.0.2.1
J. Rosenberg [Page 17]
Internet Draft SIP Presence December 3, 2002
To: <sip:resource@example.com>;tag=ffd2
From: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 17766 SUBSCRIBE
Event: presence
Expires: 600
Contact: sip:server.example.com
Content-Length: 0
F3 NOTIFY example.com server-> watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com;branch=z9hG4bKna998sk
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
Event: presence
Subscription-State: active;expires=599
Max-Forwards: 70
CSeq: 8775 NOTIFY
Contact: sip:server.example.com
Content-Type: application/cpim-pidf+xml
Content-Length: ..
[PIDF Document]
F4 200 OK watcher-> example.com server
SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com;branch=z9hG4bKna998sk
;received=192.0.2.2
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 8775 NOTIFY
Content-Length: 0
J. Rosenberg et. al. [Page 19] 18]
Internet Draft presence May 20, SIP Presence December 3, 2002
Content-Length: 0
F5 NOTIFY example.com server -> watcher
NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com;branch=z9hG4bKna998sl
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 8776 NOTIFY
Event: presence
Subscription-State: active;expires=543
Max-Forwards: 70
Contact: sip:server.example.com
Content-Type: application/cpim-pidf+xml
Content-Length: ...
[New PIDF Document]
F6 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com;branch=z9hG4bKna998sl
;received=192.0.2.2
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 8776 NOTIFY
Content-Length: 0
9 Security considerations Considerations
There are numerous security considerations for presence. Many are
outlined above; this section considers them issue by issue.
9.1 Privacy
J. Rosenberg et. al. [Page 20]
Internet Draft presence May 20, 2002
Privacy Confidentiality
Confidentiality encompasses many aspects of a presence system:
o Subscribers may not want to reveal the fact that they have
J. Rosenberg [Page 19]
Internet Draft SIP Presence December 3, 2002
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
Confidentiality is provided through a combination of hop-by-hop
encryption and end-to-end encryption. The hop-by-hop mechanisms
provide scalable
privacy confidentiality 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, but TLS is mandatory to
implement for servers. Therefore, it is RECOMMENDED that TLS [6] [7] be
used between elements to provide this function. The details for
usage of TLS for server-to-server, server-to-server and client-to-server security are
detailed in Section 26.3.2 of SIP RFC 3261 [1].
SIP encryption, using S/MIME, MAY be used end-to-end for the
transmission of both SUBSCRIBE and NOTIFY requests.
9.2 Message integrity Integrity and authenticity Authenticity
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 NOTIFY requests are particularly important. Without
authentication and integrity, presence documents could be forged or
modified, fooling the watcher into believing incorrect presence
information.
To deal with this problem, SIPs authentication and message integrity. integrity
features can be used. SIP provides http digest for authentication,
and S/MIME for authentication and integrity.
9.3 Outbound authentication Authentication
When local proxies are used for transmission of outbound messages,
J. Rosenberg [Page 20]
Internet Draft SIP Presence December 3, 2002
proxy authentication is RECOMMENDED. This is useful to verify the
identity of the originator, and prevent spoofing and spamming at the
J. Rosenberg et. al. [Page 21]
Internet Draft presence May 20, 2002
originating network.
9.4 Replay prevention
To prevent Prevention
Replay attacks can be used by an attacker to fool a watcher into
believing an outdated presence state for a presentity. For example, a
document describing a presentity as being "offline" can be replayed,
fooling watchers into thinking that the user is never online. This
may effectively block communications with the presentity.
SIP S/MIME can provide message integrity and authentication over SIP
request bodies. This capability can be used to prevent these replay of old subscriptions and notifications, all
signed SUBSCRIBE and NOTIFY requests and responses MUST contain a
Date header covered by
attacks. When it is used for that purpose, the message signature. Any message with a date
older than several minutes presence document
carried in the past, or more than several minutes
into the future, SHOULD be discarded.
Furthermore, all signed SUBSCRIBE and NOTIFY requests request MUST contain a
Call-ID and CSeq header covered by timestamp. In the message signature. A user
agent or presence server MAY store a list case
of Call-ID values, and for
each, PIDF, this is accomplished using the highest CSeq seen within that Call-ID. Any message that
arrives for a Call-ID that exists, timestamp element, as
described in Section 6 of [6]. Tuples whose CSeq timestamp is lower older than
the
highest seen so far, is timestamp of the most recently received presence document SHOULD
be considered stale, and discarded.
Finally, HTTP digest authentication MAY be used to prevent replay
attacks.
attacks, when there is a shared secret between the PA and the
watcher. In such a case, the watcher can challenge the NOTIFY
requests with the auth-int quality of protection.
9.5 Denial of service attacks Service Attacks Against Third Parties
Denial of Service (DOS) 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.
9.5.1 Distributed DOS attacks through false contacts Unfortunately, presence is a good
candidate for Distributed DOS DoS (DDOS) 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 against a target is to send subscriptions to a large
number of users, and in the Contact header field (which is where
notifications are sent), place the address of the target.
The only reliable way
RFC 3265 provides some mechanisms to mitigate these attacks [2]. 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.
Authentication and authorization at the PA can also prevent these
attacks. Typically, authorization policy will not allow subscriptions
from unknown watchers. If the attacks are launched from watchers
unknown to the presentity (a common case), the attacks are mitigated.
J. Rosenberg [Page 21]
Internet Draft SIP Presence December 3, 2002
9.6 Denial Of Service Attacks Against Servers
Denial of service attacks can also be launched against a presence
agent itself, in order to disrupt service to a community of users.
SIP itself, along with RFC 3265 [2], describes several mechanisms to prevent
mitigate these attacks.
A server can prevent SYN-attack style attacks is through a four-way
handshake using digest 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 [1]. Even if the Contact
header in a SUBSCRIBE is from a domain which server does
not match that have a shared secret with the client, it can verify the source IP
address of the From field (which identifies request using the subscriber).
Also, note that as "anonymous" user mechanism described
in [2], if Section 22.1 of RFC 3261 [1]. SIP also allows a NOTIFY is not acknowledged
or was not wanted, the subscription that generated server to instruct
a client to back-off from sending it is removed.
This eliminates requests, using the amplification properties 503 response
code (Section 21.5.4 of providing false
Contact addresses.
J. Rosenberg et. al. [Page 22]
Internet Draft presence May 20, 2002 RFC 3261 [1]). This can be used to fend off
floods of SUBSCRIBE requests launched as a result of a distributed
denial of service attack.
10 IANA Consideration Considerations
This specification registers an event package, based on the
registration procedures defined in RFC 3265 [2]. The following is the
information required for such a registration:
Package Name: presence
Package or Template-Package: This is a package.
Published Document: RFC XXXX (Note to RFC Editor: Please fill in
XXXX with the RFC number of this specification).
Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.
11 Contributors
The following individuals were part of the initial team that worked
through the technical design of this specification:
Jonathan Lennox
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
email: lennox@cs.columbia.edu
Robert Sparks
dynamicsoft
J. Rosenberg [Page 22]
Internet Draft SIP Presence December 3, 2002
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
12 Acknowledgements
We would like to thank Rick Workman, Adam Roach, Sean Olson, Billy
Biggs, Stuart Barkley, Mauricio Arango, Richard Shockey, Jorgen
J. Rosenberg et. al. [Page 23]
Internet Draft presence May 20, 2002
Bjorkner, Henry Sinnreich, Ronald Akers, Paul Kyzivat, and Hisham
Khitarbil for their comments and support of this specification.
13 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
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
email: schulzrinne@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
J. Rosenberg et. al. [Page 24]
Internet Draft presence May 20, 2002
170 West Tasman Dr.
San Jose, CA 95134 [Page 23]
Internet Draft SIP Presence December 3, 2002
12 Acknowledgements
We would like to thank Rick Workman, Adam Roach, Sean Olson, Billy
Biggs, Stuart Barkley, Mauricio Arango, Richard Shockey, Jorgen
Bjorkner, Henry Sinnreich, Ronald Akers, Paul Kyzivat, Ya-Ching Tan
and Hisham Khartabil for their comments and support of this
specification.
13 Authors Addresses
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: oran@cisco.com jdrosen@dynamicsoft.com
Full Copyright Statement
Copyright (c) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
J. Rosenberg [Page 24]
Internet Draft SIP Presence December 3, 2002
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14 Normative References
[1] J. Rosenberg, H. Schulzrinne, et al. , G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session session
initiation protocol," Internet Draft, RFC 3261, Internet Engineering Task Force, Feb. June
2002. Work in progress.
[2] A. B. Roach, "SIP-specific "Session initiation protocol (sip)-specific event
notification," Internet Draft, RFC 3265, Internet Engineering Task Force, Mar. June 2002. Work in progress.
[3] D. Crocker et al. , "Common presence and instant messaging
(CPIM)," profile: Presence," Internet Draft,
Internet Engineering Task Force, Nov. 2001. Oct. 2002. Work in progress.
J. Rosenberg et. al. [Page 25]
Internet Draft presence May 20, 2002
[4] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[5] D. Crocker et al. , "Address resolution for instant messaging
and presence," Internet Draft, Internet Engineering Task Force, Oct.
2002. Work in progress.
[6] H. Sugano, S. Fujimoto, et al. , "CPIM "Common presence and instant
messaging (CPIM)presence information data format," Internet Draft,
Internet Engineering Task Force, May 2002. Work in progress.
[6]
[7] T. Dierks and C. Allen, "The TLS protocol version 1.0," RFC 2246,
Internet Engineering Task Force, Jan. 1999.
[7]
[8] J. Rosenberg, "A session initiation protocol (SIP)event
template-package for watcher information," Internet Draft, Internet
Engineering Task Force, May 2002. Work in progress.
[9] H. Schulzrinne and J. Rosenberg, "SIP "Session initiation protocol
(SIP) caller preferences and callee capabilities," Internet Draft,
Internet Engineering Task Force, Nov. 2001. July 2002. Work in progress.
15 Informative References
[8]
[10] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and
instant messaging," RFC 2778, Internet Engineering Task Force, Feb.
2000.
[9] J. Arkko, P. Calhoun, et al. , "Diameter base protocol,"
[11] M. Watson, "Short term requirements for network asserted
identity," Internet Draft, Internet Engineering Task Force, Apr. June
2002. Work in progress.
[10]
J. Rosenberg [Page 25]
Internet Draft SIP Presence December 3, 2002
[12] C. Rigney, S. Willens, A. Rubens, Jennings, J. Peterson, and W. Simpson, "Remote
authentication dial in user service (RADIUS)," RFC 2865, M. Watson, "Private extensions to
the session initiation protocol (SIP) for asserted identity within
trusted networks," Internet Draft, Internet Engineering Task Force, June 2000.
[11]
Aug. 2002. Work in progress.
[13] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, and A.
Sastry, "The COPS (common open policy service) protocol," RFC 2748, Peterson, "Enhancements for authenticated identity management
in the session initiation protocol (sip)," Internet Draft, Internet
Engineering Task Force, Jan. 2000.
[12] J. Rosenberg, "A SIP event sub-package for watcher information," Oct. 2002. Work in progress.
[14] P. Calhoun et al. , "Diameter base protocol," Internet Draft,
Internet Engineering Task Force, Mar. July 2002. Work in progress.
[13]
[15] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant messaging
/ presence protocol requirements," RFC 2779, Internet Engineering
Task Force, Feb. 2000.
J. Rosenberg et. al. [Page 26]
----