NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi GALEON collaborators,
The note I sent out earlier about parametrized MIME types for CF-netCDF was
prompted by a suggestion in the WCS working group. Since not all of you are
involved in those discussions, I'm quoting the specific suggestion below for
using such MIME types as "identifiers" for WCS encoding extensions. I hope
this background information will provide some context for the GALEON
discussion of MIME types for CF-netCDF.
Please note that the quote below is just a suggestion. By no means has it
been adopted for WCS, but it was put forth as a possible solution to a key
issue related to defining WCS standard extensions for encoding formats.
On the other hand, it serves as a good reminder that the question of MIME
types may be generally important in the CF-netCDF realm -- not just in the
WCS context.
-- Ben
=================================================================================
1. 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. That last one is what clinches it for me because it
works!
2. To have Encoding Extensions that:
1. Describe how a WCS GetCoverage response is mapped to a specific
format. I would even say that an extension could even map to two or more
formats: for example GIF with GML based georeferencing. To me that is
essentially devising a new format.
2. Provide a unique encoding extension "identifier" :
1. The "identifier" must be a MIME type.
2. Whether the MIME type is a registered with IANA doesn't matter.
3. Where possible it may make sense to use a registered mime type with
a parameter name and value that uniquely identifies the extension.
4. An un-parameterized MIME type means that all parameters use their
default values.
3. List additional the parameters available, their possible values, and
their defaults.
1. There is no theoretical limit on the number of mime type
parameters but there is likely a practical limit. Keep the list short to
start - others can extend the extension if they need more parameters.
2. As stated above the parameters should be encoded as MIME
parameters.
3. However, extension writers are free to add parameters as KVPs or
extend the XML request. In reality whether parameterize MIME types or
something else is used doesn't matter because, when a client
recognizes an
*encoding extension identifier (mime type)* the client automatically
knows how to encode the extension parameters.
4. Extension writers can even mix and match KVPs and MIME parameters.
When no WCS encoding extension exists for a given mime type then the
resulting file depends entirely upon the server implementation.
galeon archives: