Re: [media-types] Rethinking Media Types

One of the things that's a bit painful with media types as they are right
now is when you have envelope formats. (I'm not sure what the correct term
for this is, if there even is one, so this is the term I'm using here :)

For example, RFC-9457 defines "application/problem+json". This is actually
just a Problem Details schema represented in JSON - so the envelope is
"application/json" and the schema inside that is the Problem Details. And
this is highlighted by the fact that there's also "application/problem+xml"
for the exact same content but in a different envelope.

Right now we get away with this using the structured suffixes from
RFC-6839, but that's a bit awkward and only gets you so far. For example,
another one that uses this is "application/hal+json". That's a HAL schema
represented in JSON. Except that HAL itself is also an envelope format - it
defines some parts of the JSON and leaves the rest undefined. And without
knowing what the schema is of the rest of that document, you don't know how
to understand it.

That, in turn, means that you'd ideally want some way to specify what the
schema is inside the HAL document - which right now is left down to e.g. a
"Link" header with the "describedby" link relation, or an "_links" entry
for the same, or something like that. (And some of these formats have this
built-in - e.g. the "class" field in Siren or the "@type" field in JSON-LD.)

And then you get even more awkward things like HAL-Forms, which I've seen
used as an extension to the HAL format but under a different media type. So
now we have a response that is: JSON, encoding a HAL document, with the
HAL-Forms content as an extension, wrapping a particular schema. And
fitting all of that into a single media type value is stretching things a
bit...

Cheers

On Thu, 9 Jan 2025 at 18:01, Rahul Gupta <cxres@protonmail.com> wrote:

> Hi Michael,
>
> I am not at all suggesting that media types are not already useful. If
> anything, quite the opposite, they are necessary to REST. To quote Roy
> Fielding <
> https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven>, "A
> REST API should spend almost all of its descriptive effort in defining the
> media type(s) used for representing resources and driving application
> state, or in defining extended relation names and/or hypertext-enabled
> mark-up for existing standard media types".
>
> My assertion here is that content negotiation can be more powerful with
> better evolvability characteristics, if media types could be made modular.
> It will make it easier to define formats with greater specificity, without
> a proliferation of media-types (which comes with a registration burden).
>
> BR/Rahul
>
>
> On Thursday, January 9th, 2025 at 10:12 PM, Michael Jones <
> michael_b_jones@hotmail.com> wrote:
>
> For the record, I find Media Types as they exist extremely useful.  They
> enhance the usability and security of the Internet by providing a
> widely-deployed typing mechanism for data structures.
>
>
>
> Note that media types are used in many contexts, including:
>
>    - HTTP Content-Type Headers
>    - JWT “typ” and “cty” values
>    - CWT “typ” and “cty” values
>
>
>
> They increase the security of JWTs by preventing cross-JWT confusion, as
> described at
> https://datatracker.ietf.org/doc/html/rfc8725#name-use-explicit-typing.
>
>
>
> Yes, they declare that the content is of a specific type.  I view that as
> a feature – not a bug.
>
>
>
> For what it’s worth…
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Rahul Gupta <cxres=40protonmail.com@dmarc.ietf.org>
> *Sent:* Tuesday, January 7, 2025 3:22 AM
> *To:* media-types@ietf.org; ietf-http-wg@w3.org
> *Subject:* [media-types] Rethinking Media Types
>
>
>
> Fellow Media Type Enthusiasts,
>
>
>
> As someone working on malleable software, I have felt for sometime that
> the monolithic nature of media-types makes them a cumbersome and possibly
> inadequate mechanism for communicating data formats. The “animated”
> discussions and the “consensus by exhaustion” on the suffixes draft, I
> find, are mere symptoms of this fundamental issue.
>
>
>
> At the very least, I find media-types are inadequate along two dimensions:
>
>
>
>    - Composability: A complex format might be constructed from simpler
>    formats. (This is separate from composite media-types like multipart which
>    are intended for enclosing multiple representations in a single message,
>    although composite media-types can be a possible mechanism for composition
>    of a single representation that built out of multiple media-types).
>    - Specificity: The contained data is described by progression in
>    specificity of formats intended for some specific purpose.
>
>
>
> There is certainly interplay between the dimensions. Case in point is the
> recent intention of W3C Verifiable Credentials WG to register, for example,
> `application/vc+sd-jwt` where a Verified Credential is augmented with
> Selective Disclosures, which are together packaged in a JSON Web Token
> format. The use of "+" and "-", even if standardized by convention, seems a
> really strange way to communicate this information. Or the recent request
> by 3GPP for 32 media-type registrations...yikes!
>
>
>
> Media-types were designed with the expectation that clients already have
> applications installed (or are able to download them) to read a specific
> (set of) media-types. Malleable software defy this expectation, with the
> “application” is constructed on the fly, with the ability to compose
> components that might process data in different formats. Conceivably,
> during content-negotiation a client can advertise its capabilities/intent
> (instead of requesting a specific content-type), and the server can
> construct a representation with metadata about its composition/specificity
> or even a recipe to deconstruct it. This should preserve REST constraints.
>
>
>
> There are perhaps other ways to solve this problem with the existing
> infrastructure, but none I know of are satisfactory. One method might be to
> split up the resource across multiple URLs (with link relations or
> similar), but the integrity of data is lost, and it also creates an
> unnecessarily chatty API. The ways in which representations might be
> combined is still limited. The proposed QUERY method might be another way,
> but the response is still constrained to one format.
>
>
>
> A few years ago, Filippos Vasilakis had proposed a solution for composable
> media-types, which he calls Introspective REST.
>
>
>
> + <https://github.com/vasilakisfil/Introspected-REST> (Read Section 9
> onwards)
>
> + <https://www.youtube.com/watch?v=pc8ZyFjJY4A>
>
>
>
> This thesis introduces the concept of micro-types, partial descriptions of
> formats that can be combined to construct the media-type of a resource. I
> even contacted Filippos (about the same period last year), but his
> (unreasonable) expectation was that IETF would approach him instead. While
> the proposal does not adequately resolve all the deficiencies of
> media-types, I think micro-types is certainly an interesting starting point
> for discussion.
>
>
>
> I believe that solving for composability and specificity with actually
> lead to fewer and simpler media-type being registered going forward. It
> will also be a better story for evolvability. Media-types can be
> progressively enhanced without breaking existing clients. Vendors will be
> able to introduce changes to formats most of the time without
> re-registration.
>
>
>
> I am not prejudiced to a solution. But thinking of ways we can move away
> from the status-quo of monolithic media-types is worth consideration.
>
>
>
> Looking forward to your feedback,
>
> BR/Rahul
>
>
>
>
>