Hello, On 9/29/10 5:12 PM, Juha Heinanen wrote: to understand that xcap server has to fetch the RL from other servers? IMO, this might be a security issue if the remote XCAP server asks for user authentication, then user has to give the password to xcap server. Anyhow, might be different that thought, since maybe you refer to RLS implementation and not xcap server: http://kamailio.org/docs/modules/stable/modules_k/rls.html On another hand, pres-rules is about the rules to allow watchers and manipulate presence information. But maybe in oma this document can have external references as well. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

2010/9/29 Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt;om>: Yes, it could. IMHO in XCAP all is a security issue. pres-rules and resource-lists document contain absolute HTTP uris refering ot other documents of subnodes in other documents (in same or different XCAP server). If you decide (the provider) to change the domain or migrate from HTTP to HTTPS, then all the documents get corrupted. As I said, in OMA specs pres-rules contains absolute HTTP links to <list> elements in resource-lists document. Here is a OMA pres-rules document (extracted from OMA-WP-PRS_1_1_Implementation_Guidelines-20081209-A.pdf): <?xml version="1.0" encoding="UTF-8"?> <cr:ruleset xmlns:ocp="urn:oma:xml:xdm:common-policy" xmlns:pr="urn:ietf:params:xml:ns:pres-rules" xmlns:cr="urn:ietf:params:xml:ns:common-policy"> <!-- This rule describes that the Presentity has access to her/his own Presence Information --> <cr:rule id="wp_prs_allow_own"> <cr:conditions> <cr:identity> <cr:one id="sip:joe@example.com"/> </cr:identity> </cr:conditions> <cr:actions> <pr:sub-handling>allow</pr:sub-handling> </cr:actions> <cr:transformations> <pr:provide-services> <pr:all-services/> </pr:provide-services> <pr:provide-persons> <pr:all-persons/> </pr:provide-persons> <pr:provide-devices> <pr:all-devices/> </pr:provide-devices> <pr:provide-all-attributes/> </cr:transformations> </cr:rule> <!-- This rule describes how an anonymous Watcher’s request shall be handled --> <cr:rule id="wp_prs_block_anonymous"> <cr:conditions> <ocp:anonymous-request/> </cr:conditions> <cr:actions> <pr:sub-handling>block</pr:sub-handling> </cr:actions> </cr:rule> <!-- This rule describes that a request from a Watcher not listed in any other rule is to be confirmed. --> <cr:rule id="wp_prs_unlisted"> <cr:conditions> <ocp:other-identity/> </cr:conditions> <cr:actions> <pr:sub-handling>confirm </pr:sub-handling> </cr:actions> </cr:rule> <!-- This rule describes that a Watcher is granted access to all Presence Information if its user URI is included in the “oma_grantedcontacts” URI List in Shared XDMS--> <cr:rule id="wp_prs_grantedcontacts"> <cr:conditions> <ocp:external-list> <ocp:entry anc="http://xcap.example.org/resource-lists/users/ sip:joe@example.org/index/~~/resource-lists/list%5B@name=%22oma_grantedcontacts%22%5D"/> </ocp:external-list> </cr:conditions> <cr:actions> <pr:sub-handling>allow</pr:sub-handling> </cr:actions> <cr:transformations> <pr:provide-services> <pr:all-services/> </pr:provide-services> <pr:provide-persons> <pr:all-persons/> </pr:provide-persons> <pr:provide-devices> <pr:all-devices/> </pr:provide-devices> <pr:provide-all-attributes/> </cr:transformations> </cr:rule> <!-- This rule describes that a Watcher is blocked from accessing all Presence Information if its user URI is included in the oma_blockedcontacts list. --> <cr:rule id="wp_prs_blockedcontacts"> <cr:conditions> <ocp:external-list> <ocp:entry anc="http://xcap.example.org/resource-lists/users/ sip:joe@example.org/index/~~/resource-lists/list%5B@name=%22oma_blockedcontacts%22%5D"/> </ocp:external-list> </cr:conditions> <cr:actions> <pr:sub-handling>block </pr:sub-handling> </cr:actions> </cr:rule> <!--This rule describes that a single user is granted access to a certain set of Presence Information --> <cr:rule id="wp_prs_allow_one_1"> <cr:conditions> <cr:identity> <cr:one id="sip:bob@example.com "/> </cr:identity> </cr:conditions> <cr:actions> <pr:sub-handling>allow</pr:sub-handling> </cr:actions> <cr:transformations> <pr:provide-persons> <pr:all-persons/> </pr:provide-persons> <pr:provide-activities>true</pr:provide-activities> </cr:transformations> </cr:rule> <!--This rule describes that users on a single list in Shared XDMS is granted access to a certain set of Presence Information. --> <cr:rule id="wp_prs_allow_onelist_1"> <cr:conditions> <ocp:external-list> <ocp:entry anc="http://xcap.example.org/resource-lists/users/ sip:joe@example.org/index/~~/resource-lists/list% 5B@name=% 22list-e% 22% 5D"/> </ocp:external-list> </cr:conditions> <cr:actions> <pr:sub-handling>allow</pr:sub-handling> </cr:actions> <cr:transformations> <pr:provide-persons> <pr:all-persons/> </pr:provide-persons> <pr:provide-status-icon>true</pr:provide-status-icon> </cr:transformations> </cr:rule> <!--This rule describes that a single user is ‘polite-block’ed from accessing any Presence Information. --> <cr:rule id="wp_prs_one_1"> <cr:conditions> <cr:identity> <cr:one id="sip:jason@example.com"/> </cr:identity> </cr:conditions> <cr:actions> <pr:sub-handling>polite-block</pr:sub-handling> </cr:actions> <cr:transformations/> </cr:rule> <!--This rule describes that users on a single list in Shared XDMS is ‘polite-block’ed from accessing any Presence Information. --> <cr:rule id="wp_prs_onelist_1"> <cr:conditions> <ocp:external-list> <ocp:entry anc="http://xcap.example.org/resource-lists/users/ sip:joe@example.org/index/~~/resource-lists/list%5B@name=%22list-c%22%5D"/> </ocp:external-list> </cr:conditions> <cr:actions> <pr:sub-handling>polite-block</pr:sub-handling> </cr:actions> <cr:transformations/> </cr:rule> </cr:ruleset> Yes it has. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2010/9/30 Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt;om>: In OMA and RCS (for IMS) specs there are external references. In fact, most of the XCAP documents contains external references to the resource-list document. It's not late to think in cool features like that, but so far fom current SIMPLE specs ;) The problem is that XCAP is not just a storage engine as storage actions must trigger logic and complex actions in the XCAP server and the SIP presence server. And since all those changes are "modifications to a XML document" in order to re-calculate the logic to apply it's required that the presence server re-parses and re-computes all the XML documents (for each change), which is a really inneficient design. Regards. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2010/9/29 Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt;om>: Unfortunatelly this is not entirely true. For example, the oma-icon XCAP application (storage of an icon in XML format) requires a lot of logic in the XCAP server, why?: - Alice does a XCAP/HTMP PUT of his avatar/icon (a XCAP/XML document) to the XCAP server. - The Alice sends a PUBLISH (event "presence") to the presence server. According to OMA specs, this PUBLISH can contain a <icon> element with a link to the XCAP/XML document, something like: <icon>http://xcap.mydomain.org/org.openmobilealliance.pres-content/users/sip:alice@mydomain.com/oma_status-icon/index</icon> - Bob is a watcher allowed by Alice for event "presence". Bob receives the NOTIFY containing such <icon> link. - Bob then performs a XCAP/HTTP GET for that URL. - The XCAP server receives the GET from Bob and now, the XCAP server MUST check if Bob is allwoed or not to see Alice's status. What does it *mean*? It means that the XCAP server MUST get the 'pres-rules' document of Alice and inspect if Bob is allowed or not. Such 'pres-rules' document could contain (MUST in OMA specs) an absolute HTTP reference to Alice's 'resource-lists' document (as permissions are based on sublists. Again, 'resource-lists' document can contain (or MUST in OMA specs) absolute HTTP references to the 'resource-lists' document itself (yes, with depth 3 or 4, *really*). This means that the XCAP server MUST behave as a SIP presence server in order to allow or deny the icon of user B to user A. Painful? Yes. Read OMA-WP-PRS_1_1_Implementation_Guidelines-20081209-A.pdf and OMA-WP-XDM_1_1_Implementation_Guidelines-20081209-A.pdf. There is clear how unclear the specs are. But basically, as I've said above, pres-rules document contains absolute HTTP links to resource-lists document, and resource-lists document contains absolute HTTP links to itself. Regards. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2010/9/30 Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt;om>: Yes, but this mechanism is a bit "weak". Imagine I'm allowed by Bob and retrieve his icon. Later Bob's blocks me. Now if my client tries to retrieve his icon again I would receive a 403 or 404 (customizable using the script). Any code tells me that I've been blocked. For sure all of us know web pages like "Discover if your friend has blocked you in MSN !!!". Well, here is a way to do the same in this "cool" SIP/SIMPLE specification. And there is no solution. When I block a user he must believe that I've been disconnected, but since icon is retrieved via HTTP from a permanent storage then there is way to realize that I've blocked such user. The only solution is carrying the icon in the NOTIFY itself as XMPP does (by default). Regards. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2010/9/30 Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt;om>: In fact, in XMPP there is no concept of "buddylist" document. Instead each user has a roster and can add/modify/delete individual buddies without caring about the existance or not of a "resource-lists" document. I would say 99% :) -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

Daniel-Constantin Mierla writes: yes, there definitely is good potential in integrating xcap server in sip router. what comes to sip router's presence server, a bigger job would need to be done there as it should be able to follow external references to buddy lists. here is an example from oma spec for such a reference: <?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <list name="oma_buddylist"> <external anchor="http://xcap.example.org/resource-lists/users/ sip:joebloggs@example.com/index/~~/resource-lists/list%5B@name=%22list-a%22%5D"> </external> </list> </resource-lists> the list itself in the other document could look like this: <list name="oma_buddylist"> <display-name>My friends</display-name> <entry uri="sip:friend1@example.com"> <display-name>Friend1</display-name> </entry> <entry uri="sip:friend2@example.com"> <display-name>Friend2</display-name> </entry> </list> -- juha

2010/9/30 Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;et>: Hi, I copy some of the new features and/or fixes in the recent OpenXCAP 2.0: * Added OMA XDM support for Buddy Lists Management * Unquote external references in resource-lists and pres-rules * Use allow_external_references setting also for entry-ref elements * Don't allow relative URIs to link to another users' resource list entry * Check external references for pres-rules and resource-lists * Don't allow external-ref paths which don't point to an 'entry' * Check entry-ref entries in resource-lists * Fixed support for XCAP default document namespace It's more than clear to me that the specs are a big pain if an implementation requires so many "workarounds". -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;