Subject: [Simple] (no subject)

From: [email-masked]
Date: Wed, 19 Feb 2003 10:55:34 -0600

Jonathan,
I wanted to respond to this email of yours from the Jan 14th SIMPLE WG email archive. Not doubt this has reached the moratorium on responding to questions, but I think it is still relevant.
In the context below, you mention that there is little in common btw packages regarding filtering. I tend to disagree from the architecture perspective. As even you mention, there are common constructs such as  'or' and 'and' and such for doing logical tests. This is in fact common across packages and content such as XML. What is unique are the objects (Package elements). They are not that unique however in that for the case of XML content they are strings and hierarchical (structured). Here is where I think existing tools such as XPATH can help provide a common filtering architecture - but it is not the total solution alone. 
As for the objects, these are defined by the package. I agree however, that there may be some objects not defined in the package. Should they be? Some are generic such as time and location (standard definitions exist for describing location). Others are known only to the server such as statistical information. In the case of winfo this may be # of active watchers, for example. How to deal with these must be addressed commonly - or uniquely.
Regarding separation of triggering and filtering, perhaps they can be combined and do not require separate constructs. Point is both are required. Focusing on the triggering, you provide examples where  it would appear a notification is sent wherein multiple watchers having reached a certain state or have experienced some event are sent. 
This requires what I would call a batching mechanism whether it be time based or spatial. You describe that implementations are doing proprietary solutions but we need a standard mechanism (IMHO) wherein the client may specify and know precisely what the bathcing mechanism is. Otherwise, whenever a state change occurs (say for watcher x) only watcher x info will be sent. If the package rule is changed to say all watchers with feature y, then the entire list is sent whenever any one of them changes and this is not good.  Some examples - only send periodically, only send when a threshold (e.g. quorum #, majority, 2 or more, etc) is reached. For another application/package, it might be to only send when location has significantly changed.
In short, I personally don't care so much as to how we do triggering as long as we enable the capability. Applications should be able to take the architetcure and apply the relevant pieces (i.e. instantiate it). This follows the same ideas ( I think) that Adam had with Subscribe/Notify, Packages and sub-packages.
Regards,
Tim Moran
To: [email-masked] <mailto:[email-masked]> Subject: Re: [Simple] Content filtering for winfo From: Jonathan Rosenberg <[email-masked] <mailto:[email-masked]>> Date: Tue, 14 Jan 2003 15:03:21 -0500 Cc: [email-masked] <mailto:[email-masked]> 
[email-masked] wrote:
> All,
>
> During IETF55's SIPPING session it was discussed how to proceed with
> the content filtering work. It was concluded that SIMPLE WG will
> produce event specific content filtering for the presence package
> (requirements & solution). I am wondering whether this work also
> covers content filtering for the winfo template-package. If yes, it
> is also a question whether this issue should be addressed separately
> from the presence package (in different documents) or together with
> it.

I believe its a separate problem. The conclusion was, as I recall, that there is very little that is common across packages in terms of filters. Thus, we will develop, in sipping, a specific solution just for rate limiting, and then each particular package would get its own filter type.

So, I believe there is a filter needed for winfo. Most implementations I am aware of, in fact, are already filtering on winfo - they just want the list of pending subscribers.

So, here are the set of things I would like to be able to specify in the filter language:

* include only watchers in a specific state [i.e., give me only pending watchers]
* include only watchers that transitioned from a specific state to another state [i.e., only watchers that just transitioned from active to terminated]
* include only watchers from a particular domain [who are the watchers from my enterprise?]
* include only watchers who have been in a specified state for less than some duration [useful to only ask for the watcher whose state JUST went to pending because they just subscribed]
* include only the Nth through Mth watcher, assuming some ordering can be applied to them at the server [useful for fetching a long list of your watchers - you can ask for ten at a time]

Doing this in XML is easy, I think. You could specify a set of filters, eahc of which is an XML tag. There are filters for states, filters for domains, filters for duration, and so on. Filters nest, creating an AND rule. Sequences of filters create OR rules. So, if you want the set of watchers from either dynamicsoft.com or from microsoft.com:

<filter-document>
<domain-filter domain="dynamicsoft.com"/>
<domain-filter domain="microsoft.com"/>
</filter-document>

and to specify watchers that just transitioned to pending, who are from dynamicsoft.com:

<filter-document>
<domain-filter domain="dynamicsoft.com">
<state-filter instate="pending">
<time-filter duration="0"/>
</state-filter>
</domain-filter>
</filter-document>

The processing rule at the server is easy. Start with all watchers at the root of the XML tree. Each node (element) specifies a reduction operation to be applied. Apply it, and take the remaining elements as input to the next tags. The union of the watchers that remain at the leaves of the XML tree represent the set which is to be sent in the notify.

Note that, in the terminology proposed by Moran, the filter above does not separate content and trigger criteria. The model is that at each event transition, there is a set of watchers that would be present in the notify. THe filter is applied. If any watchers remain, a notification is sent. If none remain, none is sent. Certainly there are things you cannot do as a result (send me all the watchers whenever one watcher transitions from active to terminated). Not sure we are missing any important cases.

Comments?

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
[email-masked] FAX: (973) 952-5050
<http://www.jdrosen.net> PHONE: (973) 952-5000
<http://www.dynamicsoft.com>

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