[media-types] Re: Ideas for Multipart Media Types

Martin,

Hello. Thank you. Here is a hyperlink which shows where these ideas are useful: https://github.com/AdamSobieski/Narratology/blob/main/Content/Concepts.md . There, I am exploring defining concepts using declarative multipart-MIME techniques.

One could apply a difference or patch to a resource on a server, cache the result there, and then send it to clients and this would tend to be more efficient in multiple ways. However, when a difference or patch can be read and analyzed by clients, combinations of provided or referenced "base" resources with such readable differences or patches could have a declarative value. That is, the expression: "X is based on Y but differs in way D" has a value when clients can read and analyze both a "Y" and a "D" to use to compute and obtain an "X" or to, instead, use these to verify that the expression holds for them and an accompanying, provided "X".

Also, I am excited to share another idea for a multipart type for any comments, feedback, and discussion: "multipart/reference" (or, perhaps, "multipart/sourced"). As envisioned, this multipart type would have uses including for inter-process communication scenarios, e.g., clipboard and drag-and-drop. These recent ideas are presented here: https://github.com/w3c/clipboard-apis/issues/247 and also described below:



multipart/reference (or multipart/sourced)

This multipart type would contain two parts, the first part being content or data and the second part serving as source material(s) or reference(s) for the first. Examples of content types include "text/plain" and "application/xhtml+xml". Examples of reference types include "text/x-bibtex" and "application/ld+json".



Best regards,
Adam
________________________________
From: Martin J. Dürst <[email protected]>
Sent: Tuesday, February 3, 2026 4:31 AM
To: Adam Sobieski <[email protected]>; [email protected] <[email protected]>
Subject: Re: [media-types] Ideas for Multipart Media Types

Hello Adam,

Your proposals look good in theory (some of them are directly taken from
(set) theory).

But have you actually found any demand for these? My main argument
against it is that e.g. instead of sending a number of documents and ask
the receiver to take the difference, it would be much more efficient
(smaller) to take the difference on the sender's side and only send the
result.

Regards,   Martin.

On 2026-01-30 11:40, Adam Sobieski wrote:
> IETF Media Type Maintenance Working Group,
>
> Hello. Per Media Type Specifications and Registration Procedures, Section 5, Media Type Registration Procedures, I am writing this informal letter to "solicit comments and feedback on the choice of type/subtype name, the unambiguity of the references with respect to versions and external profiling information, and a review of any interoperability or security considerations."
>
> I welcome any comments, feedback, and discussion about the following four ideas.
>
>
>
> multipart/template
>
> This multipart type would be for multiple parts which, together, could be used to create output resources using template-processing engines. The multiple input parts would be comprised of: (1) a required template resource, (2) an optional scripting-language resource for providing helper functions, and (3) an optional input data resource.
>
> Examples of template formats include Handlebars ("text/x-handlebars-template"). Examples of scripting formats for providing optional helper functions include JavaScript ("text/javascript"). Examples of optional input data formats include JSON ("application/json").
>
> As considered, this multipart type would have a parameter for specifying the media type of the resultant output content to be produced by a template-processing engine using the input parts.
>
> For example: "multipart/template;output='application/xhtml+xml'"
>
>
>
> multipart/difference
>
> This multipart type would be for multiple parts which, together, could be used to apply differences or patches to input resource to create output resources using difference-applying engines. The multiple input parts would be comprised of: (1) a required input resource to apply a difference or patch to, and (2) a required difference or patch to apply.
>
> Examples of difference or patch formats include: "text/x-diff" and "text/x-patch".
>
> As considered, this multipart type would have a parameter for specifying the media type of the resultant output content to be produced by a difference-applying engine using the input parts.
>
> For example: "multipart/difference;output='application/xhtml+xml'"
>
>
>
> multipart/intersect
>
> This multipart type would be for multiple parts capable of being intersected to create a resultant output resource. Examples of formats capable of being intersected include knowledge-graph formats such as "text/turtle".
>
> As considered, this multipart type would have a parameter for specifying the media type of the resultant output content to be produced by an intersection algorithm using the input parts.
>
> For example: "multipart/intersect;output='text/turtle'"
>
>
>
> multipart/union
>
> This multipart type would be for multiple parts capable of being unioned to create a resultant output resource. Examples of formats capable of being unioned include knowledge-graph formats such as "text/turtle".
>
> As considered, this multipart type would have a parameter for specifying the media type of the resultant output content to be produced by a union algorithm using the input parts.
>
> For example: "multipart/union;output='text/turtle'"
>
>
>
> Thank you for any comments, feedback, or discussion about these ideas. Thank you for any information about guidelines for creating formal proposals or specifications for multipart media types.
>
>
> Best regards,
> Adam Sobieski
> http://www.phoster.com
>
>
>
>
> _______________________________________________
> media-types mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

--
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

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