[media-types] [IANA #1453973] application/vnd.mohnetic registration request

Hi Murray,

Sending a reminder for this request from June 9th.

thanks,
Amanda

On Wed Jun 10 00:50:56 2026, amanda.baber wrote:
> Hi Murray,
> 
> Could you review this one by June 23rd?
> 
> Also, could you check that there aren't any issues with the change
> controller language? I did let him know that we'd make formatting
> changes and add registration/last-updated dates, but said we'd ask him
> to supply or approve any changes required for registration.
> 
> RFC 6838, Section 5.5 says, "The IESG may reassign responsibility for
> a media type.  The most common case of this will be to enable changes
> to be made to types where the author of the registration has died,
> moved out of contact, or is otherwise unable to make changes that are
> important to the community."
> 
> This is coming from an individual with a gmail address, though, rather
> than an organization that might change hands, and he says that it
> "will be used only my SaaS platform to keep the encrypted customers
> data which is exported from the platform."
> 
> thanks,
> Amanda
> 
> =====
> 
> Name: Kostiantyn Cherednychenko
> 
> Email: [email protected]
> 
> Media type name: application
> 
> Media subtype name: vnd.mohnetic
> 
> Required parameters: N/A.
> 
> Optional parameters: N/A.
> 
> Encoding considerations: binary
> 
> Will be used only my SaaS platform to keep the encrypted customers
> data which is exported from the platform.
> 
> Security considerations: The media type comprises statically
> encrypted, non-executable data requiring robust, native, and external
> privacy and integrity protections, in accordance with RFC 6838,
> section 4.6. It employs a proprietary binary format without using
> compression or external references, ensuring no risks related to
> container parsing or external resource fetching. Detailed security
> considerations are provided below, which address all IANA
> requirements.
> 
> (1) Active or Executable Content: The media type does not contain any
> active, executable, or interpretable content. The files consist
> entirely of static, encrypted data intended for storage or transit,
> which cannot be executed by the receiving system or any interpreter.(
> 
> 2) Privacy and Integrity Needs: Yes, the information contained in this
> media type represents sensitive customer data and requires robust
> privacy and integrity protections to prevent unauthorized access or
> tampering.
> 
> (3) Provision of Privacy and Integrity Services: Privacy and integrity
> are handled both natively and externally:Natively: The payload itself
> is fully encrypted at rest using strong cryptographic standards prior
> to export from the SaaS platform, ensuring privacy. Integrity is
> maintained natively through cryptographic signatures or message
> authentication codes (MACs) embedded within the encrypted data
> structure.Externally: When transported over networks (such as
> downloading from the SaaS platform), transport-layer security
> (SSL/TLS) must be used to provide external privacy and integrity
> protections.
> 
> (4) Underlying Format Considerations: The media type is structured as
> a proprietary binary envelope wrapping the encrypted payload. It does
> not natively employ XML, JSON, or any other high-level text-based
> serialization format prone to expansion or parsing exploits.
> 
> (4a) Compression Considerations: This media type does not employ
> compression algorithms. Therefore, it is not vulnerable to
> compression-related security risks, such as decompression bombs (zip
> bombs) or side-channel attack vectors like CRIME or BREACH.
> 
> (4b) Container Format Considerations: This media type does not utilize
> a generic container format (such as ZIP or OCF). It is a monolithic
> encrypted data file, eliminating security issues related to container
> traversal, archive loops, or malicious file inclusion.
> 
> (5) External Links and References: The media type does not incorporate
> any external links, URIs, or remote references. All data required to
> store or eventually decrypt the file (given the correct keys) is
> contained entirely within the file itself or managed securely by the
> originating SaaS platform. Proper interpretation of the type does not
> rely on fetching external resources.
> 
> Interoperability considerations: The media type is restricted to
> ecosystem-specific internal processing, deliberately eliminating
> general-purpose cross-platform compatibility requirements. In
> accordance with RFC 6838, section 4.5, it does not mandate specific
> hardware or operating system architectures. Detailed interoperability
> considerations are outlined below.Interoperability
> ConsiderationsPlatform Independence: The data structure relies on a
> standardized, platform-independent byte order (big-endian). It remains
> entirely independent of specific operating systems, hardware
> architectures, or CPU endians.Ecosystem Restriction: This format is
> explicitly designed for consumption and generation by a single
> proprietary SaaS platform. It is not intended for generic cross-
> platform interoperability, public data exchange, or processing by
> third-party applications.Version Control: Future iterations or
> structural changes to the internal encrypted payload will be governed
> internally by explicit version flags embedded within the file header.
> This mechanism ensures backward compatibility or predictable fallback
> behavior within the SaaS architecture.
> 
> Published specification: There is no publicly available technical
> specification for this media type. The internal data structures,
> cryptographic layouts, and encoding schemas are proprietary to the
> originating SaaS platform. The format is explicitly reserved for
> private use and internal ecosystem processing.
> 
> Applications which use this media: This media type is utilized
> exclusively by the originating SaaS platform and its authorized client
> applications (such as official desktop utilities, companion sync
> tools, or browser-based dashboard download managers). It facilitates
> the secure export, backup, offline archival, and subsequent re-import
> of encrypted customer data back into the SaaS platform. It is not
> processed, read, or modified by any third-party or general-purpose
> applications.
> 
> Fragment identifier considerations: The media type does not define or
> support fragment identifiers. The internal payload consists of
> encrypted binary data that must be decrypted and processed as a
> single, monolithic file. Addressing, referencing, or extracting
> individual fragments or sub-resources using a fragment identifier
> (e.g., appended #fragment syntax) is not meaningful and is not
> supported. See RFC 6838, section 4.3.
> 
> Restrictions on usage: This media type is restricted solely to the
> storage and transit of encrypted data generated by the specific SaaS
> platform. It must not be used for unencrypted text, generic file
> distribution, or general-purpose data exchange. Use of this media type
> is strictly limited to environments that can safely handle the
> platform's proprietary cryptographic protocols.
> 
> Provisional registration? (standards tree only): No
> 
> Additional information:
> 
> 1. Deprecated alias names for this type: None
> 2. Magic number(s): None
> 3. File extension(s): mohnetic
> 4. Macintosh file type code: None
> 5. Object Identifiers: None
> 
> Person to contact for further information:
> 
> 1. Name: Kostiantyn Cherednychenko
> 2. Email: [email protected]
> 
> Intended usage: LIMITED USE
> 
> Author/Change controller: Author/Change controller: Kostiantyn
> Cherednychenko
> The definition, evolution, and maintenance of this media type are
> entirely controlled by the change controller. The IETF and IANA have
> no authority to alter or update this registration without explicit
> authorization from the designated controller.

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