Re: [Cbor] I-D Action: draft-ietf-cbor-file-magic-06.txt

[Michael Richardson <[e-mail]>]

I really didn't have the focus last week to understand your observation.

Christian Amsüss <[e-mail]> wrote:
    >> A diff from the previous version is available at:
    >> https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-file-magic-06

    > The example has now become inconsistent, mixing the CBOR Tag Wrapped
    > and CBOR Tags for Content Formats parts:



    >> to translate the Content-Format number registered for
    >> application/senml+cbor, the number 112, into the tag 1668546560+112 =
    >> 1668546672.
    >>
    >> 55799(1668546672([{0: "current", 6: 3, 2: 1.5}]))

    > puts CBOR data into the content-format generated item, whereas Appendix
    > A says:

    >> The tag content tagged with tag number [...] is a byte string that is
    >> to be interpreted as a representation of the content format
    >> NNNNNNNN-1668546560.

    > which would look like 55799(1668546672(h'a30067...')).

    > My understanding so far was that with the current appendix, all data
    > would be bstr-valued, and if a) the content format is CBOR based, and
    > b) the transport coding is "identity", and c) the representation is
    > actually well-formed in the advertised content format, only then will
    > the byte string (happen to) be valid CBOR, but still encoded in a byte
    > string.

I finally understand the problem you are describing (ENOCOFFEE!)
Some CoAP Content Formats are CBOR, but not all of them are.
For an abitrary Content Format, we can't run the proceedure.
But, the example in section 2.2.1 does exactly this.

However, all of the CoAP payloads are valid bstr, so the example says to do
that for the two things that it has shown.

When Carsten suggested the Content-Format -> Tag, I didn't htink that some
content format isn't CBOR.
(Sacrilege! How dare CoAP be profaned with non-CBOR content!)^K

It seems that we need to choose:

a) them all to be bstr'ed
b) for only those that happen to be CBOR to be acceptable
c) some combination of the above, as appropriate.

I think that having them all bstr'ed for storage on disk is not particularly
useful to existing programs.  We can carry PKIX certificates in CoAP
(draft-ietf-anima-constrained-voucher and draft-ietf-ace-est-coaps), but
I wouldn't want to store that on disk bstr'ed.

So I would go for (b), and we should fix the Appendix.
Carsten messaged me that he had some slides in the works for Thursday.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-