Subject: [Sip] Event Filtering

From: [email-masked]
Date: Mon, 1 Jul 2002 16:21:17 -0500

Adam/Robert/Siriram/Jonathan/Henning et. al,
	I don't watch the SIP list as much as I do the simple and sipping lists when a colleague told me of this discussion (extracted most of it from the SIP mail archive) to which I respond. I hope I haven't violated any rules by cc'ing the sipping list. 
	Before diving into the technical, would this thread be more appropriate on the SIPPING list?
	Is it possible to define a useful general-purpose filtering mechanism?  Yes - and No. If you mean one set of software that fits all - no. However, there is a good bit that can which includes: the structure, the verbs (operators) and maybe base type operations. There are some operations that don't rely on types defined in the applciation package. Time based operations are universally applicable (never say never and never say universally).
	There seems to be some interest to investigate the requirements and start the design(I'll use the term arhitecture). Architecture was chosen in the draft since we did not want to go so far as picking the implementation language (XML, SOAP, CPL, XSLT, ...). Personally, I do not care as long as it is reasonable. Admittedly, the XML we submitted in the appendix seemed like a reasonable compromise. 
	Setting a realistic scope is an admirable goal. I get a little concerned when we say minimum functionality or realistic scope given what Jonathan proposed. What is minimum for one package will not be the same for another package - necessarily. I also point out that the architecture includes mechanisms to indicate what is not supported. Nowhere is it required to implement all the functions/operators etc. Each application/package will support what it wants to. There are hooks we defined for extensibility. However, this should be the exception and not the rule.  Drawing the line for the base set of operations and extensions (as done in the draft) will be a bit tricky - but doable given the needs of the industry. For example, maybe all you need is an equality and a not operator. However, this will not satisfy the need of a watcher wanting to know when the list of buddies is greater than x or location has changed more than y. The math operators I concede are icing - but someone ma!
y prove me wrong on this. Point is, what does it hurt if we now go ahead and definea fairly complete set of verbs?
	So far, the requirements I have seen proposed are:
	Rate limiting (time based & state/attribute change based){when} and content filtering {what}.
	I suggest a BAR BOF be held in Japan to discuss this further, e.g. a design team.  Also, last I heard the moran-arch-draft was not on the agenda for Japan. Should it be?
	Regards,
	Tim Moran. Nokia Inc.

	To: Jonathan Rosenberg <[email-masked] <mailto:[email-masked]>> 
*	Subject: Re: [Sip] RE: Event Filtering 
*	From: Henning Schulzrinne <[email-masked] <mailto:[email-masked]>> 
*	Date: Sun, 30 Jun 2002 16:26:50 -0400 
*	CC: Sriram Parameswar <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]> 
*	List-Id: Session Initiation Protocol <sip.ietf.org> 
*	Organization: Columbia University 
*	References: <[email-masked] <msg05808.html>> <[email-masked] <msg05830.html>> 
*	Sender: [email-masked] <mailto:[email-masked]> 
*	User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 

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: Sean Olson <[email-masked]>
Date: Mon, 1 Jul 2002 15:24:40 -0700 (PDT)

I tend to agree with Henning that if we focus
on a solution for XML documents, then XML Query
seems like the best candidate. The million
dollar question is whether this is an appropriate
scope of the problem. A BAR BOF on the topic
seems like a good idea. Please include me on 
any scheduling e-mails for this :)

Cheers
sean

> 	I suggest a BAR BOF be held in Japan to discuss
> this further, e.g. a design team.  Also, last I
> heard the moran-arch-draft was not on the agenda for
> Japan. Should it be?
> 	Regards,
> 	Tim Moran. Nokia Inc.

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com