Re: [Cbor] Chair review of cbor-file-magic 08

[Michael Richardson <[e-mail]>]

Christian =?iso-8859-1?Q?Ams=FCss?= <[e-mail]> wrote:
    > On Wed, Feb 23, 2022 at 02:08:07PM -0500, Michael Richardson wrote:
    >> > * 5.3: At latest here, I'd have expected to read something about the
    >> > information that is lost when using this tag with 2.2. Maybe there
    >> > should be a line (not for IANA but for users, so maybe in a different
    >> > section) that outlines when this works with (non)CBOR content formats
    >> > and with which encodings.
    >>
    >> I've tried how to understand this comment, but I'm failing.
    >> Which information is lost?

    > I've phrased this badly: The ct encoded in the tag gives information
    > about the (structured) media type and the content coding. In the 2.2 and
    > 2.3 use cases, the information in the content coding is ... discarded
    > (should be the word to use rather than lost), if it is acceptable that a
    > ct for application/mine+cbor@gzip is also used in this tag. Or the
    > content coding is required to be identity, in which case any
    > non-identity content coding would be ruled out (just like any non-CBOR
    > media types are ruled out).

I'm even more lost now.

    >> >   I think I understand now that the 5.3 tags can be used with either
    >> > 2.2, 2.3 or C (55899, 55800 and 55801), but
    >>
    >> good...
    >>
    >> >   * with 55899 the ct tags can only be used if the content format is a
    >> > CBOR content format and coding is identity (and then tags a value)
    >>
    >> 55899 marks CBOR, so the content had better be CBOR.

    > any tag tags CBOR, so the content needs to be CBOR.

Yes, we are using CBOR to create the marks, so yes, this is trivially true.
The marks do not all tag CBOR.

At this point, I feel like adding 55801 and the CT stuff has just confused
what was a really really simple proposal, and I wish we hadn't gone there.

    > I'm just saying that the formalities of defining the tags are complex
    > (because 55799(ct1234(X)) can take anything for X, whereas
    > 55801(ct1234(X)) takes precisely a bytestring ('BOR'). The text in the
    > IANA section 5.3 reflect that correctly, and I haven't found text that
    > sets the rules (rather than implying them).

I'll look again to see if I can clarify this better.

    >> > * (Maybe security) considerations: 3.2 talks of trivially concatenated
    >> > data items. If CBOR Tag Sequence is used and the data gets literally
    >> > "concatenated", (say, `cat *.cborseq > outfile`), one might wind up
    >> > with self-described tags in the middle of the sequence. (As we do with
    >> > BOMs).
    >>
    >> I have added:
    >> https://github.com/cbor-wg/cbor-magic-number/commit/23c4176796d83e4d69ba56ab8a9b7f45cd691272

    > That sounds like accepting such chains; is that really desirable? It
    > sounds really messy to me.

Yes, it is sometimes appropriate to accept such chains.
Consider a file containing a series (bag) of certificates.

    >> I think that you are having a problem with A.1 wrapping a CBOR thing in
    >> 55801?

    > I don't care about what is in a 55801, but the CDDL is confusing because
    > it is unspecific about which use case it is.

    > Either this tag is for use with 55800/55801, then it can be `senml-cbor
    > = #6.1668546672('BOR')` right away.

    > Or it is for use with 55799, then it needs to be `senml-cbor =
    > #6.1668546672([*record])` or whatever we use for SenML.

I think that we shouldn't use senml-cbor in the example.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide