Re: filetype extensions

"Daniel W. Connolly" <>
Date: Tue, 10 May 1994 18:50:25 +0200
Message-id: <>
Precedence: bulk
From: "Daniel W. Connolly" <>
To: Multiple recipients of list <>
Subject: Re: filetype extensions 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

This just goes to show that one must be _very_ careful when sending
to a large audience...

In message <>, Chris Lilley, Computer Graphic
s Unit writes:
>"Daniel W. Connolly" <> said:
>> The latter form will probably work for now... but what about the future
>> when there may be caching proxy servers with built-in graphics conversion?
>> Such a proxy may have image/tiff, and it may be able to generate image/gif
>> faster than going round-trip to the original server.
>Um. If you ask a proxy for foo.gif (or foo with accept image/gif) it is supposed 
>to ask the original server for the expiry and last-modified date to be sure that 
>the version it has is exactly, in every detail, the same as the original.
>Conversion in the manner you suggest negates all this. If the proxy has bar.tif 
>and converts it to bar.gif, it is not necessarily the same as the original 
>servers version. What quantisation algorithm was employed - Heckbert's? Wu's? 
>what colour space? RGB? CXMYK? CIELAB (TIFF supports all of these). How many 
>colours was it quantised to, and is the resolution the same?

Very good point. Now... can we go back in time and pretend that I had said:

	"Assume, for the sake of argument, that this caching server implements
	100% intvertible translation between gif and tiff."

>For people who are text oriented and view images as minor decoration, these 
>differences are inconsequential. But you cannot be certain that the content of
>the image is of so little worth. And plenty of people are using the web to 
>distribute scientific visualisations, medical images, computer graphics for 
>example where these differences are extremely important.

Another good poing. It appears that clients should be able to express
a tolerance (and lack thereof) for information loss in conversion.

>> We must be very careful about time-to-live, conversion quality, etc.
>> to be sure that the proxy servers don't compromise the protocol.
>Indeed. How are you going to specify that the quality does not matter (eg a 
>silly little help icon in xpm and you want it as a gif) or does matter (a 
>medical image) and how much it matters?

Something like:

	Accept: image/gif; t=1.0

The Accept: header already specifies things like how much it costs the client
to deal with the given format, and tolerance on how long it is willing to wait
for a conversion. We just add one that says "my tolerance for information loss
is 1.0, i.e. no information loss is tolerable." For help icons and such, you
would set t=0.9 or so.

To reiterate: we need to be able to put this info _in_the_link_markup_, since
it is not only a function of the client's capabilities, but also of the author's
intent. For example, when I create a link to a help icon, I don't care if a few
color bits here and there get changed. But if I'm linking to a medical image,
I certainly do care!

> If a proxy is supposed to guarantee you 
>get the same result as going direct, then such conversions must be ruled out. 
>And yet, for many purposes, the conversions would be entirely adequate. But let 
>us not rule out certain applications of the web just because many current images 
>are content-free.

I agree with your evidence, but not with your conclusion that _all_
"such conversions must be ruled out." We just need to be careful! Keep
all the issues on the table and allow references to express _exactly_
what they refer to, and how much "slop" they'll tolerate.