29 Sep
2010
29 Sep
'10
5:44 p.m.
daniel,
does xcap-server already support oma pres-rules and resource-list or is
it on the roadmap?
-- juha
29 Sep
29 Sep
7:44 p.m.
New subject: git:master: xcap_server: support parsing oma pres-rules auid
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
8:12 p.m.
New subject: git:master: xcap_server: support parsing oma pres-rules auid
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
8:19 p.m.
New subject: git:master: xcap_server: support parsing oma pres-rules auid
Hello,
On 9/29/10 5:12 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
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
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.
8:26 p.m.
New subject: git:master: xcap_server: support parsing oma pres-rules auid
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
30 Sep
30 Sep
2:24 a.m.
New subject: git:master: xcap_server: support parsing oma pres-rules auid
2010/9/29 Juha Heinanen <jh(a)tutpro.com>om>:
Daniel-Constantin Mierla writes:
And I would like to forget it because is a pain :)
I continue the thread in oterh mail.
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
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
2:38 a.m.
New subject: git:master: xcap_server: support parsing oma pres-rules auid
2010/9/29 Daniel-Constantin Mierla <miconda(a)gmail.com>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.
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.
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(a)aliax.net>
2:46 a.m.
New subject: git:master: xcap_server: support parsing oma pres-rules auid
2010/9/29 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Yes, it could.
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
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(a)aliax.net>
3:25 a.m.
New subject: git:master: xcap_server: support parsing oma pres-rules auid
On 9/29/10 11:38 PM, Iñaki Baz Castillo wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com
2010/9/29 Daniel-Constantin
Mierla<miconda(a)gmail.com>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.
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
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.
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.
3:46 a.m.
New subject: git:master: xcap_server: support parsing oma pres-rules auid
2010/9/30 Daniel-Constantin Mierla <miconda(a)gmail.com>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
<ibc(a)aliax.net>
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.
10:08 a.m.
New subject: git:master: xcap_server: support parsing oma pres-rules auid
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
2:27 p.m.
New subject: git:master: xcap_server: support parsing oma pres-rules auid
2010/9/30 Juha Heinanen <jh(a)tutpro.com>om>:
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(a)aliax.net>
3:42 p.m.
New subject: git:master: xcap_server: support parsing oma pres-rules auid
On 9/30/10 7:08 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
What I understood from Inaki's email that needs to be supported, it is
there.
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.
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
3:47 p.m.
New subject: git:master: xcap_server: support parsing oma pres-rules auid
On 9/30/10 12:46 AM, Iñaki Baz Castillo wrote:
2010/9/30 Daniel-Constantin
Mierla<miconda(a)gmail.com>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).
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
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.
3:53 p.m.
New subject: git:master: xcap_server: support parsing oma pres-rules auid
On 9/29/10 11:46 PM, Iñaki Baz Castillo wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com
2010/9/29 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
Yes,
it could.
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
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
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.
4:02 p.m.
New subject: git:master: xcap_server: support parsing oma pres-rules auid
2010/9/30 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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(a)aliax.net>
4:06 p.m.
New subject: git:master: xcap_server: support parsing oma pres-rules auid
2010/9/30 Daniel-Constantin Mierla <miconda(a)gmail.com>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.
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.
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(a)aliax.net>
4:07 p.m.
New subject: git:master: xcap_server: support parsing oma pres-rules auid
On 9/30/10 1:02 PM, Iñaki Baz Castillo wrote:
I wanted the position of sip/simple IM networks to
look better than
reality :-)
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
2010/9/30 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
This looks indeed much better from simplicity point of view.
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% :)
1 Oct
1 Oct
5:02 a.m.
New subject: git:master: xcap_server: support parsing oma pres-rules auid
2010/9/30 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
- '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(a)aliax.net>
4957
days inactive
4959
days old
18 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Juha Heinanen