Suppose this clause of the proposed OPES WG charter:

"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."

Were modified to read

"Intermediary services provided in this way are not
transparent: They have to be authorized by the provider."

This would put control of all content transformations back in the hands of
the content provider.  If the end user or the ISP wanted a transformation,
they would have to ask to content provider to authorize it.  This would make
the OPES box purely an extension of the content provider's server, and would
only rule out transformations that the content provider is unwilling to
authorize.

With this modification, the end user can only see services intended by the
provider.  The fact that those services might be provided by a distributed
system that used intermediaries would not compromise integrity.

This would rule out business models based on selling intermediary services
that the content provider refuses to authorize.  It would rule out business
models based on capturing content and transforming it in unintended ways.
It would not rule out any business model that is based on the advise and
consent of the content provider.  Automatic mechanisms for providing such
consent could be used in cases where users are pre-approved for a class of
transformations.

I encourage everyone who is in Boston attending the Web Caching and Content
Delivery Workshop to attend the afternoon panel on Thursday on "Rule-Based
Active Edge Services".

Micah Beck

----- Original Message -----
From: "Keith Moore" <[EMAIL PROTECTED]>
To: "Paul Hoffman / IMC" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, June 19, 2001 9:47 PM
Subject: Re: WG Review: Open Pluggable Edge Services (opes)


>
> > Has everyone who has a reallyreallyreally strong opinion on this
> > matter actually read the charter? Right there near the top, it says:
> >
> > >Intermediary services provided in this way are not transparent:
> > >Either the content requestor or provider will be aware that a
> > >tranformation has been performed.
> >
> > OK, so the spelling is not so great, but it sure is clear. What some
> > people seem to be up in arms about is that the IETF would even think
> > of helping someone change the content in HTTP. Data mungers are doing
> > that already, and it is bad, and it is untraceable. So what should
> > the IETF do?
>
> the IETF SHOULD NOT pretend that the practice does not exist.
>   (*that* would be burying our heads in the sand)
> the IETF SHOULD NOT encourage the practice by making it appear legitimate,
>   even by making the endpoints aware of it.
> the IETF SHOULD (probably) NOT try to interfere with other groups that
>  might want to standardize this; to do so is to risk getting trapped
>  in a herd of lemmings who are bent on jumping off a cliff.
>
> IF, on the other hand, there is a need for pluggable end services
> which are *explicitly requested* by one or more end points, the IETF
> SHOULD consider doing work in this area, but it SHOULD also clearly
> distinguish such work from work that interferes with end-to-end
> transparency.
>
> ELSE, IETF should do nothing.  Sometimes refusing to pretend that your
> action can accomplish anything useful really is the best choice.
>
> > Data is already being changed, some of in ways that we should really
> > be unhappy about, and there is no way for the folks changing it to
> > tell either end. OPES gives them that capability.
>
> no it won't.  OPES is an application-level mechanism and the folks
> who are corrupting data now are doing so at lower layers.  OPES won't
> change what they are doing.
>
> > Post-OPES, data
> > will still get changed silently without using OPES, but at least
> > there can be pressure put on the changers to use OPES so that someone
> > sees what is happening. Without OPES, they never will.
>
> I don't think so.
> Nor do I think this is a worthwhile use of IETF's energies.
>
> Keith
>

Reply via email to