My comments are inline headed by [HKO].
Oskar Batuner wrote:
-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of John
Morris
Sent: Wednesday, June 05, 2002 3:26 PM
To: The Purple Streak (Hilarie Orman)
Cc: OPES Group
Subject: Re: Content Provider Notification
Some comments inline.....
At 06:46 PM 6/4/02 -0600, The Purple Streak (Hilarie Orman) wrote:
[..............}
Let me float a simpler and still plausible approach:
1. By default, no client-to-server notice is necessary.
2. For the limited number of servers that care, they can send
out an "are
you planning to OPES" inquiry before filling the client's request.
[HKO] Reading the IAB considerations carefully, and noting that the
content provider is only interested in corrupted or malicious OPES
services, one finds that this would not be a limited number of servers,
it would probably be almost all servers. Also, as an aside, note that
this inquiry itself could be implemented as an OPES service by a
content distributor.
[HKO] Further, the OPES intermediary will not, in general, forward
every request for a particular piece of content back to the content
provider. Thus, the best that could be done is for the content to
contain some header saying "please notify me each time you serve this
content with an OPES service applied", because in general, whether or
not an OPES service is applied will depend on some attributes particular
to the requestor.
3. The client side OPES operator would be able to respond to the inquiry
in the hope of satisfying whatever concern the server might have, UNLESS
in initially requesting the service from the OPES provider the
client said
"do not give notice to the server."
This mode of operation requires all participants to be OPES-enabled, very
strict limitation. If in response to request from the standard
browser comes inquiry (2) - well, this just means that the server
breaks HTTP and browser may behave unpredictably.
I think the same goal may be achieved (even more efficiently) by adding to
the request coming through the OPES proxy an additional header - OPES
advertisement (again, if permitted/instructed by the end user). Non-OPES
enabled server will simply ignore this additional header; OPES-enabled one
may add some instructions to the response.
[HKO] But in general, the decision about applying an OPES service will
not be made until the content arrives at the OPES box, so the
notification cannot travel with the request. I suppose all potential
OPES services could be listed in the request, but that seems unscalable
because it discourages adminstrators from installing services - they
cause request bloat.
As a side effect I'd suggest to add an explicit architectural requirement
that the presence of OPES server in the dataflow SHALL NOT disrupt
operations of non-OPES aware clients and servers. OPES server, content
server and content consumer MAY use OPES extensions to the base protocol
(HTTP), but support of these extensions SHALL NOT be required.
If you can amplify "disrupt" reasonably I'd probably agree with this
suggestion.
Oskar
Hilarie