ietf-openproxy
[Top] [All Lists]

RE: Tracing Draft version-05042003

2003-05-10 11:39:46

On Thu, 8 May 2003, The Purple Streak, Hilarie Orman wrote:

There is an asymmetry in the IAB considerations that I don't
understand.  The content providers must be able to detect and
*respond to* client-centric actions, but endusers are only given the
ability to detect.  I don't know why that exists, and I think it was
a mistake by the IAB.  At any rate, I think we are giving short
shrift to the "respond to" part of the consideration.

The draft is just about tracing ("detection") for now. Pragmatic
"response"  will be covered when bypass feature is documented. We can
also comment on non-algorithmic responses, such as complaining about
the service to the service owner. I think the current draft has some
wording about it when discussing notifications.

Note that bypass will be available for both sides.

I see a couple of problems that need discussion.  The main one is the
caching proxy issue.  If OPES is deployed on a caching proxy, near the
"consumer" end user, then the content provider endpoint will not
receive a request for each use of the data.

If a _caching proxy_ is deployed near the consumer, the provider will
not receive all requests, _unless_ the provider cares to use
appropriate cache control headers and the proxy honors them. Nowhere
OPES comes into play here, whether the same proxy does OPES or not.

The draft seems to ignore this.  I think the server must be provided
with a signalling capability to ask that some notification of the
request and the possibility of OPES services be sent on each use of
cached data.

The server is already provided with such a signalling capability in
HTTP. We should not try to solve the problem of the application
protocols we adapt. As for "OPES services be sent" part (which is
notification), we already argue that we are not going to support that
on a protocol level.

The draft also alludes to the server being able to query the OPES
processor about its services.  One could imagine that a server, on
first hearing about an OPES processor in some path, would
immediately query it to find out if it supported any of list of
problematic services; it would then either include the list of
banned services in its headers or it would specifically request that
the service be disabled for its own content. However, that adds
either a requirement for additional header information that the OPES
processor must be respond to, or it adds a query/response protocol.
Both are substantial requirements.

We will support a bypass feature. A "what services do you support?"
protocol can be written, but we do not have to write it. Moreover, I
expect its deployment levels in the cross-trust-domain scenario you
describe to be close to zero: Client-side proxies have no incentive to
respond to server-side requests and have incentives not to respond
(and vice versa).  In the same-trust-domain scenario, the usefulness
of such protocol is questionable.

This is the same argument we use when talking about notification
support. We assert that the best we can do is tracing+bypass because
anything beyond that violates administrative boundaries/incentives/etc
and has historical precedents of being rejected by the real world
(e.g. the Hit Metering protocol).

Note that traces are not likely to tell request recipients what
services are going to be applied to their response. That information
is not known (in general) at the time of the request and will be
available to the response recipient only. That is why we argue that
the only practical way for content providers to know what has happened
is to ask the end user for "response headers" (or play the end-user
role, if possible).

Alex.

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