DesignBuddyList
Version 58 (Adrian Georgescu, 01/28/2010 01:00 pm) → Version 59/115 (Adrian Georgescu, 01/28/2010 01:10 pm)
= Presence blueprint =
[[TOC(DesignBuddyList, depth=2)]]
This is a high level representation of a mechanism that maintains a '''Contacts list''' and handles subscriptions, publications and notifications that can be used by a GUI. It implements a combination of SIP SIMPLE standards related to presence event package, storage and policy.
== Contacts List ==
''Contacts List'' contains is a list of contacts displayed by the GUI. To build this consolidated list, the SIP client supporting multiple SIP accounts must perform for each account the steps from the ''Account'' section. Some contacts are marked to Subscribe to them for Presence information.
The list is indexed by a unique SIP URI, a random SIP URI must be generated for contacts that do not have a SIP URI and we must mark the contacts that we want to subscribe to. Additional, one can store full names and other attributes for each contact by using extensions to PIDF for contact information (cipid extension).
Based on received NOTIFY messages for ''Event=presence'', each Contact has a '''presentity''' attribute that contains its own published information. The GUI can display attributes of each '''presentity'''. Each contact can also publish properties related to his device capabilities (e.g. can_chat, can_share, can_talk, can_video). This is conveyed via '''caps''' extensions to pidf.
== Storage ==
The SIP client maintains the a '''Contacts list''' as that is a concatenated list of resource-lists stored on multiple XCAP servers. A Contact is stored on exactly one XCAP server to provide atomic transaction. When a Contact is added/modified/deleted the corespondent remote XCAP storage is accessed. The remote storage is set per Contact in the Add/Edit Contact dialog.
[[Image(BuddyList-Aggregation.png)]]
== Account ==
On boot:
If ''account.xcap'' is enabled
* If '''account.xcap.xcap_root''' is not defined, locate XCAP root by doing a DNS TXT lookup for xcap.example.com
* GET XCAP application xcap-caps
* For support application each document returned by above step, GET the default filename for all applications supported in xcap-caps and cache them locally
* If '''account.xcap.subscribe_xcap_diff''' is enabled, SUBSCRIBE for '''Event: xcap-diff'''
* if ''Icon'' application is enabled GET xcap-directory and locate previously uploaded icon (e.g. ABC)
If ''account.presence.enable_publish'' is enabled
* If '''pidf-manipulation''' application is supported by XCAP server, update the '''presentity''' with the PIDF stored on the XCAP server
* Initialize own '''presentity'''
* Send Publish
If ''account.presence.subscribe_winfo'' is enabled
* Initialize '''watchers list''' for Event presence
* Send Subscribe for ''presence.winfo''
If ''account.presence.resource_lists'' is enabled
* Initialize the '''Contacts List''' by using the content of the XCAP document '''resource-lists''', filename '''index'''. '''resource-lists'''. Initialize the ''Subscriptions List'' using the Contacts marked for this
If ''account.presence.rls_services'' is enabled
* Put the content of ''Subscription List'' initialized above to the XCAP document '''rls-services''' identified by account-buddies@domain
If ''account.presence.subscribe_presence'' is enabled
* If '''account.presence.subscribe_rls_services''' is True send Subscribe for event presence , and header Supported: eventlist to account-buddies@domai
* Else for each contact in the ''Contacts Lists'' send Subscribe for event presence
While running
* Refresh the XCAP server location based on DNS TTL
* Reload XCAP documents based on '''xcap-diff''' NOTIFYs
== Contacts List ==
''Contacts List'' contains is a list of contacts displayed by the GUI. To build this consolidated list, the SIP client supporting multiple SIP accounts must perform for each account the steps from the ''Account'' section.
For some contacts we SUBSCRIBE for '''Event: presence'''. We must mark each recipient ion the list for which we subscribe.
The list is indexed by a unique SIP URI, a random SIP URI must be generated for contacts that do not have a SIP URI and we must mark the contacts that we want to subscribe to.
Additional, one can store full names and other attributes for each contact by using extensions to PIDF for contact information (cipid extension).
Based on received NOTIFY messages for Event=presence, each contact has a '''presentity''' attribute that contains its own published information. The GUI can display attributes of each '''presentity'''.
* The contacts list is stored in the main '''resource-lists''' XCAP document '''index'''
* Maintain a '''presentity''' attribute with what is received in the Notify for presence for each contact
* On contacts list change, PUT resource-lists and rls-services documents on the XCAP server
A contact has properties related to his device capabilities (e.g. can_chat, can_share, can_talk, can_video). This is conveyed via '''presence caps''' and updates the preferences set by the local user
== Policy change ==
* Based on NOTIFYs for event '''presence.winfo''' we alert the user about new watchers and we update the policy stored in the pres-rules XCAP document
* PUT '''pres-rules''' document on the XCAP server and cache it locally
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
== Icon change ==
There is how OMA has specified such XCAP application [http://www.openmobilealliance.org/technical/release_program/docs/PresenceSIMPLE/V2_0-20081223-C/OMA-TS-Presence_SIMPLE_Content_XDM-V1_0-20081223-C.pdf Presence Content XDM Specification]
Publishing end-point: end-point, on boot:
1. HTTP GET for xcap-directory and locate previously uploaded icon (e.g. ABC)
1. HTTP GET http://xcap.example.com/xcap-root/org.openmobilealliance.pres-content/users/sip:alice@example.com/oma_status-icon/ABC
Publishing end-point, on icon change:
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. HTTP PUT the new icon document to XCAP xcap server
1. Update <icon> element of pidf and PUBLISH new pidf
1. HTTP DELETE any previously uploaded previous icon file ABC
Subscribing end-point:
1. Parse <icon> element of pidf cipid extension received in NOTIFY 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
[[TOC(DesignBuddyList, depth=2)]]
This is a high level representation of a mechanism that maintains a '''Contacts list''' and handles subscriptions, publications and notifications that can be used by a GUI. It implements a combination of SIP SIMPLE standards related to presence event package, storage and policy.
== Contacts List ==
''Contacts List'' contains is a list of contacts displayed by the GUI. To build this consolidated list, the SIP client supporting multiple SIP accounts must perform for each account the steps from the ''Account'' section. Some contacts are marked to Subscribe to them for Presence information.
The list is indexed by a unique SIP URI, a random SIP URI must be generated for contacts that do not have a SIP URI and we must mark the contacts that we want to subscribe to. Additional, one can store full names and other attributes for each contact by using extensions to PIDF for contact information (cipid extension).
Based on received NOTIFY messages for ''Event=presence'', each Contact has a '''presentity''' attribute that contains its own published information. The GUI can display attributes of each '''presentity'''. Each contact can also publish properties related to his device capabilities (e.g. can_chat, can_share, can_talk, can_video). This is conveyed via '''caps''' extensions to pidf.
== Storage ==
The SIP client maintains the a '''Contacts list''' as that is a concatenated list of resource-lists stored on multiple XCAP servers. A Contact is stored on exactly one XCAP server to provide atomic transaction. When a Contact is added/modified/deleted the corespondent remote XCAP storage is accessed. The remote storage is set per Contact in the Add/Edit Contact dialog.
[[Image(BuddyList-Aggregation.png)]]
== Account ==
On boot:
If ''account.xcap'' is enabled
* If '''account.xcap.xcap_root''' is not defined, locate XCAP root by doing a DNS TXT lookup for xcap.example.com
* GET XCAP application xcap-caps
* For support application each document returned by above step, GET the default filename for all applications supported in xcap-caps and cache them locally
* If '''account.xcap.subscribe_xcap_diff''' is enabled, SUBSCRIBE for '''Event: xcap-diff'''
* if ''Icon'' application is enabled GET xcap-directory and locate previously uploaded icon (e.g. ABC)
If ''account.presence.enable_publish'' is enabled
* If '''pidf-manipulation''' application is supported by XCAP server, update the '''presentity''' with the PIDF stored on the XCAP server
* Initialize own '''presentity'''
* Send Publish
If ''account.presence.subscribe_winfo'' is enabled
* Initialize '''watchers list''' for Event presence
* Send Subscribe for ''presence.winfo''
If ''account.presence.resource_lists'' is enabled
* Initialize the '''Contacts List''' by using the content of the XCAP document '''resource-lists''', filename '''index'''. '''resource-lists'''. Initialize the ''Subscriptions List'' using the Contacts marked for this
If ''account.presence.rls_services'' is enabled
* Put the content of ''Subscription List'' initialized above to the XCAP document '''rls-services''' identified by account-buddies@domain
If ''account.presence.subscribe_presence'' is enabled
* If '''account.presence.subscribe_rls_services''' is True send Subscribe for event presence , and header Supported: eventlist to account-buddies@domai
* Else for each contact in the ''Contacts Lists'' send Subscribe for event presence
While running
* Refresh the XCAP server location based on DNS TTL
* Reload XCAP documents based on '''xcap-diff''' NOTIFYs
== Contacts List ==
''Contacts List'' contains is a list of contacts displayed by the GUI. To build this consolidated list, the SIP client supporting multiple SIP accounts must perform for each account the steps from the ''Account'' section.
For some contacts we SUBSCRIBE for '''Event: presence'''. We must mark each recipient ion the list for which we subscribe.
The list is indexed by a unique SIP URI, a random SIP URI must be generated for contacts that do not have a SIP URI and we must mark the contacts that we want to subscribe to.
Additional, one can store full names and other attributes for each contact by using extensions to PIDF for contact information (cipid extension).
Based on received NOTIFY messages for Event=presence, each contact has a '''presentity''' attribute that contains its own published information. The GUI can display attributes of each '''presentity'''.
* The contacts list is stored in the main '''resource-lists''' XCAP document '''index'''
* Maintain a '''presentity''' attribute with what is received in the Notify for presence for each contact
* On contacts list change, PUT resource-lists and rls-services documents on the XCAP server
A contact has properties related to his device capabilities (e.g. can_chat, can_share, can_talk, can_video). This is conveyed via '''presence caps''' and updates the preferences set by the local user
== Policy change ==
* Based on NOTIFYs for event '''presence.winfo''' we alert the user about new watchers and we update the policy stored in the pres-rules XCAP document
* PUT '''pres-rules''' document on the XCAP server and cache it locally
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
== Icon change ==
There is how OMA has specified such XCAP application [http://www.openmobilealliance.org/technical/release_program/docs/PresenceSIMPLE/V2_0-20081223-C/OMA-TS-Presence_SIMPLE_Content_XDM-V1_0-20081223-C.pdf Presence Content XDM Specification]
Publishing end-point: end-point, on boot:
1. HTTP GET for xcap-directory and locate previously uploaded icon (e.g. ABC)
1. HTTP GET http://xcap.example.com/xcap-root/org.openmobilealliance.pres-content/users/sip:alice@example.com/oma_status-icon/ABC
Publishing end-point, on icon change:
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. HTTP PUT the new icon document to XCAP xcap server
1. Update <icon> element of pidf and PUBLISH new pidf
1. HTTP DELETE any previously uploaded previous icon file ABC
Subscribing end-point:
1. Parse <icon> element of pidf cipid extension received in NOTIFY 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