|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
[fitsbits] New MIME-types-for-FITS RFC draft
Dear Friends of FITS,
A new version of the RFC draft, dated 2004-03-12 (today), is at http://www.ucolick.org/~sla/fits/mime/ This version incorporates comments from the December 2003 review of the previous draft. Several new sections have been added to the document, and a FITS header example has been added to the FITS overview section. Many minor wording changes have been made. Comments, suggestions, corrections, proposed additions, etc, should be posted to the fitsbits and/or fitsmime mailing lists, or can be sent to the authors and ). Regards, Don Wells -- Donald C. Wells Scientist http://www.cv.nrao.edu/~dwells National Radio Astronomy Observatory +1-434-296-0277 520 Edgemont Road, Charlottesville, Virginia 22903-2475 USA |
#2
|
|||
|
|||
[fitsbits] New MIME-types-for-FITS RFC draft
In the interest of promoting more discussion, here are some highlights of
the latest FITS MIME draft proposal available at http://www.ucolick.org/~sla/fits/mime/ Note that since this is a formal Internet draft document, words like "MUST", "REQUIRED", "SHALL", "SHOULD", and "MAY" have a precise interpretation. They are defined in RFC-2119, but for convenience I've attached the relevant text to the end of this message. For those who have not yet read it, this FITS proposal requests that 2 new Internet MIME types be defined: "application/fits" and "image/fits". A MIME type is a sort of descriptive label for the data file that gets passed along with it when it is downloaded; Web browsers and other applications may use the MIME type to decide how to display or process the file. Section 5.1 describes the "application/fits" MIME type, and says that files described with this media type "SHOULD conform" to the FITS standards. In an ideal world one might prefer to say "MUST conform", but the current wording is perhaps more realistic, since it allows FITS files that may have only minor transgressions from the Standard. Section 5.2 describes the "image/fits" MIME type and says: - files SHOULD have a Primary HDU with positive integer values for the NAXIS and NAXISn keywords, and hence SHOULD contain at least 1 pixel. - In rare cases it may be appropriate to describe a NULL image -- a dataless container for FITS keywords, with NAXIS=0 or NAXISn=0 -- as 'image/fits' but this usage is discouraged because such files may confuse simple image viewer applications. - files MAY have one or more conforming extension HDUs following the primary HDU. - SHOULD be principally intended to communicate the single data array in the primary HDU. - One-dimensional arrays (NAXIS = 1) may be described as image/fits. - Three-dimensional data arrays (NAXIS = 3, and NAXIS1, NAXIS2, and NAXIS3 all greater than 1) may be described as image/fits. - Files with degenerate axes (i.e., with one or more NAXISn = 1) MAY be described as image/fits, but the first axes SHOULD be non-degenerate, i.e., the degenerate axes should be the highest dimensions. Writers of new applications that produce this type of file SHOULD consider using the WCSAXES keyword to express the dimensionality, instead of using degenerate axes. - Files with 4 or more non-degenerate axes SHOULD be described as application/fits, not image/fits, except in rare cases it MAY be appropriate to do so. - Mosaic images SHOULD NOT be described as image/fits. - Multi-exposure-frame (MEF) mosaic images MUST be declared as application/fits and not as image/fits. - Random groups FITS files MUST be described as application/fits and not as image/fits. - Any FITS file that can be described as image/fits could instead be described as application/fits, depending on context and intended usage. --------------------------------------------------------------- The following terms are defined in RFC 2119, at: http://www.faqs.org/rfcs/rfc2119.html http://www.ietf.org/rfc/rfc2119.txt 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. -- __________________________________________________ __________________ Dr. William Pence NASA/GSFC Code 662 HEASARC +1-301-286-4599 (voice) Greenbelt MD 20771 +1-301-286-1684 (fax) |
#3
|
|||
|
|||
[fitsbits] New MIME-types-for-FITS RFC draft
In the interest of promoting more discussion, here are some highlights of
the latest FITS MIME draft proposal available at http://www.ucolick.org/~sla/fits/mime/ Note that since this is a formal Internet draft document, words like "MUST", "REQUIRED", "SHALL", "SHOULD", and "MAY" have a precise interpretation. They are defined in RFC-2119, but for convenience I've attached the relevant text to the end of this message. For those who have not yet read it, this FITS proposal requests that 2 new Internet MIME types be defined: "application/fits" and "image/fits". A MIME type is a sort of descriptive label for the data file that gets passed along with it when it is downloaded; Web browsers and other applications may use the MIME type to decide how to display or process the file. Section 5.1 describes the "application/fits" MIME type, and says that files described with this media type "SHOULD conform" to the FITS standards. In an ideal world one might prefer to say "MUST conform", but the current wording is perhaps more realistic, since it allows FITS files that may have only minor transgressions from the Standard. Section 5.2 describes the "image/fits" MIME type and says: - files SHOULD have a Primary HDU with positive integer values for the NAXIS and NAXISn keywords, and hence SHOULD contain at least 1 pixel. - In rare cases it may be appropriate to describe a NULL image -- a dataless container for FITS keywords, with NAXIS=0 or NAXISn=0 -- as 'image/fits' but this usage is discouraged because such files may confuse simple image viewer applications. - files MAY have one or more conforming extension HDUs following the primary HDU. - SHOULD be principally intended to communicate the single data array in the primary HDU. - One-dimensional arrays (NAXIS = 1) may be described as image/fits. - Three-dimensional data arrays (NAXIS = 3, and NAXIS1, NAXIS2, and NAXIS3 all greater than 1) may be described as image/fits. - Files with degenerate axes (i.e., with one or more NAXISn = 1) MAY be described as image/fits, but the first axes SHOULD be non-degenerate, i.e., the degenerate axes should be the highest dimensions. Writers of new applications that produce this type of file SHOULD consider using the WCSAXES keyword to express the dimensionality, instead of using degenerate axes. - Files with 4 or more non-degenerate axes SHOULD be described as application/fits, not image/fits, except in rare cases it MAY be appropriate to do so. - Mosaic images SHOULD NOT be described as image/fits. - Multi-exposure-frame (MEF) mosaic images MUST be declared as application/fits and not as image/fits. - Random groups FITS files MUST be described as application/fits and not as image/fits. - Any FITS file that can be described as image/fits could instead be described as application/fits, depending on context and intended usage. --------------------------------------------------------------- The following terms are defined in RFC 2119, at: http://www.faqs.org/rfcs/rfc2119.html http://www.ietf.org/rfc/rfc2119.txt 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. -- __________________________________________________ __________________ Dr. William Pence NASA/GSFC Code 662 HEASARC +1-301-286-4599 (voice) Greenbelt MD 20771 +1-301-286-1684 (fax) |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[fitsbits] proposed FITS MIME types Internet Draft | Steve Allen | FITS | 0 | October 1st 03 05:49 AM |