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

[Carsten Bormann <[e-mail]>]

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].