CBOR core representation is solid and should NOT be marked as at-risk

[jonnycrunch]

CBOR and COSE are well-defined standard approaches and should be considered a valid core representations. While I agree that we could create a more concise and optimized representations.

The constraint of JSON-like strings for key maps is explicitly stated in the data model and I was using that as a scaffold to build out the CBOR examples. These constraints enable deterministically encoded canonical serialization, but use of the DID-spec registries could be optimized to enable more concise representations (int for keys for instance). My goal was for initial easy readability and interoperability to start.

Also, to be clear, this is not a CBOR-only approach, it is just a CBOR core representation and with the constraints that I suggest are to facilitate easy serialization into and out of other formats including JSON and JSON-LD as I have demonstrated multiple times.

DagCBOR is a well recognized format (tag 42) in CBOR tag registry and does not relay on any proprietary technology, although I welcome any inquiry to appropriately validate that claim. The CBOR data can be stored in a relational database and reference via a hashlink (hl) with multicodec/multibase, which has already been accepted as a work item by this group. DagCBOR is a standalone, protocol agnostic open standard. Full stop.

As discussed this week on the virtual F2F, the CBOR core representation is being threaten as being at risk. To be clear:

1.) there at at least 3 independent implementations that use CBOR: https://github.com/pinnaculum/galacteek, https://github.com/ipfs-shipyard/js-did-ipid and mine.

2.) CBOR, CBOR tag registries and COSE are well document normative standards. Nothing in the CBOR section declared novel normative changes, only references to existing methods. CBOR tags facilitate context and semantics.

3.) The CBOR section could use some additional tweaks to improve the understanding. I acknowledge CBOR is hard to follow and is not human readable, that is why is settled on human strings (tstr) at first.

4.) I think I have demonstrated a solid path for deterministic serialization between JSON, JSON-LD and CBOR/DagCBOR. Nothing shaky.

So, with that said what grounds are there for a formal objection or any general feelings of inadequacy or malaise do people have such that it warrants to be At-risk?

[msporny]

Announcement on CBOR-LD impacts this item: https://lists.w3.org/Archives/Public/public-credentials/2020Jul/0070.html

[OR13]

WIP CBOR Comparison: https://github.com/transmute-industries/decentralized-cbor/blob/master/src/__fixtures__/outputs/table.csv

I have tests for "Pure JSON", "JSON-LD", "Pure CBOR", "DAG_CBOR", "ZLIB_NQuads_CBOR".... planned to add tests for CBOR-LD

Trying to wrap my head around actual size differences between CBOR representations... transmute-industries/decentralized-cbor#1 ...

[msporny]

Since @jonnycrunch said there wasn't much discussion on this item... :)

We have too many incompatible, single-implementation approaches to CBOR encoding. It's too early in the process to say that we're going to get two solid implementations by CR, which is why we're marking this as at risk. There hasn't been enough discussion yet on this topic. So, if anyone is feeling like a normative CBOR representation is a sure thing... I don't think we're very close to converging on anything.

[burnburn]

FYI, nothing need be marked a at-risk until CR, but we can say that it is headed that way if it is

[OR13]

Related conversation here, about RDF / IPLD / DAG_CBOR / CBOR / CBOR-LD compatibility:

multiformats/multicodec#180 (comment)

[msporny]

We seem to have consensus around having a CBOR section in the spec... without calling out specific sub-versions of CBOR-specific encodings.

[msporny]

Largely waiting for PR #420 to be merged and "at risk" language to be added to that PR.

[jonnycrunch]

CBOR section has been updated in PR #420 and in-line with language for CBOR <- ADM -> JSON.