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

[Christian Amsüss <[e-mail]>]

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