LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
July 2008
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2008.07.11 12:56 "Re: eta for bigtiff support?", by Gary Mcgath
Bob Friesenhahn wrote: > On Thu, 10 Jul 2008, Gary McGath wrote: >> 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