Hmmm.
Does this mean that a source can block ANY transformation? The concept
"breaks" the Internet model of "bits are bits". The good news is that it is
impossible to enforce such a request. An end-point is an end-point. Unless
we go the way of the DMCA and end up pressuring hardware manufacturers to
physically block the execution of transformation code...
Where the model may work is if we assume it operates like the US Patent
system. I can patent something, like the use of aspirin to cure cancer.
There is NOTHING to stop someone from buying aspirin for relieving a
headache and then using it to cure their own cancer (the "bits are bits"
reality). However, my patent would prevent someone from PROVIDING a cure
for cancer using asprin.
Given the impossibility of enforcing a "do not OPES" indicator, but there
being some utility of requesting "no OPES, please", can we make this an
informational indicator, if we need it at all?
-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of John
Morris
Sent: Thursday, May 23, 2002 2:32 PM
To: The Purple Streak (Hilarie Orman)
Cc: OPES Group
Subject: Re: [ OPES architecture] Final Points of Discussion: Tracing
At least some content providers are going to want this capability for
reasons other than an after-the-fact forensic analysis.
Hypothetically, a big content site that offers both (a) free web
based content, AND (b) a fee-based option to get the same content in
a low-bandwidth wireless-friendly format, might want to block an end
user from getting a third party OPES wireless-reformatter to make the
conversion.
Even though I personally am not thrilled about that hypothetical
situation, I think it is very plausible, and one that should concern
OPES intermediaries. A site could easily, in its terms of service or
other clipwrap agreement, limit a user's license to view content to
only a single format. At least arguably, if an OPES intermediary
then transforms the content into a different format, the site might
have a claim against the intermediary.
Stated more generally, I can easily see situations in which an OPES
intermediary would want to (or would be required to) have the
abililty to allow either primary party to veto a planned OPES
transformation. In many (but not all) cases, the end user might be
able to exercise this veto simply by discarding the OPESized content.
The approach that Markus suggests could give the content provider a
similar veto (assuming the OPES intermediary honored the primary
party's veto).
To be clear, there are lots of arguments why a content provider
should not be able to control how the user transforms the delivered
content. But content owners are certainly going to want that
capability, and the IAB discussed some reasons why that capability
might in some cases be appropriate.
One alternative would be for OPES dispatchers to recognize a blanket
"DO NOT OPES" flag on content received from content providers. But
if that is the only option a content provider has, we could see an
unnecessarily high number of such flags on content (thereby
marginalizing the client-centric OPES service market).
John
At 11:40 AM -0600 5/23/02, The Purple Streak (Hilarie Orman) wrote:
I can see this as being an option for debugging, but making it
mandantory for use in forensic analysis of "inappropriateness"
by end users is simply outside the scope of protocol development.
Hilarie
Markus Hofmann wrote:
John Morris wrote:
Unless I've missed something (which is certainly possible), the
draft may want to suggest how the OPES architecture will respond
to the following IAB consideration:
(3.1) Notification: The overall OPES framework needs to assist
content providers in detecting and responding to client-centric
actions by OPES intermediaries that are deemed inappropriate by the
content provider.
Section 2.6 of the draft should extend to include some form of
notification of the OPES action to the originating party *when
requested* by the originating party. Implicit notification
mechanisms would not scale, but a content provider should be able
to explicitly request notification in some form.