Re: [Cbor] my (WGLC re-)views on error processing in RFC7049bis and future-proofing

[Carsten Bormann <[e-mail]>]

Good morning Michael,

a few quick answers to your quick answers to my first quick answers.

> Carsten Bormann <[e-mail]> wrote:
>>>> 28, 29, 30: These values are reserved for future additions to the
>>>> CBOR format.  In the present version of CBOR, the encoded item is not
>>>> well-formed.
>>> 
>>> I think that there is a bug here.  What should a parser written today
>>> do when it encounters these values?  (forward reference to section
>>> 7.2?)
> 
>> Give up (not well-formed), as there is no way to know how big the head
>> with these ai values is.
> 
> Give up, returning the content so-far, or ??

1.2:
      CBOR decoders by definition only return contents from well-formed
      data items.

So the answer is “return an error”.

> 
>>> Getting this right is how we deal with future-proofing.
> 
>> We do have extension points that have full compatibility; this
>> potential one just doesn’t.
> 
>>> It seems seeing such a thing means a current decoder has to
>>> abort/fail.  What we write here has a profound implication, I think,
>>> on how easily we could act on the advice of section 7.2.
> 
>> It would be a CBOR 1.1 (or 2.0), it will not be easy on existing
>> decoders!
> 
> Should we plan a tag for version?

No.

First of all, we have no idea whether the room we left here in the encoding space will ever be exercised.  Yes, it is an attractive nuisance (not exercising it leaves one feel strangely unsatisfied), but people have been happy with the other ways to indicated 128-bit etc. values.

Second, the habit to put versions in interchange specifications generally is misguided.  Unless they are needed to prevent false interoperability.  But false interoperability cannot happen here, as the reserved ai values are easily recognizable as such.

(CBOR is designed to be versionless, by defining well-defined extension points.  Version indications also would take significant space in one major area of application of CBOR: Small data items.)

> 
>>> Section 10, first paragraph implies we should say something.
>>> 
>>> In general, I think that the details in this introductionary encoding
>>> section are too detailed, particularly for 31.  I think that detail
>>> belongs later on. I got no value (I retained nothing) from having that
>>> level of detail there.
>>> 
>>> I wonder if section 3.1, under major type 0 should give clarify that
>>> "0" is encoded as 0b000_00000. (That is no negative 0)
>>> 
>>> "A string containing an invalid UTF-8 sequence is well- formed but
>>> invalid."
>>> 
>>> I think that this might need clarification.
>>> 
>>> I guess that RFC8742 include sequences of 7049bis CBOR sequences.  I
>>> wonder if Updates 8742 is appropriate.
> 
>> You lost me here.
> 
> Do we need to Update 8742 too?

But nothing is updated, and certainly not in 8742?

>>> 3.2.3: (Note that zero-length chunks, while not particularly useful,
>>> are permitted.)
>>> 
>>> they might be useful in non-TCP/IP situations where it is useful to
>>> send a "keep-alive" on some channel.
> 
>> We haven’t addressed general padding im CBOR (which would again require
>> a 1.1 or 2.0 maybe), and I would hate to suggest this here as the only
>> padding that CBOR already offers.
> 
> Okay, so maybe forward to Protocol.

Yes.

>>> Could future Simple Values (such as 0..19) can, have complex structure
>>> the way that values 24->27 do?
> 
>> No, the general syntax of heads does apply to the unallocated code
>> points as well.
> 
> I think we should state this.  It's a extension point that we can reliably skip.

Well, if we say how heads are decoded, that should be enough — we don’t have to restate that everywhere they are used.  But maybe I don’t understand where you see the extension point here.

Grüße, Carsten