W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: Major errors in Caching and Cache-Control

From: <jg@w3.org>
Date: Wed, 05 Jun 96 15:33:20 -0400
Message-Id: <9606051933.AA13382@zorch.w3.org>
To: "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU>
Cc: Jeffrey Mogul <mogul@pa.dec.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, jg@w3.org
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/801
Sorry I've been so quiet today, my ISP has been losing big time, and
I happened to have decided to work from home today.
 is me
> is Roy
>> is Jeff

				- Jim

>>    "no-transform"
>>       is completely wrong because it talks about content codings
>>       in a way that only transfer codings are allowed to behave, and
>>       thus CONTRADICTS other sections.  THIS IS FATAL (and isn't needed).
>> Please discuss the wording with the Digest Authentication folks,
>> who believed that this was a necessary feature.
>The whole concept is wrong -- no cache is ever allowed to change the
>entity content-coding.  The only thing allowed is transfer coding
>between hops, and that won't affect digest.

Roy, you are taking too limited a view about no-transform.

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.

With your New Zealand background, I think you might think this a GOOD
THING as well. (maybe not, but the example is valid).

Now, independent of whether HTTP/1.1 does or does not forbid the
transformation of objects being transferred, or storage of such objects
in caches, content authors have valid reasons (for example, the datatype
may be being used for mission critical, health or scientific use) where such
transformations MUST be forbidden; and the transformations may not be
taking place in the context of HTTP at all (some cooperative cache systems
may very well not use HTTP.

I personally think that forbidding transformations in the context
of HTTP is probably a mistake, but well see what consensus, if any, there
may be in the WG.

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.

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).

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.

We have to get the text right for whatever we decide, but I think
no-transform is a very good idea (and I remember having discussions with
others who thought it was as well), independent of transformation being
allowed in HTTP/1.1

Here is another example of why transformation might be a good idea:

I have a PDA, that might have a low res, 4 bit display.  I'd like to
be able to use unmodified HTTP, and use it with a proxey cache.  BTW,
it has low bandwidth.

I suspect you'd like to be able to transform the data into as compact
a representation (and maybe even lower the resolution) before the data
has to be transfered over the low bandwidth link.  If we get content
negotiation right for screen resolution (someday), the system might
even figure out the right thing to do on the fly to transform the data
into the compact, low res version optimal for the device.

My personal opinion is that no-transform should stay, even if HTTP forbids 
					- Jim
Received on Wednesday, 5 June 1996 12:36:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC