[fitsmime] FITS MIME Considerations

[Lucio Chiappetti]

On Tue, 10 Dec 2002, William Pence wrote:

> Since the data are always assumed to be in FITS format, it would be
> redundant to add an extra '.fits' to every filename,

> ad60033000g200270h.evt  (event file)
> xh30216010404_b0c.lc    (light curve)

I agree with Bill (I actually expected him to quote also .rmf (response
matrix files), .arf (ancillary response files) and .pha (spectra) !)

> One current mission that does add a FITS suffix to every filename is
> XMM-Newton,

unfortunately ! But their s/w has been designed more by engineers than
by astronomers :-)

On Tue, 10 Dec 2002, William Thompson wrote:

> The extension of the file should always tell you what the format of
> the file is, i.e. whether it is FITS, CDF, netC$ HDF, etc., or even
> one of the image formats, GIF, JPEG, etc.  I feel very strongly about
> that.

My feeling is opposite. If I go into a library in an English-speaking
country, I do not care to find shelfs labelled as "books in english", but
more by topic, history, fiction, science and so on. So I'd like that the
extension tells me (human user) that the file is a spectrum, an image, a
response matrix.

> This is slightly off topic, except in that one would presume that the
> MIME definition would include references to the typical extensions
> ".fits", ".fi$ and ".fts".

exactly, the only reason this argument is on topic here are those
references ! See below comments on Steve Allen's statements.


On Tue, 10 Dec 2002, Steve Allen wrote:

> All webservers are different, but many share a common heritage with
> the early NCSA code.  In most webservers there is a configuration file
> named mime.types, and this contains lines with each known MIME types
> followed by a list of file extensions that are to be classified as that
> type.

I should know, I still use an NCSA server for my own little private httpd.
Although I did not dare to alter mime.types !

> In current versions of Apache this can be overridden at two levels.
> [...] And there may be per-directory overrides for MIME
> types that use the "AddType" and "ForceType" directives to associate
> any other file extensions with MIME types.

I did use AddType to add features (about CGI's and to treat .html as
.shtml) but again I did not dare to add non-standard types.

I believe there is a third way in Apache ... I just checked in the conf
directory of our new official server and noticed a file called "magic"
(like the /etc/magic of Unix). So I browsed into the Apache documentation
and found it has a module called mod_mime_magic. So it looks like in
principle an httpd server could be configured to use a magic file to tell
what a file is. I also found other things I never bothered to look after,
like "output filters".

After all, there will be many users and browsers and fewer VO sites and
httpd servers, so it is reasonable to suppose that the server
administrators will be more knowledgeable and willing (then the users) to
make custom configurations, and decide that ".xyz" files are FITS images,
".uvw" are tables, and so on.

> Note that the file extension (.fits) indicated by the MIME type
> registration is taken to be advisory, not prescriptive.  Nothing

You mean what is in the RFC is advisory, don't you ? But once it makes
its way to the mime.types or mailcap becomes prescriptive for the server
or the browser !

I believe we should be careful. I presume that if a server (via mime.types
or magic) can identify a ".xyz" file and issue an http header with a
Content-Type of application/fits-whatever, the browser will obey the
Content_Type irrespective of the file extension announced. Is this true ?

We should allow the (few) server administrators the maximum freedom to
associate files with MIME types (specially if there will be many for FITS
variations). At the same time we should prevent the default mailcap of the
(greater number of ) browsers to override the choice of the
administrators.

> certain operating systems provide strong incentives to conform to a
> small list of pre-defined extensions.

That's exactly the nuisance we should avoid. Recently we had to use some
Windows/NT PCs to control the mask cutting machine for the VIMOS
spectrograph, Such PC exchanges "orders" and "reports" with the rest of
the ESO (Unix) system, so we had to devise a file extension naming, and we
found naturally to choose for our files (all ASCII) extensions like mmj,
mij, mdj for the "job orders" and mmt, mir, mdr for the "termination
reports". But for NT some of those types are by default associated to some
other cllickable action ...

> It is my impression that after registering MIME types we will find
> that the config files which come from the webserver vendors will
> associate the ".fits" extension with either "image/fits" or
> "application/fits", and that their choice will depend on the wording
> of the RFC text.

That's why we should be careful. Why should one choose one or the other ?
May be our wording should be as neutral as possible. Or, as you say

> Even if we were to register only two MIME types this will require an
> educational outreach to the FITS community.

----------------------------------------------------------------------------
Lucio Chiappetti - IASF/CNR - via Bassini 15 - I-20133 Milano (Italy)
For more info : http://www.mi.iasf.cnr.it/~lucio/personal.html
----------------------------------------------------------------------------
As of 10 Dec 2002 the Rectors of all Italian Universities resigned to
protest against the cuts to University and Research funds in the 2003
Budget Law.
----------------------------------------------------------------------------