Re: [sr-dev] git:master: xcap_server: support parsing oma pres-rules auid

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;