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

Pete Cordell <petejson@codalogic.com> Tue, 04 May 2021 13:06 UTC

Return-Path: <petejson@codalogic.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3EA3A0789 for <json@ietfa.amsl.com>; Tue, 4 May 2021 06:06:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-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 EC8VFRlt-E5n for <json@ietfa.amsl.com>; Tue, 4 May 2021 06:05:59 -0700 (PDT)
Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728F63A0765 for <json@ietf.org>; Tue, 4 May 2021 06:05:58 -0700 (PDT)
Received: (qmail 11793 invoked from network); 4 May 2021 14:05:56 +0100
Received: from host31-49-16-155.range31-49.btcentralplus.com (HELO ?192.168.1.72?) (31.49.16.155) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPS (TLS_AES_128_GCM_SHA256 encrypted, authenticated); 4 May 2021 13:05:56 -0000
To: Carsten Bormann <cabo@tzi.org>
Cc: Daniel P <danielaparker@gmail.com>, JSON WG <json@ietf.org>, cbor@ietf.org
References: <CA+mwktLWwDRYtF9BFSRnF4e7_v=e3F4HERS5yHptSksxGBysnQ@mail.gmail.com> <F1A006F9-8743-4930-B879-F83339A38485@tzi.org> <9e811395-2f56-f2b2-b4a6-c686544cb1ef@codalogic.com> <DC77FE0A-E0E1-4A92-AD7D-4522E450BED4@tzi.org>
From: Pete Cordell <petejson@codalogic.com>
Message-ID: <9771fc21-0193-1338-a128-fb9bdf00db66@codalogic.com>
Date: Tue, 04 May 2021 14:05:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <DC77FE0A-E0E1-4A92-AD7D-4522E450BED4@tzi.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/06rT8REkcNZ_3ZnfP3BrHyKDWdc>
Subject: Re: [Json] Update Standard to support ECMA-262 BigInt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 May 2021 13:06:05 -0000

Thanks Carsten,

Comments below...

On 04/05/2021 12:49, Carsten Bormann wrote:
>>...
>>
>> 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):

Indeed.  I picked an intentionally grizzly example that you wouldn't 
want to capture in a regular expression or similar.

>     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
>... >
> 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 :-)

That's where the concept of @{format 
org.ietf.extended-types.rfc2822.date-time} has extra mileage.  (Or 
.format org.ietf.extended-types.rfc2822.date-time if translated to CDDL.)

The example wasn't intended to be about ABNF, but saying specifying 
formats in purely machine readable ways usually ends up being 
insufficient.  Having provision for human understood formats done in 
such a way that a machine can ask 'does this value conform to this 
format that you, smart human, have coded?' allows a simple way to 
side-step that problem.

So in addition to the ABNF (or any other equivalent you might choose) 
you can also include to narratively define the constraints on say, 
date-mday etc.

Humans can then write code just for that format, such as:

   class Rfc3339FullDateValiadtor
     def IsValidFormat str
       # Code goes here
       return true or false
     end
   end

Then inject it into a validator:

   cddl_validator = CDDLValidator.new
   cddl_validator.add_type_validator 'org.ietf.rfc3339fulldate', 
Rfc3339FullDateValiadtor.new

which puts the data into a hash of string => object.

When cddl_validator finds a value that should be .format 
org.ietf.rfc3339fulldate it does:

   is_valid_external_type 'org.ietf.rfc3339fulldate', value

where:

   def is_valid_external_type format_key, value
      if @external_validators.include? format_key
         return @external_validators[format_key].IsValidFormat value
      end
      return ???
   end

I hope that all makes sense!

> RFC 8610 also has a .regexp control operator (using W3C XSD regexps, but other flavors can be added as needed).
>...
> 
> (*) 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].

A nice touch :)

Pete.
-- 
---------------------------------------------------------------------
Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Read & write XML in C++, http://www.xml2cpp.com
---------------------------------------------------------------------