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>