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

Iñaki Baz Castillo ibc at aliax.net
Fri Feb 19 12:10:29 CET 2010


El Viernes, 19 de Febrero de 2010, Daniel-Constantin Mierla escribió:
> > 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).

> I think two won't be much useful. Sending reject to user won't look 
> polite :-).

Fully agree.


> 1) looks good from my point of view, just letting it to 
> expire without keep notifying presentity about new watcher. Also 3) is 
> not very bad, but gives the impression that subscription request has 
> been accepted, therefore some will get it as "that guy is friend with me 
> right now".

But there is a problem with point 1 as it's not valid for the case in which 
you block a user who was allowed. This is, subscription status cannot 
transition from "active" to "pending", so the only way is using case 3 in 
which the subscription status remains "active" but the presence server sends a 
spoofed NOTIFY with "offline" status.



Anyhow I'm rebuilding all this stuff in my mind and will propose something as 
follows:


case 1)


- Bob receives a subscription request from Alice (NOTIFY Event: 
presence.winfo).

- Bob's softphone shows a dialog window:

  -------------------------------------------------------------------
  Alice has added you to her contacts list. Allow Alice to know your
  status?

  [a] Yes, allow and add to my buddy list.
  [b] No, block Alice permanently.
  [c] No, ignore the request.
  -------------------------------------------------------------------

- If Bob press [b] then Alice is "blocked", so the presence server will send a 
NOTIFY with "Subscription-Status: terminated;reason=rejected". Alice will know 
that Bob's has denied her, but IMHO it's ok. This is like when you deny some 
Linkedin contact you don't know.

- If Bob press [c] then the request remains "pending" in the server until it 
expires. Alice could retry later after expiration and Bob would see the dialog 
window again.



case 2)

- Bob already has Alice as allowed buddy in Bob's buddy list.

- Now Bob wants to block Alice so invokes "polite-block" in the server.

- From that moment Alice will think that Bob is just offline.





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



More information about the sr-dev mailing list