Subject: RE: Bypassing

From: "Abbie Barbir" <[email-masked]>
Date: Fri, 3 Oct 2003 09:57:43 -0400

Regarding Bypass,

I really think we should call it non-blocking, since the term bypass is
being misused.
Let us not loose sight of what is needed.

(3.3) Non-blocking: If there exists a "non-OPES" version of content
   available from the content provider, the OPES architecture must not
   prevent users from retrieving this "non-OPES" version from the
   content provider.

It is important for us to understand what this means. So here what I think

1. This is related to content modification (like image cropping, translation
etc)
2. Presentation is not the issue as long as the original content is
presented in the way that the content provider has intended.

3. It is the task of the content provider to make non-OPES versions
available, so OPES can serve them. In this case, the first OPES processor
will check the header of the message and see a non-blocking header on it, in
the simplest scenario, it will just fwd the request to the origin content
provider if the content provider allows that, otherwise, the opes version is
served. The user may get a page with missing weather info or no ads and may
be pink background, (so that what he gets...)

A user can issue non-blocking requests, but whether it is honored or not is
a function of how the content is/was or will be created and what the content
provider provides and its agreement with the OPES provider.

Looking at the bypass thread, it seems to me that we are not following what
IAB 3.3 suggests. We are not in the business of providing the user with
optional services or processors or callout servers that he/she can bypass
(or what you call class of services). 

As far as our non-blocking requirements go:

1. An OPES System Must Support non-blocking
2. An OPES Processor MUST be able to process a non-blocking header
3. Non-blocking MUST be Done in-band.

So, from your e-mails, non-blocking default to a wildcard request, where
what it means is a fucntion of the agreement between the content provider
and the OPES provider.

PS: The IAB has asked us to build a house (and from the bypass thread, it
seems that you want to build a Castle).

Abbie

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 03 Oct 2003 10:45:07 -0400

I mostly agree with Abbie's observations in that the fine-grained 
BYPASS features discussed earlier in the thread are not really what we 
need to do and too complicated. In particular, I'd be reluctant to 
specify classes of OPES services, since we'll never be able to predict 
all future OPES service classes...

If a user requests non-blocking, OPES processor needs to determine 
whether a "non-OPES" version is available. If yes, this version will 
have to be served. If not, either an error is returned or the OPES 
version is served.

It then boils down on how to determine whether there's a non-OPES 
version available, which Abbie addresses under (3) below. Couldn't we 
go that far and say that requests with non-blocking flag are always 
being forwarded to the origin server. Now, when an error comes back 
(because there's no non-OPES version), we could either leave it to the 
user to remove the non-blocking flag (if wanted), or invoke the OPES 
service and serve the OPES version.

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 3 Oct 2003 09:46:25 -0600 (MDT)

On Fri, 3 Oct 2003, Abbie Barbir wrote:

> I really think we should call it non-blocking, since the term bypass
> is being misused.

I disagree. What we need is a bypass mechanism. OPES does not block
anything in general, it adapts. Not to mention that using a negated
term to name a concept is not "right". Finally, non-blocking is not a
noun, is it?

> 1. This is related to content modification (like image cropping,

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.

> presented in the way that the content provider has intended.

We do not know providers intent. Some providers would consider
translation an acceptable presentational change. Some would consider
content encoding change (GIF->PNG) as unacceptable. Is image cropping
a presentational issue? Depends on the context...

> available, so OPES can serve them. In this case, the first OPES
> processor will check the header of the message and see a
> non-blocking header on it, in the simplest scenario, it will just
> fwd the request to the origin content provider if the content
> provider allows that, otherwise, the opes version is served. The
> user may get a page with missing weather info or no ads and may be
> pink background, (so that what he gets...)

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.

> A user can issue non-blocking requests, but whether it is honored or
> not is a function of how the content is/was or will be created and
> what the content provider provides and its agreement with the OPES
> provider.

Agreed.

> Looking at the bypass thread, it seems to me that we are not
> following what IAB 3.3 suggests. We are not in the business of
> providing the user with optional services or processors or callout
> servers that he/she can bypass (or what you call class of services).

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.

If you disagree or do not want to do the legwork, I suggest a simple
compromise: Document the
	Bypass: URI|*
feature, but leave URI semantics interpretation for future drafts
to define (with an appropriate default). Document just the "Bypass: *"
version. This way, we are addressing an IAB concern and leaving
enough room for future extensions.

This has to be documented in a application-agnostic way, of course.

> 1. An OPES System Must Support non-blocking

non-blocking what? Bypass is a noun, non-blocking is not, right?

> 2. An OPES Processor MUST be able to process a non-blocking header

You have to define _how_ it MUST process it for this requirement to
make sense. Clearly, a processor will process it somehow (e.g.,
forward it to the next application hop).

> 3. Non-blocking MUST be Done in-band.

Do you mean "and only in-band"? What does this requirement buy you?

> So, from your e-mails, non-blocking default to a wildcard request,
> where what it means is a fucntion of the agreement between the
> content provider and the OPES provider.

I agree with the wildcard part, but I think that we must define "what
it means" or there is not reason to document it at all.

> PS: The IAB has asked us to build a house (and from the bypass
> thread, it seems that you want to build a Castle).

Let's not go down this path or we will never stop arguing: The IAB has
asked us to make sure kids do not eat poisonous mushrooms. What you
are suggesting is to make sure kids do not eat mushrooms.

See for a constructive compromise idea above.

Thanks,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 3 Oct 2003 09:58:33 -0600 (MDT)

On Fri, 3 Oct 2003, Markus Hofmann wrote:

> BYPASS features discussed earlier in the thread are not really what
> we need to do and too complicated. In particular, I'd be reluctant
> to specify classes of OPES services, since we'll never be able to
> predict all future OPES service classes...

We do not have to specify all classes or _any_ classes. I suggest that
we specify a URI-based interface (with a wildcard) and specify
appropriate defaults for implementations that do not understand the
meaning of a given URI. Others may use our interface and specify URI
meanings.

Agreed.

> version available,

The exact mechanism is out of our scope. OPES systems will "determine"
somehow.

> Couldn't we go that far and say that requests with non-blocking flag
> are always being forwarded to the origin server.

Not in general. (a) A request may need to be modified for non-OPES
content to be served by the OPES-unaware server (e.g., a particular
header or parameter may need to be added by an OPES processor). And
(b) this is too HTTP-specific.

> Now, when an error comes back (because there's no non-OPES version),
> we could either leave it to the user to remove the non-blocking flag
> (if wanted), or invoke the OPES service and serve the OPES version.

A user usually does not have control over low-level information such
as HTTP headers. The bypass has to be implemented entirely within the
OPES system (or it is not a bypass).

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 03 Oct 2003 14:18:51 -0400

> meaning of a given URI. Others may use our interface and specify URI

That's fine, as long as we don't have pre-defined classes.

>>have to be served. If not, either an error is returned or the OPES

I actually start believeing that an error should be returned in the 
latter case...

> header or parameter may need to be added by an OPES processor). 

Agreed, good point.

> OPES system (or it is not a bypass).

First of all, someone needs to articulate the desire to bypass OPES, 
and this someone I would expect is the user. And I would assume that 
this could be done, for example, similar to the "hard reload" feature 
of Web browsers. When I hit CTRL-F% in my IE, it adds an "no-cache" 
header to the outgoing HTTTP request.

-Markus