Re: [Cbor] New IETF Internet-Draft draft-mcnally-deterministic-cbor-00

[Carsten Bormann <[e-mail]>]

A quick review of this draft:

The draft mixes up requirements of very different kinds.
This requires sorting.

Not distinguishing int and float, only supporting one NaN value, as well as not allowing `null` values in map entries, are specific choices that an application data model can make.  Or it doesn’t.  In this way, this is a *profile* of the CBOR data model.

(I happen to completely disagree with the no `null` thing as a general requirement for maps — this MAY be acceptable to certain JSON-like usages, but it rules out explicit statements about certain map keys.)

Mixing API requirements and interchange requirements makes for a weird specification.
I certainly can fulfill the interchange requirements with a very different API (which is one of the reasons why IETF has been sparse in its efforts to define APIs).

3.9 is *not* about validation, it mostly restates wellformedness requirements, with some application data model requirements thrown in.

The API assumes schema-informed processing so int and float can be handed to the application in the form expected by it.  This is certainly possible, but it reduces the usefulness of CBOR’s availability of schema-free processing.

I think it would be good to separate the restatements, the actual normative encoding requirements, the application level data model profiling, and the statements about API characteristics.

The net normative encoding content is small, but not negligible, so I do think this writeup is a useful profile for deterministic CBOR.  It certainly is not the only one that can claim to be deterministic CBOR.

Grüße, Carsten