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

From: "Jeffrey" <[email-masked]>
Date: Fri, 4 Feb 2005 16:45:45 +0800

Hi Paul,

Thanks very much for your response.
>From my point of view, according to the statement of the 16th page in RFC
3265,

       rejected: The subscription has been terminated due to change in
             authorization policy.  Clients SHOULD NOT attempt to
re-subscribe.
             The "retry-after" parameter has no semantics for "rejected".

So I assume that when a presentity blocks some watcher who was granted
before, the Notifier regards this event as authorization policy change and
replies to the Subscribe request with the "Subscription-State" value being
"terminated".  Do you think it is better to notify subscriber with the
"Subscription-State" value being "pending" rather than "terminated"? But if
I consider the statements in the section 3.2.2 in RFC 3265,

       The "pending" value
              indicates that the subscription has been received, but that
policy
              information is insufficient to accept or deny the subscription
at
              this time.

It seems the value of "pending" doesn't be suitable for such situation
because "block" should imply to deny the subscription. Am I wrong? 

BR,
Jeffrey

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, February 01, 2005 12:44 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]'; 'Markus.
[email-masked]'
Subject: Re: [Simple] About change in authorization policy

[email-masked] wrote:
> Hi all,
> 
> I am afraid that I might miss something or not capture your focus. I 
> just wonder if revising the authorization rule document is enough for 
> solving this problem. I would like to emphasize a point that when a 
> subscription state at Notifier become 'terminated' due to authorization
change (e.g.
> presentity block some watcher), this subscription will never be 
> re-active even the presentity changes his mind to do the unblock 
> action later. This will result in a problem that watcher can't be 
> notified of presence information except the watcher re-subscribe 
> again. I wonder if  it is possible to add a new subscription state of 
> "forbidden" for this purpose, so that a subscription state can be from 
> "active" to "forbidden" and have a chance to go back to "active" in case.
> Thanks.

If you want to keep the subscription active, you already have two options:

- just leave it active, but change the filter criteria so you don't tell
   the watcher much

- change the state to pending, and then don't tell the watcher much.

These seem sufficient to handle the case - why do you need yet another
state?

	Paul

> BRs,
> Jeffrey
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jonathan Rosenberg
> Sent: Friday, January 21, 2005 10:07 AM
> To: Paul Kyzivat
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] About change in authorization policy
> 
> inline.
> 
> Paul Kyzivat wrote:
> 
> 
>>
>>[email-masked] wrote:
>>
>>
>>>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.
>>
>>
>>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.
> 
> 
> 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.
>>
>>
>>This sounds like a different document - a best practices for presence.
> 
> 
> 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
> 
> _______________________________________________
> 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: Fri, 04 Feb 2005 17:37:59 -0500

(retrying - had trouble first time)

 > because "block" should imply to deny the subscription. Am I wrong?

This is all a bit subjective - there are different ways to approach it
and/or rationalize a particular way of responding.

If the access policy is changed so that someone with an active
subscription is no longer permitted to have one, then I think "rejected"
is the right status to send. Terminated is wrong, because that means the
subscription is over but another is probably still ok.

In that case, I think the SHOULD NOT re-subscribe applies most directly
to the subscribing UAC, so it shouldn't *automatically* try to
resubscribe. However I think the user associated with that UAC is free
to instruct the UAC to try again. This of course is what you want to
avoid - the annoying human interactions.

However, the whole pending status mechanism depends on authorization
being at least tri-state: authorized, forbidden, unspecified. So,
instead of kicking the subscriber off by changing access to forbidden,
you could just change it to unspecified. Then, that change could cause a
terminated response to the old subscription, and a retry could go into
pending. Or you could short circuit that and just transition the
existing subscription to pending state.

	Paul