Presence for Wireless Systems 10

1 3GPP2 S.R0062-0 2 Version Date: 30 October 2002 3 Version 1.0 4 5 6 7 8

9 Presence for Wireless Systems 10

11 Stage 1 Requirements 12 13 14 15 16 17 18 19 20 COPYRIGHT NOTICE 3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner's name based on this document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at [email protected] . Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See www.3gpp2.org for more information. 21 22 S.R0062-0 v1.0

1 Ihab A. Guirguis P.E. (Sprint PCS) (913) 890-4245, 2 [email protected] 3 4 Alan Hameed (Fujitsu Network Communications) (972) 333-8990, 5 [email protected] 6 7 Tom Hiller (Lucent Technologies) (630) 979-7673, [email protected] 8 9 George Fry (Nokia) (972) 894-4405, [email protected] 10 11 12 REVISION HISTORY

13 REVISION HISTORY Rev. 1.0 Initial Stage 1 30 October 2002 14 15 S.R0062-0 v1.0

1 2 1 INTRODUCTION AND SCOPE ...... 1 3 2 REFERENCES...... 3 4 2.1 Acknowledgement...... 4 5 3 DEFINITIONS AND ABBREVIATIONS ...... 4 6 4 GENERAL FEATURE DESCRIPTION ...... 7 7 4.1 Overview ...... 7 8 4.2 IETF Model ...... 7 9 4.3 Service Interaction...... 7 10 5 Numbered Requirements...... 7 11 5.1 General Requirements ...... 7 12 5.2 Accounting ...... 8 13 5.3 Security...... 9 14 5.4 User Perspective of Presence Service...... 10 15 5.5 Operator Perspective of Presence Service ...... 11 16 5.6 Privacy ...... 14 17 18 19 20 21 22 23 S.R0062-0 v1.0

1 2 1 INTRODUCTION AND SCOPE 3 4 A presence service manages the collection and dissemination of status 5 information regarding user devices, services and services components being 6 managed by the wireless network. Presence service is already available in the 7 Internet world, although via different non-interoperable mechanisms. This 8 specification identifies the requirements for support of a wireless-enhanced 9 version of the presence service through the support of wireless attributes (e.g. 10 services, media components of a multimedia service, location information) in 11 an interoperable manner between cdma2000 wireless data networks and 12 between cdma2000 wireless data networks and other IP networks. 13 14 This document defines Stage 1 level requirements of the presence service from 15 the perspective of the user and the system operator, so that it may be 16 incorporated into cdma2000 based wireless networks. This document limits 17 itself to presence service and does not delve into other applications that make 18 use of presence, such as instant messaging. 19 Presence is an attribute related to, but quite different from mobility 20 information, and is a service that can be exploited to create additional services. 21 The presence service enables presence information to be made available to 22 other users or services. This Stage 1 makes extensive use of Internet 23 terminology to ensure alignment with the presence service description and 24 behavior in Internet recommendations. 25 The types of services that could be supported by the presence service may 26 include: 27 New communications services 28 The presence service will enable new multimedia services to exploit this key 29 enabler to support other advanced multimedia services and communications. 30 These new services may infer the context, availability and willingness of a user 31 to accept or participate in particular types of communications by accessing the 32 presence information for the user's devices and services. Examples of such 33 new multimedia services that could potentially exploit the presence service 34 include "chat", instant messaging, multimedia messaging, e-mail, handling of 35 individual media in a multimedia session etc. 36 37 38 39 40 Information services S.R0062-0 v1.0

1 The presence service may also be exploited to enable the creation of services in 2 which abstract entities are providing the services to the mobile community. 3 The presence service may be used to support such abstract services as cinema 4 ticket information, the score at a football match, motorway traffic status, 5 advanced push services etc. 6 Enhanced existing services 7 Exploiting the presence information may also significantly enhance existing 8 wireless services. For example a user may dynamically arrange for his wireless 9 services to be supported through his corporate PABX whilst he is on-site, 10 require media to be converted and directed to specific devices (e.g. user cannot 11 accept a voice call while in a meeting, but is prepared to receive the voice call 12 converted to text in the form of an SMS/MMS/e-mail message). The presence 13 service may also be used to enable the creation of advanced versions of CS/PS 14 services, enable terminal capabilities support etc. 15 16 Figure 1 represents a logical overview of how services could exploit the 17 presence service to create advanced services. S.R0062-0 v1.0

Visited networks

Home Environment Presence-enhanced packet domain VoiceVoice services services Internet Data services Data services Presence Supplementary services Supplementary services Multimedia services Multimedia services IMS Abstract entities legacy domain Abstract entities

Other networks

1 2

3 Figure 1: Logical presence service support of services 4 5 A presence-enabled service, as observed by the user, is a service in which the 6 user can control the dissemination of presence information to other users and 7 services. Combined with the capability of other users' control of their own 8 presence status, virtually infinite combinations of users and services 9 interacting at different levels can be created. 10 11 2 REFERENCES 12 Applicable references for this specification include the following: 13 14 [1] IS835-AD Wireless IP Network Standard, April 2001-09-06 15 [2] [RFC2778] M. Day, J. Rosenberg, H. Sugano, "A Model for Presence and 16 Instant Messaging", RFC 2778, February 2000. 17 [3] [RFC2779] M.Day, S.Aggarwal, G.Mohr, and J.Vincent, "Instant Messaging 18 / Presence Protocol Requirements", RFC 2779, February 2000 S.R0062-0 v1.0

1 [4] [CPIM] D. Crocker et al., "A Common Profile for Instant Messaging (CPIM)", 2 draft-ietf-impp-cpim-01.txt, Work in Progress. 3 4 2.1 Acknowledgement 5 This document contains extracts of documents, the copyright of which is vested 6 in the Internet Society. The terms of the Internet Society copyright are fulfilled 7 by the reproduction of the copyright and paragraph below. This copyright only 8 applies to text in this document that has been directly reproduced from the 9 appropriate RFC. 10 11 Copyright (C) The Internet Society (2000). All Rights Reserved. 12 This document and translations of it may be copied and furnished to others, and derivative works that 13 comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and 14 distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and 15 this paragraph are included on all such copies and derivative works. However, this document itself may not 16 be modified in any way, such as by removing the copyright notice or references to the Internet Society or 17 other Internet organizations, except as needed for the purpose of developing Internet standards in which 18 case the procedures for copyrights defined in the Internet Standards process must be followed, or as required 19 to translate it into languages other than English.

20 3 DEFINITIONS AND ABBREVIATIONS 21 The terms and abbreviations that are used within this specification are taken 22 from RFC 2778, as follows: 23 24 Access rules: constraints on how the presence service makes presence 25 information available to watchers. For each presentity’s presence information, 26 the principal that controls the presentity manages the applicable access rules. 27 28 Activation: the action taken at any time to: enable the registered presentity or 29 watcher to invoke Presence Service features; allow other presentities or 30 watchers to invoke Presence Service features concerning this presentity or 31 watcher (e.g. by subscribing to its presence information); allow the Presence 32 Service to invoke Presence Service features concerning this presentity or 33 watcher (e.g. by notifying changes in the presence information) 34 35 Availability: a property of a presentity denoting its ability and willingness to 36 communicate based on factors such as the identity or properties of the watcher 37 and the preferences and/or policies that are associated with the presentity. 38 39 Deactivation: an action taken at any time to: disable the registered presentity 40 or watcher from invoking future Presence Service features; disallow other 41 presentities or watchers from invoking Presence Service Features concerning 42 this presentity or watcher (e.g. by removing all subscriptions to its presence S.R0062-0 v1.0

1 information); disallow the Presence Service from invoking Presence Service 2 features concerning this presentity or watcher. 3 4 Deregistration: the deletion by the service provider, the subscriber or the 5 system, of information stored for a particular service by a previous 6 registration(s). 7 8 Fetcher: a form of watcher that has asked the presence service for the 9 presence information of one or more presentities, but is not requesting a 10 notification from the presence service of (future) changes in a presentity's 11 presence information. 12 13 Identifier: a means of indicating a point of contact, intended for public use 14 such as on a business card. Telephone numbers, email addresses, and typical 15 home page URLs are all examples of identifier in other systems. 16 17 Interoperable Services: Two implementations are interoperable if they can 18 interact without protocol interworking devices. 19 20 Poller: a fetcher that requests presence information on a regular basis. 21 22 Presence information: is a set of attributes characterizing current properties 23 of presentities such as status, an optional communication address and other 24 optional attributes etc. 25 26 Presence list: is the Presence information for a list of users 27 28 Presence service: the capability to support management of presence 29 information between watchers and presentities, in order to enable applications 30 and services to make use of presence information. 31 32 Presentity (presence entity): any uniquely identifiable entity that is capable 33 of providing presence information to presence service. Examples of presentities 34 are devices, services etc. Any presentity shall have one, and only one, principal 35 associated with it. 36 37 Principal: human, organization, program, or collection of humans, 38 organizations and/or programs that chooses to appear to the presence services 39 as a single actor, distinct from all other principals. A principal is associated 40 with one or more presentities and/or watchers. A principal is said to "own" a 41 certain presentity or watcher if such an association exists. Within the context 42 of this specification a subscriber may be a principal to one or more presentities 43 and/or watchers. Examples: A subscriber may be a principal to the terminals 44 (the presentities) he owns. A program, providing a stock exchange information S.R0062-0 v1.0

1 service to customers, may be the principal to the market quotations (the 2 presentities) it monitors. 3 4 Provisioning: an action taken by the service provider to make the presence 5 service available to a principal. Provisioning may be general, where the service 6 may be made available to all principals without prior arrangements being made 7 with the service provider, or it may be pre-arranged, where the service is made 8 available to an individual principal only after the necessary arrangements (e.g., 9 login name, password) have been made with the service provider. 10 11 Registration: an action taken by the service provider or 12 principal to provide information necessary for presentities and/or watchers 13 to use the presence service. For example a 3GPP2 user could request the 14 creation of a presentity associated with him and provide the corresponding 15 access rules. 16 17 Subscribed-watcher: a subscribed-watcher is a type of watcher, which 18 requests notification from the presence service of changes in a presentity's 19 presence information, resulting in a watcher-subscription, as they occur in the 20 future. 21 22 Watcher-subscription: the information kept by the presence service about a 23 subscribed-watcher's request to be notified of changes in the presence 24 information of one or more presentities 25 26 Watcher: any uniquely identifiable entity that requests presence information 27 about a presentity, or watcher information about a watcher, from the presence 28 service. Special types of watcher are fetcher, poller, and subscribed-watcher. 29 Any watcher shall have one, and only one, principal associated with it. 30 Watcher information: information about watchers that have received or may 31 receive presence information about a particular presentity within a particular 32 recent span of time 33 34 Withdrawal: an action taken by the service provider to remove 35 an available service from a principal's access. Withdrawal may be general 36 (withdrawal of service from all principals) or specific (withdrawal of 37 service from a particular principal). 38 S.R0062-0 v1.0

1 4 GENERAL FEATURE DESCRIPTION 2 4.1 Overview 3 A presence service provides a means for users or services to find, retrieve, and 4 subscribe to changes in presence information (e.g. "online" or "offline") of other 5 users. A presence-enabled user is able to control the dissemination of his/her 6 presence information to other users and services, as well as explicitly identify 7 the users and services for which he/she would like to provide presence status. 8 A presence service thus manages the collection and dissemination of status 9 information regarding users and services being managed by the wireless 10 network. 11 The presence service status of a user may include a combination of network 12 state information (online or offline), application state information (idle or active) 13 and user specified state information (available or busy), for example. 14 4.2 IETF Model 15 This Stage 1 is based on the IETF abstract model for a presence system that 16 has been defined in RFC 2778. RFC 2778 defines the various entities involved 17 and terminology, and outlines presences services. The goal of the IETF model is 18 to provide a common basis for the definition of requirements for open, 19 interoperable protocols and markup languages for presence services. The IETF 20 presence service models do not imply a particular implementation or 21 architecture. 22 An informative Annex on the IETF abstract model is included for convienence of 23 readers. 24 4.3 Service Interaction 25 Presence may work in conjunction with many services. For example, a potential 26 sender of an instant message or ordinary voice caller registers for presence 27 information regarding another user (or principal). This potential sender of an 28 instant message becomes a watcher. The presence service then returns 29 presence information regarding the particular principal, if that principal had 30 previously agreed to allow such information to be disseminated to the 31 requesting watcher. Later, when the principal registers onto the system or 32 becomes otherwise available, the presence service sends presence information 33 to the requesting watcher. The watcher may then send instant messages or call 34 the principal. 35 5 Numbered Requirements 36 The following are high-level requirements for presence service. 37 5.1 General Requirements 38 The following are general requirements for the presence service: S.R0062-0 v1.0

1 GEN-01 Presence information for presentities shall be made available in a 2 standardized format. 3 GEN-02 The standardized presence service shall be able to interoperate 4 with IETF specified presence service, including RFC 2778, RFC 5 2779 and CPIM. 6 GEN-03 The presence service shall enable a watcher to request a time 7 after which delivery of the requested information shall not take 8 place. 9 GEN-04 The presence service shall enable a presentity to indicate an 10 expiry time for the presence information. 11 GEN-05 The presence service shall enable presence information delivered 12 to a watcher to be marked with an expiry time. 13 GEN-06 The presence service shall allow use of presence information by 14 other services such as supplementary services, teleservices, 15 bearer services or any other services. 16 GEN-07 An entity shall be able to watcher-subscribe to the presence 17 service at any time, i.e. to request notification from the presence 18 service of (future) changes in a presentity's presence information, 19 subject to the presentity's privacy. Note that by this watcher- 20 subscription, the entity becomes a subscribed-watcher. 21 GEN-08 The subscribed-watcher shall be able to cancel his watcher- 22 subscription to a presentity’s presence information at any time. 23 Whenever a subscribed-watcher cancels its watcher-subscription 24 from a presentity’s presence information, the subscribed-watcher 25 shall no longer receive notifications regarding the presentity’s 26 presence information. 27 GEN-09 It shall be possible for the presentity to request the watcher 28 information. 29 30 5.2 Accounting 31 The presence service shall generate detail records and shall be able to support 32 various charging mechanisms. The following accounting characteristics shall 33 be considered: 34 35 ACT-01 The presence service shall provide support for accounting based 36 on a user's registration as a presentity. 37 ACT-02 The presence service shall provide support for accounting based 38 on each subscription to presence information for a user. S.R0062-0 v1.0

1 ACT-03 The presence service shall provide support for accounting based 2 on presence information retrieval for users. 3 ACT-04 The presence service shall provide support for accounting based 4 on presence information notifications received for users. 5 ACT-05 The presence service shall provide support for accounting based 6 on presence information usage when in a visited network. 7 ACT-06 It shall be possible to forward presence accounting detail 8 information to the accounting entity. 9 10 5.3 Security 11 Security is an important aspect of presence. The presence service must control 12 access to its information and functionality. 13 The use and access to the presence service shall be supported in a secure 14 manner. It shall only be possible for presence information to be supplied 15 and/or updated by the presentity. The following are security requirments for 16 presence services: 17 SEC-01 The presence service shall support measures to detect and 18 prevent attempts to maliciously use or abuse the services. It 19 shall be possible to authenticate presentities and/or watchers at 20 any time 21 SEC-02 It shall be possible to authenticate a principal before allowing 22 registration to the presence service 23 SEC-03 It shall be possible to authenticate a watcher requesting access 24 to the presence service 25 SEC-04 It shall be possible to authorize a watcher’s watcher-subscription 26 request to a presentity’s presence information. 27 SEC-05 An authorized third party shall be able to cancel a subscribed- 28 watcher's watcher-subscription to a presentity's presence 29 information. 30 SEC-06 It shall be possible to protect the following items from 31 eavesdropping and tampering: 32 1. Presence information and notifications 33 2. Requests for presence information, e.g., requests for 34 subscription and requests for presence information 35 retrieval. 36 S.R0062-0 v1.0

1 5.4 User Perspective of Presence Service 2 The following presence service requirements are seen from the user’s 3 perspective: 4 UP-01 The user shall have the ability to control a presence state which 5 is published. 6 UP-02 The user shall have the ability to block other users and control 7 the release of presence data (privacy management).

8 UP-03 It shall be possible for the presentity to configure the presence 9 service to deny a subscribed-watcher's subscription, while 10 appearing to the subscribed-watcher as if the subscription has 11 been granted. (This is sometimes called "polite blocking”). 12 UP-04 The user shall have the ability to subscribe to and monitor 13 another user’s presence, unless prevented by the presentity’s 14 access rules. 15 UP-05 The user shall have the ability to set user specified status that 16 over-rides all other presence states. 17 UP-06 The presence service shall have the capability to notify the 18 principal of new watcher subscription requests . 19 UP-07 The user shall have the ability to accept or deny new 20 subscription requests. The watcher requesting a subscription 21 should be able to determine whether a subscription request has 22 been denied, unless prevented by the presentity’s access rules. 23 UP-08 The presence service shall allow a principal to update their 24 presence status.. 25 UP-09 The user shall be able to access presence services from different 26 devices. Restrictions may apply due to the nature of the 27 underlying transport mechanism (e.g. a legacy terminal may not 28 be capable to supply the same presence information as a mobile 29 station attached to the MMD). 30 UP-10 It shall be possible for the watcher to withhold its identity from 31 the presentity. 32 UP-11 It shall be possible to request the current value of presence 33 information data at any time. Such requests may be one-time 34 (i.e., fetcher), or periodic (i.e., a poller), or when changes occur in 35 presence information data, except when such notification is 36 prevented by access rules. 37 UP-12 It shall be possible to inform the presentity of watcher- 38 subscription requests. S.R0062-0 v1.0

1 UP-13 It shall be possible to report existing watcher-subscriptions to 2 the presentity (on request or periodically). 3 UP-14 If the subscribed-watcher so chooses, the subscribed-watcher’s 4 watcher-subscription to a presentity’s presence information shall 5 not be revealed to other watchers. 6 UP-15 It shall be possible for a watcher to define which parts of a 7 presentity’s presence information it receives, subject to the 8 presentity’s privacy requirements. 9 10 5.5 Operator Perspective of Presence Service 11 The following presence service requirements are seen from the operator’s 12 perspective: 13 OP-01 The operator shall have the ability to set policies for the control 14 and management of inter-service and intra-service access to 15 presence information. 16 OP-02 The presence service shall provide the ability to store a presence 17 list on the presence server and distribute the list to any watcher 18 used to access the presence service. 19 OP-03 The presence service shall provide the ability to store multiple 20 sets of presence attributes from multiple presentities (presence 21 sources) for a single user. 22 OP-04 Presence information for presentities shall be made available in 23 a standardised format to enable interoperability. 24 OP-05 The presence information format shall be extensible without 25 undermining the standardised format (e.g. customize the status 26 dependent on location, time of day, devices etc.). 27 OP-06 The presence service shall define a standardized presence 28 schema suitable for different services (e.g. instant messaging), 29 with a minimum set of attributes and their values needed for 30 interoperability within 3GPP2 (e.g. status attributes with the 31 following values open, closed, online, offline, busy, away, do not 32 disturb etc.). 33 OP-07 The presence service may access presence information from 34 other network entities, e.g., an HLR, a AAA. 35 OP-08 The presence service shall be access technology independent. 36 OP-09 The principal shall be able to specify the specific types of 37 presence information that may be accessed by specific users. 38 Users may be individuals or groups. S.R0062-0 v1.0

1 OP-10 The presence service shall support the processing of presence 2 information elements according to logical rules, e.g., the user is 3 present (registered) on the network, is willing to accept a 4 particular type of service request and is located in some 5 geographic area, etc. The presentity shall have the option to 6 accept or reject all requests for presence information from a 7 watcher without requiring user action on each request (e.g. set 8 up access rules for known watcher, groups of watchers, 9 anonymous watcher-subscriptions, etc.) 10 OP-11 It shall be possible to request the current value of presence 11 information data. Such requests may be one-time (i.e. a fetcher), 12 or periodic (i.e. a poller), or when changes occur in presence 13 information data, except when such notification is prevented by 14 access rules. 15 OP-12 The presence service shall support subscription to notification 16 events. This implies that the presence service asynchronously 17 returns presence events (e.g. state change). 18 OP-13 The presence service shall support subscription to periodic 19 update of presence state (i.e. polling and returning presence to 20 the watcher). 21 OP-14 The presence service shall support both IP and non-IP based 22 transport mechanism. 23 OP-15 The standardized presence information format shall include a 24 means to uniquely identify the presentity. 25 OP-16 The standardized presence information format shall include a 26 means to relate contact information for the presentity's principal 27 (if applicable), such as email address, telephone number, postal 28 address etc., or a link to that information 29 OP-17 It may be possible for the presence service to utilize location 30 information and provide notifications based on changes in 31 location as requested by a watcher. Note: The presence service 32 may also allow other presence attributes to be supported. 33 OP-18 There shall be a means to uniquely identify a watcher. 34 OP-19 The presence service shall continue to be supported if the 35 environment into which the user has moved supports presence 36 service. The presence service shall take into account changes in 37 the availability of users (e.g. the user is out of contact or not 38 reachable, despite having activated his presence) or his mobility 39 (e.g., whenever he may be in his home environment or in a 40 visited network). S.R0062-0 v1.0

1 OP-20 It shall be possible for the service provider to provision the 2 presence service for use by principals, either a) in a general way, 3 making it available to all principals without prior arrangement 4 with the service provider, or b) in a pre-arranged way where the 5 service is made available to an individual principal only after the 6 necessary arrangements e.g., login name, password) have been 7 made with the service provider 8 OP-21 The action of provisioning shall allow principals to subsequently 9 register with the presence service as a presentity, watcher or 10 both 11 OP-22 The presence service shall allow withdrawal of the service from 12 all principals (suspension of service by the operator). 13 OP-23 The presence service shall allow the withdrawal of the service 14 from a particular principal (suspension of service by the 15 operator). 16 OP-24 It shall be possible for the service provider or principal to register 17 a presentity to use the presence service. This act of registration 18 may be performed at any time by the principal or the service 19 provider to create new presentities. Registration involves the 20 supplying of service-related data needed by the presence service 21 for a particular presentity. 22 OP-25 It shall be possible for the service provider or principal to register 23 a watcher to use the presence service. This act of registration 24 may be performed at any time by the principal or the service 25 provider to create new watchers. Registration involves the 26 supplying of service-related data needed by the presence service 27 for a particular watcher. 28 OP-26 The presence service shall allow activation. 29 OP-27 The presence service shall allow deactivation by either the service 30 provider, the presentity or the watcher. 31 OP-28 The presence service shall provide for its deactivation. 32 OP-29 The service provider may provide privacy control at registration 33 time on behalf of the presentity (e.g., the service provider may 34 supply default access rules for a presentity). 35 OP-30 It shall be possible for the service provider or principal to 36 deregister from the presence service at any time. Deregistration 37 involves removal, by the service provider or principal, of 38 information stored for the presence service by a previous 39 registration(s). 40 S.R0062-0 v1.0

1 5.6 Privacy 2 The following are privacy requirements on the presence service: 3 PRV-01 The standardized presence service shall comply with specific 4 local, national, and regional privacy regulations. 5 PRV-02 The privacy aspect of presence information and the need for 6 authorization before providing presence information shall be 7 configurable by the user (i.e. presentity). 8 PRV-03 It shall be possible for the principal (i.e. presentity) to define 9 different user groups with different access rules. User 10 membership in each group, and the access rules governing each 11 group, may be dynamic in nature. 12 PRV-04 A principal of a presentity shall, at any time, be able to control to 13 whom, for how long and what (all or part of) presence 14 information of the presentity is provided, and a principal of a 15 watcher shall, at any time, be able to control to whom, for how 16 long and what (all or part of) watcher information of the watcher 17 is provided. 18 PRV-05 The principal shall define a set of default access rules. 19 20 S.R0062-0 v1.0

1 Annex 2 This section presents a review of the IETF presence model as a convenience for 3 the reader. The material can be deleted in the final Stage 1 as all of the 4 information below is covered in the IETF references. 5 Present services model 6 To facilitate development of a suite of protocols to provide this service, we 7 believe that it is valuable to first develop a model for the system. The model 8 consists of the various entities involved, descriptions of the basic functions 9 they provide, and most importantly, definition of a vocabulary that can be used 10 to facilitate discussion. 11 12 The purpose of this model is to be descriptive and universal: we want the model 13 to map reasonably onto all of the systems that are informally described as 14 presence. The model is not intended to be prescriptive or achieve 15 interoperability: 16 17 The model is intended to provide a means for understanding, comparing, and 18 describing systems that support the services typically referred to as presence. 19 It consists of a number of named entities that appear, in some form, in existing 20 systems. No actual implementation is likely to have every entity of the model as 21 a distinct part. 22 23 The model defines services, the PRESENCE SERVICE serves to accept 24 information, store it, and distribute it. The information stored is PRESENCE 25 INFORMATION. 26 27 The PRESENCE SERVICE has two distinct sets of "clients": 28 • One set of clients, called PRESENTITIES, provides PRESENCE 29 INFORMATION to be stored and distributed. 30 • The other set of clients, called WATCHERS, receives PRESENCE 31 INFORMATION from the service. 32 33 34 35 PRESENCE SERVICE 36 37 38 PRESENTITY WATCHER 39 40 41 S.R0062-0 v1.0

1 The WATCHERS have two kinds of WATCHERS called FETCHERS and 2 SUBSCRIBERS: 3 4 1. FETCHER simply requests the current value of some PRESENTITY's 5 PRESENCE INFORMATION from the PRESENCE SERVICE 6 • Special kind of FETCHER is called A POLLER, POLLER is one 7 that fetches information on a regular basis 8 9 2. SUBSCRIBER requests notification from the PRESENCE SERVICE of 10 future changes in some PRESENTITY's PRESENCE INFORMATION. 11 • Changes to PRESENCE INFORMATION are distributed to 12 SUBSCRIBERS via NOTIFICATIONS 13 14 15 16 17 FETCHER SUBSCRIBED-

18 WATCHER Fetcher requests the current 19 value of some Presentity’s presence information from 20 the Presence Service Subscribed-watcher is a 21 Watcher that requests 22 notification of (future) 23 changes in some POLLER Presentity’s presence 24 information from the

25 A Poller is a Fetcher Presence Service 26 that requests the current value of some 27 Presentity’s presence 28 29 30 31 32 A presence service is the means to collect and report presence. Presence is 33 therefore all about the collection and distribution of user availability, the types 34 of availability, and the rules for dissemination of availability. 35 36 General Operation S.R0062-0 v1.0

1 Presence systems enable a user to monitor the connection state or presence of 2 other users. The presence model may include a combination of network state 3 information (online or offline), application state information (idle or active) and 4 user specified state information (available or busy). Presence information is 5 usually presented as a list of users (e.g. buddy list). 6 A PRESENCE Model defines the interaction between PRESENCE SERVICE, 7 PRESENTITIES, and WATCHERS. The PRESENCE PROTOCOL carries 8 PRESENCE INFORMATION. This model includes other elements that are useful 9 in characterizing how the protocol and markup work. It defined: 10 11 PRINCIPALS, are people, groups, and/or software in the "real world" outside 12 the system that use the system as a means of coordination and 13 communication. A PRINCIPAL interacts with the system via one of several 14 user agents (INBOX USER AGENT, SENDER USER AGENT, PRESENCE USER 15 AGENT, and WATCHER USER AGENT). 16 17 A simple example of applying the model is to describe a generic "buddy list" 18 application for instant message service. These applications typically expose the 19 user's presence to others, and make it possible to see the presence of others. 20 So we could describe a buddy list as the combination of a PRESENCE USER 21 AGENT and WATCHER USER AGENT for a single PRINCIPAL, using a single 22 PRESENTITY and a single SUBSCRIBER. 23 24 We could then extend our example to instant messaging and describe a 25 generic "instant messenger" as essentially a buddy list with additional 26 capabilities for sending and receiving instant messages. 27 28 1. User activates Mobile Presence Client (assumed to be available on 29 mobile station) 30 2. Service instance establishment using service option 33, then performs 31 PPP establishment, Mobile IP registration, and presence service 32 registration. 33 3. A result of the registration is the authorization of the user for instant 34 message service and the server knowing the current IP address of the 35 mobile station. 36 4. The Presence Client synchronizes the members of a list of interest with 37 their presence states 38 5. A user (Watcher) activates the IM Client and selects a user (Principal) to 39 add to their contact list by either directly entering the user name or 40 searching a directory service. 41 6. The IM Client sends the subscription request to the IM Server 42 requesting an addition to the Watcher’s contact list. The Principal is 43 immediately added to the Watcher’s contact list but appears offline. 44 7. The IM Server forwards the request to the Principal. S.R0062-0 v1.0

1 8. The Principal receives the request (either as an alert or at next log in). 2 9. The Principal accepts or rejects the request. If the Principal rejects the 3 request, the Principal continues to appear offline to the Watcher. If the 4 Principal accepts the request, the IM Server starts forwarding the 5 Principal’s presence information to the Watcher (if the Watcher is 6 currently active) 7 10. A Principal may have multiple presence sources (Presentities) that 8 generate presence information for the IM Server to aggregate. 9 11. The Mobile IM Client maintains contact list synchronization with IM 10 Server via the Mobile Immediate Messaging Protocol. 11 12 Presence information 13 The model defines the PRESENCE INFORMATION to consist of an arbitrary 14 number of elements, called PRESENCE TUPLES. Each such element consists of 15 a STATUS marker (which might convey information such as 16 online/offline/busy/away/do not disturb), an optional COMMUNICATION 17 ADDRESS, and optional OTHER PRESENCE MARKUP. A COMMUNICATION 18 ADDRESS includes a COMMUNICATION MEANS and a CONTACT ADDRESS. 19 One type of COMMUNICATION MEANS, and the only one defined by this model, 20 is INSTANT MESSAGE SERVICE. One type of CONTACT ADDRESS, and the 21 only one defined by this model, is INSTANT INBOX ADDRESS. However, other 22 possibilities exist: a COMMUNICATION MEANS might indicate some form of 23 telephony, for example, with the corresponding CONTACT ADDRESS containing 24 a telephone number. 25 S.R0062-0 v1.0

PRESENCE INFORMATION

PRESENCE TUPLE TUPLE STATUS STATUS COMMUNICATION ADDRESS COMMUNICATION ADDRESS OTHER MARKUP Communication means Contact address

OTHER PRESENCE MARKUP . . .

PRESENCE TUPLE TUPLE STATUS STATUS COMMUNICATION ADDRESS COMMUNICATION ADDRESS OTHER MARKUP Communication means Contact address

OTHER PRESENCE MARKUP