Re: Bypassing

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

Abbie Barbir wrote:

> 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