looks fine at this stage,
abbie
-----Original Message-----
From: Markus Hofmann [mailto:hofmann(_at_)bell-labs(_dot_)com]
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 <hofmann(_at_)bell-labs(_dot_)com>
Applications Area Director(s):
Ted Hardie <hardie(_at_)qualcomm(_dot_)com>
Scott Hollenbeck <sah(_at_)428cobrajet(_dot_)net>
Applications Area Advisor:
Ted Hardie <hardie(_at_)qualcomm(_dot_)com>
Technical Advisor(s):
Allison Mankin <mankin(_at_)psg(_dot_)com>
Hilarie Orman <ho(_at_)alum(_dot_)mit(_dot_)edu>
Mailing Lists:
General Discussion: ietf-openproxy(_at_)imc(_dot_)org
To Subscribe: ietf-openproxy-request(_at_)imc(_dot_)org
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.