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

Klaus Darilion klaus.mailinglists at pernau.at
Fri Feb 19 09:57:04 CET 2010


Am 18.02.2010 18:12, schrieb Iñaki Baz Castillo:
> 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 think option 2 would be nice for debugging, as Alice immediately knows 
that she is blocked and does not have to debug why the subscription does 
not work.

Of course, from privacy point of view I would also prefer options 1 and 
3. IMO option 1 is better. Because with option 3 Alice would think that 
Bob is really offline, whereas option 1 just signals "nothing" and thus 
tells Alice that the information is just not available.

regards
klaus

>
> I would appreciate your opinnions about it.
> Thanks.
>
>



More information about the sr-dev mailing list