I have two questions regarding the recent new IRML draft --
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.
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.
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?
From: Andre Beck [mailto:abeck(_at_)bell-labs(_dot_)com]
Sent: Wednesday, July 25, 2001 6:42 AM
We submitted an update to the Intermediary Rule Markup Language (IRML)
draft last week. Until published, the new draft is available at:
- updated references to include the OPES models and policy
- removed terminology section and referenced the taxonomy in the OPES
models draft instead
- revised use of terminology to be conform with OPES models draft
- removed access provider from list of rule authors (as
suggested by new
- 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
- 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
- new timestamp format in <system-date> variable (as suggested by Ian)
- removed DEFAULT keyword from IRML DTD (as suggested by Ting)