Wrt to the discussion today at he Hackathon, i am trying to figure out how the header hierarchy for constrained voucher would work:
We use a CoAP session. As a payload of CoAP, we indicate a COSE message, so somewhere in a CoAP header we have a (hopefully ?) binary field for the message type, and the value would be the TBD value to be assigned for cose vouchers in https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats e.g.: application/voucher-cose+cbor ID=TBD3 Is that a correct understanding how CoAP would work ? Now, there is in the COSE header also a parameter paramaeter called "content type", and if i read RFC8152 correctly, that field SHOULD be present and i guess also have the value TBD3, so there is some duplication here. I am not so much worried about this, i just don't understand RFC8152 text "Applications SHOULD provide this header parameter if the content structure is potentially ambiguous", and i wonder if/how that could ever be the case. I can only imagine his would be the case if we would not use TBD3 in CoAP for the COSE message, but instead "18" to indicate only application/cose; cose-type="cose-sign1" ID=18. Cheers Toerless _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
