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

From: Christian Amsüss <[email-masked]>
Date: Wed, 3 Nov 2021 15:09:39 +0100

Hello Carsten, hello Michael,

> 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 kind of like having pre-allocated tags for the CBOR protocols implied
by a content format (where applicable) for reasons of closure, that it
works this way and how it works (can't share the same 16bit tag range
without creating ambiguity, can it?) needs to be spelled out -- right
now, this is internally contradictory.

Could you clarify what your intentions are here, or whether I missed a
discussion due to which this is being changed?

BR
Christian

-- 
There's always a bigger fish.
  -- Qui-Gon Jinn

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 3 Nov 2021 15:23:42 +0100

The Content-Format part has become inconsistent; we weren’t able to fix this before the I-D deadline.  We do need to have a discussion what we want to achieve here; there are two potential approaches, and we need to discuss which one we take (or possibly both, adding a 55801 or some such).

Grüße, Carsten

> On 2021-11-03, at 15:09, Christian Amsüss <[email-masked]> wrote:
> 
> Signed PGP part

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Nov 2021 17:44:23 -0500

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

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

    > 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

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 Nov 2021 23:58:02 +0100

> c) some combination of the above, as appropriate.

d) Don’t bstr.

Define a tag 55801 that means “I’m a CBOR header for a non-CBOR file of content-format X (see next tag)”.

So it’s like a CBOR sequence, except that only the first item is CBOR, and rest is arbitrary media type till end of file.

Of course, we don’t have to do this, and can stick with 55800 for b and don’t do the others, but why should we limit ourselves so much.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Nov 2021 08:44:54 -0500

> content-format X (see next tag)”.

sure, I do not object to that.

    > So it’s like a CBOR sequence, except that only the first item is CBOR,
    > and rest is arbitrary media type till end of file.

I think that this is very invasive, but perhaps there are uses/users I haven't imagined.

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Nov 2021 14:54:55 +0100

> I think that this is very invasive, but perhaps there are uses/users I haven't imagined.

Might not make a lot of sense for, say, JSON files, but we can find examples where it does.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Nov 2021 13:50:01 -0500

I think that we have now resolved (in the WG meeting) the situation about
magic numbers for all Content-Formats vs non-CBOR, but I'm unclear what the
resolution exactly was in the end.  (cbor WG vs another WG conflict too)

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Nov 2021 20:29:06 +0100

> resolution exactly was in the end.  (cbor WG vs another WG conflict too)

I’m planning to write it up when we’ve done the next step over in the CORE WG on CORECONF…

(This was a very productive IETF, but unfortunately also productive in Action Items…)

Grüße, Carsten