Unfortunately, I cannot make it to the workshop, but I will offer my
opinions for the record:
----- Original Message -----
From: "Yang, Lily L" <lily(_dot_)l(_dot_)yang(_at_)intel(_dot_)com>
To: <ietf-openproxy(_at_)imc(_dot_)org>; "Yang, Lily L"
<lily(_dot_)l(_dot_)yang(_at_)intel(_dot_)com>
Cc: "Andre Beck (E-mail)" <abeck(_at_)dnrc(_dot_)bell-labs(_dot_)com>;
<hofmann(_at_)bell-labs(_dot_)com>
Sent: Tuesday, June 05, 2001 8:18 PM
Subject: RE: issues on IRML & rule processing for OPES
Here is a list of open issues concerning IRML and rule processing:
1) In what order should the rule engine process rule modules by client,
content provider and access provider?
The current IRML draft proposes the order following the content flow,
i.e.,
the requests from the client to server (at point 1 & 2) should be
processed
in the order of client, access provider to content provider, while the
responses (at point 3 and 4) should be in the order of content provider,
access provider to client. This order may not always make business sense
to
the OPES box owner. One can argue that the exact order should be left
outside of the rule engine and other external factors such as business
arrangement or administration policy could dictate the order in any way.
Following this argument, the ordering infomation can be completely left
outside of the IRML and be part of the configuration or policy info on the
OPES device. Thus the question becomes how and in what form, what
granularity such order infomation should be passed to the OPES device?
I strongly urge OPES to define an interface that allows the fully integrated
set of rules to be specified with no possibility of introducing additional
rules. This interface could be used by a mechanism that integrated
multiple, interdependent sets of rules from different sources to create a
single, well-defined rule set with a known order of rule applications.
If the OPES group really wants to try and specify a mechanism for rule set
merging, then that can be a seperate effort, using a metadata language that
specifies dependences and other complications. However, the basic rule
application mechanism is useful even if this rule set merging mechanism
cannot be standardized. There are business approaches to using OPES that
have no need for rule set merging procedures.
2) How many and what kind of processing points should we define for OPES
devices?
Currently there are 4 clearly-defined processing points in the OPES
framework and these points are very much cache-oriented. Are there any
additional points that people see useful for other intermediary devices or
applications? Should these points be defined statically at the
configuration
time or dynamically on the fly? (Actually I don't see how it can work
dynamically since the rules are written for a specific processing point in
IRML, hence the processing points need to be well-defined to be
interoperable.)
Perhaps there should be a hierarchical system for naming processing points?
A servelet sees only one processing point: the client request/response. A
cachelet sees four: the client request in, the server request out, the
server response in and the client response out. Apparently, some people see
a value in further decomposing some of those points.
3) What kind of environmental variables need to be supported in IRML?
Currently we have time and day. Anything else? How do we support condition
like "when the server load is low..." ?
4) Currently IRML supports only regular expression for condition matching.
Do we see a need for other kind of conditions, like arithmetic support?
This
is related to question 3). Regular expression isn't so handy for
conditions
like "for every 5 minutes", or "if the load is below 25%" etc.
This is moving IRML towards being a scripting language for proxies (equally
applicable to servers, by the way). Defining such a language is an
interesting idea, but perhaps a bit ambitious for OPES at the moment.
5) Currently IRML supports only static and exact action binding in the
<action> element. It is proposed that late and flexible (or not-exact)
action binding might also be desirable. How can IRML facilitate both? In
another word, how can we allow people to say "do exactly this translation
service by this vendor at this location", or "just do whatever virus scan
you have".
This is no longer a rule-based service, it is end-user programming.
6) Do we allow multiple rule modules from the same content provider (for
different level of domains)? One example is to have one general rule
module
for intel.com and another more specific rule module only for
www.intel.com.
Since the ID attribute in the <owner> element really identifies the domain
boundary that the rule module is applicable to, it seems legal to have
both
rule modules in place and it also seems logical to apply both rule modules
for content inside www.intel.com domain. Does it make sense? What about
the
order then? Should it be the general module (intel.com) first followed by
the more specific one (www.intel.com)?
See comment on (1) above.
7) what kind of rules make sense for streaming media instead of web
content?
Feel free to add to it.
Lily
Hope this is useful input.
/micah