-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
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.