dcrocker> Unfortunately, image/gif is in the original Mime spec. And THAT
dcrocker> spec IS on the standards track. **>> That makes the content-types
dcrocker> referenced in it implicitly part of the standard. <<**
dcrocker>
dcrocker> So, if image/gif were merely registered with IANA separately,
dcrocker> there'd be no problem. **>> Having it built into the Mime spec
dcrocker> changes things, I believe. **<<
I disagree with the two statements marked with **>><<**. I'm not sure how to
convince you from your belief, however.
I might put it somewhat differently.
The inclusion of image/gif in the MIME spec amounts to an endorsement
of the GIF image format over other image formats not mentioned in the
MIME spec. Given a choice of how to encode an image, an implementor
might choose GIF because of this endorsement. I don't believe it's
appropriate for IETF to endorse a patented technology, especially when
reasonable alternatives exist.
Moving the image/gif spec out of the MIME document would put image/gif
on an equal footing with other MIME content-types.
dcrocker> Correct, because I guess we didn't realize there was a patent
dcrocker> claim on gif. The IETF standards process documentation very much
dcrocker> DOES have discussion about the question of standardizing patented
dcrocker> technology.
Yes, but we're not standardizing GIF (which is prohibited), we're
standardizing a reference to GIF (which is not). I believe (there's those
two words again! :-) ) that the two are completely different.
I think we're talking about whether to include the image/gif
content-type in the document that defines MIME standard, or to move it
elsewhere.
Perhaps the answer it so not REMOVE image/gif, but to instead add references
to other image types that are NOT encumbered.
This might be seen as requiring that MIME be set back to Proposed
status. By all means let us register unencumbered image
content-types, but let's not delay MIME in the process.
Also, application/postscript is similarly encumbered. Are we going to remove
that as well?
You don't have to use LZW to construct an application/postscript file.
You do have to use LZW to construct a GIF file.
Unisys is said to believe that the LZW patent covers decompression as
well as compression. If that were true, there might be a reason for
MIME to recommend against use of LZW in application/postscript files.
But the whole notion of true/false is pretty hazy when it comes to
patent claims...
--
Keith Moore NETLIB development group
Computer Science Department / University of Tennessee at Knoxville
107 Ayres Hall / Knoxville TN 37996-1301
Let's stamp out software patents in our lifetime.