[media-types] Re: [IANA #1453973] application/vnd.mo hnetic registration request
"Murray S. Kucherawy" <[email protected]> Tue, 14 Jul 2026 22:37:14 -0700
| Newsgroups | gmane.ietf.types |
|---|---|
| Message-ID | <CAL0qLwbstTTOdcUoVYthtJYuisSSy1_NUQU3nLuXrWoF_Xnotw@mail.gmail.com> |
--===============4844349523595250832== Content-Type: multipart/alternative; boundary="000000000000fd797306569fb744" --000000000000fd797306569fb744 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Approved with those changes. -MSK On Thu, Jun 25, 2026 at 9:34=E2=80=AFPM Amanda Baber via RT < [email protected]> wrote: > Hi Murray, > > We have a response from the requester: > > Please find below a reformatted version of the interoperability > considerations section with proper line breaks: > > =3D=3D=3D > > 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 manda= te > 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 architectu= re. > > - 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.mohneti= c > 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 happ= y > 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. > > =3D=3D=3D > > 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=E2=80=AFPM 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? > > > > =3D=3D=3D=3D=3D > > > > > > 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 > > --000000000000fd797306569fb744 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Approved with those changes.<div><br></div><div>-MSK</div>= </div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr"= class=3D"gmail_attr">On Thu, Jun 25, 2026 at 9:34=E2=80=AFPM Amanda Baber = via RT <<a href=3D"mailto:[email protected]">iana-mime-comment@= iana.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D= "margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le= ft:1ex">Hi Murray,<br> <br> We have a response from the requester:<br> <br> Please find below a reformatted version of the interoperability considerati= ons section with proper line breaks:<br> <br> =3D=3D=3D<br> <br> Interoperability considerations:<br> <br> The media type is restricted to ecosystem-specific internal processing, del= iberately eliminating general-purpose cross-platform compatibility requirem= ents. In accordance with RFC 6838, Section 4.5, it does not mandate specifi= c hardware or operating system architectures.<br> <br> Platform Independence: The data structure relies on a standardized, platfor= m-independent byte order (big-endian). It remains entirely independent of s= pecific operating systems, hardware architectures, or CPU endianness.<br> <br> Ecosystem Restriction: This format is explicitly designed for consumption a= nd generation by a single proprietary SaaS platform. It is not intended for= generic cross-platform interoperability, public data exchange, or processi= ng by third-party applications.<br> <br> Version Control: Future iterations or structural changes to the internal en= crypted payload will be governed internally by explicit version flags embed= ded within the file header. This mechanism ensures backward compatibility o= r predictable fallback behavior within the SaaS architecture.<br> <br> - Regarding the reviewer's question about the registration tree, the Sa= aS platform is currently under development but is intended to be a publicly= available commercial service. Although the media type itself describes a p= roprietary 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 registrat= ion remains the appropriate choice.<br> <br> - Regarding the change controller section, I understand the reviewer's = concern. My intention was only to indicate that the media type specificatio= n is maintained by the designated change controller, not to restrict the IE= TF's or IANA's established procedures. I am therefore happy to simp= lify this field to:<br> <br> Author/Change controller: Kostiantyn Cherednychenko<br> <br> Please let me know if there are any additional changes or clarifications th= at would help move the registration forward.<br> <br> =3D=3D=3D<br> <br> Does this work with those edits?<br> <br> thanks,<br> Amanda<br> <br> On Thu Jun 25 00:30:26 2026, <a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a> wrote:<br> > On Tue, Jun 9, 2026 at 5:50=E2=80=AFPM Amanda Baber via RT <<br> > <a href=3D"mailto:[email protected]" target=3D"_blank">iana-m= [email protected]</a>> wrote:<br> > <br> > > Hi Murray,<br> > ><br> > > Could you review this one by June 23rd?<br> > ><br> > <br> > Sorry, I missed this until now.<br> > <br> > <br> > > Also, could you check that there aren't any issues with the c= hange<br> > > controller language? I did let him know that we'd make format= ting<br> > > changes<br> > > and add registration/last-updated dates, but said we'd ask hi= m to<br> > > supply or<br> > > approve any changes required for registration.<br> > <br> > <br> > I don't think it's reasonable to assert that the IETF or IESG = can't<br> > change<br> > this in some circumstance where doing so might be necessary.=C2=A0 On = the<br> > flipside, the IETF or IESG wouldn't impose a change without at lea= st<br> > trying<br> > to communicate with the change controller.<br> > <br> > Do we have any precedent of another registration making this demand?<b= r> > <br> > =3D=3D=3D=3D=3D<br> > ><br> > > Name: Kostiantyn Cherednychenko<br> > ><br> > > Email: <a href=3D"mailto:[email protected]" target=3D"_blank">moh= [email protected]</a><br> > ><br> > > Media type name: application<br> > ><br> > > Media subtype name: vnd.mohnetic<br> > ><br> > > Required parameters: N/A.<br> > ><br> > > Optional parameters: N/A.<br> > ><br> > > Encoding considerations: binary<br> > ><br> > > Will be used only my SaaS platform to keep the encrypted customer= s<br> > > data<br> > > which is exported from the platform.<br> > ><br> > <br> > I'm interested in "my" here.=C2=A0 Should this be on the= "prs" tree instead<br> > of<br> > "vnd"?<br> > <br> > <br> > > Security considerations: The media type comprises statically<br> > > encrypted,<br> > > non-executable data requiring robust, native, and external privac= y<br> > > and<br> > > integrity protections, in accordance with RFC 6838, section 4.6. = It<br> > > employs<br> > > a proprietary binary format without using compression or external= <br> > > references, ensuring no risks related to container parsing or<br> > > external<br> > > resource fetching. Detailed security considerations are provided<= br> > > below,<br> > > which address all IANA requirements.<br> > ><br> > > (1) Active or Executable Content: The media type does not contain= any<br> > > active, executable, or interpretable content. The files consist<b= r> > > entirely of<br> > > static, encrypted data intended for storage or transit, which can= not<br> > > be<br> > > executed by the receiving system or any interpreter.(<br> > ><br> > > 2) Privacy and Integrity Needs: Yes, the information contained in= <br> > > this<br> > > media type represents sensitive customer data and requires robust= <br> > > privacy<br> > > and integrity protections to prevent unauthorized access or<br> > > tampering.<br> > ><br> > > (3) Provision of Privacy and Integrity Services: Privacy and<br> > > integrity are<br> > > handled both natively and externally:Natively: The payload itself= is<br> > > fully<br> > > encrypted at rest using strong cryptographic standards prior to<b= r> > > export from<br> > > the SaaS platform, ensuring privacy. Integrity is maintained nati= vely<br> > > through cryptographic signatures or message authentication codes<= br> > > (MACs)<br> > > embedded within the encrypted data structure.Externally: When<br> > > transported<br> > > over networks (such as downloading from the SaaS platform),<br> > > transport-layer<br> > > security (SSL/TLS) must be used to provide external privacy and<b= r> > > integrity<br> > > protections.<br> > ><br> > > (4) Underlying Format Considerations: The media type is structure= d as<br> > > a<br> > > proprietary binary envelope wrapping the encrypted payload. It do= es<br> > > not<br> > > natively employ XML, JSON, or any other high-level text-based<br> > > serialization<br> > > format prone to expansion or parsing exploits.<br> > ><br> > > (4a) Compression Considerations: This media type does not employ<= br> > > compression algorithms. Therefore, it is not vulnerable to<br> > > compression-related security risks, such as decompression bombs (= zip<br> > > bombs)<br> > > or side-channel attack vectors like CRIME or BREACH.<br> > ><br> > > (4b) Container Format Considerations: This media type does not<br= > > > utilize a<br> > > generic container format (such as ZIP or OCF). It is a monolithic= <br> > > encrypted<br> > > data file, eliminating security issues related to container<br> > > traversal,<br> > > archive loops, or malicious file inclusion.<br> > ><br> > > (5) External Links and References: The media type does not<br> > > incorporate any<br> > > external links, URIs, or remote references. All data required to<= br> > > store or<br> > > eventually decrypt the file (given the correct keys) is contained= <br> > > entirely<br> > > within the file itself or managed securely by the originating Saa= S<br> > > platform. Proper interpretation of the type does not rely on fetc= hing<br> > > external resources.<br> > ><br> > > Interoperability considerations: The media type is restricted to<= br> > > ecosystem-specific internal processing, deliberately eliminating<= br> > > general-purpose cross-platform compatibility requirements. In<br> > > accordance<br> > > with RFC 6838, section 4.5, it does not mandate specific hardware= or<br> > > operating system architectures. Detailed interoperability<br> > > considerations<br> > > are outlined below.Interoperability ConsiderationsPlatform<br> > > Independence:<br> > > The data structure relies on a standardized, platform-independent= <br> > > byte<br> > > order (big-endian). It remains entirely independent of specific<b= r> > > operating<br> > > systems, hardware architectures, or CPU endians.Ecosystem<br> > > Restriction: This<br> > > format is explicitly designed for consumption and generation by a= <br> > > single<br> > > proprietary SaaS platform. It is not intended for generic cross-<= br> > > platform<br> > > interoperability, public data exchange, or processing by third-pa= rty<br> > > applications.Version Control: Future iterations or structural cha= nges<br> > > to<br> > > the internal encrypted payload will be governed internally by<br> > > explicit<br> > > version flags embedded within the file header. This mechanism ens= ures<br> > > backward compatibility or predictable fallback behavior within th= e<br> > > SaaS<br> > > architecture.<br> > ><br> > <br> > There's some formatting weirdness here.<br> > <br> > <br> > > Published specification: There is no publicly available technical= <br> > > specification for this media type. The internal data structures,<= br> > > cryptographic layouts, and encoding schemas are proprietary to th= e<br> > > originating SaaS platform. The format is explicitly reserved for<= br> > > private<br> > > use and internal ecosystem processing.<br> > ><br> > <br> > This also makes me wonder why we're not using the "prs" = tree.=C2=A0 "vnd"<br> > is<br> > reserved for publicly available products; is this Saas platform<br> > publicly<br> > available?<br> > <br> > <br> > > Applications which use this media: This media type is utilized<br= > > > exclusively<br> > > by the originating SaaS platform and its authorized client<br> > > applications<br> > > (such as official desktop utilities, companion sync tools, or<br> > > browser-based<br> > > dashboard download managers). It facilitates the secure export,<b= r> > > backup,<br> > > offline archival, and subsequent re-import of encrypted customer = data<br> > > back<br> > > into the SaaS platform. It is not processed, read, or modified by= any<br> > > third-party or general-purpose applications.<br> > ><br> > > Fragment identifier considerations: The media type does not defin= e or<br> > > support fragment identifiers. The internal payload consists of<br= > > > encrypted<br> > > binary data that must be decrypted and processed as a single,<br> > > monolithic<br> > > file. Addressing, referencing, or extracting individual fragments= or<br> > > sub-resources using a fragment identifier (e.g., appended #fragme= nt<br> > > syntax)<br> > > is not meaningful and is not supported. See RFC 6838, section 4.3= .<br> > ><br> > > Restrictions on usage: This media type is restricted solely to th= e<br> > > storage<br> > > and transit of encrypted data generated by the specific SaaS<br> > > platform. It<br> > > must not be used for unencrypted text, generic file distribution,= or<br> > > general-purpose data exchange. Use of this media type is strictly= <br> > > limited<br> > > to environments that can safely handle the platform's proprie= tary<br> > > cryptographic protocols.<br> > ><br> > > Provisional registration? (standards tree only): No<br> > ><br> > > Additional information:<br> > ><br> > > 1. Deprecated alias names for this type: None<br> > > 2. Magic number(s): None<br> > > 3. File extension(s): mohnetic<br> > > 4. Macintosh file type code: None<br> > > 5. Object Identifiers: None<br> > ><br> > > Person to contact for further information:<br> > ><br> > > 1. Name: Kostiantyn Cherednychenko<br> > > 2. Email: <a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a><br> > ><br> > > Intended usage: LIMITED USE<br> > ><br> > > Author/Change controller: Author/Change controller: Kostiantyn<br= > > > Cherednychenko<br> > > The definition, evolution, and maintenance of this media type are= <br> > > entirely<br> > > controlled by the change controller. The IETF and IANA have no<br= > > > authority to<br> > > alter or update this registration without explicit authorization = from<br> > > the<br> > > designated controller.<br> > ><br> > <br> > At a minimum I'd ask the IESG for an opinion about this, per my<br= > > comments<br> > above.<br> > <br> > -MSK<br> <br> </blockquote></div> --000000000000fd797306569fb744-- --===============4844349523595250832== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWVkaWEtdHlw ZXMgbWFpbGluZyBsaXN0IC0tIG1lZGlhLXR5cGVzQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNl bmQgYW4gZW1haWwgdG8gbWVkaWEtdHlwZXMtbGVhdmVAaWV0Zi5vcmcK --===============4844349523595250832==--