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

Reply via email to