18 Feb
2010
18 Feb
'10
7:37 p.m.
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>
19 Feb
19 Feb
9:30 a.m.
New subject: Your opinion about presence subscription blocking actions
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):
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 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.
--
Daniel-Constantin Mierla
SIP Server Professional Solutions
* http://www.asipto.com/
1:10 p.m.
New subject: Your opinion about presence subscription blocking actions
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(a)aliax.net>
2:21 p.m.
New subject: Your opinion about presence subscription blocking actions
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
2:37 p.m.
New subject: Your opinion about presence subscription blocking actions
El Viernes, 19 de Febrero de 2010, Klaus Darilion escribió:
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.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
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
2:23 p.m.
New subject: Your opinion about presence subscription blocking actions
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
2:40 p.m.
New subject: Your opinion about presence subscription blocking actions
El Viernes, 19 de Febrero de 2010, Klaus Darilion escribió:
Am 19.02.2010 12:10, schrieb Iñaki Baz Castillo:
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(a)aliax.net>
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. 
24 Feb
24 Feb
10:38 a.m.
New subject: Your opinion about presence subscription blocking actions
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(a)aliax.net> wrote:
El Viernes, 19 de Febrero de 2010, Klaus Darilion
escribió:
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(a)aliax.net>
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Dipl.-Inf. (FH)
Marcus Hunger - hunger(a)sipgate.de
Telefon: +49 (0)211-63 55 55-61
Telefax: +49 (0)211-63 55 55-22
sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf
HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois
Steuernummer: 106 / 5724 / 7147, Umsatzsteuer-ID: DE219349391
www.sipgate.de - www.sipgate.at - www.sipgate.co.uk
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.
11:49 a.m.
New subject: Your opinion about presence subscription blocking actions
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?
--
Iñaki Baz Castillo <ibc(a)aliax.net>
5:35 p.m.
New subject: Your opinion about presence subscription blocking actions
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?
5:41 p.m.
New subject: Your opinion about presence subscription blocking actions
2010/2/24 Edson - Lists <4lists(a)gmail.com>om>:
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ñaki Baz Castillo
<ibc(a)aliax.net>
6:05 p.m.
New subject: Your opinion about presence subscription blocking actions
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(a)gmail.com>om>:
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.
8:07 p.m.
New subject: Your opinion about presence subscription blocking actions
I agree, 403 would work.
On Wed, Feb 24, 2010 at 5:05 PM, Edson - Lists <4lists(a)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:
--
Dipl.-Inf. (FH)
Marcus Hunger - hunger(a)sipgate.de
Telefon: +49 (0)211-63 55 55-61
Telefax: +49 (0)211-63 55 55-22
sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf
HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois
Steuernummer: 106 / 5724 / 7147, Umsatzsteuer-ID: DE219349391
www.sipgate.de - www.sipgate.at - www.sipgate.co.uk
2010/2/24 Edson - Lists
<4lists(a)gmail.com>om>:
Not very polite, neither enlightenment... I can image that Alice and Bob
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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.
6:59 p.m.
New subject: Your opinion about presence subscription blocking actions
Iñaki Baz Castillo writes:
yes, i agree with inaki.
-- juha
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?
5385
days inactive
5391
days old
13 comments
6 participants
participants (6)
-
Daniel-Constantin Mierla -
Edson - Lists -
Iñaki Baz Castillo -
jh＠tutpro.com -
Klaus Darilion -
Marcus Hunger