- From: Michael W. Condry <condry@intel.com>
- Date: Thu, 25 Jan 2001 15:38:48 -0800
- To: discuss@apps.ietf.org
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