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.
Unless the ISP can assign some sort of unique group id to each of the
members and use that to match to the owner class id, we got some logical
problem -- that is, if each user has its own user-id, then you would need a
proxylet to map the user-id to group-id and you need a rule to act on all
users' request to fire up that proxylet -- but remember, since we don't have
the "access-provider" class, how do you write such a rule that can be
legally fired up for all users?
And I would argue that it might not be a good idea to ask ISP to assign
"group-id" instead of "user-id" to their subscribers. For one, it is not
flexible. Any user might want to sign up for any number of different
services, so one user A may belong to several groups for that reason. How do
you deal with that?
From: Markus Hofmann [mailto:hofmann(_at_)bell-labs(_dot_)com]
Sent: Tuesday, August 28, 2001 6:05 AM
To: Andre Beck
Cc: Yang, Lily L; ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: two questions regarding IRML
Andre Beck wrote:
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
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
about introducing a new rule module class "delegate" for
rules that are
authored by an authorized entity on behalf of the actual rule owner.
Not sure whether we need or want to have a new rule module class. The
"owner" section of a IRML rule serves two purposes - the "name" and
"id" elements identify the rule author, and the "class" attribute
indicates whether the rule has been specified on behalf of a content
provider or a client (and, therefore, whether the associated service
is executed on behalf of a content provider or client). A rule is
never specified for or on behalf of an access provider.
In Lily's example, the 100 subscribers to the filtering service
delegate authority for service execution and rule authoring to the
service provider (e.g. by signing up to the service), and the service
provider authors the corresponding rule(s) on behalf of the clients.
Therefore, the rule module class still is "client" (as the service is
executed on behalf of and authorized by clients), but the rule author
is the service provider (on behalf of its subscribers). This allows
the service provider to specify a single rule for multiple users.