[fitsmime] Re: New MIME-types-for-FITS RFC draft

[William Pence]

In the interest of promoting more discussion, here are some highlights of
the latest FITS MIME draft proposal available at
        http://www.ucolick.org/~sla/fits/mime/
Note that since this is a formal Internet draft document, words like
"MUST", "REQUIRED", "SHALL", "SHOULD", and "MAY" have a precise
interpretation.  They  are defined in RFC-2119, but for convenience I've
attached the relevant text to the end of this message. 

For those who have not yet read it, this FITS proposal requests that 2 new
Internet MIME types be defined: "application/fits" and "image/fits".  A MIME
type is a sort of descriptive label for the data file that gets passed along
with it when it is downloaded;  Web browsers and other applications may use
the MIME type to decide how to display or process the file.

Section 5.1 describes the "application/fits" MIME type, and says that files
described with this media type "SHOULD conform" to the FITS standards.  In
an ideal world one might prefer to say "MUST conform", but the current
wording is perhaps more realistic, since it allows FITS files that may have
only minor transgressions from the Standard.

Section 5.2 describes the "image/fits" MIME type and says:

 - files SHOULD have a Primary HDU with positive integer values for
   the NAXIS and NAXISn keywords, and hence SHOULD contain at 
   least 1 pixel.  

 - In rare cases it may be appropriate to describe a 
   NULL image -- a dataless container for FITS keywords,
   with NAXIS=0 or NAXISn=0 -- as 'image/fits' but this usage is 
   discouraged because such files may confuse simple image viewer
   applications.

 - files MAY have one or more conforming extension HDUs following
   the primary HDU.

 - SHOULD be principally intended to communicate the single data
   array in the primary HDU.

 - One-dimensional arrays (NAXIS = 1) may be described as image/fits.

 - Three-dimensional data arrays (NAXIS = 3, and NAXIS1, NAXIS2,
   and NAXIS3 all greater than 1) may be described as image/fits.

 - Files with degenerate axes (i.e., with one or more NAXISn = 1)
   MAY be described as image/fits, but the first axes SHOULD be 
   non-degenerate, i.e., the degenerate axes should be the highest
   dimensions.   Writers of new applications that produce this
   type of file SHOULD consider using the WCSAXES keyword to
   express the dimensionality, instead of using degenerate axes.

 - Files with 4 or more non-degenerate axes SHOULD be described
   as application/fits, not image/fits, except in rare cases it
   MAY be appropriate to do so.

 - Mosaic images SHOULD NOT be described as image/fits.

 - Multi-exposure-frame (MEF) mosaic images MUST be declared
   as application/fits and not as image/fits.

 - Random groups FITS files MUST be described as application/fits
   and not as image/fits.

 - Any FITS file that can be described as image/fits could instead
   be described as application/fits, depending on context and
   intended usage.

---------------------------------------------------------------

The following terms are defined in RFC 2119, at:
  http://www.faqs.org/rfcs/rfc2119.html
  http://www.ietf.org/rfc/rfc2119.txt


1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

-- 
____________________________________________________________________
Dr. William Pence                   William.D.Pence(nospam)@nasa.gov
NASA/GSFC Code 662         HEASARC         +1-301-286-4599 (voice)     
Greenbelt MD 20771                         +1-301-286-1684 (fax)