![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
ALthough I've raised these concerns in the past, it seems appropriate to reiterate them.
OPES wants to interpose an intermeidiary processing model into HTTP (and possibly other application-layer protocols), to allow services to be applied to messages as they pass through.
While there are many scenarios where this is useful (especially when there is knowledge and consent from either or both endpoints), there are others where it is dangerous (where there is no such knowledge or consent). In such solutions, the only thing an intermediary can do is to use heuristics to determine how to interpose services.
As such, the OPES goals break end-to-end transparency at the application layer. As a result, (using HTTP as an example, because it seems the first target of OPES), the publisher loses control over a resource once it leaves their server. It then becomes impossible to makes statements about that resource (e.g., P3P, Semantic Web, legal status of a resource, etc.).
I suppose this would be fine if there was an active need for client- or server-driven OPES vectoring in the market (e.g., integration of OPES into the browser, or into content delivery networks, etc.). However, I see no market for OPES in the CDN world, despite ICAP's existence for more than two years, and nothing on the client side. Instead, the only ICAP services to date seem to be targetted at ISPs (e.g., virus scanning, content transformation, ad insertion, etc.).
While nothing stops intermediaries from doing this now, it's another thing, IMHO, to encourage these practices by standardizing them. HTTP (perhaps unfortunately) does not preclude transformation of messages by intermediaries, so OPES has authority to do what it wants to with the protocol. My problem is that it provides considerable power to intermediaries, before there are mechanisms (trust, etc.) in place to mitigate its effects.
Cheers,
-- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA USA)
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.