Update to OPES Workgroup Charter Request

Open Pluggable Extension Services(opes)

Co-chairs:
    Michael Condry <condry@intel.com>
    Hilarie Orman <HORMAN@novell.com>

Mailing Lists:
    General Discussion: ietf-openproxy@imc.org
    To Subscribe: ietf-openproxy-request@imc.org
    Web: http://www.ietf-opes.org and http://www.extproxy.org (same sites)
    Archive: ftp://ftp.ietf.org/ietf-mail-archive/opes

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 
from the
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 
protocols
and, if appropriate, API's for a broad set of services that facilitate 
efficient
delivery of complex content or services related to content.  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 co-located with the transit
intermediary or located on other cooperating servers.  There is a protocol 
that
connects the OPES service device and cooperating services. The ICAP 
protocol is
being developed as one option for carrying HTTP headers and data to 
cooperating
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 
administrator
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
cooperating servers.
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.

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.

Existing Internet-Drafts
Basic Requirements:
         http://draft-tomlinson-epsfw-00.txt
Initial iCAP Callout Server:
         http://draft-elson-opes-icap-00.txt
A Rule Specification Language for Proxy Services:
         http://draft-beck-opes-psrl-00.txt
General Use Cases:
         http://draft-beck-opes-esfnep-01.txt


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, 
standard
data items, postprocessing directives.



Michael W. Condry
Director, Network Edge Technology

Received on Thursday, 25 January 2001 18:41:32 UTC