[sr-dev] Your opinion about presence subscription blocking actions

Iñaki Baz Castillo ibc at aliax.net
Thu Feb 18 18:37:14 CET 2010


Hi, I'm dealing with presence right now. I've read full OMA and RCS 
specifications/proposals/guidelines for presence and XCAP but I don't feel 
comfortable with some parts of them.

So let me to explain the question (it involves the sr/kamailio presence module 
behavior for a future re-design in which I want to participate):

In presence/XCAP/XDM there are three ways bob can deny alice to see his 
presence status (by modifying the XCAP documents according):

1) Ignore alice's request. This is, bob doesn't "allow" neither "blocks" 
alice, so alice just gets the first NOTIFY from the server with:
  Subscription-Status: pending
After some long time the server will send:
  Subscription-Status: terminated ; reason=expired

2) Block alice by invoking a "block" action. This means that alice receives a 
NOTIFY from the server with:
  Subscription-Status: terminated; reason=rejected
This is: alice *knows* that she has been explicitely blocked by bob.

3) Polite-block alice by invoking "polite-block" action. In this way the 
presence server generates a spoofed NOTIFY for alice containing "offline" 
information but the header:
  Subscription-Status: active
This is: alice *things* she has been allowed by bob and bob it's offline right 
now (not true).


Well, in real IM/presence world (MSN, Skype, XMPP, Yahoo...) option 2 doesn't 
exist, am I right? This is, if you block an user he doesn't know that you have 
blocked him. Instead just options 1 or 3 are used (and in some networks just 
option 1).

Do you see any advantage in point 2? Personally I don't see it and it just 
introduces too much complexity for presence/XCAP/XDM client developers.

I would appreciate your opinnions about it.
Thanks.


-- 
Iñaki Baz Castillo <ibc at aliax.net>



More information about the sr-dev mailing list