wdiff draft-rosenberg-impp-presence-00.txt draft-rosenberg-impp-presence-01.txt

Internet Engineering Task Force IMPP SIMPLE WG
Internet Draft Jonathan Rosenberg
Dean Willis
Robert Sparks
Ben Campbell
dynamicsoft

Henning Schulzrinne
Jonathan Lennox
Columbia U.

Bernard Aboba
Christian Huitema
David Gurle
Microsoft

Dave Oran
Cisco
draft-rosenberg-impp-presence-00.txt
June 15, 2000 et al.
draft-rosenberg-impp-presence-01.txt Various Places
March 2, 2001
Expires: December, 2000 September 2001

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

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document proposes an extension to SIP for subscriptions and
notifications of user presence. Traditional SIP clients already make
use of User presence is defined as the REGISTER method
willingness and ability of a user to upload communicate with other users on
the network. Historically, presence state to network
servers, in order to enable call establishment. This extension allows
that data to be published has been limited to subscribers. This is accomplished by
defining two new SIP methods - SUBSCRIBE "on-line" and NOTIFY,
"off-line" indicators; the notion of presence here is broader.
Subscriptions and notifications of user presence are supported by
defining
a new logical entity, an event package within the presence agent (PA), which handles
subscriptions general SIP event notification
framework. This protocol is also compliant with the Common Presence
and notifications. 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.

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. Baseline SIP is used primarily for
initiation of interactive sessions, such as voice, video, and games.
The process of session initiation requires a system which uses the
communications means, communications addresses, and communications
status of a user in order to determine the host where initiation
requests can be delivered. A presence system is one where this
information is pushed to subscribers through notification requests,
as opposed to being pulled by proxy and redirect servers when session
establishment is desired. In a sense, this makes presence and session
initiation "duals" - one is synchronous (presence systems push data
the instant it changes) and the other is asynchronous (servers access
presence data for a user at the point where a call is initiated to
that user). The similarities between presence and communications
establishment is one reason why we chose to base the presence
protocol on SIP. Section 2 explains this in greater detail.

The extension defined here has, as its objectives, scalability,
security, flexibility, and extensibility. To provide scale, our
protocol (1) pushes intelligence to the periphery wherever possible,
as we believe this to be the primary tool for achieving this goal,
(2) allows the global namespace to be divided into a hierarchy, and
(3) allows presence state to be distributed along this hierarchy.
Many of the capabilities of this extension for providing scale are
simply inherited from SIP, which was engineered to handle highly
scalable communications establishment. This extension also makes
communications between differing administrative domains possible. The
scale objectives and mechanisms for achieving it are outlined in
detail in section 9.

Presence deals with highly sensitive data regarding people, and we
can envision future applications which deal with information like the
physical location of individuals, which is even more sensitive. To
handle this, privacy of the information distributed, and
authentication of relevant parties in the system is provided by the
system.

Finally, flexibility is important. It is likely that a protocol for
subscription and notification concrete
instantiation of events related to communications
will be applied to other applications. Even within the general area
of communications, subscription and event notification services are needed
for features like auto callback and message waiting indication. While
these are not directly addressed by this extension, we have
engineered in sufficient flexibility to enable them in a systematic
fashion. This is accomplished by separating the protocol operation
from the underlying transport (UDP, TCP, or anything else can be
used), and by separating the transfer of subscriptions and
notifications from their content. The extension is also flexible in
that it can support client to client subscriptions and notifications
with no server at all (serverless operation), support a single server
for intra-domain operation, multiple servers framework defined for intra-domain
operation, and inter-domain operation with a server in one domain,
the other, or both.

2 Why use
SIP [3], and as a base protocol for presence?

We have chosen such, makes use of the Session Initiation Protocol (SIP) as a starting
point for developing a SUBSCRIBE and NOTIFY methods
defined there. User presence protocol. This is particularly well suited for many reasons.
Overall, our aim is to reuse infrastructure and components which help
solve the problem. We have found that SIP. SIP solves a very similar
problem, with the result that minimal work is required to extend it
to solve the problem at hand.

SIPs primary function is to initiate interactive multiparty
communications sessions. The challenge in doing this is to allow a
caller to take a location independent identifier, such as
joe@example.com,
registrars and use it to discover the location of the user
(where location in this context refers to a host on the Internet
where the services already hold user can be reached), so that the invitation to join a
session can be delivered. The problem presence
information; it is challenging because users
move around, have dynamically assigned IP addresses, may be reachable
at numerous locations and via multiple devices, and may have varying
capabilities at those locations. SIP operates by allowing users to
send communications reachability state uploaded to the network, these devices through REGISTER
messages, and this
information is used by the network to "rendezvous" the caller with
the called party. Within baseline SIP, this communications
reachability state consists primarily of communications addresses.
However, an extension, caller preferences and callee capabilities
[3], extends this state to include status and capabilities. This
enables a much more powerful form of rendezvous. For example, a
caller can dial a generic number for the called party, specify in the
call establishment request that communications is desired with a
mobile phone, and the call will be preferentially routed route calls to the users
cell phone.

We observed that the information used by network elements within those users. Furthermore, SIP
to rendezvous callers with called users is the *same* information
distributed by a presence protocol. The only difference is in the
application of this information. In SIP, this information is not
distributed to interested parties when it changes, but rather used
networks already route INVITE messages from any user on
demand to set up a call. In essence, SIP makes use of this state
(uploaded to the network in REGISTER requests) for asynchronously
initiated queries for communications, while presence distributes it
synchronously when it changes. Effectively, session initiation and
presence are "duals" of each other, relying on the same information.
Because of this, extension of SIP
to satisfy the needs of a presence
protocol seems very sensible - a re-use of "information".

There is also significant reuse of protocol machinery, and more
importantly, reuse of deployed components, infrastructure, and data.
Conceptually, using the same infrastructure for initiation of
communications, and for distribution of communications state, seems
natural. It means that the same system provides both components of
interactive communications services, working seamlessly and
efficiently. Reuse of the same infrastructure means a big reduction
in management and infrastructure costs for providers. Perhaps most
importantly, using the same underlying protocols and infrastructures
makes it easy to provide new services which integrate voice/video and
presence.

Furthermore, we anticipate proxy that many systems will offer both
communications establishment and presence on the same device, such as
a wireless handset. Therefore, using holds the same underlying protocol
components registration state for both is a substantial practical advantage in terms of
code reuse and memory footprint reduction, both of which are very
important for wireless handsets. Real SIP implementations exist with
memory footprints well under 100k. user. As only a subset of SIP this
state is needed
for user presence, this number will be even lower for presence-only
systems.

The abstract arguments made in the previous paragraph manifest
themselves through a common set of requirements for both presence and
session initiation. As a result, there are many capabilities already
present in SIP which are directly applicable to presence. In
particular:

Scale: SIP must scale to support initiation of communications
sessions among the global Internet populace. This presents
demanding scale requirements. To meet them, those SIP allows for
the global namespace of users to be divided up
hierarchically, with dynamic communications state stored
only in the leaves of the hierarchy. Network elements
(called proxies) within the hierarchy networks can be stateless,
handling routing of requests downward in the hierarchy, and
responses upwards, without storing any information. This
simulaneously provides both scale and fault tolerance.

Rendezvous: SIP must also allow a caller to have an initiation
request routed to the server which has authoritative
information about the location and communications
capabilities of the called user. For presence, a mechanism
is needed to route subscription SUBSCRIBE
requests to the server
which has authoritative information about the location and
communications capabilities of the subscribed-to user.
Clearly, these are the same exact problem, and SIPs
existing rendezvous and routing capabilities are directly
applicable for presence.

Identity of Participants: In SIP, it is critical to be able to
identify the initiator of the request, and the target of
the communications. In presence, messages need routed to identify
the initiator of the subscription, and its target. These
are the same parties. The SIP mechanisms for identification
of entities are therefore directly usable for presence.

Authentication of Initiator: In SIP, it is essential that the
called party be able to verify the identity of the caller,
in order to prevent calls from unwanted parties. In
presence, it is essential proxy. This means that the presentity be able to
verify the identity of the subscriber, in order to prevent
subscriptions from unwanted parties. Both are the same
problem, and readily accomplished with end to end
authentication mechanisms. SIP currently provides three
such mechanisms, one of which is public key based (PGP),
and the other two of which are based on a shared secret
(http basic and digest). The protocol is extensible to
support additional mechanisms. Furthermore, SIP provides
proxy-signed requests, so that the presentity can verify
the domain of the originator.

End-to-end privacy of Data: In SIP, the bodies, and several of
the headers of the request and response messages networks
can be
encrypted, using PGP. This allows for privacy of sessions
users are being invited to. For presence, there is a need
for end reused to end privacy of the presence state users convey,
which is also encapsulated in bodies. Thus, the SIP
encryption mechanisms can provide privacy establish global connectivity for presence.

Hop-by-Hop Encryption: End to end encryption is important, but
requires deployment of a PKI with end user keys. As none
really exists, a secondary level of privacy can be provided
when a transitive trust relationship exists between users presence
subscriptions and network elements of multiple administrative domains. notifications.

This extension is through hop by hop encryption between users and
proxies and proxies and proxies. SIP allows hop by hop
encryption based on any number of mechanisms, and this the concept can be reused for privacy of a presence as well.

Content: SIP uses MIME to carry content in its messages.
Normally, this content is the Session Description Protocol
(SDP) [4] agent, which defines sessions, but other content is
allowed. Subscription requests need to carry documents
a new logical entity that
describe details is capable of the subscription, accepting subscriptions,
storing subscription state, and notification
requests carry documents that describe the state of the
presentity. We propose that MIME is also used for this
purpose. This provides important extensibility
capabilities. As these capabilities generating notifications when there
are already provided by
SIP, no additional work is needed to support them changes in user presence.

Transport Independence: SIP is used to establish communications
sessions. A widely varying set of devices The entity is likely to make
use of such services, including PCs, wireless PDAs (in
fact, the 3GPP wireless standards body has already chosen
SIP defined as the signaling platform for third generation wireless
devices), standalone phones, cell phones, laptops, and even
Internet appliances. In recognition of the diverse
connectivity these devices have, SIP a logical one,
since it is transport neutral,
and can run over any protocol, including TCP generally co-resident with another entity, and UDP. It can also be run over the newer SCTP [5], and a process for
doing so is defined in a companion document [6].

Soft State: In SIP, the communications state pushed into even
move around during the
network must be periodically refreshed in order for it to
remain present. This soft state mechanism provides
robustness against system crashes. The period lifetime of refresh
can be negotiated through a simple two phase mechanism. In
presence, this mechanism subscription.

This extension is not only needed for
communications state, but also for subscriptions, which
represent a new piece of state in compliant with the system. SIPs existing
refresh mechanisms can be reused for this purpose.

These similarities mean Common Presence and Instant
Messaging (CPIM) framework that the majority of SIPs mechanisms are
directly applicable for presence. has been defined in [4]. This allows
SIP proxies can route for presence
requests to easily interwork with no change. Section 12 details those components of SIP
which are, and are not, needed for presence.

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

User Agent (UA): A SIP User Agent. A UA is capable of sending
and receiving SIP requests.

User Agent Server (UAS): A UAS is the component of a UA which
receives requests, and responds to them.

User Agent Client (UAC): A UAC is the component of a UA which
sends requests, and receives responses.

Registrar: A registrar is a SIP server which can receive and
process REGISTER requests. These requests are used to
construct address bindings.

Proxy: A proxy is a SIP proxy. A SIP proxy receives a SIP
request, modifies some of the headers, and forwards the
request to a next-hop server, which can be another proxy,
or possibly a user agent.

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. 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 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 logical entity that can
act as either a presence agent that is
colocated with or as a proxy/registrar. It 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. It defines two new methods, SUBSCRIBE (for subscribing

When an entity, the subscriber, wishes to
changes in state), and NOTIFY (for notifying subscribers of changes
in state).

4.1 Architecture

We define a new type of SIP user agent, called a Presence Agent, or
PA. A PA is learn about presence
information from some user, it creates a logical function, and is usually co-located with SUBSCRIBE request. This
request identifies the desired presentity in the request URI, using
either a proxy/registrar, presence URL or a PUA. A PA SIP URL. The subscription is capable of storing subscriptions
and generating notifications. Since carried along
SIP proxies as any other INVITE would be. It eventually arrives at a PA
presence server, which can reside either in either
a proxy/registrar or within the PUA, the system allows both "network"
and "client" generated notifications and management of subscriptions.
In fact, terminate the role of PA is defined on a subscription by subscription
basis, and can change during the lifetime of the subscription. This
allows for (in
which case it acts as the PA function to migrate from PUA to presence server and
back, depending on the connectivity of the PUA.

PAs generate notifications. These notifications can be delivered
directly to agent for the subscriber, presentity), or proxies
proxy it on the subscription path can
elect to receive a presence client. If the notifications as well. Such flexibility allows
each administrative domain to make its own decision regarding presence client handles the
tradeoffs between security, scalability, and provision of services.
This flexibility is inherited from SIP.

The architecture
subscription, it is depicted in Figure 1.

4.2 Message Flow

A subscriber, effectively acting as a User Agent Client (in SIP, an end system
which sends requests the presence agent for the
presentity. The decision about whether to proxy or terminate the
SUBSCRIBE is called a User Agent Client, or UAC) wishing
to subscribe local matter; however, we describe one way to some presentity constructs effect
such a SIP SUBSCRIBE request
message. configuration, using REGISTER.

The request URI 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 request is protocol, and
we expect that many mechanisms will be used. Once authorized, the
presence agent sends a normal SIP URL
identifying 202 Accepted response. It also sends an
immediate NOTIFY message containing the address state of the presentity. This request URI is
rewritten by SIP proxies (which are very similar to HTTP proxies) as As
the request travels towards state of the recipient. For example, a request presentity changes, the PA generates NOTIFYs for
sip:joe@example.com will arrive at all
subscribers.

The SUBSCRIBE message effectively establishes a session with the example.com server, which
looks up Joe in some corporate database, and then determines that Joe
presence agent. As a result, the SUBSCRIBE can be reached internally at sip:joe@engineering.example.com. This
new address record-routed, and
rules for tag handling and Contact processing mirror those for
INVITE. Similarly, the NOTIFY message is placed handled in much the request same way
a re-INVITE within a call leg is handled.

4 Naming

Figure 1: Architecture form pres:user@domain. These URIs are
protocol independent. Through a variety of Presence System

sent means, these URIs can be
resolved to the server for engineering.example.com. Since the request URI
is rewritten by proxies, some means is needed determine a specific protocol that can be used to convey the identity
of the original desired recipient. Thus, access
the sender also places presentity. Once such a resolution has taken place, the
presentity can be addressed with a sip URL for the desired recipient in the mandatory To field. The From
field identifies the originator of the message. nearly identical form:
sip:user@domain. The message must also
contain protocol independent form (the pres: URL) can be
thought of as an abstract name, akin to a Call-ID. In SIP, the Call-ID URN, which is used to associate
identify elements in a group
of requests with presence system. These are resolved to
concrete URLs that can be used to directly locate those entities on
the same session. Here, network.

When subscribing to a presentity, the usage is subscription can be addressed
using the protocol independent form or the same; sip URL form. In the
session in this case SIP
context, "addressed" refers to the request URI. It is initiated by a SUBSCRIBE. All SUBSCRIBE
messages RECOMMENDED
that refresh if the subscription, and all NOTIFY messages
generated for that subscription, are part entity sending a SUBSCRIBE is capable of resolving the same session, and
thus share
protocol independent form to the same Call-ID value. Call-ID has no meaning beyond
being a common identifier.

Each SUBSCRIBE also carries a CSeq, which SIP form, this resolution is a sequence number plus done
before sending the name of request. However, if the method entity is incapable of
doing this translation, the request (the method name protocol independent form is there to
support SIP features not required for presence). The CSeq uniquely
identifies each SUBSCRIBE and NOTIFY used in the session, and increases
for each subsequent
request in URI. Performing the same direction. Each translation as early as possible means
that these requests can be routed by SIP request
also carries a Via header. Via headers contain a trace proxies that are not aware
of the IP
addresses or FQDNs presence namespace.

The result of the systems this naming scheme is that the request traversed. As a SUBSCRIBE request travels from proxy to proxy towards the recipient, each adds
its address, "pushing" them into a header, much like the operation of
a stack. The stack of addresses is reflected in the response, and
each proxy "pops" the top address off, and uses that to determine
where
addressed to send a user the response. exact same way an INVITE request would be
addressed. This allows proxies to forward UDP
requests statelessly, so means that they need not even remember where the
request came from to forward SIP network will route these messages
along the response. Finally, clients using
this extension MUST insert a Contact header into same path an INVITE would travel. One of these entities
along the request (Contact
is used path may act as a PA for routing of requests in the reverse direction, from subscription. Typically, this
will either be the
target of presence server (which is the original message to proxy/registrar
where that user is registered), or the initiator presence client (which is one
of the original
message).

The user agents associated with that presentity).

SUBSCRIBE request MAY messages also contain a body. The body contains
additional information logical identifiers that describes define the subscription. SIP uses
originator and recipient of the
standard MIME headers (Content-Type, Content-Length, subscription (the To and Content-
Encoding) From header
fields). Since these identifiers are logical ones, it is RECOMMENDED
that these use the protocol independent format whenever possible.
This also makes it easier to interwork with other systems which
recognize these forms.

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

An example subscription request looks like:

SUBSCRIBE sip:jdrosen@dynamicsoft.com SIP/2.0
Via: SIP/2.0/UDP userpc.example.com
To: sip:jdrosen@dynamicsoft.com
From: sip:user@example.com
Contact: sip:user@userpc.example.com
Call-ID: knsd08alas9dy@3.4.5.6
CSeq: 1 SUBSCRIBE
Content-Length: 0

The request MAY be sent using UDP or TCP (SIP supports SIP URL forms in both UDP and
TCP (and even SCTP [6] transport; reliability is guaranteed over UDP SUBSCRIBE and congestion control is provided through a simple retransmission
scheme with exponential backoff). NOTIFY.

5 Presence Event Package

The request MAY be sent to a local outbound proxy (a local outbound
proxy is a device similar to SIP event framework [3] defines an http proxy; it receives requests
which are not destined abstract SIP extension for itself,
subscribing to, and then forwards them towards receiving notifications of, events. It leaves the
final destination), or MAY be sent directly
definition of many additional aspects of these events to the server concrete
extensions, also known as event packages. This extension qualifies as
an event package. This section fills in the
domain specified in information required by
[3].

5.1 Package Name

The name of this package is "presence". This name MUST appear within
the Event header in SUBSCRIBE request URI. and NOTIFY request. This is identical to baseline
SIP. Local outbound proxies are RECOMMENDED in order to provide
domain-based third party signatures (i.e., resign
section also serves as the request with a
key IANA registration for the entire domain). These proxies SHOULD perform proxy
authentication, verifying the identity event package
"presence".

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

Example:

Event: presence

5.2 SUBSCRIBE bodies

The body of a SUBSCRIBE request MAY contain a body. The purpose of
the originator, before
resigning.

Proxies forward body depends on its type. In general, subscriptions will normally
not contain bodies. The request URI, which identifies the message according to configured routing logic presentity,
combined with DNS SRV record procedures. Pre-established security
associations MAY be used, or SAs MAY be established on demand. The
SAs themselves SHOULD be based on IPSec ESP in transport mode [7] to
provide privacy services for instant messages. Keys the event package name, are sufficient for ESP MAY user
presence.

We anticipate that document formats could be
established administratively. If administrative keys are not
available, IKE is used defined to act as
filters for key exchange [8]. If a proxy receives a
request subscriptions. These filters would indicate certain user
presence events that does not arrive over a SA, it MAY reject the request.
This decision is based on would generate notifies, or restrict the local security policy set of
data returned in NOTIFY requests. For example, a presence filter
might specify that the proxy.

Each proxy adds its address to notifications should only be generated when
the Via header as it forwards status of the
request. Proxies MAY users instant message inbox changes. It might also record route; this means
say that they can
request to receive all subsequent messages for the same Call-ID. By
not record-routing, proxies will see content of these notifications should only contain the initial request they
forward; all subsequent requests in the same session will bypass the
proxy, and go
IM related information.

5.3 Expiration
User presence changes as a result of events that include:

o Turning on and off of a more direct path between cell phone

o Modifying the end systems. Record-
routing is done by inserting registration from a header into softphone

o Changing the forwarded request
(called Record-Route) which contains status on an instant messaging tool

These events are usually triggered by human intervention, and occur
with a frequency on the address order of minutes or hours. As such, it is
subscriptions should have an expiration in the proxy. Like
the Via headers, Record-Route has a "stack" property, since proxies
"push" values into middle of this range,
which is roughly one hour. Therefore, the message. The entire Record-Route stack default expiration time for
subscriptions within this package is
reflected in 3600 seconds. As per [3], the response to
subscriber MAY include an alternate expiration time. Whatever the SUBCRIBE, but unlike Via, no
addresses are "popped" in
indicated expiration time, the response. In this fashion, both sender
and recipient server MAY reduce it but MUST NOT
increase it.

5.4 NOTIFY Bodies

The body of the SUBSCRIBE have notification contains a list presence document. This
document describes the user presence of the message path for
subsequent requests. This path list is built into a Route header by presentity that was
subscribed to. All subscribers MUST support the end systems, presence data format
described in [fill in with IMPP document TBD], and placed MUST list its MIME
type, [fill in subsequent requests. The Route with MIME type] in an Accept header
is like a loose source route present in IP, and specifies the path that the
request should take. Record-routing gives each proxy the capability
to independently decide
SUBSCRIBE request.

Other presence data formats might be defined in the right trade off of scale (achieved by not
record routing) and services (generally achieved by record routing).
Proxies which are aware future. In that they are behind a firewall,
case, the subscriptions MAY indicate support for example,
can record-route, ensuring that messages from inside to outside other presence
formats. However, they MUST always come from the proxy.

Eventually, the SUBSCRIBE request is forwarded to a proxy which is
co-located support and list [fill in with a registrar. A registrar is
MIME type of IMPP presence document] as an entity in SIP that has
dynamic application layer routing information. When a client starts
up, they send allowed format.

Of course, the registrar a REGISTER request that binds an address
in notifications generated by the domain presence agent MUST be
in one of the registrar to formats specified in the address of Accept header in the machine they are
residing on. Continuing with SUBSCRIBE
request.

5.5 Processing Requirements at the example above, PA

User presence is highly sensitive information. Because the proxy for
engineering.example.com receives
implications of divulging presence information can be severe, strong
requirements are imposed on the request for Joe. Joe had
formerly registered a binding from sip:joe@engineering.example.com PA regarding subscription processing,
especially related to
sip:joe@mypc.engineering.example.com, which contains the FQDN authentication and authorization.

A presence agent MUST authenticate all subscription requests. This
authentication can be done using any of the
host Joe mechanisms defined for
SIP. It is using. In fact, not considered sufficient for the binding established by a REGISTER can
be one authentication to many, so be
transitive; that a user can indicate is, the ability to authentication SHOULD use an end-to-end
mechanism. The SIP basic authentication mechanism MUST NOT be
contacted at multiple hosts (laptop, PDA, cell phone). This
information used.

It is fundamentally presence. For RECOMMENDED that any subscriptions that reason, are not authenticated
do not cause state to be established in the
proxy/registrar PA. This can elect to act as be
accomplished by generating a PA 401 in response to the SUBSCRIBE, and
then discarding all state for this subscription. A
proxy/registrar which can act as that transaction. Retransmissions of
the SUBSCRIBE generate the same response, guaranteeing reliability
even over UDP.

Furthermore, a PA is known as MUST NOT accept a presence server.

Before accepting the subscription, the presence server will generally
need to obtain subscription unless authorization from the principal. This extension does
not specify how
has been provided by the presence server would obtain presentity. The means by which authorization from
are provided are outside the principal. scope of this document. Authorization can be
may have been provided ahead of time through access lists, perhaps
specified in a web configuration, for example. Another approach 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 [5],
RADIUS [6], or COPS [7], can also be used. It is also useful to obtain be
able to query the user for authorization at following the time receipt of the subscription. One approach a
subscription request for such which no authorization is defined in information was
present. Appendix A provides a separate document [9]. If possible solution for such a scenario.

The result of the authorization decision by the server will be
reject, accept, or pending. Pending occurs when the server cannot
obtain authorization at this time, and may be obtained able to do so at a
later time, when the time of subscription, presentity becomes available.

Unfortunately, if the presence server
can return a 202 (Accepted) response, which indicates informs the subscriber that the
subscription might have been accepted. When authorization is finally
obtained (because the principal becomes online and is queried once
again for authorization), the presence server can then enable pending, this will divulge information about the
subscription
presentity - namely, that they have not granted authorization and begin generation of notifications for it.

Instead of acting as are
not available to give it at this time. Therefore, a PA, PA SHOULD
generate the presence server can act as a proxy same response for
a subscription, both pending and forward it to accepted
subscriptions. This response SHOULD be a presence client. A presence
client makes itself known to 202 Accepted response.

If the presence server by registering
(using SIP REGISTER) a Contact address informs the subscriber that includes the methods tag
of "SUBSCRIBE". The tag subscription is defined in
rejected, this also divulges information about the caller preferences
specification [3]. This specification allows, among other things, for
clients to indicate in a REGISTER presentity -
namely, that they would prefer to receive
messages with specific methods. Proxies receiving requests with a
particular method forward it to the contact address which has
indicated it can handle that method. This allows for a user with a
single SIP address to use separate user agents for presence and for
other communications. Alternatively, users can use have explicitly blocked the same user
agents for both.

An example registration using subscription
previously, or are available at this tag looks like:

REGISTER sip:dynamicsoft.com SIP/2.0
Via: SIP/2.0/UDP mypc.dynamicsoft.com
To: sip:jdrosen@dynamicsoft.com
From: sip:jdrosen@dynamicsoft.com
Call-ID: asidhasd@1.2.3.4
CSeq: 39 REGISTER
Contact: sip:jdrosen@pua-pc.dynamicsoft.com;methods="SUBSCRIBE"
Contact: http://www.cs.columbia.edu/~jdrosen
Content-Length: 0

One of time and chose to decline the Contact headers contains
subscription. If the SUBSCRIBE value in policy of the
methods tag. The presence server can therefore forward the request is not to
that address. If there are no registrations divulge this
information, the PA MAY respond with a 202 Accepted response even
though the methods tag subscription is rejected. Alternatively, if the policy of
"SUBSCRIBE", there are no presence clients, and
the presence server
SHOULD assume presentity or the role of PA.

In fact, it PA is possible that two different presence clients register
for it is acceptable to inform the same presentity. In this case,
subscriber of the presence server, acting as rejection, a proxy, may fork the SUBSCRIBE, which means it sends multiple copies
of 603 Decline SHOULD be used.

Note that since the request, one response to each presence client. Each client will
presumably query its principal a subscription does not contain any
useful information about whether the subscription presentity, privacy and integrity of
SUBSCRIBE responses is
acceptable. In the common case where not deemed important.

5.6 Generation of Notifications

Upon acceptance of a principal has left their
presence tool running at work, and then gone home and started subscription, the
tool there, PA SHOULD generate an
immediate NOTIFY with the principal will accept current presence state of the subscription at home. This
causes presentity.

If a success response to be generated, subscription is received, and forwarded to the
presence server (which is acting marked as a proxy), and then back to the
subscriber. The presence tool at home then assumes responsibility for
that subsription. The tool at work can continue to support
subscriptions it received previously.

Independently of whether pending or was
rejected, the PA resides in the presence server or
presence client, if a SUBSCRIBE request arrives and is acceptable, SHOULD generate an immediate NOTIFY. This NOTIFY
should contain a
200 OK response is generated, and the PA stores valid state for the
subscription. The 200 OK response contains a copy of the current
presence state of presentity, yet be one which
provides no useful information about the presentity. The 200 OK response An example of
this is to the
SUBSCRIBE listed above might look like:

SIP/2.0 200 OK
Via: SIP/2.0/UDP presenceserver.dynamicsoft.com
Via: SIP/2.0/UDP userpc.example.com
To: sip:jdrosen@dynamicsoft.com
From: sip:user@example.com
Contact: sip:user@userpc.example.com
Record-Route: sip:jdrosen@example.com;maddr=presenceserver.dynamicsoft.com
Expires: 3600
Call-ID: knsd08alas9dy@3.4.5.6
CSeq: 1 SUBSCRIBE
Content-Type: application/xpidf+xml
Content-Length: 287

<?xml version="1.0"?>
<!DOCTYPE presence
PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd">
<presence>
<presentity uri="sip:jdrosen@dynamicsoft.com;method="SUBSCRIBE">
<atom id="779js0a98">
<address uri="sip:jdrosen@dynamicsoft.com;method=INVITE">
<status status="open"/>
</address>
</atom>
</presentity>
</presence>

Notice provide an IM URL that is the response has mirrored many fields from the request,
including same form as the To, From, Call-ID, CSeq, presence
URL, and Via headers. The PA has
also added a Contact header, providing an mark that IM address where it can be
reached. as "not available". The response also contains a Record-Route header. This
header was presumably inserted by the proxy (the address in the maddr
header reason for this
process of "lying" is that of a presence server acting as without it, a proxy), and is
reflected in subscriber could tell the 200 OK response. The response also contains
difference between a
presence document for the presentity, pending subscription and a Contact header. The
Contact headers in a response to SUBSCRIBE list all the current
addresses which have been subscribed.

A an accepted
subscription is uniquely defined by the combination of based on the Call-ID,
To, existence and From header fields in the SUBSCRIBE. Subscriptions are soft-
state; they must be refreshed periodically by the subscriber in order
to remain active. The Expires header in the 200 OK response is used
to indicate the lifetime content of the subscription; the subscriber must
resend the subscription before then, or it is deleted from the PA.

When an immediate
NOTIFY. The approach defined here ensures that the presence information for the presentity changes, the PA
generates delivered
in a NOTIFY request for each subscriber. Recall that generated by a PA pending or rejected subscription is
assumed to know about all changes in the presence information for also a
presentity; it will know this either because it is co-located with
the PUA, otherwise it is co-located with the registrar, and will
learn about changes in presence information from REGISTER requests.
The NOTIFY request is routed using the Record-Route and Contact
headers obtained from the subscription, as is done
valid one that could have been delivered in baseline SIP.
For example, the PA will generate a NOTIFY that looks like this:

NOTIFY sip:user@userpc.example.com
Via: SIP/2.0/UDP pua-pc.dynamicsoft.com
To: sip:user@example.com
From: sip:jdrosen@dynamicsoft.com
Contact: sip:jdrosen@pua-pc.dynamicsoft.com
Route: sip:user@userpc.example.com;maddr=userpc.example.com
Call-ID: knsd08alas9dy@3.4.5.6
CSeq: 1 NOTIFY
Content-Type: application/xpidf+xml
Content-Length: 290

<?xml version="1.0"?>
<!DOCTYPE presence
PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd">
<presence>
<presentity uri="sip:jdrosen@dynamicsoft.com;method="SUBSCRIBE">
<atom id="779js0a98">
<address uri="sip:jdrosen@dynamicsoft.com;method=INVITE">
<status status="closed"/>
</address>
</atom>
</presentity>
</presence>

This NOTIFY is sent to generated by an
accepted subscription.

If the presence server
(presenceserver.dynamicsoft.com) because policy of the maddr parameter in
the Record-Route. The presence server receives this, and sees the
Route header. It removes the Route header, places the URI
sip:user@userpc.example.com into or the Request URI, and sends presentity is that it is
acceptable to divulge information about whether the
IP address corresponding to the maddr parameter, in this case, also
userpc.example.com. In this way, subscription
succeeded or not, the immediate NOTIFY takes the same path as
the SUBSCRIBE took.

As an optimization, notifications do not need to not be sent if the
subscriber is not actually online. This improves scalability.

When a client wishes to fetch the current communications state of a
user, it generates a SUBSCRIBE request, with an Expires header with
time 0 (that is, for pending
or rejected subscriptions.

Of course, once a subscription which immediately expires). Once it
hits the PA, a 200 OK response is generated (assuming authorization
exists) containing accepted, the current presence state. The subscription is
then immediately expired. The result is a fetch of presence
information without generation of PA SHOULD generate a subscription. Note that since
fetch is accomplished using SUBSCRIBE, the same security mechanisms
and authorization requirements are used
NOTIFY for both.

5 Subscriptions

This section defines detailed syntax and semantics associated with
subscriptions.

5.1 Generating subscriptions

Subscription is accomplished using the new SUBSCRIBE method, defined
below.

Subscribe = "SUBSCRIBE"

Like all SIP method names, the SUBSCRIBE method name is case
sensitive. SUBSCRIBE is used subscription when a subscriber wishes to receive
asynchronous notifications about events generated by some object.
These events can be changes in it determines that the presence
state of the object, or any other
type of event. The address of the object is placed by the subscriber
in the To header and also presentity has changed. Section 6 describes how the request URI. The body PA
makes this determination.

For reasons of the SUBSCRIBE
method MAY contain information privacy, it will frequently be necessary to limit encrypt
the set contents of events for which
notifications are sent, or otherwise provide modifiers to the
subscription. If no body is present, all events generated by the
object cause notifications.

In its application to presence of people, the object is actually a
presentity, and its address is the SIP URL for the presentity.

Tables 1 and 2 extend tables 4 and 5 of SIP with two additional
columns, defining the headers that This can be used in accomplished using the SUBSCRIBE and
NOTIFY requests and responses.

Subscriptions are soft-state, and must be periodically refreshed.
standard SIP encryption mechanisms. The
refresh interval is suggested by the client in the SUBSCRIBE request
(using encryption should be
performed using the Expires header) and key of the actual value returned subscriber as identified in the
SUBSCRIBE response in From
field of the Expires header; see Section 6.20 SUBSCRIBE. Similarly, integrity of SIP. If
no value is present, the default notifications is one hour. The response
important to subscribers. As such, the
subscription MUST contain an Expires header indicating the actual
expiration contents of the subscription. This time will never be later than
the time offered in the request, if it is offered. The subscription notifications
SHOULD be refreshed before this expiration of the client still
desires the subscription to be valid.

A SUBSCRIBE request MUST contain a To header, identifying the logical
identity authenticated using one of the user or object who is being subcribed to (i.e., standardized SIP mechanisms.
Since the
where enc. e-e SUBSCRIBE NOTIFY
___________________________________________________
Accept R e o o
Accept 415 e o o
Accept-Encoding R e o o
Accept-Encoding 415 e o o
Accept-Language R e o o
Accept-Language 415 e o o
Allow 200 e o o
Allow 405 e m m
Authorization R e o o
Authorization r e o o
Call-ID gc n e m m
Contact R e m o
Contact 2xx e m o
Contact 3xx e o o
Contact 485 e o o
Content-Encoding e e o o
Content-Length e e m m
Content-Type e e * *
CSeq gc n e m m
Date g e o o
Encryption g n e o o
Expires g e o o
From gc n e m m
Hide R n h o o
Max-Forwards R n e o o
Organization g c h o o

Table 1: Summary of header fields, A--O

address of the presentity).

A SUBSCRIBE request, of course, MUST contain a Request-URI. For
requests are generated by a UAC, this SHOULD be identical to the To
field. As the SUBSCRIBE request traverses proxy servers, the
Request-URI is rewritten presence server, which may not
have access to the address of the subscribed-to entity
as known in the next-hop server.

A SUBSCRIBE request MUST contain a Call-ID header (simply an opaque
identifier) and a From header. The From header contains logical
identity key of the user requesting represented by the subscription. Generally, this is
a SIP URL, although it need not be. Note that as a logical
identifier, presentity, it
will generally not contain a complete hostname, such
as sip:user@pc10.engineering.example.com, but rather contain a
logical name, such as sip:user@example.com.

where enc. e-e SUB NOTIFY
__________________________________________________________
Priority R c e - -
Proxy-Authenticate 407 n h o o
Proxy-Authorization R n h o o
Proxy-Require R n h o o
Record-Route R h o o
Record-Route 2xx,401,484 h o o
Require R e o o
Retry-After R c e - -
Retry-After 404,413,480,486 c e o o
500,503 c e o o
600,603 c e o o
Response-Key R c e o o
Route R h o o
Server r c e o o
Subject R c e - -
Timestamp g e o o
To gc(1) n e m m
Unsupported 420 e o o
User-Agent g c e o o
Via gc(2) n e m m
Warning r e o o
WWW-Authenticate R c e o o
WWW-Authenticate 401 c e o o

Table 2: Summary of header fields, P--Z; (1): copied with possible
addition of tag; (2): UAS removes first Via header field

A subscription is uniquely identified by the combination of the To,
Call-ID and the From field in the SUBSCRIBE request. Refreshes of
subscriptions SHOULD reuse the same Call-ID if possible, since
subscriptions are uniquely identified at presence servers using the
Call-ID. Two subscriptions from frequently be the same user, for case that the same user, but
with different Call-IDs, NOTIFY are considered different subscriptions. We
anticipate signed by a third
party. It is RECOMMENDED that reuse of the same Call-ID will not signature be possible
through reboot cycles. This is acceptable, however. The soft-state
nature by an authority over
domain of subscriptions will cause the old one to expire. Note this
is exactly the same as usage of Call-ID in registrations.

A SUBSCRIBE request MUST contain a CSeq header. As specified in [2],
The CSeq header MUST increment for each subsequent request presentity. In other words, for the
same To, From, and Call-ID field (thus, the CSeq in each refresh MUST
increase). The CSeq header uniquely identifies and orders each
refresh of a particular subscription.

A SUBSCRIBE request MUST contain a Via header, formatted as defined
in RFC 2543 [2]. Via headers are used to properly forward the
response to the SUBSCRIBE.

A SUBSCRIBE request MUST contain a Contact header. This indicates user
pres:user@example.com, the
address(es) (as a SIP URL) to which signator of the client would like to receive
notifications. This MUST be NOTIFY SHOULD be one or more SIP addresses, containing the fully qualified domain names
authority for the host generating the
subscription, or the IP address example.com.

5.7 Rate Limitations on NOTIFY

For reasons of the host generating the
subscription. Other addresses are possible, supporting third party
subscriptions. If congestion control, it contains multiple addresses, notifications will
be sent to each address. If no Contact header is present, no important that the rate of
notifications will be sent.

The SUBSCRIBE request MAY contain not become excessive. As a body, and when present, result, it is RECOMMENDED
that the
Content-Length, Content-Type, and Content-Encoding are used as
specified in [2]. There are many applications PA not generate notifications for bodies within a
SUBSCRIBE request - for example, providing more detailed information
about what the subscription is for. Derivation of semantics of the
purpose of the body is based on the Content-Type and Content-
Disposition headers.

A SUBSCRIBE request MAY contain an Accept header, indicating the
allowed presence description formats which may be returned in single presentity at a
notification. When not present, the server assumes only the
lightweight presence format [10] is supported.

This extension does NOT neccessitate the use of either Require or
Proxy-Require. These headers SHOULD NOT be present unless some other
extensions are needed beyond this one.

Usage of the other headers specified as optional in Tables 1 and 2 is
defined in [2].

5.2 Sending subscriptions

The
rate faster than once every 5 seconds.

5.8 Refresh Behavior

Since SUBSCRIBE request MAY be sent directly to the server identified
in the Request URI. Alternatively, it can be sent to a local outbound
proxy server. Usage of local outbound proxies is RECOMMENDED with
presence in order to provide security features.

An example subscription message looks like:

SUBSCRIBE sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP myhost.example.com
From: Professor Smith <sip:professor@university.edu>
To: Joe User <sip:user@example.com>
Contact: sip:professor@mypc.university.edu
Call-ID: 986sdo909y66555@12.33.4.5
CSeq: 4937872 SUBSCRIBE
Accept: text/uri-list, text/xml-presence

5.3 Proxying subscriptions

Proxies forward SUBSCRIBE requests routed by proxies as they would any other request.
The result method, it is
possible that the SUBSCRIBE eventually arrives at a server where
the user is registered. Section 5.4 outlines processing in these
servers.

5.4 Presence server processing of SUBSCRIBE

This section outlines the processing of a new subscription request
for a presentity served by a presence server.

When a SUBSCRIBE request arrives, the presence server SHOULD send a
100 Trying response. might fork. The next job of the presence server result is to determine if that it will might
arrive at multiple devices which are configured to act as a proxy PA for this subscription, or as a PA. Once this determination is
made, processing follows Section 5.3 in
the case same presentity. Each of these will respond with a proxy, and
Section 5.5 in 202 response
to the case of a PA.

If SUBSCRIBE. Based on the presentity identified forking rules in the request URI has at least one
registered Contact that indicates support of the SUBSCRIBE method,
the presence server MAY proxy the request, or MAY act as a PA. If no
Contacts are registered for the presentity, or if there are Contacts,
but none indicate support for the SUBSCRIBE method, the presence
server SHOULD assume the role of PA.

If there was more than one Contact which indicated support of the
SUBSCRIBE method, the proxy MAY fork the request (that is, send the
subscription to more than SIP, only one PA). Standard SIP processing, as
defined in Section 12.4 of RFC2543 [2],
these responses is used passed to collect responses
and send a single response upstream, towards the subscriber.
Basically, However, the algorithm specified subscriber
will result in a 200 OK being
forwarded upstream if any of the presence clients responded with a
200 OK. If more than one presence client responded with a 200 OK,
only one of them is forwarded upstream. Note that this may cause
multiple PAs to generate receive notifications for the same presentity. This
is acceptable; from each of those PA is generating which accepted the same information.
subscriptions. The
redundant information is discarded at the subscriber [11].

If the presence server was formerly acting as a PA for a subscription
(in other words, the presence server was a PA for a subscription with
the same Call-ID, To, and From field, but different CSeq), but is now
a proxy, SIP event framework allows each package to define
the presence server MUST cease acting as PA handling for this
subscription if the proxied request generates a final response,
unless that final response is 405 (Method not Allowed) (which means
the presence client isn't actually a presence client, since it
doesn't support SUBSCRIBE).

It case.

The processing in this case is possible for the role of PA to migrate from presence server identical to
presence client dynamically. Consider first the case of a presence
server acting as a PA, because there were no presence clients
available. At some point, the presence client comes online (known way INVITE would be
handled. The 202 Accepted to the presence server through a registration). When the subscription is
next refreshed, SUBSCRIBE will result in the presence server can act as a proxy instead
installation of a
PA, and forward the subscription to the presence client. This
terminates state in the subscriber. The
subscription on is associated with the server, To and allows it to become
active on the presence client. By transferring subscriptions on
refreshes, handling of subscriptions to gradually transition From (both with tags) and
Call-ID from a
presence server to a presence client.

The role of presence server migrates back in much the same way. 202. When notifications arrive, those from the presence client goes offline (by unregistering PA's
whose 202's were discarded in the Contact
address with forking proxy will not match the methods="SUBSCRIBE" tag),
subscription refreshes
will now terminate ID stored at the presence server, causing the presence
server subscriber (the From tags will differ).
These SHOULD be responded to act as with a PA for those subscriptions. 481. This will cause the
subscriptions to gradually become active at the presence server.

As an optimization, the presence server can cache disable the active
subscriptions at the client. This is done by observing the SUBSCRIBE
requests, and the 200 OK responses, which pass by the presence server
(which is acting as a proxy). When the presence client goes offline, from those PA. Furthermore, when refreshing the presence server can simply instantiate
subscription, the cached subscriptions
immediately. Note that caching refresh SHOULD make use of subscriptions imposes a security
risk unless the presence server can authenticate and verify tags from the
integrity of SUBSCRIBE requests 202
and their responses.

5.5 Presence agent processing make use of SUBSCRIBE

The presence agent MAY authenticate the request (using a 401
response, NOT 407, since the PA is a user agent in SIP terminology).

Once authenticated, the PA determines if this is a subscription
refresh, any Contact or a new subscription. If Record-Route headers in order to
deliver the Call-ID, To, and From field
match that of an existing subscription, SUBSCRIBE back to the subscription is a
refresh. Otherwise, it is a new subscription.

5.5.1 Refreshes
A same PA MAY reject a refresh if it determines that sent the subscription is
no longer acceptable (for example, if the subscription was permitted
on a timed basis). In 202.

The result of this case, the subscription is removed from the
system, and a 6xx class response is sent. Note that a 4xx or 5xx
error response MUST NOT cause the subscription to presentity can have multiple PAs active,
but these should be removed from the
system.

The remainder of the discussion on refreshes assumes homogeneous, so that the
subscription is still acceptable.

Each notification address (as indicated in the Contact header), is
independently refreshed. This allows different expiration times for
different notification addresses. Differing expiration times each can be
indicated using generate the expires parameter same
set of the Contact header, just as
is done notifications for registrations [2].

When a presence agent receives a subscription refresh, it updates the
expiration time of presentity. Supporting heterogeneous
PAs, each notification address in the subscription. As
with the initial subscription, the server MAY lower the amount of
time until expiration, but MUST NOT increase it. The final expiration
time is placed in the Expires header in the response, or into the
expires parameters of the Contact headers in the response. The 200 OK
response SHOULD also contain a copy of the current presence state of
the presentity, in a format listed in the Accept header of the
SUBSCRIBE, else the Light Presence Information Data Format (LPIDF)
[10] if no Accept header is present. If the Accept header was present
but empty, no presence information is placed in the response.

If no refresh which generated notifications for a notification address is received before its
expiration time, that address is removed from the list subset of addresses.
If all notification addresses are removed, the entire subscription is
deleted.

5.5.2 New subscriptions

The
presence server first determines if the subscriber is authorized.
How such authorization is determined data, is outside the scope of this
document. Authorizations may have been pre-granted by the presentity
or the system administrator. Alternatively, when the subscription
arrives, the PA may query the user complex and difficult to determine if authorization is
permitted. Such querying is straightforward in the case of a PA co-
resident with a PUA (in which case manage. If such a screen pop or something else feature
is needed, it can be used). In the case of a PA co-resident accomplished with a proxy/registrar, B2BUA rather than through a
remote authorization protocol, such as [9], or even the Common Open
Policy Service (COPS) [12] can be used.

If authorization was refused, the request SHOULD be rejected with
forking proxy.

6 Publication

The user presence for a
600 class response. If authorization could not presentity can be obtained (for
example, because the principal was offline or not available), the PA
SHOULD generate from any number of
different ways. Baseline SIP defines a 202 response. This response tells the subscriber method that the subscription is pending. The PA may reattempt authorization
at a later time, possibly when the principal comes back online. See
[9], which describes a SIP extension that can be used for
authorization of users. The subscriber SHOULD refresh the
subscription as per a 200 response. The subscriber knows by all SIP
clients - the
subscription is accepted when either (1) a NOTIFY for that
subscription appears, or (2) a refresh generates REGISTER method. This method allows a 200 response.

If authorization has been granted, the PA MUST respond UA to SUBSCRIBE
with inform a 200 OK response. The response MUST contain an indication of
expiration time for each notification address in the SUBSCRIBE. The
200 OK response SHOULD also contain a copy
SIP network of the its current presence
state of the presentity, in a format listed in the Accept header of
the SUBSCRIBE, else the Light Presence Information data Format
(LPIDF) [10] if no Accept header is present. If the Accept header was
present but empty, no presence information is placed in the response.

The PA MAY sign the 200 OK response.

The PA also instantiates a subscription communications addresses (ie., Contact
addresses) . Furthermore, multiple UA can independently register
Contact addresses for the subscriber. The
subscription is indexed by the Call-ID in the SUBSCRIBE and the URI
in the From field (including the tag). The PA generates Route headers
(using the same SIP URL. These Contact and Record-Route headers from the request) to addresses can
be
used for sending notifications. These Route headers are constructed
exactly as if SIP URLs, or they can be any other valid URL.

Using the SUBSCRIBE request were an INVITE. The Route headers
are stored register information for use in subsequent notifications.

5.6 Subscriber processing of SUBSCRIBE response

The subscriber will receive a single final response to the SUBSCRIBE
request. If this response is a 600 class response, the subscription
request has been denied. If the response presence is a 200 class response, the
subscription has been accepted. straightforward. The response may contain the current
presence state
address of record in the REGISTER (the To field) identifies the
presentity. The 200 OK response will contain
expiration information (either in an Expires header, and/or in the
expires parameter of Contact headers in the 200 OK response)
indicating when the subscription expires. The subscriber MUST refresh define communications addresses that
describe the subscription before an expiration time if it wishes to continue
to receive notifications to state of the address with that expiration. presentity. The
SUBSCRIBE response will also contain Record-Route headers; these are
used to build a Route header set for use in subsequent subscription
refreshes. The construction of the Route headers follows those SIP caller
preferences extension [8] is RECOMMENDED for a
200 OK response to INVITE as documented in RFC2543 [2], except use with UAs that
Contact headers are not included in the processing.

SUBSCRIBE is like REGISTER,
interested in that the Contact headers
don't refer to signaling addresses, but rather notification
addresses. Unlike REGISTER, a Route needs to be built for
SUBSCRIBE, and this Route should not include presence. It provides additional information about the
Contact
headers.

To refresh the subscription, the subscriber contructs a new SUBSCRIBE
request. The Call-ID, To, and From in this request MUST match those
of the previous SUBSCRIBE request. The CSeq header MUST be higher
than addresses that of the previous SUBSCRIBE request. The Via header is
constructed as described in 5.2. The request MUST contain the Route
header constructed from the response can be used to the initial SUBSCRIBE. The
request MAY contain Accept, Content-Length, Content-Type, and
Content-Encoding headers as described in Section 5.2. The request URI
is constructed from the Route headers, as defined in RFC2543 [2]. construct a richer presence
document. The
request is then sent to the server in the request URI.

As long as the subscription remains active, the subscriber will
receive notifications "description" attribute of presence state from the PA.

5.7 Unsubscribing

A subscriber may unsubscribe by sending a SUBSCRIBE request with an
Expires header of 0. The Contact header indicates the particular
address that is being unsubscribed. This MAY be a *, indicating that
all Contacts for that particular subscription (as identified by the
Call-ID, To, and From) are
explicitly defined here to be removed. If all Contacts are
removed, the PA deletes the subscription.

5.8 Fetching

Fetching is similar to a subscribing, in that it returns the current
presence state. However, no notifications are sent for future changes
in the presence state. Rather than inventing a new method for this,
it is readily accomplished with used as a SUBSCRIBE along with an Expires: 0
header and no Contact header. The absence of any Contact header is
what distinguishes it from the similar operation of unsubscribing.
The advantage of using SUBSCRIBE is free-form field that the server can simply
process the request independently of whether its allows a fetch or longer
lived subscription; the authorization and processing steps are
identical. The only difference is whether an actual subscription is
instantiated for the
user or not.

This parallels how fetching of registrations is done in SIP. Note
that fetching has no effect on existing subscriptions.

6 Publication
Publication is the process by which presence information is uploaded
from the presence user agents to the presence agent. The information
uploaded through publications is the content used to formulate
presence documents distributed through notifications.

Publication can be done using any number of means, including
proprietary protocols. There are many cases where this is both
necessary and desirable.

However, we define a standard mechanism for publication of presence
information from a PUA to a presence server. This mechanism is
entirely based on the existing SIP registration and caller
preferences specifications [3]. Simply put, the Contact headers
placed in registrations are the presence information published by the
presence user agents. The caller preferences extension provides a
large set of parameters which can be used to provide additional
information, beyond location, which provided by SIP REGISTER.

Usage status of REGISTER to publish presence information has several
important features:

o It supports communications means represented by any URL
scheme, including HTTP and SMTP.

o It supports distributed presence information, whereby multiple
PUAs can independently update state for different
communications addresses for the same presentity.

o It supports third party updates, so that one entity can update
presence state for another.

o Caller preferences allows for relative weights to be assigned
to the addresses.

o Caller preferences allows for arbitrary characteristics to be
assigned to the addresses.

o Caller preferences allows for descriptions to contain
arbitrary text presentity at that can be used for notes. communications
address.

We also allow REGISTER requests to contain presence documents, so
that the PUAs can publish more complex information.

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
not require get-before-set, since the SIP register mechanism works in
such a way that data can be updated without a get.

The application of registered contacts to presence increases the
requirements for authenticity. Therefore, REGISTER requests used by
presence user agents SHOULD be authenticated using either SIP
authentication mechanisms, or a hop by hop mechanism.

7 Notification

Notification is

To indicate presence for instant messaging, the process UA MAY either
register contact addresses that are SIP URLs with the "methods"
parameter set to indicate the method MESSAGE, or it MAY register an
IM URL.

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

6.1 Migrating the PA Function

It is done by a PA.

7.1 When important to send

Notifications are sent when realize that the state of PA function can be colocated with
several elements:

o It can be co-located with the presentity changes, and
that state change is one proxy server handling
registrations for which a notification is desired.
Notifications SHOULD the presentity. In this way, the PA knows
the presence of the user through registrations.

o It can be sent in co-located with a timely fashion after PUA for that presentity. In the state has
changed. Description
case of a single PUA per presentity, the cases in which state changes should
trigger notifications is handled by subscription documents
transmitted in SUBSCRIBE requests. If no such document was present, PUA knows the PA SHOULD assume that all state changes are reported. Similarly,
the subscription document describes the subscribers preferences for
of the detailed content present presentity by sheer nature of its co-location.

o It can be co-located in any proxy along the notification. The actual data
sent would be computed through call setup path.
That proxy can learn the intersection requested content,
and presence state of the content authorized presentity by the subscribed party
generating its own SUBSCRIBE in their access
controls. order to determine it. In this
case, the absense of PA is effectively a subscription document, B2BUA.

Because of the soft-state nature of the subscriptions, it is assumed
that becomes
possible for the subscriber wants all data.

As an important optimization, a PA MAY elect not to send a notify function to
a subscriber if it knows that migrate during the subscriber lifetime of a
subscription. The most workable scenario is not available to
receive notifications. This can be known by having for the PA subscribe function to
migrate from the subscriber. In particular, the ability to receive
notifications represents another piece of presence state which can be
uploaded in a REGISTER, server to the PUA, and discovered through back.

Consider a SUBSCRIBE. For
example, if userA subscribes to userB, userA would include, subscription that is installed in its
registrations, an address a presence server.
Assume for the moment that indicates its ability to receive
NOTIFY requests:

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP userApc.example.com
To: sip:userA@example.com
From: sip:userA@example.com
Call-ID: 8ynllz9a6ajsda009@9.8.7.6
CSeq: 1 REGISTER
Contact: sip:userA@userApc.example.com;methods=NOTIFY
Content-Length: 0
If userB also subscribes to userA, userB would be aware the presence server can determine that a
downstream UA is capable of this
communications address acting as a PA for notifications. It could then match it
against the notification addresses in the presentity. When a
subscription from userA, refresh arrives, the PA destroys its subscription, and determine whether
then acts as a notification address was currently active.

We anticipate that most subscriptions will be symmetric, that is, A
subscribes to B and B subscribes to A. In this case, no extra
subscriptions are required proxy for this optimization.

Note that this optimization is likely to work only when notifications
are sent by clients. This is because presence servers are not likely
to be privy to presence state of the subscribers.

7.2 Formatting of NOTIFY subscription. The generation of notifications subscription is relatively straightforward. then
routed to the UA, where it can be accepted. The
presence data result is constructed based on rules outside of that the scope of
subscription becomes installed in the PUA.

For this document. Note that migration to work, the entity generating a notification PUA MUST
use a presence format listed among those be prepared to accept
SUBSCRIBE requests which already contain tags in the Accept header in To field.
Furthermore, the
SUBSCRIBE request. If not present, PUA MUST insert a Contact header into the Lightweight Presence
Information Data Format (LPIDF) [10] type is assumed.

The NOTIFY 202, and
this header MUST contain be used by the same Call-ID as subscriber to update the SUBSCRIBE contact
address for which
it is acting as a notification. The From field MUST match the To
field subscription.

TODO: Does this work? What about getting a Record-Route in place at
the SUBSCRIBE, and PUA. This might only be possible for refreshes that don't use
Route or tags.

The presence server determines that a PUA is capable of supporting a
PA function through the To field MUST match REGISTER message. Specifically, if a PUA
wishes to indicate support for the From field PA function, it SHOULD include a
contact address in
the its registration with a caller preferences
"methods" parameter listing SUBSCRIBE. The From field MUST contain

7 Mapping to CPIM

This section defines how a tag, which allows SIP for
notifications from presence server and PUA messages are converted to be distinguished, as
far as SIP transaction processing
CPIM, and how a CPIM messages are concerned.

For converted to SIP experts - this represents a slightly different
operation than for INVITE. When presence. SIP
to CPIM conversion occurs when a user SIP system sends an INVITE,
they will receive a 200 OK with a tag. Requests in the
reverse direction then contain SUBSCRIBE request
that tag, and contains a pres URL or SIP URL that tag only,
in the From field. Here, the response corresponds to SUBSCRIBE may
contain a tag user in the To field, and a NOTIFY will contain
domain that runs a
tag in the From field. However, different presence protocol. CPIM to SIP involves
the UA may receive NOTIFY
requests with tags case where a user in the From field a different protocol domain generates a
subscription that do not match the
tag is destined for a user in a SIP domain.

Note that the 200 OK received to process defined below requires that the initial SUBSCRIBE. gateway store
subscription state. This unfortunate result is because only a single 200 OK is returned to a SUBSCRIBE
request, as opposed due to multiple 200 OK for INVITE. Thus, the UA MUST be prepared need to receive NOTIFYs with many
different tags, each
remember the Call-ID, CSeq, and Route headers for subscriptions from a different PUA.

The CSeq MUST be formatted as described in
the SIP [2]. In particular,
note side, so that they can be inserted into the CSeq space SIP NOTIFY
generated when a CPIM notification arrives.

7.1 SIP to CPIM

SIP for presnce is different converted to CPIM through a SIP to CPIM abstract
gateway service, depicted in the direction of notifier Figure 1.

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

Figure 1: SIP to notifier, and CPIM Conversion

The first step is from a different space
for presence clients and presence servers. NOTIFY SHOULD NOT contain that a Contact header.

If the SUBSCRIBE request contained Record-Route and/or Contact
headers, the Route header for NOTIFY is computed as per [2], as if
the SUBSCRIBE were an INVITE, and the NOTIFY were received at a BYE. gateway.
The
request-URI is also computed gateway generates a CPIM subscription request, with its
parameters filled in as per [2].

NOTIFY requests SHOULD be authenticated, using any of the end to end
SIP authentication mechanisms. Note that the shared secret mechanisms
are likely to only work for presence client generated notifications,
since shared secrets will exist only between end users, not between
servers and end users. When presence servers are generating the
notifications, public key based authentication is RECOMMENDED.

7.3 Responding to NOTIFY

The subscriber SHOULD be prepared to receive notifications from
different sources for the same presentity. follows:

o The mechanisms for
combining these notifications to watcher identity in the overall presentity state CPIM message is
outside copied from the scope
From field of this document, but is described in [11]. the SUBSCRIBE. If the From field contains a NOTIFY SIP
URL, it is received converted to an equivalent pres URL by a UA for a subscription which does dropping all
SIP URL parameters, and changing the scheme to pres.

This conversion may not
exist, work - what if the UA SHOULD respond with SIP URL has
no user name. Plus, converting from a 481 (Unknown Call Leg). It is
RECOMMENDED that the UA also send URL back to a SUBSCRIBE method, with
URN in this fashion may not do it correctly.

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

o The duration parameter in the From CPIM message is copied from the To
of
Expires header in the SUBSCRIBE. If the NOTIFY, Expires equal header
specifies an absolute time, it is converted to zero, and Contact wildcarded (*).
This will request that the subscription which generated a delta-time by
the unwanted
notification be removed. gateway. If no Expires header is present, one hour is
assumed.

o The transID parameter in the NOTIFY CPIM message is properly formed and desired, constructed by
appending the UA MUST respond
with a 200 OK. Notification responses will not normally contain
bodies. They MAY if Call-ID, the request contained an Accept header listing
acceptable bodies URI in the response.

If To field, the notification generates no final response at all, and times
out, or if URI in the notification generates a 481 response,
From field, the entity
generating CSeq and the notification should invalidate that notification
address tag in the subscription. If invalidation From field, and the
request URI, and computing a hash of the address results
in no notification addresses remaining in resulting string.
This hash is used as the subscription, transID. Note that the
entire subscription request URI is deleted.
included in the hash. This prevents notifications from
being generated is to users differentiate forked requests
within the SIP network that have gone offline, or to those users
who were mistakenly subscribed but have no presence client may arrive at all.
The soft state nature of subscriptions will ensure that valid
subscriptions will be refreshed if accidentally deleted.

8 Access controls

Access controls are mechanisms which allow the user controlling a
presentity to define rules about who is allowed to subscribe, what
data they see, and when. Access controls are same gateway.

The CPIM service then responds with either a critical component success or failure. In
the case of
a presence solution, but are ideally separated from success, the underlying
presence protocol. This is because access controls are fundamentally
a mechanism for influencing policy decisions made by presence
servers; policy can be controlled in numerous ways, and for maximum
flexibility and modularity, should be kept separate.

Some possibilities for access controls include:

Web Based: A user can go SIP to CPIM gateway service generates a secure web page, enter in access
controls, and have the data pushed 202
response to the presence server
through proprietary means (the presence server itself may
run SUBSCRIBE. It adds a web server). This provides tag to the opportunity for
substantial differentiation To field in access control services,
without interoperability issues. However, it is not
suitable for automated control over access controls.

CPL Based: The call processing language (CPL) [13] the
response, which is used to
define call processing rules (i.e., policy) for call setup
requests. We observe that the same policies will likely
make sense for subscriptions as well. Therefore, CPL,
possibly with some extensions, can be used for access
controls for presence. These access controls can be
uploaded the transID field in a SIP REGISTER request [14].

COPS: the success
response. The Common Open Policy Service (COPS) [12] protocol allows
for general purpose outsourced policy decisions. 202 response also contains a Contact header, which is
the value of the target from the SUBSCRIBE request. It could
easily is important
that the Contact header be used by presence servers set to define processing of
subscriptions.

Some of the things access controls can be used for are:

o Pre-authorizing subscribers, so target, since that their subscriptions are
automatically accepted.

o Blocking subscribers, so makes sure
that their subscription requests are
automatically rejected

o Specifying that only subsets of presence information are
reported to selected subscribers

o Specifying that false presence information can be given to
selected subscribers

9 Providing scalability

This section briefly overviews the mechanisms in this extension which
provide scalability, a critical goal for any presence protocol.

We refreshes have observed that scalability is limited by the messaging and
processing load at presence servers. As the processing load is
proportional to the message load, we can consider just same value in the message
load to determine request URI as
the scale bottlenecks at a presence server. This
load is equal to:

load = (presentities *
subscribers per presentity *
notifications per presentity) +

(presentities *
subscribers per presentity) original subscription. The first term represents the notification load, and the second, duration value from the
subscription load. The dominant factor CPIM success
response is placed into the notification load. We
address this load by providing three mechanisms - one for the
reduction of each of these terms.

9.1 Partitioning Expires header of the namespace 202. The load on an individual server can be reduced by partitioning gateway
stores the
namespace, so that Call-ID and Route header set for this subscription.

If the CPIM service responds with a single presence server handles only failure, the SIP to CPIM gateway
generates a small
number of presentities. This is accomplished through proxy servers,
which can receive 603 response. It adds a subscription, determine the subdomain which owns tag to the presence for that user, and forward To field in the subscription to that
subdomain. The subdomain itself may have proxies
response, which do this. The
result is that the presence namespace can be divided hierarchically,
with proxies providing routing towards same as the leafs, which handle transID field in the
actual presence servers.

As an example, failure
response.

When the CPIM system generates a subscription request notification request, the SIP to sip:joe@example.com reaches
CPIM gateway creates a SIP NOTIFY request. The request is constructed
using the main proxy server standard RFC2543 [2] procedures for example.com. This server does nothing but
look up users in constructing a directory server, mapping them to subdomains. request
within a call leg. This
particular user is will result in engineering, so the proxy maps To field containing the request URI
to sip:joe@engineering.example.com,
watcher field from CPIM, and forwards it to the
engineering.example.com server. A different user may have been
forwarded to From field containing the marketing.example.com server. These servers, target
field from the CPIM notification. The tag in
turn, can rely on databases or other configuration to map these
addresses into further subdomains. For example, the engineering
server might map sip:joe@engineering.example.com to
sip:joe@electrical.engineering.example.com. As these proxies are
generally stateless, they can be easily clustered, with load
balancing provided through DNS SRV records. Use of SRV records also
provides for fault tolerance among From field will
contain the cluster.

SIP proxy servers can be stateless; assisting only in transID. The presence information is copied into the routing body
of
requests, the notification. The Call-ID and not maintaining any Route headers are constructed
from the subscription state at all. Furthermore, through
SIPs Record-Routing mechanisms, proxies can assist stored in routing the
first gateway. If no notification
has yet been generated for this subscription, an initial CSeq value
is selected and stored.

SUBSCRIBE request; refreshes can bypass are handled identically to initial subscriptions
as above.

If a subscription is received with an Expires of zero, the proxies SIP to improve
scale.

9.2 Client notifications
CPIM gateway generates an unsubscribe message into the the CPIM
system. The load can also be reduced by completely eliminating notifications watcher parameter is copied from the presence server. This From field of the
SUBSCRIBE. The target parameter is accomplished through copied from the mechanisms
described Request URI field
of the SUBSCRIBE. The transID is copied from the tag in this extension that allow, by default, a presence client the To field
of the SUBSCRIBE request.

The response to generate notifications 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. This follows All subscription
state is removed. In the well
known Internet scalability principle case of pushing intelligence to failure, a 603 response is
constructed in the
periphery.

9.3 Distributed same fashion as above, and then subscription state

All the subscriptions from one domain
is removed, if present.

7.2 CPIM to another can be aggregated by
co-locating a PA with SIP

CPIM to SIP conversion occurs when a local outbound proxy. 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 figure, domain X has two subscribers first step is to determine if the subscribe
is for a single presentity
in domain Y. Both subscribers use a local outbound proxy, so that an existing subscription. That is done by taking the
SUBSCRIBE messages pass through a single proxy. When target in
the proxy sees a CPIM subscription request, and matching it against targets for a user in an outside domain,
existing subscriptions. If there are none, it acts as is a PA, and
accepts the subscription itself. Since new subscription,
otherwise, its a PA must be aware of refresh.

If its a new subscription, the
complete presence state of gateway generates a SIP SUBSCRIBE
request in the presentity, following manner:

o The From field in the presence server itself
subscribes request is set to the presentity watcher field in
the first time it gets a CPIM subscription
for that presentity. Subsequent subscriptions from inside domain X
for request

o The To field in the same presentity do not need request is set to trigger additional
subscriptions outside. A single the target field in the
CPIM subscription from domain X request

o The Expires header in the SUBSCRIBE request is used.

So, set to the
duration field in the CPIM subscription request

o The tag in the figure, From field is set to the first transID in the CPIM
subscription request, SUBSCRIBE 1, might
look like:

SUBSCRIBE sip:presentity@domainy.com SIP/2.0
Via: SIP/2.0/UDP subscriberA-pc.domainx.com
From: sip:subscriberA@domainx.com
To: sip:presentity@domainy.com
Call-ID: uobhasd97@7.3.4.2
CSeq: 1 SUBSCRIBE
Contact: sip:subscriberA@subscriberA-pc.domainX.com
Content-Length: 0
++++++++++
++++++++ +++++
+++ +++
++ ++++++++++++
+ ++
+ ++
+---------+ + + +---------+
| +----+ | +SUBSCRIBE 3 | |
| | request.

+-------------+
| |-------------------> |
| CPIM to SIP |
| PA Conversion |
| ++ + | Proxy
SIP SUBSCRIBE | | +----+ CPIM subscription request
<--------------> | +++++ + | <--------------->
| | Outbound| ++ +
| |
| Proxy | + +
| |
+---------+ ++ + +---------+
SUBSCRIBE ^ ^ + ++ \
1 / \ + ++ \
/ \ SUBSCRIBE + ++++ \ SUBSCRIBE 3
//-----\\ \ 2 ++ ++++++ \
// \\ \ ++ ++ \
| Subscriber | \ ++ +++ >
\\ A // \ ++ ++ +---------+
\\-----// \ + ++ | |
//------\\ ++ + | Presence|
|/ \| + +
| Server |
| Subscriber | + ++ | |
|\ B /| + + | |
\\------// + + +---------+
+ ++
+ +
++ +
DOMAIN X + + /\
+ + / \
++++ + /PUA \
+++++ ++ /------\
++++++ +
++ DOMAIN Y ++
++ ++
+++++++++++++++++++
+-------------+

Figure 2: Distributing Subscription State

When this CPIM to SIP Conversion

This SUBSCRIBE message is received at the outbound proxy/PA for domain X, then sent.

If the PA
itself generates a subscription for presentity, SUBSCRIBE 3:

Via: SIP/2.0/UDP outboundproxy.domainx.com
From: sip:domainx.com
To: sip:presentity@domainy.com
Call-ID: gghhjjoo@0.1.2.3
CSeq: 77 is a refresh, a SUBSCRIBE
Contact: sip:outboundproxy.domainX.com
Content-Length: 0

Note that this subscription lists request is generated in
the outbound proxy/PA as same way. However, there will also be a tag in the
originating host (in To field,
copied from the Via and Contact fields), subscription state in the gateway, and sip:domainx.com
as a Route
header, obtained from the identity of subscription state in the subscriber. This subcription gateway.

When a response to the SUBSCRIBE is forwarded received, a response is sent to
the PA for presentity CPIM system. The duration parameter in domain Y. If it this response is willing copied
from the Expires header in the SUBSCRIBE response (a conversion from
an absolute time to accept a
domain wide subscription (after authenticating delta time may be needed). The transID in the request, of
course, as coming
response is copied from the owner tag in the From field of the domain), a response. If
the response was 202, the status is set to indeterminate. If the
response was any other 200 OK class response, the status is
generated. Once this arrives at set to
sucess. For any other final response, the outbound proxy, it can accept status is set to failure.

If the response was a 200 class response, subscription state is
established. This state contains the tag from subscriber 1.

When subscriber 2 subscribes, using SUBSCRIBE 2:

SUBSCRIBE sip:presentity@domainy.com SIP/2.0
Via: SIP/2.0/UDP subscriberB-pc.domainx.com
From: sip:subscriberB@domainx.com
To: sip:presentity@domainy.com
Call-ID: qwertyuiop@11.22.33.44
CSeq: 12 the To field in the
SUBSCRIBE
Contact: sip:subscriberB@subscriberB-pc.domainX.com
Content-Length: 0

this response, and the Route header set computed from the
Record-Routes and Contact headers in the 200 class response. The
subscription is accepted indexed by the outbound proxy/PA. No
subscriptions are presentity identification (the To
field of the SUBSCRIBE that was generated).

If an unsubscribe request is received from the CPIM side, the gateway
checks if the subscription exists. If it does, a SUBSCRIBE is
generated or forwarded as described above. However, the Expires header is set to domain Y.

This process results in
zero. If the subscription state being distributed
throughout does not exist, the network, with each domain holding gateway generates a
failure response and sends it to the subscriptions
from users within its own domain. In fact, CPIM system. When the process can take place
recursively, resulting in distribution of presence state over a tree
of domains. That achieves scale; a presentity that might get millions
of subscribers would be readily served by such an architecture.

The important concept response
to note here is that this aggregation process the SUBSCRIBE request arrives, it is converted to a matter of local optimization in domain X; as far CPIM response
as domain Y described above for the initial SUBSCRIBE response. In all cases,
any subscription state in the gateway is
concerned, there destroyed.

When a NOTIFY is received from the SIP system, a single subscription, and processing that
subscription CPIM notification
request is no different than processing any other subscription. sent. This notification is possible because we have defined presence operations constructed as follows:

o The CPIM watcher is set to be
invoked on logical entities, PAs, which can dynamically be
instantiated on a subscription by subscription basis the URI in any device
which can somehow determine the complete To field of the
NOTIFY.

o The CPIM target is set to the URI in the From field of the
NOTIFY.

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

o The presence state component of the notification is extracted from
the body of the SIP NOTIFY request.

The gateway generates a
presentity. In 200 response to the case here, SIP NOTIFY and sends it
as well.

TODO: some call flow diagrams with the outbound proxy parameters

8 Firewall and NAT Traversal

It is instantiating anticipated that presence services will be used by clients and
presentities that are connected to proxy servers on the
PA, 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 [9] and [10].

Generally, data traverses NATs and firewalls when it is allowing sent over TCP
or TLS connections established by devices inside the PA firewall/NAT to know the presence state
devices outside of it. As a
presentity through another subscription.

The drawback of this optimization result, it is RECOMMENDED that SIP for
presence entities maintain persistent TCP or TLS connections to their
next hop peers. This includes connections opened to send a SUBSCRIBE,
NOTIFY, and most importantly, REGISTER. By keeping the latter
connection open, it introduces security
issues. The subscription from domainX is now domain wide; can be used by the
presentity cannot authenticate SIP proxy to send messages
from outside the identity of every subscriber
within firewall/NAT back to the domain. client. It is forced into a trust relationship with that
domain, such also
recommended that domain Y trusts the client include a Contact cookie as described in
[10] in their registration, so that domain X is authenticating
each subscriber. Furthermore, the ability of proxy can map the presentity
URI to
authorize some subscribers from domain X, but not others, is lost,
unless there is some means to convey access control across domains.
As that connection.

Furthermore, entities on either side of a result, the decision about whether to accept such domain wide
subscriptions is up firewall or NAT should
record-route in order to ensure that the security policy of initial connection
established for the presence server.
Clearly, such subscriptions might be accepted subscription is used for certain
presentities (ones with many subscribers), but not others.

10 the notifications as
well.

9 Security considerations

There are numerous security considerations for presence. Many are
outlined above; this section considers them issue by issue.

10.1

9.1 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 end-to-end mechanisms do not require transitivity of
trust, and reveal information only to the desired recipient. However,
end to end
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
between network servers (proxies to proxies, proxies to redirect
servers), transport mode ESP [7] [11] is used to encrypt the entire
message. Between a UAC and its local proxy, TLS [15] [12] is RECOMMENDED.
Similarly, TLS SHOULD be used between a presence server and the PUA.

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 that registration contains the token
"tls" as transport, it implies that the PUA supports TLS.

Furthermore, we allow for the Contact header in the SUBSCRIBE request
to contain TLS as a transport. The Contact header is used to route
subsequent messages between a pair of entities. It defines the
address and transport used to communicate with the user agent. Even
though TLS might be used between the subscriber and its local proxy,
placing this parameter in the Contact header means that TLS can also
be used end to end for generation of notifications after the initial
SUBSCRIBE message has been successfully routed. This would provide
end to end privacy and authentication services with low proxy
overheads.

SIP encryption MAY be used end to end for the transmission of both
SUBSCRIBE and NOTIFY requests. SIP supports PGP based encryption,
which does not require the establishment of a session key for
encryption of messages within a given subscription (basically, a new
session key is established for each message as part of the PGP
encryption). Work has recently begun on the application of S/MIME
[16]
[13] for SIP. Tunneling of TLS over SIP, for the purposes of
establishment of an end to end private key for encryption, is also
under investigation.

10.2

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

10.3 HTTP Basic is
NOT RECOMMENDED.

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

10.4

9.4 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 basic, digest, of digest or PGP) MAY
be used to prevent replay attacks.

10.5

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

10.5.1

9.5.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 Section 7.3, [3], if a notify NOTIFY is not acknowledged
or was not wanted, the subscription that generated it is removed.
This eliminates some of the amplification properties of providing false
Contact addresses.

10.5.2 Annoyance subscriptions

A user can attempt to "annoy" another by subscribing, and on
rejection, subscribe again. If subscriptions cause screen pops, this
can result in a DoS attack whereby screen pops are constantly pushed
onto the subscribed parties machine. To avoid this attack, PUAs
SHOULD cache rejected subscriptions and automatically reject
subsequent ones (of course, the UA will want a way for the subscriber
to remove the negative cached entries if they change their mind). In
addition, the PUA SHOULD use access control mechanisms to block those
subscriptions at the presence server as well.

10.6 Firewall traversal

The extension defined here is firewall and NAT friendly, in that it
can be configured in such a way as to traverse any device which
allows outgoing TCP connections to an external server.

Consider the configuration in Figure 3:

The key to enabling traversal of the firewall is to ensure that all
SUBSCRIBE requests, their responses, and subsequent notifications and
their responses, all traverse a long lived connection opened from the
proxy inside the firewall (on the left) out towards the proxy or
presence server in the remote domain.

SIP supports long lived connections, but what is needed here is a
means for the proxy inside the firewall to request to the presence
entity on the far side that (1) the connection be kept open, and (2)
the presence entity record-route, so that notifications pass over the
same connection. These are accomplished with a simple extension [17].

In this environment, the proxy would need to be aware it is behind a
firewall, so that it can request the persistent connection, and use
TCP in the first place. Note that a subscriber could also do this,
allowing for firewall traversal even in the absence of a proxy inside
the firewall.

Since usage of these persistent connections is not mandatory, it can
be used when needed, but for non-firewalled networks, end to end
notifications can be used instead, increasing scalability.

11 Addressing Transport

SIP, and this protocol based on it, is very flexible in its usage of
|
|
|
|
INSIDE | OUTSIDE
|
|
|
|
+--------+ | +--------+
| | | | |
| | | |Presence|
| Proxy | --------------+--------- | Entity |
| | | | |
| | | | |
+--------+ | +--------+
| |
| |
| |
| |
| |
| |
| |
/------\ |
// \\ |
| Subscriber | |
| | |
\\ //
\------/ Firewall

Figure 3: Architecture of Presence System

transport protocols. Both TCP and UDP operation are defined; SIP is
reliable over any transport and provides its own application layer
congestion control, reliability and sequencing. New transports can be
used, such as the Stream Control Transmission Protocol (SCTP) [5],
which may prove useful for presence messages [6], or TLS. SIPs
ability to run over UDP may provide useful for an eventual
application of multicast to presence information. Notifications, in
particular, might be very amenable to multicast distribution.

This flexibility is needed because, simply put, one size does not fit
all. UDP is beneficial in that it can be used in stateless proxy
servers, improving scale and performance. It is also faster, as no
explicit connection setup is required. It may also be appropriate for
small devices, such as wireless handsets, which may not readily
support persistent connections. However, TCP is advantageous in many
cases for liveness determination, congestion control, and its
superior segmentation and reassembly capabilities.

12 Required SIP features

SIP contains many components and capabilities, only some of which are
needed to support presence. It is a common misconception to believe
that SIP is only good for initiating phone calls. Since SIP separates
the definition of a session to other protocols, such as the Session
Description Protocol (SDP) [4], SIP is best viewed as a real-time
rendezvous system, which allows content to be delivered from one
user, to the current location(s) where another user, the desired
target, is located. This rendezvous system can be used to deliver
invitations to sessions, as is accomplished with the INVITE method,
but other data, such as subscriptions and notifications, can be
delivered.

As such, most of the generic components of SIP as they relate to
message routing are useful and needed for this extension, and most of
those related specifically to INVITE, BYE, ACK, and CANCEL processing
are not needed.

This section outlines those components needed, and those not needed,
for presence.

12.1 Needed components

The following are the SIP components needed in a PA, PUA, or
subscriber (all three are classified as user agents in SIP
terminology) to support this extension:

o Basic SIP parser, capable of generating To, From, Call-ID,
CSeq, To, Via, Route, Accept, Allow, Require, Record-Route,
Expires, Contact, Content-Length, and Content-Type headers, in
addition to the request and response line.

o UDP transmission mechanisms for non-INVITE requests, which is
nothing more than a periodic retransmit of a request with
exponential backoff.

o Implementation of the client and server state machine for
non-INVITE requests (used for reliable transport), documented
in Section 10.4.1 of SIP [2].

o The ability to send SIP REGISTER requests, and process
responses, and refresh those registrations.

o Construction and usage of Route headers.

o Support the Require mechanism for protocol extension, as
defined in Section 6.30 of RFC 2543.

o Reject requests with unknown methods, returning an Allow
header in the response.

o Reject requests with unknown bodies, returning an Accept
header in the response.

o Send and process SIP responses based solely on the 100s digit.

o Send responses based on the Via header processing rules of
Section 6.40

If a UA wishes to implement security, it needs to support the
security mechanisms defined in RFC 2543.

A presence server must additionally act as a proxy, and therefore
must additionally be able to:

o Parse and generate SIP messages, understanding the To, From,
Call-ID, CSeq, Via, Route, Record-Route, and Proxy-Require
headers, in addition to the request and response line.

o If co-located with a registrar, process SIP REGISTER requests
and generate responses

o Perform the proxying functions described in Section 12 of RFC
2543; these rules mainly concern connection management, Via
processing, loop detection, and transport.

12.2 Components not needed

User agents supporting presence do not need to support the following
SIP capabilities:

o Processing of INVITE, ACK, CANCEL, BYE requests

o Support for the INVITE reliability mechanisms and state
machines

o multiple 200 OK responses
o SDP processing

o re-INVITEs

Elimination of INVITE processing alone results in a substantial
reduction in required features.

10 Example message flows

THe

The following subsections exhibit example message flows, to further
clarify behavior of the protocol.

13.1

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

Watcher Presentity
------- -----------
| F1 SUBSCRIBE |
| ----------------------------->|
| F2 200 OK 202 Accepted |
|<------------------------------|
| F3 NOTIFY |
|<------------------------------|
| F4 200 OK |
|------------------------------>|
| F5 NOTIFY |
|<------------------------------|
| F6 200 OK |
|------------------------------>|
| F7 SUBSCRIBE (unsub) |
|------------------------------>|
| F8 200 OK 202 Accepted |
|<------------------------------|

Message Details

F1 SUBSCRIBE watcher -> presentity

SUBSCRIBE sip:presentity@pres.example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@watcherhost.example.com> <pres:user@example.com>
To: Resource <sip:presentity@pres.example.com> <pres:presentity@example.com>
Call-ID: 3248543@watcherhost.example.com
CSeq : 1 SUBSCRIBE
Expires: 600
Accept: application/xpidf+xml, text/lpidf application/xpidf+xml
Event: presence
Contact: sip:user@watcherhost.example.com

F2 200 OK 202 Accepted presentity->watcher

SIP/2.0 200 OK 202 Accepted
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@watcherhost.example.com> <pres:user@example.com>
To: Resource <sip:presentity@pres.example.com> <pres:presentity@example.com>;tag=88a7s
Call-ID: 3248543@watcherhost.example.com
Cseq: 1 SUBSCRIBE
Event: presence
Expires: 600
Content-Type: application/xpidf+xml
Content-Length: 351

<?xml version="1.0"?>
<!DOCTYPE presence
PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd">
<presence>
<presentity uri="sip:presentity@pres.example.com;method=SUBSCRIBE"/>
<atom id="779js0a98">
<address uri="sip:presentity@pres.example.com;method=INVITE">
<status status="open"/>
</address>
</atom>
</presence>
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 <sip:presentity@pres.example.com> <pres:presentity@example.com>;tag=88a7s
To: User <sip:user@watcherhost.example.com> <pres:user@example.com>
Call-ID: 3248543@watcherhost.example.com
CSeq: 1 NOTIFY
Event: presence
Content-Type: application/xpidf+xml
Content-Length: 352 120

<?xml version="1.0"?>
<!DOCTYPE presence
PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd">
<presence>
<presentity uri="sip:presentity@pres.example.com;method=SUBSCRIBE"/>
<atom id="779js0a98">
<address uri="sip:presentity@pres.example.com;method=INVITE">
<status status="inuse"/>
</address>
</atom>
<presence entityInfo="pres:presentity@example.com">
<tuple destination="sip:presentity@example.com" status="open"/>
</presence>

F4 200 OK watcher->presentity

SIP/2.0 200 OK
Via: SIP/2.0/UDP pres.example.com:5060
From: Resource <sip:presentity@pres.example.com> <pres:presentity@example.com>
To: User <sip:user@watcherhost.example.com> <pres:user@example.com>
Call-ID: 3248543@watcherhost.example.com
CSeq: 1 NOTIFY

F5 NOTIFY Presentity->watcher

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

<?xml version="1.0"?>
<!DOCTYPE presence
PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd">
<presence>
<presentity uri="sip:presentity@pres.example.com;method=SUBSCRIBE"/>
<atom id="779js0a98">
<address uri="sip:presentity@pres.example.com;method=INVITE">
<status status="open"/>
</address>
</atom>
<presence entityInfo="pres:presentity@example.com">
<tuple destination="sip:presentity@example.com" status="closed"/>
</presence>

F6 200 OK watcher->presentity

F7 SUBSCRIBE watcher -> presentity

SUBSCRIBE sip:presentity@pres.example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@watcherhost.example.com> <pres:user@example.com>
To: Resource <sip:presentity@pres.example.com> <pres:presentity@example.com>
Call-ID: 3248543@watcherhost.example.com
Event: presence
CSeq : 2 SUBSCRIBE
Expires: 0
Accept: application/xpidf+xml, text/lpidf application/xpidf+xml
Contact: sip:user@watcherhost.example.com

F8 200 OK 202 Accepted presentity->watcher

SIP/2.0 200 OK 202 Accepted
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@watcherhost.example.com> <pres:user@example.com>
To: Resource <sip:presentity@pres.example.com> <pres:presentity@example.com>
Call-ID: 3248543@watcherhost.example.com
Event: presence
Cseq: 2 SUBSCRIBE
Expires:0
Content-Type: text/lpidf
Content-Length: 113

To: sip:presentity@pres.example.com
Contact: sip:presentity@pres.example.com;method=INVITE;
description="open"

13.2

10.2 Presence Server with Client Notifications

This call flow shows the involvement of a presence server in the
handling of subscriptions. In this scenario, the client has indicated
that it will handle subscriptions and thus notifications. The message
flow shows a change of presence state by the client and a
cancellation of the subscription by the watcher.

Presence
Watcher Server PUA
| | F1 REGISTER |
| |<---------------------|
| | F2 200 OK |
| |--------------------->|
| F3 SUBSCRIBE | |
|--------------------->| |
| | F4 SUBSCRIBE |
| |--------------------->|
| | F5 200 OK 202 |
| |<---------------------|
| F6 200 OK 202 | |
|<---------------------| |
| | F7 REGISTER | NOTIFY | |<---------------------| |
|<--------------------------------------------+
| F8 200 OK | | |--------------------->|
|-------------------------------------------->|
| | F9 NOTIFY REGISTER |
|
|<--------------------------------------------+ |<---------------------|
| | F10 200 OK |
|
|-------------------------------------------->| |--------------------->|
| F11 SUBSCRIBE | |
|--------------------->| NOTIFY | |
|<--------------------------------------------+
| F12 SUBSCRIBE |
| |--------------------->|
| | F13 200 OK |
| |<---------------------|
| F14 200 OK | |
|<---------------------| |
|-------------------------------------------->|

Message Details

F1 REGISTER PUA->server

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com>
From: <sip:resource@example.com>
Call-ID: 2818@pua.example.com
CSeq: 1 REGISTER
Contact: <sip:id@pua.example.com;method=MESSAGE> <sip:id@pua.example.com>;methods="MESSAGE"
;description="open"
Contact: <sip:id@pua.example.com;method=SUBSCRIBE> <sip:id@pua.example.com>;methods="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;method=MESSAGE> <sip:id@pua.example.com>;methods="MESSAGE"
;description="open"
Contact: <sip:id@pua.example.com;method=SUBSCRIBE> <sip:id@pua.example.com>;methods="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 <sip:user@example.com> <pres:user@example.com>
To: Resource <sip:resource@example.com> <pres:resource@example.com>
Call-ID: 32485@watcherhost.example.com
CSeq : 1 SUBSCRIBE
Expires: 600
Event: presence
Accept: application/xpidf+xml
Contact: sip:user@watcherhost.example.com

F4 SUBSCRIBE server->PUA

SUBSCRIBE sip:id@pua.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com> <pres:user@example.com>
To: Resource <sip:resource@example.com> <pres:resource@example.com>
Call-ID: 32485@watcherhost.example.com
CSeq : 1 SUBSCRIBE
Event: presence
Expires: 600
Accept: application/xpidf+xml
Contact: sip:user@watcherhost.example.com

F5 200 OK 202 Accepted PUA->server

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

To: sip:resource@example.com
Contact: <sip:id@pua.example.com;method=MESSAGE>
;description="open"

F6 200 OK server->watcher

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

To: sip:resource@example.com
Contact: <sip:id@pua.example.com;method=MESSAGE>
;description="open"

F7 REGISTER PUA->server

F8 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;method=MESSAGE>
;description="inuse"; expires=600
Contact: <sip:id@pua.example.com;method=SUBSCRIBE>
; expires=210

F9 NOTIFY PUA->watcher

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

To: sip:resource@example.com
Contact: <sip:id@pua.example.com;method=MESSAGE>
;description="inuse"

F10 120

<?xml version="1.0"?>
<presence entityInfo="pres:resource@example.com">
<tuple destination="im:resource@example.com" status="open"/>
</presence>

F8 200 OK watcher->PUA

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

F11 SUBSCRIBE watcher->server

SUBSCRIBE sip:resource@example.com

F9 REGISTER PUA->server

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com> pua.example.com:5060
To: Resource <sip:resource@example.com>
From: <sip:resource@example.com>
Call-ID: 32485@watcherhost.example.com
CSeq : 2818@pua.example.com
CSeq: 2 SUBSCRIBE
Expires: 0 REGISTER
Contact: sip:user@watcherhost.example.com

F12 SUBSCRIBE <sip:id@pua.example.com>;methods="MESSAGE"
;description="busy"
Contact: <sip:id@pua.example.com>;methods="SUBSCRIBE"
Expires: 600

F10 200 OK server->PUA
SUBSCRIBE sip:resource@example.com

SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com> pua.example.com:5060
To: Resource <sip:resource@example.com>
From: <sip:resource@example.com>
Call-ID: 32485@watcherhost.example.com
CSeq : 2818@pua.example.com
CSeq: 2 SUBSCRIBE
Expires: 0 REGISTER
Contact: <sip:id@pua.example.com>;methods="MESSAGE"
;description="busy"
Contact: <sip:id@pua.example.com>;methods="SUBSCRIBE"
Expires: 600

F11 NOTIFY PUA->watcher

NOTIFY sip:user@watcherhost.example.com

F13 200 OK PUA->server SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com> pua.example.com:5060
To: User <pres:user@example.com>
From: Resource <sip:resource@example.com> <pres:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq : 2 SUBSCRIBE NOTIFY
Event: presence
Content-Type: text/lpidf application/xpidf+xml
Content-Length: 115

To: sip:resource@example.com
Contact: <sip:id@pua.example.com;method=MESSAGE>
; description="open"

F14 120
<?xml version="1.0"?>
<presence entityInfo="pres:resource@example.com">
<tuple destination="im:resource@example.com" status="busy"/>
</presence>

F12 200 OK server->watcher watcher->PUA

SIP/2.0 200 OK
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com> pua.example.com:5060
To: User <pres:user@example.com>
From: Resource <sip:resource@example.com> <pres:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq : 2 SUBSCRIBE
Content-Type: text/lpidf
Content-Length: 115

To: sip:resource@example.com
Contact: <sip:id@pua.example.com;method=MESSAGE>
; description="open"

13.3 NOTIFY

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

Watcher Server PUA
| F1 SUBSCRIBE | |
|------------------>| |
| F2 200 OK 202 Accepted | |
|<------------------| |
| | F3 REGISTER |
| |<-------------------|
| | F4 200 OK |
| |------------------->|
| F5 NOTIFY | |
|<------------------| |
| F6 F4 200 OK | |
|------------------>| |
| | F7 F5 REGISTER |
| |<-------------------|
| | F8 F6 200 OK |
| |------------------->|
| F9 F7 NOTIFY | |
|<------------------| |
| F10 F8 200 OK | |
|------------------>| |

Message Details

F1 SUBSCRIBE watcher->server

SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
To: <sip:resource@example.com> <pres:resource@example.com>
From: <sip:user@example.com> <pres:user@example.com>
Call-ID: 2010@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Event: presence
Accept: application/xpidf+xml
Contact: <sip:user@watcherhost.example.com>
Expires: 600

F2 200 202 OK server->watcher

SIP/2.0 200 OK 202 Accepted
Via: SIP/2.0/UDP watcherhost.example.com:5060
To: <sip:resource@example.com> <pres:resource@example.com>;tag=ffd2
From: <sip:user@example.com> <pres:user@example.com>
Call-ID: 2010@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Event: presence
Expires: 600
Content-Type: text/lpidf
Content-Length: 114

To: sip:resource@example.com
Contact: <sip:resource@example.com;method=MESSAGE>
;description="closed"

F3 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: 110@pua.example.com
CSeq: 1 REGISTER
Contact: <sip:id@pua.example.com;method=MESSAGE>
;description="open"
Expires: 600

F4 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: 110@pua.example.com
CSeq: 1 REGISTER
Contact: <sip:id@pua.example.com;method=MESSAGE>
; description="open"; expires=600

F3 NOTIFY server-> watcher

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

To: sip:resource@example.com
Contact: <sip:id@pua.example.com;method=MESSAGE>
; description="open"

F6 120

<?xml version="1.0"?>
<presence entityInfo="pres:resource@example.com">
<tuple destination="im:resource@example.com" status="open"/>
</presence>

F4 200 OK

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

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> <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> <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: <sip:resource@example.com> <pres:resource@example.com>;tag=ffd2
To: <sip:user@example.com> <pres:user@example.com>
Call-ID: 2010@watcherhost.example.com
CSeq: 2 NOTIFY
Event: presence
Content-Type: text/lpidf application/xpidf+xml
Content-Length: 125

To: sip:resource@example.com
Contact: <sip:id@pua.example.com;method=MESSAGE>
; description="Away from keyboard"

F10 200 OK

SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
From: <sip:resource@example.com>
To: <sip:user@example.com>
Call-ID: 2010@watcherhost.example.com
CSeq: 2 NOTIFY

13.4 Presence Server Notifications with Client Authorization of
Subscription

This call flow expands on the call flow in 13.3 by showing how the
Presence Server gets authorization for a new subscription 120

<?xml version="1.0"?>
<presence entityInfo="pres:resource@example.com">
<tuple destination="im:resource@example.com" status="Away from the
client. The authorization is done using the QAUTH method defined in
[9].

Presence
Watcher Server PUA
| | F1 REGISTER |
| |<---------------------|
| | F2 200 OK |
| |--------------------->|
| F3 SUBSCRIBE | |
|--------------------->| |
| F4 202 Accepted | |
|<---------------------| |
| | F5 QAUTH |
| |--------------------->|
| | F6 200 OK |
| |<---------------------|
| F7 NOTIFY | |
|<---------------------| |
| F8 200 OK | |
|--------------------->| |
| | F9 REGISTER |
| |<---------------------|
| | F10 200 OK |
| |--------------------->|
| F11 NOTIFY | |
|<---------------------| |
| F12 200 OK | |
|--------------------->| |
| F13 SUBSCRIBE | |
|--------------------->| |
| F14 200 OK | |
|<---------------------| |

Message Details:

F1 REGISTER PUA->server

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: <sip:resource@example.com>
From: <sip:resource@example.com>
Call-ID: 12@pua.example.com
CSeq: 1 REGISTER
Contact: <sip:id@pua.example.com;methods=MESSAGE>
;description="open"
Contact: <sip:id@pua.example.com;methods=QAUTH>
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: 12@pua.example.com
CSeq: 1 REGISTER
Contact: <sip:id@pua.example.com;methods=MESSAGE>
;description="open"
Contact: <sip:id@pua.example.com;methods=QAUTH>
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 <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 3248546@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Expires: 600
Contact: sip:user@watcherhost.example.com

F4 202 Accepted server->watcher

SIP/2.0 202 Accepted
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 3248546@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Expires: 600

F5 QAUTH server->PUA

QAUTH sip:id@pua.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 2874@server.example.com
CSeq: 1 QAUTH
Expires: Sun, 14 Jun 2036 00:00:00 GMT
Contact: sip:server.example.com

F6 200 OK PUA->server

SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 2874@server.example.com
CSeq: 1 QAUTH
Expires: Sun, 14 Jun 2036 00:00:00 GMT

F7 NOTIFY server->watcher

NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
From: <sip:resource@example.com>
To: <sip:user@example.com>
Call-ID: 3248546@watcherhost.example.com
CSeq: 1 NOTIFY
Content-Type: text/lpidf
Content-Length: 111

To: sip:resource@example.com
Contact: <sip:resource@example.com;method=MESSAGE>
; description="open" keyboard"/>
</presence>

F8 200 OK

SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
From: <sip:resource@example.com>
To: <sip:user@example.com>
Call-ID: 3248546@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: 12@pua.example.com
CSeq: 2 REGISTER
Contact: <sip:id@pua.example.com;methods=MESSAGE>
;description="hiding in storm shelter"
Contact: <sip:id@pua.example.com;methods=QAUTH>
Expires: 600

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: 12@pua.example.com
CSeq: 2 REGISTER
Contact: <sip:id@pua.example.com;methods=MESSAGE>
;description="hiding in storm shelter"
Contact: <sip:id@pua.example.com;methods=QAUTH>
Expires: 600

F11 NOTIFY server->watcher

NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
From: <sip:resource@example.com>
To: <sip:user@example.com>
Call-ID: 3248546@watcherhost.example.com
CSeq: 2 NOTIFY
Content-Type: text/lpidf
Content-Length: 131

To: sip:resource@example.com
Contact: <sip:resource@example.com;method=MESSAGE>
; description="hiding in storm shelter"

F12 200 OK watcher->server

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

F13 SUBSCRIBE watcher->server
SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 3248546@watcherhost.example.com
CSeq: 2 SUBSCRIBE
Expires: 0
Contact: sip:user@watcherhost.example.com

F14 200 OK server->watcher

SIP/2.0 200 OK
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 3248546@watcherhost.example.com
CSeq: 2 SUBSCRIBE
Content-Type: text/lpidf
Content-Length: 131

To: sip:resource@example.com
Contact: <sip:resource@example.com;method=MESSAGE>
; description="hiding in storm shelter"

13.5 Delayed Subscription Approval

11 Open Issues

The call flow is similar to 13.4 with the difference being that the
client following is currently offline.

A watcher subscribes to a resource for which the server but has not
been authorized and a PUA for list of known open issues:

o This draft recommends that resource is not available. The
server queues the request until a PUA becomes available. The PUA
grants permission, but since the original subscription had expired,
the server does not generate a NOTIFY. The watcher subscribes again,
after the REGISTER has expired, To and has its subscription approved.
Note that since there From field are no contacts registered for the resource at populated
with presence URLs rather than sip URLs. Is that time, reasonable?
Will this lead to incompatibilities in proxies? Is there any
issues with CPIM if the presence document SIP URL format is vacuous.

watcher server PUA
| | |
| F1 SUBSCRIBE | |
|--------------------->| (PUA not "online") |
| F2 202 Accepted | |
|<---------------------| |
| (subscription expires) |
| | F3 REGISTER |
| |<--------------------|
| | F4 200 OK |
| |-------------------->|
| | F5 QAUTH |
| |-------------------->|
| | F6 200 OK |
| |<--------------------|
| (registration expires)|
| F7 SUBSCRIBE | |
|--------------------->| |
| F8 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
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 3248543@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Date: Mon, 12 Jun 2000 16:00:00 GMT
Expires: 600
Contact: sip:user@watcherhost.example.com

F2 202 Accepted server->watcher

SIP/2.0 202 Accepted
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 3248543@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Expires: 600

F3 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: 2001@pua.example.com
CSeq: 1 REGISTER
Date: Wed, 14 Jun 2000 09:57:16 GMT
Contact: <sip:id@pua.example.com;methods=MESSAGE;
description="open">
Contact: <sip:id@pua.example.com;methods=QAUTH>
Expires: 600

F4 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: 2001@pua.example.com
CSeq: 1 REGISTER
Contact: <sip:id@pua.example.com;methods=MESSAGE;
description="open">
Contact: <sip:id@pua.example.com;methods=QAUTH>
Expires: 600

F5 QAUTH server->PUA

QAUTH sip:id@pua.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 47774@server.example.com
CSeq: 1 QAUTH
Expires: Sun, 14 Jun 2036 00:00:00 GMT
Contact: sip:server.example.com

F6 200 OK PUA->server

SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 47774@server.example.com
CSeq: 1 QAUTH
Expires: Sun, 14 Jun 2036 00:00:00 GMT

F7 SUBSCRIBE watcher->server

SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 3248544@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Date: Thu, 15 Jun 2000 07:22:15 GMT
Expires: 600
Contact: sip:user@watcherhost.example.com

F8 200 OK server->watcher

SIP/2.0 200 OK
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <sip:user@example.com>
To: Resource <sip:resource@example.com>
Call-ID: 3248544@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Expires: 600
Content-Type: text/lpidf
Content-Length: 31

To: sip:resource@example.com

14 Checklist of requirements used? This section examines the requirements for presence, as specified in
RFC2779 [18], and indicates how each requirement is addressed by this
extension. Only the requirements related to presence are discussed
here. Requirements for instant messaging depends
on what components of a message are discussed in [19] and
presence data formats signed in [10,11].

"Requirement 2.1.1. The protocols MUST allow CPIM.

o Rate limitations on NOTIFY: do we want that? How do we pick a PRESENCE SERVICE
to be available independent of whether an INSTANT MESSAGE
SERVICE
value? 5 seconds is available, and vice-versa." Presence and IM are
supported by completely separate protocols, and do not
depend on each other.

"Requirement 2.1.2. The protocols must not assume arbitrary.

o Merging of presence data from multiple PA has been removed. Is
that an
INSTANT INBOX is necessarily reached by OK?

o Placing IM URLs in the same IDENTIFIER
as that Contact header of a PRESENTITY. Specifically, the protocols must
assume REGISTER: is that some INSTANT INBOXes may have no associated
PRESENTITIES, and vice versa."
OK? What does it mean?

o The complete separation process of
IM and migrating subscriptions from a presence allows different identifiers to be used for
each.

"Requirement 2.1.3. The protocols MUST also allow an INSTANT
INBOX server
to be reached via the same IDENTIFIER as the
IDENTIFIER of some PRESENTITY." The architecture provided
here allows for the IM and presence identifiers PUA is not likely to be work in the
same, if so desired.

"Requirement 2.1.4. The administration case where subscription
refreshes use tags and naming of ENTITIES
within Route headers. So, we have a given DOMAIN MUST be able to operate independently
of actions in any other DOMAIN." This requirement choice.
Either migration is met by
SIP. SIP uses email-like identifiers which consist of a
user name at a domain. Administration of user names disallowed, and we keep with leg oriented
subscriptions, or migration is done
completely within the domain, allowed, and these user names have there is no
defined rules tags
or organization that needs to be known
outside of the domain in order for Route's associated with subscriptions.

o Converting SIP URLs back to operate.

"Requirement 2.1.5. pres URLs.

o The protocol MUST allow for an arbitrary
number of DOMAINS within the NAMESPACE." This requirement
is met by SIP. SIP uses standard DNS domains, which to CPIM and CPIM to SIP gateways are not
restricted in number.

"Requirement 2.2.1. It MUST be possible for ENTITIES in one
DOMAIN to interoperate with ENTITIES in another DOMAIN,
without the DOMAINS having previously been aware stateless,
because of each
other." This requirement is met by SIP, as it is essential
for establishing sessions as well. DNS SRV [20] records are
used the need to discover servers for maintain Route, Call-ID, CSeq, and
other parameters. Perhaps we can ask CPIM to define a particular service within token
value which is sent in a
domain. They are CPIM request and returned in a generalization of MX records, used for
email routing. SIP defines procedures for usage of DNS
records CPIM
response. Would that help?

o Need to find servers in another domains, which include
SRV lookups. This allows domains specify how to communication without
prior setup.

"Requirement 2.2.2: The protocol MUST be capable of meeting its
other functional take Contacts from REGISTER and performance requirements even when
there are millions of ENTITIES within build a single DOMAIN."
Whilst it
presence document. One obvious thing is hard to judge whether this can be met by
examining the architecture of a protocol, SIP has numerous
mechanisms for achieving large scales of users within a
domain. It allows hierarchies of servers, whereby the
namespace can be partitioned among servers. Servers near
the top of that the hierarchy, used solely for routing, can be
stateless, providing excellent scale.

"Requirement 2.2.3: The protocol MUST be capable of meeting its
other functional and performance requirements when contact
addresses don't go in there
are millions of DOMAINS within directly; you probably want to put
the single NAMESPACE." The
usage address of DNS for dividing the namespace into domains
provides record, otherwise calls might not go through
the same scale as todays email systems, which
support millions of DOMAINS.

"Requirement 2.2.4: proxy.

12 Changes from -00

The protocol MUST be capable of meeting its
other functional and performance requirements when every
single SUBSCRIBER document has SUBSCRIPTIONS been completely rewritten, to hundreds of
PRESENTITIES." Section 9 discusses reflect the means by which our
extension provides scale.

"Requirement 2.2.5: The protocol MUST be capable of meeting its
other functional change
from a sales pitch and performance requirements when hundreds
of distinct SUBSCRIBERS have SUBSCRIPTIONS educational document, to a single
PRESENTITY." Section 9 discusses the means by which our
extension provides scale.

"Requirement 2.2.6: The more formal
protocol MUST be capable of meeting its
other functional and performance requirements when every
single SUBSCRIBER specification. It has SUBSCRIPTIONS also been changed to PRESENTITIES in
hundreds of distinct DOMAINS." Section 9 discusses the
means by which our extension provides scale.

"Requirement 2.4.1: The protocol MUST allow align with the creation of a
SUBSCRIPTION both directly and via intermediaries, such as
PROXIES."
SIP supports proxies, but they are optional. User
agents can communicate directly. This feature is inherited
by this extension.

"Requirement 2.4.2: event architecture and with CPIM. The specific protocol MUST allow the sending of a
NOTIFICATION both directly and via intermediaries, such as
PROXIES." changes
resulting from this rewrite are:

o The use of Record-Routing described here, and Event header must now be used in
RFC2543 [2] means that notifications can go directly from
presence agent to subscriber, or through proxies, as the
policy of each proxy dictates.

"Requirement 2.4.4: The protocol proxying facilities and
transport practices MUST allow ADMINISTRATORS ways to
enable and disable protocol activity through existing SUBSCRIBE and
commonly-deployed FIREWALLS. NOTIFY
requests.

o The protocol MUST specify how
it can be effectively filtered by such FIREWALLS." Although
SIP itself runs on port 5060 by default, any other port SUBSCRIBE message can
be used. It is simple to specify that presence should run
on only have a different port, if so desired.

"Requirement 2.5.1: single Contact header.
-00 allowed for more than one.

o The protocol MUST provide means to ensure
confidence that a received message (NOTIFICATION or INSTANT
MESSAGE) has not been corrupted or tampered with." SIP
provides end to end authentication From and message integrity
using PGP; other mechanisms To headers can be specified.

"Requirement 2.5.2. contain presence URIs.

o The protocol MUST provide means Request-URI can contain a presence URI.

o Subscriptions are responded to ensure
confidence that with a received message (NOTIFICATION 202 if they are pending
or INSTANT
MESSAGE) has accepted.

o Presence documents are not been recorded returned in the body of the
SUBSCRIBE response. Rather, they are sent in a separate
NOTIFY. This more cleanly separates subscription and played back
notification, and is mandated by an
adversary." Replay attacks can be prevented through either
challenge-response authentication, timestamp based checks, 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 storage rejected subscriptions.

o A rate limit on notifications was introduced.

o Merging of previously used sequence numbers and
transaction identifiers. See Section 10.4.

"Requirement 2.5.3: presence data has been removed.

o The protocol MUST provide means to ensure
that a sent message (NOTIFICATION or INSTANT MESSAGE) is
only readable by ENTITIES subscriber rejects notifications received with tags that
don't match those in the sender allows." SIP
provides end-to-end encryption using PGP.

"Requirement 2.5.4: The protocol MUST allow any client 202 response to use the SUBSCRIBE. This
means to ensure non-corruption, non-playback, and
privacy, but the protocol MUST NOT require that all clients
use these means at all times." SIPs security mechanisms are
optional.

"Requirement 3.1.1: All ENTITIES MUST produce and consume at
least a common base format only one PA will hold subscription state for PRESENCE INFORMATION." Here,
we mandate the Lightweight Presence Information Data Format
(LPIDF) [10].

"Requirement 3.2.1. A FETCHER MUST be able to fetch a
PRESENTITY's PRESENCE INFORMATION even when the PRESENTITY
is OUT OF CONTACT." The extension described here defines a
fetch operation that can be made on a presence server; this
server handles subscriptions and fetches when
particular subscriber for a presence
client is not available.

"Requirement 3.2.2: A SUBSCRIBER MUST be able to request particular presentity.

o IM URLs allowed in Contacts in register

o CPIM mappings defined.

o Persistent connections recommended for firewall traversal.

Obtaining Authorization

When a
SUBSCRIPTION to subscription arrives at a PRESENTITY's PRESENCE INFORMATION, even
when PA, the PRESENTITY is OUT OF CONTACT." Subscriptions are
handled subscription needs to be
authorized by a presence server when the presence client presentity. In some cases, the presentity may have
provided authorization ahead of time. However, in many cases, the
subscriber is not available.

"Requirement 3.2.3: If the PRESENCE SERVICE has SUBSCRIPTIONS
for a PRESENTITY's PRESENCE INFORMATION, and pre-authorized. In that PRESENCE
INFORMATION changes, case, the PRESENCE SERVICE MUST deliver a
NOTIFICATION PA needs to each SUBSCRIBER, unless prevented by query
the presentity for authorization.

In order to do this, we define an implicit subscription at the
PRESENTITY's ACCESS RULES." PA.
This subscription is supported as described
in Section 7.

"Requirement 3.2.4. The protocol MUST provide a mechanism for
detecting when a PRESENTITY or SUBSCRIBER has gone OUT OF
CONTACT." The SIP REGISTER method virtual presentity, which is used the "set of
subscriptions for this purpose.

"Requirement 3.2.5: The protocol MUST NOT depend on a PRESENTITY
or SUBSCRIBER gracefully telling presentity X", and the service subscriber to that it will
no longer be in communication, since virtual
presentity is X itself. Whenever a PRESENTITY or
SUBSCRIBER may go OUT OF CONTACT due subscription is received for X,
the virtual presentity changes state to unanticipated
failures." Registrations reflect the new subscription
for X. This state changes for subscriptions that are soft state, approved and will timeout
if not refreshed.

"Requirement 3.3.1: The protocol MUST include mechanisms to
allow PRESENCE INFORMATION to be cached." Although not
explicitly described here, this is easily supported as an
implementation improvement.

"Requirement 3.3.2: The protocol MUST include mechanisms to
allow cached PRESENCE INFORMATION to be updated for
ones that are pending. As a result of this, when the
master copy changes." Presence data contains timestamps a subscription
arrives for which authorization is needed, the state of the virtual
presentity changes to indicate its expiration; this forces a fetch to go to
the PA after expiration.

"Requirement 3.3.3: pending subscription. The protocol caching facilities MUST NOT
circumvent established ACCESS RULES or restrict choice entire
state of
authentication/encryption mechanisms." The protocol does
not explicitly circumvent access rules when caching is
used; however, if the caching server does not choose virtual presentity is then sent to
authenticate or authorize subscribers, no protocol in the
world subscriber (the
presentity itself). This way, the user behind that presentity can prevent this.

"Requirement 3.4.1 When a PRESENTITY changes its PRESENCE
INFORMATION, any SUBSCRIBER to see
that information MUST be
notified of there are pending subscriptions. It can then use some non-SIP
means to install policy in the changed information rapidly, except when
such notification is entirely prevented by ACCESS RULES. server regarding this new user. This requirement is met if each SUBSCRIBER's NOTIFICATION
policy is transported as rapidly as an INSTANT MESSAGE would be
transported then used to an INSTANT INBOX." SIP is engineered either accept or reject the subscription.

A call flow for
rapid transfer of messages. this is shown in Figure 3.

In fact, SIP (and the case where the presentity is not online, the problem is also
straightforward. When the user logs into their presence
extension) allows notifications client, it
can fetch the state of the virtual presentity for X, check for
pending subscriptions, and for each of them, upload a new policy
which indicates the appropriate action to go directly from
presence agent take.

A data format to subscriber.

15 represent the state of these virtual presentities
can be found in [14].

A 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

B Authors Addresses

Jonathan Rosenberg
dynamicsoft
| SUBSCRIBE X | |
| -------------------> | |
| | |
| 202 Accepted | |
| <------------------- | NOTIFY X-subscriptions|
| |---------------------->|
| | |
| | 200 Executive Drive
Suite 120
West Orange, OK |
| |<----------------------|
| | |
| | |
| | HTTP POST w/ policy |
| |<----------------------|
| | |
| | 200 OK |
| |---------------------->|
| | |
| | |
| | |

Figure 3: Sequence diagram for online authorization
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07052 07936
email: jdrosen@dynamicsoft.com

Dean Willis
dynamicsoft
200 Executive Drive
5100 Tennyson Parkway
Suite 120
West Orange, NJ 07052 1200
Plano, Texas 75024
email: dwillis@dynamicsoft.com

Robert Sparks
dynamicsoft
200 Executive Drive
5100 Tennyson Parkway
Suite 120
West Orange, NJ 07052 1200
Plano, Texas 75024
email: rsparks@dynamicsoft.com

Ben Campbell
dynamicsoft
200 Executive Drive
5100 Tennyson Parkway
Suite 120
West Orange, NJ 07052 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
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

C 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] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and
callee capabilities," A. Roach, "Event notification in SIP," Internet Draft, Internet
Engineering Task Force, Mar. Oct. 2000. Work in progress.

[4] M. Handley and V. Jacobson, "SDP: session description protocol,"
Request for Comments 2327, Internet Engineering Task Force, Apr.
1998.

[5] R. Stewart D. Crocker et al. , "Simple control transmission protocol," "A common profile for instant messaging
(CPIM)," Internet Draft, Internet Engineering Task Force, Apr. Nov. 2000.
Work in progress.

[6] J. Rosenberg and

[5] P. Calhoun, A. Rubens, H. Schulzrinne, "SCTP as a transport for SIP," Akhtar, and E. Guttman, "DIAMETER base
protocol," Internet Draft, Internet Engineering Task Force, June Sept.
2000. Work in progress.

[7]

[6] C. Rigney, S. Kent Willens, A. Rubens, and R. Atkinson, "IP encapsulating security payload
(ESP)," W. Simpson, "Remote
authentication dial in user service (RADIUS)," Request for Comments 2406,
2865, Internet Engineering Task Force,
Nov. 1998.

[8] June 2000.

[7] J. Boyle, R. Cohen, D. Harkins Durham, S. Herzog, R. Rajan, and D. Carrel, A.
Sastry, "The internet key exchange (IKE)," COPS (common open policy service) protocol," Request for
Comments 2409, 2748, Internet Engineering Task Force, Nov.
1998.

[9] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, Jan. 2000.

[8] H. Schulzrinne,
J. Lennox, C. Huitema, B. Aboba, Schulzrinne and D. Gurle, J. Rosenberg, "SIP extensions for
presence authorization," caller preferences and
callee capabilities," Internet Draft, Internet Engineering Task
Force, June July 2000. Work in progress.

[10]

[9] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, Drew, and H. Schulzrinne,
J. Lennox, C. Huitema, B. Aboba, "Getting SIP through
firewalls and D. Gurle, "A lightweight
presence information data format (LPIDF)," NATs," Internet Draft, Internet Engineering Task Force, June
Feb. 2000. Work in progress.

[11]

[10] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, Rosenberg and H. Schulzrinne,
J. Lennox, C. Huitema, B. Aboba, "SIP traversal through
enterprise and D. Gurle, "A data format for
presence using XML," residential NATs and firewalls," Internet Draft,
Internet Engineering Task Force,
June Nov. 2000. Work in progress.

[12] J. Boyle, R. Cohen, D. Durham,

[11] S. Herzog, R. Rajan, Kent and A.
Sastry, "The COPS (common open policy service) protocol," R. Atkinson, "IP encapsulating security payload
(ESP)," Request for Comments 2748, Internet Engineering Task Force, Jan. 2000.

[13] J. Lennox and H. Schulzrinne, "CPL: a language for user control
of internet telephony services," Internet Draft, Internet Engineering
Task Force, Mar. 1999. Work in progress.

[14] J. Lennox and H. Schulzrinne, "Transporting user control
information in sip register payloads," Internet Draft, 2406, Internet Engineering Task Force, Mar. 2000. Work in progress.

[15]
Nov. 1998.

[12] T. Dierks and C. Allen, "The TLS protocol version 1.0," Request
for Comments 2246, Internet Engineering Task Force, Jan. 1999.

[16]

[13] B. Ramsdell and Ed, "S/MIME version 3 message specification,"
Request for Comments 2633, Internet Engineering Task Force, June
1999.

[17]

[14] J. Rosenberg and H. Schulzrinne, "SIP extensions for managing
persistent connections," Internet Draft, Internet Engineering Task
Force, June 2000. Work in progress.

[18] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant messaging
/ presence protocol requirements," Request for Comments 2779,
Internet Engineering Task Force, Feb. 2000.

[19] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne,
J. Lennox, C. Huitema, B. Aboba, and D. Gurle, "SIP extensions et al. , "An XML based format for
instant messaging," watcher
information," Internet Draft, Internet Engineering Task Force, June
2000. Work in progress.

[20] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)," Request for Comments
2782, Internet Engineering Task Force, Feb. 2000.

Table of Contents

1 Introduction ........................................ 1
2 Why use SIP as a base protocol for presence? ....... 3
3 Definitions ......................................... 6
4 2
3 Overview of Operation ............................... 8
4.1 Architecture ........................................ 8
4.2 Message Flow ........................................ 8 3
4 Naming .............................................. 4
5 Presence Event Package .............................. 5 Subscriptions ....................................... 16
5.1 Generating subscriptions ............................ 16 Package Name ........................................ 5
5.2 Sending subscriptions ............................... 19 SUBSCRIBE bodies .................................... 5
5.3 Proxying subscriptions .............................. 20 Expiration .......................................... 5
5.4 Presence server processing of SUBSCRIBE ............. 20 NOTIFY Bodies ....................................... 6
5.5 Presence agent processing of SUBSCRIBE .............. 21
5.5.1 Refreshes ........................................... 21
5.5.2 New subscriptions ................................... 22 Processing Requirements at the PA ................... 6
5.6 Subscriber processing Generation of SUBSCRIBE response ......... 23 Notifications ......................... 7
5.7 Unsubscribing ....................................... 24 Rate Limitations on NOTIFY .......................... 8
5.8 Fetching ............................................ 24 Refresh Behavior .................................... 9
6 Publication ......................................... 24 9
6.1 Migrating the PA Function ........................... 10
7 Notification ........................................ 26 Mapping to CPIM ..................................... 11
7.1 When SIP to send ........................................ 26 CPIM ......................................... 11
7.2 Formatting of NOTIFY ................................ 27
7.3 Responding CPIM to NOTIFY ................................ 28 SIP ......................................... 14
8 Access controls ..................................... 28 Firewall and NAT Traversal .......................... 16
9 Providing scalability ............................... 29
9.1 Partitioning of the namespace ....................... 30
9.2 Client notifications ................................ 31
9.3 Distributed subscription state ...................... 31
10 Security considerations ............................. 34
10.1 17
9.1 Privacy ............................................. 34
10.2 17
9.2 Message integrity and authenticity .................. 35
10.3 18
9.3 Outbound authentication ............................. 35
10.4 18
9.4 Replay prevention ................................... 36
10.5 18
9.5 Denial of service attacks ........................... 36
10.5.1 19
9.5.1 Smurf attacks through false contacts ................ 36
10.5.2 Annoyance subscriptions ............................. 37
10.6 Firewall traversal .................................. 37
11 Addressing Transport ................................ 37
12 Required SIP features ............................... 39
12.1 Needed components ................................... 39
12.2 Components not needed ............................... 40
13 19
10 Example message flows ............................... 41
13.1 19
10.1 Client to Client Subscription with Presentity
State Changes .................................................. 41
13.2 19
10.2 Presence Server with Client Notifications ........... 45
13.3 Presence Server Notifications ....................... 51
13.4 23
10.3 Presence Server Notifications with Client
Authorization of Subscription .................................. 54
13.5 Delayed Subscription Approval ....................... 60
14 Checklist of requirements ........................... 64
15 28
11 Open Issues ......................................... 32
12 Changes from -00 .................................... 32
A Acknowledgements .................................... 68
16 34
B Authors Addresses ................................... 69
17 34
C Bibliography ........................................ 70 37