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)