Subject: [Sip] Event Filtering

From: Adam Roach <[email-masked]>
Date: Tue, 25 Jun 2002 11:51:19 -0400

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
>
> We're seeing a similar kind of pressure in other event packages. Often
> its called event-filtering. I'm still not sure whether a 
> filter approach
> or a separate event is the better approach. In any case, this problem
> is not an event refer specific one, so we shouldn't solve it in this
> draft.

We left this up to event packages in sip-events on purpose. (We say
the SUBSCRIBE bodies can define filters and throttles, but don't
define specifics). I don't beleive that it is even possible to define
a useful general-purpose filtering mechanism, precisely because the
variety of things you'll want to filter based on varies widely, and
will need to be tailored to the exact type of state being conveyed.

If I'm wrong, please make a proposal for such a mechanism.

/a

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Sriram Parameswar" <[email-masked]>
Date: Fri, 28 Jun 2002 10:11:15 -0500

Jonathan,

Looking at it from a requirements perspective, we could trim it down to a
small set. We could start with something as small as:

	* Rate of Notification - here all the subscriber says is - do not
exceed 'x' notifications per minute.
	* Content of Notification - they subscriber indicates support for
full or partial/incremental notification bodies.
	  This would help UA's that can handle only full event notification
documents and do not have the computation power
	  to deal with incremental notifications. Support for content
indirection could be optional here - this would allow
	  a UA to indicate that it is capable of retrieving event
notification bodies using an alternate mechanism like
	  HTTP.

Any other filtering requirements may be treated as extensions by individual
event packages. I strongly support the use of XML for the filter language.

Thanks,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: [email-masked]

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Thursday, June 27, 2002 2:59 AM
To: Parameswar, Sriram [NGC:B615:EXCH]
Cc: 'Adam Roach'; Robert Sparks; [email-masked]
Subject: Re: [Sip] RE: Event Filtering

I acutally like the idea of a more generic filter/trigger mechanism that 
would apply cross-packages. The tradeoff is one of generality vs. 
complexity. The single mechanism will be more general, but probably more 
complex than an event-specific one. How much more complex? Impossible to 
say, of course. I generally favor generality, so if its not to omuch 
more complex, I think its a good thing. However, unless you plan on 
enumerating the set of filters and triggers allowed in a package, I 
suspect that the general one won't be that much more complex. Saying 
"only send me notifies once an hour on alternate thursdays, if the value 
of the foo parameter is bar" is going to be complex in any case.

I think the Moran draft is a good start, but not quite there yet. Part 
of the problem is scope. What exactly do we wish to support, in terms of 
filter/trigger policies? You don't want to boil the ocean with the first 
version. I think that, if we go for a general solution, we should do 
JUST enough to meet the *real* problems people are trying to solve, and 
we can make it extensible to handle more down the road.

I would postulate that, realistically, the scope of triggers is going to 
be limited to:

   * waiting for a certain event to occur within a certain state,
   * waiting for a certain variable to take a certain value

Things like the mathematical and temporal conditions are interesting, 
but I doubt would really be used in practice. Similarly, the filtering 
conditions are probably limited to asking for notifications to contain 
only certain variables.

With a well scoped set of requirements, as I have proposed above, I 
think you can get a pretty straightforward language that would apply 
cross-packages.

I'll also note that, if we assume that all notifications contain XML as 
bodies (I know its not true, bear with me), then the filter could 
possibly be an XSLT document. This might be overkill. For things that 
are not XML, you'd need to specify an XML mapping for it to work (yuck). 
  Just a thought.

So, I would propose that, in order to make progress on this issue, we 
agree upon a realistic scope for these things, in terms of requirements 
on filters and triggers, and then we can see how complex the 
general-purpose filtering language is.

-Jonathan R.

Sriram Parameswar wrote:
> Adam, 
> 
> I agree with you on the fact that each event package should define its
> own filters. I would tend to say that using different events for
> filtering would not work, simply because we can filter on various
> different criteria. However there was a draft that attempted a generic
> filtering architecture (draft-moran-sipping-filter-arch-00.txt), which
> did not get very much traction.
> 
> Maybe the working group could take a look at that draft one more time? 
> 
> Thx, 
> 
> Sriram 
> 
> __________________________________________ 
> Sriram Parameswar              Phone: 972-685-8540 
> Interactive Multimedia Server (IMS) Fax: 972-684-3986 
> Nortel Networks, Richardson USA  Email: [email-masked] 
> 
> 
> From: Adam Roach [ mailto:[email-masked]
> <mailto:[email-masked]> ] 
> Sent: Tuesday, June 25, 2002 10:51 AM 
> To: Robert Sparks; Parameswar, Sriram [NGC:B615:EXCH] 
> Cc: [email-masked] 
> Subject: Event Filtering 
> 
> 
> 
>>From: Robert Sparks [ mailto:[email-masked]
> 
> <mailto:[email-masked]> ] 
> 

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