Subject: RE: [Simple] Re: pres-rules/common-pol: splitting <actions> and<transformations>

From: "Thanos Diacakis" <[email-masked]>
Date: Thu, 24 Feb 2005 22:53:23 -0700

Jonathan,

How is this issue addressed in this latest release of the presence-rules
draft?

Thanks

Thanos

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Wednesday, November 03, 2004 4:56 PM
> To: Thanos Diacakis
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Simple] Re: pres-rules/common-pol: splitting 
> <actions> and<transformations>
> 
> 
> 
> Thanos Diacakis wrote:
> 
> > So an implementation would need to evaluate the conditions 
> in *every* 
> > row, whenever a subscription is received *and* everytime a 
> > notification is about to be sent?
> 
> No. Sorry I was not being clear.
> 
> Assuming you are associating a condition with a "row" in a 
> database, the presence rules specification will call out 
> which rows are applicable to processing the subscription, and 
> which are needed for processing the privacy filtering before 
> a notification is sent. The document doesn't do that now. I 
> will correct that in the next revision.
> 
> 
> > 
> > That doesn't seem like a very efficient way of doing things. 
> > 
> > I think having those into two tables, would make life easier.  If 
> > you're trying to decide whether you're authorizing a sub, 
> you look in 
> > the one table.  Conversely, if you're trying to determine what 
> > transformations to apply to send out a notification, you 
> look at the other table.
> 
> An implementation that works this way is possible.
> 
> -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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 25 Feb 2005 09:45:57 -0500

The following text appears in presence-rules now:

    Care must be taken in using <sphere> as a condition for determining
    the subscription handling.  Since the value of <sphere> changes
    dynamically, a state change can cause a subscription to be suddenly

Rosenberg               Expires August 22, 2005                 [Page 6]

Internet-Draft           Presence Authorization            February 2005

    terminated.  The watcher has no way to know, aside from polling, when
    their subscription would be re-instated as the value of <sphere>
    changes.  For this reason, <sphere> is primarily useful for matching
    on rules that define transformations.

Unfortunately, it appears that I messed up here, and the last word 
should read "actions" and not "transformations". I've repaired that in 
my working copy of -03.

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 25 Feb 2005 09:47:24 -0500

OK. Not enough coffee this morning. The current text is actually 
correct; we want sphere to be used in rules that define transformations, 
not actions.

Sorry for confusing everyone...

-Jonathan R.

Jonathan Rosenberg wrote:

>>> From: Jonathan Rosenberg [mailto:[email-masked]] Sent: Wednesday, 
>>> November 03, 2004 4:56 PM
>>> To: Thanos Diacakis
>>> Subject: Re: [Simple] Re: pres-rules/common-pol: splitting <actions> 
>>> and<transformations>
>>>
>>>
>>>
>>> Thanos Diacakis wrote:
>>>
>>>
>>> Assuming you are associating a condition with a "row" in a database, 
>>> the presence rules specification will call out which rows are 
>>> applicable to processing the subscription, and which are needed for 
>>> processing the privacy filtering before a notification is sent. The 
>>> document doesn't do that now. I will correct that in the next revision.
>>>
>>>
>>>