2008.07.11 12:56 "Re: [Tiff] eta for bigtiff support?", by Gary McGath

There's still the open issue of the MIME type, which was discussed a while back and then dropped. As I read IETF RFC 3302 (http://www.ietf.org/rfc/rfc3302.txt), "image/tiff" is defined in terms of TIFF 6.0 conformity, so it would be incorrect to refer to a BigTIFF document as "image/tiff". IANA has also registered a MIME type "image/tiff-fx" for TIFF-FX, defined by RFC 3950, so it would be consistent to shoot for "image/tiff-big". IANA requires "publication by a formal standards body," though, so it would be more realistic to stake out "image/x-tiff-big".

This is closely related to the file extension issue. If the file extension used is similar to existing TIFF (as many here seem to prefer), then the only way to determine its type is by inspecting the file header.

Updated file formats do not always obtain new file extensions or MIME types. BMP, Postscript, and PDF are excellent examples of this.

MIME types are rather fuzzy in practice. IANA doesn't list "image/bmp"
as a MIME type, though it's widely used. "application/pdf" is defined by

RFC 3778 and refers to PDF 1.5, which is one version behind. The listing for "application/postscript" refers only to a couple of RFC's which aren't about defining PostScript. For "application/msword" we have 'Specification by example: From any microsoft word application select "Save As..." from the "File" menu. Enter a filename, make sure that "Normal" is specified for the file type, and click "Save".' Aaarrrrgggghhh!!!!

So the world won't collapse whatever choice is adopted. But I still
maintain that replacing "42" with "43" is a fundamental, incompatible
change, reinforced by the simple but pervasive differences in structure,
so BigTIFF should have its own MIME type.

My own inclination is to continue using the existing TIFF file extensions and TIFF MIME type and let the end applications and users figure things out. If users start having problems with opening files, then they will complain to their application vendor so that the updated format is supported.

If TIFF is defined by TIFF 6.0 conformity then many existing TIFF files do not conform. For example, JPEG compression in TIFF does not conform.

I'd have to look that one up, but doesn't it use extensibility
mechanisms which are consistent with 6.0?

--
Gary McGath
Digital Library Software Engineer
Harvard University Library Office for Information Systems
http://hul.harvard.edu/~gary/index.html