Markus --
I still think (b) is important for that is how OPES engine reinforce the
"authorization" principle that OPES would not modify the content unless the
content is either owned or reqested by the rule owner.
Without it, content provider A can modify the content owned by B. We
certainly don't want that to happen. So this "pre-selection" is good for
efficiency and even more necessary for security reason.
But on the other hand, a simple and strict policy like we've got in IRML
would run into problems with a large group of subscribers like in the
example. So we need to find a way to solve that.
Lily
-----Original Message-----
From: Markus Hofmann [mailto:hofmann(_at_)bell-labs(_dot_)com]
Sent: Thursday, August 30, 2001 1:39 PM
To: Yang, Lily L
Cc: 'ietf-openproxy(_at_)imc(_dot_)org'
Subject: Re: two questions regarding IRML
Lily,
I guess the question is what kind of "id" you would assign
to the members of
that subscriber group. that was the reason that I asked
both the "owner"
question and the "id" question in one email. They are
related to each other.
The "id" and the "name" would be the ones of the ISP, and the "class"
attribute would be "client", as the ISP has authored/installed the
rule on behalf of its clients. Obviously, the "id" value can now no
longer be used for selection of the appropriate rule modules -
something I didn't like too much from beginning on.
The "id" element has been serving two distinct purposes: (a) Uniquely
identify the rule author/installer, and (b) allow (pre-) selection of
appropriate rule modules for incoming messages (e.g. only consider
rule modules authored by "cnn.com" if the requested URL is
"*.cnn.com"). These are distinct functions and should be kept separate
and should not be overloaded into a single IRML element.
One possibility would be to use the "id" element only for purpose (a)
and don't do any rule set pre-selection at all. Simply look at all
installed rule sets and see which rules match. If, for efficiency, we
need a mechanism for pre-selecting rule modules, this should be kept
separate and more flexible.
-Markus