Hi Toerless, > Is that a correct understanding how CoAP would work ?
Agree, the content-format is stored as a single var-length uint in a CoAP Option (not part of the fixed header but one of the optional elements). > Now, there is in the COSE header also a parameter paramaeter called "content > type" In my implementation I don't use the 'content type' header in COSE because it is duplicate. The type is given at CoAP level already so there is no ambiguity, so the "SHOULD" in RFC 8152 doesn't apply. We may mention in the draft not to use this 'content type' for live-generated vouchers and voucher-requests. If the object is created to be transported over other ways (e.g. email, USB stick, etc) then I would opt for including that 'content type' possibly. Although the filename (*.vch) in that case will indicate the exact media type. > ... 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 Correct, then there might be ambiguity w.r.t. other / future Voucher and Voucher Request formats that may be transported between Pledge and Registrar in operations on the *same* resource (e.g. /rv). But as long as such formats aren't defined it will also work in practice. For example my servers should also accept content-format 18 just as TBD3. So all in all I would say leaving out the 'content type' parameter always will just work and it will only be needed once a new content type is defined that also uses COSE_Sign1 encoding and that new type is used on BRSKI resources like /rv. Esko -----Original Message----- From: Toerless Eckert <t...@cs.fau.de> Sent: Tuesday, July 20, 2021 21:39 To: draft-ietf-anima-constrained-vouc...@ietf.org; Carsten Bormann <c...@tzi.org> Cc: anima@ietf.org Subject: draft-ietf-anima-constrained-voucher COSE confusion 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 Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
