[Top] [All Lists]

Re: Charter updates, changes, etc.

2001-03-23 17:47:13
At 08:13 AM 3/23/2001 -0800, Ian Cooper wrote:
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 thought that was clear it was out of the transit pathway. What's confusing?

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.

Ian, yes SMTP was out of scope. Just how do you read it in?

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?

Do you mean a service done by the access provider to enable the endpoints?
Like Ad-insertion, done by the access provider to provide reduced cost
service to the consumer. I think this is a very touchy area that needs
requirements to spell it cases of acceptability.

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?

Methodology for this policy space has not been considered yet. THere is
going to be a partition between business practices and policy/protocol issues.

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.

I think that Hilarie's point is quit interesting and worth discussing.

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.

lets see what other's think.

Existing Internet-Drafts
Early Requirements document (expired but available on the
web site):
Updated iCAP Callout Server:
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:

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

Michael W. Condry
Director, Network Edge Technology

<Prev in Thread] Current Thread [Next in Thread>