Re: [Cbor] CBOR-then-data example in EDHOC (was: draft-ietf-cbor-file-magic-07.txt)

[Carsten Bormann <[e-mail]>]

On 2021-12-16, at 09:35, Christian Amsüss <[e-mail]> wrote:
> 
> Signed PGP part
> 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).

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