[fitsbits] Start of the FITS MIME type Public Comment Period

[Steve Allen]

On Thu 2004-05-20T11:47:34 -0700, Tim Pearson hath writ:
> I believe that specifying two media types, application/fits and
> image/fits, is confusing and unnecessary. A single type,
> application/fits, should suffice.
>
> The proposal does not provide clear, unambiguous instructions for
> determining whether a given FITS file should be described as
> application/fits or image/fits. The apparent intent of the proposal is
> that the choice of media type should be used to convey information
> about the file that cannot be determined merely by examining the
> contents of the file. I think this is a mistake that will lead to
> confusion and incompatibilities in implementation.
>
> I understand that the authors of the proposal do not agree with me, but
> I think this issue still needs further clarification.

There are other existing MIME types which do not provide unambiguous
instructions for determining what they contain or how to process them.
In particular see

application/applefile
http://www.iana.org/assignments/media-types/application/applefile

multipart/appledouble
http://www.iana.org/assignments/media-types/multipart/appledouble

These two apple MIME types are described by a single document.  In a
way they are like a MEF file which may be intended to convey one
principal image, or which may contain almost any other form of data.
As with FITS, the apple data types were designed to do things far more
general than the simple classifications that MIME provides.

I take the above as an indication that the IANA namespace need not be
conserved so preciously as to inhibit potential users of the MIME
types from doing useful work.  Indications are that the existing usage
of FITS is already so broad that there is no way to provide an
absolutely firm dividing line between what is and is not simply an
image in the MIME sense.

Many FITS files definitely fit the MIME categorization of image, and
my impression is that the VO community would be adversely affected if
image/fits were not registered.

--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla at ucolick.org      Voice: +1 831 459 3046     http://www.ucolick.org/~sla
PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93