DesignBuddyList » History » Revision 114
Revision 113 (Adrian Georgescu, 11/11/2010 01:04 PM) → Revision 114/115 (Adrian Georgescu, 11/11/2010 01:04 PM)
h1. = Presence Requirements = [[TOC(DesignBuddyList, depth=2)]] This is a high level design for implementing the SIP SIMPLE standards related to _presence_ ''presence'' and _presence.winfo_ ''presence.winfo'' event packages into the _SIP ''SIP SIMPLE client_ client'' that achieves the following goals: # 1. Manages a _Contacts List_ # ''Contacts List'' 1. Controls the presence information published by a _SIP account_, ''SIP account'', handles the Subscriptions and Notifications for the _Contacts_ # ''Contacts'' 1. Manages an _Icon_ ''Icon'' (a small size picture of the end user using the client) # 1. Managed the _Policy_ ''Policy'' that described who has access to what part of the published PIDF The design requires a _Presence Agent_ ''Presence Agent'' and an _XCAP server_ ''XCAP server'' serving the domain of the SIP account for which this functionality is desired. h2. == Contacts List _Contacts List_ == ''Contacts List'' contains is a list of discrete contacts displayed by the GUI. It must be managed by the SIP client at a global level above the individual SIP account level. The _Contacts List_ ''Contacts List'' is organized into _Groups_. ''Groups''. The _SIP client_ ''SIP client'' maintains this central _Groups List_ ''Groups List'' by merging all found groups on local and remote storage(s) and populates each group with all contacts found for them. Some contacts are marked to Subscribe to them for _Event: presence_. ''Event: presence''. Based on received Notify messages for _Event: presence_, ''Event: presence'', each Contact has a _presentity_ ''presentity'' attribute that contains its own published information as pidf xml payload, the GUI can display attributes of it. The following presence related payloads as used to generate the presentity payload used for publish: * Presence Data Model RFC4479 * Rich Presence Extensions RFC4480 * Contact Information for the Presence Information Data Format RFC4482 * User Agent Capability Extension to Presence Information Data Format RFC5196 > Same Contact may end up belonging to different Groups if the same SIP address is stored on multiple XCAP servers in different groups. The _SIP client_ ''SIP client'' builds the _Contacts List_ ''Contacts List'' by concatenating the individual lists stored locally or on the _resource-lists_ ''resource-lists'' documents stored on the XCAP server corespondent to each SIP account. When a Contact is added/modified/deleted the corespondent remote XCAP storage documents are also updated. The remote storage is set per Contact in the Add/Edit Contact dialog of the SIP client. This remote server storage is used for initializing the locally cached Contacts List between restarts and to synchronize changes between multiple SIP UAs configured for the same SIP account. !{}BuddyList-Aggregation.png! h2. [[Image(BuddyList-Aggregation.png)]] == Account == Each SIP Account has settings in the middleware that affect the way it interacts with its correspondent Contacts * Subscribes to information related to who has subscribed to its own presence information and generate a policy document that is used for subsequent subscriptions and notifications by the Presence Agent * Stores its data into the XCAP server corespondent with the SIP account or locally if no XCAP server is available !{}contact-details.jpg! h3. [[Image(contact-details.jpg)]] === Storage === If _account.xcap_ ''account.xcap'' is enabled * If _account.xcap.xcap_root_ ''account.xcap.xcap_root'' is not set, locate XCAP root by doing a DNS TXT lookup for xcap.example.com * GET XCAP application xcap-caps * GET XCAP application xcap-directory * For all supported applications returned by above step, GET their files and cache them locally If _Icon_ ''Icon'' application is enabled * GET the previous icon using HTTP request * Refresh the location of the XCAP server based on DNS TTL h3. === Publish === If _account.presence.enabled_ ''account.presence.enabled'' is True ** * Send Publish with the current pidf if pidf_manipulation is not set, let the user change his state manually if pidf_manipulation is set If _account.xcap_ ''account.xcap'' is enabled and _account.presence.enabled_ ''account.presence.enabled'' is True * Initialize the _Contacts List_ ''Contacts List'' by using the content of the XCAP document _resource-lists_, ''resource-lists'', filename _index_. ''index''. Initialize the _Subscriptions List_ ''Subscriptions List'' using the Contacts marked for _Subscribe ''Subscribe to Presence_ Presence'' If _account.xcap_ ''account.xcap'' is enabled and _account.presence.use_rls_services_ ''account.presence.use_rls_services'' is enabled * Put the content of _Subscription List_ ''Subscription List'' initialized above to the XCAP document _rls-services_ ''rls-services'' identified by SIP URI account-buddies@domain. h3. === PIDF manipulation # === 1. Add menu item with _Offline status_ ''Offline status'' that brings up dialog window with Presence Activity and Note to be displayed while offline. # 1. Add a reminder icon on main interface so that we know we have set this offline status h3. === Subscribe === If _account.xcap_ ''account.xcap'' is enabled and _account.xcap.use_xcap_diff_ ''account.xcap.use_xcap_diff'' is enabled * Sent Subscribe for _Event: xcap-diff_ ''Event: xcap-diff'' to the account own SIP address If _account.presence.enabled_ ''account.presence.enabled'' is True * Send Subscribe for _presence.winfo_ ''presence.winfo'' to the account own SIP address If _account.presence.use_rls_services_ ''account.presence.use_rls_services'' is True * Send one Subscribe for _Event: presence_, ''Event: presence'', and header _Supported: eventlist_ ''Supported: eventlist'' to sip:account-buddies@domain else * For each contact in the _Subscriptions List_ ''Subscriptions List'' send individual Subscribe for _Event: presence_ h3. ''Event: presence'' === Notify === * On Notify for _Event: xcap-diff_ ''Event: xcap-diff'' that a supported XCAP document has been changed by other SIP UA GET the new document * On Notify for _Event: presence_ ''Event: presence'' update the presentity of affected Contacts * On Notify for _Event: presence.winfo_ ''Event: presence.winfo'' trigger notifications end user to update its policy > Each individual contact list stored in a resource-lists document is indexed by a unique SIP URI, a random SIP URI must be generated for Contacts that do not have a real SIP URI and we must mark the contacts that we want to Subscribe to for presence information. Additional, one can store full names and other attributes related to remote recipient by using extensions to PIDF for contact information (cipid extension). h3. === Policy change === * Based on Notify for _Event: presence.winfo_ ''Event: presence.winfo'' alert the user about new watchers * If _account.xcap_ ''account.xcap'' is enabled PUT _pres-rules_ ''pres-rules'' document on the XCAP server Transformations are required to support the following functionality: # 1. First degree watchers - access to entire PIDF # 1. Second degree watchers - access to subset of PIDF # 1. Third degree watchers - access to basic presence online/offline h3. === Notifications === The SIP client must be notified by the middleware when a network event related to Presence occurs: # _Watcher list_ 1. ''Watcher list'' has changed # 1. Account has activated/deactivated to update the _Contacts List_ # ''Contacts List'' 1. Presence information of a Contact has changed # 1. A conflict exists between the server version and the local version of an XCAP document Each _Contact_ ''Contact'' can publish properties related to his device capabilities (e.g. chat, audio, video). This is conveyed via _caps_ ''caps'' extension to _pidf_ ''pidf'' and can be used to drive the contextual menu presented for each Contact related to what kind of action can be initiated to it. h3. === Actions # === 1. Display and manages the _Contacts List_ # ''Contacts List'' 1. Display attributes of the Presence information of each Contact # 1. Manage the content of the _Policy_ ''Policy'' document # 1. Update the _Icon_ ''Icon'' of the SIP account h2. == Icon == Publishing end-point: # 1. Generate a new random filename: XYZ # 1. Build URL http://xcap.example.com/xcap-root/org.openmobilealliance.pres-content/users/sip:alice@example.com/oma_status-icon/XYZ # 1. PUT the new icon document to XCAP server # 1. Update <icon> element of pidf and PUBLISH new pidf # 1. DELETE any previously uploaded icon file Subscribing end-point: # 1. Parse <icon> element of pidf cipid extension received in Notify # 2. HTTP GET http://xcap.example.com/xcap-root/org.openmobilealliance.pres-content/users/sip:alice@example.com/oma_status-icon/XYZ # 3. Cache picture until next Notify with diferent <icon> element is received The icon is common across all accounts, it must be put on all XCAP servers for all active accounts. h2. == Policy == All PIDF attributes that can be published must register themselves with the Policy manager. This Policy Manager renders these PIDF attributes in a Window where the user can associate the attributes with Contacts that subscribe to his presentity. !{}PresencePolicy.png! h1. [[Image(PresencePolicy.png)]] = Presence Design # = 1. Contact management ## 1. local vs xcap (resourcelist) storage # 1. Incoming presence ## 1. Subscribe to presence ## 1. Subscribe to dialog-event ## 1. RLS Services document management # 1. Outgoing presence ## 1. Publish presence, dialog-event ## 1. PIDF-manipulation ## 1. Subscribe .winfo ## 1. Pres-rules, dialog-rules ## 1. Icon h2. == Published items # == 1. presence activity # 1. presence note # 1. icon # 1. location URL # 1. display name # 1. idle status (keyboard idle) # 1. privacy information # 1. time offset from UTC # 1. device capabilities h2. == Design notes == * XCAPManager (DONE) ** * offers high-level API for accessing different types of resources (resource-lists, rls-services, pres-rules, dialog-rules, pidf) ** * keeps cached copies of XCAP-stored files in case there is lack of connectivity ** * keeps journal with high-level described changes made to files (in case of lack of connectivity, these will be retried later) ** * subscribes to xcap-diff so it can be informed of changes to xcap files * Contacts Manager (DONE except subscriptions which are work in progress) ** * per-account ** * communicates with XCAPManager to find out information about the contacts ** * integrate with contact list: contacts should have attributes with various information that can be retrieved by subscribing to presence and dialog events (tree structure most likely, rather than having all attributes at the same level) ** * solve conflicts and aggregate information from multiple publishing agents * Presence Manager ** * offer API for fine-grained control of published info (pres-rules and dialog-rules) ** * be able to understand any valid policy because it can be changed by another client and notify the application when the policy is changed ** * subscribe to .winfo of presence and dialog events and manage information about active, pending and blocked subscriptions (integrate with contact list) ** * notify user of new subscription requests ** * information published via presence and dialog events ** * accounts should have attributes which can store information to be published (probably similar to contacts) ** * accounts should publish this information automatically if configured to ** * manage persistent presence information via xcap pidf-manipulation ** * publish icon via xcap ** * estimated time of development: 1 weeks