Return-Path: <tiff-bounces@lists.maptools.org>
Delivered-To: info@awaresystems.be
Received: (qmail 25655 invoked from network); 11 Jul 2008 12:59:25 -0000
Received: from cheryl.telenet-ops.be ([195.130.136.3])
          (envelope-sender <tiff-bounces@lists.maptools.org>)
          by angelia.telenet-ops.be (qmail-ldap-1.03) with SMTP
          for <info@awaresystems.be>; 11 Jul 2008 12:59:25 -0000
Received: from waldo.telenet-ops.be (waldo.telenet-ops.be [195.130.136.10])
	by cheryl.telenet-ops.be (8.13.1/8.13.1) with ESMTP id m6BCxPh5031281
	for <info@awaresystems.be>; Fri, 11 Jul 2008 14:59:25 +0200
Received: from localhost (localhost.localdomain [127.0.0.1])
	by waldo.telenet-ops.be (Postfix) with SMTP id 73AE51C004
	for <info@awaresystems.be>; Fri, 11 Jul 2008 14:59:25 +0200 (CEST)
Received: from ladon.telenet-ops.be (ladon.telenet-ops.be [195.130.132.50])
	by waldo.telenet-ops.be (Postfix) with ESMTP id 6DFE11C009
	for <info@awaresystems.be>; Fri, 11 Jul 2008 14:59:25 +0200 (CEST)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153])
	by ladon.telenet-ops.be (Postfix) with ESMTP id 089F6312787
	for <info@awaresystems.be>; Fri, 11 Jul 2008 14:59:24 +0200 (CEST)
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id m6BCuCJF017860;
	Fri, 11 Jul 2008 08:57:44 -0400
Received: from hulmail.harvard.edu (hulmail.harvard.edu [128.103.151.245])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id m6BCuAv8017857
	for <tiff@lists.maptools.org>; Fri, 11 Jul 2008 08:56:11 -0400
Received: from [127.0.0.1] ([128.103.151.152])
	by hulmail.harvard.edu (8.13.1/8.13.1) with ESMTP id m6BCvNlb030441;
	Fri, 11 Jul 2008 08:57:24 -0400
Message-ID: <48775868.806@hulmail.harvard.edu>
Date: Fri, 11 Jul 2008 08:56:08 -0400
From: Gary McGath <gary@hulmail.harvard.edu>
User-Agent: Thunderbird 1.5.0.14 (Windows/20071210)
MIME-Version: 1.0
To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
Subject: Re: [Tiff] eta for bigtiff support?
References: <200807031431.m63EVhmX002848@duke.maptools.org><486CE917.9040308@hulmail.harvard.edu>
	<486CF00A.7040905@pobox.com>
	<7800565F56E246818EED8FF70E0000C5@awarec74cb3e1c>
	<4876841C.90608@hulmail.harvard.edu>
	<Pine.SOC.4.64.0807101809320.1058@freddy.simplesystems.org>
In-Reply-To: <Pine.SOC.4.64.0807101809320.1058@freddy.simplesystems.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Tiff List <tiff@lists.maptools.org>
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-SpamCatcher-Score: 50 [XX]

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

_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
