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.