Subject: [Simple] Content filtering for winfo

From: [email-masked]
Date: Tue, 14 Jan 2003 20:22:09 +0200

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.

As a background, winfo-package-04 mentions the issue of filtering and defines that SUBSCRIBE may contain a body for filtering the watcherinfo subscription. Similarly to presence, the actual filter definition for winfo is left out of the scope. In the I-D there is one example mentioned, a filter indicating that notifications should contain full state every time instead of the default policy to send partial updates. Additionally to this, I think filters could be defined e.g. to select the active watchers, new or unauthorized watchers, and also watcher history information could be collected with the help of filters.

Comments are welcome!

Thanks,
Krisztian

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Jan 2003 15:03:21 -0500

inline.

[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