[fitsmime] How it works

[Steve Allen]

On Tue 2002-12-10T13:49:41 +0100, Lucio Chiappetti hath writ:
> But the common feeling is that asking to configure one's browser is "too
> much" for the generic user. At least that was the feeling in the case of
> our early AVO project, and it has still been the case recently in some
> other more dedicated contexts.  A colleague comes to me and says "how can
> the generic user automatically do this to such a file" and I say "he has
> to place this in his own .mailcap" and he says "no, that's too much,
> nobody will do it".

If most users are using web-based mailreaders, and if the MIME type is
registered, then I strongly suspect the association between image/fits
and an application that can view it will be made by a number of vendors.
Read on to see why I believe this.

> We'd also need some WIDESPREAD SUPPORT at server level. Ideally what one'd
> want would be to write an HTML page on one's server containing something
> like
>
>   <A HREF=myfile.mytype>This is a FITS file</a>
>
> and having the user at the other end in the browser click on it and have
> the appropriate action (view a FITS image, view as text a FITS table, save
> to disk a generic FITS file)

> What we'd need is to have a mechanism at server level which issues the
> appropriate Content-Type header without the need of a CGI.

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.

In current versions of Apache this can be overridden at two levels.
The name of the file may be other than "mime.types" as specified by
the "TypesConfig" directive.  (This is the same mechanism used by many
mail user agents.)  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.

Addressing the "WIDESPREAD SUPPORT" issue, I can vouch that getting a
MIME type registered with the IANA is sufficient to get a MIME type
included into the next release of the "mime.types" file from most
vendors.  I know this because I am already the author of a
registration document on file with the IANA as MIME type "text/vnd.abc".
Shortly after this type was registered it began appearing in the
"mime.types" file for many webservers.

However, the Apache entry for "text/vnd.abc" contains a null list of
file extensions; i.e., ".abc" is not defaulted to be one of our files.
There is no other registered MIME type which asserts ".abc" as the
file extension.  Nevertheless, I believe that the Apache authors
consider abc files to be quite rare, and that they are unwilling to be
seen awarding such a prime piece of namespace to us -- especially when
they have provided a per-directory override that permits lowly webpage
authors to modify the system defaults.  I suspect that ".fits" (and
any other commonly used extensions that are mentioned by the RFC) is
much more likely to be found in future releases of Apache.

Note that the file extension (.fits) indicated by the MIME type
registration is taken to be advisory, not prescriptive.  Nothing
prevents you from using your own file naming scheme, but certain
operating systems provide strong incentives to conform to a small list
of pre-defined extensions.

> For the rest I consider three basic types
>
>   images : image/fits or application/fits-image
>
>   tables : text/fits (!) or application/fits-table and/or
>            application/fits-bintable
>
>   generic : application/fits

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.

Even if we were to register only two MIME types this will require an
educational outreach to the FITS community.  Presumably it will be
best to create HOWTO pages that demonstrates the configuration of
various different species of webserver to publish FITS files.  The
HOWTO pages would best be replicated onto all sites that publish
the FITS standard.

> To have more useful actions, requires SUPPORT to the (new or unusual, e.g.
> FITS) Content-Type from both the server and client sides.

If you build it (or register it with the IANA) they will come.

I suspect that once FITS is registered, and once it is understood that
the various VO sites are chock full of astronomical images that
are nice to view, then we will see FITS viewers become much more
commonplace in desktop systems.

--
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