[media-types] Re: [IANA #1444999] application/vnd.vn d.hdfgroup.hdf4 registration request

Amanda,

This is good other than the double vnd.

Darrel
________________________________
From: Amanda Baber via RT <[email protected]>
Sent: Tuesday, March 10, 2026 1:42 AM
Cc: [email protected] <[email protected]>; Darrel Miller <[email protected]>
Subject: [IANA #1444999] application/vnd.vnd.hdfgroup.hdf4 registration request

Hi Darrel,

Sending a reminder for this other request from February 26th. #2 of 2.

thanks,
Amanda

On Thu Feb 26 23:48:00 2026, amanda.baber wrote:
> Hi Darrel,
>
> Can you review this one by March 12th as well? It's #2 of 2.
>
> thanks,
> Amanda
>
> =====
>
> Name: Gerd Heber
>
> Email: [email protected]
>
> Media type name: application
>
> Media subtype name: vnd.vnd.hdfgroup.hdf4
>
> Required parameters: N/A.
>
> Optional parameters: N/A.
>
> Encoding considerations: binary
>
> Security considerations: HDF4 is a binary container format that can
> hold large, complex datasets and metadata. Implementations should
> treat files as untrusted input and defend against:
>
> - memory corruption and parser vulnerabilities in HDF4 libraries,
> - resource exhaustion (very large declared dimensions, many objects,
> deeply nested or highly fragmented structures),
> - decompression-related resource exhaustion if compression is used.
>
> HDF4 does not provide built-in mechanisms for confidentiality,
> integrity, or authentication; if such services are required, they must
> be provided externally (e.g., via transport security or encryption at
> rest).
>
> Interoperability considerations: Filename extensions are not a
> reliable indicator of the underlying format: the extension “.hdf” is
> commonly used for both HDF4 and HDF5 content (and may also be used for
> other HDF-family files). Implementations SHOULD identify content by
> inspecting the on-disk format signature rather than relying on
> extensions. HDF4 files begin with the 4‑byte header signature
> 0x0E031301 at offset 0. HDF5 files contain the 8‑byte signature
> 0x894844460D0A1A0A at offset 0, or at offset 512 and successive
> powers-of-two multiples (to allow an optional user block). If the
> expected signature is not present, the content SHOULD be treated as
> unknown or in a different format rather than inferred from the
> filename.
>
> Published specification: HDF Specification and Developer’s Guide (The
> HDF Group).
>
> https://zenodo.org/records/13754936
>
> Applications which use this media: Scientific/engineering data tools
> using the HDF4 library, including HDFView and domain-specific
> toolchains.
>
> Fragment identifier considerations: none
>
> Restrictions on usage: none
>
> Provisional registration? (standards tree only): No
>
> Additional information:
>
> 1. Deprecated alias names for this type: application/x-hdf (historic,
> unregistered)
> 2. Magic number(s): Hex (offset 0): 0E 03 13 01 (This is the 4-byte
> HDF file header signature.)
> 3. File extension(s): .hdf (common), .h4, .hdf4 (also seen)
> 4. Macintosh file type code: none known
> 5. Object Identifiers: none
>
> Person to contact for further information:
>
> 1. Name: The HDF Group
> 2. Email: [email protected]
>
> Intended usage: COMMON
>
> Author/Change controller: The HDF Group

_______________________________________________
media-types mailing list -- [email protected]
To unsubscribe send an email to [email protected]