[fitsbits] New MIME-types-for-FITS RFC draft

Dear Friends of FITS,

A new version of the RFC draft, dated 2004-03-12 (today), is at

http://www.ucolick.org/~sla/fits/mime/

This version incorporates comments from the December 2003 review of
the previous draft. Several new sections have been added to the
document, and a FITS header example has been added to the FITS
overview section. Many minor wording changes have been made.

Comments, suggestions, corrections, proposed additions, etc, should be
posted to the fitsbits and/or fitsmime mailing lists, or can be
sent to the authors and ).

Regards,
Don Wells
--
Donald C. Wells Scientist
http://www.cv.nrao.edu/~dwells
National Radio Astronomy Observatory +1-434-296-0277
520 Edgemont Road, Charlottesville, Virginia 22903-2475 USA

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
NASA/GSFC Code 662 HEASARC +1-301-286-4599 (voice)
Greenbelt MD 20771 +1-301-286-1684 (fax)

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
NASA/GSFC Code 662 HEASARC +1-301-286-4599 (voice)
Greenbelt MD 20771 +1-301-286-1684 (fax)