(Sorry last message got munged)
Generally, I think using mime type to specify encoding format is a good idea.
The netcdf subset service uses "application/x-netcdf" for the Content-Type HTTP header, when
returning netcdf files. When requesting format types, we use "accept=application/x-netcdf" but also
allow "accept=netcdf", in order to make human typing of the URLs as easy as possible.
I dont think we need to register "application/x-netcdf". If we do want to, it would have to be
"application/netcdf" since types or subtypes that begin with "x-" are nonstandard -- they
cannot be registered with IANA.
Im less sure about the profile parameter. I like the idea of clarifying that
these are cf files. But Im not sure if there are other implications.
Ben Domenico wrote:
Hi,
Many of you may be aware, that, in the WCS Standards Working Group, a
suggestion has arisen to:
Use Parameterized MIME Types to transmit format request options
(parameter values). It is flexible, it is simple, and it is how most of
the web negotiates formats.
As I understand it, this would mean that we would move in the direction
of having netCDF or CF-netCDF formally registered with IANA as a MIME
type.
As it is now, we could continue with the MIME type that is used in
places but not recognized
application/x-netcdf
and apply to have that registered formally. Then we could use a
profile parameter to specify cf-netcdf3. This would look like
application/x-netcdf;profile=cf-netcdf3
That might be the cleanest approach for the moment and would probably
require minimal consideration from the CF conventions community since we
would not be applying for formal registration of CF as part of a MIME
type. MIME type issues are a bit troubling for us because it's an area
most of us have only been involved in peripherally in the past.
Of course there are many other possible approaches for MIME types we
could pursue, but, if we are going to pursue this at all, this seems to
be the most straightforward.
Any thoughts on this? Is it a good idea in general. Are there other
approaches we should consider?
-- Ben
