It seems the early registrations focused on encoding formats for content to the right of the "+" like '+xml', '+json', '+cbor', '+der', while later registrations seem to include schema formats like '+jwt', '+sqlite3', and '+tlv'.
It would have been nice if the registry defined the right side for encoding formats and let the left side contain content / schema formats IMHO. That way, the parsers could scan for the "+" to identify if it supports the encoding format as a first pass operation. If it can't decode the first byte, then there's no point in going further. If it can decode, then the first byte/bytes may provide insight into what content is there. For example, a CBOR tagged structure. But additionally, the left hand side identifies schemas. Given many data structures can be integrity protected, signed, and encrypted. Supplying a value that describes a cryptographic enveloping schema / format seems like a reasonable requirement for the '-label' to the immediate left of the plus, e.g., "-cose+cbor". The data within the cryptographic envelope may follow a well-defined schema such as the RATS ar4si. E.g., "ar4si-cose+cbor". I don't see a problem with omitting the cryptographic envelope label if no envelope is provided. E.g., "ar4si-+cbor". JWT and CWT are both an envelope and a data model schema, so the cryptographic envelope could be inferred. But it wouldn't be incorrect to restate the obvious for the benefit of the parsers who only care about cryptographic wrapper processing. E.g., "jwt-jose+json" is still a reasonable way to encode 'jwt'. If there are content schemas that are to the left of some other content schema, then that can be accommodate easily by prepending another 'label-'. E.g., "ar4si-jwt-jose+json". This approach allows an initial parser / message router to get a view of all the parsers needed to fully inspect the message in advance of making an initial message routing decision which would enable efficient parser offload architectures. There could be different registries for the different types of structure "+label" for encoding formats only, "-label" to the immediate left of "+" for cryptographic enveloping, and application formats for the next left most content. To make processing even more efficient, the content-type-name should reverse the order based on outer-most format. E.g., "json+jose-jwt-ar4si". This way buffer only needs to contain the first bytes up to the '+' and so forth. I realize this goes beyond the initial focus of the discussion thread. But IETF is also concerned about the long-term future of the Internet and in optimizing wherever it makes sense. Content typing is just a form of deep packet inspection that goes beyond network framing. Cheers, Ned On 4/3/23, 12:33 AM, "RATS on behalf of Esko Dijk" <[email protected] <mailto:[email protected]> on behalf of [email protected] <mailto:[email protected]>> wrote: Hi, As for the questions mentioned on these slides: 1. "Is is '-cose+cbor' or '-cbor+cose' The registry https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml <https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml> lists the subtypes that one have after the '+' sign. 'cbor' is there but 'cose' is not. 'cwt' is also not there. So for the moment, registering a 'mytype+cose' or 'voucher+cose' or 'voucher-cbor+cose' is not possible now unless you would also register the '+cose' as a subtype. RFC 9052 did not choose to register the subtype '+cose', for whatever reason. Luckily because COSE is just "plain CBOR" itself , we can use the subtype '+cbor'. So having "voucher-cose+cbor" would be fine. Also "voucher+cbor" would be equally ok albeit a little bit less informative that it contains COSE. 2. "are they sufficiently different" (this is about application/voucher-cose+cbor and application/eat+cwt formats) The voucher is not a CWT format, e.g. it does not use the standardized CWT claims at all. It defines an own format within the constraints of YANG CBOR, while CWT does not use any YANG semantics. (Now converting the constrained Voucher format into a CWT based format would certainly be possible; but that's probably not the discussion intended by these slides.) Regards Esko PS more detailed info at https://github.com/anima-wg/constrained-voucher/issues/264 <https://github.com/anima-wg/constrained-voucher/issues/264> https://github.com/anima-wg/constrained-voucher/issues/263 <https://github.com/anima-wg/constrained-voucher/issues/263> -----Original Message----- From: Anima <[email protected] <mailto:[email protected]>> On Behalf Of Michael Richardson Sent: Monday, March 27, 2023 01:19 To: Thomas Fossati <[email protected] <mailto:[email protected]>>; Thomas Fossati <[email protected] <mailto:[email protected]>>; [email protected] <mailto:[email protected]>; [email protected] <mailto:[email protected]>; [email protected] <mailto:[email protected]> Subject: Re: [Anima] [Rats] cose+cbor vs cwt in MIME types Michael Richardson <[email protected] <mailto:[email protected]>> wrote: > COSE CHAIRS: can we have 5 minutes for this discussion? > I guess I can make two slides tomorrow and get Thomas to co-author them. I guess we didn't get any time at COSE. https://github.com/anima-wg/voucher/blob/main/presentations/ietf116-cose-mime-cwt.pdf <https://github.com/anima-wg/voucher/blob/main/presentations/ietf116-cose-mime-cwt.pdf> _______________________________________________ Anima mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/anima <https://www.ietf.org/mailman/listinfo/anima> _______________________________________________ RATS mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats> _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
