ietf-openproxy
[Top] [All Lists]

Re: [ OPES architecture] Final Points of Discussion: Tracing

2002-05-23 11:31:46

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.