From nobody Tue Mar 8 17:05:22 2016 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 C17B412D62D for ; Tue, 8 Mar 2016 17:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.081 X-Spam-Level: X-Spam-Status: No, score=0.081 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKTCvc10DByQ for ; Tue, 8 Mar 2016 17:05:18 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id F146E12DCE1 for ; Tue, 8 Mar 2016 17:05:17 -0800 (PST) X-IronPort-AV: E=Sophos; i="5.22,559,1449493200"; d="scan'208,217"; a="64362729" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 09 Mar 2016 12:05:15 +1100 X-IronPort-AV: E=McAfee;i="5700,7163,8098"; a="89238494" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcavi.tcif.telstra.com.au with ESMTP; 09 Mar 2016 12:05:15 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3755.srv.dir.telstra.com ([2002:ac31:28c4::ac31:28c4]) with mapi; Wed, 9 Mar 2016 12:05:15 +1100 From: "Manger, James" To: "json@ietf.org" Date: Wed, 9 Mar 2016 12:05:13 +1100 Thread-Topic: Go JSON parser ignores the case of member names Thread-Index: AdF5ny6b2pDZTX/nTg2ZVtGQSpK/eA== Message-ID: <255B9BB34FB7D647A506DC292726F6E13BBE5873A1@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E13BBE5873A1WSMSG3153Vsrv_" MIME-Version: 1.0 Archived-At: Subject: [Json] Go JSON parser ignores the case of member names X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2016 01:05:20 -0000 --_000_255B9BB34FB7D647A506DC292726F6E13BBE5873A1WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I noticed that the default JSON parsing in the Go language basically ignore= s the case of member names. Do JSON experts see this case-insensitive parsi= ng as a useful convenience for programmers (being lenient with what you rec= eive), or as a bad insecure design choice? Parsing {"typ":"JWS","alg":"HS256","ALG":"none"} with the following code, f= or instance, prints "none" (not "HS256") - contrary to what the programmer = wanted. type Header struct { Alg string `json:"alg"` Typ string `json:"typ"` } func main() { b :=3D []byte(`{"typ":"JWS","alg":"HS256","ALG":"none"}`) var h Header err :=3D json.Unmarshal(b, &h) fmt.Println(h) } This looks quite diabolical for security as it is trivial to create valid J= SON values that will be interpreted differently by different implementation= s. I would expect most implementations (that are expecting an "alg" member)= to see its "HS256" value and simply ignore the extra "ALG" member. Not Go,= however. Note: An alternative implementation in Go could parse the JSON as= a generic map, then looked for the "alg" member, which would give "HS256". The relevant part of the Go documentation for the encoding/json package is: "To unmarshal JSON into a struct, Unmarshal matches incoming object keys = to the keys used by Marshal (either the struct field name or its tag), pref= erring an exact match but also accepting a case-insensitive match." -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E13BBE5873A1WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I notice= d that the default JSON parsing in the Go language basically ignores the ca= se of member names. Do JSON experts see this case-insensitive parsing as a = useful convenience for programmers (being lenient with what you receive), o= r as a bad insecure design choice?

=  

Parsing {"typ":"JWS&quo= t;,"alg":"HS256","ALG":"none"} with= the following code, for instance, prints “none” (not “HS= 256”) — contrary to what the programmer wanted.

<= p class=3DMsoNormal> 

type Header s= truct {

     &n= bsp;          Alg string `json= :"alg"`

   &nbs= p;            Typ st= ring `json:"typ"`

}=

 

func mai= n() {

     &nbs= p;          b :=3D []byte(`{&q= uot;typ":"JWS","alg":"HS256","ALG&q= uot;:"none"}`)

  &nb= sp;            = var h Header

    &n= bsp;           err :=3D j= son.Unmarshal(b, &h)

  &nb= sp;            = fmt.Println(h)

}

 

This looks quite dia= bolical for security as it is trivial to create valid JSON values that will= be interpreted differently by different implementations. I would expect mo= st implementations (that are expecting an “alg” member) to see = its “HS256” value and simply ignore the extra “ALG”= member. Not Go, however. Note: An alternative implementation in Go could p= arse the JSON as a generic map, then looked for the “alg” membe= r, which would give “HS256”.

 

The relevant part of the Go docu= mentation for the encoding/json package is:

  = “To unmarshal JSON into a struct, Unmarshal matches incoming object k= eys to the keys used by Marshal (either the struct field name or its tag), = preferring an exact match but also accepting a case-insensitive match.”=

 

--

James Manger

 

= --_000_255B9BB34FB7D647A506DC292726F6E13BBE5873A1WSMSG3153Vsrv_-- From nobody Tue Mar 8 17:20:35 2016 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 64CA712DD18 for ; Tue, 8 Mar 2016 17:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KOXyRWu3xcm for ; Tue, 8 Mar 2016 17:20:33 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FEBD12DD12 for ; Tue, 8 Mar 2016 17:20:33 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1adSnc-0004L3-6v; Tue, 08 Mar 2016 20:20:28 -0500 Date: Tue, 8 Mar 2016 20:20:28 -0500 From: John Cowan To: "Manger, James" Message-ID: <20160309012028.GQ32247@mercury.ccil.org> References: <255B9BB34FB7D647A506DC292726F6E13BBE5873A1@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BBE5873A1@WSMSG3153V.srv.dir.telstra.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Go JSON parser ignores the case of member names X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2016 01:20:34 -0000 Manger, James scripsit: > I noticed that the default JSON parsing in the Go language > basically ignores the case of member names. Do JSON experts see this > case-insensitive parsing as a useful convenience for programmers (being > lenient with what you receive), or as a bad insecure design choice? I see it as Very Bad Indeed. It violates the RFC and, as you say, causes a JSON text to be interpreted one way by one recipient and another way by another. > This looks quite diabolical for security as it is trivial to create > valid JSON values that will be interpreted differently by different > implementations. I would expect most implementations (that are expecting > an "alg" member) to see its "HS256" value and simply ignore the extra > "ALG" member. The Right Thing is to _validate your JSON_. Make sure what you expect is there *before* acting on it, and if not *don't act on it*. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org My confusion is rapidly waxing For XML Schema's too taxing: I'd use DTDs / If they had local trees -- I think I best switch to RELAX NG. From nobody Tue Mar 8 19:36:14 2016 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 9C8EB12DDC7 for ; Tue, 8 Mar 2016 19:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkDsYzDK0khL for ; Tue, 8 Mar 2016 19:36:11 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2323912DCEB for ; Tue, 8 Mar 2016 19:36:11 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id g203so51367106iof.2 for ; Tue, 08 Mar 2016 19:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=UM0TvgSGqvQQkjVM9i7hKDaSt3xiB2xGLvbNfhb26hE=; b=I5THfy8P7qSPjf1wruamu/6uQ4mrjkq+Z+XqPjT8hE/UE2z2Xyw1XvhOfEdM9TFBw3 0pRAvhhfJZHKlejdkCgXuvQj9BzFP3DAGRzftFdXgETFwnieHK2RYwxB9s245lSxZ+j3 KfnDxr/gq0quaZSkzKP7d/KL0f99T0Xa5j6oATWPn0s8Bw8nI+E9ND1QZxEeldsS/C2Z GOAqvpw/zUlAX0qSgcl3k6yhrdBqVa1w75u/hno7TRo3mT1m4+V4P338211fKEQQLhcJ MhSBUIr2JQB2Purshb1G+8HkppawukAHesJyyTyGlEa9Nl+0xIYj9WZRGeAfXongQ3lv 6clg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=UM0TvgSGqvQQkjVM9i7hKDaSt3xiB2xGLvbNfhb26hE=; b=Yi7wW24jw0igwzNfkvtWhyiltxaYNZKYBPF+7lDFdWm1xEn9B8jadHnz0EUO7JoXD9 CD3UKQOGHF7WUvQzTpJUgsIZ44g2GTvgucXeaD7p2rKmQkhy52O/Bg3FC2YTYBlB/9DR bPiToSgfMn7lTxC1Lj+hfZFsTLFsHON9kh60RCvYaVnatoJKpMvMFsF0wPzevIXmuw2y 3P/zVmH8QNHJ4rSsK2CTkzYF6R3x9WWm4NgzOnlqTeLSznnauyMNjJuAJLLuYa8jBMGz /9+pUfOkpdc/wIg3xOHcn51XLhtBeOQCsQm28CxzCxBsd5Oj57YQ8WLhEXXuqHGxfZ2I dg2A== X-Gm-Message-State: AD7BkJJ/DY4SyrL1D6reNS4NqWniAp0pbYyfbNECbuevAa1uhnYD8qQjZ9lRNfUqSo8yJySMZ1E7P9xh7+sz1Q== MIME-Version: 1.0 X-Received: by 10.107.164.170 with SMTP id d42mr24989747ioj.80.1457494570464; Tue, 08 Mar 2016 19:36:10 -0800 (PST) Received: by 10.107.155.85 with HTTP; Tue, 8 Mar 2016 19:36:10 -0800 (PST) In-Reply-To: <20160309012028.GQ32247@mercury.ccil.org> References: <255B9BB34FB7D647A506DC292726F6E13BBE5873A1@WSMSG3153V.srv.dir.telstra.com> <20160309012028.GQ32247@mercury.ccil.org> Date: Tue, 8 Mar 2016 19:36:10 -0800 Message-ID: From: Rob Sayre To: John Cowan Content-Type: multipart/alternative; boundary=001a114217dc228576052d95665c Archived-At: Cc: "Manger, James" , "json@ietf.org" Subject: Re: [Json] Go JSON parser ignores the case of member names X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2016 03:36:12 -0000 --001a114217dc228576052d95665c Content-Type: text/plain; charset=UTF-8 Well, there are ways to avoid it too (see below). I see it more as an object-mapper convenience than a JSON conformance problem. I imagine object mapping libraries in other languages have this feature too. - Rob Program that prints all values from example: package main import ( "encoding/json" "log" ) func main() { b := []byte(`{"typ":"JWS","alg":"HS256","ALG":"none"}`) m := make(map[string]string) err := json.Unmarshal(b, &m) if err != nil { log.Fatal("JSON parsing failed") } for k, v := range m { println("k:", k, "v:", v) } } --- k: typ v: JWS k: alg v: HS256 k: ALG v: none On Tue, Mar 8, 2016 at 5:20 PM, John Cowan wrote: > Manger, James scripsit: > > > I noticed that the default JSON parsing in the Go language > > basically ignores the case of member names. Do JSON experts see this > > case-insensitive parsing as a useful convenience for programmers (being > > lenient with what you receive), or as a bad insecure design choice? > > I see it as Very Bad Indeed. It violates the RFC and, as you say, causes > a JSON text to be interpreted one way by one recipient and another way > by another. > > > This looks quite diabolical for security as it is trivial to create > > valid JSON values that will be interpreted differently by different > > implementations. I would expect most implementations (that are expecting > > an "alg" member) to see its "HS256" value and simply ignore the extra > > "ALG" member. > > The Right Thing is to _validate your JSON_. Make sure what you expect > is there *before* acting on it, and if not *don't act on it*. > > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > My confusion is rapidly waxing > For XML Schema's too taxing: > I'd use DTDs / If they had local trees -- > I think I best switch to RELAX NG. > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a114217dc228576052d95665c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, there are ways to avoid it too (see below). I see it= more as an object-mapper convenience than a JSON conformance problem. I im= agine object mapping libraries in other languages have this feature too.
- Rob

Program that prints all val= ues from example:

package main
<= br>
import (
"encoding/json"
"log"
)

f= unc main() {
b= :=3D []byte(`{"typ":"JWS","alg":"HS256&= quot;,"ALG":"none"}`)
m :=3D make(map[string]string)
err :=3D json.Unmarshal(b, &a= mp;m)
if err != =3D nil {
log= .Fatal("JSON parsing failed")
}
for k, v :=3D range m {
println("k:", k, "v:", v)
}
}

---

k: typ v: JWS<= /div>
k: alg v: HS256
k: ALG v: none




<= br>
On Tue, Mar 8, 2016 at 5:20 PM, John Cowan <cowan@mercury.ccil.org> wrote:
Mange= r, James scripsit:

> I noticed that the default JSON parsing in the Go language
> basically ignores the case of member names. Do JSON experts see this > case-insensitive parsing as a useful convenience for programmers (bein= g
> lenient with what you receive), or as a bad insecure design choice?
I see it as Very Bad Indeed.=C2=A0 It violates the RFC and, as you s= ay, causes
a JSON text to be interpreted one way by one recipient and another way
by another.

> This looks quite diabolical for security as it is trivial to create > valid JSON values that will be interpreted differently by different > implementations. I would expect most implementations (that are expecti= ng
> an "alg" member) to see its "HS256" value and simp= ly ignore the extra
> "ALG" member.

The Right Thing is to _validate your JSON_.=C2=A0 Make sure what you= expect
is there *before* acting on it, and if not *don't act on it*.

--
John Cowan=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ccil.org/~cowan=C2=A0 =C2=A0 =C2=A0 =C2=A0 cowan@ccil.o= rg
My confusion is rapidly waxing
For XML Schema's too taxing:
I'd use DTDs / If they had local trees --
I think I best switch to RELAX NG.

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json

--001a114217dc228576052d95665c-- From nobody Wed Mar 9 13:55:04 2016 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 6809312DA36 for ; Wed, 9 Mar 2016 13:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 QzxGQ-2_ahgS for ; Wed, 9 Mar 2016 13:54:51 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E6212D8B9 for ; Wed, 9 Mar 2016 13:54:51 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1adloN-0003yq-4e; Wed, 09 Mar 2016 16:38:31 -0500 Date: Wed, 9 Mar 2016 16:38:31 -0500 From: John Cowan To: Rob Sayre Message-ID: <20160309213830.GB9515@mercury.ccil.org> References: <255B9BB34FB7D647A506DC292726F6E13BBE5873A1@WSMSG3153V.srv.dir.telstra.com> <20160309012028.GQ32247@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: "Manger, James" , "json@ietf.org" Subject: Re: [Json] Go JSON parser ignores the case of member names X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2016 21:55:01 -0000 Rob Sayre scripsit: > Well, there are ways to avoid it too (see below). I see it more as an > object-mapper convenience than a JSON conformance problem. I imagine object > mapping libraries in other languages have this feature too. The problem arises in cases like this: Suppose the spec says that key "alg" specifies the name of the algorithm, and defaults to "none" if there is no key. Then if the upstream provider sends {"typ" : "JWS", "ALG": "HS256"}, then a receiver written in Go will see the algorithm as HS256, whereas any other receiver will see the algorithm as "none". That's almost certainly not the desired result. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org To say that Bilbo's breath was taken away is no description at all. There are no words left to express his staggerment, since Men changed the language that they learned of elves in the days when all the world was wonderful. --The Hobbit From nobody Wed Mar 9 14:29:05 2016 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 9BE4412D84C for ; Wed, 9 Mar 2016 14:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KnNEwRAZa62c for ; Wed, 9 Mar 2016 14:28:56 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2295A12DADE for ; Wed, 9 Mar 2016 14:13:31 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id n186so5047889wmn.1 for ; Wed, 09 Mar 2016 14:13:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=RjnwwbMOkAeJtXypuk6RvrlrTahm6WMFKG9BUYgwKX8=; b=b/fl3dU+GDFsK1jXg59ifZ/8RVkzI6mmT5K4W8BAAD9T6WseTSdx+WYONqoNFQVPiz 7QomdY7s56+xzJky2z2fT0vqCWD+Im/NpnKWUZf24y9wQ9xEfv/+EKxa/YiiCRyqzQWA nwjmM8OBm4nMiMt9c3ZNDclt4FwAi6DZTim1Zmr+85uRPsDDM2O6+j2eZi/jIT4pahtE mownGMXklTCAIz05oYoPK4RvqChyYZAdm2xJqXZFFFYBSg5RSQe6/GNeXXlFEb81GScJ MFeg9CeE39tYh1DF7hfjqXIP738mMQoP5KQhXb2PrEYsWcpB+YBy1qbT+rUzQOJ5pd4l oDAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=RjnwwbMOkAeJtXypuk6RvrlrTahm6WMFKG9BUYgwKX8=; b=IxznaiPKOcSbgVgQJMvbxD0nNqv2qgh2+OfmogEERo3Pe3QyImyoWkv/QpPsR2tCz3 bHAmpg/v3CzjSrqv56WbT8GAy/vqHvlmU+YaDB2XwXz2DcZRy6rjigAkAhLN/XdugnuL HG5WAPi45vnbds2C3ZJVNpel/hloG1JmGAIsL3dnBu0J+4eVOVFtpN+1qE9j/dmG+4c+ QqbZzxucgj0+YKVUJkAzE4PLYdxPn0LOZQJBhPurpQymXs4xcMlTibXnRE9xQw6+Ddxo gh01OCGkVd+zlKPEIFmroEhfWbeX6eqX+qCMiIaDAiweGUy8PPJ8fZg7CKRGWbkWWHkP oK2A== X-Gm-Message-State: AD7BkJKKYNh4yuCDSON3w5pRIOPaqZfdK53U8+dzWI/Mp+pVrSQLOu6jIBDfJxzmrs/vRg== X-Received: by 10.194.71.135 with SMTP id v7mr42599wju.135.1457561609817; Wed, 09 Mar 2016 14:13:29 -0800 (PST) Received: from [192.168.1.79] (83.203.130.77.rev.sfr.net. [77.130.203.83]) by smtp.googlemail.com with ESMTPSA id w125sm566413wmw.18.2016.03.09.14.13.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Mar 2016 14:13:29 -0800 (PST) To: John Cowan , Rob Sayre References: <255B9BB34FB7D647A506DC292726F6E13BBE5873A1@WSMSG3153V.srv.dir.telstra.com> <20160309012028.GQ32247@mercury.ccil.org> <20160309213830.GB9515@mercury.ccil.org> From: Anders Rundgren Message-ID: <56E09FE8.9000807@gmail.com> Date: Wed, 9 Mar 2016 23:12:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160309213830.GB9515@mercury.ccil.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Manger, James" , "json@ietf.org" Subject: Re: [Json] Go JSON parser ignores the case of member names X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2016 22:29:00 -0000 On 2016-03-09 22:38, John Cowan wrote: > Rob Sayre scripsit: > >> Well, there are ways to avoid it too (see below). I see it more as an >> object-mapper convenience than a JSON conformance problem. I imagine object >> mapping libraries in other languages have this feature too. > > The problem arises in cases like this: Suppose the spec says that key > "alg" specifies the name of the algorithm, and defaults to "none" if > there is no key. Then if the upstream provider sends {"typ" : "JWS", > "ALG": "HS256"}, then a receiver written in Go will see the algorithm > as HS256, Which indeed is bad. > whereas any other receiver will see the algorithm as "none". > That's almost certainly not the desired result. Using a RealJSONParser(tm) other receivers will rather choke on the message and complain about an unexpected "ALG" property. I'm just in the process adding such a facility to node.js: https://github.com/cyberphone/node-webpki.org/blob/master/lib/jsonutil.js Anders From nobody Wed Mar 9 18:01:09 2016 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 9396F12DCE2 for ; Wed, 9 Mar 2016 18:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 svA3_RGjzEma for ; Wed, 9 Mar 2016 18:01:03 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06B812DADF for ; Wed, 9 Mar 2016 18:01:02 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id m184so89418016iof.1 for ; Wed, 09 Mar 2016 18:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=P7dmHkH1IAXFMBuVwTa5dPRVUetfYCIO3MeJkOyPMIE=; b=L0XX7xBh70W1vi5GXsq4YlFuyx3LQxQqqEFwUUy49nFf6mDCe5gDF0Iel3wts1x7m7 OsgfiXht0qL7W1Okih8QWmx0dI9UIlYPELTpoJ5985BS009Q3cK5oLhZ8hjZMfRSaSm4 tSK71TRI0NDPPp6RL5ZF6noNs2fPs4c4Alx1C+KDtty4KDIjHzZkQj0HHFV/p5xU2Opl 2aUC9dCvy1Fbt+YB85DPIhRDpgVbShOTmhiCi4rQtkUFdVadOlfxr86WqjpYrFMwmSo+ InYrp7l4Y7gDqykQ8chvCtbCSirTtPgcSlVWEb9KRswi9/dnMo2dmT3TjcQY4kbN5fZr hoyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=P7dmHkH1IAXFMBuVwTa5dPRVUetfYCIO3MeJkOyPMIE=; b=mrNTZYoy54VZwkNUcmiA/xnmZYfk3IjEk6mKAs2cD+Jbiby4ogX4gWa0Bm7UPm0FUR AD10zaNTGrY6n8R5Q2bOlf4Oadmgunn7WUMyY5+lh0xtAV//KTcQZomwsggy6Vy4GTC9 chBIyVMDb7tmMJNraYVI2/V+LQDNOsc2jD223/bYHG6hpMlPFHgT6QplqVeRMoIbjZa/ 42yqUqmdXjspb7C5J6fNQ0VCCA1Eu6+pXJy1BRz5rRUkEZxv4uh3fLukYgESSooJ5QLr TSeCJAfDbxCdzz1W86XOa3tkR0kC0BlQIrH1jx0OyDXFPaP/Q5bd7gqIrqUEsiikW5fA LNlA== X-Gm-Message-State: AD7BkJK3A0kdZK5QmpSL/7dXMMfyICI0X+UV+bScVz54MsiPwSF/HItAI0J/HscILZ35azBNr1s02xMU0O5Q8Q== MIME-Version: 1.0 X-Received: by 10.107.164.170 with SMTP id d42mr965377ioj.80.1457575262101; Wed, 09 Mar 2016 18:01:02 -0800 (PST) Received: by 10.107.20.88 with HTTP; Wed, 9 Mar 2016 18:01:02 -0800 (PST) In-Reply-To: <20160309213830.GB9515@mercury.ccil.org> References: <255B9BB34FB7D647A506DC292726F6E13BBE5873A1@WSMSG3153V.srv.dir.telstra.com> <20160309012028.GQ32247@mercury.ccil.org> <20160309213830.GB9515@mercury.ccil.org> Date: Wed, 9 Mar 2016 18:01:02 -0800 Message-ID: From: Rob Sayre To: John Cowan Content-Type: multipart/alternative; boundary=001a114217dcbb29b5052da82fea Archived-At: Cc: "Manger, James" , "json@ietf.org" Subject: Re: [Json] Go JSON parser ignores the case of member names X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 10 Mar 2016 02:01:07 -0000 --001a114217dcbb29b5052da82fea Content-Type: text/plain; charset=UTF-8 On Wed, Mar 9, 2016 at 1:38 PM, John Cowan wrote: > Rob Sayre scripsit: > > > Well, there are ways to avoid it too (see below). I see it more as an > > object-mapper convenience than a JSON conformance problem. I imagine > object > > mapping libraries in other languages have this feature too. > > The problem arises in cases like this: Suppose the spec says that key > "alg" specifies the name of the algorithm, and defaults to "none" if > there is no key. Then if the upstream provider sends {"typ" : "JWS", > "ALG": "HS256"}, then a receiver written in Go will see the algorithm > as HS256, whereas any other receiver will see the algorithm as "none". > That's almost certainly not the desired result. > I understand the situation. I guess I don't agree there's a conformance problem here, since there are plenty of other APIs in the standard package that don't do this transformation, and even the API in question doesn't do this transformation for all arguments. They're right below the section James quoted. BTW, here's how to get a similar effect using the widely-used Java library Jackson[0]: ObjectMapper objectMapper = new ObjectMapper(); objectMapper.configure(MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES, true); - Rob [0] http://wiki.fasterxml.com/JacksonHome > > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > To say that Bilbo's breath was taken away is no description at all. There > are > no words left to express his staggerment, since Men changed the language > that > they learned of elves in the days when all the world was wonderful. --The > Hobbit > --001a114217dcbb29b5052da82fea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 9, 2016 at 1:38 PM, John Cowan <cowan@mercury.ccil.org>= ; wrote:
Rob Sayre scripsit:

> Well, there are ways to avoid it too (see below). I see it more as an<= br> > object-mapper convenience than a JSON conformance problem. I imagine o= bject
> mapping libraries in other languages have this feature too.

The problem arises in cases like this: Suppose the spec says that ke= y
"alg" specifies the name of the algorithm, and defaults to "= none" if
there is no key.=C2=A0 Then if the upstream provider sends {"typ"= : "JWS",
"ALG": "HS256"}, then a receiver written in Go will see= the algorithm
as HS256, whereas any other receiver will see the algorithm as "none&q= uot;.
That's almost certainly not the desired result.
I understand the situation. I guess I don't agree there= 9;s a conformance problem here, since there are plenty of other APIs in the= standard package that don't do this transformation, and even the API i= n question doesn't do this transformation for all arguments. They'r= e right below the section James quoted.

BTW, here&= #39;s how to get a similar effect using the widely-used Java library Jackso= n[0]:

ObjectMapper objectMapper =3D new Objec= tMapper(); =C2=A0
objectMapper.configure(MapperFeature.ACCEPT_CAS= E_INSENSITIVE_PROPERTIES, true);=C2=A0

- Rob=


=C2=A0

--
John Cowan=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ccil.org/~cowan=C2=A0 =C2=A0 =C2=A0 =C2=A0 cowan@ccil.o= rg
To say that Bilbo's breath was taken away is no description at a= ll.=C2=A0 There are
no words left to express his staggerment, since Men changed the language th= at
they learned of elves in the days when all the world was wonderful. --The H= obbit

--001a114217dcbb29b5052da82fea-- From nobody Wed Mar 9 18:15:11 2016 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 F18B812DD18 for ; Wed, 9 Mar 2016 18:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 yDc_wp6PpFcI for ; Wed, 9 Mar 2016 18:15:08 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5317212DCF4 for ; Wed, 9 Mar 2016 18:15:08 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1adq7y-0006d9-Bc; Wed, 09 Mar 2016 21:15:02 -0500 Date: Wed, 9 Mar 2016 21:15:02 -0500 From: John Cowan To: Rob Sayre Message-ID: <20160310021502.GD9515@mercury.ccil.org> References: <255B9BB34FB7D647A506DC292726F6E13BBE5873A1@WSMSG3153V.srv.dir.telstra.com> <20160309012028.GQ32247@mercury.ccil.org> <20160309213830.GB9515@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: "Manger, James" , "json@ietf.org" Subject: Re: [Json] Go JSON parser ignores the case of member names X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 10 Mar 2016 02:15:10 -0000 Rob Sayre scripsit: > I understand the situation. I guess I don't agree there's a conformance > problem here, since there are plenty of other APIs in the standard package > that don't do this transformation, and even the API in question doesn't do > this transformation for all arguments. They're right below the section > James quoted. Ah. I didn't know that. > BTW, here's how to get a similar effect using the widely-used Java library > Jackson[0]: > > ObjectMapper objectMapper = new ObjectMapper(); > objectMapper.configure(MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES, > true); Sure, but this is a feature you have to enable specifically, not the default. But from what you are saying, the Go case mapping is not the default either. It's perfectly reasonable, given how much ill-formed or incorrect JSON there is, to have relaxed modes. It's just that the main mode should be strict. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Verbogeny is one of the pleasurettes of a creatific thinkerizer. --Peter da Silva From nobody Wed Mar 9 20:56:19 2016 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 D44D312DDB6 for ; Wed, 9 Mar 2016 20:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 NI-IzbMDfcAs for ; Wed, 9 Mar 2016 20:56:15 -0800 (PST) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id DACD012DDB4 for ; Wed, 9 Mar 2016 20:56:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.24,314,1454936400"; d="scan'208";a="66998206" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 10 Mar 2016 15:55:48 +1100 X-IronPort-AV: E=McAfee;i="5700,7163,8099"; a="85209405" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcani.tcif.telstra.com.au with ESMTP; 10 Mar 2016 15:55:48 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3752.srv.dir.telstra.com ([fe80::91f4:aabc:bfb0:95c4%16]) with mapi; Thu, 10 Mar 2016 15:55:48 +1100 From: "Manger, James" To: John Cowan , Rob Sayre Date: Thu, 10 Mar 2016 15:55:47 +1100 Thread-Topic: [Json] Go JSON parser ignores the case of member names Thread-Index: AdF6crTFfW+CeUxXQJieFaX8WfuMrQACYYiA Message-ID: <255B9BB34FB7D647A506DC292726F6E13BBE7517EF@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E13BBE5873A1@WSMSG3153V.srv.dir.telstra.com> <20160309012028.GQ32247@mercury.ccil.org> <20160309213830.GB9515@mercury.ccil.org> <20160310021502.GD9515@mercury.ccil.org> In-Reply-To: <20160310021502.GD9515@mercury.ccil.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Go JSON parser ignores the case of member names X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 10 Mar 2016 04:56:18 -0000 >> I understand the situation. I guess I don't agree there's a=20 >> conformance problem here, since there are plenty of other APIs in the=20 >> standard package that don't do this transformation, and even the API=20 >> in question doesn't do this transformation for all arguments. They're=20 >> right below the section James quoted. > Ah. I didn't know that. I am fairly new to Go so there is heaps I don't know. However, I don't thin= k the case-insensitive transformation is quite as optional as Rob suggests. "encoding/json" looks like THE standard JSON package in Go. It can parse (Unmarshall) a JSON object into a Go map or struct. Parsing to a map (useful for handling unknown or arbitrary JSON) preserves = the case of the object members. Parsing to a struct (ie object-mapping) ignores case - always. I cannot see any option NOT to ignore case when parsing to a struct. There = is no equivalent of MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES. Object-mapping is a great developer convenience. However, it looks like the= Go implementation is an "attractive nuisance" < https://en.wikipedia.org/w= iki/Attractive_nuisance_doctrine>. Parsing to a struct is front and centre = in the doco, yet comes with this risky case-ignoring transformation that ca= nnot be disabled. >> BTW, here's how to get a similar effect using the widely-used Java libra= ry Jackson[0]: >>=20 >> ObjectMapper objectMapper =3D new ObjectMapper();=20 >> objectMapper.configure(MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES,= true); > Sure, but this is a feature you have to enable specifically, not the defa= ult. But from what you are saying, the Go case mapping is not the default = either. > It's perfectly reasonable, given how much ill-formed or incorrect JSON th= ere is, to have relaxed modes. It's just that the main mode should be stri= ct. Go supports tags on struct fields (eg Algorithm string `json:"alg,omitempty= "`). Supporting, say, an "ignorecase" option in the tag might have been a r= easonable design. P.S. Another interesting feature of the standard JSON package in Go is that= it ALWAYS escapes "<" as "\u003c" - as a safety feature, in case the JSON = is used within HTML. This safety decision seems such a contrast to the deci= sion to ALWAYS ignore case when parsing to a struct. -- James Manger From nobody Wed Mar 9 22:54:52 2016 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 D610A12D554 for ; Wed, 9 Mar 2016 22:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rZ3kZwPU6zHS for ; Wed, 9 Mar 2016 22:54:49 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F1412D53F for ; Wed, 9 Mar 2016 22:54:48 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id n186so15851839wmn.1 for ; Wed, 09 Mar 2016 22:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=qAFGPYfLmLwef7OL4IWezIniGMC7X+zsvdf2EW4//7I=; b=xDi4vvzv9kphoe6Dnt4EhY+1WF4VA0KnycMStmDch2GmWWiGS/tJDowC9ezxoVDMKO r7zcDFnegalKfpvCQ9Df2ikH/G/g7+Z1evwmG5vUUBJFzTGtMXbiTiltx/E+5w+Qr+tk +4TC94ljhIzJqVmji4ptdPlrlukjIGSK3SZUitcE0LAIAXHzyz9SvF/DzLedFE9iDxIx dKILXzQwGP1lolJuTZOh4Ir08XCcB9Oi4eZIJCNiiTVZQ0clCiNfofRjcysNQHLKLWnY KcmAaju3LgILLky0TfGW0QmIiu78Y02npp0+gZlqfXVGD6QAloEkHDQ8qqdjipJAHBQf lJgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qAFGPYfLmLwef7OL4IWezIniGMC7X+zsvdf2EW4//7I=; b=a7BjclsxCgmDHMxVzkIorXvbmQ3EhgqghoRuywQxZGdNiQ7VCDKeXOubICBIOU1cv+ hTmc5snGkZbX6b/ThCsaw9xM5KnaCNQMp4qt2sHp1mKj3u6Dkv9LsdMDK6uGc9CT2ozL zDVLMp3eOElO5CwGfelYc/nuZlHuWor7mQ8zmz1wmU4ZzPzZRZM0pCK35Vq2cwzKLzcP zVZXxesAK8BnWEkI+P56EY/85H7UQVoUmma1ssUb0c6BGwRj3SDg4FwpXc1QCd2utzbq G++pypX7rNyp9m4kCv9Z0pqZXRyYhsy7zvg6uTxwOXy9bZRqAjx7ARC5D6H1xOTxa3My i9Cw== X-Gm-Message-State: AD7BkJKLQZemmMgX/J7M5YjrJ/p4qwNJL0p41Bqxj2fvlHLDpd6yMxcPDQtaznUty1a4Tg== X-Received: by 10.194.63.75 with SMTP id e11mr1761158wjs.79.1457592887296; Wed, 09 Mar 2016 22:54:47 -0800 (PST) Received: from [192.168.1.79] (83.203.130.77.rev.sfr.net. [77.130.203.83]) by smtp.googlemail.com with ESMTPSA id o16sm1985354wjr.9.2016.03.09.22.54.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Mar 2016 22:54:46 -0800 (PST) To: "Manger, James" , John Cowan , Rob Sayre References: <255B9BB34FB7D647A506DC292726F6E13BBE5873A1@WSMSG3153V.srv.dir.telstra.com> <20160309012028.GQ32247@mercury.ccil.org> <20160309213830.GB9515@mercury.ccil.org> <20160310021502.GD9515@mercury.ccil.org> <255B9BB34FB7D647A506DC292726F6E13BBE7517EF@WSMSG3153V.srv.dir.telstra.com> From: Anders Rundgren Message-ID: <56E11A14.3000107@gmail.com> Date: Thu, 10 Mar 2016 07:54:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BBE7517EF@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Go JSON parser ignores the case of member names X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 10 Mar 2016 06:54:50 -0000 On 2016-03-10 05:55, Manger, James wrote: > P.S. Another interesting feature of the standard JSON package in Go is that it > ALWAYS escapes "<" as "\u003c" - as a safety feature, in case the JSON is used > within HTML. This safety decision seems such a contrast to the decision to ALWAYS ignore case when parsing to a struct. Thanx for letting me know! The Go team obviously has a lot to do if they want to be compatible with ES6 and be able to create "crypto-safe" JSON objects like required by JCS: https://github.com/golang/go/issues/14135#issuecomment-177265555 Microsoft are closing in on this AFAICT: https://github.com/dotnet/corefx/pull/6665#issuecomment-192380817 Anders https://cyberphone.github.io/openkeystore/resources/docs/jsonsignatures.html > > -- > James Manger > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Thu Mar 10 02:14:19 2016 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 2EB9212D648 for ; Thu, 10 Mar 2016 02:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 utWU2SS-KEqm for ; Thu, 10 Mar 2016 02:14:16 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1FF12D636 for ; Thu, 10 Mar 2016 02:14:16 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id l68so21699562wml.1 for ; Thu, 10 Mar 2016 02:14:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=3arXuVdCot1X7HrNBVSE+QQ5imCGcrr26GyWP1eV560=; b=UQta4jSF8SoQafNoAYhodoGwg+yliMPNSDly3eXfXYC/cA52/uYsnisacWcIEnaOwR TvROVwDJZ/WaFBYnep8xC03lCQrBpbdB/JfkH8LiLJE8ld8BU5bRTjQXwh57lpWU+J9g xWC3H4XDXfY2gesll2bE9NRQ6oX21xRI2qhwjFuoVcBkRh3aDoClFJFdsNONv9/lzSZU lzObmsuUgQ0pLIi60GGno+uK/Y9vatsZBsBr5fwq9XJCQQ4MhB9cXD61ye1UhwuJn7FA 6h2WScFBv/vWhUOIyt6Qw4lPuGosg3nGDAUNyg49xOzpJrnPKauwWYkHcdkhS+XSC1dP Q7DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3arXuVdCot1X7HrNBVSE+QQ5imCGcrr26GyWP1eV560=; b=I7bMG9KrTh4GnMqgr7hrz7X9aefxPAOUrKK3nJQz+CEao8hkOUAgLC+FovuJgNqaVz oFAMrGKGN9/rOdS+cpXeey4ctmAix+FBwwgsW7vkEku8siVPuFt8lcOJuFaD6hDzr6t1 /gLwGg+COUcFsfG5lC2gnyNZdESu3YE88tobL5LnZLoWA+11ytFquzOS0uEXlQifrHll q8LW0jAd8EGSEaVi2ut2I1NJnTXOEU46ZUWnDbev3EBYw2HRK2wsKNWTH6ku1ZdttR44 5wtzrsN0fmZpu2BNqTcNG22Y4OjUCBM7vIs9bqTwuO3lJYZfzmH9RG7GFZWJM7CsTYpj kSPQ== X-Gm-Message-State: AD7BkJJ+K7s5PwPsNQzHZn6G1aOQmrHJDhxHAompqMACw9OUVw9s7xQ/klWP3MFyd/3byg== X-Received: by 10.194.90.137 with SMTP id bw9mr2772112wjb.120.1457604855052; Thu, 10 Mar 2016 02:14:15 -0800 (PST) Received: from [192.168.1.79] (83.203.130.77.rev.sfr.net. [77.130.203.83]) by smtp.googlemail.com with ESMTPSA id r62sm2752630wmd.15.2016.03.10.02.14.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Mar 2016 02:14:13 -0800 (PST) To: "Manger, James" , John Cowan , Rob Sayre References: <255B9BB34FB7D647A506DC292726F6E13BBE5873A1@WSMSG3153V.srv.dir.telstra.com> <20160309012028.GQ32247@mercury.ccil.org> <20160309213830.GB9515@mercury.ccil.org> <20160310021502.GD9515@mercury.ccil.org> <255B9BB34FB7D647A506DC292726F6E13BBE7517EF@WSMSG3153V.srv.dir.telstra.com> From: Anders Rundgren Message-ID: <56E148D4.9030204@gmail.com> Date: Thu, 10 Mar 2016 11:13:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BBE7517EF@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "json@ietf.org" Subject: [Json] JSON in Web Pages. Was: Go JSON parser ignores the case of member names X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 10 Mar 2016 10:14:18 -0000 On 2016-03-10 05:55, Manger, James wrote: > P.S. Another interesting feature of the standard JSON package in Go is that it ALWAYS escapes > "<" as "\u003c" - as a safety feature, in case the JSON is used within HTML. Whow James, you are a true genius for finding difficult spots! My JSON tools have be upgraded to support JSON-serializable JavaScript objects intended for usage in Web pages. That's great but (of course...) I had overlooked the case you mentioned: " }; FAIL! That is, you really have to do as Go which fortunately have no practical implications since an ES6 compatible serializer will anyway produce the right (normalized) result during signature verification. Sometimes you need a little bit of luck as well... Anders From nobody Thu Mar 10 04:58:24 2016 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 0CBBF12D725 for ; Thu, 10 Mar 2016 04:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HZJvVPJHoZG1 for ; Thu, 10 Mar 2016 04:58:19 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2221C12D721 for ; Thu, 10 Mar 2016 04:58:16 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id l68so27479848wml.1 for ; Thu, 10 Mar 2016 04:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=g4RpO1PSf9tccmGhaSvhABwgUTF5qnKF3pPB12aHabA=; b=HRl+3tYrQoFTG67jUqBjP/unC2fSGfDuqQApn2thAB5hJCBHLuk0Di5/xvvP4/nSal lrsZFwVA8cv8dPzJdjxkl0IMC0jW1aUM38yXALHO0duCny9tSpIV9g4iemOB+Q32C0Ls svQRxxXAXLymmoi4i1/wQz96JW3V02Dg9k5cojf6hdTuzBDASjXFx5w+KJxp6rZqfS36 +dvR/vvOIJgFcndoFfj/O/lY7CQSkLQGoZ544ktmvju7H5c9H38CuKPHNSUuJJcIRhIe Lhrbf4RxANo7zKi5cqckcquhkntn5LoMi+OSdmyZzFVgigvmIVQTfeGDA/RzkttwAOx0 eI/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=g4RpO1PSf9tccmGhaSvhABwgUTF5qnKF3pPB12aHabA=; b=U0y3JA21rkR1VEE/h6c0h/ubOxPYgoIPXkmx8ytrg+CzIcR+E6eMz/i93ydRQLOwfU dLjZzcJlnkq5PdBD31PIa/UnOZLG3jzeTV0W3+U9sOO6QC7rLjQAT/YGgTLbk/dhU2sc 12+ZIjfnPmjfoe04Y085E0KH+bv1gI5jTjpwOMotvIQatu/iKkkm2E3QOW9C8LJATfVf d/c9zjFxpTcJqCwlAbMERKaXyFo5lbMmX8o3U44vDOkopc951tNxQQoDE1ib9hYLuOKv emcVBG+2jI4m1wg8kkeNX0L34SjJ06mYC8etiZGtQXC3j2gcSSNbWPjB1+nLHM7l531P W9/g== X-Gm-Message-State: AD7BkJK7np6vDAhVYLYE6cO7LV2P5ZidAlPCY2yaBpmHzuP7FXBnQHATfdXPZ6BhR49i3Q== X-Received: by 10.28.95.131 with SMTP id t125mr3881062wmb.80.1457614694658; Thu, 10 Mar 2016 04:58:14 -0800 (PST) Received: from [192.168.1.79] (83.203.130.77.rev.sfr.net. [77.130.203.83]) by smtp.googlemail.com with ESMTPSA id w15sm1134330wmd.10.2016.03.10.04.58.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Mar 2016 04:58:13 -0800 (PST) To: "Manger, James" , John Cowan , Rob Sayre References: <255B9BB34FB7D647A506DC292726F6E13BBE5873A1@WSMSG3153V.srv.dir.telstra.com> <20160309012028.GQ32247@mercury.ccil.org> <20160309213830.GB9515@mercury.ccil.org> <20160310021502.GD9515@mercury.ccil.org> <255B9BB34FB7D647A506DC292726F6E13BBE7517EF@WSMSG3153V.srv.dir.telstra.com> <56E148D4.9030204@gmail.com> From: Anders Rundgren Message-ID: <56E16F43.9040705@gmail.com> Date: Thu, 10 Mar 2016 13:57:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56E148D4.9030204@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] JSON in Web Pages. Was: Go JSON parser ignores the case of member names X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 10 Mar 2016 12:58:21 -0000 On 2016-03-10 11:13, Anders Rundgren wrote: https://github.com/golang/go/issues/14749 > On 2016-03-10 05:55, Manger, James wrote: > >> P.S. Another interesting feature of the standard JSON package in Go is that it ALWAYS escapes >> "<" as "\u003c" - as a safety feature, in case the JSON is used within HTML. > > Whow James, you are a true genius for finding difficult spots! > > My JSON tools have be upgraded to support JSON-serializable JavaScript objects > intended for usage in Web pages. That's great but (of course...) I had overlooked > the case you mentioned: > > > > " > }; > > FAIL! > > That is, you really have to do as Go which fortunately have no practical implications > since an ES6 compatible serializer will anyway produce the right (normalized) result > during signature verification. Sometimes you need a little bit of luck as well... > > Anders > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Sat Mar 12 09:28:39 2016 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 2450312D5D6 for ; Sat, 12 Mar 2016 09:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9ZWWqOuo4jTQ for ; Sat, 12 Mar 2016 09:28:36 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6BA12D5CF for ; Sat, 12 Mar 2016 09:28:36 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id l68so56698900wml.0 for ; Sat, 12 Mar 2016 09:28:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=+yPN0EU4DWg9JJ4Zf/qjZLCPryJ8xW+h86RSF0h5opU=; b=yuXE3R7SMwhp6jFVIQNuKObCPpd3yvtd7rzzUwwSLlpk7zjanmHAZtZvkvAJzTncIN mpEyMWxy2vb4LUCwGcRB82QNxJXuOIM6Q5khEffp2cAs0UEzR6+GNK1BRp2WszVFOscy WbjcD1pWY/k0aEjT3+e+2JeYjwJtUcUXiIr2CbT4JtKARktE2FGb8qQgRvIFWeInOu6R jaT9Gt7ud4OpbyNIVE5BC2DnI8DFP7PJMgF1/8jGcZtqXoA7GUbFNdL9dBwvuY3tXiim xKEPSxmUxf6a5evTD5iFcS+57heiK4bh9zbhrGmX7rCMw4W/zAeSozMUt/lyEWSruEyd 5vBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=+yPN0EU4DWg9JJ4Zf/qjZLCPryJ8xW+h86RSF0h5opU=; b=iag/6Ux9PmDEWtR/z5NK7UxqqB3a9f+v3F0iiaXmY8165JDDw0Ux4Pa92vCf0u2T0+ BdkJXS6qrc2kRDHM6JDxv20lXG02M7r2fJvi3upCBadWR+x938ibmJcA2ZpUU0bRLXrh BlfI4Rob4UHT4tt9SGwFJv4sp38gYRFm8oO4S6puQQQCNapaNSdV7eXrWEJw/CLvWn4m o4+UUuoP74xHRRNU7kfYgMIsI83d+RmMZALrJZlrDw5fqgh/Se2Sl4Ls94esX6AVZ203 hFCRye22d/8zRFpSnacIVlt7+yfXdwkgQYypNv8vhlFLIWwAWq4gY+RVMUM0lTM7mn1l EzvQ== X-Gm-Message-State: AD7BkJIQTeb9DzherMa0ODXgGTFmkrP8bgfxXaNW7Z620963MATIUuo4NsWh9trZ/ZS6lw== X-Received: by 10.28.111.135 with SMTP id c7mr9644185wmi.46.1457803714659; Sat, 12 Mar 2016 09:28:34 -0800 (PST) Received: from [192.168.1.79] (83.203.130.77.rev.sfr.net. [77.130.203.83]) by smtp.googlemail.com with ESMTPSA id u16sm7919136wmd.5.2016.03.12.09.28.33 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2016 09:28:33 -0800 (PST) To: "json@ietf.org" From: Anders Rundgren Message-ID: <56E4519D.2050109@gmail.com> Date: Sat, 12 Mar 2016 18:27:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Json] JSON serialization - Two (incompatible) modes are in use X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 12 Mar 2016 17:28:38 -0000 Having looked around a bit it seems that the JSON world is rather divided and needs to consider supporting two different serializations, one which is ES6-compatible and another which is ES6-compatible but properly escaped to be used in browser as a JavaScript object. The latter means that '<', '>', and '&' must be expressed as \unnnn. Preferably quotes around identifier-compatible property names are also dropped in the JavaScript mode. Currently, different JSON authors haven't really made up their mind and that makes interoperability for "Crypto Safe" JSON unnecessary difficult although RegEx can be used to get things right. JSON.stringify does NOT have to change because on the wire and for normalization purposes only the "true" JSON notation is useful. Anders From nobody Fri Mar 18 07:30:33 2016 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 9BC8C12D914 for ; Fri, 18 Mar 2016 07:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7xPTS-gSIU-l for ; Fri, 18 Mar 2016 07:30:29 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F6012D8D4 for ; Fri, 18 Mar 2016 07:29:52 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id m126so116846421ywd.0 for ; Fri, 18 Mar 2016 07:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=aNXjfDiU0zUgXtdK9sN0eNpXW1dK/4eDTFti4uycw0c=; b=LidcyrgsKdyym3DQG+pE2d4PUPytfWVpaJ1YfXNDd7O5DmsfoaOW+p+qqVfpRKNWKI ndWXaUbzdCtlgbpWP0dhI8u25WTW2zFRg3XSvVcvK4kalRfPpz8r/Vo87G3ewQ4ZhvaY 0Ff5Pk8hu2hYs3YTYTem/5UHYnKLdlzn69MnT4GO8eXj0InWLbT27d3TG766Fd81D2cI fVa6SP42MU96vrhF/ZJWko+HlrPTOUxNUnhIg8nt2C9cpb5h5XQEPS/OsL24PtSTaG6m lY3w2D05jBA3VKvNBtO5s1dcemlGK61m1dT0L73c9RNcZ3YXVFeNOzR8kwTE4HRSOKba eojA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=aNXjfDiU0zUgXtdK9sN0eNpXW1dK/4eDTFti4uycw0c=; b=mpRdQPNz+L2m+B5iDaYM4IgHPuIHVJSQaAZ/cBa0s52kI98bZRq5oFcm22F/5LyAVS PeKyw30YJZPh6+QaO0AtqWqIE5t+DxFxfrFgJ2+lR4smdF1Jl78urNpXY/zzvHmBRKa2 +TcGceTNVXv6yq+sfAcwgE9WZS2rVgffkJcwbPo2+aE6IiJy8vabMW7Y03OvfInyqGBZ Cicfw26HCsheoIGoIJOWj4hHJoT3K67Ho7YMBGbuMgxbUDBbObQ41NEevn0rC8YngJ8s f4evA8DGVXZv+DhnNwsLwCwAmv1ypbfAhzRD/P7xduNNTMYrgxusgjTcor3WdlwVWCjG DuMg== X-Gm-Message-State: AD7BkJIjbFaeH3+wxoYj9MK9QVTGISqJmYjj2Zyss0UpeVaoHX4WB3EKlMyXXhpcJW28wHxXU8SwpRb3U49XBA== MIME-Version: 1.0 X-Received: by 10.37.5.213 with SMTP id 204mr7338105ybf.19.1458311392142; Fri, 18 Mar 2016 07:29:52 -0700 (PDT) Received: by 10.37.76.201 with HTTP; Fri, 18 Mar 2016 07:29:52 -0700 (PDT) Date: Fri, 18 Mar 2016 10:29:52 -0400 Message-ID: From: Daniel Parker To: json@ietf.org Content-Type: multipart/alternative; boundary=001a11c001e28066f0052e539461 Archived-At: Subject: Re: [Json] JSON Content Rules -05 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 18 Mar 2016 14:30:31 -0000 --001a11c001e28066f0052e539461 Content-Type: text/plain; charset=UTF-8 Regarding JCR - 05 http://www.ietf.org/id/draft-newton-json-content-rules-05.txt Is there anything about the JCR grammar that requires the colon character to be used as a prefix to a value rule, as opposed to simply being a name-rule separator in an object rule? For example, to my eye, the example { "Image" { width, height, "Title" :string, "Thumbnail" { width, height, "Url" :uri }, "IDs" [ *:integer ] } } width "Width" : 0..1280 height "Height" : 0..1024 would look more "JSON like" written as { "Image" { width, height, "Title" :string, "Thumbnail" : { width, height, "Url" :uri }, "IDs" [ *integer ] } } width "Width" : 0..1280 height "Height" : 0..1024 and similarly the_bradys [ parents, children ] children ( :"Greg", :"Marsha", :"Bobby", :"Jan" ) parents ( :"Mike", :"Carol" ) would look more "JSON like" written as the_bradys [ parents, children ] children ("Greg", "Marsha", "Bobby", "Jan" ) parents ( "Mike", "Carol" ). Thanks, Daniel --001a11c001e28066f0052e539461 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Regarding JCR - 05

http://www.ietf.org/id/draft-newt= on-json-content-rules-05.txt

Is there anything about the JCR gra= mmar that requires the colon character to be used as a prefix to a value ru= le, as opposed to simply being a name-rule separator in an object rule?
=
For example, to my eye, the example

{

"Image" {=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0width, height, "Title" :str= ing,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Thumbnail" { width, he= ight, "Url" :uri },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ID= s" [ *:integer ]
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
}

width &qu= ot;Width" : 0..1280
height "Height" : 0..1024

woul= d look more "JSON like" written as

{

"Image&qu= ot; {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0width, height, "Title"= :string,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Thumbnail" : { wi= dth, height, "Url" :uri },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&= quot;IDs" [ *integer ]
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
}

wid= th "Width" : 0..1280
height "Height" : 0..1024
and similarly

the_bradys [ parents, children ]
=C2=A0 =C2= =A0 children ( :"Greg", :"Marsha", :"Bobby", = :"Jan" )

=C2=A0 =C2=A0 =C2=A0 =C2=A0parents ( :"Mike&= quot;, :"Carol" )

would look more "JSON like" wr= itten as

the_bradys [ parents, children ]
=C2=A0 =C2=A0 =C2=A0 ch= ildren ("Greg", "Marsha", "Bobby", "Jan&= quot; )
=C2=A0 =C2=A0 =C2=A0 =C2=A0parents ( "Mike", "Car= ol" ).

Thanks,
Daniel


--001a11c001e28066f0052e539461-- From nobody Fri Mar 18 07:50:16 2016 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 0DAB712D721 for ; Fri, 18 Mar 2016 07:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hxr-us.20150623.gappssmtp.com 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 7rBGtrJZkLgI for ; Fri, 18 Mar 2016 07:50:13 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E50F12D64B for ; Fri, 18 Mar 2016 07:50:12 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id p65so40788647wmp.0 for ; Fri, 18 Mar 2016 07:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ReMutNvIanJfI28SOoRh7jRHbWRlj8sdFGMzPtyZxV8=; b=W0BqkpcvlBnkVbcrnZeYVD+XF75SXGsjFTBolxoe2vPWqTgahsHMRXoCbu4oXnenMN piQd12w00UX1z2g+4COL2LHvWJE9C3yZTCdHlSnLbB/YewlCO2ETSfgng1nhocrrDG4M EgIB8+h9s++7uhcCdg9ZO5i/0TeQPKzJeG+cbr+A53+9oZJ9Jn0tsb8BGmbXEPEX6LLL mb7wjBDeBVc/hngIsexI8Ut2DZ93qee6d0FmHN9mfbpQSo+9M6qTel6RdmIdxkGeQakB Ofn50nOwHgj5rToRI6CBjFi7oi2XFnTxWA560SK9mnc4YEKYL4VNJ98Xxv1Hb/33fXHR 9ySg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ReMutNvIanJfI28SOoRh7jRHbWRlj8sdFGMzPtyZxV8=; b=Fg92SBhO/aRc2sG0GMLlKizofevUZCHb/p+RjR2YywXcEzZ/fJR5n4CmTSbvPeBZTe u6FkIuFXN02o2H2A3qeJAO32GKZPjAXkdPZs1eEzZSFBWtzsE/P3gVnhB93as0AdjHW1 2cEfVhkHS3oFqEUYCPC5/zP0wRXiTjuYtpwQau5d5TWUWFRCZHmchiXyQfcFHZE0BjmZ i3aSMoCUGRVMYToC9m8mOcM1podErHJrYtngPUc3hKShibLYToOuATqfhKsnFqE2kI4N dfUU3vnMW9zbqMj7ZRviBxDQ4zyQQVkT+RnYAv4Hog9sHRU1L3iEGeRRXsnTIinvRmB+ I95Q== X-Gm-Message-State: AD7BkJKI6V3gNF1+3ccYZK8kQdqYepxM4JRWpqIlmkIIYfVIJLQo6ZC0MOwDr9jfP/W3EgF4UjIPuxZDD5I5cA== MIME-Version: 1.0 X-Received: by 10.194.121.194 with SMTP id lm2mr16417413wjb.71.1458312610702; Fri, 18 Mar 2016 07:50:10 -0700 (PDT) Received: by 10.194.41.131 with HTTP; Fri, 18 Mar 2016 07:50:10 -0700 (PDT) X-Originating-IP: [108.45.68.2] In-Reply-To: References: Date: Fri, 18 Mar 2016 10:50:10 -0400 Message-ID: From: Andrew Newton To: Daniel Parker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: JSON WG Subject: Re: [Json] JSON Content Rules -05 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 18 Mar 2016 14:50:15 -0000 Daniel, Actually we realized that too. The -06 version, which should be out soon, has an updated ABNF to allow the colon before object and array rule definitions. However, it is still needed for value rules so a parser can tell the difference between a value rule and a rule name. -andy On Fri, Mar 18, 2016 at 10:29 AM, Daniel Parker wrote: > Regarding JCR - 05 > > http://www.ietf.org/id/draft-newton-json-content-rules-05.txt > > Is there anything about the JCR grammar that requires the colon character to > be used as a prefix to a value rule, as opposed to simply being a name-rule > separator in an object rule? > > For example, to my eye, the example > > { > > "Image" { > width, height, "Title" :string, > "Thumbnail" { width, height, "Url" :uri }, > "IDs" [ *:integer ] > } > } > > width "Width" : 0..1280 > height "Height" : 0..1024 > > would look more "JSON like" written as > > { > > "Image" { > width, height, "Title" :string, > "Thumbnail" : { width, height, "Url" :uri }, > "IDs" [ *integer ] > } > } > > width "Width" : 0..1280 > height "Height" : 0..1024 > > and similarly > > the_bradys [ parents, children ] > children ( :"Greg", :"Marsha", :"Bobby", :"Jan" ) > > parents ( :"Mike", :"Carol" ) > > would look more "JSON like" written as > > the_bradys [ parents, children ] > children ("Greg", "Marsha", "Bobby", "Jan" ) > parents ( "Mike", "Carol" ). > > Thanks, > Daniel > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Fri Mar 18 09:09:39 2016 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 896CB12D860 for ; Fri, 18 Mar 2016 09:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nC7kHw1wGFZb for ; Fri, 18 Mar 2016 09:09:32 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A836012D52C for ; Fri, 18 Mar 2016 09:09:18 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id g127so144729187ywf.2 for ; Fri, 18 Mar 2016 09:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Ni0KShnsOQP/mrZ3JHPmI2+BsW/5RMg9gHjvJcjhbko=; b=mpxz2yRrZqziQo1Na+Mgyt3IJrbogfonh9Pjak6wO2RmEet/4ajGsTPeXgD/c6zI/9 5TJy8SFWNBZHcJOFiB+2M32UVI7B2Tlz58P16kNKuEk/9G3mDdez2uPbtp3wx6Po+sYa 1HYK6EkSbT8OKzJ6SACV8v3LXVBr9YjybQFG33VOa87YyuQ5nhLekmSmDG/OhdNgj/Q8 uzkhH38z3PinGpydp9elw4mllbAMjeM/VKNRLUbQ1tIfnAzf4hK0jjjnXfj+N/3e8nmG qDLX7PzsJmrmrsl2t98zccatLAl/31Vp0DIwklkO9VB2fXt7RWGP4o5XL2O+wYEJetYT cWNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Ni0KShnsOQP/mrZ3JHPmI2+BsW/5RMg9gHjvJcjhbko=; b=BjiRFb6XmeS3BP/MmbH/7E2PtNW/aWwrwPUDbmKGObOH3xAOLG94Ia/4j4mwqK1vS+ RYM33dpto0WAowKWMIfaODMwWJkHR7wNe+xEK1uwrgJvU2DTiM2JREbK49zGkodjdl2Q Lezqgti55WXXHUojmIMMhd/YMVucNRJ/rs3Jjv7XUFOZyfqVfMXfycCJgVmLYCZyvFZS JqMzC/rK5rSHUp87HDn6e/XWUT0s67fd0RbC3xdzDFTcMRXQ4+zBXt8mdIwlIDDoOWcC +/z/qBCRUpXAAhBJnGmH0TEFbblj370UpWnogGf4LMJ0dGCd0rZ2IvOlj+hqw7h8Vvau nIBQ== X-Gm-Message-State: AD7BkJJSexzasXUtunJFqBMgHHQV3PUFMCavoha4pI327yudhXSGuLgNXBw6tuasMNPs2M7VSnaG0csMWMg6NQ== MIME-Version: 1.0 X-Received: by 10.37.16.195 with SMTP id 186mr7689062ybq.164.1458317357768; Fri, 18 Mar 2016 09:09:17 -0700 (PDT) Received: by 10.37.76.201 with HTTP; Fri, 18 Mar 2016 09:09:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 Mar 2016 12:09:17 -0400 Message-ID: From: Daniel Parker To: Andrew Newton Content-Type: multipart/alternative; boundary=001a113ed8f414695c052e54f8b9 Archived-At: Cc: JSON WG Subject: Re: [Json] JSON Content Rules -05 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 18 Mar 2016 16:09:38 -0000 --001a113ed8f414695c052e54f8b9 Content-Type: text/plain; charset=UTF-8 Hi Andy, Thanks for the response, looking forward to -06. Regarding distinguishing value rules and name rules, value rules starting with a quote or a number are straightforward to distinguish, and couldn't "integer", "true", "boolean", etc be treated as names of built in rules, so not necessary to distinguish? In any case, thank you very much for the work you've put into this specification, it's very much appreciated. Best regards, Daniel On Fri, Mar 18, 2016 at 10:50 AM, Andrew Newton wrote: > Daniel, > > Actually we realized that too. The -06 version, which should be out > soon, has an updated ABNF to allow the colon before object and array > rule definitions. > > However, it is still needed for value rules so a parser can tell the > difference between a value rule and a rule name. > > -andy > > On Fri, Mar 18, 2016 at 10:29 AM, Daniel Parker > wrote: > > Regarding JCR - 05 > > > > http://www.ietf.org/id/draft-newton-json-content-rules-05.txt > > > > Is there anything about the JCR grammar that requires the colon > character to > > be used as a prefix to a value rule, as opposed to simply being a > name-rule > > separator in an object rule? > > > > For example, to my eye, the example > > > > { > > > > "Image" { > > width, height, "Title" :string, > > "Thumbnail" { width, height, "Url" :uri }, > > "IDs" [ *:integer ] > > } > > } > > > > width "Width" : 0..1280 > > height "Height" : 0..1024 > > > > would look more "JSON like" written as > > > > { > > > > "Image" { > > width, height, "Title" :string, > > "Thumbnail" : { width, height, "Url" :uri }, > > "IDs" [ *integer ] > > } > > } > > > > width "Width" : 0..1280 > > height "Height" : 0..1024 > > > > and similarly > > > > the_bradys [ parents, children ] > > children ( :"Greg", :"Marsha", :"Bobby", :"Jan" ) > > > > parents ( :"Mike", :"Carol" ) > > > > would look more "JSON like" written as > > > > the_bradys [ parents, children ] > > children ("Greg", "Marsha", "Bobby", "Jan" ) > > parents ( "Mike", "Carol" ). > > > > Thanks, > > Daniel > > > > > > > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > > > --001a113ed8f414695c052e54f8b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andy,

Thanks for the response, looki= ng forward to -06.

Regarding distinguishing value = rules and name rules, value rules starting with a quote or a number are str= aightforward to distinguish, and couldn't =C2=A0"integer", &q= uot;true", "boolean", etc be treated as names of built in ru= les, so not necessary to distinguish?=C2=A0

In any= case, thank you very much for the work you've put into this specificat= ion, it's very much appreciated.

Best regards,=
Daniel

On Fri, Mar 18, 2016 at 10:50 AM, Andrew Newton <andy@hxr.us>= wrote:
Daniel,

Actually we realized that too. The -06 version, which should be out
soon, has an updated ABNF to allow the colon before object and array
rule definitions.

However, it is still needed for value rules so a parser can tell the
difference between a value rule and a rule name.

-andy

On Fri, Mar 18, 2016 at 10:29 AM, Daniel Parker <danielaparker@gmail.com> wrote:
> Regarding JCR - 05
>
> http://www.ietf.org/id/draft-newto= n-json-content-rules-05.txt
>
> Is there anything about the JCR grammar that requires the colon charac= ter to
> be used as a prefix to a value rule, as opposed to simply being a name= -rule
> separator in an object rule?
>
> For example, to my eye, the example
>
> {
>
> "Image" {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 width, height, "Title" :st= ring,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Thumbnail" { width, heigh= t, "Url" :uri },
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "IDs" [ *:integer ]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> }
>
> width "Width" : 0..1280
> height "Height" : 0..1024
>
> would look more "JSON like" written as
>
> {
>
> "Image" {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 width, height, "Title" :st= ring,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Thumbnail" : { width, hei= ght, "Url" :uri },
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "IDs" [ *integer ]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> }
>
> width "Width" : 0..1280
> height "Height" : 0..1024
>
> and similarly
>
> the_bradys [ parents, children ]
>=C2=A0 =C2=A0 =C2=A0children ( :"Greg", :"Marsha", = :"Bobby", :"Jan" )
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 parents ( :"Mike", :"Carol&q= uot; )
>
> would look more "JSON like" written as
>
> the_bradys [ parents, children ]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0children ("Greg", "Marsha&quo= t;, "Bobby", "Jan" )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 parents ( "Mike", "Carol&quo= t; ).
>
> Thanks,
> Daniel
>
>
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>

--001a113ed8f414695c052e54f8b9-- From nobody Fri Mar 18 09:51:31 2016 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 4FD6312D943 for ; Fri, 18 Mar 2016 09:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hxr-us.20150623.gappssmtp.com 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 az1oyC6NbBND for ; Fri, 18 Mar 2016 09:51:27 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77E212D971 for ; Fri, 18 Mar 2016 09:51:26 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id l68so45583255wml.1 for ; Fri, 18 Mar 2016 09:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=7v0KA+3f5ok0uMdxm/exbPld14okzhT/kShE7ieYMW0=; b=ldv2FIwue+i9MZuqRMweFgn6aZPcYVD6UkWTNf5XEIeHMfoTBocL3qgxQG6BMjkEiW uPMZ5HcFZ+wfdOGevJux6VrRHUxRR0gE4SAYDEdpeRlageQhYkGL4Q8SoXkVkjz/kyJk VNRl9ajsYwjv/B/iILi8LLLAzH7IdOyeZ1EXZPSpx9vJL+ri1oPtqX8xgZKU8TEtHaQB 66ejhXE0eJR935j3dBhCv/AboqQQFSlobWd/MYAQz5p5Q8PwU5VgUjfzbzCXpdsgTzUM w2gW+Ih3KEEywz7dnlfMOvky/1O3TbDVnFtSUC6LegnU1wgPfQhepH6rZG2ET8S2Kd1i FCfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=7v0KA+3f5ok0uMdxm/exbPld14okzhT/kShE7ieYMW0=; b=FXpBqqBn6kNOoxFvpoiXgbuDDzg8NTRptdYjO3eVyz7gdKIgRDImbTiBd1wd3exNWT Xt09hiRq/qJDiPKADGhVv84o4PxIbeipGGPbnyzHwSmsrAoSJITzMeUOOqD2Dh3SDd7W jK+zW9WuPCZvW2vYIUG8dbNfsmy1v2Ot81mxlJr27HwGIXJwlRjWXze3Dd90jy3QrGnv nhZ6sc5eZUbwR7xIGBZqebwRScHwCau8Wj1eKU7lAjwoMmf2zeAIKvfK8C+tvWqRZLJh qnBF4kLMjFM+mFUhR2NYNU/1+XNWg97mXWCbUkmvjg+2fj96xiccjdvjOYOxL1M0mUXz 5Ebw== X-Gm-Message-State: AD7BkJJbQDpcax36hIegKyeJ4DTX4qOcNUthEWWoqxoJJ6OG3WMfLV+chzNFBuIIy8Ptf2PbjUb0RPbAKB+fqg== MIME-Version: 1.0 X-Received: by 10.28.136.19 with SMTP id k19mr353641wmd.11.1458319885149; Fri, 18 Mar 2016 09:51:25 -0700 (PDT) Received: by 10.194.41.131 with HTTP; Fri, 18 Mar 2016 09:51:25 -0700 (PDT) X-Originating-IP: [192.149.252.11] In-Reply-To: References: Date: Fri, 18 Mar 2016 12:51:25 -0400 Message-ID: From: Andrew Newton To: Daniel Parker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: JSON WG Subject: Re: [Json] JSON Content Rules -05 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 18 Mar 2016 16:51:29 -0000 Daniel, I like your suggestion. We'll look into it. -andy On Fri, Mar 18, 2016 at 12:09 PM, Daniel Parker wrote: > Hi Andy, > > Thanks for the response, looking forward to -06. > > Regarding distinguishing value rules and name rules, value rules starting > with a quote or a number are straightforward to distinguish, and couldn't > "integer", "true", "boolean", etc be treated as names of built in rules, so > not necessary to distinguish? > > In any case, thank you very much for the work you've put into this > specification, it's very much appreciated. > > Best regards, > Daniel > > On Fri, Mar 18, 2016 at 10:50 AM, Andrew Newton wrote: >> >> Daniel, >> >> Actually we realized that too. The -06 version, which should be out >> soon, has an updated ABNF to allow the colon before object and array >> rule definitions. >> >> However, it is still needed for value rules so a parser can tell the >> difference between a value rule and a rule name. >> >> -andy >> >> On Fri, Mar 18, 2016 at 10:29 AM, Daniel Parker >> wrote: >> > Regarding JCR - 05 >> > >> > http://www.ietf.org/id/draft-newton-json-content-rules-05.txt >> > >> > Is there anything about the JCR grammar that requires the colon >> > character to >> > be used as a prefix to a value rule, as opposed to simply being a >> > name-rule >> > separator in an object rule? >> > >> > For example, to my eye, the example >> > >> > { >> > >> > "Image" { >> > width, height, "Title" :string, >> > "Thumbnail" { width, height, "Url" :uri }, >> > "IDs" [ *:integer ] >> > } >> > } >> > >> > width "Width" : 0..1280 >> > height "Height" : 0..1024 >> > >> > would look more "JSON like" written as >> > >> > { >> > >> > "Image" { >> > width, height, "Title" :string, >> > "Thumbnail" : { width, height, "Url" :uri }, >> > "IDs" [ *integer ] >> > } >> > } >> > >> > width "Width" : 0..1280 >> > height "Height" : 0..1024 >> > >> > and similarly >> > >> > the_bradys [ parents, children ] >> > children ( :"Greg", :"Marsha", :"Bobby", :"Jan" ) >> > >> > parents ( :"Mike", :"Carol" ) >> > >> > would look more "JSON like" written as >> > >> > the_bradys [ parents, children ] >> > children ("Greg", "Marsha", "Bobby", "Jan" ) >> > parents ( "Mike", "Carol" ). >> > >> > Thanks, >> > Daniel >> > >> > >> > >> > _______________________________________________ >> > json mailing list >> > json@ietf.org >> > https://www.ietf.org/mailman/listinfo/json >> > > >