Re: [Anima] [media-types] Thoughts on suffixes, single and multiple

[Mark Nottingham <[e-mail]>]

Hi Michael,

> On 5 Apr 2024, at 07:21, Michael Richardson <[e-mail]> wrote:
> 
> We in ANIMA have been struggling because we have an artifact, a voucher
> (YANG defined in RFC8366, being revised/extended in 8366bis), which can be in
> two major formats: JSON and CBOR (in theory, XML too), but can be signed by
> three formats (CMS, JWS, COSE).
> 
> That gives us three major variations today:
> 1) application/voucher-cms+json  aka voucher+json+cms?
> 2) application/voucher+cose      or? voucher+cbor+cose?
> 3) application/voucher-jwt+json  aka voucher+json+jwt?
> 
> (because CMS signing CBOR seems dumb, as does mixing {JSON,CBOR} X {JWS,COSE})

It would be very helpful if you could give us insight into why it's important to surface the signature format (CMS, JWS, COSE) in the media type **in a manner that's apparent to consumers who don't understand the semantics of the specific media type**. If it only needs to be apparent to the application-specific software processing the voucher, you could easily use application/voucher-cms+json -- and you may even be able to use application/voucher+json if the format is capable of distinguishing between signature formats internally.

Your question also highlights the confusion and a problem around suffixes. If you use application/voucher+json+cms, it means that generic software that expects to see +json as the last component of the media type suffix (for an example, a web browser that can display "pretty" JSON, which at this point is theoretical, but it's the best example we have for suffixes) will not recognise it. However, if you use application/voucher+cms+json, generic software that expects +cms to be the final suffix won't function correction. 

> Also, +gzip makes it pretty clear you can maybe do something with it, if you
> just know how to decompress.

But what does it imply? For example, if I see application/foo+xml+gzip, can I assume that application/foo+xml is also registered, and that decompressing will result in something that conforms to it? If so, that gets us back into the processing model mess that's bedevilled the WG for a long time.

> So, +jwt and +cose says, "this is a signed object, and if you look in the
> payload slot, you might find something you might know how to decode" (or not)
> 
> But, for many formats they only appear in a signed form in the wild, so maybe
> this just doesn't matter.

To ask the questions above in a slightly different way: To whom are +jwt and +cose speaking to here, other than the code handling the specific media type?

Cheers,


--
Mark Nottingham   https://www.mnot.net/