Re: Efficacy of rule specification, processing

I do not favor looking into content but personaly favor having some dynamic 
state variables without too much complicating the whole design. One option 
could be, we could have a minimum service requirement/recommendation (simple 
proxylet - on the opes client) to do the state variable extraction and updates 
- so rules that could make use of this can use it, other just can ignore it?

-gs

Gamze Seckin, Ph.D.
Luxxon Corporation
www.luxxon.com

  
----- Original Message ----- 
From: "Hilarie Orman" <HORMAN(_at_)volera(_dot_)com>
To: <ietf-openproxy(_at_)imc(_dot_)org>; 
<christian(_dot_)maciocco(_at_)intel(_dot_)com>
Sent: Thursday, June 14, 2001 4:34 PM
Subject: RE: Efficacy of rule specification, processing


> I hope you don't think I'm advocating looking for HTML tags in
> RTP streams.  That being said, I don't think it's unreasonable to
> expect that application level  data units can be terms of reference
> for the rule engine.  Consider, one might specify "audio stream, 5 minutes
> from start".
>
> I'm thinking in terms of proxy caches, which do have to know all
> these things in order to do their job.  I suppose other kinds of
> devices can say "selection parameters not supported." 
>
> Hilarie
>
> > > > "Maciocco, Christian" <christian(_dot_)maciocco(_at_)intel(_dot_)com> 
> > > > 06/14/01 05:25PM >>>
> Considering that we also need to support non-text based protocols like RTP
> where the message body will most often be a bitstream very expensive to
> parse at the rule engine level I also favor not parsing the message body
> with the rule engine but instead have a service do it.
>
> Christian
>
> > -----Original Message-----
> > From: Hilarie Orman [mailto:HORMAN(_at_)volera(_dot_)com] 
> > Sent: Thursday, June 14, 2001 3:34 PM
> > To: hofmann(_at_)bell-labs(_dot_)com; 
> > lily(_dot_)l(_dot_)yang(_at_)intel(_dot_)com 
> > Cc: ietf-openproxy(_at_)imc(_dot_)org 
> > Subject: Re: Efficacy of rule specification, processing
> >
> >
> >
> > There's experience is that it is not too expensive to parse message
> > bodies.  It is, however, a very limited form of parsing, one that
> > could be more accurately described as lexical analysis.  Only the
> > tags needed for the current set of rules need be lexed.
> >
> > Hilarie
> >
> > > > > Markus Hofmann <hofmann(_at_)bell-labs(_dot_)com> 06/14/01 03:56PM >>>
> > "Yang, Lily L" wrote:
> >  
> > > 1) Currently IRML does not let the rule engine parse the data (like
> > > html/xml) itself. It only parses the html headers. The sole 
> > reasoning behind
> > > it is for performance and simplicity. We feel like the 
> > service itself would
> > > deal with the data, not the rule engine.
> > > Maybe people are not aware of that limitation. So it is 
> > good time to reflect
> > > on it. How do people feel about that?
> > We already had this discussion a while ago, but you're right, it might
> > be a good idea to raise this issue again.
> >
> > I'm still in favor of NOT parsing the message bodies in the rule
> > engine itself - simply too expensive. Having rules on the header
> > leavel seems ok, let the services do the (more detailed) message
> > parsing (which is also nicely supported by, for example, the message
> > preview feature in iCAP).
> >
> > > 2) IF the rule engine does parse the content, then you 
> > don't really need to
> > > define a variable per say for the example of 
> > "has-an-xml-phone-number-tag"
> > > -- you just set up a rule to find the <phone-number> tag in 
> > the XML data
> > > body. Regular expression matching can easily satisfy that. 
> > No need to
> > > additional variable.
> > Not sure whether Hilarie refered to meta-tags in the message body. The
> > point was that "...services should be allowed to introduce components
> > that define and set variables for the rule engine." This can be
> > achieved without having to parse the message bodies - for example by
> > supporting user-defined header fields, as in IRML.
> >
> > Example: There's a service that determines the location (e.g. the
> > country) of the user issuing a request. This service now inserts a
> > user-defined header in the request (e.g. "X-Country: Germany"). The
> > rule enigne might now have other rules based on this user-defined
> > header field, maybe something like "if X-Country matches Germany, do
> > translation to German".
> >
> > -Markus