Subject: Re: [Sip] RE: Event Filtering

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 30 Jun 2002 16:26:50 -0400

Jonathan Rosenberg wrote:
> 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.

CPL with the calsch extensions makes expressing alternate Thursdays very 
easy :-)

> 
> 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.

We've also looked at extending CPL for presence (draft-wu-cpl-presence, 
I thin). The question is whether the same model makes sense for events.

I don't think XSLT is the right choice. If anything, you want something 
like the XML Query language where you can formulate conditions on XML 
bodies.

Henning

_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Sun, 30 Jun 2002 16:26:50 -0400

Henning