> +cwt is also three layers: CBOR, COSE, and then CWT claims inside the signed > part. So, if we'd call it application/eat+cwt, then we ought also call it > application/voucher+ysid Wouldn't it be "application/cbor+cose+ysid+voucher" given the +cwt context and ordering convention in I-D.ietf.mediaman-suffixes?
On 4/3/23, 12:10 PM, "RATS on behalf of Michael Richardson" <[email protected] <mailto:[email protected]> on behalf of [email protected] <mailto:[email protected]>> wrote: Orie Steele <[email protected] <mailto:[email protected]>stries> wrote: > At IETF 116 this draft was discussed: > - https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes > <https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes> - > https://youtu.be/BrP1upACJ0c?t=1744 <https://youtu.be/BrP1upACJ0c?t=1744> > TLDR; there is work in progress to define multiple suffixes, and how > they are interpreted. Right, I read through mediaman-suffixes. I got the feedback that we should use the most specific type available. >> Luckily because COSE is just "plain CBOR" itself , we can use the >> subtype '+cbor'. So having "voucher-cose+cbor" would be fine. Also I don't understand why it's not application/voucher+cose+cbor. The outer encoding is cbor, the next layer is cose. There is the a third layer which is `yang-core`. (It seems that we ought to call this "ysid"? or maybe +cst. ) +cwt is also three layers: CBOR, COSE, and then CWT claims inside the signed part. So, if we'd call it application/eat+cwt, then we ought also call it application/voucher+ysid It seems that we ought to have registered +ysid in RFC9254. Can we do it in draft-ietf-core-sid-20? -- Michael Richardson <[email protected] <mailto:[email protected]>> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
