Re: [Json] The "CBOR Everywhere" Project

[David Kemp <dk190a@gmail.com>]

I'm proposing: a platform- and application-independent CBOR encoding profile

A superb goal! ÂNote that "encoding profile" is another name for "encoding rules", which are used in conjunction with a platform-independent but application-specific information model:

"One common problem is the lack of an encoding-independent standardization of the information, the so-called information model."

--ÂRFC 8477

One of the problems with using only data examples is that it is impossible to extrapolate from examples to the set of other data objects that applications consider valid. That is where the IM comes in - creating an IM forces the designer to think about what is or should be possible, which in turn may suggest changes to the examples. Issue #1 on your repo refers to "contract-first" design, where the contract is a model of some sort. You mention CBOR'sÂCDDL modeling language, but using an information model as the contract supports both "idiomatic" JSON as normally used by developers and a CBOR that is actually concise rather than just JSON rehashed into CBOR format.

--------------- Information Model --------------------
Mime = Record
 1 text String
 2 value Value

Value = Record
 1 data Binary /x
 2 type MediaType

MediaType = Record
 1 reg MediaRegistry
 2 type String

MediaRegistry = Enumerated
 Â1 application
 Â2 audio
 Â3 font
 Â4 example
 Â5 image
 Â6 message
 Â7 model
 Â8 multipart
 Â9 text
 10 video

------------ JSON-ish CBOR (55 bytes, from example) --------------

{

 "text": "This is text",

 "image": {

  "data": h'89504e470d0a1a0a',

  "type": "image/png"

 }

}

-------------- Concise CBORÂÂ(30 bytes, from information model)Â------------------Â

[
    "This is text",
    [h'89504e470d0a1a0a', [5, "png"]],
]

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

The other examples use integer map keys, which are smaller than string keys but still convey no information and can be eliminated.

JSON Abstract Data Notation (JADN) is an information modeling language developed underÂOASISÂwhich, conveniently enough,Âdefines a small set of platform- and application-independent information types used to construct information models. The information model example above is in JADNÂformat. I don't think the proposal will go anywhere without addressing the contract-first issue.

Cheers,

David

On Tue, May 16, 2023 at 10:30âPM Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

Hi List,
Warning: slightly political content.
As you know(?) Microsoft and Oracle do not use the same algorithm for serializing JSON numbers outside of the 64-bit IEEE-754 range although they both claim to be RFC compliant.

FWIW, I have decided to push CBOR as a viable alternative to JSON and XML for enterprise applications as well as well as standards like Open Banking. A rationale can be found here: https://github.com/cyberphone/cbor-everywhere

I was surprised seeing this idea immediately being dismissed in the same way as RFC 8785 [1]. As a countermeasure/attack, some of the leading folks in the CBOR WG, suggest creating a CBOR encoding scheme [2] that defies current industry best practices, including the encoding scheme used by the excellent CBOR on-line tool provided by the primary CBOR RFC editor himself: https://cbor.me
Another suggestion is creating sector specific CBOR encoding profiles, like a "fintech" profile. Why would the financial industry need a specific CBOR encoding scheme?

Anyway, these proposals are about as far you can possible get from what I'm proposing: a platform- and application-independent CBOR encoding profile [3], to avoid the situation we got with JSON.ÂÂ It would obviously be a waste of time for me going to IETF 117 if such high-level goals cannot be addressed in a constructive way.

Regards,
Anders Rundgren

1] "Bad idea". Not a single piece of hard technical evidence was ever provided. It just got even more confusing because some recent W3C work items depend on JSON canonicalization including authorship by none less than Mike Jones:
https://w3c.github.io/vc-jws-2020/

2] https://www.ietf.org/archive/id/draft-mcnally-deterministic-cbor-01.html

3] https://cyberphone.github.io/android-cbor/distribution/apidoc/org/webpki/cbor/package-summary.html#deterministic-encoding

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json