The 4th paragraph seems to imply a solution. That is, by saying
"RTP/RTSP-encapsulated data" the underlying assumption is that for stream
data the intermediary will actually be on the data path and that's not clear
to me at this time. A lexical comment: I think we really mean
"encapsulated [HTTP | RTP/RTSP] data" not the other way around.
Also, as one might expect, I share Jayanth's concern. I disagree with any
implication that icap is the answer. In my edits below I've made a few
changes in that paragraph to further
clarify the status of icap in the charter and I've changed the wording for
the deliverable from "icap" to "callout" protocol. But I can go with
Jayanth's suggestion to strike icap from the charter.
Speaking of deliverables, I think we're already behind schedule and we might
want to consider revising some of the dates.
Also, I'm not sure how we develop a security model and insure the that
clients and origin servers are protected if we only work on the policy
requirements. It seems that the security architecture and the policy
architecture need to be developed in tandem.
Here's my stab at a revised charter but I didn't try to rewrite the policy
requirements staement pending some other responses. I've attached a word
doc for those who can and want to read the edits in context. (If someone
wants it, I'll produce a pdf or rtf.)
------
The Internet is facilitating multiple forms of distributed applications,
some of which employ application-level intermediaries. The Open Pluggable
Edge Services (OPES) working group primary task is to define
application-level protocols enabling such intermediaries to incorporate
services that operate on messages transported by HTTP and RTP/RTSP. At the
IP level, the participating intermediaries are endpoints that are
addressed explicitly.
The protocols to be defined provide a framework for integrating a wide
range of services into application-level intermediaries. The advantage of
standardizing such protocols is that services can be re-used across vendor
products without modifying the intermediaries or services.
Intermediary services provided in this way are not transparent: they must be
authorized by an application endpoint (either the content requestor or the
content provider) that requests the edge service.
A key task for
the working group is to specify an appropriate authorization mechanism.
Intermediaries may employ services executed either locally or on a remote
("callout") server. One task for this working group is the development of
callout protocols that enable the receiving callout service to either
receive encapsulated HTTP or RTP/RTSP messages or, through some other
mechanism, for the callout service to receive the application data necessary
to perform its services.
The iCAP protocol provides similar function for services
operating on iCAP-encapsulated HTTP application data. The working group will
evaluate the iCAP protocol as one candidate for passing HTTP
application data for remote services. It may decide to extend or even not
use the iCAP protocol without being
obliged to retain any level of compatibility with the current iCAP proposal.
Another task for this working group is to enumerate the requirements for
management policies and associated administrative protocols that allow
these services to be specified and deployed. This includes requirements on
the rule systems used to specify conditions under which services are
executed.
The working group will develop a security model for OPES services in which
authorization and enforcement will be defined. The model will specify the
entities, privileges, notifications, and authorization actions affecting
content. In addition, the model will show how end-to-end services and data
integrity concepts are mapped onto the OPES architecture.
Related Internet-Drafts
Early Requirements document (expired but available on the web site):
draft-tomlinson-epsfw-00.txt
Updated iCAP Callout Protocol:
draft-elson-opes-icap-01.txt
A Rule Specification Language for Proxy Services:
draft-beck-opes-irml-00.txt
OPES Network Taxonomy:
draft-erikson-opes-net-taxonomy-00.txt
OPES Architecture for Rule Processing and Service Execution:
draft-yang-opes-rule-processing-service-execution-00.txt
OMML: OPES Meta-data Markup Language:
draft-maciocco-opes-omml-00.txt
General Use Cases:
draft-beck-opes-esfnep-01.txt
Goals and Milestones:
Aug 01: Working Group review of OPES Deployment Scenarios
document.
Sep 01: Working Group review of callout protocol
requirements.
Nov 01: Callout Protocol document last call.
Dec 01: Working group review of policy requirements
document(s).
Feb 02: Working group review of alternative callout
protocol.
Mar 02: Policy requirements document last call.
opes charter.doc
Description: MS-Word document