DesignBuddyList

Version 107 (Luci Stanescu, 08/27/2010 12:21 pm)

1 106 Adrian Georgescu
= Presence Requirements =
2 2 Adrian Georgescu
3 55 Adrian Georgescu
[[TOC(DesignBuddyList, depth=2)]]
4 1 Adrian Georgescu
5 88 Adrian Georgescu
This is a high level design for implementing the SIP SIMPLE standards related to ''presence'' and ''presence.winfo'' event packages into the ''SIP SIMPLE client'' that achieves the following goals:
6 1 Adrian Georgescu
7 94 Adrian Georgescu
 1. Manages a ''Contacts List''
8 94 Adrian Georgescu
 1. Controls the presence information published by a ''SIP account'', handles the Subscriptions and Notifications for the ''Contacts''
9 94 Adrian Georgescu
 1. Manages an ''Icon'' (a small size picture of the end user using the client)
10 100 Adrian Georgescu
 1. Managed the ''Policy'' that described who has access to what part of the published PIDF
11 1 Adrian Georgescu
12 86 Adrian Georgescu
The design requires a ''Presence Agent'' and an ''XCAP server'' serving the domain of the SIP account for which this functionality is desired.
13 86 Adrian Georgescu
14 1 Adrian Georgescu
== Contacts List ==
15 1 Adrian Georgescu
16 86 Adrian Georgescu
''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.
17 59 Adrian Georgescu
18 86 Adrian Georgescu
The ''Contacts List'' is organized into ''Groups''. The ''SIP client'' maintains this central ''Groups List'' by merging all found groups on local and remote storage(s) and populates each group with all contacts found for them.
19 70 Adrian Georgescu
20 86 Adrian Georgescu
Some contacts are marked to Subscribe to them for ''Event: presence''. Based on received Notify messages for ''Event: presence'', each Contact has a ''presentity'' attribute that contains its own published information as pidf xml payload, the GUI can display attributes of it.
21 1 Adrian Georgescu
22 78 Adrian Georgescu
The following presence related payloads as used to generate the presentity payload used for publish:
23 78 Adrian Georgescu
24 78 Adrian Georgescu
 * Presence Data Model RFC4479
25 78 Adrian Georgescu
 * Rich Presence Extensions RFC4480
26 78 Adrian Georgescu
 * Contact Information for the Presence Information Data Format RFC4482
27 78 Adrian Georgescu
 * User Agent Capability Extension to Presence Information Data Format RFC5196
28 78 Adrian Georgescu
29 78 Adrian Georgescu
> Same Contact may end up belonging to different Groups if the same SIP address is stored on multiple XCAP servers in different groups.
30 1 Adrian Georgescu
 
31 79 Adrian Georgescu
The ''SIP client'' builds the ''Contacts List'' by concatenating the individual lists stored locally or on the ''resource-lists'' documents stored on the XCAP server corespondent to each SIP account. 
32 1 Adrian Georgescu
33 79 Adrian Georgescu
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.
34 79 Adrian Georgescu
35 1 Adrian Georgescu
[[Image(BuddyList-Aggregation.png)]]
36 1 Adrian Georgescu
37 78 Adrian Georgescu
== Account ==
38 1 Adrian Georgescu
39 79 Adrian Georgescu
Each SIP Account has settings in the middleware that affect the way it interacts with its correspondent Contacts
40 78 Adrian Georgescu
41 79 Adrian Georgescu
 * 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
42 79 Adrian Georgescu
 * Stores its data into the XCAP server corespondent with the SIP account or locally if no XCAP server is available
43 1 Adrian Georgescu
44 98 Adrian Georgescu
[[Image(contact-details.jpg)]]
45 98 Adrian Georgescu
46 87 Adrian Georgescu
=== Storage ===
47 78 Adrian Georgescu
48 1 Adrian Georgescu
If ''account.xcap'' is enabled
49 1 Adrian Georgescu
50 60 Adrian Georgescu
 * If ''account.xcap.xcap_root'' is not set, locate XCAP root by doing a DNS TXT lookup for xcap.example.com
51 1 Adrian Georgescu
 * GET XCAP application xcap-caps
52 1 Adrian Georgescu
 * GET XCAP application xcap-directory
53 1 Adrian Georgescu
 * For all supported applications returned by above step, GET their files and cache them locally
54 78 Adrian Georgescu
55 57 Adrian Georgescu
If ''Icon'' application is enabled
56 78 Adrian Georgescu
57 78 Adrian Georgescu
 * GET the previous icon using HTTP request
58 87 Adrian Georgescu
 * Refresh the location of the XCAP server based on DNS TTL
59 78 Adrian Georgescu
60 87 Adrian Georgescu
=== Publish  ===
61 78 Adrian Georgescu
62 105 Adrian Georgescu
If ''account.presence.enabled'' is True
63 78 Adrian Georgescu
64 1 Adrian Georgescu
  * Send Publish with the current pidf if pidf_manipulation is not set, let the user change his state manually if pidf_manipulation is set
65 78 Adrian Georgescu
66 105 Adrian Georgescu
If ''account.xcap'' is enabled and ''account.presence.enabled'' is True
67 1 Adrian Georgescu
68 54 Adrian Georgescu
 * Initialize the ''Contacts List'' by using the content of the XCAP document ''resource-lists'', filename ''index''. Initialize the ''Subscriptions List'' using the Contacts marked for ''Subscribe to Presence''
69 1 Adrian Georgescu
70 105 Adrian Georgescu
If ''account.xcap'' is enabled and  ''account.presence.use_rls_services'' is enabled
71 1 Adrian Georgescu
72 1 Adrian Georgescu
 * Put the content of ''Subscription List'' initialized above to the XCAP document ''rls-services'' identified by SIP URI account-buddies@domain.
73 54 Adrian Georgescu
74 102 Adrian Georgescu
=== PIDF manipulation ===
75 1 Adrian Georgescu
76 104 Adrian Georgescu
 1. Add menu item with ''Offline status'' that brings up dialog window with Presence Activity and Note to be displayed while offline.
77 103 Adrian Georgescu
 1. Add a reminder icon on main interface so that we know we have set this offline status
78 1 Adrian Georgescu
79 102 Adrian Georgescu
=== Subscribe ===
80 1 Adrian Georgescu
81 104 Adrian Georgescu
If ''account.xcap'' is enabled and ''account.xcap.use_xcap_diff'' is enabled
82 87 Adrian Georgescu
83 78 Adrian Georgescu
 * Sent Subscribe for ''Event: xcap-diff'' to the account own SIP address
84 90 Adrian Georgescu
85 104 Adrian Georgescu
If ''account.presence.enabled'' is True
86 1 Adrian Georgescu
87 104 Adrian Georgescu
 * Send Subscribe for ''presence.winfo'' to the account own SIP address
88 87 Adrian Georgescu
89 104 Adrian Georgescu
If ''account.presence.use_rls_services'' is True
90 90 Adrian Georgescu
91 104 Adrian Georgescu
 * Send one Subscribe for ''Event: presence'', and header ''Supported: eventlist'' to sip:account-buddies@domain
92 104 Adrian Georgescu
93 104 Adrian Georgescu
else
94 104 Adrian Georgescu
95 104 Adrian Georgescu
 * For each contact in the ''Subscriptions List'' send individual Subscribe for ''Event: presence''
96 87 Adrian Georgescu
97 78 Adrian Georgescu
=== Notify ===
98 78 Adrian Georgescu
99 78 Adrian Georgescu
 * On Notify for ''Event: xcap-diff'' that a supported XCAP document has been changed by other SIP UA GET the new document
100 78 Adrian Georgescu
 * On Notify for ''Event: presence'' update the presentity of affected Contacts
101 87 Adrian Georgescu
 * On Notify for ''Event: presence.winfo'' trigger notifications end user to update its policy
102 1 Adrian Georgescu
103 59 Adrian Georgescu
> 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). 
104 54 Adrian Georgescu
105 91 Adrian Georgescu
=== Policy change ===
106 62 Adrian Georgescu
107 87 Adrian Georgescu
 * Based on Notify for ''Event: presence.winfo'' alert the user about new watchers
108 87 Adrian Georgescu
 * If ''account.xcap'' is enabled PUT ''pres-rules'' document on the XCAP server
109 32 Adrian Georgescu
110 1 Adrian Georgescu
Transformations are required to support the following functionality:
111 56 Adrian Georgescu
112 1 Adrian Georgescu
 1.  First degree watchers - access to entire PIDF
113 1 Adrian Georgescu
 1.  Second degree watchers - access to subset of PIDF
114 59 Adrian Georgescu
 1.  Third degree watchers - access to basic presence online/offline
115 32 Adrian Georgescu
116 96 Adrian Georgescu
=== Notifications ===
117 96 Adrian Georgescu
118 96 Adrian Georgescu
The SIP client must be notified by the middleware when a network event related to Presence occurs:
119 96 Adrian Georgescu
120 96 Adrian Georgescu
 1. ''Watcher list'' has changed
121 96 Adrian Georgescu
 1. Account has activated/deactivated to update the ''Contacts List''
122 96 Adrian Georgescu
 1. Presence information of a Contact has changed
123 96 Adrian Georgescu
 1. A conflict exists between the server version and the local version of an XCAP document
124 96 Adrian Georgescu
 
125 96 Adrian Georgescu
Each ''Contact'' can publish properties related to his device capabilities (e.g. chat, audio, video). This is conveyed via ''caps'' extension to ''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.
126 96 Adrian Georgescu
127 96 Adrian Georgescu
=== Actions ===
128 96 Adrian Georgescu
129 96 Adrian Georgescu
 1. Display and manages the ''Contacts List''
130 96 Adrian Georgescu
 1. Display attributes of the Presence information of each Contact 
131 96 Adrian Georgescu
 1. Manage the content of the ''Policy'' document
132 96 Adrian Georgescu
 1. Update the ''Icon'' of the SIP account
133 96 Adrian Georgescu
134 92 Adrian Georgescu
== Icon ==
135 84 Adrian Georgescu
136 92 Adrian Georgescu
Publishing end-point:
137 1 Adrian Georgescu
138 91 Adrian Georgescu
 1. Generate a new random filename: XYZ
139 91 Adrian Georgescu
 1. Build URL http://xcap.example.com/xcap-root/org.openmobilealliance.pres-content/users/sip:alice@example.com/oma_status-icon/XYZ
140 84 Adrian Georgescu
 1. PUT the new icon document to XCAP server
141 84 Adrian Georgescu
 1. Update <icon> element of pidf and PUBLISH new pidf
142 1 Adrian Georgescu
 1. DELETE any previously uploaded icon file
143 84 Adrian Georgescu
144 84 Adrian Georgescu
Subscribing end-point:
145 92 Adrian Georgescu
146 84 Adrian Georgescu
 1. Parse <icon> element of pidf cipid extension received in Notify
147 84 Adrian Georgescu
 2. HTTP GET http://xcap.example.com/xcap-root/org.openmobilealliance.pres-content/users/sip:alice@example.com/oma_status-icon/XYZ
148 91 Adrian Georgescu
 3. Cache picture until next Notify with diferent <icon> element is received
149 84 Adrian Georgescu
150 84 Adrian Georgescu
The icon is common across all accounts, it must be put on all XCAP servers for all active accounts.
151 99 Adrian Georgescu
152 99 Adrian Georgescu
153 99 Adrian Georgescu
== Policy ==
154 99 Adrian Georgescu
155 101 Adrian Georgescu
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.  
156 101 Adrian Georgescu
157 101 Adrian Georgescu
158 1 Adrian Georgescu
[[Image(PresencePolicy.png)]]
159 106 Adrian Georgescu
160 106 Adrian Georgescu
 = Presence Design =
161 106 Adrian Georgescu
162 106 Adrian Georgescu
 1. Contact management
163 106 Adrian Georgescu
  1. local vs xcap (resourcelist) storage
164 106 Adrian Georgescu
 1. Incoming presence
165 106 Adrian Georgescu
  1. Subscribe to presence
166 106 Adrian Georgescu
  1. Subscribe to dialog-event
167 106 Adrian Georgescu
  1. RLS Services document management
168 106 Adrian Georgescu
 1. Outgoing presence
169 106 Adrian Georgescu
  1. Publish presence, dialog-event
170 106 Adrian Georgescu
  1. PIDF-manipulation
171 106 Adrian Georgescu
  1. Subscribe .winfo
172 106 Adrian Georgescu
  1. Pres-rules, dialog-rules
173 106 Adrian Georgescu
  1. Icon
174 106 Adrian Georgescu
175 106 Adrian Georgescu
 == Published items ==
176 106 Adrian Georgescu
177 106 Adrian Georgescu
 1. presence activity
178 106 Adrian Georgescu
 1. presence note
179 106 Adrian Georgescu
 1. icon
180 106 Adrian Georgescu
 1. location URL
181 106 Adrian Georgescu
 1. display name
182 106 Adrian Georgescu
 1. idle status (keyboard idle)
183 106 Adrian Georgescu
 1. privacy information
184 106 Adrian Georgescu
 1. time offset from UTC
185 106 Adrian Georgescu
 1. device capabilities
186 106 Adrian Georgescu
187 106 Adrian Georgescu
 == Design notes ==
188 106 Adrian Georgescu
189 106 Adrian Georgescu
 * XCAPManager (needs to be highly robust!)
190 106 Adrian Georgescu
  * offers high-level API for accessing different types of resources (resource-lists, rls-services, pres-rules, dialog-rules, pidf)
191 106 Adrian Georgescu
  * keeps cached copies of XCAP-stored files in case there is lack of connectivity
192 106 Adrian Georgescu
  * keeps journal with high-level described changes made to files (in case of lack of connectivity, these will be retried later)
193 106 Adrian Georgescu
    * Example: Add contact luci@umts.ro to list Friends in resource-list file of account luci@ag-projects.com
194 106 Adrian Georgescu
    * Resolve possible conflicts when pushing/pulling changes (maybe based on timestamps?) 
195 106 Adrian Georgescu
  * subscribes to xcap-diff so it can be informed of changes to xcap files
196 106 Adrian Georgescu
  * estimated time of development: 2-3 weeks
197 106 Adrian Georgescu
 * Contact list in middleware
198 106 Adrian Georgescu
  * communicates with XCAPManager (uses resource-lists)
199 106 Adrian Georgescu
  * estimated time of development: 3 days
200 106 Adrian Georgescu
 * Contact list in application
201 106 Adrian Georgescu
  * uses middleware API to aggregate internally stored contact list with the contact lists of all accounts
202 106 Adrian Georgescu
  * how should the contacts be stored if the user has more than one SIP account?
203 106 Adrian Georgescu
  * estimated time of development: blink-qt 4 days, blink-cocoa ?
204 106 Adrian Georgescu
 * Incoming presence in middleware
205 106 Adrian Georgescu
  * 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)
206 106 Adrian Georgescu
  * should try to use RLS (via XCAPManager)
207 106 Adrian Georgescu
  * probably quite coupled with contact list management
208 106 Adrian Georgescu
  * solve conflicts and aggregate information from multiple publishing agents
209 107 Luci Stanescu
  * subscribe to .winfo of presence and dialog events and manage information about active, pending and blocked subscriptions (integrate with contact list)
210 107 Luci Stanescu
  * offer API for fine-grained control of published info (pres-rules and dialog-rules)
211 107 Luci Stanescu
  * be able to understand any valid policy because it can be changed by another client and notify the application when the policy is changed
212 107 Luci Stanescu
  * estimated time of development: 2 weeks
213 106 Adrian Georgescu
 * Incoming presence in application
214 106 Adrian Georgescu
  * think how to display the various information obtained from the contact objects
215 106 Adrian Georgescu
  * estimated time of development: blink-qt 1 week, blink-cocoa ?
216 106 Adrian Georgescu
 * Outgoing presence in middleware
217 106 Adrian Georgescu
  * information published via presence and dialog events
218 106 Adrian Georgescu
  * accounts should have attributes which can store information to be published (probably similar to contacts)
219 106 Adrian Georgescu
  * accounts should publish this information automatically if configured to
220 106 Adrian Georgescu
  * manage persistent presence information via xcap pidf-manipulation
221 106 Adrian Georgescu
  * publish icon via xcap
222 107 Luci Stanescu
  * estimated time of development: 1 weeks
223 106 Adrian Georgescu
 * Outgoing presence in application
224 106 Adrian Georgescu
  * push presence information to middleware for publishing
225 106 Adrian Georgescu
  * notify user of new subscription requests
226 106 Adrian Georgescu
  * manage policy in an intuitive interface
227 106 Adrian Georgescu
  * estimated time of development: blink-qt 2 weeks, blink-cocoa ?