This sounds like playing with fire.
Why does the ISP need rules. They can insert rules
for the client customer (at the customer's request)
I do not think an IMRL mechanism is needed for that, its
administrative/policy.
ISP only inserts rules as a delegate!
At 04:08 PM 8/27/2001, Andre Beck wrote:
Lily,
We are currently working on a new IRML version to address the two issues
you mentioned. I agree with you and ohers that having one rule module
per user is not desirable, especially in light of the fact that most
users probably won't write their own rules anyway. Instead they will
authorize their ISP to set up rules on their behalf. So we were thinking
about introducing a new rule module class "delegate" for rules that are
authored by an authorized entity on behalf of the actual rule owner.
These rule modules would contain all rules set up by a specific delegate
and thus they could contain rules for many different users. Does this
make sense?
-Andre
"Yang, Lily L" wrote:
>
> Andre --
>
> I have two questions regarding the recent new IRML draft --
> 1)
> Several recent postings suggest that we want to avoid the situation of
> having too many individual user rules. Instead, rules for aggregated group
> of user are much more preferable. I totally agree.
> In light of this and the fact that we do not have access provider class as
> rule module owner now, how exactly do you think we can support rules for a
> group of users?
> For example, if 100 users out of the 10000 subscribers sign up for
filtering
> service. We used to say that we can apply a "for all" rule (from access
> provider) first to execute a proxylet "membership-checking" to find out
> whether or not a user is indeed one of the filtering group members. Now
that
> we can not have such a rule, how are we going to do such things? It isn't
> very clear to me yet.
>
> 2)
> I also noticed a change that "user-id" now is missing from the list of the
> properties that are required. Instead, we have "client-ip" now. But the
spec
> also seems to suggest that it is ok to map the "id" against some other
> unique identifier -- however, there is no mechanism in IRML to allow such
> mapping happen explicitly, how does the rule engine know what property name
> should be used? Maybe we should add a "mapping" attribute in the "id"
> element, which can be default to "client-ip" if not specified.
> Example:
> <owner class="client">
> <name>abeck</name>
> <id mapping="client-login-name">andrebeck</id>
> </owner>
>
> With this rule module, the rule engine would look up the
"client-login-name"
> value in the properties and see if it matches. Does it make sense?
>
> Lily
>
> > -----Original Message-----
> > From: Andre Beck [mailto:abeck(_at_)bell-labs(_dot_)com]
> > Sent: Wednesday, July 25, 2001 6:42 AM
> > To: ietf-openproxy(_at_)imc(_dot_)org
> > Subject: draft-beck-opes-irml-01.txt
> >
> >
> >
> > We submitted an update to the Intermediary Rule Markup Language (IRML)
> > draft last week. Until published, the new draft is available at:
> >
> > http://markus.planethofmann.com/papers/draft-beck-opes-irml-01.txt
> >
> > Change Log
> >
> > - updated references to include the OPES models and policy
> > requirements
> > draft
> > - removed terminology section and referenced the taxonomy in the OPES
> > models draft instead
> > - revised use of terminology to be conform with OPES models draft
> > terminology
> > - removed access provider from list of rule authors (as
> > suggested by new
> > OPES charter)
> > - late binding in <action> field through OPES URI (as suggested by Lee
> > Rafalow and others)
> > - added "request-host" variable to accomodate HTTP/1.0
> > messages that do
> > not have the "Host" header (as suggested by Francis Zane)
> > - added "type" attribute to property element to accomodate three
> > different types of properties: message, system, and service
> > properties
> > - added "client-ip" system variable to support services that depend on
> > the client IP, e.g. URL rewriting service
> > - added support for service environment variables which allow OPES
> > services to maintain state information, communicate with other
> > services, and dynamically control the invocation of services (if
> > service variables are referenced in IRML rules) (as suggested by Lee
> > and others)
> > - new timestamp format in <system-date> variable (as suggested by Ian)
> > - removed DEFAULT keyword from IRML DTD (as suggested by Ting)
> >
> >
> >
Michael W. Condry
Director, Network Edge Technology