At IETF 116 this draft was discussed: - https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes - https://youtu.be/BrP1upACJ0c?t=1744
TLDR; there is work in progress to define multiple suffixes, and how they are interpreted. This would be relevant to potential future +cwt media types, it is already causing us some concern with respect to special cases of +jwt. Regards, OS On Mon, Apr 3, 2023 at 12:28 PM Smith, Ned <[email protected]> wrote: > 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> > > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
