Re: [Cbor] [Json] Update Standard to support ECMA-262 BigInt

Carsten Bormann <cabo@tzi.org> Tue, 04 May 2021 11:49 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B263A3125; Tue, 4 May 2021 04:49:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqitRxZMYowg; Tue, 4 May 2021 04:49:45 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7273A3124; Tue, 4 May 2021 04:49:44 -0700 (PDT)
Received: from [192.168.217.118] (p548dcb12.dip0.t-ipconnect.de [84.141.203.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FZJ6Y3h7TzyWg; Tue, 4 May 2021 13:49:41 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <9e811395-2f56-f2b2-b4a6-c686544cb1ef@codalogic.com>
Date: Tue, 4 May 2021 13:49:41 +0200
Cc: Daniel P <danielaparker@gmail.com>, JSON WG <json@ietf.org>, cbor@ietf.org
X-Mao-Original-Outgoing-Id: 641821781.044234-a5949ef69ac687f8a061feab3db8a667
Content-Transfer-Encoding: quoted-printable
Message-Id: <DC77FE0A-E0E1-4A92-AD7D-4522E450BED4@tzi.org>
References: <CA+mwktLWwDRYtF9BFSRnF4e7_v=e3F4HERS5yHptSksxGBysnQ@mail.gmail.com> <F1A006F9-8743-4930-B879-F83339A38485@tzi.org> <9e811395-2f56-f2b2-b4a6-c686544cb1ef@codalogic.com>
To: Pete Cordell <petejson@codalogic.com>
X-Mailer: Apple Mail (2.3608.120.23.2.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/0byabTP4ZyKsXoMWHdQE2TfOgzE>
Subject: Re: [Cbor] [Json] Update Standard to support ECMA-262 BigInt
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 May 2021 11:49:51 -0000

Hi Pete,

> Firstly, Carsten, do you or anyone else knows of any IETF WGs using CDDL to define JSON data?

Sure.

I’m not keeping a list, and the info is a bit scattered, but you can start from 

https://datatracker.ietf.org/doc/rfc8610/referencedby/

E.g.,

https://datatracker.ietf.org/doc/draft-ietf-asdf-sdf/
https://datatracker.ietf.org/doc/draft-ietf-ace-aif/
https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/

Sorry, I stopped at WGs starting with “a”, but you can continue if you want…

(The data is skewed a bit because WGs that are aware about CDDL often also are aware about CBOR and are using that for encoding what would maybe have been encoded in JSON otherwise.)

If you want to get started with using CDDL for JSON, RFC 8610 has a little appendix with a worked example for the JSON in RFC 7071:
https://www.rfc-editor.org/rfc/rfc8610.html#appendix-H

> As for what I think JCR offers that I don't think CDDL currently offers:
> 
> 1.
> JCR has a simple way to combine multiple rulesets.  In one ruleset you might have:
> 
>   #ruleset-id org.ietf.example1
> 
>   $foo = int32
> 
> Then in another ruleset:
> 
>   #import org.ietf.example1 as ex1
> 
>   {
>      "id" : $ex1.foo
>   }
> 
> Here, $ex1.foo refers to $foo defined in the ruleset with id org.ietf.example1.

Yep, the top item on the list for CDDL 2.0, probably this year.
Right now, you have to concatenate by hand.

(As we already did before with CDDL “groups” (*), we are certainly going to learn from JCR when defining the CDDL import/export/module feature.  We are certainly also going to learn from YANG, the other IETF data definition language.)

> 2.
> Although possibly not formally released, we were considering a way of declaring that a string had to adhere to an arbitrary format.  This was a way of adding additional string based types (as there is no other option in JSON for extended types!) without adding new base types (like int32, date-http etc).  So, in a ruleset you could specify something like:
> 
>   #ruleset-id org.ietf.extended-types
> 
>   $rfc2822-date-time =
>         @{format org.ietf.extended-types.rfc2822.date-time} string
> 
> Then use it as:
> 
>   #import org.ietf.extended-types as iet
> 
>   {
>      "start-time" : $iet.rfc2822-date-time,
>      "end-time" : $iet.rfc2822-date-time
>   }
> 
> The spec for the "org.ietf.extended-types.rfc2822.date-time" format might read something like:
> 
>   Formatted according to the RFC2822 date-time ABNF but omitting
>   the trailing [CFWS] term.

I don’t think one ever, ever wants to use RFC 2822 (5322) date-time, but here is a snippet from https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl-control/, which is in pre-WGLC review (with X and Y for things that are not relevant here):

   X = text .abnf full-date
   Y = text .abnf date-time

   full-date = "full-date" .det rfc3339
   date-time = "date-time" .det rfc3339

   ; Note the trick of idiomatically starting with a newline, separating
   ;   off the element in the concatenations above from the rule-list
   rfc3339 = '
      date-fullyear   = 4DIGIT
      date-month      = 2DIGIT  ; 01-12
      date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                                ; month/year
      time-hour       = 2DIGIT  ; 00-23
      time-minute     = 2DIGIT  ; 00-59
      time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap sec
                                ; rules
      time-secfrac    = "." 1*DIGIT
      time-numoffset  = ("+" / "-") time-hour ":" time-minute
      time-offset     = "Z" / time-numoffset

      partial-time    = time-hour ":" time-minute ":" time-second
                        [time-secfrac]
      full-date       = date-fullyear "-" date-month "-" date-mday
      full-time       = partial-time time-offset

      date-time       = full-date "T" full-time
   ' .cat rfc5234-core

   rfc5234-core = '
      DIGIT          =  %x30-39 ; 0-9
      ; abbreviated here
   '

These are some examples the cddl tool generates for X:

"6962-26-77"
"7578-39-91"
"5073-91-77"
"1258-31-15"
"9316-20-59"
"8308-23-92"
"2131-42-71"
"6573-08-96"
"3120-88-30"
"4322-41-98”

Well, the ABNF is a bit loose :-)

RFC 8610 also has a .regexp control operator (using W3C XSD regexps, but other flavors can be added as needed).

[…]

> currently my gut feeling is that if those sorts of features are supported in CDDL, it would be worth adopting CDDL for JSON format specification.  

Indeed.

> Primarily because it has a formally published spec!

It also is pretty alive and responding to user requirements.

Grüße, Carsten

(*) From RFC 8610:

Acknowledgements

   Inspiration was taken from the C and Pascal languages, MPEG's
   conventions for describing structures in the ISO base media file
   format, RELAX NG and its compact syntax [RELAXNG], and, in
   particular, Andrew Lee Newton's early proposals on JSON Content Rules
   (JCR) as found in draft version four (-04) of [JCR].