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

[Mark Calabretta]

Comments on the rfcFITS-20040312.txt:

1) As previously, my main comment/question relates to "Recommendations
   for application writers" for application/fits.

   What does it mean in practical terms to say that "An application
   intended to handle "application/fits" SHOULD be prepared to
   encounter..."?  Specifically, does any utility currently exist that
   can do something sensible with ANY general FITS file?  E.g. I know
   that 'fv' does a good job with BINTABLES, etc., but can it even list
   pixel values for a 999 dimensional image?  What about a random groups
   file?  Are there any others that even come close?  The statement

     "Complete interpretation of the meaning and intended use of the
      data in each of the HDUs typically requires the use of heuristics
      that attempt to ascertain which local conventions were used by the
      author of the FITS file."

   implies that a certain amount of black magic is required.

2) Do the lists of software packages on page 11 (and 15) really count as
   *applications* that can handle "application/fits" (or "image/fits")?
   When setting up a mailcap entry you need to specify the name of an
   executable, e.g. 'xv' or 'fv' into which you can feed the file.
   IRAF, AIPS, miriad, etc. do not fit the bill here, though certainly
   they do contain some particular applications that can process some
   specific types of FITS file.

3) The last paragraph on p17 should be merged into the first sentence of
   "Additional information" on p16 to make it clear from the outset that
   NAXIS is limited to 3 non-degenerate axes.

4) Is it reasonable for image/fits to preclude IMAGE extensions?  Perhaps
   a comment is in order.

Additional comments:

p4, Sect. 4.1: The term "lines" in the phrase "2880-byte blocks which
    hold 36 80-character lines" is undefined.  You could say "2880-byte
    blocks that are divided into 36 records of 80 bytes".

    ASCII blank (0x20) is not a "non-printing" character - printing
    characters range from 0x20 to 0x7E inclusive.  CR, LF, FF and TAB
    are better described as print control characters.  You could also
    mention NUL which causes a lot of confusion for some software.

p9, Sect. 4.7: ATCA archive data is in the form of RPFITS which
    decidedly is not FITS.  (HIPASS data is in FITS.)

Grammar: "which" is routinely used incorrectly as a relative pronoun in
    place of "that" (e.g. the first eleven occurences of "which" in the
    document should be "that", the twelfth is the first correct usage).

Mark Calabretta
ATNF