Subject: RE: WG Review: Open Pluggable Edge Services (opes)

From: "Yang, Lily L" <[email-masked]>
Date: Wed, 20 Jun 2001 10:27:07 -0700

I disagree. Both the content requestor and the provider are the end points.
Why should only the content providers have a say on what adaptation is
allowed? End users are the ultimate content consumers and hence definetely
deserve the right to authorize services on his/her own behalf. It does not
harm to the content on the origin servers and it does not harm to other
users. Why not? 

I agree that the more grey area lies with the service provider. Current
proposal on IRML allows three parties (end users, content providers, access
providers) to authorize rules for service invocation. Maybe it is a good
idea to only allow two end-point parties (end users and content providers)
to authorize service requests via rule modules. Access Provider can provide
choices of different services to its subscribers and allow them to sign up
explicitly if they so choose. Those service requests are then still
explicitly authorized by the end users, while the access provider (ISP) is
merely a service provider/facilitator. 

Lily

> -----Original Message-----
> From: Micah Beck [mailto:[email-masked]]
> Sent: Tuesday, June 19, 2001 8:14 PM
> To: [email-masked]; [email-masked]
> Subject: Re: WG Review: Open Pluggable Edge Services (opes) 
> 
> 
> 
> 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-masked]>
> To: "Paul Hoffman / IMC" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> 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
> >
> 
>

---

From: "Micah Beck" <[email-masked]>
Date: Wed, 20 Jun 2001 15:04:22 -0400

Lily,

> harm to the content on the origin servers and it does not harm to other

It is arguable that the client has the right to have whatever adpatation
they want performed on the content that they view.  However, it enters into
a troublesome area where we obscure what exactly is being provided by the
content provider, although the identity of the content provider is still
used.

Suppose that there is a group that wants their Web site seen only in French,
say because they are advocating the preservation of French as the primary
language is some part of the world.  A community of users could decide to
ask for English language translation and then view their Web site in
English.

You might ask how anyone could object, since the content is being
transformed only on the request of and for the sole purpose of being viewed
by a single "user".  However, it is an easy thing then for the
English-speaking community to then make invocation of the transformation
standard.  The owner of the Web site, seeing it widely displayed in English,
would feel that their intent had been undermined.

I bring up this example just to illustrate the direction things can go when
we build an infrastructure that transforms content and then displays it in a
manner that is not clearly differentiated from the original.  It "seems to
be" the Web site intended by the provider, but perhaps it is not.  Perhaps
displaying a log of transformations not requested by the content provider
would mitigate the problem.

The antidote is of course end-to-end integrity checking that allows the
provider to ensure that transformations to do occur.  Allowing
transformations that are not approved by the content provider may require
the development of such tools.  Frankly, I'm not sure it's worth it.

/micah

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Jun 2001 17:15:56 -0400

> content provider, although the identity of the content provider is still

Micah,

It appears as if you're assuming that the OPES interface has to interpose
that adaptation between the provider and the audience, by usurping
the normal client-to-server interface and obscuring the original content -
probably by some sort of HTTP proxy.  I don't think this is a reasonable
assumption, or a reasonable design constraint.   In fact I would argue
that it is essential that the normal client-to-server interface not be
interfered with, precisely so that the audience has a choice - exposed
in his user interface - regarding whether to enable a particular translation.

For this and several other reasons OPES should defintely NOT be based on HTTP.

Keith

---

From: "Micah Beck" <[email-masked]>
Date: Wed, 20 Jun 2001 21:26:32 -0400

Keith,

I accept what you're saying: if one is going to perform intermediary
services not authorized by the content provider, then one should not usurp
the normal client-to-server interface and obscure the original content.

But wouldn't it be alright to perform intermediary services that do usurp
the normal client-to-server interface as long as they are authorized by the
content provider?  In this case the intermediary is serving as the agent of
the content provider, so it would seem that interposing between client and
server would be OK.

/micah

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Jun 2001 23:00:48 -0400

> content provider? 

there are two separate issues: permission and interface.

I would say that at least one endpoint has to give permission before any
intermediary should modify content.

From the point of view of granting permission, the mechanism is not relevant.
So if (for example) a content-provider wants to implement a service using 
interception proxies that intercept that content-provider's IP addresses, 
and which modify the content obtained from other servers that are maintained
by that content-provider (or with which that content-provider has made
arrangements, whatever), then I view that as strictly an implementation issue.
As long as the interface as viewed from outside of the content-provider's 
domain conforms to the standards, the content-provider should be free to 
implement its services however it wishes.

On the other hand, if you are trying to define a standard interface to a
service that modifies content in arbitrary ways, and particularly one that 
is usable on either the client or the server end, I suspect that it would be 
a poor design choice to base OPES on top of HTTP.  For instance, this 
could make it awkward for the client to enable or disable OPES services
at will; for another, HTTP is already too overloaded from trying to serve
a variety of needs, and doesn't need to be stretched in additional directions 
to accomodate OPES.

I'm not saying it cannot be done; I'm saying that from this (admittedly
cursory) view, it looks like a huge mess.  I might be wrong.  But
I hope that the working group (if chartered) does not presume HTTP as
a solution - either as a substrate or by treating intermediaries as proxies.

Keith

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 21 Jun 2001 10:15:29 -0400

Keith Moore wrote:

> a poor design choice to base OPES on top of HTTP.  

Not sure whether there's a misunderstanding - the proposed OPES work
is NOT based on top of HTTP. It is meant that OPES, in a first step,
would focus on services for HTTP-based transactions (and possible
other protocols later on). This does NOT mean that the protocols to be
worked on would be based on top of HTTP.

-Markus

---

From: "Lee Rafalow" <[email-masked]>
Date: Thu, 21 Jun 2001 13:22:28 -0400

> There seems to be consensus that OPES services would have to be
> authorized explicitly and must not be transparent to both end-points.
> This is in line with the discussion we had at the OPES BOF in
> Minneapolis and is also reflected in the group description on the web
> page ("Intermediary services provided in this way are not transparent:
> They have to be authorized by either the content requester or the
> provider, corresponding to who the service being provided for"). Looks
> like this should be made explicit in a charter.

The charter currenting has OPES first working on a callout services protocol
and the requirements for the policies that control the system.  The
implication is that the policies don't get real work until the group is
rechartered.  Given the nature of these discussions and this emerging
consensus, is this portion of the charter in need of some attention?

Lee M. Rafalow
Voice: 1-919-254-4455, Fax: 1-919-254-6243
IBM Internet Technology Management
IBM Corporation
P.O. Box 12195, BRQA/502
RTP, NC 27709 USA
Alternate email: [email-masked]
Personal email: [email-masked]