Register a netCDF media type

[ethanrd]

Information on media types and the registration process is here: http://www.iana.org/assignments/media-types/.

I believe the next step is to draft some text for the registration proposal.

Some references to previous conversations on a netCDF media type are listed in opengeospatial/netcdf-ld#80. Thanks to @marqh for starting this conversation again.

[marqh]

Hello @ethanrd

many thanks for raising this issue

some thoughts from me on elements within https://www.iana.org/form/media-types (ref: https://www.rfc-editor.org/rfc/rfc6838.html )

marqh

• type name:
  • application
• subtype name
  • standards tree (no prefix)
• Required / optional Parameters
  • this could be left blank, as per rfc6838
• Encoding Considerations
  • binary
• Security Considerations (https://www.rfc-editor.org/rfc/rfc6838.html#page-15)
  • no provision for directives that institute actions on a recipient's files or other resources
  • no provision for directives that lead to disclosure of information
  • highlight opportunity for use of compression, highlight that the application layer: netCDF handles decompression on data access
  • no need for services for security assurance
• Interoperability Considerations
  • no known limitations
• Published specification (https://www.rfc-editor.org/rfc/rfc6838.html#page-18 )
  • netCDF Specification reference
• Application Usage
  • scientific data sharing
  • multidimensional arrays of numerical data
• Fragment Identifier Considerations
  • no fragment identifier considerations
• Restrictions on Usage
  • no restrictions on use
• Provisional Registrations (https://www.rfc-editor.org/rfc/rfc6838.html#page-20)
  • unclear if this is required, worthy of consideration
• Additional Information
  • Magic numbers
    • ?
  • File Extensions
    • .nc
• intended Use
  • common

[marqh]

@WardF, @lesserwhirls, @dopplershift, @ethanrd, @jyucsiro, @adamml

Does this look like the making of a submission to IANA?

What could Jonathan, Adam or i do to help or facilitate this submission?

[marqh]

https://www.rfc-editor.org/rfc/rfc6838.html#page-20 describes the provisional registration process:

A provisional registration MAY be submitted to IANA for standards-tree types. The only required fields in such registrations are the media type name and contact information (including the standards-related organization name). Upon receipt of a provisional registration, IANA will check the name and contact information, then publish the registration in a distinct publicly visible provisional registration list.

Would you be interested in expediting a provisional registration to facilitate us updating the OGC work to include this whilst we work through the formal registration details & process?

[ethanrd]

Hi @marqh - I reviewed the registration process a bit last week and expanded a bit on your application material here. I'll create a PR shortly.

I was wondering if a provisional registration would be useful. I'm open to moving forward with that if it helps the netCDF-LD effort in terms of using a media type in your OGC docs. Thoughts @WardF, @lesserwhirls, @dopplershift, @DennisHeimbigner ?

[lesserwhirls]

I would support pushing a provisional registration forward.

[ethanrd]

@marqh and all - RFC 6838 section 4.4 “Canonicalization and Format Requirements” says:

All registered media types MUST employ a single, canonical data format, regardless of registration tree.

Thoughts on implications for netCDF-3 and netCDF-4?

I'd prefer a single media type. Most current netCDF implementations can read either so don't need a media type to tell them the difference. However, the nc-3 and nc-4 are quite different and so perhaps should be separate. (Too bad HDF5 doesn't already have a media type. Then we could consider registering "application/netcdf" and "application/netcdf+hdf5".)

[marqh]

hello @ethanrd (with apologies for thee overly long response delay)

i think that the differences between nc-3 and nc-4 are at a library and installation management level, not at a specification level.

I think the fact that nc-4 requires HDF is an application support detail, which is well handled by installation options such as package managers

As such i am in favour of a single registration of application/netcdf

rather than multiple registrations

i understand the waryness about https://www.rfc-editor.org/rfc/rfc6838.html#section-4.4 and i do recognise a nuance here.

But, i think that the netCDF libraries protect users from the encoding details, particularly on read, and that there is real benefit from seeing the netCDF interface as encoding agnostic, therefore there being a single media type from the perspective of use

[marqh]

I also think that provisional registration would be useful,

For example, it would allow us to reference the registration in the upcoming netCDF-LD standard proposal without having to wait for a full registration completion before using the term in the OGC document

many thanks mark

[ethanrd]

Hi @marqh - I agree, a single netCDF media type seems the way to go.

I will look into requesting a provisional registration.

[ethanrd]

Hi @marqh, @ogcscott, and all,

I heard back from IANA:

We've added the following entry to the provisional standard media type registry:

Media Type: application/netcdf Organization: Unidata Reference: Ethan Davis

Please see https://www.iana.org/assignments/provisional-standard-media-types

So we can start using "application/netcdf" as the netCDF media type.

Next step is to refine the draft registration information in PR #45 and get it ready to submit to IANA for the full registration. I will plan to make another pass at that in the next month or so.

Cheers, Ethan

[marqh]

that's great progress @ethanrd we'll put updates in place for this many thanks mark

[jerstlouis]

@ogcscotts @ethanrd Is this effort to register the official netCDF media type on-going?

It would be great if a parameter was defined to pick a particular version, since they're not backward compatible and considerably different. In the OGC 10-090r3 Core encoding standard these are called "encoding extension" which are defined separately (e.g. in OGC 10-092r3 NetCDF Binary Encoding Extensions Standard: NetCDF Classic and 64-bit Offset Format). I also don't see a reference to the netCDF 4 from https://www.ogc.org/standard/netcdf/ , which use HDF5 if I understand correctly? Is there also an OGC Standard for these encoding extensions? And CDF5 is something else from the Parallell netCDF project?

For OGC API - Coverages and OGC API - DGGS, we need to define a clear mechanism on how client and server negotiate netCDF content, and simply Accept: application/netcdf may not guarantee interoperability if the client is not ready to accept all possible versions aka encoding extensions.

Thanks!