Hilarie,
good points.
on the proxy issue, I will add proper text and resubmit.
on the second issue, i need suggestions from the group
abbie
-----Original Message-----
From: The Purple Streak, Hilarie Orman
[mailto:ho(_at_)alum(_dot_)mit(_dot_)edu]
Sent: Thursday, May 08, 2003 4:44 PM
To: Barbir, Abbie [CAR:1A00:EXCH]
Cc: ietf-openproxy(_at_)imc(_dot_)org;
rousskov(_at_)measurement-factory(_dot_)com
Subject: RE: Tracing Draft version-05042003
Excellent start.
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.
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. 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 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.
Hilarie