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

Hi Murray,

We have a response from the requester:

Please find below a reformatted version of the interoperability considerations section with proper line breaks:

===

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.

Platform 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 endianness.

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.

- Regarding the reviewer's question about the registration tree, the SaaS platform is currently under development but is intended to be a publicly available commercial service. Although the media type itself describes a proprietary format that is used exclusively by the platform and its official client applications, the platform is not intended for private or personal use. For this reason, I believe that the application/vnd.mohnetic registration remains the appropriate choice.

- Regarding the change controller section, I understand the reviewer's concern. My intention was only to indicate that the media type specification is maintained by the designated change controller, not to restrict the IETF's or IANA's established procedures. I am therefore happy to simplify this field to:

Author/Change controller: Kostiantyn Cherednychenko

Please let me know if there are any additional changes or clarifications that would help move the registration forward.

===

Does this work with those edits?

thanks,
Amanda

On Thu Jun 25 00:30:26 2026, [email protected] wrote:
> On Tue, Jun 9, 2026 at 5:50 PM Amanda Baber via RT <
> [email protected]> wrote:
> 
> > Hi Murray,
> >
> > Could you review this one by June 23rd?
> >
> 
> Sorry, I missed this until now.
> 
> 
> > 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.
> 
> 
> I don't think it's reasonable to assert that the IETF or IESG can't
> change
> this in some circumstance where doing so might be necessary.  On the
> flipside, the IETF or IESG wouldn't impose a change without at least
> trying
> to communicate with the change controller.
> 
> Do we have any precedent of another registration making this demand?
> 
> =====
> >
> > 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.
> >
> 
> I'm interested in "my" here.  Should this be on the "prs" tree instead
> of
> "vnd"?
> 
> 
> > 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.
> >
> 
> There's some formatting weirdness here.
> 
> 
> > 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.
> >
> 
> This also makes me wonder why we're not using the "prs" tree.  "vnd"
> is
> reserved for publicly available products; is this Saas platform
> publicly
> available?
> 
> 
> > 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.
> >
> 
> At a minimum I'd ask the IESG for an opinion about this, per my
> comments
> above.
> 
> -MSK

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