Subject: Re: [Cbor] Making CBOR parsing more rigorous

From: Jeffrey Yasskin <[email-masked]>
Date: Thu, 05 Apr 2018 16:22:15 +0000

Does anyone have opinions about these changes?

On Fri, Mar 23, 2018 at 10:04 AM Jeffrey Yasskin <[email-masked]>
wrote:

> I have a collection of PRs against CBORbis to try to make parsing more
> rigorous, to deal with objections from web spec owners like
> https://github.com/mozilla/standards-positions/issues/29#issuecomment-334376573.
> I haven't yet run these changes by a web spec person to make sure they're
> complete, so there might be another set of PRs coming after these are in.
>
> https://github.com/cbor-wg/CBORbis/pull/17 has a lot of changes to define
> which kinds of CBOR parsers need to detect which errors in the encoded
> data, and which errors are recoverable.
>
> The basic idea is to classify encoded CBOR data into valid,
> invalid-but-well-formed, recoverably-ill-formed, and fatally-ill-formed
> categories, and then use that in this and derived specifications to
> describe parser behavior precisely.
>
> A question came up whether we can give an item's "unsigned integer" a
> better name. Any ideas?
>
> https://github.com/cbor-wg/CBORbis/pull/18 defines when the known kinds
> of tagged items are valid.
>
> Let me know what you think. Approving PRs is probably helpful to the
> editors even if you have no comments.
>
> Thanks,
> Jeffrey
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 Apr 2018 19:03:28 +0200

On Mar 23, 2018, at 18:04, Jeffrey Yasskin <[email-masked]> wrote:
> 
> https://github.com/cbor-wg/CBORbis/pull/17 has a lot of changes to define which kinds of CBOR parsers need to detect which errors in the encoded data, and which errors are recoverable.

There are lots of changes there.

I like identifying the value derived of the head (first byte plus any additional bytes that go into the additional information) of a data item (what is currently called the “unsigned integer” in your text) by name.  If “argument” is the best we can do, let’s go for it.

> The basic idea is to classify encoded CBOR data into valid, invalid-but-well-formed, recoverably-ill-formed, and fatally-ill-formed categories, and then use that in this and derived specifications to describe parser behavior precisely.

I don’t know that we need all these.
I think that the impetus for this change stems from a misreading of Section 3.3.
This Section lists things to check for in a generic parser, but also gives some advice on processing damaged data.
With some malice, that can be read as specifying the soupification of CBOR, but that was never the intention (and I haven’t met anyone misreading it that way).  Specifically, there is no intention to require specific methods of salvaging (or making the standard behavior depend on it).

So I think the editorial improvement would be to indicate more clearly in 3.3 what is about consistency requirements that must be checked (and violate wellformedness if they fail) and what is about potential degraded processing in the presence of an error.

> A question came up whether we can give an item's "unsigned integer" a better name. Any ideas?

Let’s go for “argument" now; we can always globally substitute that later.

Grüße, Carsten