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
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.
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.
> >>> "Michael W. Condry" <condry(_at_)intel(_dot_)com> 03/29/01 11:36AM >>>
> Open Pluggable Edge Services (opes)
> 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):
> Updated iCAP Callout Protocol:
> A Rule Specification Language for Proxy Services:
> OPES Network Taxonomy:
> OPES Architecture for Rule Processing and Service Execution:
> OMML: OPES Meta-data Markup Language:
> General Use Cases:
> Goals and Milestones:
> Jun 01: Working Group review of OPES Deployment Scenarios
> Jul 01: Working Group review of callout protocol
> Aug 01: iCAP Protocol document last call.
> Aug 01: Working group review of policy requirements
> Nov 01: Working group review of alternative callout
> Dec 01: Policy requirements document last call.
> Michael W. Condry
> Director, Network Edge Technology
Michael W. Condry
Director, Network Edge Technology