Hi Wolf,
Before we go down the rabbit hole, I may need to do some clarifications:
- The CBOR WG have not expressed ANY sympathy for creating a "JSON challenger",
targeting mainstream applications currently using Open API, and more recently, Wallets
like the EUDI.
- Related IETF WGs like CBOR, COSE, etc. are most likely to be STRONGLY OPPOSED
to supporting non-COSE methods of the kind outlined in draft (and used by the
Gordian Envelope as well).
That is, this work cannot be carried out within the IETF, which in turn means
that I'm free to do whatever I feel is appropriate 😆
In short the idea is "simply" making the U-CBOR (a true subset of RFC 8949), be
the CBOR known by most developers.
TL:DR
However, you are right, the draft does indeed not address the issues you mention. Am I worried?
Not really, because my [quite straightforward] JavaScript and Java implementations do (AFAICT) not
suffer from any of these issues. Well, for JavaScript there is one issue that application
developers must consider: should I use "Number" or "BigInt" for a particular
integer object? Since this is governed by the protocol and Number.MAX_SAFE_INTEGER it seems pretty
unrelated to CBOR.
Regarding non-deterministic (versus canonicalized) encodings, I believe the date sample
explains my position on this topic. For the thorny number issue, I have (in spite of
actually trying...), not been able to find a justification for deviating from Rule 2 of
4.2.2 of RFC 8949. I once started with https://cbor.me as some kind
"explainer" (and reference) on how to interpret RFC 8949, and I am still there.
If we take JSON as a (bad) example, I'm not aware of a single IETF standard that uses the
JSON "Number" type for expressing big integers. That is, the JSON standard
(RFC 8259), isn't actually very useful. U-CBOR MUST NOT follow this path.
BTW, I find the CBOR interoperability discussions extremely confusing. If you are about to communicate with a device
which you don't control, your only option is using the lingo it understands; the [long-term] with U-CBOR is to improve
interoperability by "prescribing" a standard set of "data types" which maps well to current
platforms. Yes, I need to add this to the U-CBOR spec!! CBOR connoisseurs will frown at the idea
"downgrading" CBOR into a set of data types, but that is what it is for "normal" developers. No
ALDR issues have been identified either.
Regards,
Anders
https://github.com/cyberphone/CBOR.js#cborjs
On 2025-03-04 01:12, Wolf McNally wrote:
Anders,
I read your new I-D with interest. A few points in passing:
- You have your sights set on a replacement for JSON, but now require JSON
developers to decide whether a numeric field is to be designated as int or
float, adding complexity for those coming from that world.
- When to apply bigint seems a bit ambiguous: you have distinct types for int
and bigint, implying that users must select a type for an integer field, but
you also seem to mandate a “hybrid” implicit integer type that requires a form
of numeric reduction: IFF a value is not representable by int then bigint MUST
be used, else int.
- You claim deterministic encoding, but have nothing to say about the
non-deterministic encodings of equivalent UTF-8 strings.
- You retain three distinct encodings of zero: 0, 0.0, and -0.0, acknowledging
that this yields three distinct encodings of map keys that nonetheless have the
same semantics. I think bigint 0 would represent a fourth.
- You acknowledge credit to Gordian Envelope, but never mention the work upon
which it relies: dCBOR, which deals with all of the above issues, including
support for bigint as a distinct type like any other tagged type. Envelope,
built on dCBOR, already supports numerous signature and public key encryption
schemes (we recently added the post-quantum algorithms ML-DSA and ML-KEM as
well.)
~ Wolf
On Mar 2, 2025, at 6:16 PM, Anders Rundgren <[email protected]>
wrote:
Phew, it only took 3Y+ to get to the stage where an I-D felt appropriate.
Note: this is not about "deprecating" COSE; it is just about providing an
alternative.
-------- Forwarded Message --------
Subject: New Version Notification for draft-rundgren-universal-cbor-00.txt
Date: Sun, 02 Mar 2025 17:50:56 -0800
From: [email protected]
To: Anders Rundgren <[email protected]>
A new version of Internet-Draft draft-rundgren-universal-cbor-00.txt has been
successfully submitted by Anders Rundgren and posted to the
IETF repository.
Name: draft-rundgren-universal-cbor
Revision: 00
Title: Universal CBOR (U-CBOR)
Date: 2025-03-02
Group: Individual Submission
Pages: 20
URL: https://www.ietf.org/archive/id/draft-rundgren-universal-cbor-00.txt
Status: https://datatracker.ietf.org/doc/draft-rundgren-universal-cbor/
HTML: https://www.ietf.org/archive/id/draft-rundgren-universal-cbor-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-rundgren-universal-cbor
Abstract:
This document defines Universal CBOR (U-CBOR), a strict subset of
CBOR (RFC 8949) intended to serve as a viable replacement for JSON.
To foster interoperability, deterministic encoding is mandated.
Furthermore, the document outlines how deterministic encoding
combined with enhanced CBOR tools, enables the support of
cryptographic constructs that operate on "raw" (unwrapped) CBOR data.
The intended audience for this document are CBOR tool developers.
The IETF Secretariat
_______________________________________________
CBOR mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
