Subject: RE: Tracing Draft version-05042003

From: "Abbie Barbir" <[email-masked]>
Date: Thu, 8 May 2003 15:25:22 -0400

All,

We need feedback on this or should we issue a last call (this would be easy)

abbie

> -----Original Message-----
> From: Barbir, Abbie [CAR:1A00:EXCH] 
> Sent: Sunday, May 04, 2003 7:01 AM
> To: 'Alex Rousskov'; [email-masked]
> Cc: Barbir, Abbie [CAR:1A00:EXCH]
> Subject: Tracing Draft version-05042003
> 
> 
> hi,
> 
> attached is the updated version of the tracing draft.
> please provide feedback ASAP.
> 
> Note: This is work in progress. I am on the road with limited 
> e-mail access untill May 8th.
> 
> Regards
> 
> Abbie
>

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Thu, 8 May 2003 14:43:54 -0600

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: Sat, 10 May 2003 12:39:34 -0600 (MDT)

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

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

The draft is just about tracing ("detection") for now. Pragmatic
"response"  will be covered when bypass feature is documented. We can
also comment on non-algorithmic responses, such as complaining about
the service to the service owner. I think the current draft has some
wording about it when discussing notifications.

Note that bypass will be available for both sides.

> receive a request for each use of the data.

If a _caching proxy_ is deployed near the consumer, the provider will
not receive all requests, _unless_ the provider cares to use
appropriate cache control headers and the proxy honors them. Nowhere
OPES comes into play here, whether the same proxy does OPES or not.

> 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 server is already provided with such a signalling capability in
HTTP. We should not try to solve the problem of the application
protocols we adapt. As for "OPES services be sent" part (which is
notification), we already argue that we are not going to support that
on a protocol level.

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

We will support a bypass feature. A "what services do you support?"
protocol can be written, but we do not have to write it. Moreover, I
expect its deployment levels in the cross-trust-domain scenario you
describe to be close to zero: Client-side proxies have no incentive to
respond to server-side requests and have incentives not to respond
(and vice versa).  In the same-trust-domain scenario, the usefulness
of such protocol is questionable.

This is the same argument we use when talking about notification
support. We assert that the best we can do is tracing+bypass because
anything beyond that violates administrative boundaries/incentives/etc
and has historical precedents of being rejected by the real world
(e.g. the Hit Metering protocol).

Note that traces are not likely to tell request recipients what
services are going to be applied to their response. That information
is not known (in general) at the time of the request and will be
available to the response recipient only. That is why we argue that
the only practical way for content providers to know what has happened
is to ask the end user for "response headers" (or play the end-user
role, if possible).

Alex.