But wouldn't it be alright to perform intermediary services that do usurp
the normal client-to-server interface as long as they are authorized by the
content provider?
there are two separate issues: permission and interface.
I would say that at least one endpoint has to give permission before any
intermediary should modify content.
From the point of view of granting permission, the mechanism is not relevant.
So if (for example) a content-provider wants to implement a service using
interception proxies that intercept that content-provider's IP addresses,
and which modify the content obtained from other servers that are maintained
by that content-provider (or with which that content-provider has made
arrangements, whatever), then I view that as strictly an implementation issue.
As long as the interface as viewed from outside of the content-provider's
domain conforms to the standards, the content-provider should be free to
implement its services however it wishes.
On the other hand, if you are trying to define a standard interface to a
service that modifies content in arbitrary ways, and particularly one that
is usable on either the client or the server end, I suspect that it would be
a poor design choice to base OPES on top of HTTP. For instance, this
could make it awkward for the client to enable or disable OPES services
at will; for another, HTTP is already too overloaded from trying to serve
a variety of needs, and doesn't need to be stretched in additional directions
to accomodate OPES.
I'm not saying it cannot be done; I'm saying that from this (admittedly
cursory) view, it looks like a huge mess. I might be wrong. But
I hope that the working group (if chartered) does not presume HTTP as
a solution - either as a substrate or by treating intermediaries as proxies.
Keith