-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Sent: Friday, October 03, 2003 1:06 PM
To: OPES WG (E-mail)
Subject: RE: Bypassing
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.