Subject: [Cbor] comments x2 on draft-greevenbosch-appsawg-cbor-cddl-08

From: Sean Leonard <[email-masked]>
Date: Mon, 25 Jul 2016 03:02:11 -0700

While reviewing draft-greevenbosch-appsawg-cbor-cddl-08, I wanted to make a couple of comments. Not sure if this is the best place for them? These comments are “some other issues”.

I am deeply suspicious of the .cbor and .cborseq annotations in B.1.4. I understand why they are there, because specification designers may be tempted to carve out a hole in a spec to put “whatever”, as has happened with a lot of specs using ASN.1. Please, don’t do that. The proper thing to say is in the current grammar is “any”, not something contained in a bstr. Don’t go down that bad ASN.1 path; this is not the 1980s. See the late John Larmouth’s book, ASN.1 Complete (available for free, just Google it) on why it’s a bad idea. By dumping CBOR in a byte string, you’re going back to ASN.1 BER, and not even the fixed up ASN.1 BER of today, we’re talking about the BER from the 1980s. (Think about length specifiers, which CBOR goes out of its way to incorporate as the number of items, not the number of encoded bytes.) :(

People like optionality when they can’t decide which alternative is better, but this muddles the grammar. Currently “bstr” and “bytes” are synonyms; “tstr” and “text” are also synonyms. Please pick one. I like “bstr” and “tstr” because RFC 7049 specifically calls them “a byte string” and “a text string”, respectively. They are strings, not arrays per-se.

The examples are correct according to the grammar, but are also (literally) quite artificial. It would be better to replace the nonsensical keys/values with keys/values that are more plausible. I am happy to volunteer to change some of the examples.

I have read through this draft several times, and remain utterly confused by the choice of terms “record” and “struct”. The term “struct” is a very famous C/C++ thing, where the items are laid out positionally in memory according to the struct definition. The names are not stored in memory or serialized. However, this draft uses “struct” for maps where the map keys are serialized, and “record” for arrays with “positionally defined semantics”. This is super-confusing for me as a C/C++ programmer.

I really think that “struct” should be the term used for a CBOR array whose elements have different, positionally defined semantics.

As for “record”, I suppose it could go either way, but whenever I use the term “record”, I think of the *fields* comprising the record, as having *field names*, so the *field names* ought to be serialized along with the *field values*. I would prefer a stronger search of the literature before settling upon “record”.

Honestly “map” is the most straightforward term to use, but I understand that this draft is trying to distinguish the CBOR map from the semantic things that are serialized as CBOR maps (also, contrast needs to be provided with “table”, which is a map). “Object” is not too bad (where each name/value pair is a “member”), seeing as how they are mirroring JSON objects.

I am okay with “vector”. “list” could be used but I suppose that “vector” is better since the items in the array are 0-indexed.

I am only somewhat okay with “table”. The problem is that “table” tends to imply multiple columns (more than 2) as well as multiple rows; the meaning shades somewhat too close for comfort into “record”. Something about “tuples” would probably be better, such as “pairs” or “2-tuples”. Other terms to consider would be “dictionary”, “definition list”, or “association”. Personally I would go with “pairs” or “dictionary”.

Best regards,

Sean