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):
- 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
- 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.
- 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.
- 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.