Oskar Batuner wrote:
On OPES advertisement/notification headers:
The main idea is to let the content server know that
there is an OPES entity in the dataflow path. Adding
an "existence and capabilities" notification to request
or response does not replace tracing and reporting
mechanism, it just supplements it and helps to overcome
limitations imposed by "don't break end-to-end HTTP" rule.
If such notification is present it SHALL include:
a) OPES protocol extensions level supported, including
tracing and reporting support available;
b) method to be used by the content server to communicate
with OPES server - OPES extensions to base protocol or
out-of-band. In the latter case OPES server address
MUST be included.
[HKO] This implies that there is a new communication protocol and
that the OPES server MUST be directly addressable from outside
the content path. That opens a security hole for DOS attacks
that didn't have to be there before.
It MAY also include:
c) OPES server origin-of-authority address (if one is different
from the OPES server itself and the OPES server is willing to
expose one). This may be useful for out-of-band negotiations
(for example getting/checking authorization for certain actions
or signing up for pay-per-use services);
[HKO] Signing up for services is not part of the OPES callout or
tracing protocol. The architecture specifies this as a separate
function. I don't see how an SOA in a request helps the process.
d) services or classes of services available.
[HKO] Do you mean "available" or "might be applied sometime to the
result of this request"? What about subsequent requests for the
same content, requests that do not go to the origin server? If
the OPES data processor changes it policies, must it notify all
origin servers for which it holds cached data of the changes?
I don't think such notification creates a scalability
problem - number of OPES servers in a particular dataflow is
very limited. The main goal of notification is not to advertise
all available services or their classes (though this also may
be feasible in some cases) but to declare willingness of the
OPES server to disclose its presence and negotiate services
(including tracing and reporting) with the content server
or user agent.
[HKO] This extra negotiation seems to be a needless complication.
Hilarie
Oskar
-----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 The
Purple Streak
(Hilarie Orman)
Sent: Thursday, June 06, 2002 1:12 AM
To: OPES Group
Subject: Re: Content Provider Notification
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