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.
Hi Inaki,
On 02/18/2010 06:37 PM, Iñaki Baz Castillo wrote:
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):
- 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).
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 two won't be much useful. Sending reject to user won't look polite :-). 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".
Not sure how currently is handled by other IM when you do "deny" for presence subscription requests. I hope is not that tough :-) -- using gmail/yahoo/... email opens you to a lot potential subscriptions that have to be denied.
Cheers, Daniel
I would appreciate your opinnions about it. Thanks.
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.
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.
This sounds like the "invisible" feature of ICQ
klaus
El Viernes, 19 de Febrero de 2010, Klaus Darilion escribió:
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.
This sounds like the "invisible" feature of ICQ
Yes :)
Perhaps we should redefine the blocking actions:
- "polite-block" means "set invisible", and it's *just* useful for our buddy list contacts. This is, we don't explicitely block a buddy in our contact list, but instead we lie him by setting "invisible" status for a while. For example: "I want to talk with Alice and want to show her my wonderful nacked photo, but I don't want my friend Carol to see me connected, neither my photo".
- "block" means explicitely reject a subscription request (the subscriber knows it has been rejected). This is useful when we receive an invitation from a person we don't know or we hate ("no, I'm *not* your friend!").
- "ignore" means "I don't want to accept this user right now, so let the subscriber think that I'm not online now and cannot handle the request for now". The subscription remains in "pending" state until the server expires it and sends a NOTIFY to the subscriber with: Subscription-Status: terminated; reason=timeout This is like when you receive a Linkedin invitation from some person you know nothing about, so you don't want to accept it but neither explicitely reject his offer (perhaps he wants to pay you for a good job!!!). So you leave the request in "pending" state and search for such user in Google.
I think that the above points cover all the required features for blocking a user (when he is in our buddylist, when we don't want him in our buddylist and when we want just to ignore his request for now).
Are you agree? Thanks a lot.
Am 19.02.2010 12:10, schrieb Iñaki Baz Castillo:
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.
Why not terminate the subscription if Bob removes Alice from the allowed buddies?
Then Alice will SUBSCRIBE again and receives status=pending.
regards klaus
El Viernes, 19 de Febrero de 2010, Klaus Darilion escribió:
Am 19.02.2010 12:10, schrieb Iñaki Baz Castillo:
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.
Why not terminate the subscription if Bob removes Alice from the allowed buddies?
Then Alice will SUBSCRIBE again and receives status=pending.
But then Alice will know (or can know) that you have rejected her!
Imagine you want to "captivate" Carol but don't want Alice to know that you are connected. You don't want to reject Alice, but just set "invisible" for her (you don't want to reject Alice because if you don't captivate Carol you would like to try with Alice later). :)
Hi,
there could be other reasons to block subscriptions. Maybe the operator of the service decides that Alice and Bob are on different realms, and are thus not allowed to subscribe each others status. Explicitly blocking these requests, eventually with a reason would be the right way to do this.
Marcus
On Fri, Feb 19, 2010 at 1:40 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
El Viernes, 19 de Febrero de 2010, Klaus Darilion escribió:
Am 19.02.2010 12:10, schrieb Iñaki Baz Castillo:
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.
Why not terminate the subscription if Bob removes Alice from the allowed buddies?
Then Alice will SUBSCRIBE again and receives status=pending.
But then Alice will know (or can know) that you have rejected her!
Imagine you want to "captivate" Carol but don't want Alice to know that you are connected. You don't want to reject Alice, but just set "invisible" for her (you don't want to reject Alice because if you don't captivate Carol you would like to try with Alice later). :)
-- Iñaki Baz Castillo ibc@aliax.net
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
El Miércoles, 24 de Febrero de 2010, Marcus Hunger escribió:
Hi,
there could be other reasons to block subscriptions. Maybe the operator of the service decides that Alice and Bob are on different realms, and are thus not allowed to subscribe each others status. Explicitly blocking these requests, eventually with a reason would be the right way to do this.
Shouldn't then the operator reply "403 Forbidden" for the SUBSCRIBE?
Not very polite, neither enlightenment... I can image that Alice and Bob would never talk each other again, 'cause they would think that the other wan't to have other's 'contact'.... :)
But, yes... it'd do the job.
Edson.
Iñaki Baz Castillo escreveu:
El Miércoles, 24 de Febrero de 2010, Marcus Hunger escribió:
Hi,
there could be other reasons to block subscriptions. Maybe the operator of the service decides that Alice and Bob are on different realms, and are thus not allowed to subscribe each others status. Explicitly blocking these requests, eventually with a reason would be the right way to do this.
Shouldn't then the operator reply "403 Forbidden" for the SUBSCRIBE?
2010/2/24 Edson - Lists 4lists@gmail.com:
Not very polite, neither enlightenment... I can image that Alice and Bob would never talk each other again, 'cause they would think that the other wan't to have other's 'contact'.... :)
Well, IMHO is worse if the presence server replies 200 for the SUBSCRIBE and inmediately rejects the subscription with a NOTIFY containing "Subscription-status: terminated;reason=rejected". In this way it really seems that bob has blocked alice. In the other hand, if the proxy responsible for bob rejects the SUBSCRIBE from alice with 403 it's clear that it's a realm/inter-provider issue.
As far as Alice and Bob have the same interpretation, yes.
The problem here, isn't the blocking message itself, but the way it will be interpreted by both sides... The best would be have some kind of blocking message/mechanism that would leave no doubts about the real reason of the block. Believing that all Alices and Bobs out there would have the same interpretation is, at least, a flaw point.
But again, "403 Forbidden" for the SUBSCRIBE would work for sure.
Edson.
Iñaki Baz Castillo escreveu:
2010/2/24 Edson - Lists 4lists@gmail.com:
Not very polite, neither enlightenment... I can image that Alice and Bob would never talk each other again, 'cause they would think that the other wan't to have other's 'contact'.... :)
Well, IMHO is worse if the presence server replies 200 for the SUBSCRIBE and inmediately rejects the subscription with a NOTIFY containing "Subscription-status: terminated;reason=rejected". In this way it really seems that bob has blocked alice. In the other hand, if the proxy responsible for bob rejects the SUBSCRIBE from alice with 403 it's clear that it's a realm/inter-provider issue.
I agree, 403 would work.
On Wed, Feb 24, 2010 at 5:05 PM, Edson - Lists 4lists@gmail.com wrote:
As far as Alice and Bob have the same interpretation, yes.
The problem here, isn't the blocking message itself, but the way it will be interpreted by both sides... The best would be have some kind of blocking message/mechanism that would leave no doubts about the real reason of the block. Believing that all Alices and Bobs out there would have the same interpretation is, at least, a flaw point.
But again, "403 Forbidden" for the SUBSCRIBE would work for sure.
Edson.
Iñaki Baz Castillo escreveu:
2010/2/24 Edson - Lists 4lists@gmail.com:
Not very polite, neither enlightenment... I can image that Alice and Bob
would never talk each other again, 'cause they would think that the other wan't to have other's 'contact'.... :)
Well, IMHO is worse if the presence server replies 200 for the SUBSCRIBE and inmediately rejects the subscription with a NOTIFY containing "Subscription-status: terminated;reason=rejected". In this way it really seems that bob has blocked alice. In the other hand, if the proxy responsible for bob rejects the SUBSCRIBE from alice with 403 it's clear that it's a realm/inter-provider issue.
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Iñaki Baz Castillo writes:
there could be other reasons to block subscriptions. Maybe the operator of the service decides that Alice and Bob are on different realms, and are thus not allowed to subscribe each others status. Explicitly blocking these requests, eventually with a reason would be the right way to do this.
Shouldn't then the operator reply "403 Forbidden" for the SUBSCRIBE?
yes, i agree with inaki.
-- juha
-
Daniel-Constantin Mierla -
Edson - Lists -
Iñaki Baz Castillo -
jh＠tutpro.com -
Klaus Darilion -
Marcus Hunger