Esko Dijk <esko.d...@iotconsultancy.nl> wrote:
> 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.
Agreed.
Also, we use CORE-SID encoding, which means that we essentially start off
with a SID value that is unique to voucher (or voucher-request).
Combined with the Content-format (which replaces the MIME-Type info in CoAP),
it's pretty clear what we have.
> 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.
Yes!
> For example my servers should also accept content-format 18 just as TBD3.
Esko, do you think the draft needs to include this option?
I prefer not to include.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
