![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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.com> To: "James P. Salsman" <bovik at best.com>; <ietf-openproxy at imc.org> Cc: <ietf at ietf.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 > > > >
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.