> I don't understand why it's not application/voucher+cose+cbor.
> The outer encoding is cbor, the next layer is cose.
Well, the reason is clearly that the draft-ietf-mediaman-suffixes is just a
draft at the moment. Things may change there. We don't want to overhaul our
draft in this stage or wait until mediaman-suffixes is done, presumably?
So we have to assume for the near future only one suffix has a clearly defined
semantics.
So it's either
application/voucher+cbor
application/voucher+cose (if we register 'cose' in the IANA registry as
well)
Note that '+cbor' only refers to the outer CBOR encoding, that is, the fact
that the COSE data is CBOR itself. It doesn't refer to the fact that 'voucher'
itself is also (again) encoded in a particular form of CBOR.
If mediaman-suffixes in current state would be accepted and become RFC, then it
could optionally also be:
application/voucher+cose+cbor
(Note: this wouldn't be mandatory, though. All forms are still valid.)
If we want it could be extended to
application/voucher+ysid+cose+cbor
where '+ysid' would indicate it using the CBOR-YANG-SID encoding. This has the
benefit that a decoder that doesn't know about 'vouchers' but does know about
CBOR YANG/SID encoding and about COSE, can still represent the information to a
user in a readable form.
That said, for the constrained bootstrap procedure we are considering there's
no benefit as such in adding suffixes to the name. And especially not given the
draft status of multiple suffixes.
As you said also the following would be possible today:
application/voucher+ysid
if we register 'ysid' as being CBOR-YANG-SID that's included in a COSE wrapper.
I find this less useful than the first options of '+cbor' or '+cose' , it seems
too specific.
Esko
-----Original Message-----
From: Anima <anima-boun...@ietf.org> On Behalf Of Michael Richardson
Sent: Monday, April 3, 2023 21:10
To: c...@ietf.org; r...@ietf.org; anima@ietf.org
Subject: Re: [Anima] [COSE] [Rats] cose+cbor vs cwt in MIME types
Orie Steele <orie@transmute.industries> wrote:
> 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.
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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
