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

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).`


> 

> Darrel
> 



BR/Rahul
BR/Rahul