ietf-openproxy
[Top] [All Lists]

Re: OPES Ownership

2001-02-02 17:21:40

I'm trying to get a feel for the intent and bounds of OPES; I've
heard some discussion of allowing clients to interpose a processing
module into an intermediary, and there seem to be some people
interested in developing a trust model.

In your last mail on this thread, you stated:
In summary, the rule modules and proxylets would only flow through
a path with established trust relationship in place first.

I haven't been making that assumption. Once the OPES framework is
established, there is no mechanism to enforce that trust model. It's
nice to say that OPES deliverables will only be used in a "nice" way,
but I don't know that it's meaningful. While people will always do
bad things like intercept and modify messages in the network, it's
quite another thing to standardize a framework which encourages this
without addressing these concerns.



On Fri, Feb 02, 2001 at 01:25:15PM -0800, Yang, Lily L wrote:
Mark --
At the client's side, I don't envision any end user would actually have to
deal with the OPES framework -- his/her desire to use services such as virus
scanning, filtering, translation, adaptation, etc would be honored by his
access provider on his behalf. So the access provider would generate and/or
load the relevant rule modules and proxylets on the clients' behalf onto the
OPES boxes. With that in mind, I guess I don't quite follow what you meant
here by "integration into the client"? Could you elaborate?
Also the knowledge about how to act on behalf of the client does not reside
on the content provider in this case -- it should reside with the access
provider, already in the OPES box or its Admin box.

I probably completely misunderstood your point here. Maybe you can provide
some more clarificaiton?

Lily

-----Original Message-----
From: Mark Nottingham [mailto:mnot(_at_)akamai(_dot_)com]
Sent: Thursday, February 01, 2001 1:05 PM
To: Erickson, Rob
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: OPES Ownership

... (omitted)

There is an equivalent model between the client and their access
provider, through their terms of service/employment (as the case may
be). However, while CDNs are developing mechanisms to allow content
providers to control how their objects are served, developing such
controls for client->access providers is much more difficult.

This is not only because it requires integration into the client --
which alone makes it a difficult issue. It also requires insight into
the semantics of messages -- both requests and responses -- to make
reasonable decisions about how to act. Unfortunately, this knowledge
resides at the content provider. URIs are explicitly opaque; current
systems which derive object characteristics from them are extremely
limited, and arguably limit the functionality and extensibility of
the Web.

... (omitted)

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)

<Prev in Thread] Current Thread [Next in Thread>