On Fri, 3 Oct 2003, Abbie Barbir wrote:
IAB used non-blocking as a means to find corrupted imtermediaries.
I disagree. In general, one cannot find corrupted intermediaries by
any programmatic means. One can bypass corrupted imtermediaries, once
they are found, using programmatic means such as bypass. IAB was
concerned that if OPES intermediaries become ubiquitous, then
corruption of a small number of unimportant services will lead to
essential information being unavailable to Internet users (humans and
machines).
This is similar to the current wildcard DNS mess: Verisign does
OPES-like transformations on DNS messages, but DNS does not have a
bypass feature so many users (humans and machines) get "blocked".
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.
So, what is the point. if non-blocking means nothing, then that is
the non-opes version.
The point is that with a more flexible bypass interface you can bypass
_corrupted_ intermediaries (and get the content rather than nothing).
With a wildcard interface you can only bypass all intermediaries which
will most likely leave you without any content or without bypass.
BTW, this brings up an important question: What should an OPES system
return if there is no non-OPES content and bypass was requested. IMO,
it should return an error of some sorts rather than OPES content.
Otherwise, it would be impossible to determine whether bypass was
processed or ignored. Returning OPES content instead of an error would
also make bypass a lot less effective: imagine a situation where a
corrupted (but unimportant) portion of a web page (e.g., some ad
applet) crashes your browser...
Design issue here. A system that requires you to go through 100 hops
before determing that you have taken the wrong pass is not optimal.
It is not up to us to decide what is optimal in an OPES system. I can
easily come up with a realistic case where checking for bypass at the
first hop is actually much worse than checking at the 100th hop,
especially if bypass instruction is an exception rather than a rule.
So simply, keep the non-blocking header in the flow until it reaches
the first processor that is capapble of handeling it.
Even simpler and more general:
bypass instruction semantics is end-to-end and not hop-by-hop
(not all application protocols have headers AND just because a
processor is capapble of handeling an instruction, does not mean it is
authorized to remove it).
Agreed. That minimum, for me, is a URI-based interface with a
wildcard option and appropriate defaults.
So what do u mean by a URI-based approach?
Something along these lines, if you wish:
A bypass instruction contains a URI that identifies an OPES
entities or a group of OPES entities to be bypassed. An
instruction may contain more than one such URI. A special
wildcard identifier can be used to represent all possible
URIs (i.e., all possible OPES entities).
The recipient of a bypass instruction containing a URI
that identifies a known-to-recipient OPES entity MUST ...
The recipient of a bypass instruction containing a URI
that identifies the recipient itself MUST ...
The recipient of a bypass instruction with a URI that does
not identify any known-to-recipient OPES entity MUST ...
(treat that URI as a wildcard identifier?).
Bypass instruction semantics is end-to-end and not
hop-by-hop. The recipient MUST forward bypass instructions to
the next application hop provided that next hop speaks
application protocol with OPES bypass support. This
requirement applies to all bypass instructions, including
those that identify known-to-recipient entities.
Application-specific bindings MUST map the above bypass
mechanism to their application protocol. An explicit
declaration of no bypass support is an acceptable mapping.
HTH,
Alex.