gzipped images in SIAP 1.0

[Norman Gray]

Roy, hello again.

On 2007 May 22 , at 23.15, Roy Williams wrote:

> (1) SIAP specification remains unchanged and gzipped images are  
> declared non compliant. Unfortunately this means fewer VO-compliant  
> data services, more broken registry records, and less happiness in  
> the world.

There's no need for this, I think.  The notion of a gzipped FITS file  
is perfectly adequately expressed in the content-type and content- 
encoding headers of HTTP.

I don't think SIAP has a say in this (being at a layer above HTTP),  
unless it explicitly states that it wishes to  profile HTTP and  
forbid services from using the content-encoding header (which would  
be a Bad Thing, I believe).

[[And forget what I said before about the transparency of decoding  
content-encoding.  Having checked, I think I was conflating content- 
encoding and transfer-encoding, or mixing it up with the content- 
transfer-encoding of MIME; HTTP transfer-encoding is supposed to be  
transparent, but is not intended to be particularly relevant here.]]

> (2) The SIAP spec is changed to allow a new field may be in the  
> table with |ucd=*"VOX:Image_Encoding"*|, and if present, the value  
> may be "gzip", or "compress" etc as written here
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5

I don't believe that there's any need for that, either, given that  
HTTP is expressive enough already.

I think that all your client has to do, Roy, is remember that the  
content-encoding header exists, and be prepared to deal with it if it  
sees it.  No problem!

All the best,

Norman


-- 
------------------------------------------------------------------
Norman Gray  :  http://nxg.me.uk
eurovotech.org  :  University of Leicester, UK