ietf-openproxy
[Top] [All Lists]

Rules and rule sets

2000-09-15 08:35:42
Hi,

Michael asked me to send the thoughts on rules and rule sets to the
mailing list for further discussion. So, here they are:

(1) As written in the draft, wildcards are essential to
    specify rules.

(2) Possible actions for a rule are not only "call proxylet"
    and "remote call-out", but also an action like "do NOT
    do that", thus overwriting a possible wildcard rule. We
    refer to such rules as "negative rules". Example: An ISP
    has installed a wildcard rule that forwards all client
    requests to a remote call-out server (e.g. for filtering).
    Now, if one specific client keeps complaining about the
    new service, the ISP might not want to shut down the
    new service for all clients, but only for this specific
    one => use a negative rule. Other examples include
    scenarios in which you want to execute a service for all
    URLs except for some specific ones (e.g. do adaptation
    for all URLs except for the URLs from content providers
    that threat with suing you :)

(3) If multiple rules fire on a single message, the ordering
    of rules becomes very important. Example: two rules fire
    on a single message, e.g. a rule for language translation
    and a rule for ad insertion. In which order should the
    rules fire? You might want to do the ad insertion first,
    followed by the translation (or vice versa).

(4) Given that ordering of rules is important - who is
    reponsible for the ordering of rules? According to the
    draft, rules can be installed by different parties.
    Imagine that the above mentioned rule for language
    translation and for ad insertion are from different
    parties. Which party defines the ordering of rules?
    There might be conflicts!!! A single instance for 
    receiving, installing and defining the order of rules
    might be a good idea (e.g. the administrator of the
    proxy/cache). Of course, one might also think about
    mechanisms to specify dependencies of rules..., but...

(5) My feeling is that rules should NOT be too complex.
    Simple rules looking at basic message properties that
    are common to most rules should be sufficient. More
    enhanced "filtering" and "rule matching" should be
    done in the proxylets. For example, we've implemented
    a simple rule set only looking at the source address
    and the destination URL of a request. If there's a match,
    the associated action will be executed, for example
    calling a proxylet. The proxylet itself can now do more
    enhanced filtering, for example, checking the language
    preferences of the user in order to determine whether
    the response has to be translated.

(6) Somehow related to the above item: Message properties
    to be extracted by the message parser do NOT only
    depend on the protocol, but also on the rules that have
    been installed. Potentially, every single line of an
    HTTP header can be of interest for a rule. So, do you
    want to extract all HTTP header fields in the parser?
    According to (5), one could define some HTTP header
    fields that are of interest to most rules, extract them
    in the message parser, match rules (i.e. rules are also
    restricted to these fields) and than forward the message
    to a proxylet, for example. The proxylet can now further
    examine the message and check the header fields that are
    of specific interest. The cost, however, is more parsing
    overhead...
    
We will keep working on our rule set implementation to see whether it
can meet the requirements of the services we have in mind. We would be
very interested in more detailed discussion, your comments, thougts,
feedback, so that we together can come up with a common and open
solution that works for all of us. Please let us know if you're
interested in that issue so that we can work together on that.

-Markus

<Prev in Thread] Current Thread [Next in Thread>
  • Rules and rule sets, Markus Hofmann <=