OPES Draft Charter and Mailing INfo, please comment

Orthogonal Protocol 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.extproxy.org
    Archive: ftp://ftp.ietf.org/ietf-mail-archive/opes

Description of Working Group:

The Orthogonal Protocol 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 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 and 
API's 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 servers (referred to as auxiliary 
servers in this charter).  The ICAP protocol is being developed for 
carrying HTTP headers and data to cooperating servers; other protocols for 
carrying SMTP or other protocols to cooperating servers will be supported 
by the framework, 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 four parts of a good service definition for transit-based 
extensions to an application protocol.  The first part defines the protocol 
processing point or points in the intermediary that could detect an 
application data event of interest to the auxiliary service.  The second 
part defines the server, the access method for the server, and the 
marshaled form for arguments added when delivering the application data to 
the auxiliary server.  The third defines the post processing of the data 
returned by the auxiliary.  The fourth element of the definition is an 
encoding of the above information combined with the service extension 
itself, defined as some form of loadable code or access method for invoking 
the code.  The working group will define an information model and 
realization of the model into repository and protocol elements.

These service definitions must be standardized in ways that are compatible 
with the policy framework of the Policy working group. The definitions 
constitute configuration information that can come from repositories or 
runtime protocols; for example, and ICAP server coming on-line can notify 
its clients of the services it offers, and it can update their status 
("up", "changed", "suspended", "moved") while it is running.  A namespace 
for services and a means for registering names will be considered.

Some crucial data must be communicated from the intermediary to the 
auxiliary server in standardized semantics.  Identification and 
authentication information for the application connection may be important 
to the auxiliary processing, for example.  The working group will define a 
core set of information necessary for supporting generic application needs.

Postprocessing the result from the auxiliary processor is done at the 
option of the intermediary, but instructions from the auxiliary server must 
be communicated in a standardized manner.  Generic directives ("drop", 
"hold", "assign attribute", are examples.  The working group will define 
postprocessing directives and the rules for their interaction with the 
configuration policy.

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 will use the 
Policy Configuration Information Model to define the security attributes 
and the enforceable policy.

The working group items for delivery are
1.      A "side transit" protocol (ICAP) for use with HTTP
2.      A policy-based configuration and definition model for orthogonal 
service extensions
a.      To include representation of conditions leading to invocation of 
extension 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.      A specific repository-based embodiment of the model
c.      A delivery protocol embodying the elements of the model as a 
language; the protocol may be embedded in HTTP and/or ICAP.
d.      Recommended procedures for registering service names and 
repositories for extensions
3.      A security 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: Requirements and roadmap documents for WG
Feb 01: First draft of HTTP orthogonal protocol; first draft of policy 
information model
Mar 01: Meet at Minneapolis IETF
Mar 01: OPES architecture and requirements documents
Jun 01: Submission of security model and configuration policy to IETF
Jul 15: Draft of policy rules, enforcement semantics, standard data items, 
and post processing
Aug 01: Meet at London IETF
Aug 01: Final submission of HTTP orthogonal protocol.
Oct 01: Submission of repository specific and ICAP-based policy rule 
deliver protocol
Dec 01: Salt Lake City IETF.
Dec 01: Review charter, if necessary, amend for additional orthogonal 
protocol definitions, standard data items, postprocessing directives.







Michael W. Condry
Director, Internet Strategy
2111 N.E. 25th Ave.
JF3-206
Hillsboro, OR 97124-5961

Phone: (503) 264-9019
FAX: (503) 264-3483
Email: condry@intel.com

Received on Monday, 18 December 2000 10:48:27 UTC