ietf-openproxy
[Top] [All Lists]

RE: questions about PSRL

2001-02-12 12:48:45

Hi Lily,

     It is necessary to make sure that , rule module from one owner( CP/ End 
User)  should deal  only with its own content .But I don't see any reason to 
define these constraints . What I think is,   if rule engine interacts only 
with 
 that part of rule base which is related to the respective  (message / owner) 
combination , then constraints come into effect automatically .
     
     
     Example : Lets assume , an owner ( www.abc.com ) has given a rule file 
which mentions about another owner ( www.cde.com) .Now , whenever  message( 
request / response) related to www.abc.com comes  , rule parser interacts with 
rule base , but there will be no rule matching and thus constraint comes into 
effect on its own.
       
     Comments Welcome.
     
     
     Rajnish..
     
     

Markus --

Thanks for the quick reply. I am glad we agree on most of these.
Yes, I also think separating the version from name is a better way so we can
associate multiple versions of the same module or proxylet properly.

Now, I have another question -- it may very well land itself outside of
PSRL, but it is certainly related.

The current PSRL does not impose any constraint as to what kind of rules are
allowed or not allowed at all. We need to be sensitive to the fact that
people are paranoid about this all-too-powerful intermediary sitting between
the traffic and can do a lot of (both wonderful and horrible) things to the
traffic. I think we need to impose constraint to both the rule modules and
the proxylet services. The constraint would be different for the three types
of rule owners. For content provider, like www.disney.com, their rule
modules should be only concerned about their content, and should not do
anything to other people's content, like filtering out AOL Time Warner's
content, for example. Similarly, the end user's rules should only be
concerned about the traffic for themselves, for example, Christian should
not be allowed to filter out content for Lily. (Well, there is some twists
here though that we need to consider - like parents want to do things for
their minors, etc.) The rule modules from access provider (i.e. the OPES box
owner) may be allowed more freedom since they are dealing with many end
users and many content providers. They might do different things for
different end users and content providers, depending on the economic model
or financial arrangement, etc. These are just some initial thoughts. 

Another question is where these constraint should be defined? In the PSRL
language (then it is part of the standard), or stays within the Rule Parser
in proprietary form, or as part of the policy that OPES owner can do at
configuration time? It isn't clear to me yet.

Comments welcome.

Lily Yang
Intel Corp.

-----Original Message-----
From: Markus Hofmann [mailto:hofmann(_at_)bell-labs(_dot_)com]
Sent: Friday, January 19, 2001 10:37 AM
To: Yang, Lily L
Cc: Condry, Michael W; Christian Maciocco (E-mail); Manasi Bhutani
(E-mail); Rob Erickson (E-mail); Markus Hofmann; Andre Beck
Subject: Re: questions about PSRL


Lily,

1) Could you give me an example that "request-body" and "response-body"
are
necessary to involve in the rule matching?
I would think that headers are flexible and sufficient enough to trigger
the
actions. Body, esp. the response bodies could be a lot of data to pass
through to the rule matching engine. Do we really need that? Whatever
action
that involves body should probably be pushed out to the proxylet or
callout
service anyway -- 

Absolutely agreed. I'm also very much in favor of parsing only the
protocol headers (e.g. the HTTP header) and to NOT look into the body
when doing rule matching. Parsing a body is likely to be too processor
and time consuming; it should be done at the proxylet or remote
call-out server instead. Basically, we want to have a relative simple
and fast (pre-) matching at the rule engine; more complex and time
comsuming filtering/matching should be done at the call-out
server/proxylet.

We just included the property names "request-body" and "response-body"
so that PSRL does not exclude this option. Somebody might still look
into the body when doing rule matching, and he should also be able to
use PSRL. And, there might be use cases where one might look into the
body of a POST request, for example.
 
2) naming and version of the rule module and proxylet:
Have you thought about how to name and version the rule modules and
proxylets? 

The naming scheme itself is NOT part of PSRL, it's outside PSRL. PSRL
just has to provide support to integrate an appropriate naming scheme.
The "name" and "id" elements in PSRL provides support for that.
However, based on your comments, it might be a good idea to add an
aditional element "version" to PSRL.

Although the exact naming scheme is out of scope for PSRL, we had a
naming scheme in mind similar to the one described in RFC 2774. Every
provider of rules needs to have a globally unique host/domain name,
such as www.lucent.com (it's anyway very likely that a company
providing rules will have its own web site, private clients might have
a globally unique IP address assigned or might get a subdomain name
assigne from their ISP, or it could be their emai ladress, or...).
This name is used to build the gloablly uniques name for the ruleset,
for example:

  http://www.lucent.com/rulesets/adapation/html2wmt.rl

or
 
  mailto:hofmann(_at_)home(_dot_)com/rules/dummy.rl

This coud also specify the URL on where to download the ruleset, which
might be very interesting when we start talking about rule set
distribution etc. A mail adress could be used to get request more
information etc.

Think that's very close to what you have in mind.

We imagine that the proxy service environment need to be able to
support versioning of these two (like replace the old version with the new
one, or even support multiple versions of the same proxylet, etc.),
think it probably makes sense to use something similar to URI with
version,
like:
proxylet://www.intel.com/translation/version2.0
          --------------------- --------------- --------------
         (namespace)    (name)      (version)

I like the idea of being able to have multiple versions, but I don't
like the idea of having it encoded in the name. I'd rather suggest to
have it separate and to add an additional "version" field to PSRL.

<rulemodule> 
     <owner class="client"> 
       <name>Lucent Technologies</name> 
       <id>http://www.lucent.com/rules/html2wml.rl</ID> 
       <version>1.0</version>
     </owner> 
     blabla
</rulemodule>

Hm, we'll probably add an appendix to the PSRL draft explaining thses
things a little bit, But, again, I think PSRL should NOT specify the
naming scheme, PSRL should be independent from the naming. Maybe, we
even need a separate draft for the naming.

-Markus



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