From nobody Tue May 4 03:11:26 2021 Return-Path: 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 02EF73A2E3B for ; Tue, 4 May 2021 03:11:24 -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 WY7YzOmjRbdv for ; Tue, 4 May 2021 03:11:18 -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 CEE003A2E3A for ; Tue, 4 May 2021 03:11:17 -0700 (PDT) Received: (qmail 4866 invoked from network); 4 May 2021 11:11:14 +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 10:11:14 -0000 To: Carsten Bormann , Daniel P Cc: JSON WG References: From: Pete Cordell Message-ID: <9e811395-2f56-f2b2-b4a6-c686544cb1ef@codalogic.com> Date: Tue, 4 May 2021 11:11:14 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 10:11:24 -0000 On 30/04/2021 21:53, Carsten Bormann wrote: > On 30. Apr 2021, at 21:36, Daniel P wrote: >> >> Do you mean in the context of a schema specification? > > CDDL (RFC 8610) can already do much of what is probably needed here. > If there is anything else to be added, CDDL has an extension point (control operators) that is rather flexible. Hi Daniel and Carsten, I was speaking in very general and abstract terms. More along the lines of "one could imagine that ..." with no specific work item in mind. But.... Since you raise the issue of JCR vs CDDL, here are my thoughts... Firstly, Carsten, do you or anyone else knows of any IETF WGs using CDDL to define JSON data? 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. 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. So, "org.ietf.extended-types.rfc2822.date-time" is not machine resolvable to a specific format on its own. It is just an opaque character string used as an identifier for the format. A validator would either know about strings formatted according to "org.ietf.extended-types.rfc2822.date-time" (possibly via inbuilt hard coding or using some plugin arrangement) or just issue a warning saying I don't know what the format "org.ietf.extended-types.rfc2822.date-time" is so I'll check it is a string but leave it to other layers to verify that it is the right format. Such a feature may not be something so useful for CBOR but I think it is very useful for JSON strings. In conclusion, I need to revisit things in more detail, but 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. Primarily because it has a formally published spec! Many thanks, Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Tue May 4 03:38:10 2021 Return-Path: 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 12A663A2EF6 for ; Tue, 4 May 2021 03:38:09 -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 dpwMX7O8YATj for ; Tue, 4 May 2021 03:38:03 -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 4F75D3A2EF9 for ; Tue, 4 May 2021 03:38:02 -0700 (PDT) Received: (qmail 6183 invoked from network); 4 May 2021 11:38:00 +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 10:38:00 -0000 From: Pete Cordell To: Carsten Bormann , Daniel P Cc: JSON WG References: <9e811395-2f56-f2b2-b4a6-c686544cb1ef@codalogic.com> Message-ID: Date: Tue, 4 May 2021 11:38:00 +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: <9e811395-2f56-f2b2-b4a6-c686544cb1ef@codalogic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 10:38:09 -0000 On 04/05/2021 11:11, Pete Cordell 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. > Actually, @{format} doesn't have to be limited to strings. You could also format other base types. For example, @{format} on an int might look something like: #ruleset-id org.example.my-types $int-div-3 = @{format org.example.my-types.int-div-3} int Where the definition for "org.example.my-types.int-div-3" is "positive integers that are multiples of 3". Cheers, Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Tue May 4 04:49:53 2021 Return-Path: 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 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 In-Reply-To: <9e811395-2f56-f2b2-b4a6-c686544cb1ef@codalogic.com> Date: Tue, 4 May 2021 13:49:41 +0200 Cc: Daniel P , JSON WG , cbor@ietf.org X-Mao-Original-Outgoing-Id: 641821781.044234-a5949ef69ac687f8a061feab3db8a667 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9e811395-2f56-f2b2-b4a6-c686544cb1ef@codalogic.com> To: Pete Cordell X-Mailer: Apple Mail (2.3608.120.23.2.6) Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=E2=80=99m not keeping a list, and the info is a bit scattered, but you = can start from=20 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 =E2=80=9Ca=E2=80=9D, but you can = continue if you want=E2=80=A6 (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: >=20 > 1. > JCR has a simple way to combine multiple rulesets. In one ruleset you = might have: >=20 > #ruleset-id org.ietf.example1 >=20 > $foo =3D int32 >=20 > Then in another ruleset: >=20 > #import org.ietf.example1 as ex1 >=20 > { > "id" : $ex1.foo > } >=20 > 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 =E2=80=9Cgroups=E2=80=9D (*), 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: >=20 > #ruleset-id org.ietf.extended-types >=20 > $rfc2822-date-time =3D > @{format org.ietf.extended-types.rfc2822.date-time} string >=20 > Then use it as: >=20 > #import org.ietf.extended-types as iet >=20 > { > "start-time" : $iet.rfc2822-date-time, > "end-time" : $iet.rfc2822-date-time > } >=20 > The spec for the "org.ietf.extended-types.rfc2822.date-time" format = might read something like: >=20 > Formatted according to the RFC2822 date-time ABNF but omitting > the trailing [CFWS] term. I don=E2=80=99t 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 =3D text .abnf full-date Y =3D text .abnf date-time full-date =3D "full-date" .det rfc3339 date-time =3D "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 =3D ' date-fullyear =3D 4DIGIT date-month =3D 2DIGIT ; 01-12 date-mday =3D 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on ; month/year time-hour =3D 2DIGIT ; 00-23 time-minute =3D 2DIGIT ; 00-59 time-second =3D 2DIGIT ; 00-58, 00-59, 00-60 based on leap = sec ; rules time-secfrac =3D "." 1*DIGIT time-numoffset =3D ("+" / "-") time-hour ":" time-minute time-offset =3D "Z" / time-numoffset partial-time =3D time-hour ":" time-minute ":" time-second [time-secfrac] full-date =3D date-fullyear "-" date-month "-" date-mday full-time =3D partial-time time-offset date-time =3D full-date "T" full-time ' .cat rfc5234-core rfc5234-core =3D ' DIGIT =3D %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=E2=80=9D 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). [=E2=80=A6] > 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. =20 Indeed. > Primarily because it has a formally published spec! It also is pretty alive and responding to user requirements. Gr=C3=BC=C3=9Fe, Carsten (*) =46rom 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]. From nobody Tue May 4 06:06:06 2021 Return-Path: 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 ; 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 ; 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 ; 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 Cc: Daniel P , JSON WG , cbor@ietf.org References: <9e811395-2f56-f2b2-b4a6-c686544cb1ef@codalogic.com> From: Pete Cordell Message-ID: <9771fc21-0193-1338-a128-fb9bdf00db66@codalogic.com> Date: Tue, 4 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 --------------------------------------------------------------------- From nobody Tue May 4 06:38:43 2021 Return-Path: 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 505163A0AE8; Tue, 4 May 2021 06:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 c77XPJBirkzy; Tue, 4 May 2021 06:38:34 -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 C44093A0AEE; Tue, 4 May 2021 06:38:33 -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 4FZLX64k8lzyV6; Tue, 4 May 2021 15:38:30 +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 In-Reply-To: <9771fc21-0193-1338-a128-fb9bdf00db66@codalogic.com> Date: Tue, 4 May 2021 15:38:30 +0200 Cc: cbor@ietf.org, JSON WG , Daniel P X-Mao-Original-Outgoing-Id: 641828310.162697-8fbb037fbffc0b1df239fb2a2318519d Content-Transfer-Encoding: quoted-printable Message-Id: <881D79CF-3CA2-46B4-8D9C-CC0D3D817403@tzi.org> References: <9e811395-2f56-f2b2-b4a6-c686544cb1ef@codalogic.com> <9771fc21-0193-1338-a128-fb9bdf00db66@codalogic.com> To: Pete Cordell X-Mailer: Apple Mail (2.3608.120.23.2.6) Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 13:38:38 -0000 On 2021-05-04, at 15:05, Pete Cordell wrote: >=20 > 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. >=20 > 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. Sure, we can add something like that, that is an interesting thought. I=E2=80=99m mostly in favor of also providing a machine-executable form, = which may not cover all the bases (if I say there is a =E2=80=9Csignature=E2= =80=9D of type =E2=80=9Cbstr=E2=80=9D, I won=E2=80=99t be able to = specify in CDDL what exactly I want from that :-). Gr=C3=BC=C3=9Fe, Carsten From nobody Tue May 4 09:56:45 2021 Return-Path: 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 374A83A1261 for ; Tue, 4 May 2021 09:56:41 -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=unavailable 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 YfB9eSo_XRkG for ; Tue, 4 May 2021 09:56:35 -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 0C0773A125E for ; Tue, 4 May 2021 09:56:34 -0700 (PDT) Received: (qmail 7005 invoked from network); 4 May 2021 17:56:26 +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 16:56:26 -0000 To: Carsten Bormann Cc: cbor@ietf.org, JSON WG , Daniel P References: <9e811395-2f56-f2b2-b4a6-c686544cb1ef@codalogic.com> <9771fc21-0193-1338-a128-fb9bdf00db66@codalogic.com> <881D79CF-3CA2-46B4-8D9C-CC0D3D817403@tzi.org> From: Pete Cordell Message-ID: Date: Tue, 4 May 2021 17:56:25 +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: <881D79CF-3CA2-46B4-8D9C-CC0D3D817403@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 16:56:42 -0000 On 04/05/2021 14:38, Carsten Bormann wrote: > On 2021-05-04, at 15:05, Pete Cordell wrote: >> >> 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. > > Sure, we can add something like that, that is an interesting thought. > > I’m mostly in favor of also providing a machine-executable form, which may not cover all the bases (if I say there is a “signature” of type “bstr”, I won’t be able to specify in CDDL what exactly I want from that :-). I agree that an ABNF option is good. In fact, if I had to choose between ABNF and regex, I'd go with ABNF. But your example did make me think, did you consider HEREDOC format in CDDL? e.g. something like: rfc3339 = < 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 6E01A3A0FB0; Tue, 4 May 2021 12:40:50 -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 KqD4XH1dlJfE; Tue, 4 May 2021 12:40:46 -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 8A7573A0FAF; Tue, 4 May 2021 12:40:46 -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 4FZVZ31hzszyRF; Tue, 4 May 2021 21:40:43 +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 In-Reply-To: Date: Tue, 4 May 2021 21:40:42 +0200 Cc: cbor@ietf.org, JSON WG , Daniel P X-Mao-Original-Outgoing-Id: 641850042.7453001-a7d30ad2ab7dbb0ecaf2dc5a0b67e85c Content-Transfer-Encoding: quoted-printable Message-Id: <0472A232-51F2-4173-9A1C-EF9C3A9D3405@tzi.org> References: <9e811395-2f56-f2b2-b4a6-c686544cb1ef@codalogic.com> <9771fc21-0193-1338-a128-fb9bdf00db66@codalogic.com> <881D79CF-3CA2-46B4-8D9C-CC0D3D817403@tzi.org> To: Pete Cordell X-Mailer: Apple Mail (2.3608.120.23.2.6) Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 19:40:51 -0000 On 2021-05-04, at 18:56, Pete Cordell wrote: >=20 > But your example did make me think, did you consider HEREDOC format in = CDDL? e.g. something like: For the .abnf/.abnfb control operators, we tried to make do with what we = had in RFC 8610 (no changes in the syntax, just two new control = operators =E2=80=94 and a third, .det, which is needed to handle = ABNF=E2=80=99s indentation intolerance). A CDDL 2.0 might have a HEREDOC-style mechanism, if people find that = useful. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue May 4 21:56:55 2021 Return-Path: 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 67CEF3A0AD8; Tue, 4 May 2021 21:56:36 -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 BCDmC_nGWixP; Tue, 4 May 2021 21:56:32 -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 C70643A0AD7; Tue, 4 May 2021 21:56:31 -0700 (PDT) Received: from smtpclient.apple (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 4FZkvD4qHSz105p; Wed, 5 May 2021 06:56:24 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) From: Carsten Bormann In-Reply-To: Date: Wed, 5 May 2021 06:56:19 +0200 Cc: cbor@ietf.org, Daniel P , JSON WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <9e811395-2f56-f2b2-b4a6-c686544cb1ef@codalogic.com> <9771fc21-0193-1338-a128-fb9bdf00db66@codalogic.com> <881D79CF-3CA2-46B4-8D9C-CC0D3D817403@tzi.org> To: Pete Cordell X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 04:56:37 -0000 Ah, I missed this point: > On 4. May 2021, at 18:56, Pete Cordell wrote: >=20 > rfc3339 =3D < date-fullyear =3D 4DIGIT > date-month =3D 2DIGIT ; 01-12 > [=E2=80=A6] > date-time =3D full-date "T" full-time > ABNFEND .cat rfc5234-core >=20 > rfc5234-core =3D < DIGIT =3D %x30-39 ; 0-9 > ; abbreviated here > ABNFEND >=20 > (I think HEREDOCs would normally end when only the end token appears = on its own line, but CDDL could say it has to be the first token on the = line ad other tokens could follow so you can get your .cat rfc5234-core = in.) Using classical HEREDOC syntax, this would actually be: > rfc3339 =3D < date-fullyear =3D 4DIGIT > date-month =3D 2DIGIT ; 01-12 > [=E2=80=A6] > date-time =3D full-date "T" full-time > ABNFEND =E2=80=A6which is maybe the best reason why one might want to prefer = HEREDOCs over strings (or not!). Gr=C3=BC=C3=9Fe, Carsten