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(a)aliax.net>