[With apologies for the large distribution... though I wonder whether it
would have been better to have addressed IAB directly rather than Sally?]
--On Friday, December 7, 2001 13:41 -0800 Joseph Hui <jhui(_at_)digisle(_dot_)net>
wrote:
# (2.2) IP-layer communications: For an OPES framework standardized in
# the IETF, the OPES intermediary must be explicitly addressed at the
# IP layer by the end user.
The above clause in draft-iab-opes-01.txt, taken literally as I
understand it,
constrains that only single-intermediary content processing pipeline
will be
possible under OPES. E.g. it'll be impossible to do filtering like:
server | language_translation | virus_scan | client
(or: server | insert_image | dither_image_for_viewing_device | client)
where the multiple intermediaries run on different IP hosts.
Hrm...
It's hard to image one would have to resort to some unscaleable hacks
like:
server | language_translation | \
server | virus_scan | client
in order to work around the constraint.
Q1, to IAB:
Would the IAB shed some light on the benefits of
stipulating n=1 (as in an n-intermediary OPES content
pipeline), such that they outweigh the cost of depriving
content providers and consumers the advantages that n>=1
offers, as exemplified in the use cases above?
I'm not sure the intent was really to limit things in this way but I can
see the problem (and obviously it would be good to get an official answer).
If implementors could argue their case that use of multiple intermediaries
had the same overall effect as multiple proxylets on the same intermediary
then I think this would sufficiently demonstrate that the recommendation
had been addressed.
It's my belief that recommendation 2.2 is really saying "you must not do
this transparently by intercepting traffic". Of course, when taken on its
own like this 2.2 can be seen to convey more awkward issues.
(As a pet rant I wonder whether potentially problematic issues like this
would have been identified and resolved if the document had gone through a
Last Call.)
Q2, to IAB & all:
Can the "explicit addressing at the IP layer by the end user,"
which I take it for the need of the end user's cognizance of
the remote IP address in the end_user-intermediary socket
connection, be critically meaningful for OPES practitioners
anyway in the face of NAT (which, incidentally, was yet
another IETF whipping boy)?
I'm not sure I understand your question Joe.