Re: [media-types] Re: Rethinking Media Types

> so 11. 1. 2025 v 19:54 odesílatel Rahul Gupta <cxres@protonmail.com> napsal:
> 
> > Hi Glenn, Darrel,
> >
> > On Saturday, January 11th, 2025 at 10:24 PM, Darrel Miller <
> > darrel@tavis.ca> wrote:
> >
> > Glenn,
> >
> > > Why should media-types be modified/extended to solve these issues?
> > > Are media-types the right place to add this complexity and combinatorial
> > > explosion of types?  (I do not think so.)
> >
> > There is some value to having the type identifier in a header.  It
> > provides visibility to intermediaries without having to parse the content.
> > It does allow some form of conneg.

> > There is some value to having the type identifier in a header.
> >
> > To further add, the representation data is meant to communicate the state
> > of the resource. Embedding metadata in the data (a part of the intended
> > processing mechanism for the data in this case) is to break the intended
> > separation of concerns.

That "state of the resource" is in a specific data format, which can
include an enclosing description.  I don't see a problem here, other
than I don't think that is what you were thinking.

> > However, I agree exploding subtypes is not a good idea.  But media types
> > allow parameters, and I think they are ideal for doing this kind of type
> > identification for a media type that defines the processing model.

Sounds to me you are complaining about having to register types media
types, and yet continuing the argument of using parameters.

Don't get me wrong.  Registering media types is "a" solution.  However,
if you are registering tens or hundreds, then maybe there is a better
solution than overloading media types with that combinatorial explosion.

> > What if we could instead specify something like "Content-Type-Novelle:
> > wt(json(ld(vc+sd)))" with some form of standardized content arithmetic,
> > each string token being an registry reference.

[...]

> >                                         [...], but I would genuinely like
> > for us to explore if there might be a better way to describe the intended
> > processing mechanism than with a single type/subtype reference (even when
> > differentiated by parameters).

If you are averse to self-describing data "wt(json(ld(vc+sd)))" in the
data, and instead prefer a separate header, then why not use a separate
header?

e.g.
Content-Type: application/rahul (or even Content-Type: application/json)
Rahul-Representation: wt(json(ld(vc+sd)))

Rahul-Representation would not require registration of the *values*
where Content-Type does require registration of media types.
Rahul-Representation could require a format for its tokens.

On Sat, Jan 11, 2025 at 08:23:20PM +0100, Melvin Carvalho wrote:
> Thank you for the idea! However, introducing something like
> Content-Type-Novelle risks breaking interoperability and backward
> compatibility—e.g., intermediaries and legacy systems would struggle to
> parse wt(json(ld(vc+sd))), adding unnecessary complexity. Parameters seem a
> simpler, more compatible path forward.

That is a bit of hand-waving.  If an intermediary does not understand an
extended use, then an intermediary does not understand an extended use.

An intermediary that looks only for application/melvin might not
understand application/melvin+jwt just was it would not know to look
for a new header Melvin-Representation: wt(json(ld(vc+sd)))

Cheers, Glenn

Received on Saturday, 11 January 2025 20:19:05 UTC