Michael, Could you share what scenarios you envision for clients processing an application/eat+cwt as a cwt without understanding what an eat is?
It is my understanding that structured suffixes are not intended to convey instructions on how to parse a media type, but to provide a clients that are not familiar with the specific media type the ability to fall back to the more generic semantics of the suffix. https://www.rfc-editor.org/rfc/rfc6839.html#section-2 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. Darrel ________________________________ From: media-types <[email protected]> on behalf of Michael Richardson <[email protected]> Sent: Friday, April 7, 2023 9:17 PM To: Roy Williams (COSINE) <[email protected]> Cc: Ned Smith <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: [media-types] [Rats] registration for +cwt Roy Williams (COSINE) <[email protected]> wrote: > The question I have is if CBOR and COSE are simply > content-transfer-encodings and not content-type. This gets into a > nebulous area when discussing reasoning over volumes of data. > If all the content is signed it would show as homogenous data > application/cose and thus any filtering would require tunnelling into > the payload which could be expensive. Don't forget Accept: headers. CBOR/COSE are not CTE. (Base64 is CTE) -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
