At 07:21 3/23/2001 -0800, Michael W. Condry wrote:
Description of Working Group:
The Open Pluggable Edge Service (OPES) working group primary
task is to define a protocol to be used to extend
participating transit intermediaries to incorporate services
executed on application data transported by HTTP and
possibly RTP protocol suite. The protocol provides a framework for
integrating a wide range of services into arbitrary
intermediaries. Intermediaries may employ either local or
remote ("callout") servers to perform a service, and as a
result, the data may be diverted temporarily over a closed
loop pathway different from the transit pathway.
The value of the "remote" or "callout" server is that it can be provisioned
elsewhere on the network, not in the transit pathway.
I may be projecting my own thoughts, but in the meeting we said that SMTP
should be out of scope, since services such as virus checking are typically
provided by the introduction of another SMTP relay (and this notion in SMTP
is well established). Service introduction in HTTP could also be
provisioned within a proxy on the transit path. The use of a callout
server "only" seems to gain you some control over possible loops and the
avoidance of complication of transit pathways.
Intermediary services provided in this way are not
transparent: Either the content requestor or provider will
be aware that a transformation has been performed.
Did we remove the case where the access provider is the one controlling the
transformation?
Also "..the content requestor.. will be aware that a transformation has
been performed". Would this be similar to the notional Warning headers
that I've never seen used in HTTP/1.1? The content consumer may have
requested that services be provided, but when do they know if the trigger
has fired and the transformation has been carried out?
As part of the development of this protocol the working
group will produce an analysis of the security implications
of this architecture.
I'm not too sure how I see this as being different to the security
considerations part of any protocol documents.
The iCAP protocol already provides similar functionality and
this working group may elect to use iCAP as a starting point
for its work. However, the working group is not obliged to
retain any level of compatibility with iCAP.
This paragraph seems redundant. It seems to make more sense to have iCAP
as a draft for consideration within the group, but I'm not sure it belongs
within the charter description text.
Existing Internet-Drafts
Early Requirements document (expired but available on the
web site):
draft-tomlinson-epsfw-00.txt
Updated iCAP Callout Server:
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
Is this section necessary in the charter?
Goals and Milestones:
Apr 01: Consensus on the charter.
Seems an odd milestone to have in a charter proposed for the formation of a
WG...
Jul 01: iCAP Protocol document last call.
But you said you wouldn't be obliged to maintain compatibility with iCAP.
So either you're using the name to mean "something that doesn't look like
iCAP does at the moment" or you mean "we may recharter to change this goal".
Aug 01: Working group review of policy requirements document(s).
Nov 01: Alternative callout protocol review.
This one has me confused too. Why is iCAP being taken to last call if you
also have a review of alternative callout protocols?
I must be missing something?!
Dec 01: Policy requirements document last call