Re: Major errors in Caching and Cache-Control

>Date: Wed, 5 Jun 1996 13:33:20 -0700 (PDT)
>From: Benjamin Franz <snowhare@netimages.com>
>X-Sender: snowhare@ns.viet.net
>To: jg@w3.org
>Cc: "Roy T. Fielding" <fielding@liege.ics.uci.edu>,
>        Jeffrey Mogul <mogul@pa.dec.com>,
>        http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-wg@cuckoo.hpl.hp.com
>Subject: Re: Major errors in Caching and Cache-Control 
>In-Reply-To: <9606051933.AA13382@zorch.w3.org>
>Message-Id: <Pine.LNX.3.93.960605132045.13252B-100000@ns.viet.net>
>Mime-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>Content-Length: 2780
>
>On Wed, 5 Jun 1996 jg@w3.org wrote:
>
>> There are two issues here:
>> 
>> 1) what content authors can/need to say about how their content
>> might be modified.
>> 
>> 2) what HTTP allows/disallows in the protocol.
>> 
>> To begin with, believing that all web stuff uses HTTP is a mistake;
>> in particular, we'd like to eventually transition to other transport
>> protocols, which may potentially take a more liberal view of content.
>> It seems perfectly reasonable to me, particularly working for an international
>> company as I do, to think that a set of proxies that
>> transformed all GIF files to JPEG before transporting them across the
>> expensive interoceanic links would BE A GOOD THING.  This may very well
>> save me 2X on bandwidth right now.  Not a trivial deal at all.  I'd
>> like my cache to be more efficient as well, and would like to store the
>> data that way.
>
>As a site developer I can tell you that silent content transformation is
>*EVIL*. AOL was converting JPEGs to ART silently this way. Caused one of
>my clients some grief as people on AOL downloaded files with a .jpg ending
>and their viewers puked on it. Fortunately I was aware of the possibility
>that AOL might be doing this and could guide the user in *disabling* the
>JPEG->ART transformation. I am NOT in favor of content transformation
>by proxies in the least. The legal ramifications alone are potentially
>killers.
>
>> It seems to me that the sooner we get "no-transform" into the hands of
>> content authors the ability to say that this data better not be messed
>> with between me and the end user, the better.  I'd sure not want my
>> medical images so messed with.  People will (already are) experimenting
>> with such data transformation in research contexts; wouldn't surprise me
>> (might even take bets on) people doing it for product.
>
>See above.
>
>> I think that "no-transform" is worth having, even if HTTP forbids transformation
>> (for which I think forbidding tranformations would be draconian, and people
>> who run corporate or island cache systems would not thank you for).
>
>I think that transformations *should* be forbidden. You want to break
>protocal inside an organization fine - but don't tempt fate by allowing it
>on the big bad net.

The New Zealand case is a valid example on the big bad net.  If I'm
an ISP on an island, with very expensive bandwidth, I may need to do this,
and may even want to forbid port 80 access from the island (forcing
use of a proxy).
> 
>> Note that adding it later is closing the barn door after the animals escape;
>> we'd like content authors to start now, so that such proxy systems might
>> be deployed in the future, while allowing critical data to be marked.
>
>If this allowed at all, it should be in the affirmative mode: 
>transform-allowed. The default without question should be no content
>transformations allowed unless explicitly stated otherwise. At no point
>should intermediates be allowed to transform content unless I
>affirmatively give them permission to do so.
>

I'd have more sympathy to saying transform-allowed as opposed to no-transform
if it weren't for the following two observations:

1) the default case should be the kind case to the net; transforms can help
on bandwidth usage.  Those that have legal/health/scientific reasons to 
forbid it can do so, but most won't have to worry about it.  Most of the
time it is a good thing.

2) you can't presume that data won't be transformed today; in fact,
the clear experience (yours and others) is that data is being
transformed today, and content providers must presume it is, due to
current practice.

				- Jim

Received on Wednesday, 5 June 1996 13:40:57 UTC