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

From: Jeffrey Yasskin <[email-masked]>
Date: Thu, 24 May 2018 19:54:07 -0700

Sorry for my delay in responding to this.

On Thu, Apr 5, 2018 at 10:03 AM Carsten Bormann <[email-masked]> wrote:

> 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.

Done.

> > 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).

I'd be happy to have this change declare that all ill-formed items are
fatally ill-formed. Does that match your goals?

I think we do need the separate "valid" and "invalid-but-well-formed"
categories since a generic parser can't distinguish those for a tag it
doesn't understand.

> 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.

I don't follow this well enough to propose wording for it, sorry. Could you?

Jeffrey