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.
>
>
> 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.
>
>
> 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.
>
>
> I am not sure if parameters (as they are allowed today) alone provide a
> general solution because there is still ambiguity of how these
> registrations might be made and puts a burden on the registerer to
> anticipate which parameters might be needed in the future.  For example
> (without knowing much about Verifiable Credentials), if one wanted to avoid
> registering "application/vc+sd-jwt" the options might be:
>
>    - "application/jwt" that now allows a "contains" parameter which can
>    be set to "vc, sd"
>    - "application/vc+jwt" that now allows a "contains" parameter which
>    can be set to "sd"
>    - "application/vc" that now allows parameters "format" set to "jwt" &
>    "contains" set to "sd"
>
> I am not sure which of these is preferable? This is not to suggest that
> parameters are not useful in specific cases, as you have recommended to
> registerers in the 3gpp case.
>
> 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. This particular example
> might probably not be backwards compatibility, 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).
>

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.


>
>
> Darrel
>
>
> BR/Rahul
> BR/Rahul
>