RE: Latest Charter Proposal

looks fine at this stage,

abbie


> -----Original Message-----
> From: Markus Hofmann [mailto:[email protected]] 
> Sent: Thursday, July 15, 2004 10:01 AM
> To: OPES Group
> Subject: Latest Charter Proposal
> 
> 
> 
> Folks,
> 
> below the latest charter proposal. I'd like to close on this soon and 
> forward to our Area Directors for feedback.
> 
> Please take a careful look. If you've comments, please make 
> *specific* 
> suggestions on where the text should be changed and how it should be 
> changed.
> 
> If there are no more comments by Friday, 7/16, 5pm (EST), 
> I'll forward 
> this version of the charter to Ted/IESG.
> 
> 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-party 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 one or more OCP profiles 
> that will 
> support OPES services 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. Several kinds of agents participate in SMTP 
> exchanges, including MSA, MTA, MDA, and MUA. The first OCP/SMTP 
> profile will address the needs of at least the MTA. More profiles may 
> be needed to address other agent-specific needs.
> 
> In addition, the WG will define a rules language to control selection 
> and invocation of services by an OPES processor. This includes a 
> mechanism allowing an OPES processor to perform a runtime check of 
> service parameters, leveraging existing interface description 
> standards like WSDL, if possible, or OPES-specific description 
> otherwise. Defining language(s) for implementing OPES services is out 
> of the WG scope. The rules language will be based on previous work of 
> the WG on a rule language named "P". The working group will have a 
> design goal that the language 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:
> 
> - Develop a scenarios and use case document for OPES
>    services operating on SMTP messages.
> - Define SMTP profile(s) to supplement OCP core.
> - Define a rules language to control the selection and
>    invocation of HTTP-based or SMTP-based OPES services.
> 
> 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.
> SEP04   Revised document on OPES rules language.
> OCT04   Submit use cases document for OPES services
>          operating on SMTP messages to IESG for
>          Informational.
> DEC04   Initial document on OCP/SMTP profile for MTAs.
> FEB05   Submit document on OCP/SMTP profile for MTAs to
>          IESG for Proposed Standard.
> APR05   Submit document(s) on OCP/SMTP profile(s) for those
>          other SMTP agents the WG has decided to work on, if
>          any.
> MAY05   Submit document(s) on OPES rules language to
>          IESG for Proposed Standard.
> MAY05   Consider additional OPES work and present new
>          charter to IESG, or conclude working group.
> 
>