Subject: Re: OPES charter proposal again.

From: "James P. Salsman" <[email-masked]>
Date: Tue, 3 Jul 2001 23:03:48 -0700 (PDT)

I hope that the latest attempt at the OPES charter is resoundingly 
rejected by the IESG.

If it is not, though, I would suggest these three special requirements 
for an OPES working group:

1. The Security Considerations section could be required to be placed 
at the front of all OPES drafts, following the legend, "This OPES 
working group publication is required to have a Security Considerations 
section that meets certain requirements [cite BCP].  Readers are 
encouraged to confirm for themselves that the Security Considerations
section requirements have been met."

2. Another section, "Ethics Considerations," could follow immediatly 
thereafter, and explore the ethical implications of the technology 
being described, in terms of privacy, disclosure and other terms of 
service requirments, and impacts upon common carrier feasability.

3. A third section, "Legal Considerations," could survey and cite the 
laws that could be inadvertently violated by careless implementation 
or use of the technology described, such as the U.S.'s Electronics 
Communications Privacy Act.

Cheers,
James

---

From: Dave Crocker <[email-masked]>
Date: Wed, 04 Jul 2001 00:36:03 -0700

>I hope that the latest attempt at the OPES charter is resoundingly

The key task statement in the opening paragraph of the draft proposal is:

         "define application-level protocols enabling such intermediaries 
to incorporate services that operate on messages transported by HTTP and 
RTP/RTSP."

"Incorporate services" is vague.  Or rather, it says nothing useful.  The 
opening paragraph of a charter is to be widely distributed, to help people 
decide what a working group is doing and whether it is relevant to one's 
own work.

The current proposal language is frankly a Rorschach for anyone with any 
HTTP-related activity that might involve an intermediary.

Later language in the draft do not assuage this fear:

         "protocols to be defined provide a framework for integrating a 
wide range of services".

Specifics (or even examples) are not provided.

Honest.  In spite of considerable experience writing and reading IETF 
charters, I can not tell what problem is to be solved, never mind how.

d/

Addendum  #1:

         Either as an minor irritation, or as a major demonstration of 
deception -- and I can't quite decide which -- the iCAP web page 
<http://www.i-cap.org/> uses the IETF logo in a fashion that can easily be 
taken to imply IETF endorsement for 
<http://search.ietf.org/internet-drafts/draft-elson-opes-icap-01.txt>.

Addendum #2:

         Isn't an implied promise to integrate HTTP and RTP/RTSP rather 
ambitious?

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: "Michael W. Condry" <[email-masked]>
Date: Wed, 04 Jul 2001 17:05:51 -0700

out of interest, did any other groups need to have
these restrictions?
>Communications Privacy Act.

Michael W. Condry
Director,  Network Edge Technology

---

From: "Micah Beck" <[email-masked]>
Date: Wed, 4 Jul 2001 23:38:03 -0400

I would suggest to the advocates of the OPES working group that they
reconsider the modification I suggested to the charter a while ago, and
which generated almost no discussion:

Modify

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

to read

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

To those who see no reason for such a restriction, I suggest that it might
server to address the sort of reaction you see from James Salsman in the
note below.  If you think that reaction is unreasonable, that won't matter
if it is widely enough held to keep the working group from getting chartered
or establishing consensus on anything.

To those who want a more reasoned response to why this a good proposal, I
offer this:

1. If the transformations being proposed are advantageous to the client and
not harmful to the content provider, then any reasonable content provider
should agree to them.  If the cost of contacting the original content
provider is prohibitive, then the content provider can authorize an agent to
act on their behalf, and that agent can reside in the OPES box.  They can
even issue a blanket authorization, authorizing all transformations
requested by the end user.  The architecture is almost identical to that
being currently proposed, except it is under the control of the content
provider.  The fact that the OPES charter explicitly allows transformations
that are not authorized by the content provider looks suspicous if not
downright dangerous to some people.  Why cut them out unless you think that
they will not want their content transformed?

2. Of courese, the client can capture content from the browser and transform
it locally, or can write their own browser that performs local
transformations (Mozilla is now open sources, after all).  While that is
true, the provisioning of transformations in the network violates a common
assumption among end-users of content that the network is transparent and
that they are recieving content as the provider intended.  It is well
established that end users can do some things with content on a personal
basis (like sharing MP3 files) without fear of prosecution but conspiring
with them to do it within a community is either illegal or immoral,
depending on who you talk to.  Transformation of content in the network
without the authorization of the content provider can be a power tool for
using content in ways never forseen by the content provider.

As I understand it, this proposal satisfies neither the people who want to
create a market for user-directed transformation of content, nor the people
who want to keep all transformations out of the server-to-browser path.  My
questions are these:

1. Would this proposal accomplish a significant part of what the advocates
of an OPES working group are trying to achieve?

2. Would this proposal satisfy the people who are dead set against OPES
because of the danger of transformations that go against the intentions of
the content provider?  Would anyone still find OPES dangerous to content
providers or end users if the charter were modified in this way?

The current discussions on OPES are focusing almost exclusively on iCAP, and
I fear that those who are dead-set against out of fear that it allows
content to be misappropriated may simply dig in their heels since their
fears are not being addressed.  If transformations that are purely
client-directed are really needed, it would be possible to try and extend
the charter to include them later.

Perhaps I am misreading the politics here, and my proposal is either
unnecessary or inadequate.  Perhaps someone could at least explain why.

Micah Beck
Research Associate Professor, University of Tennessee
Chief Scientist, Lokomo Systems

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Jul 2001 09:38:01 -0500

Micah,

> transparent: They have to be authorized by the provider."

I disagree. It isn't acceptable to remove the requestor from
the authorization loop in the general case.

   Brian