Re: OPES charter proposal again.

["Michael W. Condry" <[e-mail]>]

At 02:45 AM 7/3/2001 +0100, Lloyd Wood wrote:
>I do like the 'extend [..] the iCAP protocol without being obliged to
>retain any level of compatibility with the current iCAP proposal.'
>Fine, since iCAP's just an individual draft -- but isn't extending
>without being compatible something only Microsoft is generally
>regarded as being capable of doing?

That is not the intent. The intent is that the IETF process
will be followed with regard to iCAP (not some other organization's
process).


>(and security _enforcement_? is lack of enforcement specification the
>reason IPSec hasn't taken off, perhaps?)
>
>L.
>
>http://www.extproxy.org/ doesn't have that expired draft.

Which one, I will correct that.


><[e-mail]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
>
>On Mon, 2 Jul 2001, The IESG wrote:
>
> > Date: Mon, 02 Jul 2001 18:04:26 -0400
> > From: The IESG <[e-mail]>
> > To: IETF-Announce:  ;
> > Cc: [e-mail]
> > Subject: WG Review: Open Pluggable Edge Services (opes)
> >
> >
> > A new IETF working group has been proposed in the Applications Area.
> > The IESG has not made any determination as yet. Note that this is the
> > second review message for OPES due to changes to the original
> > proposed charter.
> >
> > The following Description was submitted, and is provided for
> > informational purposes only:
> >
> > Description of Working Group:
> >
> > The Internet is facilitating multiple forms of distributed
> > applications, some of which employ application-level intermediaries.
> > The Open Pluggable Edge Services (OPES) working group's primary task is
> > to define application-level protocols enabling such intermediaries to
> > incorporate services that operate on messages transported by HTTP and
> > RTP/RTSP. At the IP level, the participating intermediaries are
> > endpoints that are addressed explicitly.
> >
> > The protocols to be defined provide a framework for integrating a wide
> > range of services into application-level intermediaries. The advantage
> > of standardizing such protocols is that services can be re-used across
> > vendor products without modifying the intermediaries or services.
> >
> > Intermediary services provided in this way are not transparent: They
> > must be authorized by the application endpoint (either the content
> > requestor or the content provider) that requests the intermediary
> > service. A key task for the working group is to specify an appropriate
> > authorization mechanism.
> >
> > Intermediaries may employ services executed either locally or on a
> > remote ("callout") server. One task for this working group is the
> > development of callout protocols that enable the receiving callout
> > service to either receive encapsulated HTTP or RTP/RTSP messages or,
> > through some other mechanism, for the callout service to receive the
> > application data necessary to perform its services.
> >
> > The iCAP protocol provides similar function for services operating on
> > iCAP-encapsulated HTTP application data. The working group will
> > evaluate the iCAP protocol as one candidate for passing HTTP
> > application data for remote services. It may decide to extend or even
> > not use the iCAP protocol without being obliged to retain any level of
> > compatibility with the current iCAP proposal.
> >
> > Another task for this working group is to enumerate the requirements
> > for management policies and associated administrative protocols that
> > allow these services to be specified and deployed. This includes
> > requirements on the rule systems used to specify conditions under which
> > services are executed.
> >
> > The working group will develop a security model for OPES services in
> > which authorization and enforcement will be defined. The model will
> > specify the entities, privileges, notifications, and authorization
> > actions affecting content. In addition, the model will show how
> > end-to-end services and data integrity concepts are mapped onto the
> > OPES architecture.
> >
> >
> > Related Internet-Drafts
> >
> > Prior related requirements document (expired but available on the web
> > site):
> >   draft-tomlinson-epsfw-00.txt
> >
> > Updated iCAP Callout Protocol:
> >   draft-elson-opes-icap-01.txt
> >
> > A Rule Specification Language for Proxy Services:
> >   draft-beck-opes-irml-00.txt
> >
> > OPES Network Taxonomy:
> >   draft-erikson-opes-net-taxonomy-00.txt
> >
> > OPES Architecture for Rule Processing and Service Execution:
> >   draft-yang-opes-rule-processing-service-execution-00.txt
> >
> > OMML: OPES Meta-data Markup Language:
> >   draft-maciocco-opes-omml-00.txt
> >
> > General Use Cases:
> >   draft-beck-opes-esfnep-01.txt

Michael W. Condry
Director,  Network Edge Technology