[fitsbits] FITS MIME RFC ready for review

[Tom McGlynn]

I'd planned on waiting till I got home before discussing this, since
my previous message came from there and I could reuse some text
but it sounds like the discussion has already begun...


I've not been privy to the FITSMIME discussion, but
it seems to me that image/fits is a reasonable MIME type to use when
the data of interest is a simple primary HDU.  Here are a couple of
examples of how I thought this might be used.

SkyView currently uses the image/x-fits extension for its MIME type
and it allows the user to specify the pixel dimensions of the image
to be returned.  Somewhat to my chagrin it currently fails silently
if the user specifies a Nx0 pixel array.  However in fixing this bug
I'd anticipate that what we're likely to do is to provide the user
with a primary image with no pixels but with the header associated
with the position and survey they user requested.  As it stands I
cannot legally return this image using the same MIME type as all of the other
images SkyView generates.  So both SkyView and the invoking program
need to be able to handle two different MIME types.  In practice I would
imagine that distinction would be ignored by developers so 0 pixel images
would be returned as Image/FITS regardless of what the rules say!

Another example is supposing a users has a time sequence of images with
a specific instant associated with each image.  A user may request
an the images within some interval.  If there are N images found in
the interval and images have some common a x b format, the data might
appropriately be returned as an a x b x N image -- a FITS equivalent
to an animated GIF.  If no images are found a return of an a x b x 0 image
may be the most natural return format.  Again, it seems strange to
constrain this value to be in Application/FITS while all others
are legal Image/FITS.

I don't see Image/FITS as a moribund MIME type supported purely for
historical interest, but as a strong suggestion to the reader that the primary HDU is
of interest.  I think that's similar to what Steve is suggesting.


	Regards,
	Tom McGlynn

Steve Allen wrote:
> On Tue 2003-06-03T15:24:09 -0400, Arnold Rots hath writ:
> 
>>Uh, does this mean that you retract your earlier proposal to change
>>MUST to SHOULD or is it meant to strengthen the argument?
>>
>>If the latter, then I would argue that we should not put the cart
>>before the horse.  SIAP is a prototype and we should not design a
>>standard on the basis of usage in a prototype interface.
> 
> 
> I do not retract the change from MUST to SHOULD, but I would very much
> like to know whether the VO community thinks that "application/fits"
> alone serves their current and future needs.
> 
> I neglected to mention the existing non-astronomical applications
> which currently also use what is effectively "image/fits".
> The semantics of FITS files with the standard keywords is currently
> very limited.  The grammar the existing standard keywords consists of
> NOUNs and ADJECTIVEs.  Is there any standard keyword that functions as
> VERB?
> 
> The absence of keywords that describe what to do with the data and
> metadata in a FITS file is already contrary to the notion embodied by
> most other MIME types.  One thing that the MIME type "image/fits" can
> do is to allow the server to inform a client that it should be
> acceptable to hand the incoming FITS file to a "simple" image browser
> like gimp or xv.
> 
> In any case, this dearth of VERBs is not going to be remedied without
> significant effort on the part of the FITS community.  I believe that
> we need a MIME type sooner than that.  In the interim two MIME types
> may be a partial remedy.
> 
> Note that the IANA rules do permit the MIME media type registrations
> to be amended at a later date.  Is the risk of having to refine the
> registrations later greater than the urgency with which they are
> needed now?
> 
> --
> Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
> sla at ucolick.org      Voice: +1 831 459 3046     http://www.ucolick.org/~sla
> PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93
> 
> _______________________________________________
> fitsbits mailing list
> fitsbits at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits
> 
>