Strawman OPES Charter

Folks,

please see below for a strawman proposal for a new OPES charter.

Ted already provided some comments and feedback on it; his main 
comment being that the single SMTP milestone seems a bit monolithic. A 
  suggestion is to maybe split the work up a bit more along the 
several roles SMTP elements can have: MSA, MTA, MDA, MUA, and working 
out what might be opes related for each. Ted mentioned that for some 
it will be easy (not much "callout protocol" work for an MUA), but 
that there is no guarantee that the roles are the same for the others.

Please provide your comments and thoughts on the proposed new charter, 
but also on the suggestion made with respect to the single SMTP milestone.

Thanks,
   Markus


===========================================================

Open Pluggable Edge Services (opes)
-----------------------------------

Chair(s):
Markus Hofmann <[email protected]>

Applications Area Director(s):
Ted Hardie <[email protected]>
Scott Hollenbeck <[email protected]>

Applications Area Advisor:
Ted Hardie <[email protected]>

Technical Advisor(s):
Allison Mankin <[email protected]>
Hilarie Orman <[email protected]>

Mailing Lists:
General Discussion: [email protected]
To Subscribe: [email protected]
Archive: http://www.imc.org/ietf-openproxy/mail-archive/

Description of Working Group:
The Internet facilitates the development of networked services at the 
application level that both offload origin servers and improve the 
user experience. Web proxies, for example, are commonly deployed to 
provide services such as Web caching, virus scanning, and request 
filtering. Lack of standardized mechanisms to trace and to control 
such intermediaries causes problems with respect to failure detection, 
data integrity, privacy, and security.

The OPES Working Group has previously developed an architectural 
framework to authorize, invoke, and trace such application-level 
services. The framework follows a one-part consent model, which 
requires that each service be authorized explicitly by at least one of 
the application-layer endpoints. It further requires that OPES 
services are reversible by mutual agreement of the application endpoints.

In particular, the WG has developed a protocol suite for invocation 
and tracking of OPES services inside the net. The protocol suite 
includes a generic, application-agnostic protocol core (OCP Core) that 
is supplemented by profiles specific to the application-layer protocol 
used between the endpoints. So far, the WG has specified an OCP 
profile for HTTP, which supports OPES services that operate on HTTP 
messages.

In a next step, the WG will specify an additional OCP profile that 
will support applications operating on SMTP messages. In particular, 
the profile to be specified will enable an OPES processor to 
encapsulate and forward SMTP messages (or parts thereof) to a callout 
server for additional processing.

In addition, the WG will define one or more methods for specifying 
rules that enable application endpoints to control the execution of 
OPES services. These methods are purely for controlling the invocation 
of services. They are not aimed at implementing the actual services. 
The working group will have a design goal that the methods be 
compatible with existing policy work within the IETF (e.g. IETF Policy 
Framework)and be able to interface with systems automating 
distribution of policies to multiple endpoints. It will be out of 
scope for this WG to develop the policy framework and specify 
multiple-endpoint policy distribution.

The group's new work items can be listed as:

- Define a SMTP profile to supplement OCP core.
- Define specification method(s) and rules for controlling
   invocation of OPES services operating on HTTP/SMTP
   messages.

Each deliverable must follow the previously developed OPES 
architecture. As each deliverable is developed, it must address the 
IAB considerations specified in RFC 3238.

Goals and Milestones:

Done    Submit OPES scenarios document and architecture
         document to IESG for Informational.
Done    Submit document on protocol (callout and tracing)
         requirements to IESG for Informational.
Done    Submit document on endpoint authorization and
         enforcement requirements to IESG for Informational.
Done    Submit document on threat/risk model for OPES
         services to IESG for Informational.
Done    Initial protocol document for OPES services
         including their authorization, invocation,
         tracking, and enforcement of authorization.
Done    Initial document on rules specification method.
Done    Submit protocol document for OPES services
         including their authorization, invocation,
         tracking, and enforcement of authorization to IESG
         for Proposed Standard.
NOV04   Initial document on SMTP protocol profile
JAN05   Initial document on OPES rules language
FEB05   Submit document on SMTP protocol profile to
         IESG for Proposed Standard
MAY05   Submit document on OPES rules language to
         IESG for Proposed Standard