path: root/doc/rfc/rfc4047.txt

Network Working Group                                           S. Allen
Request for Comments: 4047                          UCO/Lick Observatory
Category: Informational                                         D. Wells
                                    National Radio Astronomy Observatory
                                                              April 2005


                    MIME Sub-type Registrations for
                 Flexible Image Transport System (FITS)

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes the registration of the Multipurpose Internet
   Mail Extensions (MIME) sub-types to be used by the international
   astronomical community for the interchange of Flexible Image
   Transport System (FITS) files.  The encoding is defined by the
   published FITS standard documents.  The FITS format has been in use
   since 1979, and almost all data from astronomical observations are
   interchanged by using FITS.

Table of Contents

   1.  Introduction..................................................  2
   2.  Conventions Used in this Document.............................  2
   3.  Overview......................................................  2
   4.  FITS Definition...............................................  3
       4.1.  FITS Structure..........................................  3
       4.2.  History of FITS Features................................  5
       4.3.  Stability of the FITS definition........................  6
       4.4.  Portability of FITS files...............................  7
       4.5.  Application Programming Interfaces to FITS..............  7
       4.6.  FITS File Conformance Testing...........................  8
       4.7.  Archives That Distribute FITS Files.....................  8
   5.  IANA Considerations...........................................  9
       5.1.  Registration of application/fits........................ 10
       5.2.  Registration of image/fits.............................. 14
   6.  References.................................................... 19
       6.1.  Normative References.................................... 19



Allen & Wells                Informational                      [Page 1]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


       6.2.  Informative References.................................. 20
   7.  Security Considerations....................................... 21
   8.  Contributors.................................................. 21
   9.  Acknowledgements.............................................. 22
   Authors' Addresses................................................ 22
   Full Copyright Statement.......................................... 23

1.  Introduction

   The FITS file format [FITS] was designed in order to facilitate the
   interchange of astronomical image data between observatories.  FITS
   provides a means of transporting arrays and tables of data and
   keyword/value pairs of metadata.  FITS is defined by standards
   documents that are approved by the International Astronomical Union
   (IAU, http://www.iau.org/) and published in refereed journals.

   Before the inception of HTTP, astronomers used the Internet to
   exchange FITS files.  Multiple unofficial media types for FITS files
   [ASU] came into use shortly after the inception of the WWW and have
   remained in use.  Currently (2005) the international astronomical
   community is pursuing many cooperative efforts (e.g., [IVOA], [NVO],
   [AstroGrid], [AVO]) to produce web services that provide astronomical
   data.  The exchange of FITS files is a fundamental element of the
   prototypes for these web services [SIAP].  The astronomical community
   has to agree to use one set of media types for FITS files in order to
   promote interoperability of its various services.

   In its simplest form, FITS is used as a means of transporting
   astronomical image data in a raster form along with coordinate
   information and other standard and locally defined metadata.  In such
   applications FITS is much like the well-known TIFF format [TIFF] with
   the addition of the GeoTIFF tags [GeoTIFF].  However, FITS is capable
   of describing a much broader range of data than 2-dimensional
   rasters.  A consensus has developed in the FITS community that two
   media types are needed:  one for images and one for all other cases.

2.  Conventions Used in this Document

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [Require].

3.  Overview

   This document describes the registration of the MIME media sub-types
   "application/fits" and "image/fits".





Allen & Wells                Informational                      [Page 2]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


   In 1988 the International Astronomical Union formed the FITS Working
   Group (IAUFWG) to oversee matters pertaining to the evolution of the
   FITS data format.  The IAUFWG has approved the submission of this
   document and the registration of these two MIME types.

4.  FITS Definition

   FITS is defined by a document approved by the International
   Astronomical Union (IAU) and published in the journal Astronomy &
   Astrophysics [NOST].  Conventions for additional keywords used in
   FITS files are proposed by interested parties and negotiated and
   reviewed by ad hoc committees of the FITS community.  If such usage
   of additional keywords is approved by national committees and the
   IAUFWG then they become new reserved keywords in the FITS standard
   and are published in an ongoing series of papers (e.g., [WCS1,
   WCS2]).

   Copies of the standard documents can be found at the following sites:

   http://fits.gsfc.nasa.gov/

   http://archive.stsci.edu/fits/

   http://www.cv.nrao.edu/fits/

   http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html

   Although a brief structure and feature description is provided in
   this section as background information, the reader is directed to the
   FITS standards documents to obtain complete feature and technical
   details.

4.1.  FITS Structure

   A FITS file consists of a sequence of one or more header and data
   units (HDUs) optionally followed by special records.  The structure
   of a FITS file is based on blocks with a length of 2880 8-bit bytes
   (23040 bits).  This size was chosen because it is evenly divisible by
   the byte and word lengths of all known computer systems.  All FITS
   files have lengths that are integral multiples of this block size.

   Each FITS header consists of a sequence of one or more 2880-byte
   blocks that hold 36 80-character records (36*80=2880).  The records
   consist of ASCII keyword/value pairs plus optional comments.  The
   character set is the 7-bit printing ASCII codes, including the ASCII
   space.  In particular, the control codes CR, LF, FF, TAB and NUL are
   not used in FITS headers.  The keywords are up to 8 characters in
   length.  Some keywords are mandatory, and their meaning is rigidly



Allen & Wells                Informational                      [Page 3]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


   prescribed.  Among these are keywords that describe the structure and
   size of the subsequent data array.  The standard reserves other
   keywords for the purpose of conveying specifically defined items of
   metadata.  Keywords that are neither mandatory nor reserved may be
   inserted with semantics that are defined by local conventions.  (Some
   local conventions have later been adopted into standardized
   practice.)  The end of the header is signified by a block containing
   the keyword "END".  A simple example of a FITS header for a digital
   image, using only keywords that were specified in the initial FITS
   Agreement of March 1979 [FITS], is as follows:

            1         2         3         4         5         6
   1234567890123456789012345678901234567890123456789012345678901234567..

   SIMPLE  =                    T / file does conform to FITS standard
   BITPIX  =                   16 / 16-bit twos-complement pixel values
   NAXIS   =                    2 / 2-dimensional image
   NAXIS1  =                  512 / first axis length
   NAXIS2  =                  512 / second axis length
   COMMENT  -----------------------------------------------------
   COMMENT   FITS (Flexible Image Transport System) format is defined
   COMMENT   in 'Astronomy and Astrophysics', volume 376, page 359;
   COMMENT   bibcode: 2001A&A...376..359H
   COMMENT  -----------------------------------------------------
   ORIGIN  = 'Lick Observatory   ' /
   DATE    = '2003-11-22T05:23:45' / when this file was written
   END

   (These 13 records are followed by 23 80-character records of ASCII
   spaces, to pad the header block to the 2880-byte FITS block size.)

   The first keyword/value pair, SIMPLE=T, is the signature of FITS; all
   FITS files begin with these characters.  BITPIX is the second keyword
   of all FITS files; legal values for it are 8, 16, 32, -32 and -64.
   NAXIS is the third keyword of all FITS files; legal values for it are
   0 to 999.  NAXIS=0 is legal, and implies that there is no image data
   matrix associated with the header (and the NAXISi keywords must not
   be present); this value is common for files that will be given the
   media type "application/fits" as discussed in section 5.1 of this
   document.  NAXIS=2 is the value most often used for files that will
   be given the media type "image/fits", as discussed in section 5.2 of
   this document (NAXIS=3 FITS images are also common).  The COMMENT
   records will be ignored by FITS reading software, but are used here
   to specify the precise journal citation for the FITS standard, an
   item of information that is important for archiving on timescales of
   decades.  The ORIGIN keyword is commonly used in FITS files to encode
   the name of the institution where the file was produced.  The DATE
   keyword is used to convey the timestamp for the file (whereas the



Allen & Wells                Informational                      [Page 4]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


   keyword DATE-OBS is used to convey observation start times).  FITS
   headers commonly contain a vast variety of additional keywords used
   to encode metadata.  In particular, a digital image header will often
   include keywords to specify the precise celestial coordinates of the
   pixels of the 2-D matrix, with conventions that became part of the
   FITS standard in 2002 (see [WCS2]).  Finally, the above example
   demonstrates how, in addition to the COMMENT records, 60% of the
   bytes in keyword=value records in FITS headers are reserved for
   comments.  Although the simple header example above is contained in
   only one FITS block, multi-block FITS headers are commonly
   interchanged.

   Following each header is a data unit that consists of a sequence of
   zero or more 2880-byte blocks.  In accordance with the description in
   the keywords of their header, these blocks contain an N-dimensional
   data array, optionally followed by other small groups of array data.
   In most cases, the data array represents either an N-dimensional
   array of image pixel values or a 2-dimensional array of tabular data.

   Following the HDUs a FITS file may contain zero or more 2880-byte
   blocks of special records.  The standard does not specify anything
   about their content.  (This convention for special records is not
   known to have been used for any purpose other than prototyping new
   elements of the standard, such as random groups and BINTABLE.)

   The initial HDU in a FITS file is known as the primary HDU (PHDU);
   any subsequent HDU is known as an extension HDU (XHDU).  The keyword
   content of the PHDU is distinct (a PHDU requires a slight alteration
   before it can become an XHDU, and most types of XHDU cannot become a
   PHDU).  A PHDU may have a data array consisting of zero elements, and
   this will often be the case for FITS files intended to communicate
   tables and multiple images.  An XHDU may be one of several standard
   types, or it may be another conforming type.  Standard types of XHDU
   include "IMAGE" (containing an N-dimensional data array similar in
   most respects to the PHDU), "TABLE" (containing a 2-dimensional table
   of ASCII character data), and "BINTABLE" (containing a 2-dimensional
   table of binary data whose elements may themselves be multi-
   dimensional arrays).

4.2.  History of FITS Features

   In 1981 the original definition of FITS described a single HDU
   containing one multi-dimensional image array [FITS], as illustrated
   by the sample header shown in section 4.1.  Subsequent agreements
   have used the original framework of HDUs and keyword/value pairs to
   extend FITS while preserving the validity of all existing files.
   FITS now has standard means of describing multiple arrays of image
   data and/or multiple tables of numeric and character information.



Allen & Wells                Informational                      [Page 5]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


   Brief highlights of the history of FITS

      - 1979: Initial FITS Agreement and first interchange of files

      - 1980: Random groups convention developed

      - 1981: Published original (single HDU) definition [FITS]

      - 1981: Published random groups definition [GROUPS]

      - 1982: Formally endorsed by the IAU

      - 1988: Defined rules for multiple HDUs [XTENSION]

      - 1988: FITS Working Group established by IAU [IAUFWG]

      - 1988: Extended to include ASCII tables [TABLE]

      - 1990: Extended to include IEEE floating-point data

      - 1994: Extended to multiple image arrays [IMAGE]

      - 1995: Extended to binary tables [BINTABLE]

      - 1997: Adopted a Y2K-compliant date format

      - 2001: Reiterated existing standard in one paper [NOST]

      - 2002: Approved conventions for world coordinates [WCS1, WCS2]

4.3.  Stability of the FITS Definition

   After the adoption of FITS by the IAU in 1982, some in the emerging
   community of FITS users realized that there would be tension between
   the need for archival stability and the need for evolution.  In order
   to satisfy both of these requirements they set up a controlled
   parliamentary process.  At the time of the Generalized Extensions
   Agreement [XTENSION], the meta-agreement that controls the evolution
   of FITS, the FITS community adopted the guiding principle "Once FITS,
   always FITS".  Under this rule, no change may be made to FITS that
   invalidates existing files.  Changes to the FITS standard occur only
   after action by the IAU FITS Working Group (FWG).  The FWG acts only
   after approval by regional working groups that coordinate FITS
   activity in various parts of the world.

   FITS has been adopted as the archival format for image data and
   interferometric data obtained by many ground-based observatories and
   for all data from many spacecraft.  Many astrophysical archives store



Allen & Wells                Informational                      [Page 6]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


   their data in FITS format, and most astronomical catalog data has
   been transcribed into FITS files.  The many terabytes of data in
   these archives contribute to the stability of the FITS standard.

4.4.  Portability of FITS files

   Eric Greisen, one of the authors of the original document [FITS],
   relates that in 1979

      [t]he first FITS files were written by a PL/I program on an IBM
      360 under OS/MFT (32-bit, twos-complement numbers and 8-bit EBCDIC
      characters) and were read by a Fortran program executing on a CDC
      6400 under SCOPE (60-bit, ones-complement numbers and 6-bit
      "Display Code" characters).  [Remark]

   Subsequent evolution of computing hardware and FITS over 25 years has
   not degraded this ability to transfer the data content.

   The structure of FITS files is extremely general, and this
   necessarily complements the nature of astronomical data.  FITS is
   used to store observations of the entire electromagnetic spectrum
   from radio to gamma rays, from ground-based observatories and from
   spacecraft.  FITS is also used to communicate physical properties
   other than radiation intensity; these may be inferred from
   observations or calculated by theoretical models.  The pedigree of
   data in a FITS file typically varies among disciplines; FITS may be
   used to store raw and uncalibrated data, completely reduced and
   calibrated data, or both.  Nevertheless, the FITS standard provides
   that the syntactic content of the data and metadata are unambiguously
   available to posterity.

   Observatories have developed numerous local conventions for the
   storage and transfer of data peculiar to their instrumentation and
   purview.  Application software for handling FITS files from different
   regions of the electromagnetic spectrum has been largely disjoint.
   For a FITS file that consists of multiple HDUs there are no widely
   established conventions governing the meaning of, interrelations
   between, and suggested use of the data sets.  Recognition of any
   local conventions used for FITS data has often been based on
   heuristics of the additional (non-standard) keyword/value pairs.
   Fully understanding the semantic content of a FITS file usually
   requires an external data dictionary.

4.5.  Application Programming Interfaces to FITS

   Although the definition of FITS is expressed in terms of the bit
   content of the files, there are widely supported application
   programming interfaces (APIs) which simplify the task of manipulating



Allen & Wells                Informational                      [Page 7]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


   FITS files.  Interfaces exist for many languages and operating
   systems.  A partial list of APIs follows:

   CFITSIO      http://heasarc.gsfc.nasa.gov/fitsio/
   fitsTcl      http://heasarc.gsfc.nasa.gov/ftools/fv/fitsTcl_home.html
   WCSLIB       http://www.atnf.csiro.au/people/mcalabre/WCS/
   PyFITS       http://www.stsci.edu/resources/software_hardware/pyfits
   WCSTools     http://tdc-www.harvard.edu/software/wcstools/
   FUNTOOLS     http://hea-www.harvard.edu/RD/funtools/
   IDLASTRO     http://idlastro.gsfc.nasa.gov/
   fitsy        http://cfa-www.harvard.edu/~john/fitsy/
   IUEDAC       http://archive.stsci.edu/iue/iuedacfits.html
   Mathematica  http://documents.wolfram.com/v5/Built-inFunctions/
                       GraphicsAndSound/ImportAndExport/
                       AdditionalInformation/Import.html
   MatLab       http://www.mathworks.com/access/helpdesk/help/techdoc/
                       ref/fitsread.shtml?cmdname=fitsread

   Current lists of more APIs can be found at
   http://fits.gsfc.nasa.gov/fits_libraries.html

   List of applications that use FITS are found in the IANA
   registrations of the media types.

4.6.  FITS File Conformance Testing

   FITS files can be tested for conformance to the Definition of FITS
   rules [NOST, WCS1, WCS2] with an application named "fitsverify",
   which is available at

   http://heasarc.gsfc.nasa.gov/docs/software/ftools/fitsverify/

   in the form of executable binary files for Solaris, Linux, and
   Windows platforms, as well as in source code.  Although "fitsverify"
   has not been endorsed by the IAUFWG, users should be aware that the
   designer of the program was the Secretary of the Technical Panel that
   produced the published FITS standard [NOST].

4.7.  Archives That Distribute FITS Files

   As noted in section 4.3 of this RFC, massive (multi-terabyte) data
   archives that contain and/or distribute FITS files contribute to the
   stability of the FITS standard.  There are numerous publicly
   available archives of FITS files derived from both space and ground-
   based observations that span the entire range of the electromagnetic
   spectrum from radio to gamma-ray wavelengths.  The following are
   examples of such archives, in no particular order:




Allen & Wells                Informational                      [Page 8]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


   Telescope(s)   URLs for archive access
   ------------   ------------------------------------------------------
   KPNO,CTIO,..   http://archive.noao.edu/nsa/
   VLT,HST,..     http://archive.eso.org/
   Subaru         http://smoka.nao.ac.jp/
   SDSS           http://www.sdss.org/dr3/
   CFHT           http://cadcwww.dao.nrc.ca/cfht/cfht.html
   VLA,VLBA,GBT   http://e2e.aoc.nrao.edu/archive/archive_describe.html
   HST,MAST       http://archive.stsci.edu/
   HEASARC        http://heasarc.gsfc.nasa.gov/w3browse/
   Chandra        http://cxc.harvard.edu/cda/
   LaPalma        http://archive.ast.cam.ac.uk/ingarch/
   BIMA           http://bimaarch.ncsa.uiuc.edu/
   Keck-DEIMOS    http://archive.deep.ucolick.org/
   ComptonGRO     http://cossc.gsfc.nasa.gov/archive/index.html
   Spitzer,..     http://www.ipac.caltech.edu/
   AAT            http://www.aao.gov.au/archive/
   HIPASS         http://www.atnf.csiro.au/research/multibeam/
                          multibeam.html
   JCMT           http://salish.dao.nrc.ca:8080/jcmt/intro.html
   COBE,WMAP      http://lambda.gsfc.nasa.gov/
   EVN            http://www.jive.nl/archive/scripts/listarch.php
   Gemini         http://gemini.ast.cam.ac.uk/sciops/data/dataIndex.html
   XMM-Newton     http://xmm.vilspa.esa.es/external/xmm_data_acc/xsa/

5.  IANA Considerations

   The general nature of the full FITS standard requires the use of the
   media type "application/fits".  Nevertheless, the principal intent
   for a great many FITS files is to convey a single data array in the
   PHDU, and such arrays are very often 2-dimensional images.  Several
   common image viewing applications already display single-HDU FITS
   files, and the prototypes for virtual observatory projects specify
   that data provided by web services be conveyed by the data array in
   the PHDU.  These uses justify the registration of a second media
   type, namely "image/fits", for files which use the subset of the
   standard described by the original FITS standard paper [FITS].

   We note that the media type "image/gif" [MIME2] admits raster images
   that are three dimensional, because animated GIF images contain two
   spatial dimensions and one temporal dimension.  We note that the
   media types "image/vnd.dwg" and "image/vnd.dxf" admit data that
   include three-dimensional vectors and curves as well as objects
   created by using constructive solid geometry.  Following these
   precedents for the "image" media type, we specify that "image/fits"
   MAY be used to describe FITS PHDUs that have other than two
   dimensions.  We expect that most files described as "image/fits" will
   have two-dimensional (NAXIS=2) PHDUs.



Allen & Wells                Informational                      [Page 9]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


5.1.  Registration of application/fits

   To: ietf-types@iana.org
   Subject: Registration of Standard MIME Media type application/fits

   MIME media type name: application

   MIME subtype name: fits

   Required parameters: none

   Optional parameters: none

   Encoding considerations: binary

   FITS files can be quite large.  When transferred via HTTP it may be
   efficient for the transaction to make use of content-coding or
   transfer-coding values such as "gzip", "compress", or "deflate".

   Security considerations:

   FITS provides a means of transporting arrays and tables of data and
   keyword/value pairs of metadata.  The standard FITS keywords are
   either mandatory or reserved.  Mandatory keywords provide information
   necessary for correct interpretation of the data; reserved keywords
   merely provide standard bits of metadata.  As such, the current
   standard FITS keywords do not pose security risks.

   A FITS file author may insert additional keywords with semantics that
   are not described by the standard.  Parties exchanging FITS files may
   employ locally defined conventions that use various keywords and
   their values to induce actions on the part of the recipient.  There
   are existing local conventions where such keywords are used to
   request the reading of other files and/or URIs.  There are other
   local conventions where such keywords are used to modify the state of
   a telescope and/or instrument.  The security implications of local
   conventions such as these SHOULD be analyzed by the parties employing
   them.

   Interoperability considerations:

   FITS files have been successfully transported between wildly
   different computers since 1979.  The difficulty most likely to be
   encountered by a FITS application is inability to acquire the
   computational resources required by a very large FITS file.






Allen & Wells                Informational                     [Page 10]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


   Published specification:

   The specification for this content type is published as a series of
   papers in refereed astronomical journals:

   Hanisch, R., et al., "Definition of the Flexible Image Transport
   System (FITS)", Astronomy & Astrophysics, 376, p. 359, 2001.

   Greisen, E. and M. Calabretta, "Representations of world coordinates
   in FITS", Astronomy & Astrophysics, 395, p. 1061, 2002.

   Calabretta, M. and E. Greisen, "Representations of celestial
   coordinates in FITS", Astronomy & Astrophysics, 395, p. 1077, 2002.

   Copies of these specifications can also be found via:

   http://fits.gsfc.nasa.gov/
   http://archive.stsci.edu/fits/
   http://www.cv.nrao.edu/fits/
   http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html

   Applications that use this media type:

   There are many astronomical image viewing and data reduction
   applications including, but not limited to, the following list:

   IRAF     http://iraf.noao.edu/
   AIPS     http://www.aoc.nrao.edu/aips/
   AIPS++   http://aips2.nrao.edu/
   MIDAS    http://www.eso.org/projects/esomidas/
   ds9      http://hea-www.harvard.edu/RD/ds9/
   fv       http://heasarc.gsfc.nasa.gov/ftools/fv/
   Aladin   http://aladin.u-strasbg.fr/
   Starlink http://star-www.rl.ac.uk/
   Miriad   http://bima.astro.umd.edu/miriad/
   STSDAS   http://www.stsci.edu/resources/software_hardware/stsdas
   PROS     http://hea-www.harvard.edu/PROS/pros.html
   CIAO     http://cxc.harvard.edu/ciao/
   XANADU   http://heasarc.gsfc.nasa.gov/docs/xanadu/xanadu.html
   HESSI    http://hesperia.gsfc.nasa.gov/ssw/hessi/doc/
   FITSview http://www.nrao.edu/software/fitsview/
   XMM-SAS  http://xmm.vilspa.esa.es/external/xmm_sw_cal/sas_frame.shtml

   At the present time many of these applications are not designed to
   support use as viewers of "application/fits" files in association
   with web browsers.





Allen & Wells                Informational                     [Page 11]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


   Additional information:

   A FITS file described with the media type "application/fits" SHOULD
   conform to the published standards for FITS files as determined by
   convention and agreement within the international FITS community.  No
   other constraints are placed on the content of a file described as
   "application/fits".

   A FITS file described with the media type "application/fits" may have
   an arbitrary number of conforming extension header and data units
   (XHDUs) that follow its mandatory primary header and data unit
   (PHDU).  The XHDUs may be one of the standard types ("IMAGE",
   "TABLE", and "BINTABLE") or any other type that satisfies the
   "Requirements for Conforming Extensions" (section 4.4.1 of [NOST]).
   The PHDU or any "IMAGE" XHDU may contain zero to 999 dimensions with
   zero or more pixels along each dimension.

   The PHDU may use the random groups convention, in which the dimension
   of the first axis is zero and the keywords GROUPS, PCOUNT and GCOUNT
   appear in the header.  NAXIS1=0 and GROUPS=T is the signature of
   random groups; see section 7 of the Definition of FITS paper [NOST].

   Recommendations for application writers:

   An application intended to handle "application/fits" SHOULD be able
   to provide a user with a manifest of all of the HDUs that are present
   in the file and with all of the keyword/value pairs from each of the
   HDUs.

   An application intended to handle "application/fits" SHOULD be
   prepared to encounter XHDUs that contain either ASCII or binary
   tables, and to provide a user with access to their elements.

   An application which can modify FITS files or retrieve FITS files
   from an external service SHOULD be capable of writing such files to a
   local storage medium.

   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.

   As examples, files with media type "application/fits" might contain
   any of the following contents:

   - An empty PHDU (containing zero data elements) followed by a table
     HDU that contains a catalog of celestial objects.




Allen & Wells                Informational                     [Page 12]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


   - An empty PHDU followed by a table HDU that encodes a series of
     time-tagged photon events from an exposure using an X-ray detector.

   - An empty PHDU followed by a series of IMAGE HDUs containing data
     from an exposure taken by a mosaic of CCD detectors.

   - An empty PHDU followed by a series of table HDUs that contain a
     snapshot of the state of a relational database.

   - A PHDU containing a single image along with keyword/value pairs of
     metadata.

   - A PHDU with NAXIS1=0 and GROUPS=T followed by random groups data
     records of complex fringe visibilities

   Magic number(s): "SIMPLE  =                    T"

   Jeff Uphoff of the National Radio Astronomy Observatory (NRAO) has
   contributed database entries for the magic number file which is used
   by the Unix "file" command.  Magic number files with these entries
   are distributed with a variety of Unix-like operating systems.  In
   addition to recognizing a FITS file using the string given above, the
   Uphoff entries also recognize the data type of the pixels in the
   PHDU.

   File extension(s): fits

   This file extension SHOULD NOT be interpreted as a prescription.

   The FITS standard originated in the era when files were stored and
   exchanged via magnetic tape; it does not prescribe any nomenclature
   for files on disk.  Various sites within the FITS community have
   long-established practices where files are presumed to be FITS by
   context.  File extensions used at such sites commonly indicate
   content of the file instead of the data format.

   In the absence of other information it is reasonably safe to presume
   that a file name ending in ".fits" is intended to be a FITS file.
   Nevertheless, there are other commonly used extensions; e.g., ".fit",
   ".fts", and many others not suitable for listing in a media type
   registration.

   Intended usage: Common

   Persons to contact for further information:

      "Steve Allen"     <sla@ucolick.org>
      "Don Wells"       <dwells@nrao.edu>



Allen & Wells                Informational                     [Page 13]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


   Author/Change controller:

      "Steve Allen" <sla@ucolick.org>

   The IAU FITS Working Group may authorize changes to this document.

5.2.  Registration of image/fits

   To: ietf-types@iana.org
   Subject: Registration of Standard MIME Media type image/fits

   MIME media type name: image

   MIME subtype name: fits

   Required parameters: none

   Optional parameters: none

   Encoding considerations: binary

   FITS files can be quite large.  When transferred via HTTP it may be
   efficient for the transaction to make use of content-coding or
   transfer-coding values such as "gzip", "compress", or "deflate".

   Security considerations:

   FITS provides a means of transporting arrays and tables of data and
   keyword/value pairs of metadata.  The standard FITS keywords are
   either mandatory or reserved.  Mandatory keywords provide information
   necessary for correct interpretation of the data; reserved keywords
   merely provide standard bits of metadata.  As such, the current
   standard FITS keywords do not pose security risks.

   A FITS file author may insert additional keywords with semantics that
   are not described by the standard.  Parties exchanging FITS files may
   employ locally defined conventions that use various keywords and
   their values to induce actions on the part of the recipient.  There
   are existing local conventions where such keywords are used to
   request the reading of other files and/or URIs.  There are other
   local conventions where such keywords are used to modify the state of
   a telescope and/or instrument.  The security implications of local
   conventions such as these SHOULD be analyzed by the parties employing
   them.







Allen & Wells                Informational                     [Page 14]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


   Interoperability considerations:

   FITS files have been successfully transported between wildly
   different computers since 1979.  The difficulty most likely to be
   encountered by a FITS application is inability to acquire the
   computational resources required by a very large FITS file.

   Published specification:

   The specification for this content type is published as a series of
   papers in refereed astronomical journals:

   Hanisch, R., et al., "Definition of the Flexible Image Transport
   System (FITS)", Astronomy & Astrophysics, 376, p. 359, 2001.

   Greisen, E.  and M.  Calabretta, "Representations of world
   coordinates in FITS", Astronomy & Astrophysics, 395, p.  1061, 2002.

   Calabretta, M. and E. Greisen, "Representations of celestial
   coordinates in FITS", Astronomy & Astrophysics, 395, p. 1077, 2002.

   Copies of these specifications can also be found via:

   http://fits.gsfc.nasa.gov/
   http://archive.stsci.edu/fits/
   http://www.cv.nrao.edu/fits/
   http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html

   Applications that use this media type:

   There are many astronomical image viewing and data reduction
   applications including, but not limited to, the following list:

   IRAF     http://iraf.noao.edu/
   AIPS     http://www.aoc.nrao.edu/aips/
   AIPS++   http://aips2.nrao.edu/
   MIDAS    http://www.eso.org/projects/esomidas/
   ds9      http://hea-www.harvard.edu/RD/ds9/
   fv       http://heasarc.gsfc.nasa.gov/ftools/fv/
   Aladin   http://aladin.u-strasbg.fr/
   Starlink http://star-www.rl.ac.uk/
   Miriad   http://bima.astro.umd.edu/miriad/
   STSDAS   http://www.stsci.edu/resources/software_hardware/stsdas
   PROS     http://hea-www.harvard.edu/PROS/pros.html
   CIAO     http://cxc.harvard.edu/ciao/
   XANADU   http://heasarc.gsfc.nasa.gov/docs/xanadu/xanadu.html





Allen & Wells                Informational                     [Page 15]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


   HESSI    http://hesperia.gsfc.nasa.gov/ssw/hessi/doc/
   FITSview http://www.nrao.edu/software/fitsview/
   XMM-SAS  http://xmm.vilspa.esa.es/external/xmm_sw_cal/sas_frame.shtml

   Non-astronomical FITS image display applications include:

   netpbm          http://netpbm.sourceforge.net/
   gimp            http://www.gimp.org/
   IDL             http://www.rsinc.com/
   ImageMagick     http://www.imagemagick.com/
   Mathematica     http://www.wolfram.com/
   MatLab          http://www.mathworks.com/
   xv              http://www.trilon.com/xv/xv.html

   There are also two FITS plug-ins for Adobe Photoshop
   (http://www.adobe.com/products/photoshop/), available at
   http://astroshed.com/fitsplug/fitsplug.htm and
   http://www.spacetelescope.org/projects/fits_liberator/

   At the present time many of the applications listed above are not
   designed to support use as viewers of "image/fits" files in
   association with web browsers.

   Additional information:

   A FITS file described with the media type "image/fits" SHOULD have a
   PHDU with positive integer values for the NAXIS and NAXISn keywords,
   and hence SHOULD contain at least one pixel.  Files with 4 or more
   non-degenerate axes (NAXISn>1) SHOULD be described as
   "application/fits", not as "image/fits".  (In rare cases it may be
   appropriate to describe a NULL image -- a dataless container for FITS
   keywords, with NAXIS=0 or NAXISn=0 -- or an image with 4+ non-
   degenerate axes as "image/fits" but this usage is discouraged because
   such files may confuse simple image viewer applications.)

   FITS files declared as "image/fits" MAY also have one or more
   conforming XHDUs following their PHDUs.  These extension HDUs MAY
   contain standard, non-linear, world coordinate system (WCS)
   information in the form of tables or images.  The extension HDUs MAY
   also contain other, non-standard metadata pertaining to the image in
   the PHDU in the forms of keywords and tables.

   A FITS file described with the media type "image/fits" SHOULD be
   principally intended to communicate the single data array in the
   PHDU.  This means that "image/fits" SHOULD NOT be applied to FITS
   files containing MEF (multi-exposure-frame) mosaic images.  Also,
   random groups files MUST be described as "application/fits" and not
   as "image/fits".



Allen & Wells                Informational                     [Page 16]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


   A FITS file described with the media type "image/fits" is also valid
   as a file of media type "application/fits".  The choice of
   classification depends on the context and intended usage.

   Recommendations for application writers:

   An application that is intended to handle "image/fits" SHOULD be able
   to provide a user with a manifest of all of the HDUs that are present
   in the file and with all of the keyword/value pairs from each of the
   HDUs.  An application writer MAY choose to ignore HDUs beyond the
   PHDU, but even in this case the application SHOULD be able to present
   the user with the keyword/value pairs from the PHDU.

   Note that an application intended to render "image/fits" for viewing
   by a user has significantly more responsibility than an application
   intended to handle, e.g., "image/tiff" or "image/gif".  FITS data
   arrays contain elements which typically represent the values of a
   physical quantity at some coordinate location.  Consequently they
   need not contain any pixel rendering information in the form of
   transfer functions, and there is no mechanism for color look-up
   tables.  An application SHOULD provide this functionality, either
   statically using a more or less sophisticated algorithm, or
   interactively allowing a user various degrees of choice.

   Furthermore, the elements in a FITS data array may be integers or
   floating-point numbers.  The dynamic range of the data array values
   may exceed that of the display medium and the eye, and their
   distribution may be highly nonuniform.  Logarithmic, square-root, and
   quadratic transfer functions along with histogram equalization
   techniques have proved helpful for rendering FITS data arrays.  Some
   elements of the array may have values which indicate that their data
   are undefined or invalid; these should be rendered distinctly.  Via
   WCS Paper I [WCS1] the standard permits "CTYPEnnn = 'COMPLEX'" to
   assert that a data array contains complex numbers (future revisions
   might admit other elements such as quaternions or general tensors).

   Three-dimensional data arrays (NAXIS=3 with NAXIS1, NAXIS2 and NAXIS3
   > 1) are of special interest.  Applications intended to handle
   "image/fits" MAY default to displaying the first 2D plane of such an
   image cube, or they MAY default to presenting such an image in a
   fashion akin to that used for an animated GIF, or they MAY present
   the data cube as a mosaic of "thumbnail" images.  Even in the absence
   of WCS indication of a temporal axis the time-lapse movie-looping
   display technique can be effective, and application writers SHOULD
   consider offering it for all three-dimensional arrays.

   An "image/fits" PHDU with NAXIS=1 is describing a one-dimensional
   entity such as a spectrum or a time series.  Applications intended to



Allen & Wells                Informational                     [Page 17]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


   handle "image/fits" MAY default to displaying such an image as a
   graphical plot rather than as a two-dimensional picture with a single
   row.

   An application that cannot handle an image with dimensionality other
   than 2 SHOULD gracefully indicate its limitations to its users when
   it encounters NAXIS=1 or NAXIS=3 cases, while still providing access
   to the keyword/value pairs.

   FITS files with degenerate axes (i.e., 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).  An algorithm designed to render only two-dimensional
   images will be capable of displaying such an NAXIS=3 or NAXIS=4 FITS
   array that has one or two of the axes consisting of a single pixel,
   and an application writer SHOULD consider coding this capability into
   the application.  Writers of new applications which generate FITS
   files intended to be described as "image/fits" SHOULD consider using
   the WCSAXES keyword [WCS1] to declare the dimensionality of such
   degenerate axes, so that NAXIS can be used to convey the number of
   non-degenerate axes.

   Magic number(s): "SIMPLE  =                    T"

   Jeff Uphoff of the National Radio Astronomy Observatory (NRAO) has
   contributed database entries for the magic number file which is used
   by the Unix "file" command.  Magic number files with these entries
   are distributed with a variety of Unix-like operating systems.  In
   addition to recognizing a FITS file using the string given above, the
   Uphoff entries also recognize the data type of the pixels in the
   PHDU.

   File extension(s): fits

   This file extension SHOULD NOT be interpreted as a prescription.

   The FITS standard originated in the era when files were stored and
   exchanged via magnetic tape; it does not prescribe any nomenclature
   for files on disk.  Various sites within the FITS community have
   long-established practices where files are presumed to be FITS by
   context.  File extensions used at such sites commonly indicate
   content of the file instead of the data format.

   In the absence of other information it is reasonably safe to presume
   that a file name ending in ".fits" is intended to be a FITS file.
   Nevertheless, there are other commonly used extensions; e.g., ".fit",
   ".fts", and many others not suitable for listing in a media type
   registration.



Allen & Wells                Informational                     [Page 18]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


   Intended usage: Common

   Persons to contact for further information:

      "Steve Allen"     <sla@ucolick.org>
      "Don Wells"       <dwells@nrao.edu>

   Author/Change controller:

      "Steve Allen"     <sla@ucolick.org>

   The IAU FITS Working Group may authorize changes to this document.

6.  References

6.1.  Normative References

   [Require]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [MIME1]     Freed, N. and N. Borenstein, "Multipurpose Internet Mail
               Extensions (MIME) Part One: Format of Internet Message
               Bodies", RFC 2045, November 1996.

   [MIME2]     Freed, N. and N. Borenstein, "Multipurpose Internet Mail
               Extensions (MIME) Part Two: Media Types", RFC 2046,
               November 1996.

   [MIME4]      Freed, N., Klensin, J., and J. Postel, "Multipurpose
               Internet Mail Extensions (MIME) Part Four: Registration
               Procedures", BCP 13, RFC 2048, November 1996.

   [HTTP]      Fielding,  R., Gettys, J., Mogul, J., Frystyk, H.,
               Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
               Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [NOST]      Hanisch, R., et al., "Definition of the Flexible Image
               Transport System (FITS)", Astronomy & Astrophysics, 376,
               p. 359, 2001.

   [WCS1]      Greisen, E. and M. Calabretta, "Representations of world
               coordinates in FITS", Astronomy & Astrophysics, 395, p.
               1061, 2002.

   [WCS2]      Calabretta, M. and E. Greisen, "Representations of
               celestial coordinates in FITS", Astronomy & Astrophysics,
               395, p. 1077, 2002.




Allen & Wells                Informational                     [Page 19]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


6.2.  Informative References

   [FITS]      Wells, D., et al., "FITS: A Flexible Image Transport
               System", Astronomy & Astrophysics Supplement, 44, p. 363,
               1981.

   [GROUPS]    Greisen, E. and R. Harten, "An extension of FITS for
               groups of small arrays of data", Astronomy & Astrophysics
               Supplement, 44, p. 371, 1981.

   [XTENSION]  Grosbol, P., et al., "Generalized extensions and blocking
               factors for FITS", Astronomy & Astrophysics Supplement,
               73, p. 359, 1988.

   [IAUFWG]    McNally, D., ed., "Transactions of the IAU, Vol.  XXB
               1988, Proceedings of the Twentieth General Assembly
               Baltimore 1988", Kluwer Academic, p. 52 (Resolution B2),
               1988.

   [TABLE]     Harten, R., et al., "The FITS tables extension",
               Astronomy & Astrophysics Supplement, 73, p. 365, 1988.

   [IMAGE]     Ponz, J., et al., "The FITS image extension", Astronomy &
               Astrophysics Supplement, 105, p. 53, 1994.

   [BINTABLE]  Cotton, W., et al., "Binary table extension to FITS",
               Astronomy & Astrophysics Supplement, 113, p. 159, 1995.

   [Remark]    Greisen, E., "FITS: A remarkable achievement in
               information exchange" in "Information Handling in
               Astronomy -- Historical Vistas", A. Heck, ed., Kluwer
               Academic, p. 71, 2003.

   [IVOA]      The International Virtual Observatory Alliance,
               http://www.ivoa.net/

   [NVO]       The US National Virtual Observatory, http://www.us-
               vo.org/

   [AstroGrid] The UK AstroGrid, http://www.astrogrid.org/

   [AVO]       The European Astrophysical Virtual Observatory,
               http://www.euro-vo.org/

   [ASU]       Albrecht, M., et al., "Astronomical Server URL",
               http://vizier.u-strasbg.fr/doc/asu.html, 1996.





Allen & Wells                Informational                     [Page 20]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


   [SIAP]      Tody, D., et al., "Simple Image Access Prototype
               Specification", http://www.us-vo.org/pubs/, 2002.

   [TIFF]      Adobe Systems Incorporated, "TIFF Revision 6.0",
               http://partners.adobe.com/asn/developer/pdfs/tn/TIFF6.pdf
               1992.

   [GeoTIFF]   Ritter, N. and M. Ruth, "GeoTIFF Format Specification",
               http://www.remotesensing.org/geotiff/geotiff.html, 2000.

7.  Security Considerations

   The security considerations of interchanging FITS files are discussed
   above within the text of the IANA registration for each media type.

8.  Contributors

   Several individuals have made significant contributions to the
   content and clarity of this text:

   - Francois Ochsenbein  (Observatoire Astronomique de Strasbourg)

   - Clive Davenhall      (Institute for Astronomy of the Royal
                           Observatory Edinburgh)

   - Tom McGlynn          (Laboratory for High Energy Astrophysics of
                           the NASA Goddard Space Flight Center)

   - Lucio Chiappetti     (Milan section of the Italian Istituto di
                           Astrofisica Spaziale e Fisica Cosmica)

   - William Pence        (NASA High Energy Astrophysics Science Archive
                           Research Center)

   - Arnold Rots          (High Energy Astrophysics Division of the
                           Smithsonian Astrophysical Observatory)

   - Doug Tody            (National Radio Astronomy Observatory)

   - Bob Hanisch          (Space Telescope Science Institute)

   - Mark Calabretta      (Australia Telescope National Facility)









Allen & Wells                Informational                     [Page 21]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


9.  Acknowledgements

   This document originated when William Joye of the Research and
   Development Group at the Smithsonian Astrophysical Observatory High
   Energy Astrophysics Division discovered many experimental and
   unofficial MIME media types being used by various agencies.

   Jeff Uphoff of the National Radio Astronomy Observatory (NRAO)
   contributed the FITS entries for the magic number file that permits
   the Unix-like "file" command on many systems to identify a FITS file.

   Nelson Zarate verified that the fgread and fgwrite programs are able
   to store hierarchical directories containing files with arbitrary
   MIME media types within a HDU of a FITS file.  The fgread and fgwrite
   programs are part of the FITSUTIL IRAF external package (version
   dated September 1999) written by N. Zarate, D. Tody, and R. Seaman at
   National Optical Astronomy Observatory (NOAO).

Authors' Addresses

   Steven L. Allen
   UCO/Lick Observatory
   University of California
   Santa Cruz, CA  95064  USA

   Phone: +1 831 459 3046
   EMail: sla@ucolick.org


   Donald C. Wells
   National Radio Astronomy Observatory
   520 Edgemont Road
   Charlottesville, Virginia  22903-2475  USA

   Phone: +1 434 296 0277
   EMail: dwells@nrao.edu















Allen & Wells                Informational                     [Page 22]
^L
RFC 4047          MIME Sub-type Registrations for FITS        April 2005


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Allen & Wells                Informational                     [Page 23]
^L