IMO, this is _exactly_ what IAB was (or should have been) concerned
about: corrupted or misbehaving OPES intermediaries. Clearly,
it is a matter of IAB RFC interpretation, but I would rather
err on the safe side than narrow down IAB implications to a
trivial case.
IAB used non-blocking as a means to find corrupted imtermediaries.
Even today, content is being composed from dozens of sources
and pieces. An all-or-nothing approach would more and more
often mean "nothing". Not just will you strip the ad or
weather info. You will not get the news page at all. The
URI-based approach lets you get the page you want, with some
missing information.
So, what is the point. if non-blocking means nothing, then that is the
non-opes version.
While 3.3 indeed applies to content, it says nothing about
the OPES side (client or server) or the OPES processor
number. While it is the 1st OPES processor that will get the
request, it may not be the 1st OPES processor that will know
whether a non-OPES version is available.
Design issue here. A system that requires you to go through 100 hops before
determing that you have taken the wrong pass is not optimal.
So simply, keep the non-blocking header in the flow until it reaches the
first processor that is capapble of handeling it.
Agreed. That minimum, for me, is a URI-based interface with a
wildcard option and appropriate defaults.
So what do u mean by a URI-based approach?
Abbie
-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Sent: Friday, October 03, 2003 12:16 PM
To: OPES WG (E-mail)
Subject: RE: Bypassing
On Fri, 3 Oct 2003, Abbie Barbir wrote:
Not necessarily. For example, if I know that my ISP is
logging all
HTTP request bodies to be sent to FBI or a marketing
agency, I want
to tell my ISP to bypass that feature. An OPES-compliant ISP will
honor my request if possible.
I recommend that you change ISP or better move to another country.
This is not what we are asked to do here by the IAB.
IMO, this is _exactly_ what IAB was (or should have been) concerned
about: corrupted or misbehaving OPES intermediaries. Clearly,
it is a matter of IAB RFC interpretation, but I would rather
err on the safe side than narrow down IAB implications to a
trivial case.
Even today, content is being composed from dozens of sources
and pieces. An all-or-nothing approach would more and more
often mean "nothing". Not just will you strip the ad or
weather info. You will not get the news page at all. The
URI-based approach lets you get the page you want, with some
missing information.
True, except we cannot tell whether it is the first or any other
OPES processor or callout service that will honor the bypass
instruction. We should not tell an OPES system exactly how to
implement bypass.
It is clear from (3.3) it is client centric (It is the 1st OPES
processor that will get the request)
While 3.3 indeed applies to content, it says nothing about
the OPES side (client or server) or the OPES processor
number. While it is the 1st OPES processor that will get the
request, it may not be the 1st OPES processor that will know
whether a non-OPES version is available.
IAB is concerned about some minimal functionality. We can
get a lot
more, at about the same cost. We do follow what IAB 3.3 suggests,
but we go further.
U can if u have the time. I suggest that u do the minimum
for now and
get the OCP/HTTP drafts done, otherwise, just packup and go home.
Agreed. That minimum, for me, is a URI-based interface with a
wildcard option and appropriate defaults.
3. Non-blocking MUST be Done in-band.
Do you mean "and only in-band"? What does this
requirement buy you?
What I mean, just ride on tracing (one extra header all what we
need)
Not sure I follow. Traces go in the opposite direction of
bypass requests so you cannot reuse them for bypass. I am not
suggesting that we specify an out-of-band mechanism, but I do
not see any reason to prohibit one either.
Alex.