> Will there be a .cose file extension? Or will we still use .cbor?

Each media type that wants to use +cose would need to indicate what file 
extension it wants to use. This could be “.cose” or “.cbor” I think if nothing 
more specific is wanted. For application/voucher+cose, it is “.vch”.
The COSE RFC has defined “.cbor” as the file extension. 
(https://www.rfc-editor.org/rfc/rfc9052.html#section-11.3.1)

> Are there any fragment processing details, that need to be considered?

Currently not. Note that +cbor did define fragment considerations, even where 
cbor itself doesn’t have fragments, see 
https://datatracker.ietf.org/doc/html/rfc8949#section-9.5.
Similar text can be added for +cose.  It would be just saying that currently 
there is no fragment identification but a foo+cose can define its own fragment 
identification if it wants to. We could try to say it shorter than +cbor does.

Esko

From: Orie Steele <[email protected]>
Sent: Thursday, January 11, 2024 14:50
To: Esko Dijk <[email protected]>
Cc: cose <[email protected]>; [email protected]
Subject: Re: [COSE] Intended IANA registration of "+cose" media type suffix / 
cBRSKI

I think both SCITT and W3C Verifiable  Credentials have uses cases that would 
use this.

Will there be a .cose file extension? Or will we still use .cbor?

Are there any fragment processing details, that need to be considered? Such as 
referring to headers, or payload with fragments?

OS


On Thu, Jan 11, 2024, 2:54 AM Esko Dijk 
<[email protected]<mailto:[email protected]>> wrote:
Hi all,

In our latest cBRSKI draft we have included a request to IANA to register the 
“+cose” media type suffix. This is used in turn to construct the 
“application/voucher+cose” media type. Because some people here in the COSE WG 
may be interested in this; I’m bringing this to your attention and soliciting 
feedback – if any – until January 19th. Details are below.

Motivation: using a +cose suffix was felt to be more specific and appropriate 
than using only the +cbor suffix. Multi-suffix was also considered (+cose+cbor) 
but not pursued because this isn’t formally enabled yet and is under heavy 
discussion. Other COSE-based data formats can also benefit from the +cose 
suffix in the future. It allows much better diagnostic viewing experience of a 
Voucher in future media-type-viewers that know about +cose, compared to using 
+cbor.


Registry: 
https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml



There has been a first round of review by the mediaman WG, which led to an 
updated request.

See: 
https://mailarchive.ietf.org/arch/msg/media-types/Ila6R7g1zGaG4nSYJVUXTR4UkuY/



Registration Template: see I-D document

https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher-23#section-16.5

Best regards
Esko


IoTconsultancy.nl  |  Email/Teams: 
[email protected]<mailto:[email protected]>




IoTconsultancy.nl  |  Email/Teams: 
[email protected]<mailto:[email protected]>    |   +31 6 
2385 8339

_______________________________________________
COSE mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to