Subject: RE: Tracing Draft version-05042003

From: "Abbie Barbir" <[email-masked]>
Date: Thu, 8 May 2003 16:56:31 -0400

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:[email-masked]] 
> Sent: Thursday, May 08, 2003 4:44 PM
> To: Barbir, Abbie [CAR:1A00:EXCH]
> Cc: [email-masked]; [email-masked]
> 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
> 
>

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 8 May 2003 15:33:29 -0600 (MDT)

> on the proxy issue, I will add proper text and resubmit.

Please do NOT without further discussion! Application caching is out
of OPES scope. If we assume HTTP is being adapted, then HTTP already
has all necessary mechanisms that servers can use to get "all
requests", even if their responses are cachable. OPES has nothing to
do with this. We can explicitly say that OPES is not concerned with
application caching if we want to.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 8 May 2003 20:14:25 -0600 (MDT)

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

> If OPES is not friendly to caching, I see it as being fatally crippled.

OPES is neither friendly or unfriendly to caching. OPES makes caching
no more or less good/evil. HTTP and other application protocols may be
friendly or unfriendly, but OPES has nothing to do with caching.  If
you think otherwise, please give an example where caching-awareness in
application-agnostic OPES will make any positive difference.

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Thu, 8 May 2003 20:10:19 -0600

Hilarie