Overthinking is a result of underspecification in the COSE RFC/bis-draft. I simply would like for the constrained voucher document to make a statement about the use of the COSE content type field. I have no strong opinions by now as to what it should say, but i would like our RFCs not to be underspecified and leave implementers guess about use of fields, leading to possibly more complex interop matrixes.
As a reader i also like explanation/justification text for the requirements described. My sugestion for the constrained voucher text is: Constrained vouchers (application-type/voucher-cose+cbor, TBD3) SHOULD NOT use the COSE header "content type" field because the encoding is never "ambiguous" according to RFC8152 Section 3.1. If a constrained voucher contains this field, it MUST be ignored by the processing described in this document. Aka: i don't know what purpose it serves and if we wanted it to serve a purpose it sounds as if we would need to assign more useless code points. Cheers Toerless On Thu, Jul 22, 2021 at 04:55:59PM -0400, Michael Richardson wrote: > > Toerless Eckert <t...@cs.fau.de> wrote: > > So: if we wanted to support the COSE content-type field semantically > > correctly, we should ask for another registry entry: > > > application/voucher-cbor TBD4 > > I don't understand what that would be for. > > We already are registering application/voucher-cose+cbor in section 13.5.1 > We fit voucher-request into the same content. > (that's distinguished by the SID values) > > I think you are overthinking this. > And we transport constrained-vouchers with that MIME type over HTTPS between > Registrar and MASA. And we use it in the Accept: header. > > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > -- --- t...@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima