git:master: xcap_server: support parsing oma pres-rules auid
daniel, does xcap-server already support oma pres-rules and resource-list or is it on the roadmap? -- juha
Hello, On 9/29/10 2:44 PM, Juha Heinanen wrote:
daniel,
does xcap-server already support oma pres-rules and resource-list or is it on the roadmap? xcap server is just for storage and manipulation of xml xcap docs. Presence modules are able to deal with pres-rules, not sure to what extent the oma additions.
I was writing a tutorial, I just sent the email announcing it: http://bit.ly/btrJij In the particular case of SIP Communicator, a user is allowed to see your status when you add it in your body list -- it is when SC updates the pres-rules document. The presence module fetches then the pres-rules xml doc and send presence notification to that user since it was allowed. I wait to test with other SIP clients, but there were some bugs I reported for my version of OS. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com
Daniel-Constantin Mierla writes:
xcap server is just for storage and manipulation of xml xcap docs. Presence modules are able to deal with pres-rules, not sure to what extent the oma additions.
daniel, i understand that oma resource lists stored in xcap server can contain references to external lists stored somewhere else. xcap server should thus be able to follow those references, not just store xml docs. inaki knows more about that. -- juha
Hello, On 9/29/10 5:12 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
xcap server is just for storage and manipulation of xml xcap docs. Presence modules are able to deal with pres-rules, not sure to what extent the oma additions. daniel,
i understand that oma resource lists stored in xcap server can contain references to external lists stored somewhere else. xcap server should thus be able to follow those references, not just store xml docs.
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
daniel, by coincident, this came out a minute ago and it refers to OMA XDM buddy list management and external references. i should be getting a client with oma capabilities to test in a couple of weeks. -- juha There is a new release of OpenXCAP, version 2.0.0 It contains many bug fixes and buddy lists management based on OMA XDM specifications related to SIP SIMPLE presence. openxcap (2.0.0) unstable; urgency=low * Added OMA XDM support for Buddy Lists Management * Unquote external references in resource-lists and pres-rules
2010/9/29 Daniel-Constantin Mierla <miconda@gmail.com>:
i understand that oma resource lists stored in xcap server can contain references to external lists stored somewhere else. xcap server should thus be able to follow those references, not just store xml docs.
to understand that xcap server has to fetch the RL from other servers?
Yes, it could.
IMO, this might be a security issue
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.
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
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>
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.
Yes it has. -- Iñaki Baz Castillo <ibc@aliax.net>
On 9/29/10 11:46 PM, Iñaki Baz Castillo wrote:
2010/9/29 Daniel-Constantin Mierla<miconda@gmail.com>:
i understand that oma resource lists stored in xcap server can contain references to external lists stored somewhere else. xcap server should thus be able to follow those references, not just store xml docs.
to understand that xcap server has to fetch the RL from other servers? Yes, it could.
IMO, this might be a security issue 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.
Agree. As expressed in previous email, the market didn't show the need for external references (to my knowledge so far). If it was me, I would keep the documents on xcap server only with contacts. Then each user has its own private contacts list, but there can be kind of public (or shared) contacts lists (say: support group, sales, a.s.o). that the sip client can download separately and then mixes in its GUI as it wants, based on client capabilities and user wishes. I see xcap as a storage engine, in the way that if I start the same SIP client on a different system, it is able to download configuration and contact lists. But putting the server to do client jobs is a wrong architecture. Cheers, Daniel
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 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>
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. Yes it has.
-- Daniel-Constantin Mierla http://www.asipto.com
2010/9/30 Daniel-Constantin Mierla <miconda@gmail.com>:
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.
Agree. As expressed in previous email, the market didn't show the need for external references (to my knowledge so far).
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.
If it was me, I would keep the documents on xcap server only with contacts. Then each user has its own private contacts list, but there can be kind of public (or shared) contacts lists (say: support group, sales, a.s.o). that the sip client can download separately and then mixes in its GUI as it wants, based on client capabilities and user wishes.
It's not late to think in cool features like that, but so far fom current SIMPLE specs ;)
I see xcap as a storage engine, in the way that if I start the same SIP client on a different system, it is able to download configuration and contact lists. But putting the server to do client jobs is a wrong architecture.
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 <ibc@aliax.net>
2010/9/29 Juha Heinanen <jh@tutpro.com>:
Daniel-Constantin Mierla writes:
xcap server is just for storage and manipulation of xml xcap docs. Presence modules are able to deal with pres-rules, not sure to what extent the oma additions.
daniel,
i understand that oma resource lists stored in xcap server can contain references to external lists stored somewhere else. xcap server should thus be able to follow those references, not just store xml docs.
inaki knows more about that.
And I would like to forget it because is a pain :) I continue the thread in oterh mail.
-- juha
_______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Iñaki Baz Castillo <ibc@aliax.net>
2010/9/29 Daniel-Constantin Mierla <miconda@gmail.com>:
does xcap-server already support oma pres-rules and resource-list or is it on the roadmap?
xcap server is just for storage and manipulation of xml xcap docs.
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.
Presence modules are able to deal with pres-rules, not sure to what extent the oma additions.
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 <ibc@aliax.net>
On 9/29/10 11:38 PM, Iñaki Baz Castillo wrote:
2010/9/29 Daniel-Constantin Mierla<miconda@gmail.com>:
does xcap-server already support oma pres-rules and resource-list or is it on the roadmap? xcap server is just for storage and manipulation of xml xcap docs. 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:
- 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.
Well, then this xcap server can do more than I expected so far, because it can behave like a presence server :-) since kamailio is a presence server. You can check the authorization status for watchers in config, iirc, Juha added it: http://kamailio.org/docs/modules/devel/modules_k/presence.html#id2941538 So, when there is a query for someone's resources, you can check in the config if querying person is allowed to see presence of queried person. Cheers, Daniel
Presence modules are able to deal with pres-rules, not sure to what extent the oma additions. 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.
-- Daniel-Constantin Mierla http://www.asipto.com
2010/9/30 Daniel-Constantin Mierla <miconda@gmail.com>:
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.
Well, then this xcap server can do more than I expected so far, because it can behave like a presence server :-) since kamailio is a presence server.
You can check the authorization status for watchers in config, iirc, Juha added it: http://kamailio.org/docs/modules/devel/modules_k/presence.html#id2941538
So, when there is a query for someone's resources, you can check in the config if querying person is allowed to see presence of queried person.
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 <ibc@aliax.net>
On 9/30/10 12:46 AM, Iñaki Baz Castillo wrote:
2010/9/30 Daniel-Constantin Mierla<miconda@gmail.com>:
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. Well, then this xcap server can do more than I expected so far, because it can behave like a presence server :-) since kamailio is a presence server.
You can check the authorization status for watchers in config, iirc, Juha added it: http://kamailio.org/docs/modules/devel/modules_k/presence.html#id2941538
So, when there is a query for someone's resources, you can check in the config if querying person is allowed to see presence of queried person. 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). You know I agree that the SIMPLE specs are not that good and really looking forward for a better alternative.
Funny enough, we talk about all these advanced things, like within-document references, while there are no clients implementing properly the basics. Like, ok, let's have the buddy list in one document for now and working well. I don't think that xmpp has external references in buddy list, am I wrong? That means 80% of open IM market didn't feel the need for it. With private IM networks, I couldn't spot client options for it (e.g., yahoo, skype, etc). Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com
2010/9/30 Daniel-Constantin Mierla <miconda@gmail.com>:
I don't think that xmpp has external references in buddy list, am I wrong?
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.
That means 80% of open IM market didn't feel the need for it. With private IM networks, I couldn't spot client options for it (e.g., yahoo, skype, etc).
I would say 99% :) -- Iñaki Baz Castillo <ibc@aliax.net>
On 9/30/10 1:02 PM, Iñaki Baz Castillo wrote:
2010/9/30 Daniel-Constantin Mierla<miconda@gmail.com>:
I don't think that xmpp has external references in buddy list, am I wrong? 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.
This looks indeed much better from simplicity point of view.
That means 80% of open IM market didn't feel the need for it. With private IM networks, I couldn't spot client options for it (e.g., yahoo, skype, etc). I would say 99% :) I wanted the position of sip/simple IM networks to look better than reality :-)
Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com
Daniel-Constantin Mierla writes:
Well, then this xcap server can do more than I expected so far, because it can behave like a presence server :-) since kamailio is a presence server.
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 Juha Heinanen <jh@tutpro.com>:
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>
Hi Juha, in OMA specs: - 'resource-lists' contains absolute http references to different <list> elements in the *same* document (annoying but true). - 'pres-rules' contains absolute http external references to different <list> elements in 'resource-lists' document. - Other XCAP/XDM applications also refer to <list> elements in 'resource-lists' document. -- Iñaki Baz Castillo <ibc@aliax.net>
2010/9/30 Iñaki Baz Castillo <ibc@aliax.net>:
- 'resource-lists' contains absolute http references to different <list> elements in the *same* document (annoying but true).
- 'pres-rules' contains absolute http external references to different <list> elements in 'resource-lists' document.
- Other XCAP/XDM applications also refer to <list> elements in 'resource-lists' document.
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 <ibc@aliax.net>
On 9/30/10 7:08 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Well, then this xcap server can do more than I expected so far, because it can behave like a presence server :-) since kamailio is a presence server. yes, there definitely is good potential in integrating xcap server in sip router.
What I understood from Inaki's email that needs to be supported, it is there.
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.
But isn't this the job of resource lists server, when you subscribe to a resource list? I still fail to see what xcap server should do for it. Afaik, rls module is able to follow references inside the xml doc, but I haven't really test it due to lack of clients.
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>
I don't think the first xcap server should resolve the referece and store a combined document. The value of external reference can change, and it is a matter of client or rls server to fetch it when it needs it. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com
participants (3)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Juha Heinanen