Subject: Charter issues

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Thu, 10 Apr 2003 16:21:12 -0600

Are we defining standards that apply to any content transforming
proxy, even those which do not use a callout protocol?  Such an entity
might be known as an "IETF standard OPES processor"? From our charter,
I would guess that this is true, and that the callout protocol is a
minor part of the work.  However, I'd never really thought of it that
way - we've done so little on authorization, reversibility, "end-to-end"
encryption, policy specification, control by endpoints, tracking,
traceability, etc. that it would be difficult for someone to tell whether
or not a particular content-transforming proxy was "IETF compliant" or not.
Should we be working on this?

My impression was that we would have guidelines, but the only thing that
would really be standardized would be a callout protocol and tracing
support.  What's the group opinion?

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 10 Apr 2003 17:25:18 -0600 (MDT)

On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote:

> proxy, even those which do not use a callout protocol?

Some of our standards will apply to content transforming proxies
(OPES processors) that do not use OCP.

> Such an entity
> might be known as an "IETF standard OPES processor"?

Something like that. Just "OPES processor" is probably sufficient.

> From our charter, I would guess that this is true, and that the
> callout protocol is a minor part of the work.

The same conclusion can be derived from already published drafts.

> we've done so little on authorization, reversibility, "end-to-end"

"OPES compliant". IETF may have other standards related to
content-transforming proxies.

It is impossible to tell right now whether something is OPES
compliant, of course.

- tracing: We have made very good progress on tracing (IMO, most major
decisions either have been made or have known options to chose from).
Abbie is already working on the second revision of the draft that will
cover tracing (at least).
- We talked about authorization a little bit (its bypass form)
- I am not sure what reversibility is.
- "end-to-end" encryption seems to be out of scope
- policy specification is out of scope if you mean "privacy policy
	specification"
- control by endpoints: same as authorization?

> Should we be working on this?

Yes, and we are.

> My impression was that we would have guidelines, but the only thing
> that would really be standardized would be a callout protocol and
> tracing support.  What's the group opinion?

and bypass (or other form(s) of authorization)

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 10 Apr 2003 22:20:29 -0400

> proxy, even those which do not use a callout protocol?  

We're chartered to define two things: a "callout protocol" and a 
"rules specification method". Obviously, the former applies only to 
services using a callout, the later also applies to services that 
don't use a callout.

We're further chartered to "draft [a] high-level, overall example OPES 
architecture", which is different from "defining a standard".

> minor part of the work.  

The "high-level, overall example OPES architecture" we're chartered to 
*draft* certainly includes this possibility, but I don't see us 
chartered to *standardize* it. The draft architecture is expected to 
only set the stage for the callout protocol and the rules 
specification method.

 > However, I'd never really thought of it that

I'd say we need to work on this to the extend that we must understand 
the implications coming from that for (a) the callout protocol and (b) 
the rules specification method.

> support.  What's the group opinion?

I agree with you, but in addition we're also chartered to standardize 
the rules specification method.

-Markus

---

From: jfcm <[email-masked]>
Date: Sat, 12 Apr 2003 12:13:09 +0200

>support.  What's the group opinion?

As indicated several times I consider that the callout protocol is NO part 
of the OPES concept. It is a convenient way for Service providers to 
operate WITHIN the common processing of an OPES. If the callout protocol is 
above transportation layers it can be a framework for inter service 
applications. If there are transport layers proposing faster, more secure 
and more efficient solutions than TCP/IP this will be of interest to create 
"network black hole" provinding a faster, more secure and more efficient 
service than TCP/IP.

All the issues you point out are far more important as far as service 
operations and provisions are concerned. And, again, their organization 
depend very much on an OPES/ONES modelization first. As pointed out still 
recently the model we use (dispatcher/call-out protocol/call-out servers) 
can only be a part of the OPES chain, even when this architecture is used, 
because both ends can use it. This would create already a daisy chaining 
and the temptation of a direct call-out relation between these two, without 
getting down at http; smtp etc. protocol.

I feel this results from the "proxy" image whch made the proxy server to be 
considered as a front-end dispatcher, ie performing an OPES level of tasks 
(hence the OPES Procesor wording as a machine in front of the Content 
Server). A true architecture is dasy chaining along the transport or 
querry/response path. With all the points you rise. IMHO at least.
jfc