Open Pluggable Extension Services(opes)
Michael Condry <condry(_at_)intel(_dot_)com>
Hilarie Orman <HORMAN(_at_)novell(_dot_)com>
General Discussion: ietf-openproxy(_at_)imc(_dot_)org
To Subscribe: ietf-openproxy-request(_at_)imc(_dot_)org
Web: http://www.ietf-opes.org and http://www.extproxy.org (same sites)
Description of Working Group:
The Open Pluggable Extension Services architecture (OPES) enables construction
of services executed on application data by participating transit
intermediaries. Caching is the most basic intermediary service, one that
requires a basic understanding of application semantics by the cache server.
Because intermediaries divert data temporarily over a pathway different
transit pathway, one can think of the service path as being orthogonal to the
main transit path. The purpose of this working group is to define the
and, if appropriate, API's for a broad set of services that facilitate
delivery of complex content or services related to content. The advantage of
standardizing these protocols is that the services can be re-used across
products without modifying the transit intermediaries or services.
The architecture supports services that are either co-located with the transit
intermediary or located on other cooperating servers. There is a protocol
connects the OPES service device and cooperating services. The ICAP
being developed as one option for carrying HTTP headers and data to
servers; the framework will support other protocols to cooperating servers, as
they exist or become available. This working group defines the supporting
configuration data and protocols for configuring services on the transit
intermediaries; this configuration makes it possible to administer collections
of transit intermediaries and content services as a coherent system.
There are protocols and policies to define the applications that are plugged
into the OPES server. The working group must define these as well.
The security model for intermediary services involves defining the
roles and privileges for the application client, application server,
intermediary, and auxiliary server.
The working group items for delivery are
1. A "side transit" protocol (e.g., ICAP) for use with HTTP
2. A "service delivery" protocol for delivering the services or service
descriptions to be preformed by the OPES facility or/and its
3. A configuration and definition model for service extensions
a. To include representation of conditions leading to invocation of
intermediary-based services, common data items (identities,
authentication state, etc.), postprocessing directives, and the
access method for the service or a representation of a loadable
service (URL or encoded executable or interpretable code, for
b. Other policy recommendations observed by having an intermediary be
the central point of service extensions.
4. A trust model and security configuration policy definitions, i.e.
roles, privileges, and enforcement point responsibilities.
After these items have been delivered, the working group can examine the
progress in this area and, if appropriate, re-charter to with more
general work items in the OPES framework.
Initial iCAP Callout Server:
A Rule Specification Language for Proxy Services:
General Use Cases:
Goals and Milestones:
Feb 01: Workshop to discuss OPES issues
Mar 01: First draft of a OPES-device-to-OPES-servers protocol.
Mar 01: Meet at Minneapolis IETF
Mar 01: Requirements gathering and document update plans.
May 01: First draft of policy information model
Jun 01: Submission of security model and configuration policy to IETF
Jul 15: Draft of service dispatch rules, enforcement semantics, standard data
items, and post processing
Aug 01: Meet at London IETF
Aug 01: Final submission of callout protocol(s).
Nov 01: Draft of "service specification" protocol
Dec 01: Salt Lake City IETF.
Mar 02: Review charter, if necessary, amend for additional definitions,
data items, postprocessing directives.
Michael W. Condry
Director, Network Edge Technology