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.