Sorry I made an error. Please replace the draft with this:
Open Pluggable Edge 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
Description of Working Group:
The Open Plugable Edge Services architecture (OPES) is defines how
participating transit intermediaries can be extended to incorporate
services executed on application data. The services are written to an open
standard for use with the intermediaries.
Caching is a basic intermediary service, one that requires an understanding
of at least a subset of application semantics by the cache server.
Intermediaries may employ either local or remote ("callout") servers to
perform a service, and as a result, the data may be diverted temporarily
over a closed loop pathway different from the transit pathway. The purpose
of this working group is to define the protocols for a broad set of
services that facilitate efficient delivery of complex content or services
related to application data. The advantage of standardizing these protocols
is that the services can be re-used across vendor products without
modifying the transit intermediaries or services.
The architecture supports services that are either located on the transit
intermediary or on callout servers. Protocols that connect the OPES
servicedevice and callout services must be defined. The ICAP protocol is
one option for carrying HTTP headers and data to cooperating servers; the
OPES framework will support other protocols to cooperating servers as they
exist or become available.
There are protocols and policies to define the applications that are
plugged into the OPES server. The working group must define all the
requirements that expose these as well.
The security model for intermediary services involves defining the
administrator roles and privileges for the application client, application
server, intermediary, and auxiliary server. The data integrity model
defines what operations are permitted by the content owner(s) and
guarantees of content correctness can be made to the owner(s) and viewers
when content-related services are performed.
The first objective of the working group is to deliver the requirements of
the overall system and, where possible, mandate protocol solutions where
there is consensus. Target areas where requirements and proposed solutions are:
1. Callout services protocols (e.g., ICAP) for use with HTTP and other
2. "Service delivery" protocols for delivering the services or service
descriptions to be preformed by the OPES facility or/and its cooperating
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 example).
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.
With consensus on the requirements, 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.
Early Requirements document (expired but available on the web site):
Updated iCAP Callout Server:
A Rule Specification Language for Proxy Services:
OPES Network Taxonomy:
OPES Architecture for Rule Processing and Service Execution:
OMML: OPES Meta-data Markup Language:
General Use Cases:
Goals and Milestones:
Feb 01: Workshop to discuss OPES issues
Mar 01: Consensus on the charter.
Mar 01: Meet at Minneapolis IETF
Apr 01: Additional requirements gathering and document update plans.
Jun 01: Proposed requirements for policy information model
Jul 01: Requirements for security model and configuration policy to IETF
Aug 01: Requirements of service dispatch rules, enforcement semantics,
standard data items, and post processing
Aug 01: Draft revised consensus requirements document.
Aug 01: Meet at London IETF
Nov 01: Review proposals for service dispatch rules and delivery protocols.
Dec 01: Update of requirements document.
Dec 01: Salt Lake City IETF.
Mar 02: Review charter and plan for protocol specifications.
Michael W. Condry
Director, Network Edge Technology