I have mixed opinions on this. Most prefer the iCAP paragraph because
it is one example. The charter only deals with it that way.
If you believe it is a protocol worth looking at, and the paragraph basically
says that, why is there such a concern?
At 02:32 PM 3/29/2001 -0600, Jayanth Mysore wrote:
I am not yet fully convinced that we need the paragraph on ICAP in
the charter.
I do believe it is a protocol worth looking at closely for our
purposes. However it
seems unecessary to state out intentions to do so in the charter.
- Jayanth
Hilarie Orman wrote:
> I strongly advise simplification by taking the two
> paragraphs re transparency and security and combining
> them thusly:
>
> Intermediary services will not be transparent.
> A security model with modes of authorization will
> be part of the architecture and protocol elements.
>
> Hilarie
>
> >>> "Michael W. Condry" <condry(_at_)intel(_dot_)com> 03/29/01 11:36AM >>>
>
> Open Pluggable Edge Services (opes)
>
> Co-chairs:
> Michael Condry <condry(_at_)intel(_dot_)com>
> Markus Hofmann <hofmann(_at_)lucent(_dot_)com>
>
> Technical Team Lead:
> Hilarie Orman <horman(_at_)volera(_dot_)com>
>
> Mailing Lists:
> General Discussion: ietf-openproxy(_at_)imc(_dot_)org
> To Subscribe: ietf-openproxy-request(_at_)imc(_dot_)org
> Web: http://www.ietf-opes.org
> Archive: ftp://ftp.ietf.org/ietf-mail-archive/opes
>
> Description of Working Group:
>
> The Open Pluggable Edge Services (OPES) working group
> primary task is to define protocols enabling
> participating transit intermediaries to incorporate
> services that operate on application-level data
> transported by HTTP and possibly RTP/RTSP. The protocol
> to be defined provides a framework for integrating a
> wide range of services into arbitrary intermediaries.
> Intermediaries may employ services executed either
> locally or on a remote ("callout") server. As a result,
> the data may be diverted temporarily over a closed loop
> pathway different from the transit pathway.
>
> The advantage of standardizing such a protocol is that
> services can be re-used across vendor products without
> modifying the transit intermediaries or services.
>
> The iCAP protocol already provides similar functionality
> for services operating on HTTP-encapsulated application
> data. The working group will evaluate the iCAP protocol
> as one candidate for HTTP-encapsulated application data.
> It may decide to extend the iCAP protocol without being
> obliged to retain any level of compatibility with
> the current iCAP proposal.
>
> Intermediary services provided in this way are not
> transparent: They have to be authorized by either the
> content requestor or the provider, corresponding to
> who the service being provided for.
>
> As part of the development of this protocol the working
> group will produce an analysis of the security
> implications of this architecture.
>
> A secondary 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.
>
> Related Internet-Drafts
>
> Early 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
>
> Goals and Milestones:
>
> Jun 01: Working Group review of OPES Deployment Scenarios
> document.
> Jul 01: Working Group review of callout protocol
> requirements.
> Aug 01: iCAP Protocol document last call.
> Aug 01: Working group review of policy requirements
> document(s).
> Nov 01: Working group review of alternative callout
> protocol.
> Dec 01: Policy requirements document last call.
>
> Michael W. Condry
> Director, Network Edge Technology
Michael W. Condry
Director, Network Edge Technology