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