Subject: [Cbor] Multiple ways to encode true, false, ...

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 13 Apr 2017 18:35:02 -0700

Lawrence Lundblade posted an issue in the issue tracker:

https://github.com/cbor-wg/CBORbis/issues/1

This text or similar should be added to section 2.3 on simple values.

It us explicitly forbidden to encode true as 0xf8, 0x14, false as 0xf8 
0x1... The two byte encodings of 0xf8 00 ... 0xf8 1f are forbidden in 
CBOR and a CBOR decoder MUST treat them as an error.

The encodings of unassigned simple values available to extend CBOR are:
0… 19 which must be encoded as e0 … f3
32 … 255 which must be encoded as f8 20 … f8 ff

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Apr 2017 09:08:05 +0200

Right, see https://mailarchive.ietf.org/arch/msg/cbor/1dUANaAg9QLud1WI1GCvyylRzH0

I think the current text is pretty clear about what is correct CBORand what is not.

Currently, there is no explicit mandate for a recipient to *check* this (and the tool behind cbor.me doesn’t).  Should we add an explicit mandate for that?

So far, we have been relatively lenient on the checking requirements for a decoder outside “strict mode” (3.10, to which the check for 0xf8 0xnn for 0xnn < 32 could be added), so constrained implementations can omit code for that.

Grüße, Carsten

> On Apr 14, 2017, at 03:35, Paul Hoffman <[email-masked]> wrote:
> 
> It us explicitly forbidden to encode true as 0xf8, 0x14, false as 0xf8 0x1... The two byte encodings of 0xf8 00 ... 0xf8 1f are forbidden in CBOR and a CBOR decoder MUST treat them as an error.
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
> 
>

---

From: Christoph Engelbert <[email-masked]>
Date: Fri, 14 Apr 2017 12:12:25 +0200

Hey guys,

I actually think the specification is pretty clear about how true / false / null are encoded. From what I read in the spec value 23 is just not assigned which is obviously to be ignored / throw an error from the parser (which mine does and I think plenty of the other implementations I looked at), same as the further reserved / unassigned values (24-255). All of them should throw an error as long as not specifically assigned.

That said, I guess there’s no clarification necessary but the parser behind cbor.me <http://cbor.me/> is wrong :)

Chris

> On 14. Apr 2017, at 09:08, Carsten Bormann <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Apr 2017 13:29:35 +0200

On Apr 14, 2017, at 12:12, Christoph Engelbert <[email-masked]> wrote:
> 
> but the parser behind cbor.me is wrong :)

Fixed (also in the cbor-diag gem 0.2.6).

Grüße, Carsten