Re: OPES charter proposal again.
Sorry for being brief. At 01:11 AM 7/5/2001 +0100, Lloyd Wood wrote: On Wed, 4 Jul 2001, Michael W. Condry wrote: If the working group wants to endorse iCAP I will discuss this with ECMA I'm lost. What working group? The working group below refers to the group of people participating in the proposed working group OPES. - HOWEVER, team members have made it clear that an ECMA vs IETF game is not desired. If ECMA honors the IETF process then they will do that otherwise I doubt if OPES team members will bother working on cleaning up iCAP as they have been doing recently. I'm lost. who is this 'team'? The team is the people interested in the OPES concepts that have been attending the BOFs and interim meetings. L. and is standards lobbying taking a backseat to protocol revision? [EMAIL PROTECTED]PGPhttp://www.ee.surrey.ac.uk/Personal/L.Wood/ Michael W. Condry Director, Network Edge Technology
RE: OPES charter proposal again.
At 21:43 7/4/2001 -0700, Tomlinson, Gary wrote: On Wednesday, July 04, 2001 @5:06 PM Michael W. Condry wrote: 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: This is a most unusual request. In fact, I have no idea where you are coming from. 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. And why would this be? It is recognized by OPES that security is a fundamental issue to be addressed. Please read the current charter. In that case the documents should self-reference the group's own security considerations document at the start of other work, to ensure (so far as possible) that folks are aware of the issues surrounding any protocols and deployment of the systems. 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. OPES services MUST be authorized by the party they are being provided for. How can this not be ethical? I think the key in James's point there is disclosure. Remember, once an OPES device is present in the network it's all too easy for the network operator to install a new service and flick the yeah, yeah, all my users agreed to let me do this switches. 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. This one is even more puzzling. OPES services acting in behalf of clients MUST be authorized by them. Such a OPES service may in fact improve privacy from those over aggressive cookie trackers. Bad choice of example perhaps - a clueful end user can easily disable use of cookies at all or select sites. I may prefer to keep my state with me, rather than letting my network provider hold it for me. (And of course, taking my state with me lets me change network providers without having to get that state transferred to the new network provider...) Anyhow, with respect to legal considerations and authorization - even if an end user has said that an intermediary system can change the format of a page I think you'd still be in a slightly awkward position wrt. copyright - especially if you stored that transcoding for use by others. Cheers, James Michael W. Condry Director, Network Edge Technology An area many seem to forget about in these diatribes is the Enterprise (intranets). These are wholly contained within an Administrative Domain which renders most if not all the issues raised above irrelevant. I'm not so sure. From memory the use cases that have been provided would seem to be nonexistent in a closed environment. Where an enterprise network meets the Internet there may be some uses - but that then gets back to the issues of ethics and law. Sure, it's the enterprise's network. But in some territories they're only allowed to snoop things so far. Heck, with the right configuration an enterprise could certainly make things very interesting for employees making used of web-based email systems in the office.
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
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 [EMAIL PROTECTED] To: James P. Salsman [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] 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
RE: OPES charter proposal again.
On Wednesday, July 04, 2001 @5:06 PM Michael W. Condry wrote: 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: This is a most unusual request. In fact, I have no idea where you are coming from. 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. And why would this be? It is recognized by OPES that security is a fundamental issue to be addressed. Please read the current charter. 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. OPES services MUST be authorized by the party they are being provided for. How can this not be ethical? 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. This one is even more puzzling. OPES services acting in behalf of clients MUST be authorized by them. Such a OPES service may in fact improve privacy from those over aggressive cookie trackers. Cheers, James Michael W. Condry Director, Network Edge Technology An area many seem to forget about in these diatribes is the Enterprise (intranets). These are wholly contained within an Administrative Domain which renders most if not all the issues raised above irrelevant. Sorry for the harsh reply, but this proposal went over my piling on limit. Gary
Re: OPES charter proposal again.
At 04:40 PM 7/3/2001 -0500, Brian E Carpenter wrote: Michael W. Condry wrote: At 02:45 AM 7/3/2001 +0100, Lloyd Wood wrote: I do like the 'extend [..] the iCAP protocol without being obliged to retain any level of compatibility with the current iCAP proposal.' Fine, since iCAP's just an individual draft -- but isn't extending without being compatible something only Microsoft is generally regarded as being capable of doing? That is not the intent. The intent is that the IETF process will be followed with regard to iCAP (not some other organization's process). Not ECMA's, for example? Brian ECMAs gives the appearance of a rubber stamp for i-CAP Forum. If this is completely true it is disappointing because the members attending the OPES meetings have certainly given some effort to clean up the iCAP bugs. Its not clear this is totally true but we will see Michael W. Condry Director, Network Edge Technology
Re: OPES charter proposal again.
At 2:45 AM +0100 7/3/01, Lloyd Wood wrote: I do like the 'extend [..] the iCAP protocol without being obliged to retain any level of compatibility with the current iCAP proposal.' Fine, since iCAP's just an individual draft -- but isn't extending without being compatible something only Microsoft is generally regarded as being capable of doing? No, we have done it with SSL-TLS, S/MIMEv2-S/MIMEv3, PGPorig-OpenPGP, vCalendar-iCalendar, and so on. --Paul Hoffman, Director --Internet Mail Consortium
