- From: <jg@w3.org>
- Date: Wed, 05 Jun 96 15:33:20 -0400
- 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
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 transforms. - Jim
Received on Wednesday, 5 June 1996 12:36:36 UTC