NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi Dominic, all, Dominic Lowe wrote:
I think perhaps there is a subtle difference in the CF case in that 'cf' in itself is not a media format. i.e. in the general case of "application/a+b" my reading of the document suggests that both a and b must be data/media formats. So while xhtml and xml are both formats in there own right, cf is not - it is merely a convention for writing NetCDF. There's no such thing as a CF file, only netCDF files.
In my mind the CF and netCDF relationship is very much like the XHTML (or GML or ...) and XML relationship. XHTML defines the XML tags and attributes that you can use to write XHTML. CF defines attributes and variables for use in a netCDF file.For this reason, I prefer application/cf+netcdf over application/cf-netcdf.
If a CF-netCDF mime type is going to be registered, I think it would be worth coordinating with the registration of a general netCDF mime type (application/netcdf) as well.
It is a blurry distinction as xhtml is just a way of writing xml, but there is such a tangible thing as an xhtml file (or a GML file...) whereas I don't think there is such a tangible thing as a CF file. There are no applications for reading CF files, only applications that read NetCDF and understand CF.So my take on it is that application/cf+netcdf does not conceptually fit this pattern. My preference would be to have optional parameters that look something like this.application/netcdf;version=3;convention=cf-1.1However your main point is that dispatchers may not be able to deal with this and so the pragmatic solution may indeed be application/cf+netcdf...But, this could be with us for a long time, so if we are not sure at this point in time perhaps it is safest just to register application/netcdf ?Does anyone know if it is necessary to register parameters? If it is do you just register the parameter names or names + values?
I think if you want to use parameters with a registered mime type, the parameters should be registered as well. From RFC 4288 "Media Type Registration" (http://www.ietf.org/rfc/rfc4288.txt?number=4288), section 4.3 "Parameter Requirements" "Media types MAY elect to use one or more media type parameters. [...] [T]he names, values, and meanings of any parameters MUST be fully specified when a media type is registered in the standards tree" In section 3.1 "Standards Tree" it says: "The standards tree is intended for types of general interest to the Internet community. Registrations in the standards tree MUST be approved by the IESG and MUST correspond to a formal publication by a recognized standards body." As Ben said, CF seems like the right standards body for registering a CF-netCDF mime type. Does WCS (or other OGC specs) require registered mime types?
Finally, who is reading these parameters/profiles? One use case is the WCS client server negotiation. Are there any other use cases at the moment?
The main one that comes to mind is web browsers being handed netCDF files (not necessarily from WCS) and wanting to hand them to a helper application. Which is potentially a very important use case. And brings us back to Eizi's comments about mime type parameters. Ethan -- Ethan R. Davis Telephone: (303) 497-8155 Software Engineer Fax: (303) 497-8690 UCAR Unidata Program Center E-mail: edavis@xxxxxxxx P.O. Box 3000 Boulder, CO 80307-3000 http://www.unidata.ucar.edu/ ---------------------------------------------------------------------------
galeon archives: