alcatel lucent wp simple based presence v2.4

8/13/2019 Alcatel Lucent WP SIMPLE Based Presence v2.4

1/44

Franois Leygues

Thomas Froment

Jol Repiquet

V2.4 April 2007

Telecommunication

Application Servers

SIP/SIMPLE-based Presence Services


2/44

Copyright 2007 Alcatel-Lucent. All Rights Reserved.

Telecommunication Application ServersSIP/SIMPLE-based Presence Services White Paper (V2.4 04/2007) Page 2

Contents

Executive Summary..................................................................................................................41

Introduction...................................................................................................................5

2 The SIMPLE Presence Environment ......................................................................................73 From Presentity to Watchers............................................................................................ 10

3.1 Overview............................................................................................................103.2 Publication on behalf of a presentity ..........................................................................113.3 Notifying watchers of presence information ..................................................................13

4 Presence Information..................................................................................................... 144.1 The Data Model for Presence ....................................................................................144.2 Presence Data Structure..........................................................................................144.3 RPID: Rich Presence Extensions to PIDF........................................................................174.4 Other PIDF Extensions.............................................................................................20

4.4.1 Timed Presence .........................................................................................204.4.2 CIPID: Contact Information for the PIDF ............................................................204.4.3 Geographic Location PIDF extensions................................................................214.4.4 SIP User Agent Capabilities Extensions to PIDF ....................................................22

4.5 OMA specific PIDF extensions....................................................................................235 Document Processing at the Presence Server ....................................................................... 24

5.1 Document Composition ...........................................................................................245.2 Privacy Filtering ...................................................................................................265.3 Watcher Filtering ..................................................................................................29

6 Presence winfo Notification.......................................................................................... 317 XCAP and XML Document Management................................................................................ 32

7.1 Document Management via XCAP ...............................................................................327.2 Subscribing to Changes in the XML Documents................................................................34

8 Subscription to a Presence List via RLS ............................................................................... 359 Optimization Features.................................................................................................... 37

9.1 Partial Publication / Notification ...............................................................................379.2 Content Indirection................................................................................................389.3 Notification Throttling............................................................................................389.4 Compression........................................................................................................38

10 Usage of Presence by other Services .................................................................................. 3911 Use Cases .................................................................................................................... 40

11.1 Use case #1: privacy management via the sphere presence element ..................................4011.2 Use case #2: relationship management ........................................................................4111.3 Use case #3: presence authorization ...........................................................................4211.4 Use case #4: unavailability.......................................................................................42

List of abbreviations ............................................................................................................... 43References........................................................................................................................... 43

IETF RFCs and Drafts ........................................................................................................43OMA Specifications ..........................................................................................................44


3/44



3GPP Specifications .........................................................................................................44Glossary .............................................................................................................................. 44

List of Figures

Figure 1: IETF standardization work on Presence and IM ....................................................................... 5Figure 2: IETF - 3GPP - OMA support for Presence............................................................................... 6Figure 3: Presence Overview ........................................................................................................ 7Figure 4: Example of Presence Network Agent ................................................................................... 8Figure 5: Presence-related Servers................................................................................................. 9Figure 6: Presence Document Generation Process..............................................................................10Figure 7: Initial Presence Publication.............................................................................................11Figure 8: Presence Publication Refresh...........................................................................................12Figure 9: Presence Publication Modification .....................................................................................12Figure 10: Watchers subscription and notifications............................................................................13Figure 11: Presence Data Model ...................................................................................................14Figure 13: PIDF Structure ...........................................................................................................15Figure 12: Presence Data Model Format..........................................................................................16Figure 14: RPID element to data model component mapping table..........................................................17Figure 15: Example of RPID-based document....................................................................................19Figure 16: Example of timed-status element ....................................................................................20Figure 17: Example of contact information ......................................................................................20Figure 18: Example of geopriv element with GPS coordinates in GML.....................................................21Figure 19: Example of geopriv element with the use of a civicLoc object................................................22Figure 20: User Agent Capability Presence Status ..............................................................................22Figure 21: Document Composition.................................................................................................25Figure 22: Privacy Filtering Rules..................................................................................................26Figure 23: Privacy Filtering Example..............................................................................................28Figure 24: Watcher Filtering - Example 1 ........................................................................................29Figure 25: Watcher Filtering - Example 2 ........................................................................................30Figure 26: Presence Watcher Information Example.............................................................................31Figure 27: XDMS environment ......................................................................................................32Figure 28: HTTP URI for XCAP ......................................................................................................33Figure 29: Subscription authorization rules update by the Presentity .......................................................34Figure 30: Subscription to a Presence List via the RLS .........................................................................35Figure 31: RLS Notification as a multipart/related MIME type................................................................36Figure 32: Partial Publication ......................................................................................................37Figure 33: Use of the Presence Service with PoC ...............................................................................39Figure 34: Use case #1 - Bob at home.............................................................................................40Figure 35: Use case #1 - Bob goes to work .......................................................................................41Figure 36: Use case #2 - Bob is in a meeting.....................................................................................41Figure 37: Use case #3 - presence authorization and Push-to-Share.........................................................42


4/44



Executive Summary

Presence services enable entities to expose their ability and willingness to communicate with other entities. For a

long time, proprietary solutions have been used by ISPs for offering instant messaging services coupled with presence.

Unsurprisingly, these products could not interoperate. In 1999, the IETF (the Internet standardization body) createdthe IMPP (instant messaging and presence protocol) working group that a year later defined a model for presence and

the requirements for both instant messaging and presence protocols. Based on this initial work, two solutions have

emerged at the IETF: XMPP (extensible messaging and presence protocols) and SIMPLE (SIP for instant messaging and

presence leveraging extensions). XMPP is oriented XML streaming while SIMPLE re-uses SIP signalling. This paper

explores the SIP/SIMPLE solution also adopted by the 3GPP for IMS and by the OMA.

The focus is first on how presence element user agents publish presence information to a presence server on behalf of

presence entities, aka presentities, and how it is distributed to watchers who have required it via the subscribe and

notify event state mechanisms. At this stage, the document processing at the presence server is simply outlined since

a more accurate understanding of presence information is required for going in more detail.

The base format of presence information is PIDF (presence information data format) that uses XML for enabling a

hierarchical and extensible structure, as per the IMPP initial requirements. PIDF is an outcome of the IMPP working

group and is compliant to the CPP (common profile for presence) that enables the creation of gateways between

different systems. For SIP/SIMPLE, PIDF is supplemented by the Data Model and by RPID, as well as several other

extensions related to geographical location and user agent capabilities.

[...]


5/44



1 Introduction

Presence services enable general-purpose entities to expose their ability, willingness and desire to communicate with

other entities. These services have been increasingly developed during the last decade, in combination with Instant

Messaging (IM). As a result, several Presence/IM systems have emerged (such as AOL, IBM, ICQ, MSN, Yahoo ones),

based on proprietary protocols and therefore not interoperable, excepted in case of bilateral agreements.

Figure 1 illustrates the standardization work carried out at the IETF, from 1999, in regards to presence and instant

messaging. The purpose of the IMPP working group was first to define an abstract model for presence and instant

messaging, and the requirements for a transport protocol enabling the distribution of messaging and presence

information. This led, around 2001-2002, to the creation of two other working groups: SIMPLE and XMPP that proposed

different approaches. The purpose of the XMPP working group was to extend the deployed XMPP protocol, an XML

streaming technology originally implemented by the Jabber open-source community, in order to be conformant to the

IMPP requirements (RFC 2779). Likewise, the purpose of the SIMPLE working group was to extend the SIP signaling

protocol in order to fulfill the model and the protocol requirements defined by the IMPP working group.

This white paper is focused on the SIP/SIMPLE-based Presence system specified at the IETF, and adopted by the 3GPP

for IMS, and also the Open Mobile Alliance (OMA) in the context of the services it standardizes.

Figure 1: IETF standardization work on Presence and IM


6/44



XMPP is already deployed through Jabber, while SIMPLE-based implementations are only emerging. It is expected that

XMPP and SIMPLE will coexist in the future, and the interoperability between XMPP and SIMPLE is currently addressed

by the saintandre-xmpp-simple IETF draft, which is based on the specifications released by the IMPP working group.

The SIMPLE working group has already released a set of RFCs and many drafts, currently used by early

implementations, will be edited as RFCs soon. From the time the SIP specification version 2.0 was released, in June

2002, a considerable work has been carried out and numerous extensions have been brought to the SIP protocol. The

features of interest for the presence requirements are in particular the routing of requests and the event framework.The extensibility of SIP has proven to be very useful and especially efficient for presence and instant messaging.

As outlined earlier, the 3GPP (which had already adopted SIP as a session signaling protocol for IMS) follows the

SIMPLE specifications for offering Presence services in IMS. Similarly, its counterpart 3GPP2 uses SIMPLE for its MMD.

The 3GPP specifications clarify the presence roles with respect to the IMS architecture. The OMA, which is focused on

service definitions and interoperability, especially in the IMS (and MMD) context, refines and supplements when

necessary both the IETF and IMS specifications. The relationship between the IETF, 3GPP and OMA organizations is

illustrated in Figure 2.

IETF (Internet Engineering Task Force)

SIP/SIMPLE Presence Pr ot ocol s

3GPP (Third Generation Partnership Project)

Implement at ion of IETF SIP/SIMPLE specif icat ions

in IMS (IP Mult imed ia Subsyst em)

3GPP2 (Third Generation Partnership Project 2)

Implement at ion of IETF SIP/SIMPLE specif icat ions

in MMD (Mult i Media Domain)

OMA (Open Mobile Alliance)

OMA Presence SIMPLE: Appl icat ion-l evel semant ics fo r SIP/SIMPLE-based Presence, guidel ines f or use...

Figure 2: IETF - 3GPP - OMA support for Presence

Note: Besides and prior to OMA Presence SIMPLE, the OMA has released a set of specifications, referred to as

IMPS (instant messaging and presence service) that is directly derived from the Wireless Village initiative.

OMA IMPS is not SIP-based and should not be confused with OMA Presence SIMPLE.


7/44



2 The SIMPLE Presence Environment

Figure 3 depicts the presence environment based on SIP/SIMPLE.

A Presence service is the transfer of information, via a Presence Server, from a presentity (presence entity) to one or

more watchers, aimed at facilitating and optimizing the communications between them, by using the mostappropriate means at the most opportune time. In most of the cases, the presentity is a human user, but it can also

represent a group of people such as a help desk or a radio station. One or more presence element agents (this term is

defined by the 3GPP) push presence information, at different times, into the presence server on behalf of the

presentity. A presence element agent is an intermediary between the presentity and the presence server. A presence

server is sometimes called a presence agent, however in the remainder of this paper the term presence server will

be used for avoiding ambiguity.

SIP/SIMPLEEnvironment

PresentityPresentity

PresenceNetwork

Agent

NOTIFY

Watcher3rd-Party

ApplicationWatcher

OtherApplication

Server

Any Domai n,

including A and B

PUBLISH

PresenceServer

RLS(Resource

ListServer)

PresenceServer

RLS(Resource

ListServer)

PresenceUserAgent

PresenceNetwork

Agent

PresenceUserAgent

PresenceNetwork

Agent

PresenceUserAgent

PUBLISH

NOTIFYNOTIFYNOTIFY

Domain

A

Domain

B

Handset s,

network elements,

3 rd par t y app l i ca t ions

(e.g. calendar ),

appl icat ion servers. . .

Figure 3: Presence Overview


8/44



As per the 3GPP, there are 3 types of presence element agents: PUA, PNA and PEA. Here are their definitions:

Presence User Agents (PUA)A PUA is a presence source that resides in a terminal or in the network. The PUA interacts with the user for

collecting user-related presence information and sending it to the presence server.

Presence Network Agents (PNA)A PNA collects network-related information, associated to a presentity, from various network elements in thesame administrative network and sends it to the presence server. Examples of network elements from which a

PNA collects presence information are, considering an IMS network with a radio access network: the MSC

Server/VLR, the SGSN, the GGSN, the GMLC (Gateway Mobile Location Center), the HSS (Home Subscriber

Server), and the S-CSCF.

As shown in Figure 4, a PNA could interact both with the HSS, via the DIAMETER-based Sh reference point, and

the S-CSCF, via the SIP-based ISC reference point, for collecting subscription and registering information,

transforms it as presence information and pushes it into the presence server.

Figure 4: Example of Presence Network Agent

Presence External Agents (PEA)A PEA collects presence information from external networks, resolves the location of the relevant presence

server, depending on the presentity, and pushes presence information into it.

The SIP routing infrastructure and the SIP event framework are the main mechanisms used for interacting with the

presence server. A presentity is uniquely identified by a URI (uniform request identifier) that is either a protocol-

agnostic pres URI or a SIP URI. A presence user agent will issue a SIP PUBLISH request addressed to the presentity

URI. The classical DNS-based SIP location services are used to reach the relevant presence server. Presence

information is conveyed as a MIME content-type in the body of PUBLISH messages.

The responsibility of the presence server is then to aggregate the presence information related to a presentity, and to

deliver it to potential watchers according to the presentity authorization rules, and also to the information subset

possibly required by the watchers. A watcher listens to presence information about a presentity via the SIP

SUBSCRIBE/NOTIFY mechanisms. Here again, the SIP routing enables a watcher to address direcly the presence server

that serves this presentity. He will then be notified every time new presence data is available.

When a watcher wants to be informed about several presentities, it may use a presence list (a buddy list) and address

its subscription, via a SIP URI representing this list, to a resource list server (RLS). This latter is typically co-located


9/44



with the presence server of the same domain. The presentities in the list may belong to the same domain or to

another domain, in which case the RLS will issue so-called back-end subscriptions to the relevant presence server.

Figure 5 shows in more detail the servers that are required when a SIP/SIMPLE-based presence service is offered in a

single domain. Both the Presence Server and the Resource List Server are respectively supplemented with XDM-

specific servers: the Presence XDM server and the RLS XDM server. XDMS (XML document management service) relates

to the management of user-related configuration data. On the one hand, a watcher can create and update presence

lists via HTTP/XCAP. On the other hand, the RLS can get the contents of presence lists either directly via HTTP/XCAP,or listen to changes in presence lists via the SIP SUBSCRIBE/NOTIFY mechanism.

Similarly, a presentity can create and update his/her authorization rules via HTTP/XCAP, and in turn, the presence

server can directly get those rules, or listen to changes to those rules.

Figure 5: Presence-related Servers

The presentity may also get information about watchers by subscribing to the presence.winfo event. In particular,

the presentity may be informed in near real-time of a watcher subscription attempt that would be in a pending state

because not identified and authorized yet. As a result, the presentity could give permissions to this watcher or not.


10/44



3 From Presentity to Watchers

3.1 Overview

Figure 6 illustrates the processing of presence information for a single presentity, several sources and two watchers.

This process is invoked by the Presence Server under several conditions: source changes, policy changes, watcherinitial subscriptions or refreshes.

PresenceServer

PUBLISH

View 2

CompositionPolicy

PUBLISH PUBLISH

Composition

Raw PresenceDocument

(related to Alice)

PresenceSource 1

PresenceSource 2

PresenceSource 3

View 1 View 3

Filtered PresenceDocument

(Carol)Watchers

Policy

Watcher(Carol)

Privacy Filtering

Watcher Filtering

Candidate PresenceDocument(for Carol)

NOTIFY

(presence)

SUBSCRIBE

(presence)

Privacy Filtering

Filtered PresenceDocument

(Bob)Watchers

Policy

Watcher(Bob)

Watcher Filtering

Candidate PresenceDocument(for Bob)

NOTIFY

(presence)

SUBSCRIBE

(presence)

Authorization Authorization

(Alice)Presence

AuthorizationRules

(content) (content)

(subscription) (subscription)

Presentity(Alice)

Figure 6: Presence Document Generation Process


11/44



One or more presence user or network agents may, over time, push presence information into a presence server, on

behalf of a presentity. From this collection of views, the presence server produces a single raw presence document.

The remainder of the processing consists in filtering operations that depend on watchers. First, the presence server

applies a privacy filtering operation based on the presentitys authorization policy. For example, the presentity may

restrict presence information to her/his home environment only for some watchers. Any change to this policy by the

presentity will entail a new application of this filtering action. The outcome of privacy filtering is one candidate

presence document per current watcher. Before notification to a watcher, the presence server will apply a second

filtering, depending on whether or not this watcher has sent its own filtering rules at subscription time. For example,

a watcher may only be interested in instant messaging communication regarding a presentity.

In the remainder of this section, the publication by PUAs or PNAs of presence information and the notification of

presence information to watchers is examined in more detail. The processing performed on presence information by

the presence server requires the understanding of presence data structure, described in section 4, and is therefore

discussed in section 5.

3.2 Publication on behalf of a presentity

Presence Information related to a presentity is pushed into the presence server by potentially several presence user

agents or presence network agents, on behalf of this presentity. This section describes the way one PUA or PNA (in the

illustrations, a PUA is represented) publishes presence data over time.

Publication of presence information is performed via the PUBLISH SIP method with the presence event. This method

is generic and can be applied to any event package defined for SIP. However, at the time it was defined, its main

application was presence.

From the PUBLISH method perspective, the user agent client (UAC) that publishes event state is an Event Publication

Agent (EPA) and the entity that processes it is an Event State Compositor (ESC). Since several user agents can

potentially publish different states for a given event, the role of the ESC is to generate a composite event state for

the resource, for delivery to potential subscribers. For Presence, the EPA will typically be located in a presence user

agent (PUA) and the ESC in the presence server. The ESC then can be referred to as a presence compositor.

The PUBLISH method is similar to the REGISTER method in that it enables a user to create, modify and remove event-

related information in another entity, which then manages this information on behalf of the user. A PUBLISH request

does not establish a dialog. The Request-URI of the Presence PUBLISH request will contain the pres-URI or SIP URI of

the presentity. This URI must be the same URI as the one placed in the element of the PIDF document.

For each successful PUBLISH request, the ESC generates an entity-tag that is returned in the SIP-ETagheader field.

Figure 7: Initial Presence Publication


12/44



The presence event is a soft state event, that is to say: the presence state is maintained for a limited time

negotiated between the PUA and the presence server. When the timer is going to expire, it is the responsibility of the

PUA to refresh the presence state of its presentity. As illustrated in Figure 8, this is performed by issuing a new

PUBLISH request without content, but with the current entity tag value placed in the SIP-If-Ma t chheader field, for

enabling the presence server to correlate the corresponding presence state document. The presence server will return

another entity tag value to be used by the next PUBLISH request, if any. It can also reduce the duration of the

presence state.

It should be noted that a zero value in the Expiresheader field of the PUBLISH request enables a PUA to remove its

presence state information.

Figure 8: Presence Publication Refresh

When presence information changes, as seen by a PUA, this latter publishes a new PIDF document that will replace

the current one. This is done by providing both a SIP-If-Match value and the PIDF document as the content of the

PUBLISH request.

Figure 9: Presence Publication Modification


13/44



3.3 Notifying watchers of presence information

For receiving presence information related to a presentity, a watcher must require it to the presence server. This is

performed via the SUBSCRIBE and NOTIFY SIP requests applied to the presence event package, defined in [RFC3856].

The watcher issues a SUBSCRIBE request addressed to the presentity SIP URI. At the same time, it may also provide its

own filtering rules in the body of the subscribe request, according to the application/simple-filter+xml [RFC4661]

MIME content-type. This request is then routed via one or more SIP proxies to the relevant presence server, by

application of the classical SIP server location mechanisms [RFC3263].

The presence server, on behalf of the presentity, may accept or reject the subscription. Nevertheless, in case of

acceptation, it may place it in a pending state, meaning that there is insufficient policy information to grant or deny

the subscription yet, and wait for an authorization from the presentity.

Note: Typically, via a subscription to the presence.winfo event, the presentity will learn that there is a new

watcher in a pending state, and will modify, via HTTP/XCAP, its authorization rules at the XDM Server for

accepting it. The presence server, either by polling or via a subscription to the ua_profile SIP event

package, will be notified of any change in the authorization rules, and then be able to pass the watcher

subscription from a pending to active state.

A subscription has a duration time negotiated between the subscriber and the notifier, which is the presence server. A

subscriber proposes its own value in the Expiresheader field. This value may be equal to zero. This means that it acts

as a Fetcher and wants to get current presence information, whenever available, only once.

The subscriber may refresh its subscription at any time, either for explicitly providing new filtering rules, or because

it is going to expire, according to the negotiated duration time.

Watcher(Bob)

Presentity(Alice)

PUA PNAPUBLISH1

SIP/2.0 200 OK

Expires: 1800

Contact:

2

3

PUBLISH 5

PresenceServer

NOTIFY sip:[email protected]

Subscription-State: active;expires=1600

Event: presence

Contact:

Content-Type: application/pidf+xml

Content-Length: ...

[New PIDF Document]

NOTIFY sip:[email protected]

Subscription-State: active;expires=1799

Event: presence

Contact:

Content-Type: application/pidf+xml

Content-Length: ...

[PIDF Document]

SUBSCRIBE sip:[email protected]

Expires: 3600

Event: presenceContact:

Content-Type: application/simple-filter+xml

Content-Length: ...

[bobs filtering rules]

3

4

6

Figure 10: Watchers subscription and notifications


14/44



4 Presence Information

4.1 The Data Model for Presence

The data model for presence [RFC4779] gives guidance on how to map real-world communications systems, built

around SIP in particular, into a presence document. There are three components in the model: the person, the serviceand the device. Each attribute in a presence document is affiliated to the service, person or device because they

describe a facet of that service, presentity or device, independently of which piece of equipment has reported this

attribute.

Presentity URI

Service

Device

Person

Service

Device Device

Service

Figure 11: Presence Data Model

A single presentity may be represented by multiple URIs. It may be represented by a presentity URI or a protocol-

specific URI such as a SIP URI. It may also have several aliases. When the URI is a SIP URI, it will typically be the

Address of Record (AoR) for that user, to which SIP calls can be directed.

The person component models information about the presentity under consideration. A person may represent a

group such as a help desk. Examples of presence attributes related to a person are her/his activity, her/his willingness

to communicate, her/his picture. The model supports only one person component per presentity, although in someconflicting cases, at composition time, the presence server may keep more than one person component.

The service data components model the forms of communications for interacting with the presentity. Examples of

services through which a presentity may communicate are PoC (Push-to-talk over Cellular), IM (Instant Messaging),

SMS (short messaging service) or MMS (Multimedia Messaging Service). However, the meaning of service is broad and

there is not any list defined in [RFC4479]. This RFC says that a reasonable approach is to model each software or

hardware agent in the system as a service.

The device data components model the physical equipment in which services execute: for instance a PC, a PDA, or

a mobile phone. As a given service may execute in more than one device, the mapping of services to devices is many

to many. Devices are uniquely identified with a device ID.

4.2 Presence Data StructureThe structure of a presence document conformant to the data model is based on PIDF (Presence Information Data

Format) defined in [RFC3859] and compliant to the Common Profile for Presence [RFC3859]. Although PIDF is very


15/44



limited in describing presence, it is the basis of any presence data format. The root of an application/pidf+xml

MIME document is the element. This element has an entity attribute that identifies, as a pres or SIP

URI, the presentity publishing the presence document, and one or more XML namespace declarations (xmlns). It

must contain the urn:ietf:params:xml:ns:pidf namespace declaration and may contain other namespace

declarations for the extensions of the document. Here is an example:

All elements and some attributes are associated with a namespace, which is in turn associated with a globally

unique URI. Within the presence data, element or attribute names are associated with a particular namespace by a

namespace prefix (e.g. pdm, rpid). The prefix name is a local matter and there are no reserved names. the

default namespace is typically the pidf namespace: urn:ietf:params:xml:ns:pidf. Figure 12 shows the structure of

a PIDF document and highlights the possible extensions. A PIDF document without any extension is limited to providing

an address for communication () and an indication of availability via the element that can be either

open or closed. The elements may enrich the presence information with text but they can be interpreted

by a human observer only.

#n

#n

#n

#n

#n

#n

At this level, the Presence Data Model [RFC4479] defines two extensionelements: and

Figure 12: PIDF Structure

Figure 13 shows the general structure of a presence document conformant to the data model for presence. It is

constrained by the PIDF document structure. It adds the and elements as extension elements and

uses the existing element to represent the Service. It is to be enriched by the RPID format as well as some

other formats defined by the IETF, the OMA or any other organization. These new attributes will appear as children of, or . However, for backward compatibility with the PIDF format, they may appear as

children of .


16/44



The element can appear either before or after the element; there are no constraints on order.

#n

#n

#n

#n

#n

#n

#n

#n

#n

#n

#n

#n

#n

#n

The existing PIDF element is used to represent the Service

The element is used to encode the service URI

The element contains the URN: the version 4UUID as defined in [RFC4122] shall be used

There is only one element excepted in a fewseldom cases

Figure 13: Presence Data Model Format


17/44



4.3 RPID: Rich Presence Extensions to PIDF

Neither PIDF nor the data model defines presence attributes beyond the status element. [RFC4480] defines

additional presence attributes that extend the PIDF element and the and elements defined

in the data model. Generally, the extensions have been chosen to provide features common in existing presence

systems, in addition to elements that could readily be derived automatically from existing sources of presence, such

as calendaring systems or communication devices, or sources describing the user's current physical environment.

The following table shows which component of the data model for presence are potentially enriched by the elements

defined in RPID [RFC4480]. It also indicates whether the from / until attributes are applicable as well as whether

a element can be included in the element. Elements that do not have from/until parameters must not appear

more than once in each , , or .

Figure 14: RPID element to data model component mapping table

The element describes what the person is currently doing. A person can be engaged in multiple

activities at the same time, e.g., traveling and having a meal. This information enables a watcher to evaluate

how approppriate a communication attempt is and what is the better way for communicating. Here are some

examples of activities: away, appointment, meeting, meal, breakfast, lunch, dinner, busy, holiday, in-transit,

looking-for-work (for paid work), sleeping, travel...

Most of them can be derived from calendar information.

The element describes the class of the service, device, or person. Multiple elements can have the same

class name within a presence document, but each person, service, or device can only have one class label. The

naming of classes is left to the presentity.

The element represents a way to map a service component to a device component. One service can

be provided by multiple devices, so that each service tuple may contain zero or more elements.

The element describes the mood of the person. For example: confused, amazed.

The element describes properties of the place the person is currently at. This offers the watcher an

indication of what kind of communication is likely to be successful. Each major media type has its own set of

attributes:

audio (noisy, ok, quiet, unknown) video (toobright, ok, dark, unknown) text (uncomfortable, inappropriate, ok, unknown)


18/44



The element describes the type of place the person is currently at. This offers the watcher an

indication of what kind of communication is likely to be appropriate. The initial set of values is contained in

[RFC4589: Location Types Registry] and it is registered under the urn:ietf:params:xml:ns:location-type

namespace.

The element indicates which types of communication third parties in the vicinity of the presentity

are unlikely to be able to intercept accidentally or intentionally.

The element extends and designates the type of relationship an alternate contact has

with the presentity. This element is provided only if the tuple refers to somebody other than the presentity.

Relationship values include "family", "friend", "associate" (e.g., for a colleague), "assistant", "supervisor", "self",

and "unknown". The default is "self".

The element extends and designates the type of service offered: electronic, postal,

courier, freight, in-person...

The element designates the current state and role that the person plays. For example, it might

describe whether the person is in a work mode, at home, or participating in activities related to some other

organization such as the IETF or a church. [RFC4480] does not define names for these spheres except for two

common ones, "work" and "home", as well as "unknown".

Spheres allow the person to easily turn on or off certain rules that depend on what groups of people should be

made aware of the person's status.

The element includes a URI pointing to an image (icon) representing the current status of the

person or service. The watcher may use this information to represent the status in a graphical user interface.

The element describes the number of minutes of offset from UTC at the person's current

location. A positive number indicates that the local time-of-day is ahead (i.e., east of) Universal Time, while a

negative number indicates that the local time-of-day is behind (i.e., west of) Universal Time.

The element records the user-input or usage state of the service or device, based on human user

input, e.g., keyboard, pointing device, or voice.


19/44



Here is an example of presence document that follows the data model for presence and that is enriched by RPID

elements.

openurn:device:0003ba4811e3im:[email protected]'t Disturb Please!2005-10-27T16:49:29Z

open

mailto:[email protected]

openurn:x-mac:0003ba4811e3emailhttp://example.com/mail.pngmailto:[email protected]

I'll be in Tokyo next week

idleurn:device:0003ba4811e3PC

Far away

calendar

bowling leaguehttp://example.com/play.gif-240Scoring 1202005-05-30T16:09:44+05:00

Figure 15: Example of RPID-based document


20/44



4.4 Other PIDF Extensions

4.4.1 Timed Presence

The indication of status information for time intervals, either in the past or in the future, can be achieved via the

element, defined in [RFC4881] as a child of the element. Here is an example:

Figure 16: Example of timed-status element

4.4.2 CIPID: Contact Information for the PIDF

[RFC4482] describes elements for providing a "business card", including references to the homepage, map,

representative sound, display name, and an icon.

Figure 17: Example of contact information


21/44



4.4.3 Geographic Location PIDF extensions

[RFC4119: a Presence-based GEOPRIV location object format] describes an object format for carrying geographical

information. It extends the 'status' element of PIDF with a complex element called 'geopriv'. There are two mandatory

subelements that are encapsulated within geopriv: one for location information, and one for usage rules. [RFC4119]

defines also two optional subelements: and .

A location-info-element consists of one or more chunks of location information. PIDF implementations

supporting the 'geopriv' element must implement the GML: Geography Markup Language (GML) 3.0 defined by

the Open Geospatial Consortium. They may support the civil location format defined in [RFC4119].

The following child elements may be used:

The method element describes how the geographical location information was discovered. The methods are

registered at: http://www.iana.org/assignments/method-tokens. Examples are: GPS, Cell, and 802.11.

The element allows an explicit designation of the entity that provided the information.

Here is an example of geopriv element with the use of a simple GML 3.0 markup:

Figure 18: Example of geopriv element with GPS coordinates in GML

Here is another example with the use of the civilLoc object defined in [RFC4119].


22/44



Figure 19: Example of geopriv element with the use of a civicLoc object

4.4.4 SIP User Agent Capabilities Extensions to PIDF

As per [RFC3840], a SIP user agent may specify a number of capabilities about itself in the Cont actheader field at

REGISTER time. Similarly, as per [RFC3841] a caller may express its preferences when initiating a call to another UA.

The set of capabilities defined in [RFC3840] are reused and augmented for enhancing PIDF.

open

truetextual description of the servicetrue

sipfalse

sip:[email protected]

urn:uuid:d27459b7-8213-4395-aa77-ed859a3e5b3a

Figure 20: User Agent Capability Presence Status


23/44



4.5 OMA specific PIDF extensions

The list of OMA-specific PIDF extensions is registered at the OMNA: Open Mobile Naming Authority.

The element (under ) is used to describe OMA-specific services. It contains the following

child elements: , and optionally . Here is an example:

So far, the OMNA has registered the following services: PoC-session, PoC-alert and IM.

The element shall be used as a child element of the element. It shall include the element and have two values open and closed indicating willingness for communication.

The element shall be used as a child element of the element. It shall include

the element and have two values open and closed indicating overriding willingness.

The element can be used as a child element of the element. It includes one or

more child elements. Each element shall contain an id attribute indicating the type of

the network and shall include at least one of the following elements:

the element indicating that the particular device is connected to the specific network; and the element indicating that the particular device is not connected to the specific

network.

The element shall be used as a child element of the element. It includes the

element and have either

the value open indicating that the particular presentity is participating in at least one session of aspecific service; or

the value closed indicating that the presentity is not participating in any session of the specificservice.

The element, if present, shall be used as a child element of the element. It shallinclude either

the value active indicating that the particular presentity has an active registration with a specificservice; or

the value terminated indicating that the presentity does not have an active registration with aspecific service.

The element, if present, shall be used as a child element of the element. It shall

include either

the value active indicating that the particular presentity has activated communication barringpertaining to a specific service; or

the value terminated indicating that the presentity has deactivated communication barring pertainingto a specific service.


24/44



5 Document Processing at the Presence Server

An overview of presence processing was presented earlier and is shown in Figure 6. The Presence server, which is in

charge of collecting, storing and distributing presence information, performs a number of operations on presence

documents. The understanding of presence information, discussed in the previous section, was a prerequisite tohaving a closer look at those operations. Presence document processing is now examined with the following sequence

of operations: composition, privacy filtering and watcher filtering.

5.1 Document Composition

Presence document composition is still under study at the IETF, and there is not any MIME content type defined yet

for the composition policy document shown in Figure 21. However it could represent the minimal approach that has

been defined by the OMA, in the Presence SIMPLE specification. When several presence sources publish, at different

times, a presence view for a presentity, the presence server has to produce a common view, which is a superset of

what watchers will eventually obtain.

Composition is independent of watchers. The special case of polite-blocking, which consists in providing a minimal

presence view to the watcher instead of refusing his/her demand, is outside the composition process since the sameview will be offered over time, whatever the published views.

As described in section 4, the structure of a presence document is made up of a set of XML elements, each

element being related to one of the data model component types: person, service or device. Based on that, the

simple-composition IETF draft proposes a good analysis on this issue and defines four steps for composition that are

described briefly:

Discarding

Whole tuples corresponding to stale or redundant information can be removed: e.g. tuples that are

not referenced by any tuples, or tuples older than a given threshold but not yet expired depending

on the publish timer.

Derivation

This step consists in providing useful new data that has not been explicitly published. For instance, a user may

wish to indicate that when he is on-the-phone (an information that may be published automatically by the

UA once the connection is set up) this means that he is busy and should not be called except in an

emergency.

Conflict resolution

Multiple sources of information may provide contradictory information, for example about the person location

or activity. This may occur easily when the information is updated manually by the end-user. There may be

situations much more complex for which an automaton is unlikely to be able to detect contradictory

information and remove erroneous information.

Merging

This step consists in combining several tuples that logically represent the same information. An example of

merging is for the element that should appear only once, unless several ones could be left in some

conflicting situations. Another example is the merging of service tuples that would have the same contact URI.

Figure 21 depicts an example of document composition, quite simple. According to the first published view, just

before noon, Alice is attending a meeting. According to the second published view, by another presence source, Alice

is still at work but she is having lunch, and is reachable on her phone. The element of the second view is

retained in the raw presence document, which is the outcome of the composition operation.


25/44



View 1

Raw Presence Document

Composition

CompositionPolicy

View 2

openim:[email protected]

work


26/44



5.2 Privacy Filtering

Privacy filtering is the function performed by the presence server for removing from the raw presence document that

results of composition, all the data that is not explicitly authorized by the presentity for a given watcher. It

corresponds to the application of the transformation rules, in the presence authorization document, that are

applicable to this watcher. The outcome is a candidate presence document specific to a given watcher.

Presence Authorization Rules is an XML document related to a Presentity and stored at the Presence XML Document

Management Server (XDMS). It can be updated by the Presentity, and accessed by the Presence Server, using the

HTTP/XCAP interface. The Presence Server may cache this information and be notified of any changes to it by

subscribing to the ua-profile event for this resource. The Presence Authorization Rules document enables a

presentity to control who is authorized to watch her/his presence information, and also what a watcher is

authorized to see.

The framework for policy documents is defined in [RFC 4745 - common policy]. For Presence, it is extended by the

simple-presence-rules IETF draft. The presence authorization rules document inherits the MIME type of common

policy documents: application/auth-policy+xml. Accordingly, it is composed of a set of rules, each rule being

composed of three parts: conditions, actions and transformations.

Figure 22 summarizes, for each main category, the rules respectively defined in the RFC 4745, the simple-presence-

rules IETF draft, and also the OMA Presence XDM specification.

The OMA retains all the and rules defined by the IETF. However, for , it only

uses a subset.

yes

yes

yes

yes

yes

yes

yes

yes

yes

yes

yes

yes

Common Policy(RFC 4745)

PresenceAuthorization Rules

OMA Presence XDM

Figure 22: Privacy Filtering Rules


27/44



The presence server goes through each rule in the rule set. For each rule, it evaluates the expressions in the

conditions part. If the rule is applicable, the actions and transformations are applied.

The element is used for watcher subscription handling. The block, allow, confirm values tell

the presence server respectively to place the subscription in the rejected, accepted and pending state. The

polite-block value also places the subscription in an accepted state but it instructs the presence server to

produce a template document with minimal information.

If the value is allow the watcher is allowed to access presence information. The transformation rules

then are used for driving the privacy filtering operation. Each transformation defines the visibility a watcher is

granted to a particular component of the presence document.

Access permissions are defined at two levels:

Firstly, the , and transformation rules providecoarse-grained access to presence data by allowing or blocking specific services or devices, and allowing or

blocking person information.

Secondly, once person, device or service tuples have been authorized, specific rules are used to for allowing orblocking presence attributes within those data components.

For the first group of transformations, the following table shows the subelements that enable the identification of the

data components that a watcher is granted to view.

Regarding the second group of transformation rules, the following table shows the subelements that are always

reported in the data components:

The enables a user to specify a presence attribute name and a namespace that is not

supported by the presence server, because it is not upgraded yet, or because this is a proprietary attribute.

The grants access to all presence attributes in all the tuples that have been retained during

the first step.

Most of the other specific attributes are related to RPID.


28/44



Figure 23 illustrates the application of Alices privacy filtering for the watcher Bob. The raw presence document

related to Alice is the outcome of the document composition operation. In Alices presence authorization rules

document, there is one transformation rule applicable to Bob. Alice only wants to communicate with Bob via a

messaging system. This is reflected via the element. As a result, the tuple that includes a tel

contact URI is removed in the candidate presence document for Bob.

Alice's Presence Authorization Rules

allow

immailto

truebaretrue

Candidate Presence Document

closedIM

im:[email protected]

openEMAILmailto:[email protected]

Raw Presence Document (related to Alice)

Privacy Filtering

closedIMim:[email protected]

openEMAILmailto:[email protected]

openvoicetel:+1-404-123-4567

Figure 23: Privacy Filtering Example


29/44



5.3 Watcher Filtering

[RFC4660] and [RFC4661] specify a filtering mechanism that enables a susbscriber to the state of a resource to control

the content of event notifications. It is applicable to XML content types.

Applied to presence, a watcher may provide its own filtering rules when it subscribes to presence for a presentity.

The MIME type associated to event notification filtering information is: application/simple-filter+xml. This data

enables a watcher to describe both the state changes that will cause notifications, and what those notifications are tocontain. In other words, a watcher may specify when and what. The XML document provided by the watcher

consists in element that contains one element (optionally) and one or more

elements.

The element may contain a element and may contain one or more elements (the when

condition). Moreover, a filter may have the domain, remove and enabled attributes that facilitate the

management of filtering rules, over time, between a subscriber and a notifier.

Figure 24 and Figure 25 illustrate the application of different filtering rules to the same candidate presence document

for Bob, in regards to Alices presence.

Figure 24: Watcher Filtering - Example 1


30/44



The candidate presence document is the outcome of the privacy filtering operation, as discussed earlier. For these

examples, it simply consists of two tuples: one reflecting a communication via instant messaging, and the other

indicating a voice communication.

Via the first filtering rules, Bob indicates that he wants to be informed about communicating via messaging services

with Alice: either IM, or SMS, or MMS. As a result, the possibility of communicating via a phone call with Alice is

filtered. Bob receives the Alices status regarding instant messaging and can see that she is not available for such a

communication at present time.

Via the second filtering rules, Bob indicates that he wants to be informed about all the communication means by

which Alice is available. Since Alice is only available by phone, this is the only presence information communicated to

Bob by the presence server.

A more flexible way for Bob to communicate his filtering rules regarding Alices presence would be to have both filters

in the document, and enabling/disabling them depending on his choice.

Figure 25: Watcher Filtering - Example 2


31/44



6 Presence winfo Notification

As with the PUBLISH method, presence requirements have entailed the enhancement of the SIP event framework with

a new feature: the Watcher Information (winfo) Event Template-Package, specified in [RFC3857]. A template

package is like a regular SIP event package, but is associated to any event package. Applied to the presence event

package, the Watcher Informationfacility enables a Presentity to be gradually informed about the subscription

states of her/his watchers.[RFC3858].defines the format of the application/watcherinfo+xml MIME content-type.

Note: the term watcher in the watcher information facility might suggest that it is related to the watcher

presence role only, but it is a generic term applicable to any event states subscriber.

Figure 26 illustrates the watcher information mechanism in the context of presence:

Alice subscribes to the presence.winfo event for her own presentity, and receives the 200 OK response. Thehypothesis is that there are no watchers yet, and the initial NOTIFY, that follows systematically a subscription

acceptation, is not shown whatever the event state. It should be noted that Alice could apply filtering rules, in

the same way as a watcher for presence, by using [RFC4660] and [RFC4661] mechanisms.

Bob subscribes to Alices presence, but is placed in a pending state: this is immediately notified to Alice bythe Presence Server. As a result, Alice may decide to authorize Bob to watch her presence information.

Later on, Carol subscribes to Alices presence and is accepted: this is immediately notified to Alice by the PS.

Watcher(Bob)

Presentity(Alice)

PresenceServer

Watcher(Carol)


Event: presence.winfo

NOTIFY sip:[email protected] SIP/2.0

Event: presence.winfo

Content-type: application/watcherinfo+xml


NOTIFY sip:[email protected] SIP/2.0

Event: presence.winfoContent-type: application/watcherinfo+xml



Event: presence


Event: presence202 Accepted

200 OK

200 OK

1

2

3

4

5

6

7

8

Figure 26: Presence Watcher Information Example


32/44



7 XCAP and XML Document Management

When processing a request, it is sometimes necessary for the the presence and resource list servers to access per-user

configuration data, such as policies and resource lists. This information is stored in the network as XML documents,

but it is managed by the end-user themselves. According to the OMA, the servers in charge of storing and managing

these XML documents are called XDMS: XML document management servers. They are either dedicated to anapplication server (presence, RLS...) or shared between several servers (Shared XDMS). An XDM client (XDMC) located

in a terminal must be authenticated by an Aggregation Proxy (actually, a HTTP Proxy) before accessing XML

documents stored in any XDMS.

PresenceXDMS

UE

XDMC

PresenceServer

Aggregation Proxy

RLSXDMS

Shared XDMS

RLSServer

XCAPcreate/modify/retrieve/delete

XCAPretrieve

XCAPretrieve

PresenceAuthorization

Rules

ResourceLists

XCAPretrieve

XCAPretrieve

SUBSCRIBE

NOTIFY

(ua-profile)

NOTIFY

(ua-profile)

SUBSCRIBE

Figure 27: XDMS environment

7.1 Document Management via XCAP

The common protocol for access and manipulation of such user-related XML documents (policies, resource lists...) is

XCAP: XML Configuration Access Protocol. Each XCAP resource on an XDM server is associated with an application, for

which are defined a set of conventions referred to as the application usage. An application usage is identified by an

AUID (application unique ID) that is registered at a naming authority (IANA, OMNA...) and it is mainly related to an

XML schema, a MIME type, and some other validation rules.

XCAP defines a specific naming convention for mapping XML documents and document components as HTTP URIs. The

structure of an XCAP URI, along with the organisation of user-related XML documents at the XCAP server, is illustrated

in Figure 28.

The XCAP rootURI identifies the root of the tree within the domain where all XCAP documents are stored. Typically,

it is built with the xcap word, followed by the domain name. As an example, http://xcap.atlanta.com would be

the XCAP root URI for the XCAP server handling all user configuration documents in Alices domain, and this root URI

would be provisioned into Alices device.


33/44



The document selector is a sequence of path segments separated by a / that identifies a document within the

XCAP root:

The first path segment is the AUID that identifies the application usage. For Alice, who manages her presenceauthorization policy document, it would be pres-rules, i.e. the AUID value registered at the IANA for that

purpose. An AUID identifies a file structure root at the XCAP Server, and the role of the XCAP Server that

supports this AUID is to enable and ensure GET, PUT and DELETE HTTP operations on XML documents that

conform to the rules associated to this application usage. The second path segment is either users or global, and corresponds to one of two sub-trees. The

documents placed under global are those common to all users, if any.

The third path segment, in case the second one is users, is the XUI (XCAP User Identifier). For SIPapplications, it is recommended that the XUI be equal to the Address-of-Record (AOR). The home directory for

Alice presence authorization rule documents at her Presence XDMS would then be represented by the following

URI:

http://xcap.atlanta.com/pres-rules/users/sip:[email protected]

The final path segment in the document selector identifies the actual document.

Figure 28: HTTP URI for XCAP

The node selectorspecifies nodes of an XML document that essentially refer to an XML element or an attribute of an

element. The node selector uses XPATH syntax, as defined by the W3C.

XCAP also defines a technique for using HTTP GET, PUT and DELETE methods for various document manipulation

operations: retrieving/adding/deleting elements and attributes...


34/44



Figure 29 shows how Alice can authorize Bob to subscribe to her presence state: pres-rules is the AUID value for

presence authorization rules.

Presentity(Alice)

XDMClient

AggregationProxy

Presence

XDMServer

HTTP PUT

HTTP PUT

201 Created

PUT /pres-rules/users/sip:[email protected]/index HTTP/1.1

Content-Type: application/auth-policy+xml

Host: xcap.presxdms.com

allow

201 Created

(Alice)Presence

AuthorizationRules

Figure 29: Subscription authorization rules update by the Presentity

7.2 Subscribing to Changes in the XML Documents

Besides retrieving per-user configuration data via XCAP, the servers may be notified of changes (by end-users in most

cases) to XML documents, by subscribing to the ua-profile event for those resources.

The [draft-ietf-sipping-config-framework] specification defines a generic configuration framework enabling a UA to

have its profile data delivered any time it is modified. In particular, it defines the ua-profile SIP event package.

For XCAP, this event package is extended by [draft-ietf-sip-xcap-config] and it enables a presence or RLS server,

acting as a UA, to subscribe to any changes (by the document owner) in policy or resource list documents. This feature

enables the server to react in near-real-time,typically to any modifications that a presentity would perform on itsauthorization rules, or that a watcher would perform on resource lists.

This facility can be applied to a specific document, to a set of documents belonging to a given user, or to a specific

part of a given document.


35/44



8 Subscription to a Presence List via RLS

[RFC4662] defines an extension to the SIP Event Framework [RFC3265] that allows for requesting and conveying

notifications for lists of resources. A resource list is identified by a URI, and it represents a list of zero or more URIs.

Each of these URIs is an identifier for an individual resource for which the subscriber wants to receive information.

The notifier for the list is called a "resource list server", or RLS. In order to determine the state of the entire list, the

RLS will act as if it had generated a subscription to each resource in the list.

The resource list is not restricted to be inside the domain of the subscriber. Similarly, the resources in the list are not

constrained to be in the domain of the resource list server.

Figure 30 illustrates an example where Bob, instead of subscribing to Alice, Bill and Carol presence, subscribes to an

available resource list (containing these three people) at the RLS in his own domain. The Eventlist option tag is

placed in the Suppor t ed header field. Moreover, the multipart/related and application/rlmi+xml MIME types

must be included in an Acceptheader, in addition to the types (application/pidf+xml) required by the presence

event package. The RLS is an authority for presence information for the users in the biloxi.com domain.

Immediately upon accepting the subscription, the RLS sends a NOTIFY containing the RLMI (Resource List Meta-

Information) as well as the presence information for Bill. The RLS then sends back-end subscriptions to the presence

of Alice and Carol in their respective domains.

Figure 30: Subscription to a Presence List via the RLS


36/44



This first notification (3) is shown in Figure 31. The message body is composed of multiple parts: the full resource list

under RLMI format, followed by the presence information for Bill.

NOTIFY sip:bob-ua.biloxi.comEvent: presenceSubscription-State: active;expires=7200Require: eventlistContent-Type: multipart/related;type="application/rlmi+xml"; start=""; boundary="--xxxxx"Content-Length: ...

--xxxxxContent-Transfer-Encoding: binaryContent-ID: Content-Type: application/rlmi+xml;charset="UTF-8"

Buddy List at the meetingListe de mes amis au meeting

Bill Jones

Alice Smith

Carol Cooper

--xxxxxContent-Transfer-Encoding: binaryContent-ID: Content-Type: application/pidf+xml;charset="UTF-8"

opensip:[email protected]

--xxxxx

Figure 31: RLS Notification as a multipart/related MIME type

When the RLS is notified of both Alice and Carol presence information, it then notifies a second time Bob with the

presence information either for the full list, or for the updated resources only.

When the list is partial, the attribute fullState must be set to false.


37/44



9 Optimization Features

9.1 Partial Publication / Notification

With the PIDF format, the full presence information must be published or notified even when there are minor

changes, compared to the previous version. In some environments with low bandwidth and high latency, it can beworth limiting the volume of transported information. The application/pidf-diff+xml content type has been

specified for dealing with this facility. This new format is similar to the standard PIDF, excepted that the

element is replaced by either a or element. The former is used with an initial view, while the

latter is used for changes. These two elements have a version attribute which is only used with notifications since the

Publish mechanism has its own mechanisms (SIP-ETag and SIP-If-Ma t ch headers) for correlating published

information.

Figure 32 shows an example with a first publication, using as the root element, and then a second

publication with as the root element. The document content of this second PUBLISH is made up of patch

operations: add, replace and remove, as defined in the simple-xml-patch-ops IETF draft. This latter utilizes the XML

Path Language (XPath).

PUBLISH sip:[email protected] SIP/2.0Event: presenceContent-Type: application/pidf-diff+xmlContent-Length: ...

open

truefalsetrue

tel:+1-404-123-4567

openim:[email protected]

Full state presence document

PUBLISH sip:[email protected] SIP/2.0Event: presenceSIP-If-Match: xyzContent-Type: application/pidf-diff+xmlContent-Length: ...

open

mailto:[email protected]

This is a new tuple insertedbetween the last tuple and note element

close

Figure 32: Partial Publication

For notifications, the processing is very similar. The only difference is that the version attribute must be used.


38/44



9.2 Content Indirection

9.3 Notification Throttling

9.4 Compression


39/44



10 Usage of Presence by other Services

Figure 33 shows the architecture that combines Presence with the Push-to-talk over Cellular (PoC) service, as per the

OMA.

Push-to-talk is a walkie-talkie like service that enables voice and data communications in a half-duplex mode betweentwo or more participants. The presence information, describing the availability of the user to communicate via PoC

Service, may be published by the Presence Source in the UE, or by the PoC Server on behalf of the PoC Client. The

presence information may be fetched or subscribed to by the Watcher in the UE, or by the PoC Server on behalf of the

PoC Client.

A similar architecture is applicable to the Instant Messaging service.

PresenceServer

PoCServer

PoCClient

WatcherPresenceSource

Presentity(Bob)

User Equipment

User Equipment

Watcher

PoCClient

PresenceSource

Presentity(Alice)

PUBLISH

(Alice)

PUBLISH

(Bob)

PUBLISH

(Bob/Alice)

SUBSCRIBE

(Bob)

NOTIFY

SUBSCRIBE

(Alice) NOTIFY

SUBSCRIBE

(Bob/Alice)

NOTIFY

Figure 33: Use of the Presence Service with PoC


40/44



11 Use Cases

Here are the actors for this series of presence use cases:

Bob has a multimedia portable PC that he uses both at home and at work. Alice is Bobs friend and owns a mobile device. John and Juliet are Bobs colleagues and, like him, use a PC. Jane is Bobs assistant and uses a mobile device.The pre-requisites are as follows:

All actors have subscribed to the presence service. Alice is in Bobs friends contact list John is in Bobs colleagues contact list Juliet is not in Bobs colleagues contact list yet Bob is in Alices contact list as well as in Johns contact list, but is not in Juliets contact list yet.

11.1Use case #1: privacy management via the sphere presence element

1) Bob is at home

Bob is at home and invokes the presence service settings menu in his PC. He chooses the current sphereoption and sets it up to home. He does not modify the service capability elements that reflect that message,

audio and video communications can be established for contacting him. As a result, a new presence view is

published towards the presence server by the presence user agent on his PC.

Alice and John, who are current Bobs contacts, are notified with new presence information regarding Bob. Alice sees Bob on-line while John sees Bob off-line: actually, Bobs friends and colleagues contact lists

have been reflected, by the presence software on Bobs PC, as sphere condition elements associated to Alice

and John identities in Bobs presence authorization rules, available at the presence XDMS.

Alice types a message and sends it to Bob. Bob receives it and they start chatting. John sets up a call-back on Bob.

Figure 34: Use case #1 - Bob at home


41/44



2) Bob goes to work

Bob goes to work and invokes the presence service settings menu in his PC. He chooses the current sphereoption and sets it up to work. He does not modify the service capability elements that reflect that message,

audio and video communications can be established for contacting him. As a result, a new presence view is

published towards the presence server by the presence user agent on his PC.

The software application on Johns PC that initiated the call back is coupled to the presence client andtherefore is notified that Bob is available. A call-back windows pops up and John decides to call Bob for anaudio/video call between their PCs.

Figure 35: Use case #1 - Bob goes to work

11.2Use case #2: relationship management

Bob is attending a meeting and becomes not available. However, Jane, his assistant can be contacted forprofessional calls: John forwards his calls to Jane and declares her as a presence relationship.

Figure 36: Use case #2 - Bob is in a meeting


42/44



Alice is notified that Bob is not available, conversely to John. Bob meets Juliet at the meeting and they exchange business contact information due to a project they will be

working on together.

John calls Bob and his call is forwarded to Jane. John could also contact Jane directly since he is aware thanBob is not available and suggests to call Jane for any urgent matter.

11.3Use case #3: presence authorization Juliet is back to her office and she adds Bob to her contact list. This entails a subscription, by her presence

client, to Bobs presence.

Bob receives a presence authorization request from Juliet: since Juliet is not in Bobs contact list, andtherefore not in Bobs presence authorization rules at the XDMS server, the presence server puts Juliets

subscription in a pending state. Bobs presence client is notified of this state, since it subscribed to

presence.winfo, and requests the authorization from Bob.

Bob accepts the demand from Juliet and adds her to his colleagues contact list. As the same time, Bobspresence client subscribes to Juliets presence.

Similarly, Juliet receives a presence authorization from Bob and accepts it. Juliet and Bob can now see each other on-line. Juliet shares with Bob the Excel file she mentioned during the meeting.

Figure 37: Use case #3 - presence authorization and Push-to-Share

11.4Use case #4: unavailability Bob goes back home in the evening. He is tired afer a day of work. He sets up the current sphere option and

to home and declares himself unaivalable for all the services: text, voice, video.

Alice would like to call Bob from her SIP phone but since her presence client was notified of latest presenceinformation about Bob, she sees that Bob is currently unavailable


43/44



List of abbreviations

3GPP 3rdGeneration Partnership

Project

AoR Address of Record

AS Application Server

AUID Application Unique ID

CPP Common Profile for

Presence

EPA Event Publication Agent

ESC Event State Compositor

GGSN Gateway GPRS Support Node

GPRS General Packet Radio

Service

HSS Home Subscriber Server

HTTP Hypertext Transfer ProtocolIETF Internet Engineering Task

Force

IM Instant Messaging

IMPP Instant Messaging and

Presence Protocol

IMS IP Multimedia Subsystem

ISC IMS Service Control

MIME Multipurpose Internet MailExtensions

MSC Mobile Switching Center

OMA Open Mobile Alliance

OMNA Open Mobile Naming

Authority

PDA Personal Digital Assistant

PEA Presence External Agent

PIDF Presence Information Data

Format

PNA Presence Network Agent

PoC Push-to-talk over Cellular

PUA Presence User AgentRFC Request For Comments

RLS Resource List Server

RPID Rich Presence Extensions to

PIDF

S-CSCF Serving Call Session Control

Function

SGSN Serving GPRS Support Node

SIMPLE SIP for Instant Messaging andPresence Leveraging

Extensions

SIP Session Initiation Protocol

UAC User Agent Client

UAS User Agent Server

URI Uniform Resource Identifier

URL Uniform Resource Locator

URN Uniform Resource Name

VLR Visitor Location Register