ietf-openproxy
[Top] [All Lists]

Re: Efficacy of rule specification, processing

2001-06-14 15:33:58

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