ietf-openproxy
[Top] [All Lists]

RE: Content Provider Notification

2002-06-05 21:44:07



-----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.
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.

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.

Oskar


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