Subject: RE: Bypassing

From: "Abbie Barbir" <[email-masked]>
Date: Fri, 3 Oct 2003 12:29:29 -0400

> 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:[email-masked]] 
> 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.
>

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 3 Oct 2003 11:06:24 -0600 (MDT)

> IAB used non-blocking as a means to find corrupted imtermediaries.

I disagree. In general, one cannot find corrupted intermediaries by
any programmatic means. One can bypass corrupted imtermediaries, once
they are found, using programmatic means such as bypass. IAB was
concerned that if OPES intermediaries become ubiquitous, then
corruption of a small number of unimportant services will lead to
essential information being unavailable to Internet users (humans and
machines).

This is similar to the current wildcard DNS mess: Verisign does
OPES-like transformations on DNS messages, but DNS does not have a
bypass feature so many users (humans and machines) get "blocked".

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

The point is that with a more flexible bypass interface you can bypass
_corrupted_ intermediaries (and get the content rather than nothing).
With a wildcard interface you can only bypass all intermediaries which
will most likely leave you without any content or without bypass.

BTW, this brings up an important question: What should an OPES system
return if there is no non-OPES content and bypass was requested. IMO,
it should return an error of some sorts rather than OPES content.
Otherwise, it would be impossible to determine whether bypass was
processed or ignored. Returning OPES content instead of an error would
also make bypass a lot less effective: imagine a situation where a
corrupted (but unimportant) portion of a web page (e.g., some ad
applet) crashes your browser...

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

It is not up to us to decide what is optimal in an OPES system. I can
easily come up with a realistic case where checking for bypass at the
first hop is actually much worse than checking at the 100th hop,
especially if bypass instruction is an exception rather than a rule.

> So simply, keep the non-blocking header in the flow until it reaches
> the first processor that is capapble of handeling it.

Even simpler and more general:

    bypass instruction semantics is end-to-end and not hop-by-hop

(not all application protocols have headers AND just because a
processor is capapble of handeling an instruction, does not mean it is
authorized to remove it).

> So what do u mean by a URI-based approach?

Something along these lines, if you wish:

    A bypass instruction contains a URI that identifies an OPES
    entities or a group of OPES entities to be bypassed. An
    instruction may contain more than one such URI. A special
    wildcard identifier can be used to represent all possible
    URIs (i.e., all possible OPES entities).

    The recipient of a bypass instruction containing a URI
    that identifies a known-to-recipient OPES entity MUST ...

    The recipient of a bypass instruction containing a URI
    that identifies the recipient itself MUST ...

    The recipient of a bypass instruction with a URI that does
    not identify any known-to-recipient OPES entity MUST ...
    (treat that URI as a wildcard identifier?).

    Bypass instruction semantics is end-to-end and not
    hop-by-hop. The recipient MUST forward bypass instructions to
    the next application hop provided that next hop speaks
    application protocol with OPES bypass support. This
    requirement applies to all bypass instructions, including
    those that identify known-to-recipient entities.

    Application-specific bindings MUST map the above bypass
    mechanism to their application protocol. An explicit
    declaration of no bypass support is an acceptable mapping.

HTH,

Alex.