Subject: [Cbor] Some comments on cbor-cddl-05 and cbor-7049bis-02

From: John Mattsson <[email-masked]>
Date: Mon, 10 Sep 2018 21:07:14 +0000

Hi,

Hi, took some time to read these two documents in detail during my last trip. Both documents are very well written and quite easy to read and understand. Some comments:

Comments on cbor-cddl-05
---------------------------------

- I think cbor-cddl-05 should formally update RFC7049 or RFC7049bis as it extends the diagnostic notation.

- Section 2.2.1 seem to define value notation for integers, floats, and text strings, but not byte strings (which in my use cases are often used very much). Maybe the cddl tool already implements something that is just missings from the documents, otherwise all or some of the diagnostic notation for byte string would fit. e.g. h'0102030405'

- If I understand correctly, Section 3.8.5. uses the $ notation which is not defined until Section 3.9.

- That ".ctrl" in Table 1 means all CDDL control operators should be explained.

- Section 2.1.2 states that "comma is actually optional (not just in the final entry), but it is considered good style to set it."

Reading the doc it feels like the good style is to set all commas in definitions with a line break after each entry, but to leave out the last comma in definitions that do not use line breaks after each entry

orderedpair = [
   a: int,
   b: int,
]

orderedpair = [ a: int, b: int ]

I think the sentence should be updated to reflect this.

- More guidelines or at least links on how to include CDDL in RFCs would be helpful, i.e.

   <artwork type="CDDL"> in xml
   
   ~~~~~~~~~~~ CDDL in kramdown

- SenML is now published as RFC 8428

- The document refers to the cddl tool, it could also refer to tools for diagnostic notation in the extended diagnostic notation section, e.g. cbor.me

Comments on cbor-7049bis-02
---------------------------------

- 7049bis should obsolete RFC7049, I think.

- The terminology section should refer to RFC 8174

- JSON should refer to RFC 8259 instead of RFC 7159

- RFC 5226 should be replaced by RFC 8126

- ANS.1 should refer to the 2015 version
  https://www.itu.int/itu-t/recommendations/rec.aspx?rec=x.690

- ECMA/262 should refer to the 9th edition, 2018

- [TIME_T] should refer to the 2017 edition

- Could refer to tools for diagnostic notation in the extended diagnostic notation section, e.g. cbor.me

Comments on cbor-7049bis-02 or cbor-cddl-05
---------------------------------

I think it's a large benefit if the CDDL and the CBOR diagnostic notation is as similar as possible. The diagnostic notation should allow comma after the final entry. The specification is not clear here, but at least cbor.me dislikes all the following

[ 1, ]
{ 1, }
<< 1, >>

Cheers,
John

---

From: John Mattsson <[email-masked]>
Date: Wed, 12 Sep 2018 14:43:55 +0000

Hi,

Two additional comments

/John

--------------------------------------------------

Should't [], {}, and () be in Table 1?

--------------------------------------------------

Would it be possible to allow the << >> notation also in CCDL? The CDDL notation for wrapping things in byte strings are very different from the diagnostic notation. Realising which diagnostic notation expressions matches bstr .cbor type1 and bstr .cborseq type2 are not obvious. I think that allowing the << >> notation in CDDL would make it easier for users of CDDL (e.g. writers of internet-drafts and developers). 

def1 = << int >>

def2 = <<
   x: float,
   y: float,

--------------------------------------------------

On 2018-09-10, 22:45, "John Mattsson" <[email-masked]> wrote:

Hi,

Comments on cbor-cddl-05

orderedpair = [
   a: int,
   b: int,
]

   

[ 1, ]
{ 1, }
<< 1, >>

Cheers,
John

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 12 Sep 2018 16:56:28 +0200

Hi John,

I’m still processing all your useful comments from the last message.
Here are quick answers for the new points:

On Sep 12, 2018, at 16:43, John Mattsson <[email-masked]> wrote:
> Should’t [], {}, and () be in Table 1?

These are not “operators” in the traditional sense.
But it might sense to include them in the table just for completeness.

This would definitely be possible.
There is a little snag in that it wouldn’t be clear whether a group or a type would be used, but we could go for the semantics of .cborseq always and just make use of the fact that when a group always creates a single entry the semantics is the same as for .cbor.
(The existing controls also allow the left hand side type to add some restrictions on the byte string, e.g., on their size; the new notation would not provide that capability.)

The reason we were happy to just introduce .cbor/.cborseq was that adding new syntax is more heavy weight for the spec; that new syntax as well as new matching rules would have been a larger change than just using the existing extension point (controls).  If people do agree this syntactic sugar is good, we could shoehorn it in.  (We are in IESG processing already, so a change of this size might create some delay.)

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Wed, 12 Sep 2018 10:31:35 -0700

I think this should be pushed off to a next version and not down now.

Jim

> -----Original Message-----
> From: CBOR <[email-masked]> On Behalf Of Carsten Bormann
> Sent: Wednesday, September 12, 2018 7:56 AM
> To: John Mattsson <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Cbor] Some comments on cbor-cddl-05 and cbor-7049bis-02
> 
> Hi John,
> 
> > Would it be possible to allow the << >> notation also in CCDL? The CDDL
> notation for wrapping things in byte strings are very different from the
> diagnostic notation. Realising which diagnostic notation expressions matches
> bstr .cbor type1 and bstr .cborseq type2 are not obvious. I think that allowing
> the << >> notation in CDDL would make it easier for users of CDDL (e.g. writers
> of internet-drafts and developers).
> >
> > def1 = << int >>
> >
> > def2 = <<
> >   x: float,
> >   y: float,
> >>>
> 
> There is a little snag in that it wouldn’t be clear whether a group or a type
> would be used, but we could go for the semantics of .cborseq always and just
> make use of the fact that when a group always creates a single entry the
> semantics is the same as for .cbor.
> (The existing controls also allow the left hand side type to add some restrictions
> on the byte string, e.g., on their size; the new notation would not provide that
> capability.)
> 
> The reason we were happy to just introduce .cbor/.cborseq was that adding
> new syntax is more heavy weight for the spec; that new syntax as well as new
> matching rules would have been a larger change than just using the existing
> extension point (controls).  If people do agree this syntactic sugar is good, we
> could shoehorn it in.  (We are in IESG processing already, so a change of this
> size might create some delay.)
> 
> Grüße, Carsten
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor

---

From: John Mattsson <[email-masked]>
Date: Wed, 19 Sep 2018 02:52:06 +0000

>I think this should be pushed off to a next version and not down now.

I am fine with that.

---

From: John Mattsson <[email-masked]>
Date: Wed, 19 Sep 2018 03:06:32 +0000

Some comments that I collected the last week while implementing a CBOR encoder and writing CDDL for EDHOC.

Three comments on cbor-7049bis-02

- What is the difference between Null and Undefined supposed to be? According to this Wikipedia article (https://en.wikipedia.org/wiki/Undefined_value) they are the same:

"A nullable data type reserves a special null value for representing undefined value"

I think two developers writing a CBOR library in the same programming language could easily end up mapping things differently.

- I think bignum should be renamed to bigintegers. This aligns with math where the float values are also numbers and with major type 0,1 which are called integers. bignum could be used to refer to both bigintegers and bigfloats.

- "byte string" is used for both CBOR byte strings (e.g. h'010203') as well as non-CBOR bytestrings (e.g. 0x624344)

"A byte string (major type 2)"
"A CBOR data item (Section 2) is encoded to or decoded from a byte string"

Would be good with terminology to differentiate the different uses.

And one on cbor-cddl-05

- The examples of groups are very map centric. It would be good with some early examples of groups that can only be used in arrays. i.e.

array1 = [ text, float ]

group1 = (
   item: text,
   int,
)

array2 = [ group ]

The only example of such a group I can find is "[* int]" in one of the appendixes

---

From: John Mattsson <[email-masked]>
Date: Sun, 23 Sep 2018 10:56:45 +0000

Hi,

I have now implemented an encoder for most (but not all) of RFC7049bis. Quite fun. Some additional comments on 7049bis and extended diagnostic notation:

- I think tag 4 (decimal fraction) should maybe be renamed to bigdecimal to align with bigfloat and bignum. Tag 4 is expanding IEEE 754 decimal32, decimal64, and decimal128 the same way that tag 5 (bigfloat) expands IEEE 754 binary16, binary32, binary64, binary128, and binary256. Someone might want to introduce tags for decimal32, decimal64, or decimal128 in the future.

- I would like to have a tag to represent rational data items. They are useful to represent e.g. 1/3 which cannot be represented exactly with any of the current types. Rational data types are very common as built-in or library-defined types.

https://en.wikipedia.org/wiki/Rational_data_type

Could be defined in the same way as decimal fractions and bigfloats. E.g. 1/3

   C6             -- Tag 6
      82          -- Array of length 2
         01       -- 1
         03       -- 3

Suggested name: bigrational or rational

- "and "\ud800\udd51" is a UTF-8 string in diagnostic notation with a single character U+10151 (GREEK ACROPHONIC ATTIC FIFTY STATERS)."

I understand that this is based on the old and very UTF-16 centric notation in JSON and earlier versions of javascript. As CBOR is modern and very UTF-8 centric, I think the diagnostic notation should be extended to allow better (i.e. not having to use UTF-16) ways to express codepoints, just as has been done in ES6 with \u{···}.

Cheers,
John

On 2018-09-19, 05:06, "John Mattsson" <[email-masked]> wrote:

And one on cbor-cddl-05

array1 = [ text, float ]

group1 = (
   item: text,
   int,
)

array2 = [ group ]