OPES charter proposal again.

[Lloyd Wood <[e-mail]>]

I do like the 'extend [..] the iCAP protocol without being obliged to
retain any level of compatibility with the current iCAP proposal.'
Fine, since iCAP's just an individual draft -- but isn't extending
without being compatible something only Microsoft is generally
regarded as being capable of doing?

(and security _enforcement_? is lack of enforcement specification the
reason IPSec hasn't taken off, perhaps?)

L.

http://www.extproxy.org/ doesn't have that expired draft.

<[e-mail]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

On Mon, 2 Jul 2001, The IESG wrote:

> Date: Mon, 02 Jul 2001 18:04:26 -0400
> From: The IESG <[e-mail]>
> To: IETF-Announce:  ;
> Cc: [e-mail]
> Subject: WG Review: Open Pluggable Edge Services (opes)
> 
> 
> A new IETF working group has been proposed in the Applications Area.
> The IESG has not made any determination as yet. Note that this is the
> second review message for OPES due to changes to the original
> proposed charter.
> 
> The following Description was submitted, and is provided for
> informational purposes only:
> 
> Description of Working Group:
>  
> The Internet is facilitating multiple forms of distributed
> applications, some of which employ application-level intermediaries.
> The Open Pluggable Edge Services (OPES) working group's 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 the application endpoint (either the content 
> requestor or the content provider) that requests the intermediary 
> 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
> 
> Prior related 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