Subject: RE: Bypassing

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

Alex,

I will not argue non-blocking vs bypass. I am very comfortable to use the
IAB term (just to be consistent).

From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Friday, October 03, 2003 11:46 AM
> To: OPES WG (E-mail)
> Subject: RE: Bypassing

SNIP

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

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

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

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

Regarding your compromise, I will consider it

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Friday, October 03, 2003 11:46 AM
> To: OPES WG (E-mail)
> Subject: RE: Bypassing
> 
> 
> 
> 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?
> 
> > 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)
> 
> 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.
> 
> > 2. Presentation is not the issue as long as the original content is 
> > 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...
> 
> > 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...)
> 
> 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.
> 
> > As far as our non-blocking requirements go:
> >
> > 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 10:16:04 -0600 (MDT)

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

> What I mean, just ride on tracing (one extra header all what we

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.