This apparently did not make it to the openproxy list, so I am reposting it
there. Sorry if anyone gets duplicates.
/micah
----- Original Message -----
From: "Micah Beck" <mbeck(_at_)ironglass(_dot_)com>
To: "James P. Salsman" <bovik(_at_)best(_dot_)com>;
<ietf-openproxy(_at_)imc(_dot_)org>; "Michael
W. Condry" <condry(_at_)intel(_dot_)com>
Cc: <ietf(_at_)ietf(_dot_)org>
Sent: Wednesday, July 04, 2001 11:38 PM
Subject: Re: OPES charter proposal again.
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
----- Original Message -----
From: "Michael W. Condry" <condry(_at_)intel(_dot_)com>
To: "James P. Salsman" <bovik(_at_)best(_dot_)com>;
<ietf-openproxy(_at_)imc(_dot_)org>
Cc: <ietf(_at_)ietf(_dot_)org>
Sent: Wednesday, July 04, 2001 8:05 PM
Subject: Re: OPES charter proposal again.
out of interest, did any other groups need to have
these restrictions?
At 11:03 PM 7/3/2001 -0700, James P. Salsman wrote:
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
Michael W. Condry
Director, Network Edge Technology