WDIFF

draft-ietf-simple-presence-01.txt --> draft-ietf-simple-presence-02.txt

Internet Engineering Task Force SIMPLE WG
Internet Draft Rosenberg et al.
draft-ietf-simple-presence-01.txt
draft-ietf-simple-presence-02.txt Various Places
July 20,
August 31, 2001
Expires: February 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 proposes an extension to 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 July 20, August 31, 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 an extension to the Session Initiation
Protocol (SIP) [2] for presence. This extension is 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. 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 extension 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 extension 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. In SIP terms, this
means that a PUA generates REGISTER requests, conveying
some kind of information about the presentity. Other means,
both SIP and non-SIP, can be used for a PUA to manipulate
presence information. 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
the presence system, but are outside of it, in that they do

Rosenberg et al. [Page 2]

Internet Draft presence July 20, August 31, 2001

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 complete knowledge of the
presence state of a presentity. Typically, this is
accomplished by co-locating the PA with the
proxy/registrar, or the presence user agent of the
presentity. A PA is always addressable with a SIP URL.

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
extension.

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
either a presence URL or a SIP URL. The subscription is carried along SIP proxies as
any other INVITE 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 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. Once authorized, the
presence agent sends a 202 Accepted response. It also sends an

Rosenberg et al. [Page 3]

Internet Draft presence July 20, August 31, 2001

immediate NOTIFY message containing the state of the presentity. As
the state of the presentity changes, the PA generates NOTIFYs for all
subscribers.

The SUBSCRIBE message effectively establishes a session with the
presence agent. agent (a presence session). 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 Naming Usage of Presence URLs

A presentity is identified in the most general way through a presence
URI
URL [4], which is of the form pres:user@domain. These URIs URLs are
protocol independent. Through a variety of means, these URIs can be They are resolved to determine a specific protocol that can be used to access
the presentity.

OPEN ISSUE: Need to add IMPP DNS procedures once stable.

Once specific URLs,
such a resolution has taken place, the presentity can be
addressed with a sip URL of nearly identical form: sip:user@domain.
The protocol independent form (the pres: URL) can be thought of as an
abstract name, akin to a URN, which is used to identify elements SIP URL, through DNS procedures defined in a
presence system. These are resolved to concrete URLs that can be used
to directly locate those entities on the network. [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.

The result of this naming scheme is that a SUBSCRIBE request is
addressed to a user the exact same way an INVITE request would be
addressed. This means that the SIP network will route these messages
along the same path an INVITE would travel. One of these entities
along the path may act as a PA for the subscription. Typically, this
will either be the presence server (which is the proxy/registrar
where that user is registered), or the presence client (which is one
of the user agents associated with that presentity).

Rosenberg et al. [Page 4]

Internet Draft presence July 20, 2001

SUBSCRIBE messages also contain logical identifiers that define the
originator and recipient of the subscription (the To and From header
fields). Since these identifiers are logical ones, it is RECOMMENDED
that these use the protocol independent format These SHOULD contain SIP URLs whenever possible.
This also makes it easier to interwork with other systems which
recognize these forms. possible, but MAY
contain a pres URL if a SIP URL 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. 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 extension qualifies as
an event package. This section fills in the information required by
[3].
[5].

5.1 Package Name

Rosenberg et al. [Page 4]

Internet Draft presence August 31, 2001

The name of this package is "presence". This name MUST appear within
the Event header in SUBSCRIBE request and NOTIFY request. This
section also serves as the IANA registration for the event package
"presence".

TODO: Define IANA template in sub-notify and fill it in
here.

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. In general, subscriptions will normally
not contain bodies. The request URI, which identifies the presentity,
combined with the event package name, are sufficient for user
presence.

We anticipate that document formats could be defined to act as

Rosenberg et al. [Page 5]

Internet Draft presence July 20, 2001
filters for subscriptions. These filters would indicate certain user
presence events that would generate notifies, or restrict 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.

When no body is present, this specifies to the presence agent that
the default filter is to be used. The default filter meets the
following definition:

o All known presence tuples for the presentity are reported in
each NOTIFY.

o Each presence tuple contains the latest status and
communications address.

o Additional markup for each presence tuple that is small (less
than 50 bytes) is included. Larger markup is only sent when
explicitly requested by the subscriber through non-default
filters.

5.3 Expiration

Rosenberg et al. [Page 5]

Internet Draft presence August 31, 2001

5.4 Subscription Duration

User presence changes as a result of events that include:

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 minutes or hours. As such, it is
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.4

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 [fill in with IMPP document TBD], [6], and MUST list its MIME type, [fill in with MIME type] "application/cpim-
pidf+xml" in an Accept header present in the SUBSCRIBE request.

Rosenberg et al. [Page 6]

Internet Draft presence July 20, 2001

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 [fill in with
MIME type of IMPP presence document]
"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.5 Processing Requirements at

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 PA

User SIP URL of
the presentity whose presence is highly sensitive information. Because the
implications of divulging desired, but MAY contain a presence information can
URL if no SIP URL is known. The To field SHOULD contain the same
value as the Request-URI. The From field MUST be severe, strong
requirements are imposed on present, and SHOULD
contain a logical identifier for the PA regarding subscription processing,
especially related subscriber (i.e.,
sip:joe@yahoo.com as opposed to authentication and authorization.

A presence agent sip:joe@1.2.3.4). The request MUST authenticate all subscription requests.
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
authentication can request is then sent. This MAY be done using any of the mechanisms DNS procedures
defined for
SIP, except that in [2] if the Request-URI contains a SIP basic authentication mechanism MUST NOT URL, else the

Rosenberg et al. [Page 6]

Internet Draft presence August 31, 2001

request MAY be
used. It is anticipated that 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.

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.

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.

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.

OPEN ISSUE: This approach is really about network
authenticated identities. Sounds like the
The SIP extension for caller identity and privacy
extensions might [7] can be useful here, especially if we want used to
support anonymous subscriptions. Should we explicitly
mention that?
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

Rosenberg et al. [Page 7]

Internet Draft presence August 31, 2001

specified in a web page. Authorization may have been provided by

Rosenberg et al. [Page 7]

Internet Draft presence July 20, 2001
means of uploading of some kind of standardized access control list
document. Back end authorization servers, such as a DIAMETER [5], [8],
RADIUS [6], [9], or COPS [7], [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 [8] [11] defines a
means by which a PUA can become aware that a user has attempted to
subscribe to it, and no authorization exists.

The result of the authorization decision by the server will

Authorization decisions can be very complex. At a minimum, these are
be reject, accept, pending, or pending. politely blocked. Pending occurs when
the server cannot obtain authorization at this time, and may be able
to do so at a later time, when the presentity becomes available.

Unfortunately, if the server informs the subscriber that the
subscription is pending, this will divulge information about the
presentity - namely, that they have not granted authorization and are
not available to give it at this time. Therefore, for any given
presentity, a presence agent can either act in confirming or non-
confirming mode. In confirming mode, a subscriber is notified about
the status of their subscription. In non-confirming mode, the
subscriber is not made aware of the status of their subscription. A
PA MAY use different modes for different subscriptions. However,
since a subscriber can distinguish confirming from non-confirming
modes, care must be taken in choosing the mode, since it reveals
information to the subscriber as well.

In confirming mode, an authorized An
accepted subscription generates a 200 OK, an
unauthorized rejected subscription
generates a 603 Declined response, and a pending subscription
generates a 202 Accepted response. In non-
confirming mode, Any other valid responses, as
specified in [2] MAY be used as well. A successful subscription also
generates a 202 Accepted response is always returned NOTIFY request which contains the current presence state.
See Section 5.8 for details.

Polite blocking, as described in all
cases.

5.6 Generation of Notifications

In confirming mode, if [12], is possibly by generating a
200 OK to the subscription was accepted, the PA SHOULD
generate even though it has been rejected (or
marked pending). Of course, an immediate NOTIFY with MUST be sent also.
The contents of the current presence state document in such a NOTIFY are at the
discretion of the
presentity. No NOTIFY is sent for pending or rejected subscriptions.

In non-confirming mode, implementor, but SHOULD be constructed in such a
way as to not reveal to the subscriber that their request has
actually been blocked.

5.8 Notifier Generation of NOTIFY MUST be sent. Requests

If a subscription is
received, and is marked as pending or was rejected, this NOTIFY
should contain accepted (or politely blocked), a valid state for the presentity, yet NOTIFY MUST be one which
provides no useful information about
sent after the presentity. An example of
this is 200 OK response to provide an IM URL that is the same form as the presence
URL, and mark that IM address as "not available". SUBSCRIBE has been sent.

Notifications MAY be sent at later times, possibly when the presence
state of the presentity changes.

The reason for this
process body of the NOTIFY MUST be sent using one of "lying" 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 that without it, sent for a subscriber could tell particular subscriber,
and the
difference between 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 pending subscription and an accepted
subscription based on baseline, a reasonable policy is to generate
notifications when the existence and content state of an immediate any of the communications addresses
changes. These notifications contain the complete and current

Rosenberg et al. [Page 8]

Internet Draft presence July 20, August 31, 2001

NOTIFY. The approach defined here ensures that the

presence delivered
in a NOTIFY generated by a pending or rejected subscription is also a
valid one that could have been delivered in a NOTIFY generated by an
accepted subscription.

For an accepted subscription in non-confirming mode, an immediate
NOTIFY is sent which contains the current state of the presentity.

For an accepted subscription, presentity as known to the PA SHOULD generate a NOTIFY for presence agent.

The means by which the
subscription when it determines that PA learns the presence state of the presentity has changed. Section 6 describes how are also
outside the PA makes scope of this
determination.

For pending recommendation. Registrations provide one
way, and rejected subscriptions, the means by which a PA MAY generate
occassional NOTIFYs that update the uses registrations to construct a
presence state document are an implementation choice. If a PUA wishes to another "fake"
value. The algorithm for "lying" is at
explicitly inform the discretion presence agent of the
implementor. However, the mechanism SHOULD, whenever possible, make its presence state, it hard to distinguish the fake information from should
explicitly upload the real.

OPEN ISSUE: Do we need presence document (or its piece of it) rather
than attempting to define what information gets
sent? Do we really want manipulate their registrations to achieve the non-confirming mode?
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
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.

5.7 Rate Limitations on NOTIFY

For reasons

5.9 Subscriber Processing of congestion control, it is important that NOTIFY Requests

The NOTIFY requests contain presence documents which describe the rate of
notifications
presentity. The subscriber SHOULD reject all NOTIFY requests whose
From field tag does not become excessive. As a result, it is RECOMMENDED
that match the PA not generate notifications for tag in the To field of the 200 OK
to the SUBSCRIBE. This means that only a single presentity at PA can be active for
a
rate faster than once every 5 seconds.

5.8 Refresh Behavior particular subscription.

The 481 response to a SUBSCRIBE refresh informs presence documents delivered in NOTIFY are ordered through the subscriber that

Rosenberg et al. [Page 9]

Internet Draft
CSeq in the NOTIFY requests. The presence July 20, 2001

their subscription failed because it was a subscription refresh
against an unknown subscription. In this case, document in the subscriber SHOULD
generate a brand new SUBSCRIBE on a new call leg, and discard NOTIFY
request with the old
subscription state. 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. Each of these will respond with a 202 response
to the SUBSCRIBE. Based on the forking rules in SIP, only one of

Rosenberg et al. [Page 9]

Internet Draft presence August 31, 2001

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 202 Accepted 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 202. 2xx. When notifications arrive, those from the PA's
whose 202's were discarded in the forking proxy will not match the
subscription ID stored at the subscriber (the From tags will differ).
These SHOULD be responded to with a 481. This will disable the
subscriptions from those PA. Furthermore, when refreshing the
subscription, the refresh SHOULD make use of the tags from the 202
and make use of any Contact or Record-Route headers in order to
deliver the SUBSCRIBE back to the same PA that sent the 202.

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. If such a feature 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 can
MUST be accomplished with done in a B2BUA rather than through PA present in a
forking proxy.

6 Publication

The network server representing the
presentity that has access to the total set of user presence for a presentity can to be obtained from any number
aggregated.

5.11 Rate of
different ways. None Notifications

For reasons of these mechanisms are mandated by this
specification. However, if used, congestion control, it should be done according to is important that the
recommendations described below.

6.1 Co-location

When rate of
notifications not become excessive. As a result, it is RECOMMENDED
that the PA function 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 PUA, user presence SIP registrar handling
registrations for the presentity (the co-location of the PA
within the proxy/registrar is known directly by as a presence server). In
this way, the PA. presence server knows the presence of the user
through registrations or other means.

Rosenberg et al. [Page 10]

Internet Draft presence July 20, August 31, 2001

6.2 REGISTER

Baseline SIP defines

o It can be co-located with a method PUA for that is used by all SIP clients - presentity (the co-
location of the
REGISTER method. This method allows PA within the PUA is known as a UA to inform presence
client). In the case of a SIP network single PUA per presentity, the PUA
knows the state 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 presentity by sheer nature of its co-
location.

o It can be co-located in any other valid URL.

Using server along 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 call setup path.
That proxy can learn the presence state of the presentity. The use of the SIP caller
preferences extension [9] is RECOMMENDED for use with UAs that are
interested presentity by
generating its own SUBSCRIBE in presence. It provides additional information about the
Contact addresses that can be used order to construct a richer presence
document. The "description" attribute of determine it. In this
case, the Contact header PA is
explicitly defined here to be used as a free-form field that allows effectively a
user to define the status of the presentity at that communications
address.

To indicate presence B2BUA.

On occassion, it makes sense for instant messaging, the UA MAY either
register contact addresses that are SIP URLs with the "methods"
Contact parameter (as defined by the caller preferences extension [9]
set PA function to indicate the method MESSAGE, or it MAY register an IM URL.

Usage migrate from one
of REGISTER information these places to construct presence is only possible
if another. For example, for reasons of scale, the PA is co-located with, or shares information with,
function may reside in the SIP
registrar.

The application of registered contacts to presence increases server when 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

Presence documents MAY be uploaded to PUA is not
running, but when the PA in REGISTER message,
using PUA connects to the procedures defined in [10]. In this case, network, the PA SHOULD
distribute the presence document as provided without modification. As
described in [10], only one presence document can be uploaded at a
time. Subsequent uploads replace the current active presence
document.

Note that we do not provide for locking mechanisms, which would allow
a client to lock presence state, fetch it, and update it atomically.
We believe that this is not neeeded for the majority of use cases,
and introduces substantial complexity. Most presence operations do

Rosenberg et al. [Page 11]

Internet Draft presence July 20, 2001

not require get-before-set, since the SIP register mechanism works in
such a way that data can be updated without a get.

OPEN ISSUE: Are we sure we are using REGISTER for this?

6.4 Call State Subscriptions

Another mechanism that a PA can use to determine the state of the
presentity is to SUBSCRIBE to the call state event package for that
presentity [11]. This will allow the PA to know when the user is in a
call, not in a call, etc., which can be used to provide richer
presence server content.

TODO: This section needs work. Need to define a concrete
example of mapping a register to a presence document, once
IMPP generates the document format.

6.5 Migrating the PA Function

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. In this way, the PA knows
the presence of the user through registrations.

o It can be co-located with a PUA for that presentity. 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 registrar when the PUA is not running, but
when the PUA connects to the network, the PA decides to migrate
subscriptions to it in order to reduce state in the network.

There are three phases to this migration:

o Determine that another element is capable of handling the
subscription.

Rosenberg et al. [Page 12]

Internet Draft presence July 20, 2001

o Destroy subscription state, and inform those subscribers that
it needs to be re-established with a new SUBSCRIBE.

o When the subscribers re-SUBSCRIBE, proxy the requests to the
new element handling the PA function.

The first of these phases can occur through configuration, or through
dynamic means. The presence server dynamically determines that a PUA
is capable of supporting a PA function 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.

For the second phase, the PA destroys the subscriptions and then
sends a NOTIFY to each subscriber, with an Expires header with value
0. This informs the subscribers that their subscription was
destroyed, and should be re-established with a new SUBSCRIBE (with a
new Call-ID).

This is an overload of the meaning of Expires. Another
approach is to use the watcherinfo event package, so that
the subscribers get notified that their subscriptions have
expired.

The subscribers then create brand new subscriptions, with a new
Call-ID, no route set and no To tag, and this is sent to refresh the
subscription. When this arrives at the "old" PA, the PA proxies the
SUBSCRIBE towards the element which will now be acting as PA.

7 Mapping to CPIM

This section defines how a SIP for presence messages are converted to
CPIM, and how a CPIM messages are converted to SIP for presence. SIP
to CPIM conversion occurs when a SIP system sends a SUBSCRIBE request
that contains a pres URL or SIP URL that corresponds to a user in a
domain that runs a different presence protocol. CPIM to SIP involves
the case where a user in a different protocol domain generates a
subscription that is destined for a user in a SIP domain.

Note that the process defined below requires that the gateway store
subscription state. This unfortunate result is due to the need to
remember the Call-ID, CSeq, and Route headers for subscriptions from
the SIP side, so that they can be inserted into the SIP NOTIFY
generated when a CPIM notification arrives.

7.1 SIP to CPIM

Rosenberg et al. [Page 13]

Internet Draft presence July 20, 2001

SIP for presnce is converted to CPIM through a SIP to CPIM abstract
gateway service, depicted in Figure 1.

+-------------+
| |
| SIP to CPIM|
| Conversion |
| |
SIP | | CPIM
---------------> | | ---------------->
| |
| |
| |
| |
| |
| |
+-------------+

Figure 1: SIP to CPIM Conversion

The first step is that a SUBSCRIBE request is received at a gateway.
The gateway generates a CPIM subscription request, with its
parameters filled in as follows:

o The watcher identity in the CPIM message is copied from the
From field of the SUBSCRIBE. If the From field contains a SIP
URL, it is converted to an equivalent pres URL by dropping all
SIP URL parameters, and changing the scheme to pres.

This conversion may not work - what if the SIP URL has
no user name. Plus, converting from a URL back to a
URN in this fashion may not do it correctly.

Rosenberg et al. [Page 14]

Internet Draft presence July 20, 2001

o The target identity in the CPIM message is copied from the
Request-URI field of the SUBSCRIBE. This may need to be
converted to a pres URL as well.

o The duration parameter in the CPIM message is copied from the
Expires header in the SUBSCRIBE. If the Expires header
specifies an absolute time, it is converted to a delta-time by
the gateway. If no Expires header is present, one hour is
assumed.

o The transID parameter in the CPIM message is constructed by
appending the Call-ID, the URI in the To field, the URI in the
From field, the CSeq and the tag in the From field, and the
request URI, and computing a hash of the resulting string.
This hash is used as the transID. Note that the request URI is
included in the hash. This is to differentiate forked requests
within the SIP network that may arrive at the same gateway.

The CPIM service then responds with either a success or failure. In
the case of success, the SIP to CPIM gateway service generates a 202
response to the SUBSCRIBE. It adds a tag to the To field in the
response, which is the same as the transID field in the success
response. The 202 response also contains a Contact header, which is
the value of the target from the SUBSCRIBE request. It is important
that the Contact header be set to the target, since that makes sure
that subscription refreshes have the same value in the request URI as
the original subscription. The duration value from the CPIM success
response is placed into the Expires header of the 202. The gateway
stores the Call-ID and Route header set for this subscription.

If the CPIM service responds with a failure, the SIP to CPIM gateway
generates a 603 response. It adds a tag to the To field in the
response, which is the same as the transID field in the failure
response.

When the CPIM system generates a notification request, the SIP to
CPIM gateway creates a SIP NOTIFY request. The request is constructed
using the standard RFC2543 [2] procedures for constructing a request
within a call leg. This will result in the To field containing the
watcher field from CPIM, and the From field containing the target
field from the CPIM notification. The tag in the From field will
contain the transID. The presence information is copied into the body
of the notification. The Call-ID and Route headers are constructed
from the subscription state stored in the gateway. If no notification
has yet been generated for this subscription, an initial CSeq value
is selected and stored.

SUBSCRIBE refreshes are handled identically decides to initial
migrate subscriptions

Rosenberg et al. [Page 15]

Internet Draft presence July 20, 2001

as above.

If a subscription is received with an Expires of zero, the SIP to
CPIM gateway generates an unsubscribe message into the the CPIM
system. The watcher parameter is copied from the From field of the
SUBSCRIBE. The target parameter is copied from the Request URI field
of the SUBSCRIBE. The transID is copied from the tag in the To field
of the SUBSCRIBE request.

The response to an unsubscribe is either success or failure. In the
case of success, a 202 response is constructed in the same fashion as
above for a success response to a CPIM subscriber. All subscription
state is removed. In the case of failure, a 603 response is
constructed in the same fashion as above, and then subscription state
is removed, if present.

7.2 CPIM to SIP

CPIM to SIP conversion occurs when a CPIM subscription request
arrives on the CPIM side of the gateway. This scenario is shown in
Figure 2.

The CPIM subscription request is converted into a SIP SUBSCRIBE
request. To do that, the first step is to determine if the subscribe
is for an existing subscription. That is done by taking the target in
the CPIM subscription request, and matching it against targets for
existing subscriptions. If there are none, it is a new subscription,
otherwise, its a refresh.

If its a new subscription, the gateway generates a SIP SUBSCRIBE
request in the following manner:

o The From field in the request is set to the watcher field it in order to reduce state in the CPIM subscription request network.

There are three phases to this migration:

o The To field in element currently providing the request PA function determines
that another element is set to capable of handling the target field in subscription.

o That element currently hosting the
CPIM PA function destroys
subscription request state, and inform those subscribers that the
state needs to be re-established with a new SUBSCRIBE.

o The Expires header in When the SUBSCRIBE request is set subscribers re-SUBSCRIBE, the element proxies the
requests to the
duration field in new element handling the CPIM subscription request

o PA function.

The tag in first of these phases can occur through configuration, or through
dynamic means. One dynamic means for a presence server to discover
that the From field is set function can migrate to a PUA through the transID in REGISTER message.
Specifically, if a PUA wishes to indicate support for the CPIM
subscription request.

This PA
function, it SHOULD include a contact address in its registration
with a caller preferences "methods" parameter listing SUBSCRIBE message [13].
This indicates that it is then sent.

If capable of terminating and processing
SUBSCRIBE, and therefore can act as a PA. The presence server MAY
migrate the subscription if, for a given address of record, there is
one, and only one registered contact that indicates explicit support
for the SUBSCRIBE method.

For the second phase, the PA destroys the subscriptions and then
sends a refresh, NOTIFY to each subscriber, with an Subscription-Expires
header with value 0 [3]. This informs the subscribers that their
subscription was destroyed, and should be re-established with a new
SUBSCRIBE request is generated in (with a new Call-ID).

The subscribers then create brand new subscriptions, with a new

Rosenberg et al. [Page 16] 11]

Internet Draft presence July 20, August 31, 2001

+-------------+
| |
| CPIM to SIP |
| Conversion |
| |
SIP SUBSCRIBE | | CPIM subscription request
<--------------> | | <--------------->
| |
| |
| |
| |
| |
| |
+-------------+

Figure 2: CPIM

Call-ID, no route set and no To tag, and this is sent to SIP Conversion recreate the same way. However, there
subscription. These will also be a tag in eventually arrive at the To field,
copied from presence server.
The presence server acts as a logical proxy, and furthermore, SHOULD
implement the subscription state in SIP Caller preferences extension [13]. Because of the gateway, and
existence of a Route
header, obtained from registered Contact with a "methods" parameter
containing SUBSCRIBE, the subscription state in caller preferences extension will cause the gateway.

When a response
proxy to send the SUBSCRIBE to that one Contact, which is received, that of the
PUA. The PUA can then act as a response is sent to PA, and process the CPIM system. subscription
accordingly.

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 duration parameter in this response is copied result will be 405
responses from those UAS. However, the Expires header in one UAS which does support the SUBSCRIBE
method will generate a 2xx class response (a conversion from
an absolute time to delta time may (assuming the subscription
is accepted), and this will be needed). The transID in correctly forwarded towards the
subscriber based on proxy response processing rules [2]. The penalty
of not supporting caller preferences is copied from the tag in the From field 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 response. If PA function is co-located with the response was 202, PUA, user presence is
known directly by the status PA.

6.2 REGISTER

Baseline SIP defines a method that is set used by all SIP clients - the
REGISTER method. This method allows a UA to indeterminate. If inform a SIP network of
its current communications addresses (ie., Contact addresses) .
Furthermore, multiple UA can independently register Contact addresses
for the
response was same SIP URL. These Contact addresses can be SIP URLs, or
they can be any other 200 class response, the status is set valid URL.

Usage of REGISTER information to
sucess. For any other final response, the status construct presence is set to failure.

If only possible
if the response was a 200 class response, subscription state PA is
established. This state contains the tag from the To field in the
SUBSCRIBE response, and co-located with, or shares information with, the Route header set computed from SIP
registrar. In this case, the
Record-Routes and Contact headers in combined PA/registrar/proxy is known as
a presence server.

Using the 200 class response. register information for presence is straightforward. The

Rosenberg et al. [Page 17] 12]

Internet Draft presence July 20, August 31, 2001

subscription is indexed by

address of record in the presentity identification REGISTER (the To
field of field) identifies the SUBSCRIBE
presentity. The Contact headers define communications addresses that was generated).

If an unsubscribe request
describe the state of the presentity. The use of the SIP caller
preferences extension [13] is received from RECOMMENDED for use with UAs that are
interested in presence. It provides additional information about the CPIM side,
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 gateway
checks if MESSAGE method implies that the subscription exists. If it does, a SUBSCRIBE is
generated presentity supports
instant messaging as described above. However, a communications means.

The q values from the Expires Contact header is set [2] can be used to
zero. If establish
priorities amongst the subscription does not exist, various communications addresses in the gateway generates a
failure response and sends it
Contact headers.

The application of registered contacts to presence increases the CPIM system. When the response
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 the SUBSCRIBE request arrives, it is converted upload presence documents from PUA to a CPIM response
as described above for the initial SUBSCRIBE response. In all cases,
any subscription state PA,
the PA can act as an aggregator and redistributor of those documents.
The PA, in this case, would take the gateway is destroyed.

When a NOTIFY is presence documents received from
each PUA for the SIP system, a CPIM notification
request is sent. This notification is constructed as follows:

o The CPIM watcher is set to the URI in same presentity, and merge the To field 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
NOTIFY.

o aggregation should be done.

The CPIM target is set specific means by which a presence document are uploaded to a
presence agent are outside the URI in the From field scope of this specification. When a
PUA wishes to have direct manipulation of the
NOTIFY.

o The transID is computed using the same mechanism as for the
SUBSCRIBE in Section 7.1

o The presence component that is
distributed to subscribers, direct uploading of the notification presence documents is extracted from
RECOMMENDED.

6.4 Call State Subscriptions

Another mechanism that a PA can use to determine the body state of the SIP NOTIFY request.

The gateway generates a 200 response
presentity is to SUBSCRIBE to the SIP NOTIFY and sends it
as well.

TODO: some call flow diagrams with state event package for that
presentity [14]. This will allow the parameters

8 PA to know when the user is in a
call, not in a call, etc., which can be used to provide richer
presence server content.

7 Security considerations

There are numerous security considerations for presence. Many are

Rosenberg et al. [Page 13]

Internet Draft presence August 31, 2001

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
not establish independent media streams, as INVITE does, firewall and
NAT traversal is much simpler than described in [12] and [13].

Generally, data traverses NATs and firewalls when it is sent over TCP
or TLS connections established by devices inside straightforward.

Specifically, the firewall/NAT to
devices outside of it. As a result, it is RECOMMENDED that SIP extensions for
presence entities maintain persistent TCP or TLS connections to their
next hop peers. This includes connections opened NAT traversal [15] are directly
applicable to send a SUBSCRIBE, SUBSCRIBE and NOTIFY, and most importantly, REGISTER. By keeping the latter
connection open, it can be used by the SIP proxy to send messages
from outside the firewall/NAT back to the client. It is also

Rosenberg et al. [Page 18]

Internet Draft presence July 20, 2001

recommended that the client include a Contact cookie as described in
[13] in their registration, so that the proxy can map the presentity
URI to that connection.

Furthermore, entities on either side of a firewall or NAT should
record-route in order to ensure that the initial connection
established for the subscription is used for the notifications as
well.

9 Security considerations

There are numerous security considerations for presence. Many are
outlined above; this section considers them issue will allow operation of the
protocol through NATs. Firewall administrators can set policies that
allow or disallow communications services by issue.

9.1 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 [14] [16] 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.

Rosenberg et al. [Page 19] 14]

Internet Draft presence July 20, August 31, 2001

that the PUA supports TLS.

SIP encryption MAY be used end to end for the transmission of both
SUBSCRIBE and NOTIFY requests.

9.2

7.3 Message integrity and 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
authentication and message integrity. SIP provides PGP based
authentication and integrity (both challenge-response and public key
signatures), and http basic and digest authentication. HTTP Basic is
NOT RECOMMENDED.

9.3

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.

9.4

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 (http digest or PGP) MAY
be used to prevent replay attacks.

9.5

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.

9.5.1 Smurf attacks through false contacts

Rosenberg et al. [Page 20] 15]

Internet Draft presence July 20, August 31, 2001

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.

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.

10.1 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
accepted, resulting in a 202 Accepted 200 OK response. The presentity subsequently
changes state (is on the phone), resulting in a new notification. The
flow finishes with the watcher canceling terminating the subscription.

Watcher Presentity
------- -----------
| F1 SUBSCRIBE |
| ----------------------------->|
| F2 202 Accepted 200 OK |
|<------------------------------|

Rosenberg et al. [Page 16]

Internet Draft presence August 31, 2001

| F3 NOTIFY |
|<------------------------------|
| F4 200 OK |

Rosenberg et al. [Page 21]

Internet Draft presence July 20, 2001
|------------------------------>|
| F5 NOTIFY |
|<------------------------------|
| F6 200 OK |
|------------------------------>|
| F7 SUBSCRIBE (unsub) |
|------------------------------>|
| F8 202 Accepted 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 <pres:user@example.com> <sip:user@example.com>;tag=9988
To: Resource <pres:presentity@example.com> <sip:presentity@example.com>
Call-ID: 3248543@watcherhost.example.com
CSeq : 1 SUBSCRIBE
Expires: 600
Accept: application/xpidf+xml application/cpim-pidf+xml
Event: presence
Contact: sip:user@watcherhost.example.com

F2 202 Accepted 200 OK presentity->watcher

SIP/2.0 202 Accepted 200 OK
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <pres:user@example.com> <sip:user@example.com>;tag=9988
To: Resource <pres:presentity@example.com>;tag=88a7s <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

Rosenberg et al. [Page 22] 17]

Internet Draft presence July 20, August 31, 2001

Event: presence
Expires: 600
Contact: sip:presentity@pres.example.com

F3 NOTIFY Presentity->watcher

NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pres.example.com:5060
From: Resource <pres:presentity@example.com>;tag=88a7s <sip:presentity@example.com>;tag=88a7s
To: User <pres:user@example.com> <sip:user@example.com>;tag=9988
Call-ID: 3248543@watcherhost.example.com
CSeq: 1 NOTIFY
Event: presence
Content-Type: application/xpidf+xml application/cpim-pidf+xml
Content-Length: 120

<?xml version="1.0"?> ...

<presence entityInfo="pres:presentity@example.com"> xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
<tuple destination="sip:presentity@example.com" status="open"/> 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 <pres:presentity@example.com> <pres:presentity@example.com>;tag=88a7s
To: User <pres:user@example.com> <pres:user@example.com>;tag=9988
Call-ID: 3248543@watcherhost.example.com
CSeq: 1 NOTIFY

Rosenberg et al. [Page 18]

Internet Draft presence August 31, 2001

F5 NOTIFY Presentity->watcher

NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pres.example.com:5060
From: Resource <pres:presentity@example.com> <sip:presentity@example.com>;tag=88a7s
To: User <pres:user@example.com> <sip:user@example.com>;tag=9988
Call-ID: 3248543@watcherhost.example.com
CSeq: 2 NOTIFY
Event: presence
Content-Type: application/xpidf+xml application/cpim-pidf+xml
Content-Length: 120

<?xml version="1.0"?> ...

Rosenberg et al. [Page 23]

Internet Draft presence July 20, 2001 xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
<tuple destination="sip:presentity@example.com" status="closed"/> 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 <pres:presentity@example.com> <sip:presentity@example.com>;tag=88a7s
To: User <pres:user@example.com> <sip:user@example.com>;tag=9988
Call-ID: 3248543@watcherhost.example.com
CSeq: 2 NOTIFY

F7 SUBSCRIBE watcher -> presentity

SUBSCRIBE sip:presentity@pres.example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <pres:user@example.com>
To: Resource <pres:presentity@example.com>
Call-ID: 3248543@watcherhost.example.com
To: Resource <sip:presentity@example.com>;tag=88a7s
From: User <sip:user@example.com>;tag=9988
Event: presence

Rosenberg et al. [Page 19]

Internet Draft presence August 31, 2001

CSeq : 2 SUBSCRIBE
Expires: 0
Accept: application/xpidf+xml application/cpim-pidf+xml
Contact: sip:user@watcherhost.example.com

F8 202 Accepted 200 OK presentity->watcher

SIP/2.0 202 Accepted 200 OK
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <pres:user@example.com>
To: Resource <pres:presentity@example.com>
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

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>

Rosenberg et al. [Page 24] 20]

Internet Draft presence July 20, August 31, 2001

10.2

F10 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: 3 NOTIFY

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 202 200 |
| |<---------------------|
| F6 202 200 | |
|<---------------------| |
| F7 NOTIFY | |
|<--------------------------------------------+
| F8 200 OK | |
|-------------------------------------------->|
| | F9 REGISTER |
| |<---------------------|
| | F10 200 OK |
| |--------------------->|
| F11 NOTIFY | |
|<--------------------------------------------+
| F12 200 OK | |

Rosenberg et al. [Page 21]

Internet Draft presence August 31, 2001

|-------------------------------------------->|

Message Details

F1 REGISTER PUA->server

Rosenberg et al. [Page 25]

Internet Draft presence July 20, 2001
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"
;description="open"
Contact: <sip:id@pua.example.com>;methods="SUBSCRIBE" <sip:id@pua.example.com>;methods="MESSAGE,SUBSCRIBE"
Expires: 600

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"
;description="open"
Contact: <sip:id@pua.example.com>;methods="SUBSCRIBE" <sip:id@pua.example.com>;methods="MESSAGE,SUBSCRIBE"
Expires: 600

F3 SUBSCRIBE watcher->server

SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <pres:user@example.com> <sip:user@example.com>;tag=ggf8
To: Resource <pres:resource@example.com> <sip:resource@example.com>
Call-ID: 32485@watcherhost.example.com

Rosenberg et al. [Page 22]

Internet Draft presence August 31, 2001

CSeq : 1 SUBSCRIBE
Expires: 600
Event: presence
Accept: application/xpidf+xml application/cpim-pidf+xml
Contact: sip:user@watcherhost.example.com

Rosenberg et al. [Page 26]

Internet Draft presence July 20, 2001

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 <pres:user@example.com> <sip:user@example.com>;tag=ggf8
To: Resource <pres:resource@example.com> <sip:resource@example.com>
Call-ID: 32485@watcherhost.example.com
CSeq : 1 SUBSCRIBE
Event: presence
Expires: 600
Accept: application/xpidf+xml application/cpim-pidf+xml
Contact: sip:user@watcherhost.example.com

F5 202 Accepted 200 OK PUA->server

SIP/2.0 202 Accepted 200 OK
Via: SIP/2.0/UDP server.example.com:5060
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <pres:user@example.com> <pres:user@example.com>;tag=ggf8
To: Resource <pres:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq : 1 SUBSCRIBE
Event: presence
Expires: 600
Contact: sip:id@pua.example.com

Rosenberg et al. [Page 23]

Internet Draft presence August 31, 2001

F6 200 OK server->watcher

SIP/2.0 202 Accepted 200 OK
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <pres:user@example.com> <pres:user@example.com>;tag=ggf8
To: Resource <pres:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq : 1 SUBSCRIBE
Event: presence
Expires: 600

Rosenberg et al. [Page 27]

Internet Draft presence July 20, 2001
Contact: sip:id@pua.example.com

F7 NOTIFY PUA->watcher

NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: User <pres:user@example.com> <pres:user@example.com>;tag=ggf8
From: Resource <pres:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq : 1 NOTIFY
Event: presence
Content-Type: application/xpidf+xml application/cpim-pidf+xml
Content-Length: 120

<?xml version="1.0"?> ...

<presence entityInfo="pres:resource@example.com"> xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
<tuple destination="im:resource@example.com" status="open"/> 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 24]

Internet Draft presence August 31, 2001

SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To: User <pres:user@example.com> <pres:user@example.com>;tag=ggf8
From: Resource <pres:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq : 1 NOTIFY

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"
;description="busy"
Contact: <sip:id@pua.example.com>;methods="SUBSCRIBE" <sip:id@pua.example.com>;methods="MESSAGE,SUBCSRIBE"
;q=0.0
Expires: 600

Rosenberg et al. [Page 28]

Internet Draft presence July 20, 2001

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"
;description="busy"
Contact: <sip:id@pua.example.com>;methods="SUBSCRIBE" <sip:id@pua.example.com>;methods="MESSAGE,SUBSCRIBE"
;q=0.0
Expires: 600

F11 NOTIFY PUA->watcher

Rosenberg et al. [Page 25]

Internet Draft presence August 31, 2001

NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: User <pres:user@example.com> <sip:user@example.com>;tag=ggf8
From: Resource <pres:resource@example.com>;tag=ffd2 <sip:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq : 2 NOTIFY
Event: presence
Content-Type: application/xpidf+xml application/cpim-pidf+xml
Content-Length: 120

<?xml version="1.0"?> ...

<presence entityInfo="pres:resource@example.com"> xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
<tuple destination="im:resource@example.com" status="busy"/> 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 <pres:user@example.com> <sip:user@example.com> ;tag=ggf8
From: Resource <pres:resource@example.com>;tag=ffd2 <sip:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq : 2 NOTIFY

Rosenberg et al. [Page 29]

Internet Draft presence July 20, 2001

10.3

8.3 Presence Server Notifications

This message flow illustrates how the presence server can be the
responsible for sending notifications for a presentity. The presence
server will do this if the presentity has not sent a registration
indicating an interest in handling subscriptions. This flow
assumes that the watcher has previously been authorized to subscribe
to this resource at the server.

In this flow, the PUA informs the server about the updated presence
information though some non-SIP means.

Rosenberg et al. [Page 26]

Internet Draft presence August 31, 2001

Watcher Server PUA
| F1 SUBSCRIBE | |
|------------------>| |
| F2 202 Accepted 200 OK | |
|<------------------| |
| F3 NOTIFY | |
|<------------------| |
| F4 200 OK | |
|------------------>| |
| | F5 REGISTER |
| |<-------------------| | Update presence | F6 200 OK
| |<------------------ | |------------------->|
| F7 | |
| F5 NOTIFY | |
|<------------------| |
| F8 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: <pres:resource@example.com> <sip:resource@example.com>
From: <pres:user@example.com> <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Event: presence
Accept: application/xpidf+xml application/cpim-pidf+xml
Contact: <sip:user@watcherhost.example.com>
Expires: 600

Rosenberg et al. [Page 30]

Internet Draft presence July 20, 2001

F2 202 OK server->watcher

SIP/2.0 202 Accepted 200 OK
Via: SIP/2.0/UDP watcherhost.example.com:5060
To: <pres:resource@example.com>;tag=ffd2 <sip:resource@example.com>;tag=ffd2
From: <pres:user@example.com> <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com

Rosenberg et al. [Page 27]

Internet Draft presence August 31, 2001

CSeq: 1 SUBSCRIBE
Event: presence
Expires: 600
Contact: sip:example.com

F3 NOTIFY server-> watcher

NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
From: <pres:resource@example.com>;tag=ffd2 <sip:resource@example.com>;tag=ffd2
To: <pres:user@example.com> <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
Event: presence
CSeq: 1 NOTIFY
Content-Type: application/xpidf+xml application/cpim-pidf+xml
Content-Length: 120

<?xml version="1.0"?> ..

F4 200 OK

SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
From: <pres:resource@example.com>;tag=ffd2 <sip:resource@example.com>;tag=ffd2
To: <pres:user@example.com> <pres:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 1 NOTIFY

Rosenberg et al. [Page 31] 28]

Internet Draft presence July 20, August 31, 2001

F5 REGISTER

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: 110@pua.example.com
CSeq: 2 REGISTER
Contact: <sip:id@pua.example.com>;methods="MESSAGE"
;description="Away from keyboard"
Expires: 600

F6 200 OK

Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com>
From: <sip:resource@example.com>
Call-ID: 110@pua.example.com
CSeq: 2 REGISTER
Contact: <sip:id@pua.example.com>;methods="MESSAGE"
; description="Away from keyboard"
; expires=600

F7 NOTIFY

NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
From: <pres:resource@example.com>;tag=ffd2 <sip:resource@example.com>;tag=ffd2
To: <pres:user@example.com> <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 2 NOTIFY
Event: presence
Content-Type: application/xpidf+xml application/cpim-pidf+xml
Content-Length: 120

<?xml version="1.0"?>

Rosenberg et al. [Page 32]

Internet Draft presence July 20, 2001 xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0">
<tuple destination="im:resource@example.com" status="Away from keyboard"/> 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: <pres:user@example.com> <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 2 NOTIFY

11 Open Issues

The following is the list of known open issues:

9 Changes from draft-ietf-simple-presence-01

o This draft recommends Complete alignment with draft-ietf-sip-events.

o Removal of non-confirming mode. Instead, just mention that the To
polite blocking is possible, and From field are populated
with how it is done is

Rosenberg et al. [Page 29]

Internet Draft presence URLs rather than sip URLs. Is that reasonable?
Will this lead to incompatibilities in proxies? Is there any
issues with August 31, 2001

implementation specific.

o Removed CPIM if the SIP URL format is used? This depends
on what components of sections to a message are signed in CPIM. separate specification.

o Rate limitations on NOTIFY: do we want that? How do we pick a
value? 5 seconds is arbitrary. Added reference to privacy specification for transitive
authentication scenarios.

o Merging Implementation of caller preferneces by presence data from multiple PA has been removed. Is
that OK? servers is
now a SHOULD.

o Placing IM URLs in Clarification on the Contact header process of a REGISTER: is that
OK? What does it mean? subscription migration.

o The SIP to CPIM and CPIM to SIP gateways are not stateless,
because of For subscription migration, the need to maintain Route, Call-ID, CSeq, and
other parameters. Perhaps we can ask CPIM to define a token
value which is sent in a CPIM request and returned in specification now mentions the
Subscription-Expires header as the means for a CPIM
response. Would that help?

o Need to specify how PA to take Contacts from REGISTER and build a
presence document. One obvious thing is inform
subscribers that the contact
addresses don't go in there directly; you probably want their subscription has expired. This header
has yet to put

Rosenberg et al. [Page 33]

Internet Draft appear in draft-ietf-sip-events.

o Updated section of usage of presence July 20, 2001

the address URLs based on consensus
of record, otherwise calls might not go through the proxy. IMPP group at IETF 51.

o Need Construction of presence documents based on REGISTER is now
defined as implementation dependent. If a UA wants to add IMPP DNS procedures once stable.
manipulate its presence, it should upload a presence document
fragment instead.

o Transitive authentication is really Removed bit about network
authenticated identities. Sounds like the SIP privacy
extensions might be useful here, especially if we want recreating subscriptions when a 481 is
received to
support anonymous subscriptions. Should we explicitly mention
that? a SUBSCRIBE request. This should be in draft-
ietf-sip-events instead.

o Do we need Removed references to define what information gets sent in draft-lennox-sip-reg-payload and much of
that discussion. Now, the NOTIFY section talks more generally about
uploading and aggregation of a non-confirming subscription when its pending or rejected?
Do we really want presence documents, and simply
states that the non-confirming mode?

o Are we sure we are using REGISTER means for such upload is outside the scope of presence
documents?

12
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.

10 Changes from draft-ietf-simple-presence-00

o Clarified that user presence can be obtained in many ways, not
just SIP.

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

Rosenberg et al. [Page 30]

Internet Draft presence August 31, 2001

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

Rosenberg et al. [Page 34]

Internet Draft presence July 20, 2001
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.

11 Changes from draft-rosenberg-impp-presence-01

Renamed to draft-ietf-simple-presence-00.

12 Changes from draft-rosenberg-impp-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.

o The SUBSCRIBE message can only have a single Contact header.
-00 allowed for more than one.

Rosenberg et al. [Page 31]

Internet Draft presence August 31, 2001

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.

Rosenberg et al. [Page 35]

Internet Draft presence July 20, 2001

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.

13 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
Jorgen Bjorkner Hotsip
Henry Sinnreich MCI Worldcom
Ronald Akers Motorola

Rosenberg et al. [Page 32]

Internet Draft presence August 31, 2001

14 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

Rosenberg et al. [Page 36]

Internet Draft presence July 20, 2001
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
email: lennox@cs.columbia.edu

Christian Huitema
Microsoft Corporation
One Microsoft Way

Rosenberg et al. [Page 33]

Internet Draft presence August 31, 2001

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

Rosenberg et al. [Page 37]

Internet Draft presence July 20, 2001
email: oran@cisco.com

15 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, "Event notification in SIP," "SIP specific event notification," Internet Draft,
Internet Engineering Task Force, Feb. July 2001. Work in progress.

[4] D. Crocker et al. , "A common profile for instant messaging
(CPIM)," 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.

[6] H. Sugano and S. Fujimoto, "Cpim presence information data
format," Internet Draft, Internet Engineering Task Force, Aug. 2001.
Work in progress.

Rosenberg et al. [Page 34]

Internet Draft presence August 31, 2001

[7] B. Marshall et al. , "SIP extensions for caller identity and
privacy," Internet Draft, Internet Engineering Task Force, Feb. Mar. 2001.
Work in progress.

[5]

[8] P. Calhoun, A. Rubens, H. Akhtar, and J. Arkko, E. Guttman, "DIAMETER A. Rubens, and G.
Zorn, "Diameter base protocol," Internet Draft, Internet Engineering
Task Force, Feb. Apr. 2001. Work in progress.

[6]

[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.

[7]

[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.

[8]

[11] J. Rosenberg, "A SIP event sub-package for watcher information,"
Internet Draft, Internet Engineering Task Force, July 2001. Work in
progress.

[9]

[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.

[10] J. Lennox and H. Schulzrinne, "Transporting user control
information in SIP REGISTER payloads," Internet Draft, Internet
Engineering Task Force, Oct. 2000. Work in progress.

[11]

[14] J. Rosenberg and H. Schulzrinne, "A SIP event package for call
and conference state," Internet Draft, Internet Engineering Task

Rosenberg et al. [Page 38]

Internet Draft presence July 20, 2001
Force, July 2001. Work in progress.

[12]

[15] J. Rosenberg, D. Drew, and H. Schulzrinne, "Getting SIP through
firewalls and NATs," Internet Draft, Internet Engineering Task Force,
Feb. 2000. Work in progress.

[13] J. Rosenberg Weinberger, and H. Schulzrinne, "SIP traversal through
residential and enterprise NATs and firewalls," extensions
for NAT traversal," Internet Draft, Internet Engineering Task Force, Mar.
Aug. 2001. Work in progress.

[14]

[16] 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 35]

Internet Draft presence August 31, 2001

2 Definitions ......................................... 2
3 Overview of Operation ............................... 3
4 Naming .............................................. Usage of Presence URLs .............................. 4
5 Presence Event Package .............................. 5 4
5.1 Package Name ........................................ 5 4
5.2 Event Package Parameters ............................ 5
5.3 SUBSCRIBE bodies .................................... 5
5.3 Expiration .......................................... 6
5.4 Subscription Duration ............................... 6
5.5 NOTIFY Bodies ....................................... 6
5.5
5.6 Subscriber Generation of SUBSCRIBE Requests ......... 6
5.7 Notifier Processing Requirements at the PA ................... of SUBSCRIBE Requests ........... 7
5.6
5.8 Notifier Generation of Notifications ......................... NOTIFY Requests .............. 8
5.7 Rate Limitations on
5.9 Subscriber Processing of NOTIFY .......................... Requests ............ 9
5.8 Refresh Behavior ....................................
5.10 Handling of Forked Requests ......................... 9
5.11 Rate of Notifications ............................... 10
5.12 State Agents and Notifier Migration ................. 10
6 Publication ......................................... 10 12
6.1 Co-location ......................................... 10 12
6.2 REGISTER ............................................ 11 12
6.3 Uploading Presence Documents ........................ 11 13
6.4 Call State Subscriptions ............................ 12
6.5 Migrating the PA Function ........................... 12 13
7 Mapping to CPIM ..................................... Security considerations ............................. 13
7.1 SIP to CPIM ......................................... 13
7.2 CPIM to SIP ......................................... 16
8 Firewall and NAT Traversal .......................... 18
9 Security considerations ............................. 19
9.1 14
7.2 Privacy ............................................. 19
9.2 14
7.3 Message integrity and authenticity .................. 20
9.3 15
7.4 Outbound authentication ............................. 20

Rosenberg et al. [Page 39]

Internet Draft presence July 20, 2001

9.4 15
7.5 Replay prevention ................................... 20
9.5 15
7.6 Denial of service attacks ........................... 20
9.5.1 15
7.6.1 Smurf attacks through false contacts ................ 20
10 16
8 Example message flows ............................... 21
10.1 16
8.1 Client to Client Subscription with Presentity
State Changes .................................................. 21
10.2 16
8.2 Presence Server with Client Notifications ........... 25
10.3 21
8.3 Presence Server Notifications ....................... 30
11 Open Issues ......................................... 33
12 26
9 Changes from draft-ietf-simple-presence-01 .......... 29
10 Changes from draft-ietf-simple-presence-00 .......... 34
13 30
11 Changes from draft-rosenberg-impp-presence-01 ....... 35
14 31
12 Changes from draft-rosenberg-impp-presence-00 ....... 35
15 31
13 Acknowledgements .................................... 36
16 32
14 Authors Addresses ................................... 36
17 33
15 Bibliography ........................................ 38 34

Rosenberg et al. [Page 40] 36]

----