diff options
Diffstat (limited to 'doc/rfc/rfc4047.txt')
| -rw-r--r-- | doc/rfc/rfc4047.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc4047.txt b/doc/rfc/rfc4047.txt new file mode 100644 index 0000000..55113f7 --- /dev/null +++ b/doc/rfc/rfc4047.txt @@ -0,0 +1,1291 @@ + + + + + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + |