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

From: [email-masked]
Date: Wed, 15 Dec 2021 05:56:12 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF.

        Title           : On storing CBOR encoded items on stable storage
        Authors         : Michael Richardson
                          Carsten Bormann
	Filename        : draft-ietf-cbor-file-magic-07.txt
	Pages           : 17
	Date            : 2021-12-15

Abstract:
   This document defines an on-disk format for CBOR objects that is
   friendly to common on-disk recognition systems such as the Unix
   file(1) command.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-cbor-file-magic/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-cbor-file-magic-07.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-file-magic-07

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 15 Dec 2021 17:01:35 +0100

Hello Carsten, hello Michael,

a few comments (basically what I said in the interim, but rephrased and
hopefully with better understanding now):

> Exceptionally, when used immediately as tag content within a tag
> 58000 (Section 2.3) or 58001 (Appendix C), the tag content is the
> byte string 'BOR', signifying that the representation of the given
> content-format follows in the way defined for these tags.

Is this a property of the 1668546560+ct range, or really a property of
the wrapping 58000 / 58001? As I understood in the interim it's the
latter, in which case the text about the exceptions does not belong with
the allocated tag numbers 1668546560-1668612095, but with the 58001
definition. (Or 55801? Probably, and it's a small error in this
paragraph).

The text would be different there, and as you already asked me to write
something about what it means for the processing model, that might be:

[to go into Enveloping Method: CBOR Tag Sequence]

| For the processing of the CBOR Sequence Tag (55800) it should be noted
| that it alters the semantics of the tag directly encapsulated in it:
| While the inner tag would, under other circumstances, contain the data
| item it is specified for, here it unconditionally contains the 3-byte
| string 'BOR', and the semantics of the inner tag are applied to the
| following element. This is consistent with the general CBOR practice
| that an outer tag can influence processing on the unextended generic
| data model (before tags are processed according to their semantics).

[to go into Using CBOR headers for non-CBOR data]

| As with tag 55800, this tag alters the processing of the inner tag.

---

On the topic of content format processing, it is sad that the only
content formats we have registered with non-identity encoding are the
general CBOR and JSON formats.

Example or not, I think that the document should be more explicit on the
content encoding. As I understand right now, the rules are that

* When used with 55799 and 55800, the content encoding is discarded, and
  the content format needs to be of the CBOR family.

* When used with 55801, the content encoding is used to describe the
  preprocessing of anything after byte 12.

(and there are no cases in the document any more when application data
would be put into a byte string).

The document has thus two sources of tag aliasing:

* A data structure may have both a content format and a descriptive tag
  assigned now (and future formats may do that too), with the same
  semantics.

  For example, content format 16 is application/cose;
  cose-type="cose-encrypt0", and tag 16 (coincidence? I think not) tags
  a COSE_Encrypt0 data item. Thus, tags 16 and 1668546576 now have the
  same semantics.

* When used outside of 55801, content formats with different content
  encodings collapse to the same semantics. (One could argue that the
  non-identity version contains a hint as to how to best encode this for
  transport, but that's about it).

There's little that can be done about these, but they are IMO worth
pointing out when it comes to compatibility. The way any of these are
transported will likely already give a good hint of which version to
best use: A COSE_Encrypt0 object transported in a single CoAP payload
gets content format 16 (there is no alternative anyway), but when part
of a larger CBOR structure it'd be tagged (because that's the obvious
thing to do), and tagging it as 1668546576 is probably nonsentical, but
not entirely wrong.

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Dec 2021 13:24:07 -0500

> 3.  The encoded three byte CBOR byte string containing 0x42_4F_52.

This is in: https://datatracker.ietf.org/doc/html/draft-ietf-cbor-file-magic-07.txt#appendix-C
I see the argument to make this an appendix since it does not tag CBOR
content.  I fear that the reviewers and IESG will be confused though.

Should it really use CBOR as bytes 8-11, since the content is not, in fact, CBOR?
Maybe we should say something else.  I don't feel strongly about this.

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Dec 2021 19:38:58 +0100

> On 2021-12-15, at 19:24, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

We could add more text why this is in an appendix.

> Should it really use CBOR as bytes 8-11, since the content is not, in fact, CBOR?

The header is.

> Maybe we should say something else.  I don't feel strongly about this.

I thought about that, but the tag should be the determining factor; keeping the information in two places invites mismatches.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Dec 2021 20:46:34 -0500

> We could add more text why this is in an appendix.

I guess so.

    > The header is.

Yeah, but for the human who saw this in the hexdump-C, if they get their CBOR
decoder out, they will be slightly annoyed once they realize that it is only
the header.
Is there another four letter word that starts with C?
(no, not that one)

%grep -i '^c[a-z][a-z][a-z]$' /usr/share/dict/words | wc -l
186

"cite" is one.... coax. coat. cork. crop.... czar.
I have no reason to pick these, but the prefix is kinda of a coat.
It could also be "CONT"ains.

    > I thought about that, but the tag should be the determining factor;
    > keeping the information in two places invites mismatches.

I take your point.
My point is that those bytes were because we had to wrap something, and it
provided a nice clue to the human who sees them.
Again, I don't feel strongly.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Dec 2021 20:48:19 -0500

> preprocessing of anything after byte 12.

Why do you say preprocessing?

(I'm not convinced 55801 is a good idea for anything except test data for
a CoAP server to return)

    > pointing out when it comes to compatibility. The way any of these are

Yeah, so I see more text here, and I'm starting to think that 55801 is a liability.

---

From: Ira McDonald <[email-masked]>
Date: Wed, 15 Dec 2021 21:16:32 -0500

Hi Carsten and Michael,

Just a thought.  What about "CBXX" (for CBOR wrapped external data)?

Cheers,
- Ira

On Wed, Dec 15, 2021 at 8:46 PM Michael Richardson <[email-masked]>
wrote:

>     >> This is in:
> https://datatracker.ietf.org/doc/html/draft-ietf-cbor-file-magic-07.txt#appendix-C
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Christian Amsüss <[email-masked]>
Date: Thu, 16 Dec 2021 09:35:58 +0100

Hello Carsten,

in yesterday's discussion of this it was briefly mentioned that we
don't have a good example of CBOR-then-data yet.

There is in the EDHOC draft:
https://lake-wg.github.io/edhoc/draft-ietf-lake-edhoc.html#appendix-A.3-5
(The data format stays unnamed, but it is a preexisting example).

BR
c

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 16 Dec 2021 11:33:02 +0100

Right.  Let me cite:

>> These identifiers are encoded in CBOR and thus self-delimiting. They are sent in front of the actual EDHOC message, and only the part of the body following the identifier is used for EDHOC processing.¶
>> 
>> Consequently, the application/edhoc media type does not apply to these messages; their media type is unnamed.

We never documented CBOR header + non-CBOR data in the same way that we documented CBOR sequences (RFC 8742) because there is no general way to do a media type for them — we never considered doing a structured syntax suffix for them, for example.

This doesn’t mean CBOR header + non-CBOR data is in some way a second-class citizen; we probably should go ahead and document this case (e.g., in an informational document) so people remember to put elements of support into their CBOR generic decoders.

We also may want to think about a variant of .cbor that bundles the specification of a CBOR header with the specification of what is essentially a byte string (which may be described in some form that we can describe a byte string in CDDL, e.g., by giving its length, or its structure via .abnfb).

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Dec 2021 11:32:27 -0500

> Just a thought.  What about "CBXX" (for CBOR wrapped external data)?

maybe: CBOX.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 16 Dec 2021 17:54:17 +0100

Hi Ira,

> On 2021-12-16, at 03:16, Ira McDonald <[email-masked]> wrote:
> 

There are many strings starting with C we could use (even ones with c).

Grüße, Carsten