Re: filetype extensions

Daniel W. Connolly (
Tue, 10 May 1994 11:39:27 -0500

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.