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

[Michael Richardson <[e-mail]>]

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

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

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

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

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

    >> I note that AFAIK, we do not use tag#24 (Encoded CBOR data item) for
    >> the signed object, in COSE.  Should we?  What's the difference between
    >> #24 and #55799.

    > 55799 is a tag that can have any CBOR data item as tag content 24 is a
    > tag that can only be on byte strings.  The byte string then *encodes*
    > another CBOR data item.  (The main use here is to keep the decoder from
    > decoding, to provide easy skip-ability or because we need exact bytes
    > as in COSE.)  As often with tags, there is no need for tag 24 on a byte
    > string when it is clear from context that the byte string contains
    > encoded CBOR; this is the case in COSE.

Understood.

    >> I guess I will read onwards to find out... Got it.
    >>
    >> BTW: Tag 25 and 29 are called out after Table 5, but are not listed
    >> *in* table 5.  That whole paragraph could use some more periods, and
    >> maybe a blank line.  I'm still loss as to why <untagged><null> is
    >> better than <epoch><null>.
    >>
    >> Why can't we use decimal fractions, or bigfloats for time?

    > That may have been a mistake (which is one reason we have tag 1001
    > now).  The WG has generally taken a dim view on extending the domain
    > (allowable syntax for tag content) for a tag, so we can’t “fix” that —
    > note that for the date tag, we have taken the decision not to reuse one
    > tag for two different tag content syntaxes either.

okay.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-