Subject: RE: [Simple] About change in authorization policy

From: [email-masked]
Date: Tue, 18 Jan 2005 13:28:25 +0200

Paul,

I think there is at least one realistic case where what Jeffrey brought up causes some trouble. 

If <sphere> value is used to influence the authorization decisions, i.e. different authorization rules apply when sphere=="home" than sphere=="work", the allowed vs. forbidden state for a particular subscriber could very well change at least twice a day. If that subscriber wants to be constantly subscribed to presence whenever it is allowed, she would have to do some polling. For instance if someone forbids her boss to subscribe while she is not working, the boss would not know when to subscribe again after the previous subscription was terminated.

This makes me think that the recommended way to use <sphere> should be not to make it affect the subscription state, but just the content, perhaps using polite blocking.

If we don't come up with any other fix to this, I think at least this issue should be written in a relevant section of the presence-rules RFC. 

Possible fixes? Well, some sort of new event package might work, but in any case it would be quite complex.

Markus

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Paul Kyzivat
> Sent: 18 January, 2005 02:14
> To: Jeffrey
> Cc: [email-masked]
> Subject: Re: [Simple] About change in authorization policy
> 
> 
> 
> 
> Jeffrey wrote:
> > Hi all,
> > 
> > I would like to ask a problem about change in authorization policy. 
> > According to RFC 3265, when a presentity grants and then 
> blocks some 
> > watcher, the Notifier must reply to the Subscribe request with the 
> > "Subscription-State" value being "terminated". This 
> subscription will be 
> > also terminated in Notifier. If the presentity unblocks 
> that watcher 
> > later (i.e. change authorization policy for that watcher), 
> how can that 
> > watcher receive the presence information because the original 
> > subscription has been terminated? Is "XCAP Event Package" 
> the best way 
> > of solution? (that is when such change in authorization 
> policy, Notifier 
> > inform that watcher to issue a new Subscribe request.) Are 
> there any 
> > other solutions?
> 
> I believe the subscription model allows three authorization 
> states for a
> watcher: allowed, forbidden, pending.
> 
> It is only when the authorization transitions to forbidden that it is
> necessary to terminate the subscription. If I put you in that 
> category,
> it means I overtly made a decision that I don't want you bothering me.
> In that situation, don't hold your breath while waiting for 
> me to change
> my mind. Maybe if you talk to me and convince me that you are 
> no longer
> such a pest, maybe I will change my mind. Then you can try again, but
> you will have to poll until I actually make the change. From 
> my POV this
> is a feature.
> 
> In principle, I suppose I could move you from allowed to 
> pending when I
> get annoyed with you. In that case you could continue to 
> subscribe, but
> not get any useful information until I change my mind. But 
> that doesn't
> seem like a use case you should count on.
> 
> 	Paul
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Jan 2005 11:11:13 -0500

> This makes me think that the recommended way to use <sphere> should be not to make it affect the subscription state, but just the content, perhaps using polite blocking.

Yes. This falls into the category of "if it hurts, don't do it". In this 
case, you may not want your boss bothering you while you are not 
working, but you probably don't want to piss off your boss.

> If we don't come up with any other fix to this, I think at least this issue should be written in a relevant section of the presence-rules RFC. 

This sounds like a different document - a best practices for presence.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Jan 2005 21:07:27 -0500

inline.

Paul Kyzivat wrote:

>> If <sphere> value is used to influence the authorization decisions, 
>> i.e. different authorization rules apply when sphere=="home" than 
>> sphere=="work", the allowed vs. forbidden state for a particular 
>> subscriber could very well change at least twice a day. If that 
>> subscriber wants to be constantly subscribed to presence whenever it 
>> is allowed, she would have to do some polling. For instance if someone 
>> forbids her boss to subscribe while she is not working, the boss would 
>> not know when to subscribe again after the previous subscription was 
>> terminated.
>>
>> This makes me think that the recommended way to use <sphere> should be 
>> not to make it affect the subscription state, but just the content, 
>> perhaps using polite blocking.
> 
> 

I concur here as well. I think this issue has been raised in the past as 
a general concern around using presence state itself as a condition for 
subscription acceptance/rejection. However, I will note that the same 
issues arise for any decision based on dynamic data, such as time of day.

> 
>> If we don't come up with any other fix to this, I think at least this 
>> issue should be written in a relevant section of the presence-rules RFC. 
> 
> 

I don't think it could hurt to mention this in the authorization rules 
document. I'll do that.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com