Re: [media-types] [Rats] registration for +cwt

[Darrel Miller <[e-mail]>]

Michael,

> From: Michael Richardson
> Sent: Sunday, April 30, 2023 4:43 PM
>
>  > Could you share what scenarios you envision for clients processing an
>  > application/eat+cwt as a cwt without understanding what an eat is?

> Yes, any kind of network diagnostics program (tcpdump, wireshark, ssldump),

I can see that WireShark has display filters for cbor https://www.wireshark.org/docs/dfref/c/cbor.html 
but I don't see any reference to native +cwt support.  I'm guessing it requires doing configuration to map +cwt to the CBOR display filter.  
If that is the case, why not just map application/eat;format=cwt to the CBOR display filter?  That way you can also map application/eat;format=eat-bun+cbor etc, to the CBOR filter.

> or any kind of desktop system that tags files with MIME types and can start
> programs the look at them.

If a user has to do the mapping between mime types and programs, then I don't see how registering the +cwt suffix makes this any easier.  If tooling hasn't already implemented fallback for rendering +cbor content types automatically, then it is not likely that +cwt, an even more specialized suffix will get adoption.  Worse, it could fragment implementation efforts.   

> > I get the impression that primary goal of registering the set of media
> > types
> > https://www.ietf.org/archive/id/draft-ietf-rats-eat-media-type-01.txt
> > is to provide decoding instructions rather than conveying additional
> > semantics.  I wonder whether registering just "application/eat" and a
> > "format" parameter might be a simpler solution.

> I don't believe so.

I don't believe that the intent of suffixes was to provide a generalized "inheritance" hierarchy of semantics.  My understanding is that they are intended to provide the ability for generic tools to gracefully degrade in how specialized media types are processed.  This is very similar to how HTTP clients that don't understand the meaning of a 422 can legally treat the response status as a 400.

The introduction of +cwt is going to lead us down the path of people asking the question "should this new media type be application/foo+cwt or application/foo+cbor or application/foo+cwt+cbor".  That's not a place we want to be.

I acknowledge that +jwt already has been registered.  However, the situation is slightly different because JSON Web Tokens are not encoded as JSON, therefore there is some value in having the +jwt suffix to indicate that the content is encoded as:
   "a series of base64url-encoded values (with trailing '=' characters removed), some of which may be the empty string, separated by period ('.') characters."

It is my understanding that application/cwt is cbor and therefore +cbor is sufficient for generic clients to gracefully degrade.


Regards,

Darrel