Despite significant effort from the FITS MIME working group, this draft still deserves much discussion and evolution. The Virtual Observatory communities may not have had sufficient chance to review it.
binaryand some media types that include some kind of compression into the MIME media type. For example:
binaryis not one of the top level MIME media types defined by RFCs 2046 and 2077.
gzipshould not be part of a media type. It can, however, be a HTTP content-coding or a HTTP transfer-coding.
(Note that there is no standard means for indicating that a FITS file being transferred by e-mail has been compressed. This is a known omission in the MIME standard. The issue has been adequately addressed by the standard for HTTP, but for e-mail it must await an RFC which revises MIME.)
When Don Wells originally suggested MIME for FITS he suggested
registering four media types:
After some discussion on the fitsmime mailing
list it was evident that the FITS community and FITS file
authoring software simply do not distinguish FITS files into such
subsets. It was decided to register only
The large list of unofficial MIME media types already in use suggests that there are other sorts of classification of FITS files that could be useful, but the discussion of the mailing list indicates that such classifications should be done within the context of FITS itself by adding new reserved keywords and values to the standard.
application. Therefore this will be the catch-all MIME media type, and any FITS file may use it.
image/fitsto have additional HDUs containing table and image information is to accommodate the WCS notions embodied in the drafts of WCS papers III (the
-TABnon-linear algorithm) and IV (distortions described by interpolation). While such FITS files are more complex than the original PHDU described by Wells et al., the intent of such files is still to communicate a single image and its characteristics.
image/fits to be used for files of dimension
other than two is somewhat dogmatic. Nevertheless, it is arbitrary to
image/fits to truly two-dimensional PHDUs. Even
for such files a FITS-viewing application has many more
responsibilities than, e.g., a GIF viewer. Among these are checking
for single-pixel axes in a PHDU with NAXIS greater than 2 and
supplying a color map.
Here is a half-baked idea about new reserved keywords and their conventional values that might or might not be useful.
The original typing mechanism in most webservers was that a single
configuration file (typically named
maintained by the webmaster provided pairs of MIME media types and
file extensions. Use of this old mechanism could mean that all files
.fits would become either
application/fits. The choice
would depend on the preferences of the vendor of the webserver,
possibly as modified by webmaster.
Given that the Internet Draft proposes two different media types, the
MIME media type of FITS files might vary on a file-by-file basis. For
that reason it would likely be necessary to use the mechanisms
provided by newer webservers which permit the individual user who
publishes a file to indicate the MIME media type of each file. In the
case of the Apache webserver this would be done using
ForceType directives issued in the
.htaccess file of
a served directory. Note, however, that Apache does not provide a
means for giving individual MIME media types to individual files.
Other webservers do provide such means, but that is at odds with the
widespread presumption that MIME media type and extension correspond
There is an existing example of FITS being used as a wrapper to transport hierarchical directories containing and describing files of arbitrary MIME media type. This is FITSUTIL by Zarate, Tody and Seaman which is available as an external IRAF package.
Clearly it would be possible to use the FITSUTIL
fgwrite functions in a system which would
automatically unpack and execute files of any suitable MIME type.
Clearly this would be a bad idea, but it is not impossible.
Partly these would be examples of the unsolved problems of FITS semantics, but moreso they could be guides for implementors who might want to teach their applications to display more kinds of data. There are undoubtedly other documents pertaining to various sorts of FITS usage which would deserve to be mentioned. Alas, the problem with all of them is that they are not solved problems. Their writeups are not in locations that are citeable in any permanent sense. As such, I do not believe that it is appropriate for the RFC to include references to them.