ietf-openproxy
[Top] [All Lists]

Re: some suggestions for IRML

2001-02-13 09:11:42
Lily,

1) I would like to see more straightforward support of "for-all" rules --
i.e., rules that trigger an action without any explicit property matching.

That's a good point. I agree that while it's possible to achieve this
with the current spec as well, a cleaner way to do it is preferable.
We need to think a little bit about how to do tis best. Not sure
whether we could simple make the "property" element optional.
Otherwise, we could introduce a special property tag indication the
"for-all" rule, something like "ANY" or so...

But it would require bring out the "action" element outside of the nested
"property" element. So something like this:

We need the nesting to allow for logical and/or relations of the
properties. For example, if we have three properties A, B, C and we
want to execute action "AandB" if properties A and B hold, and action
"AandC" if properties A and C hold, we could express this like

 <rule>
     <property A>
        <property B>
           <action> AandB </action>
        </property>
        <property C>
           <action> AandC </action>
        </property>
     </property>
  </rule>

How would you express this example having the "action" element outside
the nested "property" element? It's possible, but not as simple.

2) Define both <ICAP> and <PROXYLET> element inside of <action> element to
include basic info for code binding and service execution, like service
name, namespace and version, etc.

Rather than explicitely having such elements in IRML, it seems that
this information should be part of a naming scheme for the actions,
for example having actions like icap://icap.com/service_example or
proxylet://local/proxylet1.
 
3) Again, I do NOT like to see support of "request-body" and "response-body"
in the rule engine so that the rule engine does not even need to see the
body.

We also believe that analyzing the body for rule matching is not that
a good idea, but we thought some folks would like to have the option
of doing so - that's why we defined IRML to allow for it. If general
consensus of OPES is that we do NOT need the feature, we should take
it out - it would simplify implementation of rule engines. Any
comments from others in the group? Would it be ok if we take these
out?

4) Is there a strong argument for feeding "modified" properties versus
original properties (i.e., headers) back to the rule engine in the rule
processing loop?

Example: There's a service doing transformation from HTML to WML. The
rule for this service is something like "if content-type is HTML and
user-agent is Wireless_Device do...". The service changes the
content-type. There's another service doing ad insertion depending on
the content-type of the message, e.g. insert images in HTML and short
text into WML. You probably want the ad insertion service to operate
based on the modified content-type header field, i.e. if the content
got transformed by the first service, the rule for "insert text ad"
should fire rather than the rule for "insert image ad". Valid example?

-Markus

<Prev in Thread] Current Thread [Next in Thread>