On Wed, Sep 20, 2000 at 11:03:51AM -0600, Hilarie Orman wrote:
[...]
I'd be quite happy to have application headers contain directives
to intermediaries describing the semantics (esp. "stateless; copyrighted;
cacheable", "multipart; modifiable by insertion", "opaque") and
authorizations
("customizable by enduser", "insertions by brokers"). However, it's more
realistic right now to accomplish this by context, environment, and what
amount to service level agreements about content between
publishers and distributors.
I very much agree. Right now, I think we're at a point where we can try to
get a handle on what's acceptable without some form of negotiation.
I agree that there are problems associated with modifiable content,
but there are also huge advantages. Some things really should look
different depending on where they are in the network. It all depends
on what you mean by content and what the intent of the publisher
is. To take a minor example, in traditional publishing the consumer
doesn't get to specify the color or size of the paper and the text fonts;
with browsers and HTML, the user can override the publisher's
specification. In the physical world, such tricks may well be illegal.
I won't dispute the benefits, but this does break some assumptions in
the HTTP and URI specifications. We need to deal with that.
We need to assure that publishers and consumers can specify and
resolve their rights and preferences in protocols so that intermediaries can
exercise their capabilities in accordance with their expectations.
Here's a more concrete example of the kind of problem I'm talking about:
The W3C's P3P working group is putting together a platform which allows
specification of an XML privacy policy based on a URI. The major mechanism
for this is a metadata file in a well-known location at the origin server
which dictates how policies are applied to resources.
If a proxy inserts ads, rewrites URIs, or does something else to change the
privacy attributes of the resource, the privacy policy is invalid. If the
content provider doesn't know about this, they're making privacy guarantees
for resources that are beyond their control.
P3P is unaware of the potential for modification of an object in the
network, because a URI points to an identifiable resource, and semantic
transparency is assumed in the HTTP.
While the HTTP doesn't specifically forbid lack of transparency, it does put
limitations on how it may happen;
Requirements for performance, availability, and disconnected operation
require us to be able to relax the goal of semantic transparency. The
HTTP/1.1 protocol allows origin servers, caches, and clients to explicitly
reduce transparency when necessary. However, because non-transparent
operation may confuse non-expert users, and might be incompatible with
certain server applications (such as those for ordering merchandise), the
protocol requires that transparency be relaxed
* only by an explicit protocol-level request when relaxed by client or
origin server
* only with an explicit warning to the end user when relaxed by cache or
client
There are many assumptions in efforts like P3P that will break when you
break semantic transparency.
I haven't brought this up in the WG yet, because I wanted to get comments
from this group.
--
Mark Nottingham
http://www.mnot.net/