Re: [Cbor] tag 24, CBOR sequence and non-CBOR sequence

[Carsten Bormann <[e-mail]>]

Hi Laurence,

> On 2020-06-05, at 17:13, Laurence Lundblade <[e-mail]> wrote:
> 
> Here’s some example of CBOR sequence (e.g., application/cbor-seq) and CBOR that is not a sequence (e.g., application/cbor)
> 
> 0x00 
> This is a legal sequence or non-sequence

“CBOR data item” (or “encoded CBOR data item”) is my preferred wording for the latter.

> 
> 0x00 0x00
> This is a legal sequence, but not non-sequence. A non-sequence can contain only one data item, this contains two.

Right.

> 0x82 0x00 0x00
> This is a legal sequence or non-sequence. It is how you encode two zeros as a non-sequence.

Right.

> Looks to me that tag 24 cannot contain a CBOR sequence.

Indeed, no.

> It says “a data item”. The use of “a” implies one data item and thus not a sequence. That means a decoder should always consider a sequence in the contents of a tag 24 invalid.

(A sequence that doesn’t happen to contain exactly one data item.)

> This seems overly restrictive and unfortunate to me.  Would it be wrong for a generic decoder to allow this?

Yes.
(Well, it might not be checking the validity.)

It seems we forgot to define an equivalent to tag 24 in RFC 8742.
But a registration for such a tag can easily be made now.

> The wording for tag 55799 avoids the issue of sequence or not.
> 
> 
> Technically, it seems that something labeled application/cbor or in a file named foo.cbor can’t contain the CBOR 0x00 0x00 because it is not a legal non-sequence.

Correct.

> That might implies a generic decoder should have a sequence mode and a non-sequence mode.

Yes.  You can always use the sequence mode, though (just check that you got exactly one data item back).

My preferred API asks the generic decoder to decode one CBOR data item from a position given and returns the position of the first input byte beyond that CBOR data item.
A sequence decoder is built trivially from this.
But you can also use it for cases where a CBOR data item is the “header” for some blob that is not decoded as CBOR.

> In practice this doesn’t seem like a very useful restriction. What is useful is whether the encoded CBOR is legal for the protocol being implemented.

If the protocol wants one CBOR data item and gets two (or zero), that doesn’t help.

> From what I’ve experienced, it seems easier if everything is just a CBOR sequence and no distinction is made. Individual CBOR protocols can decide on their own structure either deciding to bind things together in an array or not. Am I missing something?

I think the important observation is that it took us a couple of years to rationalize the weird text about “streaming decoders” in RFC 7049 into a clear concept of CBOR sequences.
So there is a lot of code out that that doesn’t cope very well with CBOR sequences, just with single CBOR data items — and that is often also exactly what’s needed.

Grüße, Carsten