From hallam@gmail.com  Mon Dec  2 13:30:15 2013
Return-Path: <hallam@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11BF1ADF7B; Mon,  2 Dec 2013 13:30:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
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 CFcLKfXTlqzw; Mon,  2 Dec 2013 13:30:12 -0800 (PST)
Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 610E11ADF6D; Mon,  2 Dec 2013 13:30:12 -0800 (PST)
Received: by mail-we0-f179.google.com with SMTP id q59so12418818wes.24 for <multiple recipients>; Mon, 02 Dec 2013 13:30:09 -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:content-type; bh=t8gahYcR8akf/mkeOddBVi53DvkqbYruMlq3LUc/xVA=; b=Tv8gHeGZWVrW9QjpX67gyGeZs3cb68OdgJKtan2F7Pfpf4NhwWZvIl5uldft84y7d7 L5xsrDHZbF+CWwiCmEy5yqDmc5jyIEjYdAlLojlr4sLs9yVqrTkqodcPlw6+MW7+6d3q CEgygZ4rWFJ3cIpwfSb+pcz87+j9KaUzZ2HkCsf8Snj3O+FFiYlR0I1t8XPLHoa7sO0B OfrxKSxUP9pp15QROw4qyg0a5qmv2IU5ayKYalvk8DAdZnW4mefCApTf0X2TlOftfkNz XnUSXO5Hx9+uj1BMBSKt3IZG3ZyEdZvRhhz2AFokYZpFduzsE1bH8x0EU3HoEXezPpT/ ZY1Q==
MIME-Version: 1.0
X-Received: by 10.180.109.201 with SMTP id hu9mr3217126wib.59.1386019809581; Mon, 02 Dec 2013 13:30:09 -0800 (PST)
Received: by 10.194.243.136 with HTTP; Mon, 2 Dec 2013 13:30:09 -0800 (PST)
In-Reply-To: <6C28E0DD-5E45-42DB-A915-795EE0A489CC@w3.org>
References: <CADnb78h8AjPcQLOCwNm0Pt3pObh6uFV5+zy0c_YU6B-u4MtY1Q@mail.gmail.com> <AA45B3C6-1DC5-4B1E-8045-C9FE76022584@vpnc.org> <C93F89AD-81D2-4489-ADC4-AB05A5B10883@cisco.com> <CAHBU6itgE9=WP+c0oXt1W647b1zz+N6+4ZqRa63Ve91TUsGzTA@mail.gmail.com> <CANr5HFVhG5SNhW4yJxDicvFman94FaNi8UZHhcpQbH6AG6pfQg@mail.gmail.com> <CAHBU6it-yHeHVY+3EFvPd0pVu4uLLdH3Gmz53LL4DZWJSyyUuQ@mail.gmail.com> <6C28E0DD-5E45-42DB-A915-795EE0A489CC@w3.org>
Date: Mon, 2 Dec 2013 16:30:09 -0500
Message-ID: <CAMm+Lwh-VNdtTRj6=keGMWbANDqQKbj6CODtwe1rquU8H7+32w@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Tim Berners-Lee <timbl@w3.org>
Content-Type: multipart/alternative; boundary=e89a8f2356bd66e16f04ec93e202
Cc: IETF Discussion <ietf@ietf.org>, JSON WG <json@ietf.org>, Alex Russell <slightlyoff@google.com>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
Subject: Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2013 21:30:15 -0000

--e89a8f2356bd66e16f04ec93e202
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 27, 2013 at 11:51 PM, Tim Berners-Lee <timbl@w3.org> wrote:

JSON is interesting in being a subset of ECMAscript.  That is a big
> dependency -- will it be preserved?
> However as it is unwise to feed JSON into an ECMAscript processor for
> security reasons, that dependency may not affect code, just mean that JSON
> and ECMAscript parsers can share parts at  the moment.
>

As I see it, encoding X is a subset of encoding Y if and only if an encoder
for X will only produce outputs that are valid inputs of encoding Y.

If an issue was to occur it would be because encoding Y has changed or the
definition of Y has changed.


One could imagine that the arc of ECMAscript's evolution could end up
> having all kinds of impact on the data structure syntax and semantics.
> (unordered sets as alternative to lists? who knows).  So in that case one
> could imagine pressure to make a new version of JSON to match.
>

Since we are talking about a serialization format, the distinction between
unordered sets and lists cannot occur at the wire level and this is where
we need interoperation.

I do in fact have a schema compiler for JSON that allows an interface to
specify a set of entries rather than a list. But they are only ever
serialized as lists.

Yes, literal ISO dates and dateTimes -- I added them to my own N3/turtle
> parsers without much fanfare, wish they had been put in the Turtle language
> too.  Maybe they will.
>

And you probably do exactly what I do and represent a DateTime
representation as a subset of String just as byte, int16, int32, int64,
uint* are all subsets of Integer.

One of the things I think we have learned from JSON is that a
self-describing format only needs to specify the abstract type of the datum
and not the representation.

For convenience, I allow a schema to specify the size of an integer and
whether it is signed or unsigned so that the code generator can create
appropriate code bindings. But none of that shows up on the wire, nor is
that particularly helpful.


What we are doing at this point is to fix a version of the JSON encoding in
time so that when a client and server are negotiating use of JSON encoding,
both sides know what is being negotiated.

So hopefully JSON does not change in future, only the description of JSON.


That is not the same as saying that JSON meets all possible current and
future protocol needs. It does not. It is not possible to pass binary data
efficiently for a start and using decimal for floating point representation
is likely to make the format unacceptable for serious data applications
since it introduces conversion errors.

The next question is whether those unmet needs should be addressed by an
entirely new encoding with a completely new syntax and structure or whether
we could extend the JSON model. My view is that we should do the second.

XML is fine for documents but it is not meeting my needs as a protocol
designer. I find XML Schema to be unnecessarily confusing and baroque, the
schema validation features supported don't help me in application
protocols. XML does not support binary encoding of cryptographic data or
floating point.

There are many data encodings on offer but I would like to be able to write
one decoder that can consume a data stream that contains basic JSON data
and JSON with extensions. This makes negotiating an encoding in a Web
service easy, the consumer states which encodings are acceptable and the
sender makes sure what is sent is compatible, downgrading the encoding to
the level accepted if necessary.

-- 
Website: http://hallambaker.com/

--e89a8f2356bd66e16f04ec93e202
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Nov 27, 2013 at 11:51 PM, Tim Berners-Lee <span dir=3D"ltr">&lt;<a href=
=3D"mailto:timbl@w3.org" target=3D"_blank">timbl@w3.org</a>&gt;</span> wrot=
e:</div><div class=3D"gmail_quote">
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div=
><div>JSON is interesting in being a subset of ECMAscript. =A0That is a big=
 dependency -- will it be preserved?</div>
<div>However as it is unwise to=A0feed JSON into an ECMAscript processor fo=
r security reasons, that dependency may not affect code,=A0just mean that J=
SON and ECMAscript parsers can share parts at =A0the moment.</div></div></d=
iv>
</blockquote><div><br></div><div>As I see it, encoding X is a subset of enc=
oding Y if and only if an encoder for X will only produce outputs that are =
valid inputs of encoding Y.</div><div><br></div><div>If an issue was to occ=
ur it would be because encoding Y has changed or the definition of Y has ch=
anged.=A0</div>
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"=
word-wrap:break-word"><div><div>One could imagine that the arc of ECMAscrip=
t&#39;s evolution could end up=A0</div>
<div>having all kinds of impact on the data structure syntax and semantics.=
</div><div>(unordered sets as alternative to lists? who knows). =A0So in th=
at case one</div><div>could imagine pressure to make a new version of JSON =
to match.</div>
</div></div></blockquote><div><br></div><div>Since we are talking about a s=
erialization format, the distinction between unordered sets and lists canno=
t occur at the wire level and this is where we need interoperation.=A0</div=
>
<div><br></div><div>I do in fact have a schema compiler for JSON that allow=
s an interface to specify a set of entries rather than a list. But they are=
 only ever serialized as lists.</div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
<div style=3D"word-wrap:break-word"><div><div>Yes, literal ISO dates and da=
teTimes -- I added them to my own N3/turtle parsers without much fanfare, w=
ish=A0they had been put in the Turtle language too. =A0Maybe they will.=A0<=
/div>
</div></div></blockquote></div><div><br></div><div>And you probably do exac=
tly what I do and represent a DateTime representation as a subset of String=
 just as byte, int16, int32, int64, uint* are all subsets of Integer.</div>
<div>=A0</div><div>One of the things I think we have learned from JSON is t=
hat a self-describing format only needs to specify the abstract type of the=
 datum and not the representation.</div><div><br></div><div>For convenience=
, I allow a schema to specify the size of an integer and whether it is sign=
ed or unsigned so that the code generator can create appropriate code bindi=
ngs. But none of that shows up on the wire, nor is that particularly helpfu=
l.</div>
<div><br></div><div><br></div><div>What we are doing at this point is to fi=
x a version of the JSON encoding in time so that when a client and server a=
re negotiating use of JSON encoding, both sides know what is being negotiat=
ed.</div>
<div><br></div><div>So hopefully JSON does not change in future, only the d=
escription of JSON.</div><div><br></div><div><br></div><div>That is not the=
 same as saying that JSON meets all possible current and future protocol ne=
eds. It does not. It is not possible to pass binary data efficiently for a =
start and using decimal for floating point representation is likely to make=
 the format unacceptable for serious data applications since it introduces =
conversion errors.</div>
<div><br></div><div>The next question is whether those unmet needs should b=
e addressed by an entirely new encoding with a completely new syntax and st=
ructure or whether we could extend the JSON model. My view is that we shoul=
d do the second.</div>
<div><br></div><div>XML is fine for documents but it is not meeting my need=
s as a protocol designer. I find XML Schema to be unnecessarily confusing a=
nd baroque, the schema validation features supported don&#39;t help me in a=
pplication protocols. XML does not support binary encoding of cryptographic=
 data or floating point.=A0</div>
<div><br></div><div>There are many data encodings on offer but I would like=
 to be able to write one decoder that can consume a data stream that contai=
ns basic JSON data and JSON with extensions. This makes negotiating an enco=
ding in a Web service easy, the consumer states which encodings are accepta=
ble and the sender makes sure what is sent is compatible, downgrading the e=
ncoding to the level accepted if necessary.</div>
<div><br></div>-- <br>Website: <a href=3D"http://hallambaker.com/">http://h=
allambaker.com/</a><br>
</div></div>

--e89a8f2356bd66e16f04ec93e202--

From ashok.malhotra@oracle.com  Mon Dec  2 14:15:25 2013
Return-Path: <ashok.malhotra@oracle.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD5A1ADFA9; Mon,  2 Dec 2013 14:15:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 Uc287XEryyjp; Mon,  2 Dec 2013 14:15:24 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC9A1ADF9A; Mon,  2 Dec 2013 14:15:24 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rB2MFIW8023489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Dec 2013 22:15:19 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rB2MFHY0000538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Dec 2013 22:15:17 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rB2MFGPS010065; Mon, 2 Dec 2013 22:15:16 GMT
Received: from [192.168.1.3] (/72.89.126.123) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 02 Dec 2013 14:15:16 -0800
Message-ID: <529D0670.4030507@oracle.com>
Date: Mon, 02 Dec 2013 17:15:12 -0500
From: Ashok Malhotra <ashok.malhotra@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Phillip Hallam-Baker <hallam@gmail.com>, Tim Berners-Lee <timbl@w3.org>
References: <CADnb78h8AjPcQLOCwNm0Pt3pObh6uFV5+zy0c_YU6B-u4MtY1Q@mail.gmail.com>	<AA45B3C6-1DC5-4B1E-8045-C9FE76022584@vpnc.org>	<C93F89AD-81D2-4489-ADC4-AB05A5B10883@cisco.com>	<CAHBU6itgE9=WP+c0oXt1W647b1zz+N6+4ZqRa63Ve91TUsGzTA@mail.gmail.com>	<CANr5HFVhG5SNhW4yJxDicvFman94FaNi8UZHhcpQbH6AG6pfQg@mail.gmail.com>	<CAHBU6it-yHeHVY+3EFvPd0pVu4uLLdH3Gmz53LL4DZWJSyyUuQ@mail.gmail.com>	<6C28E0DD-5E45-42DB-A915-795EE0A489CC@w3.org> <CAMm+Lwh-VNdtTRj6=keGMWbANDqQKbj6CODtwe1rquU8H7+32w@mail.gmail.com>
In-Reply-To: <CAMm+Lwh-VNdtTRj6=keGMWbANDqQKbj6CODtwe1rquU8H7+32w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Mailman-Approved-At: Mon, 02 Dec 2013 14:32:52 -0800
Cc: IETF Discussion <ietf@ietf.org>, JSON WG <json@ietf.org>, Alex Russell <slightlyoff@google.com>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
Subject: Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: ashok.malhotra@oracle.com
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2013 22:15:25 -0000

On 12/2/2013 4:30 PM, Phillip Hallam-Baker wrote:
> XML does not support binary encoding of cryptographic data or floating point. 
XML Schema supports hexBinary and base64binary datatypes.
It also supports float and double datatypes.

All the best, Ashok

From nico@cryptonector.com  Mon Dec  2 14:48:12 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C2B1ADEB5; Mon,  2 Dec 2013 14:48:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 B1YyFJkOpa2W; Mon,  2 Dec 2013 14:48:10 -0800 (PST)
Received: from homiemail-a106.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 508DB1ADBCD; Mon,  2 Dec 2013 14:48:10 -0800 (PST)
Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id D5CBE2005D10E; Mon,  2 Dec 2013 14:48:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=BA692yo0NAq9Wt uD1gix/enARew=; b=cCPyL1MoMcr4hMdstm8P2V3SCUvdGHK3AURJNOSm24T0qt 1N4e7WOcg8zOENFRHnu2PLolEjxitn6lASpD01INEB/H2LcVRzbyUDQnlegzHaTm 4RS1J19XE5stVdjPUQ9gMrDtE8zKfxfnlR3M+gs8Jg6ULt48Eo+yw8Ss1vNlI=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPA id 150B42005D10C; Mon,  2 Dec 2013 14:48:07 -0800 (PST)
Date: Mon, 2 Dec 2013 16:48:06 -0600
From: Nico Williams <nico@cryptonector.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Message-ID: <20131202224802.GY21240@localhost>
References: <CADnb78h8AjPcQLOCwNm0Pt3pObh6uFV5+zy0c_YU6B-u4MtY1Q@mail.gmail.com> <AA45B3C6-1DC5-4B1E-8045-C9FE76022584@vpnc.org> <C93F89AD-81D2-4489-ADC4-AB05A5B10883@cisco.com> <CAHBU6itgE9=WP+c0oXt1W647b1zz+N6+4ZqRa63Ve91TUsGzTA@mail.gmail.com> <CANr5HFVhG5SNhW4yJxDicvFman94FaNi8UZHhcpQbH6AG6pfQg@mail.gmail.com> <CAHBU6it-yHeHVY+3EFvPd0pVu4uLLdH3Gmz53LL4DZWJSyyUuQ@mail.gmail.com> <6C28E0DD-5E45-42DB-A915-795EE0A489CC@w3.org> <CAMm+Lwh-VNdtTRj6=keGMWbANDqQKbj6CODtwe1rquU8H7+32w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMm+Lwh-VNdtTRj6=keGMWbANDqQKbj6CODtwe1rquU8H7+32w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Tim Berners-Lee <timbl@w3.org>, IETF Discussion <ietf@ietf.org>, JSON WG <json@ietf.org>, Alex Russell <slightlyoff@google.com>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
Subject: Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2013 22:48:12 -0000

On Mon, Dec 02, 2013 at 04:30:09PM -0500, Phillip Hallam-Baker wrote:
> Since we are talking about a serialization format, the distinction between
> unordered sets and lists cannot occur at the wire level and this is where
> we need interoperation.

But it can be part of the on-the-wire description.  See below.

> One of the things I think we have learned from JSON is that a
> self-describing format only needs to specify the abstract type of the datum
> and not the representation.

Self-description is a continuum.  Some ASN.1 encoding rules can encode
quite a bit of a schema on the wire -- clearly there's a point at which
the resulting redundancy causes problems.  But it's also true that
having a large subset of the schema in the serialization can be useful
(e.g., for generic "dump" tools).

Given the prevalence of languages like Python, a "set" type will no
doubt seem useful to some!  Heck, the ability to use non-string values
as keys (names) for objects would be nice too -- anyone who's spent much
time with Python and JSON has wished for these things.  JSON alone is
insufficiently expressive for "pickling" Python values; JSON with a fair
bit of convention layered on gets closer to being good enough for
pickling Python values.

Context will affect how much of the schema you or I will find desirable
to see appear redundantly on the wire.  But mostly I agree with you:
"datetime" and such are interpretations of more basic datatypes, and so
they belong in pre-agreed/documented schema rather than on the wire.
Indeed, datetime/timestamp could be either strings or numeric, and still
be understood correctly in context.

> There are many data encodings on offer but I would like to be able to write
> one decoder that can consume a data stream that contains basic JSON data
> and JSON with extensions. This makes negotiating an encoding in a Web
> service easy, the consumer states which encodings are acceptable and the
> sender makes sure what is sent is compatible, downgrading the encoding to
> the level accepted if necessary.

Yes.  Though, really, the main thing that's missing is chunked
(indefinite-length) unescaped binary data.  That's the thing that's
difficult/expenside to deal with in JSON (or XML, for that matter).
Bulk data transfers do matter.  (And if one is going to add that to any
serialization, then plain binary-coded integers and IEEE754 doubles may
be much better, perf-wise, than decimal encodings.)

Nico
-- 

From hallam@gmail.com  Mon Dec  2 15:58:35 2013
Return-Path: <hallam@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359081ADFBB; Mon,  2 Dec 2013 15:58:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
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 gvTPSu4GjX7q; Mon,  2 Dec 2013 15:58:33 -0800 (PST)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 430E81ADEC0; Mon,  2 Dec 2013 15:58:33 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id p61so12426758wes.8 for <multiple recipients>; Mon, 02 Dec 2013 15:58:30 -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:content-type; bh=XYHjAmlOKpNwxGIVjnJaFVxnS6b95T0d49FBijmeOb0=; b=x3pq9CtvLEa4rhphN2mRLzHroVuSqhdbEIlYB1CcwfCBQv+X2jkupB4DEmQDNABniB AuBV0mXh9c8cZc6QGhQquA8tZU6XgOfjyrXwIy4rdtjk2PoElS6AUL7KHQqz0UPeASta VlwDM8SAzIDRkck3Ew1Jh+j1TbKzzQo5dl/I/j9YjqMQXJwI2SATQg5I2cCyDsgm7UAf a17ih88Y7PjGzHbfzRvbXNrfPZJf+JEP/kGNfVAdQrmLBZy1zCvCirIaw928u4W7B9dH h5xEFu1aAAyfwcssFJrWRVkRV+g+V/suwrwuAJNKHrRKiBw+uF23ROl/4g/rUI7UyvyR NSLA==
MIME-Version: 1.0
X-Received: by 10.180.108.97 with SMTP id hj1mr20578316wib.59.1386028710376; Mon, 02 Dec 2013 15:58:30 -0800 (PST)
Received: by 10.194.243.136 with HTTP; Mon, 2 Dec 2013 15:58:30 -0800 (PST)
In-Reply-To: <529D0670.4030507@oracle.com>
References: <CADnb78h8AjPcQLOCwNm0Pt3pObh6uFV5+zy0c_YU6B-u4MtY1Q@mail.gmail.com> <AA45B3C6-1DC5-4B1E-8045-C9FE76022584@vpnc.org> <C93F89AD-81D2-4489-ADC4-AB05A5B10883@cisco.com> <CAHBU6itgE9=WP+c0oXt1W647b1zz+N6+4ZqRa63Ve91TUsGzTA@mail.gmail.com> <CANr5HFVhG5SNhW4yJxDicvFman94FaNi8UZHhcpQbH6AG6pfQg@mail.gmail.com> <CAHBU6it-yHeHVY+3EFvPd0pVu4uLLdH3Gmz53LL4DZWJSyyUuQ@mail.gmail.com> <6C28E0DD-5E45-42DB-A915-795EE0A489CC@w3.org> <CAMm+Lwh-VNdtTRj6=keGMWbANDqQKbj6CODtwe1rquU8H7+32w@mail.gmail.com> <529D0670.4030507@oracle.com>
Date: Mon, 2 Dec 2013 18:58:30 -0500
Message-ID: <CAMm+LwiCpHc_SZhTryhEEFRofY_3eUyBVOioA7X1JyM_AZUBgQ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: ashok.malhotra@oracle.com
Content-Type: multipart/alternative; boundary=e89a8f3bafefee3b9504ec95f4e6
Cc: Tim Berners-Lee <timbl@w3.org>, IETF Discussion <ietf@ietf.org>, JSON WG <json@ietf.org>, Alex Russell <slightlyoff@google.com>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
Subject: Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2013 23:58:35 -0000

--e89a8f3bafefee3b9504ec95f4e6
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Dec 2, 2013 at 5:15 PM, Ashok Malhotra <ashok.malhotra@oracle.com>wrote:

>
> On 12/2/2013 4:30 PM, Phillip Hallam-Baker wrote:
>
>> XML does not support binary encoding of cryptographic data or floating
>> point.
>>
> XML Schema supports hexBinary and base64binary datatypes.
> It also supports float and double datatypes.
>
> All the best, Ashok
>

Those are text encodings of binary data. They are not a binary encoding.
XML is a text encoding, not a binary encoding.



-- 
Website: http://hallambaker.com/

--e89a8f3bafefee3b9504ec95f4e6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Mon, Dec 2, 2013 at 5:15 PM, Ashok Malhotra <span dir=3D"ltr">&l=
t;<a href=3D"mailto:ashok.malhotra@oracle.com" target=3D"_blank">ashok.malh=
otra@oracle.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><br>
On 12/2/2013 4:30 PM, Phillip Hallam-Baker wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
XML does not support binary encoding of cryptographic data or floating poin=
t. <br>
</blockquote></div>
XML Schema supports hexBinary and base64binary datatypes.<br>
It also supports float and double datatypes.<br>
<br>
All the best, Ashok<br>
</blockquote></div><br><div>Those are text encodings of binary data. They a=
re not a binary encoding. XML is a text encoding, not a binary encoding.</d=
iv><div><br></div><div><br></div><div><br></div>-- <br>Website: <a href=3D"=
http://hallambaker.com/">http://hallambaker.com/</a><br>

</div></div>

--e89a8f3bafefee3b9504ec95f4e6--

From hallam@gmail.com  Mon Dec  2 16:07:36 2013
Return-Path: <hallam@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7671ADFAA; Mon,  2 Dec 2013 16:07:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
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 Fun32GAmZcxk; Mon,  2 Dec 2013 16:07:34 -0800 (PST)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id DC7021ADF9A; Mon,  2 Dec 2013 16:07:33 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id b13so9976337wgh.30 for <multiple recipients>; Mon, 02 Dec 2013 16:07:31 -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:content-type; bh=gnhXWov9NSYYriybXeROk3XfdUglPfoUkOyEXzjDznY=; b=E8b1QZxy+epsg5KiVJN/UJEySWGCkvxsFHYk8TUuzluCqgzrlydjOkeGsxa1q/39mO HbFURjj0Uy8+4LmiJONHVMrVgj8xmJSSJDF7ARzE+CF2PaMWQ9XjujTc1waB5Q3UZIoG hWnPGppVHJSJW5412CaplxV4ysrm/tczEkYETTU17Pbj1rxicDREx/dD1I0Hd1JsdvdT t1hOgZ/SIMgrcreoU6/AXtoYpyKneR1vAXrgL64wNvCHBG+mK2TGNq8KeED4rVAFc2fT EqaikT2dm/1PsQL71zvpewy3d+5euWwetEXjG5sxPENMPiVIWRiSnAlZw4DtnSwMkVHS 2ysQ==
MIME-Version: 1.0
X-Received: by 10.180.108.97 with SMTP id hj1mr20602587wib.59.1386029251010; Mon, 02 Dec 2013 16:07:31 -0800 (PST)
Received: by 10.194.243.136 with HTTP; Mon, 2 Dec 2013 16:07:30 -0800 (PST)
In-Reply-To: <20131202224802.GY21240@localhost>
References: <CADnb78h8AjPcQLOCwNm0Pt3pObh6uFV5+zy0c_YU6B-u4MtY1Q@mail.gmail.com> <AA45B3C6-1DC5-4B1E-8045-C9FE76022584@vpnc.org> <C93F89AD-81D2-4489-ADC4-AB05A5B10883@cisco.com> <CAHBU6itgE9=WP+c0oXt1W647b1zz+N6+4ZqRa63Ve91TUsGzTA@mail.gmail.com> <CANr5HFVhG5SNhW4yJxDicvFman94FaNi8UZHhcpQbH6AG6pfQg@mail.gmail.com> <CAHBU6it-yHeHVY+3EFvPd0pVu4uLLdH3Gmz53LL4DZWJSyyUuQ@mail.gmail.com> <6C28E0DD-5E45-42DB-A915-795EE0A489CC@w3.org> <CAMm+Lwh-VNdtTRj6=keGMWbANDqQKbj6CODtwe1rquU8H7+32w@mail.gmail.com> <20131202224802.GY21240@localhost>
Date: Mon, 2 Dec 2013 19:07:30 -0500
Message-ID: <CAMm+LwhZwgrD6U=z+rEAyYD-9TK0ZNdFbmNrVSTRAdB5M2TPCQ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary=e89a8f3bafef27a98804ec961565
Cc: Tim Berners-Lee <timbl@w3.org>, IETF Discussion <ietf@ietf.org>, JSON WG <json@ietf.org>, Alex Russell <slightlyoff@google.com>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
Subject: Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 00:07:36 -0000

--e89a8f3bafef27a98804ec961565
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Dec 2, 2013 at 5:48 PM, Nico Williams <nico@cryptonector.com> wrote:

> On Mon, Dec 02, 2013 at 04:30:09PM -0500, Phillip Hallam-Baker wrote:
> > Since we are talking about a serialization format, the distinction
> between
> > unordered sets and lists cannot occur at the wire level and this is where
> > we need interoperation.
>
> But it can be part of the on-the-wire description.  See below.
>
> > One of the things I think we have learned from JSON is that a
> > self-describing format only needs to specify the abstract type of the
> datum
> > and not the representation.
>
> Self-description is a continuum.  Some ASN.1 encoding rules can encode
> quite a bit of a schema on the wire -- clearly there's a point at which
> the resulting redundancy causes problems.  But it's also true that
> having a large subset of the schema in the serialization can be useful
> (e.g., for generic "dump" tools).
>
> Given the prevalence of languages like Python, a "set" type will no
> doubt seem useful to some!  Heck, the ability to use non-string values
> as keys (names) for objects would be nice too -- anyone who's spent much
> time with Python and JSON has wished for these things.  JSON alone is
> insufficiently expressive for "pickling" Python values; JSON with a fair
> bit of convention layered on gets closer to being good enough for
> pickling Python values.
>

Well that is a rather different situation, the language allows for
polymorphic typing and does not have a clue what the native data type of
the entries it exchanges is.

I agree that there is a utility in that information for pickling data
values but it is not an approach I would like to see in an application
protocol.

The way I would approach this if necessary would be to add in a tag that
could be used to annotate the data with additional type hints.



-- 
Website: http://hallambaker.com/

--e89a8f3bafef27a98804ec961565
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Mon, Dec 2, 2013 at 5:48 PM, Nico Williams <span dir=3D"ltr">&lt=
;<a href=3D"mailto:nico@cryptonector.com" target=3D"_blank">nico@cryptonect=
or.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Mon, Dec 02, 2013 at 04=
:30:09PM -0500, Phillip Hallam-Baker wrote:<br>
&gt; Since we are talking about a serialization format, the distinction bet=
ween<br>
&gt; unordered sets and lists cannot occur at the wire level and this is wh=
ere<br>
&gt; we need interoperation.<br>
<br>
</div>But it can be part of the on-the-wire description. =A0See below.<br>
<div class=3D"im"><br>
&gt; One of the things I think we have learned from JSON is that a<br>
&gt; self-describing format only needs to specify the abstract type of the =
datum<br>
&gt; and not the representation.<br>
<br>
</div>Self-description is a continuum. =A0Some ASN.1 encoding rules can enc=
ode<br>
quite a bit of a schema on the wire -- clearly there&#39;s a point at which=
<br>
the resulting redundancy causes problems. =A0But it&#39;s also true that<br=
>
having a large subset of the schema in the serialization can be useful<br>
(e.g., for generic &quot;dump&quot; tools).<br>
<br>
Given the prevalence of languages like Python, a &quot;set&quot; type will =
no<br>
doubt seem useful to some! =A0Heck, the ability to use non-string values<br=
>
as keys (names) for objects would be nice too -- anyone who&#39;s spent muc=
h<br>
time with Python and JSON has wished for these things. =A0JSON alone is<br>
insufficiently expressive for &quot;pickling&quot; Python values; JSON with=
 a fair<br>
bit of convention layered on gets closer to being good enough for<br>
pickling Python values.<br></blockquote><div><br></div><div>Well that is a =
rather different situation, the language allows for polymorphic typing and =
does not have a clue what the native data type of the entries it exchanges =
is.</div>
<div><br></div><div>I agree that there is a utility in that information for=
 pickling data values but it is not an approach I would like to see in an a=
pplication protocol.=A0</div><div><br></div><div>The way I would approach t=
his if necessary would be to add in a tag that could be used to annotate th=
e data with additional type hints. =A0</div>
<div><br></div></div><br clear=3D"all"><div><br></div>-- <br>Website: <a hr=
ef=3D"http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>

--e89a8f3bafef27a98804ec961565--

From cowan@ccil.org  Mon Dec  2 16:24:59 2013
Return-Path: <cowan@ccil.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0851ADFBF; Mon,  2 Dec 2013 16:24:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 RcQHbE-KU0Xm; Mon,  2 Dec 2013 16:24:57 -0800 (PST)
Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4932E1ADFBE; Mon,  2 Dec 2013 16:24:57 -0800 (PST)
Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from <cowan@ccil.org>) id 1VndnJ-0001yV-0A; Mon, 02 Dec 2013 19:24:53 -0500
Date: Mon, 2 Dec 2013 19:24:52 -0500
From: John Cowan <cowan@mercury.ccil.org>
To: Nico Williams <nico@cryptonector.com>
Message-ID: <20131203002450.GH8672@mercury.ccil.org>
References: <CADnb78h8AjPcQLOCwNm0Pt3pObh6uFV5+zy0c_YU6B-u4MtY1Q@mail.gmail.com> <AA45B3C6-1DC5-4B1E-8045-C9FE76022584@vpnc.org> <C93F89AD-81D2-4489-ADC4-AB05A5B10883@cisco.com> <CAHBU6itgE9=WP+c0oXt1W647b1zz+N6+4ZqRa63Ve91TUsGzTA@mail.gmail.com> <CANr5HFVhG5SNhW4yJxDicvFman94FaNi8UZHhcpQbH6AG6pfQg@mail.gmail.com> <CAHBU6it-yHeHVY+3EFvPd0pVu4uLLdH3Gmz53LL4DZWJSyyUuQ@mail.gmail.com> <6C28E0DD-5E45-42DB-A915-795EE0A489CC@w3.org> <CAMm+Lwh-VNdtTRj6=keGMWbANDqQKbj6CODtwe1rquU8H7+32w@mail.gmail.com> <20131202224802.GY21240@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20131202224802.GY21240@localhost>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <cowan@ccil.org>
X-Mailman-Approved-At: Mon, 02 Dec 2013 16:32:34 -0800
Cc: Tim Berners-Lee <timbl@w3.org>, IETF Discussion <ietf@ietf.org>, JSON WG <json@ietf.org>, Alex Russell <slightlyoff@google.com>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Phillip Hallam-Baker <hallam@gmail.com>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
Subject: Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 00:25:00 -0000

Nico Williams scripsit:

> "datetime" and such are interpretations of more basic datatypes, 

An interval of time is not a string, any more than a number is a string.
They are both *representable* by strings, but everything is: you can
represent a human being or the planet Saturn by a string.

> they belong in pre-agreed/documented schema rather than on the wire.

The decision to do so is arbitrary.

-- 
John Cowan   <cowan@ccil.org>   http://www.ccil.org/~cowan
One time I called in to the central system and started working on a big
thick 'sed' and 'awk' heavy duty data bashing script.  One of the geologists
came by, looked over my shoulder and said 'Oh, that happens to me too.
Try hanging up and phoning in again.'  --Beverly Erlebacher

From slightlyoff@google.com  Mon Dec  2 17:26:52 2013
Return-Path: <slightlyoff@google.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B7D1AE011 for <json@ietfa.amsl.com>; Mon,  2 Dec 2013 17:26:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 ydkA54j6-5al for <json@ietfa.amsl.com>; Mon,  2 Dec 2013 17:26:50 -0800 (PST)
Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 51C171AE010 for <json@ietf.org>; Mon,  2 Dec 2013 17:26:50 -0800 (PST)
Received: by mail-qa0-f41.google.com with SMTP id j5so5153576qaq.0 for <json@ietf.org>; Mon, 02 Dec 2013 17:26:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=atNhf0GBOzXwTQN3RHVUHrlNKNhv0EjmKU2xG8lhzms=; b=Fgvm8f4hfd+gl9WksNZoBQDW2u6GJThIMZAeR4BzV86fXu/77h7v6KQE3SlStA+9kI 3NK1+giMmGovZtL4t23A6cwKHJz1a7i27zBZcu+pAt5S1qhJpMdI4suG2qunGuBqDqoT 7G+5VdozktLYB9skzIq171kBfeYfBm62+b3xQeLKucCV8ueIdI3ttTJks3kdcF0j5P2v ePZq0W35CPhU0iSsLW52JNygvY/Oly6pkXyYRCrbywV5n55532YdVXHmyia+8CqUIpjr yGpPkXfFmAcdap3964QEM5lLIpmqsZ1YJbi4ii6SvCZgPwUDvjopPlvFhmhQlVhfgvSv BPOA==
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:from:date :message-id:subject:to:cc:content-type; bh=atNhf0GBOzXwTQN3RHVUHrlNKNhv0EjmKU2xG8lhzms=; b=QqIkILJbgkyki/s7LQu3Fukr8qrbldSPMdpQOS1NNnj1PMxz+4WIS/jj0QUzklFCFH LCGrxI6qkEMTf31iYLmj0B5AKAReh3o1r7DAbX/Ufr8hITnoO1jP2jIGQlm+zn2K85QA J5BByt0NytTzlQwQD3mHYwMTT+No/SlPnrOCJqZpX49dn28bCNMYUiXMHBmjfOUqMuqO u2Nj+balDGCWcFaLGQJ1t06w8SfxGZ6JamatwD6juYzD/1y8i2aQ+7+P/HrSfndE5d1R NVd1kuZpxkU5V/+6UL3WtVzbOV2AQvBSZQWYqfgbrDkzgsHHLhVhrTAX16WyPS4BRnp0 9AdQ==
X-Gm-Message-State: ALoCoQm1k/kSAad7seOSzxN/RQBApL9hGmTd3KIYu1F9zk8WlxNafYol1tjQ8aopZNPRgDGbucBL2lk6cisv4VBNTUztQyUU9SkwJcvbUkDu2AkYV2htP/lRaoSpBdOGegkaAd9af1CidtYLLD+KcswljEe5fedCLrjT/Fg8rxVLif++7CesVbpKs3O1feKvFT8CHf2E6zo7
X-Received: by 10.224.60.193 with SMTP id q1mr76013128qah.99.1386034007386; Mon, 02 Dec 2013 17:26:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.96.138.195 with HTTP; Mon, 2 Dec 2013 17:26:17 -0800 (PST)
In-Reply-To: <CAMm+Lwh-VNdtTRj6=keGMWbANDqQKbj6CODtwe1rquU8H7+32w@mail.gmail.com>
References: <CADnb78h8AjPcQLOCwNm0Pt3pObh6uFV5+zy0c_YU6B-u4MtY1Q@mail.gmail.com> <AA45B3C6-1DC5-4B1E-8045-C9FE76022584@vpnc.org> <C93F89AD-81D2-4489-ADC4-AB05A5B10883@cisco.com> <CAHBU6itgE9=WP+c0oXt1W647b1zz+N6+4ZqRa63Ve91TUsGzTA@mail.gmail.com> <CANr5HFVhG5SNhW4yJxDicvFman94FaNi8UZHhcpQbH6AG6pfQg@mail.gmail.com> <CAHBU6it-yHeHVY+3EFvPd0pVu4uLLdH3Gmz53LL4DZWJSyyUuQ@mail.gmail.com> <6C28E0DD-5E45-42DB-A915-795EE0A489CC@w3.org> <CAMm+Lwh-VNdtTRj6=keGMWbANDqQKbj6CODtwe1rquU8H7+32w@mail.gmail.com>
From: Alex Russell <slightlyoff@google.com>
Date: Mon, 2 Dec 2013 17:26:17 -0800
Message-ID: <CANr5HFXS3jc+E_q7yrNO7abhh+Qoxz5a6kuTog12Gg=bV-W6tA@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: multipart/alternative; boundary=001a1133dee6a85c1204ec973047
Cc: Tim Berners-Lee <timbl@w3.org>, IETF Discussion <ietf@ietf.org>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
Subject: Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 01:26:52 -0000

--001a1133dee6a85c1204ec973047
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Dec 2, 2013 at 1:30 PM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

> On Wed, Nov 27, 2013 at 11:51 PM, Tim Berners-Lee <timbl@w3.org> wrote:
>
> JSON is interesting in being a subset of ECMAscript.  That is a big
>> dependency -- will it be preserved?
>> However as it is unwise to feed JSON into an ECMAscript processor for
>> security reasons, that dependency may not affect code, just mean that JSON
>> and ECMAscript parsers can share parts at  the moment.
>>
>
> As I see it, encoding X is a subset of encoding Y if and only if an
> encoder for X will only produce outputs that are valid inputs of encoding Y.
>
> If an issue was to occur it would be because encoding Y has changed or the
> definition of Y has changed.
>
>
> One could imagine that the arc of ECMAscript's evolution could end up
>> having all kinds of impact on the data structure syntax and semantics.
>> (unordered sets as alternative to lists? who knows).  So in that case one
>> could imagine pressure to make a new version of JSON to match.
>>
>
> Since we are talking about a serialization format, the distinction between
> unordered sets and lists cannot occur at the wire level and this is where
> we need interoperation.
>
> I do in fact have a schema compiler for JSON that allows an interface to
> specify a set of entries rather than a list. But they are only ever
> serialized as lists.
>
> Yes, literal ISO dates and dateTimes -- I added them to my own N3/turtle
>> parsers without much fanfare, wish they had been put in the Turtle language
>> too.  Maybe they will.
>>
>
> And you probably do exactly what I do and represent a DateTime
> representation as a subset of String just as byte, int16, int32, int64,
> uint* are all subsets of Integer.
>
> One of the things I think we have learned from JSON is that a
> self-describing format only needs to specify the abstract type of the datum
> and not the representation.
>
> For convenience, I allow a schema to specify the size of an integer and
> whether it is signed or unsigned so that the code generator can create
> appropriate code bindings. But none of that shows up on the wire, nor is
> that particularly helpful.
>
>
> What we are doing at this point is to fix a version of the JSON encoding
> in time so that when a client and server are negotiating use of JSON
> encoding, both sides know what is being negotiated.
>
> So hopefully JSON does not change in future, only the description of JSON.
>
>
> That is not the same as saying that JSON meets all possible current and
> future protocol needs. It does not. It is not possible to pass binary data
> efficiently for a start and using decimal for floating point representation
> is likely to make the format unacceptable for serious data applications
> since it introduces conversion errors.
>
> The next question is whether those unmet needs should be addressed by an
> entirely new encoding with a completely new syntax and structure or whether
> we could extend the JSON model. My view is that we should do the second.
>

This seems entirely reasonable, so long as this extension is not called
"JSON" (assuming it adds new grammar productions). Hence the request to
normatively cite ECMA-404 and re-name any IETF-produced spec to reflect
that it is intended to be a media-type registration (or extension document
for protocol authoring, etc.), not an alternate (and therefore perhaps
extensible) definition of JSON.


> XML is fine for documents but it is not meeting my needs as a protocol
> designer. I find XML Schema to be unnecessarily confusing and baroque, the
> schema validation features supported don't help me in application
> protocols. XML does not support binary encoding of cryptographic data or
> floating point.
>
> There are many data encodings on offer but I would like to be able to
> write one decoder that can consume a data stream that contains basic JSON
> data and JSON with extensions. This makes negotiating an encoding in a Web
> service easy, the consumer states which encodings are acceptable and the
> sender makes sure what is sent is compatible, downgrading the encoding to
> the level accepted if necessary.
>
> --
> Website: http://hallambaker.com/
>

--001a1133dee6a85c1204ec973047
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Mon, Dec 2, 2013 at 1:30 PM, Phillip Hallam-Baker <span dir=3D"l=
tr">&lt;<a href=3D"mailto:hallam@gmail.com" target=3D"_blank">hallam@gmail.=
com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"im"><div class=3D"gmail_quote">On Wed, Nov 27, 2013 at 11:51 =
PM, Tim Berners-Lee <span dir=3D"ltr">&lt;<a href=3D"mailto:timbl@w3.org" t=
arget=3D"_blank">timbl@w3.org</a>&gt;</span> wrote:</div>

</div><div class=3D"gmail_quote"><div class=3D"im">
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div=
><div>JSON is interesting in being a subset of ECMAscript. =A0That is a big=
 dependency -- will it be preserved?</div>


<div>However as it is unwise to=A0feed JSON into an ECMAscript processor fo=
r security reasons, that dependency may not affect code,=A0just mean that J=
SON and ECMAscript parsers can share parts at =A0the moment.</div></div></d=
iv>


</blockquote><div><br></div></div><div>As I see it, encoding X is a subset =
of encoding Y if and only if an encoder for X will only produce outputs tha=
t are valid inputs of encoding Y.</div><div><br></div><div>If an issue was =
to occur it would be because encoding Y has changed or the definition of Y =
has changed.=A0</div>

<div class=3D"im">
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"=
word-wrap:break-word"><div><div>One could imagine that the arc of ECMAscrip=
t&#39;s evolution could end up=A0</div>


<div>having all kinds of impact on the data structure syntax and semantics.=
</div><div>(unordered sets as alternative to lists? who knows). =A0So in th=
at case one</div><div>could imagine pressure to make a new version of JSON =
to match.</div>


</div></div></blockquote><div><br></div></div><div>Since we are talking abo=
ut a serialization format, the distinction between unordered sets and lists=
 cannot occur at the wire level and this is where we need interoperation.=
=A0</div>


<div><br></div><div>I do in fact have a schema compiler for JSON that allow=
s an interface to specify a set of entries rather than a list. But they are=
 only ever serialized as lists.</div><div class=3D"im"><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">


<div style=3D"word-wrap:break-word"><div><div>Yes, literal ISO dates and da=
teTimes -- I added them to my own N3/turtle parsers without much fanfare, w=
ish=A0they had been put in the Turtle language too. =A0Maybe they will.=A0<=
/div>


</div></div></blockquote></div></div><div><br></div><div>And you probably d=
o exactly what I do and represent a DateTime representation as a subset of =
String just as byte, int16, int32, int64, uint* are all subsets of Integer.=
</div>


<div>=A0</div><div>One of the things I think we have learned from JSON is t=
hat a self-describing format only needs to specify the abstract type of the=
 datum and not the representation.</div><div><br></div><div>For convenience=
, I allow a schema to specify the size of an integer and whether it is sign=
ed or unsigned so that the code generator can create appropriate code bindi=
ngs. But none of that shows up on the wire, nor is that particularly helpfu=
l.</div>


<div><br></div><div><br></div><div>What we are doing at this point is to fi=
x a version of the JSON encoding in time so that when a client and server a=
re negotiating use of JSON encoding, both sides know what is being negotiat=
ed.</div>


<div><br></div><div>So hopefully JSON does not change in future, only the d=
escription of JSON.</div><div><br></div><div><br></div><div>That is not the=
 same as saying that JSON meets all possible current and future protocol ne=
eds. It does not. It is not possible to pass binary data efficiently for a =
start and using decimal for floating point representation is likely to make=
 the format unacceptable for serious data applications since it introduces =
conversion errors.</div>


<div><br></div><div>The next question is whether those unmet needs should b=
e addressed by an entirely new encoding with a completely new syntax and st=
ructure or whether we could extend the JSON model. My view is that we shoul=
d do the second.</div>

</div></div></blockquote><div><br></div><div>This seems entirely reasonable=
, so long as this extension is not called &quot;JSON&quot; (assuming it add=
s new grammar productions). Hence the request to normatively cite ECMA-404 =
and re-name any IETF-produced spec to reflect that it is intended to be a m=
edia-type registration (or extension document for protocol authoring, etc.)=
, not an alternate (and therefore perhaps extensible) definition of JSON.</=
div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div>XML is fine for documents but it is not meeting my needs=
 as a protocol designer. I find XML Schema to be unnecessarily confusing an=
d baroque, the schema validation features supported don&#39;t help me in ap=
plication protocols. XML does not support binary encoding of cryptographic =
data or floating point.=A0</div>


<div><br></div><div>There are many data encodings on offer but I would like=
 to be able to write one decoder that can consume a data stream that contai=
ns basic JSON data and JSON with extensions. This makes negotiating an enco=
ding in a Web service easy, the consumer states which encodings are accepta=
ble and the sender makes sure what is sent is compatible, downgrading the e=
ncoding to the level accepted if necessary.</div>

<span class=3D"HOEnZb"><font color=3D"#888888">
<div><br></div>-- <br>Website: <a href=3D"http://hallambaker.com/" target=
=3D"_blank">http://hallambaker.com/</a><br>
</font></span></div></div>
</blockquote></div><br></div></div>

--001a1133dee6a85c1204ec973047--

From nico@cryptonector.com  Mon Dec  2 18:23:12 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814BF1ACCE7; Mon,  2 Dec 2013 18:23:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 lzpWijo7p_JG; Mon,  2 Dec 2013 18:23:11 -0800 (PST)
Received: from homiemail-a84.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5371ACCE3; Mon,  2 Dec 2013 18:23:11 -0800 (PST)
Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 861FD1DE070; Mon,  2 Dec 2013 18:23:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=nx5wHek0FnxmcjTZ9eH7 42+2Wek=; b=SHCeuQRg9HHS8lYn+cGaB9h+BozGhkewfavP/TLXS+4wjBS+HAKm hlr647PFoizylSqtr8BKb+fXimAE5peaOdleqFh+O2TdMaphEyqsgczHpgLuW1z/ nVbnx3dLolsj+KWZf+13Qq0gQhrfaSMS7kaQCqi78i5BRks/Q7JW+78=
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id D8A111DE058; Mon,  2 Dec 2013 18:23:07 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id q58so12751712wes.19 for <multiple recipients>; Mon, 02 Dec 2013 18:23:06 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=352/TheAwu0zCi1fYRlrDJ3ayBqSrVT7vgmMnMjZS3c=; b=C3rZIwEpMlDcH/KLrjAdn3t9P794PWZnw/g5tvO8Cjez4rJfkIlf1i/0Nq27wLhdnt ZbN19BHesMPaz4w+/+Wq4hPaQMRziC2CKRCWZguVMdy/Jx0/FZPY9CMnLjYtenGZrxXD FsC1CS2WR69g0kDPtijF2LOyKo14ZSd/1EN/KCHkmTFnnwaALm/mz1BUy1jmv6AUfSxn oVN6kR1KnaEWoGyFPVPb2MvkeK5c+iFLS0+UsM5DYpbhAbN1Sk733qpXO1uu1O0LKcm5 j4Kez4/01nr9XFwBSDBLDoAFyvoTfYUcEIxUSppC7X6xGqHaCeeq2tDht7yoAPlTk+yc /fyw==
MIME-Version: 1.0
X-Received: by 10.180.187.101 with SMTP id fr5mr303182wic.42.1386037386187; Mon, 02 Dec 2013 18:23:06 -0800 (PST)
Received: by 10.216.151.136 with HTTP; Mon, 2 Dec 2013 18:23:06 -0800 (PST)
In-Reply-To: <20131203002450.GH8672@mercury.ccil.org>
References: <CADnb78h8AjPcQLOCwNm0Pt3pObh6uFV5+zy0c_YU6B-u4MtY1Q@mail.gmail.com> <AA45B3C6-1DC5-4B1E-8045-C9FE76022584@vpnc.org> <C93F89AD-81D2-4489-ADC4-AB05A5B10883@cisco.com> <CAHBU6itgE9=WP+c0oXt1W647b1zz+N6+4ZqRa63Ve91TUsGzTA@mail.gmail.com> <CANr5HFVhG5SNhW4yJxDicvFman94FaNi8UZHhcpQbH6AG6pfQg@mail.gmail.com> <CAHBU6it-yHeHVY+3EFvPd0pVu4uLLdH3Gmz53LL4DZWJSyyUuQ@mail.gmail.com> <6C28E0DD-5E45-42DB-A915-795EE0A489CC@w3.org> <CAMm+Lwh-VNdtTRj6=keGMWbANDqQKbj6CODtwe1rquU8H7+32w@mail.gmail.com> <20131202224802.GY21240@localhost> <20131203002450.GH8672@mercury.ccil.org>
Date: Mon, 2 Dec 2013 20:23:06 -0600
Message-ID: <CAK3OfOjYt0jV24YY1PvG_sMEvZjZAiHQ7SPLJ_0RFhHmO8nV7g@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: John Cowan <cowan@mercury.ccil.org>
Content-Type: text/plain; charset=UTF-8
X-Mailman-Approved-At: Mon, 02 Dec 2013 19:52:08 -0800
Cc: Tim Berners-Lee <timbl@w3.org>, IETF Discussion <ietf@ietf.org>, JSON WG <json@ietf.org>, Alex Russell <slightlyoff@google.com>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Phillip Hallam-Baker <hallam@gmail.com>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
Subject: Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 02:23:12 -0000

On Mon, Dec 2, 2013 at 6:24 PM, John Cowan <cowan@mercury.ccil.org> wrote:
> Nico Williams scripsit:
>
>> "datetime" and such are interpretations of more basic datatypes,
>
> An interval of time is not a string, any more than a number is a string.
> They are both *representable* by strings, but everything is: you can
> represent a human being or the planet Saturn by a string.

Interval definitely sounds like a tuple, but, sure, JSON texts can
represent arrays as text...

>> they belong in pre-agreed/documented schema rather than on the wire.
>
> The decision to do so is arbitrary.

Of course it is.  How much to describe on the wire vs. schema is... a
continuum.  Given the JSON we have though... it's best to deal with
datetime via schema.

My point was and still is that the one thing that's sorely missing is
an indefinite-length unescaped binary data encoding, and which is not
nearly as complex, notionally, IMO, as other types.

Nico
--

From cowan@ccil.org  Mon Dec  2 19:54:02 2013
Return-Path: <cowan@ccil.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE6C1ADBC7; Mon,  2 Dec 2013 19:54:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 7sddzhrpDbEa; Mon,  2 Dec 2013 19:54:00 -0800 (PST)
Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 790E61AD937; Mon,  2 Dec 2013 19:54:00 -0800 (PST)
Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from <cowan@ccil.org>) id 1Vnh3d-0005oo-6j; Mon, 02 Dec 2013 22:53:57 -0500
Date: Mon, 2 Dec 2013 22:53:57 -0500
From: John Cowan <cowan@mercury.ccil.org>
To: Nico Williams <nico@cryptonector.com>
Message-ID: <20131203035357.GB9739@mercury.ccil.org>
References: <AA45B3C6-1DC5-4B1E-8045-C9FE76022584@vpnc.org> <C93F89AD-81D2-4489-ADC4-AB05A5B10883@cisco.com> <CAHBU6itgE9=WP+c0oXt1W647b1zz+N6+4ZqRa63Ve91TUsGzTA@mail.gmail.com> <CANr5HFVhG5SNhW4yJxDicvFman94FaNi8UZHhcpQbH6AG6pfQg@mail.gmail.com> <CAHBU6it-yHeHVY+3EFvPd0pVu4uLLdH3Gmz53LL4DZWJSyyUuQ@mail.gmail.com> <6C28E0DD-5E45-42DB-A915-795EE0A489CC@w3.org> <CAMm+Lwh-VNdtTRj6=keGMWbANDqQKbj6CODtwe1rquU8H7+32w@mail.gmail.com> <20131202224802.GY21240@localhost> <20131203002450.GH8672@mercury.ccil.org> <CAK3OfOjYt0jV24YY1PvG_sMEvZjZAiHQ7SPLJ_0RFhHmO8nV7g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAK3OfOjYt0jV24YY1PvG_sMEvZjZAiHQ7SPLJ_0RFhHmO8nV7g@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <cowan@ccil.org>
X-Mailman-Approved-At: Mon, 02 Dec 2013 20:20:26 -0800
Cc: Tim Berners-Lee <timbl@w3.org>, IETF Discussion <ietf@ietf.org>, JSON WG <json@ietf.org>, Alex Russell <slightlyoff@google.com>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Phillip Hallam-Baker <hallam@gmail.com>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
Subject: Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 03:54:02 -0000

Nico Williams scripsit:

> Interval definitely sounds like a tuple, but, sure, JSON texts can
> represent arrays as text...

I was thinking about intervals like 2013-12.

-- 
The Unicode Standard does not encode            John Cowan
idiosyncratic, personal, novel, or private      http://www.ccil.org/~cowan
use characters, nor does it encode logos
or graphics.                                    cowan@ccil.org

From internet-drafts@ietf.org  Wed Dec  4 18:09:13 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFB71AE307; Wed,  4 Dec 2013 18:09:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 XKMFaDYo_K-t; Wed,  4 Dec 2013 18:09:12 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 036631ADFF4; Wed,  4 Dec 2013 18:09:11 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131205020911.25035.12082.idtracker@ietfa.amsl.com>
Date: Wed, 04 Dec 2013 18:09:11 -0800
Cc: json@ietf.org
Subject: [Json] I-D Action: draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 02:09:14 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the JavaScript Object Notation Working Group =
of the IETF.

	Title           : The JSON Data Interchange Format
	Author(s)       : Tim Bray
	Filename        : draft-ietf-json-rfc4627bis-08.txt
	Pages           : 14
	Date            : 2013-12-04

Abstract:
   JavaScript Object Notation (JSON) is a lightweight, text-based,
   language-independent data interchange format.  It was derived from
   the ECMAScript Programming Language Standard.  JSON defines a small
   set of formatting rules for the portable representation of structured
   data.

   This document makes no changes to the definition of JSON; it repairs
   specification errors and offers experience-based interoperability
   guidance.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From tbray@textuality.com  Wed Dec  4 18:10:18 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D051AE311 for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 18:10:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 qEgRnNY99PPE for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 18:10:16 -0800 (PST)
Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8101ADFF4 for <json@ietf.org>; Wed,  4 Dec 2013 18:10:16 -0800 (PST)
Received: by mail-ve0-f182.google.com with SMTP id jy13so13334786veb.27 for <json@ietf.org>; Wed, 04 Dec 2013 18:10:13 -0800 (PST)
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:content-type; bh=mY483h1GLxYHI9GzKPGf8v/JRaiAPaoOmrErjOROvV0=; b=JIZ0TloIoLTqNbk2RuIW5sD07pjuQugGcDNVdJVE87+epktFi5VAfhwdZDY7Y/CYXO mlSojduX4f6QlIlNkTG/H8iGpOFruYxvItoiz6a/992hHDvHV5UlRFBa+VYpC/2m3t0g q7S7Z/4P3nmwZENjVP6CsBwmydeC/LgiIJ++32STiZaVuqi+mxnk7dPPHv2ITjJvX+BV cu7Em2WFlr1yMGDX8kBLG2yPc5EQVsxRFwsacs7HSBIoG1GvxFySspbf/l2QIGc1Kc0l /QUPC2j/1zPLun412MSIU64WrNMJE/rwFAUCBEo8JRvnLmvWDm5vF5nAhqsLd3sR/Rgv VgxQ==
X-Gm-Message-State: ALoCoQnxHlUgRNkwMzINzXQdyXBL+y2yswhA0m3JSc/dm4UGociHpIgGDbmfTcbGvX9yRz3Jz1zB
MIME-Version: 1.0
X-Received: by 10.58.180.227 with SMTP id dr3mr430880vec.36.1386209412901; Wed, 04 Dec 2013 18:10:12 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Wed, 4 Dec 2013 18:10:12 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <20131205020911.25035.18142.idtracker@ietfa.amsl.com>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com>
Date: Wed, 4 Dec 2013 18:10:12 -0800
Message-ID: <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: "json@ietf.org" <json@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b66fbcfa45dbe04ecc007cd
Subject: [Json] Fwd: New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 02:10:18 -0000

--047d7b66fbcfa45dbe04ecc007cd
Content-Type: text/plain; charset=UTF-8

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, Dec 4, 2013 at 6:09 PM
Subject: New Version Notification - draft-ietf-json-rfc4627bis-08.txt
To: json-chairs@tools.ietf.org, draft-ietf-json-rfc4627bis@tools.ietf.org,
presnick@qti.qualcomm.com



A new version (-08) has been submitted for draft-ietf-json-rfc4627bis:
http://www.ietf.org/internet-drafts/draft-ietf-json-rfc4627bis-08.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-json-rfc4627bis-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.

--047d7b66fbcfa45dbe04ecc007cd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote">---------- Forwarded me=
ssage ----------<br>From: <b class=3D"gmail_sendername"></b> <span dir=3D"l=
tr">&lt;<a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.or=
g</a>&gt;</span><br>
Date: Wed, Dec 4, 2013 at 6:09 PM<br>Subject: New Version Notification - dr=
aft-ietf-json-rfc4627bis-08.txt<br>To: <a href=3D"mailto:json-chairs@tools.=
ietf.org">json-chairs@tools.ietf.org</a>, <a href=3D"mailto:draft-ietf-json=
-rfc4627bis@tools.ietf.org">draft-ietf-json-rfc4627bis@tools.ietf.org</a>, =
<a href=3D"mailto:presnick@qti.qualcomm.com">presnick@qti.qualcomm.com</a><=
br>
<br><br><br>
A new version (-08) has been submitted for draft-ietf-json-rfc4627bis:<br>
<a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-json-rfc4627bis-0=
8.txt" target=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-jso=
n-rfc4627bis-08.txt</a><br>
<br>
<br>
The IETF datatracker page for this Internet-Draft is:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis/" ta=
rget=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis=
/</a><br>
<br>
Diff from previous version:<br>
<a href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-08=
" target=3D"_blank">http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4=
627bis-08</a><br>
<br>
Please note that it may take a couple of minutes from the time of submissio=
n<br>
until the htmlized version and diff are available at <a href=3D"http://tool=
s.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br>
<br>
IETF Secretariat.<br>
<br>
</div><br></div>

--047d7b66fbcfa45dbe04ecc007cd--

From tbray@textuality.com  Wed Dec  4 18:15:37 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B361ADFFC for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 18:15:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 AURdyI17EYoZ for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 18:15:35 -0800 (PST)
Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) by ietfa.amsl.com (Postfix) with ESMTP id E27FD1ADF7E for <json@ietf.org>; Wed,  4 Dec 2013 18:15:34 -0800 (PST)
Received: by mail-ve0-f179.google.com with SMTP id jw12so12805101veb.24 for <json@ietf.org>; Wed, 04 Dec 2013 18:15:31 -0800 (PST)
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:content-type; bh=TlxkP0+syzXQQTgQpcZXa6CA1Zy4hpjQIL89CdBvSk4=; b=ac9/y17bvYNFVR4977rHXKEV3/WUhX2gk7z9WN7G9MJftU3nRGKtInybS4g4gYO6O+ EYvRm+pBFIoRPnwsGh0cSE/XyHT0OyQYcf4X006aLT+damw/CtnKlZ69FU7Hu9f7EYjJ gkPq3hQii7V3AmVeWoc/XuIh2jUFPhs63a6JtkmdMlvhgFVqbbpqCh4PrWosZkHzDOM5 GPSv6wWeXz/9zs71KtU3jOEfmxb29vAOBs9HK4j+MS2A+a216zRgdCCtmq5P1A+4Hazd Cfg4xxvXK5gV/R7ZBoticExEgt9d7h92YNs08kdJDPkvutAws96BpXzFomdwvSSjbIjW 709A==
X-Gm-Message-State: ALoCoQldmE0lzVHAWM7WSosEWIeGR5kQzw6XWPUjUOf3vifHz/C0oa69je/jrMXDI0yQy1USei+t
MIME-Version: 1.0
X-Received: by 10.52.0.81 with SMTP id 17mr116873vdc.50.1386209731499; Wed, 04 Dec 2013 18:15:31 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Wed, 4 Dec 2013 18:15:31 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com>
Date: Wed, 4 Dec 2013 18:15:31 -0800
Message-ID: <CAHBU6itbBp3iuuZwz5hyNVvWU7j86m80k4BhFZQ38HTxZg_M6A@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: "json@ietf.org" <json@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b5d8791a1cf5e04ecc01a1e
Subject: Re: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 02:15:37 -0000

--047d7b5d8791a1cf5e04ecc01a1e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Oh, and there=E2=80=99s real HTML at
http://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-08.html


On Wed, Dec 4, 2013 at 6:10 PM, Tim Bray <tbray@textuality.com> wrote:

>
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Wed, Dec 4, 2013 at 6:09 PM
> Subject: New Version Notification - draft-ietf-json-rfc4627bis-08.txt
> To: json-chairs@tools.ietf.org, draft-ietf-json-rfc4627bis@tools.ietf.org=
,
> presnick@qti.qualcomm.com
>
>
>
> A new version (-08) has been submitted for draft-ietf-json-rfc4627bis:
> http://www.ietf.org/internet-drafts/draft-ietf-json-rfc4627bis-08.txt
>
>
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis/
>
> Diff from previous version:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-08
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> IETF Secretariat.
>
>
>

--047d7b5d8791a1cf5e04ecc01a1e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Oh, and there=E2=80=99s real HTML at=C2=A0<a href=3D"http:=
//www.tbray.org/tmp/draft-ietf-json-rfc4627bis-08.html">http://www.tbray.or=
g/tmp/draft-ietf-json-rfc4627bis-08.html</a></div><div class=3D"gmail_extra=
"><br><br><div class=3D"gmail_quote">
On Wed, Dec 4, 2013 at 6:10 PM, Tim Bray <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:tbray@textuality.com" target=3D"_blank">tbray@textuality.com</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5"><div dir=3D"ltr"><br><br><div class=
=3D"gmail_quote">---------- Forwarded message ----------<br>From: <b class=
=3D"gmail_sendername"></b> <span dir=3D"ltr">&lt;<a href=3D"mailto:internet=
-drafts@ietf.org" target=3D"_blank">internet-drafts@ietf.org</a>&gt;</span>=
<br>

Date: Wed, Dec 4, 2013 at 6:09 PM<br>Subject: New Version Notification - dr=
aft-ietf-json-rfc4627bis-08.txt<br>To: <a href=3D"mailto:json-chairs@tools.=
ietf.org" target=3D"_blank">json-chairs@tools.ietf.org</a>, <a href=3D"mail=
to:draft-ietf-json-rfc4627bis@tools.ietf.org" target=3D"_blank">draft-ietf-=
json-rfc4627bis@tools.ietf.org</a>, <a href=3D"mailto:presnick@qti.qualcomm=
.com" target=3D"_blank">presnick@qti.qualcomm.com</a><br>

<br><br><br>
A new version (-08) has been submitted for draft-ietf-json-rfc4627bis:<br>
<a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-json-rfc4627bis-0=
8.txt" target=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-jso=
n-rfc4627bis-08.txt</a><br>
<br>
<br>
The IETF datatracker page for this Internet-Draft is:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis/" ta=
rget=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis=
/</a><br>
<br>
Diff from previous version:<br>
<a href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-08=
" target=3D"_blank">http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4=
627bis-08</a><br>
<br>
Please note that it may take a couple of minutes from the time of submissio=
n<br>
until the htmlized version and diff are available at <a href=3D"http://tool=
s.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br>
<br>
IETF Secretariat.<br>
<br>
</div><br></div>
</div></div></blockquote></div><br></div>

--047d7b5d8791a1cf5e04ecc01a1e--

From mamille2@cisco.com  Wed Dec  4 18:57:10 2013
Return-Path: <mamille2@cisco.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE191AE341 for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 18:57:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 jxhkFaIHGk_u for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 18:57:08 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9890A1AE324 for <json@ietf.org>; Wed,  4 Dec 2013 18:57:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4615; q=dns/txt; s=iport; t=1386212225; x=1387421825; h=from:to:subject:date:message-id:mime-version; bh=sIJqUmn0OMGfpKPBJFTJDO2Hq3WxLO2sBpxzFefa65c=; b=WkLxWs0VGvxy7x8lkK/eZtqWaLFYb0uYw7GyeLVEmSwNIET6r9aQEZ// tg6olV3IZwJ4XPaUDXIV2YFObq+8JfMvzxfR0fsnWOdS7zdbPCTlJEXV2 t290Kt5A3CLzUTDJDSMzMGJlAFJIscIjTEbRiyJU3uoWaQCAjztDPjG8m 0=;
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFAFbqn1KtJXG+/2dsb2JhbABZgwc4U7hqgRsWdIIschkBGmYXEAQcBYd0DaIrnzaOLQEBUYMlgRMDkDGBMYJPg2OSE4MpgXE5
X-IronPort-AV: E=Sophos;i="4.93,830,1378857600";  d="asc'?scan'208";a="289462061"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 05 Dec 2013 02:57:04 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB52v4pV031798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <json@ietf.org>; Thu, 5 Dec 2013 02:57:04 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.57]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 20:57:04 -0600
From: "Matt Miller (mamille2)" <mamille2@cisco.com>
To: JSON WG <json@ietf.org>
Thread-Topic: Response to Statement from W3C TAG
Thread-Index: AQHO8WWtG/WkDckWCEy7+BAN2GEcjQ==
Date: Thu, 5 Dec 2013 02:57:03 +0000
Message-ID: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.79.221]
Content-Type: multipart/signed; boundary="Apple-Mail=_7A07B49A-A617-4717-8EEE-F857FB1D6D6B"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Subject: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 02:57:10 -0000

--Apple-Mail=_7A07B49A-A617-4717-8EEE-F857FB1D6D6B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hello All,

The JSON Working Group has received a statement from W3C Technical =
Architecture Group (TAG) regarding draft-ietf-json-rfc4627bis.  The =
statement can be found at < =
http://www.ietf.org/mail-archive/web/json/current/msg02083.html >.

In response, the Chairs and sponsoring Area Director propose to send the =
following on behalf of the JSON Working Group.  We wish to send the =
response on December 10.  If there are any serious factual errors in the =
following response, let us know before then.  Note that we are *not* =
asking the WG to re-open any of the consensus discussions, simply to see =
if we misstated anything factual.


Thank you,

-- Paul Hoffman and Matt Miller

-----BEGIN RESPONSE-----
Thank you for your statement of concern about =
draft-ietf-json-rfc4627bis. We hope that this response from the chairs =
of the IETF's JSON Working Group allays those concerns.

The TAG expresses concerns about differences between ECMA-404 and =
draft-ietf-json-rfc4627bis. It says "the two specs vary slightly", which =
is no longer true of the syntax in the latest draft of =
draft-ietf-json-rfc4627bis. The TAG gives an example of its concern as =
being about what is allowed in a JSON text. That concern has already =
been met in the latest draft of draft-ietf-json-rfc4627bis: the two =
specifications now have no more syntax differences. During the IETF Last =
Call, it became clear that the consensus was that it was acceptable for =
the definition in draft-ietf-json-rfc4627bis be changed to match that of =
ECMA-404, namely that a JSON text can consist of any single JSON token =
(including the four-character string "42" and the two-digit number 42).

On the topic of JSON semantics, Ecma TC39 has said repeatedly that =
ECMA-404 is meant to only document the JSON syntax, with no description =
of the semantics of encoding or parsing. On the other hand, =
draft-ietf-json-rfc4627bis and RFC 4627 before it express both syntax =
and semantics. For a format such as JSON, interoperability in encoders =
and parsers can only be achieved with descriptions of both syntax and =
semantics.

The statement "we believe this could lead to interoperability issues" is =
of course true: ECMA chose to make JSON as described in the ECMAScript =
standard have different semantics than were expressed in RFC 4627. The =
JSON WG did not, and does not, object to ECMA choosing to have a =
non-interoperable semantics for JSON in its specifications: different =
SDOs are welcome to do so. A great deal of effort in the JSON WG process =
around draft-ietf-json-rfc4627bis has been to carefully describe =
differences between the new spec and ECMAScript.

Lastly, the TAG says "We suggest that the IETF JSON working group should =
re-enter discussions with ECMA TC39 in order to facilitate aligning RFC =
4627bis with the current ECMA-404 specification." The syntax in the =
current IETF draft and the current version of ECMA-404 are believed to =
agree completely.

We also note that "discussions with ECMA TC39" never actually happened: =
the chairs of the IETF JSON WG attempted repeatedly to engage members of =
TC39, but were met almost completely with silence. Further, TC39 never =
engaged the IETF JSON Working Group for any input on ECMA-404. We =
understand that outside the JSON WG, the IETF (through the IAB) and Ecma =
had some early discussions on making a formal liaison relationship; if =
those discussions become fruitful in the future, the sort of =
non-discussion that happened in this work can be avoided.
-----END RESPONSE-----


--Apple-Mail=_7A07B49A-A617-4717-8EEE-F857FB1D6D6B
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJSn+t/AAoJEDWi+S0W7cO1CLcH/2tMZxMI4uoPPyiwC8+vMcfr
jbasnNKRwKN58+TfI/3T6fntJUlIXMfkxmoFegJGzroiFBTgxjP8AwZDE+zv3bvH
nxN0nN100i9Yl05SlDp11hybcP3tX3XB35A68b2j68MTn1KzIQDPIcT1e6oW+3iT
TQUl2/q5dWE7umhxet9JHmPMgMQdGTdvymv4VVoqkeehNQu2+uy03ORxvdLIkbZk
xyXrTDqPJHq9XorA4vRaUngg96X8P/AjVRBv1FggZkC2+T7I/gcBkgRK0Kt06/6Z
kemkrMQ2XCh900WwEdSYZYpamoRM3Ev2u0R9/m3i8+JluRhdqUTy+GMiZW4zqFI=
=0pYz
-----END PGP SIGNATURE-----

--Apple-Mail=_7A07B49A-A617-4717-8EEE-F857FB1D6D6B--

From mamille2@cisco.com  Wed Dec  4 18:57:12 2013
Return-Path: <mamille2@cisco.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4FD1AE324 for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 18:57:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 stiYr_4t7OSa for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 18:57:10 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 16C721AE33F for <json@ietf.org>; Wed,  4 Dec 2013 18:57:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5758; q=dns/txt; s=iport; t=1386212227; x=1387421827; h=from:to:subject:date:message-id:mime-version; bh=aRpTCWGoLBsQKME0848y2cNPX1d0Do4cEyuoBWN3L8Y=; b=W1O8cCEoiQJLkIhBNbCQ0VSNDVUEpa+YHRU82z/lEuR/ElwTXqW75lRw 5cd8GvkefVGPOsZj78/L1sit3hJbXQuVBiN2IgyPYVH6sd1GjnnlrLynZ mxRVpACrl6kkjeZCKGx2jVf46UJkVCZ0bE3HWZZ3xE/NxmsO44WjN9UTS M=;
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFAFbqn1KtJXG9/2dsb2JhbABZgwc4U7gcgWkWdIIqAm4EGQGBACcEIYd0DaIrnzIEkiWBEwOQMYExhjKSE4Mpgio
X-IronPort-AV: E=Sophos;i="4.93,830,1378857600";  d="asc'?scan'208";a="286476207"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 05 Dec 2013 02:57:06 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB52v69Q020175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <json@ietf.org>; Thu, 5 Dec 2013 02:57:06 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.57]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 20:57:06 -0600
From: "Matt Miller (mamille2)" <mamille2@cisco.com>
To: JSON WG <json@ietf.org>
Thread-Topic: Response to Statement from Ecma International TC39
Thread-Index: AQHO8WWuWAIKhOsRzEO63MmngF6OdA==
Date: Thu, 5 Dec 2013 02:57:05 +0000
Message-ID: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.79.221]
Content-Type: multipart/signed; boundary="Apple-Mail=_25B089E7-B5BF-49D1-A44C-E7984B240F94"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Subject: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 02:57:12 -0000

--Apple-Mail=_25B089E7-B5BF-49D1-A44C-E7984B240F94
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hello All,

The JSON Working Group has received a statement from Ecma =
International's Technical Committee 39 (TC39) regarding =
draft-ietf-json-rfc4627bis.  The statement can be found at < =
https://datatracker.ietf.org/documents/LIAISON/liaison-2013-11-25-ecma-tc3=
9-json-ecma-tc39-comment-for-rfc-4727bis-attachment-1.pdf >.

In response, the Chairs and sponsoring Area Director propose to send the =
following on behalf of the JSON Working Group.  We wish to send the =
response on December 10.  If there are any serious factual errors in the =
following response, let us know before then.  Note that we are *not* =
asking the WG to re-open any of the consensus discussions, simply to see =
if we misstated anything factual.


Thank you,

-- Paul Hoffman and Matt Miller

-----BEGIN RESPONSE-----
Thank you for your statement of concern about =
draft-ietf-json-rfc4627bis. The chairs of the IETF's JSON Working Group =
were not aware of any serious concerns that TC39 had with the update =
process. Over the past many months, we repeatedly contacted ECMA and =
TC39 members about the JSON WG and draft-ietf-json-rfc4627bis, but never =
received any significant reply. We know that some TC39 members joined =
the JSON WG mailing list but did not voice any process concerns in the =
WG -- or privately to the WG Chairs -- before or during either of the =
Last Calls on the document.

In the future, it would probably be useful for Ecma and the IETF to have =
a formal liaison relationship. We have heard that there were preliminary =
discussions several months ago, but stopped short of a formal =
relationship before the JSON Working Group was formed. Formalizing the =
liaison relationship will help both SDOs communicate with each other and =
thus avoid late surprises.

As to your specific requests:

- In IETF Last Call, there was consensus to change the definition of =
"JSON text" in draft-ietf-json-rfc4627bis to match the one in ECMA-404. =
The latest draft reflects that change. At this point, we believe that =
there are no syntactic differences between the two specifications.

- The JSON WG decided to change the title of the document to better =
reflect its content. The current document is much more than a media type =
registration: it repeats the JSON syntax originally documented in RFC =
4627, and has been stable for many years, it is a discussion of the JSON =
semantics important to freestanding encoders and parsers, it is a =
discussion of interoperability issues that have been encountered since =
RFC 4627 and ECMA-262 5th Edition were published, and it is a media type =
registration. Having a more accurate title on the document will help =
readers understand its contents and the difference between it and =
ECMA-404.

- After Ecma published ECMA-404, the JSON WG discussed whether to remove =
the ABNF version of the JSON syntax that was established in RFC 4627 =
from draft-ietf-json-rfc4627bis; it was decided not to do so. One reason =
is that ECMA-404 uses "racetrack pictures" to define the syntax, whereas =
IETF documents have traditionally used ABNF, and many developers have =
expressed a strong preference for the ABNF. This might be considered =
simply a matter of style, but it was deemed important by many WG =
members. We intend to keep the discussion and reference to ECMA-404 in =
draft-ietf-json-rfc4627bis, even if Ecma continues to choose not to =
reciprocate in ECMA-262 6th Edition, because developers reading =
draft-ietf-json-rfc4627bis might indeed prefer the racetrack pictures.

- A normative reference to ECMA-404 would be premature without a clear =
and well-understood document management process. Historically, when =
someone reading an RFC sees a normative reference to one version of =
another SDO's standards, they tend to think the reference will apply to =
future versions of that external standard as well. Given the closed =
process that resulted in ECMA-404, it seems quite possible that Ecma =
could later make changes to ECMA-404 that would have a negative effect =
on interoperability from the Internet perspective. When the IETF =
normatively refers to other standards, it almost exclusively does so to =
standards that were developed with processes that are open to discussion =
and contribution by anyone.

If the IETF believed that future development of ECMA-404 would involve a =
similar kind of open participation as seen with the development of =
draft-ietf-json-rfc4627bis, it could certainly revisit the topic of a =
normative reference in any subsequent update. Such a belief could be one =
of the positive products of a formal liaison relationship between the =
IETF and Ecma.
-----END RESPONSE-----


--Apple-Mail=_25B089E7-B5BF-49D1-A44C-E7984B240F94
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJSn+uBAAoJEDWi+S0W7cO1InQIAIkFTv+hLmW5Oy/z1NVis2U/
td0IKoEtzYrh8UuIt+yKsHmdqECaPU75mxT0XtL7h2rxlEN3hOjPZ6wG6G5wkm94
OqIpp1139s5tKVa/Oiuw2iqSGgC3izwvfep/dC7W15Fe4eelJmjkSuzx0oRngUl6
d5IRwnEFyTwlNLfoPbp69SbFM6nV8o/nF6634b75NOQpheCNs8hbgO4srz6yNKUL
SHHb9nnDo73BMIMHzLiD+bO6LyP3k+GE4LQVpInkBAmLHbtOjhJuvj4a8/yQrZpN
iDlncD5zsVzo7OcaOPXgnqIlbcuUW9LlrVk6n/ZRWpBQVrvLIK49A4acrq1HFNc=
=hSCX
-----END PGP SIGNATURE-----

--Apple-Mail=_25B089E7-B5BF-49D1-A44C-E7984B240F94--

From sayrer@gmail.com  Wed Dec  4 19:33:39 2013
Return-Path: <sayrer@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E5D1AE01B for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 19:33:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
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 LXzZNhnD18NA for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 19:33:37 -0800 (PST)
Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 955971AD8EF for <json@ietf.org>; Wed,  4 Dec 2013 19:33:37 -0800 (PST)
Received: by mail-qc0-f172.google.com with SMTP id e16so4370563qcx.17 for <json@ietf.org>; Wed, 04 Dec 2013 19:33:34 -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:content-type; bh=4oUiJnP9bsc/nqHqELJZucV1cVg05bmHToMCocwW6Zo=; b=Lff9WOm1NWYGGpDGoagqdZC4tb+PEXHsHmZiq9P1k1jm9OqUnQ+q2JHqe1+QwKQXiA Sa24YjOX62LCud4DpE/qlesZKzB66SSA+/xZP+ec12PUbB8ORWarwOY9IIlDWwz3H4/v pE9EwJ0O3DlAxEJ6zi8wzZq5MUbNttFG70ecxAbF2mOJJEHTEnTYJRXN3ZBW/BeyUdo/ b2PVm6hrQxaj2SvtqguaAokTql650U2ac6e2Gl5mYmQ1TAacdGLazl7iPR+lJVp/5inX C+M8Fxam6h5f0eqYYVuERnE3CmqmPvONuulGNusRZRl/ExxQHLCIcXsrkTcflC9sN7Qa RB+A==
MIME-Version: 1.0
X-Received: by 10.224.51.196 with SMTP id e4mr124160266qag.16.1386214414214; Wed, 04 Dec 2013 19:33:34 -0800 (PST)
Received: by 10.140.101.40 with HTTP; Wed, 4 Dec 2013 19:33:34 -0800 (PST)
In-Reply-To: <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com>
Date: Wed, 4 Dec 2013 19:33:34 -0800
Message-ID: <CAChr6Sx0TzG6U4XNju91MZjFUnXmBWk5x6iic0c=HnFnCzoMZg@mail.gmail.com>
From: R S <sayrer@gmail.com>
To: Tim Bray <tbray@textuality.com>
Content-Type: multipart/alternative; boundary=001a11c29e50be111f04ecc1318c
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Fwd: New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 03:33:39 -0000

--001a11c29e50be111f04ecc1318c
Content-Type: text/plain; charset=ISO-8859-1

Some of the text in this version looks contradictory:

"This revision does not change any of the rules of the specification"

vs.

"Note that certain previous specifications of JSON constrained a JSON text
to be an object or an array."

Wouldn't one of those be RFC4627? It's right there in the diff.

- Rob




On Wed, Dec 4, 2013 at 6:10 PM, Tim Bray <tbray@textuality.com> wrote:

>
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Wed, Dec 4, 2013 at 6:09 PM
> Subject: New Version Notification - draft-ietf-json-rfc4627bis-08.txt
> To: json-chairs@tools.ietf.org, draft-ietf-json-rfc4627bis@tools.ietf.org,
> presnick@qti.qualcomm.com
>
>
>
> A new version (-08) has been submitted for draft-ietf-json-rfc4627bis:
> http://www.ietf.org/internet-drafts/draft-ietf-json-rfc4627bis-08.txt
>
>
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis/
>
> Diff from previous version:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-json-rfc4627bis-08
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> IETF Secretariat.
>
>
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>
>

--001a11c29e50be111f04ecc1318c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Some of the text in this version looks contradictory:<div>=
<br></div><div>&quot;<span style=3D"color:rgb(0,0,0);font-family:verdana,he=
lvetica,arial,sans-serif;font-size:13px">This revision does not change any =
of the rules of the specification&quot;</span></div>
<div><span style=3D"color:rgb(0,0,0);font-family:verdana,helvetica,arial,sa=
ns-serif;font-size:13px"><br></span></div><div><font color=3D"#000000" face=
=3D"verdana, helvetica, arial, sans-serif">vs.</font></div><div><span style=
=3D"color:rgb(0,0,0);font-family:verdana,helvetica,arial,sans-serif;font-si=
ze:13px"><br>
</span></div><div>&quot;Note that certain previous specifications of JSON c=
onstrained a JSON text to be an object or an array.&quot;<br></div><div><br=
></div><div>Wouldn&#39;t one of those be RFC4627? It&#39;s right there in t=
he diff.</div>
<div><br></div><div>- Rob</div><div><br></div><div><br></div></div><div cla=
ss=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Dec 4, 2013 a=
t 6:10 PM, Tim Bray <span dir=3D"ltr">&lt;<a href=3D"mailto:tbray@textualit=
y.com" target=3D"_blank">tbray@textuality.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br><div class=3D"gmail=
_quote">---------- Forwarded message ----------<br>From: <b class=3D"gmail_=
sendername"></b> <span dir=3D"ltr">&lt;<a href=3D"mailto:internet-drafts@ie=
tf.org" target=3D"_blank">internet-drafts@ietf.org</a>&gt;</span><br>

Date: Wed, Dec 4, 2013 at 6:09 PM<br>Subject: New Version Notification - dr=
aft-ietf-json-rfc4627bis-08.txt<br>To: <a href=3D"mailto:json-chairs@tools.=
ietf.org" target=3D"_blank">json-chairs@tools.ietf.org</a>, <a href=3D"mail=
to:draft-ietf-json-rfc4627bis@tools.ietf.org" target=3D"_blank">draft-ietf-=
json-rfc4627bis@tools.ietf.org</a>, <a href=3D"mailto:presnick@qti.qualcomm=
.com" target=3D"_blank">presnick@qti.qualcomm.com</a><br>

<br><br><br>
A new version (-08) has been submitted for draft-ietf-json-rfc4627bis:<br>
<a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-json-rfc4627bis-0=
8.txt" target=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-jso=
n-rfc4627bis-08.txt</a><br>
<br>
<br>
The IETF datatracker page for this Internet-Draft is:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis/" ta=
rget=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis=
/</a><br>
<br>
Diff from previous version:<br>
<a href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-08=
" target=3D"_blank">http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4=
627bis-08</a><br>
<br>
Please note that it may take a couple of minutes from the time of submissio=
n<br>
until the htmlized version and diff are available at <a href=3D"http://tool=
s.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br>
<br>
IETF Secretariat.<br>
<br>
</div><br></div>
<br>_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
<br></blockquote></div><br></div>

--001a11c29e50be111f04ecc1318c--

From nico@cryptonector.com  Wed Dec  4 20:43:02 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17451AE348 for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 20:43:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 r7WCt2qONaIS for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 20:43:01 -0800 (PST)
Received: from homiemail-a89.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 514DF1ADF0E for <json@ietf.org>; Wed,  4 Dec 2013 20:43:01 -0800 (PST)
Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 333CF31805C; Wed,  4 Dec 2013 20:42:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=E1Zu8dYRnYDCxB ywS2TDir7Uq6U=; b=be8uA8q9934ISElw7wCRzzonX89LSTqB6yMs0/VZZAsHZN T1cCgkO+H2vzi9k0bARHU14q5FM2bbeMr30okx1IdRRGE/VIKU5fIyQ532Ou+72L 2an6LEWHt/yF5FNbj6QEmpW9rZOHCpezTbgLGK3F2WEK5GXnox3s/n6rkbUzE=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPA id DDD44318059; Wed,  4 Dec 2013 20:42:57 -0800 (PST)
Date: Wed, 4 Dec 2013 22:42:56 -0600
From: Nico Williams <nico@cryptonector.com>
To: "Matt Miller (mamille2)" <mamille2@cisco.com>
Message-ID: <20131205044253.GH21240@localhost>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 04:43:02 -0000

On Thu, Dec 05, 2013 at 02:57:05AM +0000, Matt Miller (mamille2) wrote:
> [...]

Comments:

 - s/rfc4727/rfc4627/g  (the link to the attachment says 4727)

 - I don't think we ought to demand anything more than stability for
   normatively referencing ECMA-404.  In particular it seems odd to
   demand that the other SDO (ECMA) establish open processes before
   we'll consider referencing their documents -- a demand of that sort
   ought to be backed up by a statement (as a published RFC) from the
   IESG and/or IAB, not from a WG.

   I know, you said "[the IETF] _almost_ exclusively...".

   Are you asking the WG to demand that the ECMA commit to open
   processes in regards to TC39's future updates of ECMA-404?  Is that a
   consensus call?

 - While I think your note says everything that it must (and only a tad
   too much; see above), it reads a bit too plaintive to me.

   We had representation from TC39 members, and we had ECMA-404.  We had
   enormous threads on RFC4627bis.  We knew about the landmines we
   should not step on, and in the end we didn't step on them.  Things
   worked out, even if things could have worked better.

   I'm also not sure that concerns from ECMA TC39 would not have been
   dismissed as easily as similar concerns from individuals were (at
   least for a while).  We probably needed to have those long threads to
   come to our current consensus.

More in-line.

> -----BEGIN RESPONSE-----
> Thank you for your statement of concern about
> draft-ietf-json-rfc4627bis. The chairs of the IETF's JSON Working
> Group were not aware of any serious concerns that TC39 had with the
> update process. Over the past many months, we repeatedly contacted
> ECMA and TC39 members about the JSON WG and
> draft-ietf-json-rfc4627bis, but never received any significant reply.

Is there documentation of "official" attempts to contact ECMA TC39.
(I'm not sure what that would look like.)

> We know that some TC39 members joined the JSON WG mailing list but did
> not voice any process concerns in the WG -- or privately to the WG
> Chairs -- before or during either of the Last Calls on the document.

I've certainly seen complaints about direction or specific consensus
calls.  Were any by TC39 members?  I'd not know.  Were they about
process?  Perhaps if asked for clarification those voicing concerns
might specify the process as a source of concern.

> In the future, it would probably be useful for Ecma and the IETF to
> have a formal liaison relationship. We have heard that there were
> preliminary discussions several months ago, but stopped short of a
> formal relationship before the JSON Working Group was formed.
> Formalizing the liaison relationship will help both SDOs communicate
> with each other and thus avoid late surprises.

I think I'd phrase this more like:

   Given the late stage of RFC4627bis in the RFC publication process we
   came rather close to publishing an RFC of interest to the ECMA
   without formal input from the ECMA.  The ECMA's concerns were
   -accidentally- voiced in time.  The IETF has a formal liason
   relationship process for interaction with other SDOs.  Establishing
   an IETF-ECMA liason will likely make future interactions smoother.

Nico
-- 

From tbray@textuality.com  Wed Dec  4 21:02:27 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD221ADFA7 for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 21:02:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 ir7bbCFW9xqe for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 21:02:23 -0800 (PST)
Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id 23F7A1AE02F for <json@ietf.org>; Wed,  4 Dec 2013 21:02:22 -0800 (PST)
Received: by mail-ve0-f171.google.com with SMTP id pa12so13007611veb.2 for <json@ietf.org>; Wed, 04 Dec 2013 21:02:18 -0800 (PST)
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:content-type; bh=97TU517JhYlhLJuN9Jwmd9nql0jfaSDwV06REGL4zeM=; b=isGxgv50V8Q47FwR15+KcaZs1ley+KDPAJR9MY6m1NTNS7zDOJQedfXQ8ey9qBhrMp JOE50e53DBphVr+SAbfqIoqWZsYkR2UR2oEM5mHznopMVIIA3sw4wLUt14CO4Qz3XXVH WcKZ4D7YIk2qH5ZnBi9STVXZ34GKaFnnCP1SBf9dYy0HTbqIRcIrOwcpczacSiGxFb1e 4ZoMv9V/OzA9E6QxaM72GxWnlWrpefIwCrmNDZDDqdVQGEfckfrpozdrFCoY/sxP1lhP TcY1zodgouHNSs18qR8Ql6eq89t5jk8Dz4DTFWP7jdS7QIPh05Yd3855xUYEwo6qujKx hrPQ==
X-Gm-Message-State: ALoCoQmpgaAgNoWcN6GHeCh6TopnXpq1a+Ku6ZIZ4MdGbUerM0wgiaJS/qm+2REDJXtFrJbBKhpU
MIME-Version: 1.0
X-Received: by 10.220.199.5 with SMTP id eq5mr61922238vcb.16.1386219738467; Wed, 04 Dec 2013 21:02:18 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Wed, 4 Dec 2013 21:02:18 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com>
Date: Wed, 4 Dec 2013 21:02:18 -0800
Message-ID: <CAHBU6iva2H-ovjmfA7=7j2KxUuXAMjhCb8fcMgKxq6hk+A9BtQ@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: "Matt Miller (mamille2)" <mamille2@cisco.com>
Content-Type: multipart/alternative; boundary=047d7b5db26a181b6c04ecc26f61
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 05:02:27 -0000

--047d7b5db26a181b6c04ecc26f61
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I=E2=80=99m OK with most of this it goes a bit off the rails in the last pa=
ragraph.
 I think the ECMA process is better described as =E2=80=9Copaque=E2=80=9D t=
han =E2=80=9Cclosed=E2=80=9D,
and the last paragraph gets into speculative territory.  While the
not-necessarily-immutable nature of 404 is a good reason to avoid a
normative reference, we don=E2=80=99t need to speculate on what we might do=
 in a
future alternative universe.

I think that the most important reason to skip a normative reference to 404
is that a normative reference implies that you have to read that to
understand this, which clearly simply is not true.

There are also obvious content concerns with 404, in particular its sloppy
editing and its assertion that strings are composed of Unicode code points
which, while probably an improvement, takes us outside our charter which as
I understand it doesn=E2=80=99t allow us to say that documents which former=
ly were
JSON aren=E2=80=99t any more.


On Wed, Dec 4, 2013 at 6:57 PM, Matt Miller (mamille2)
<mamille2@cisco.com>wrote:

> Hello All,
>
> The JSON Working Group has received a statement from Ecma International's
> Technical Committee 39 (TC39) regarding draft-ietf-json-rfc4627bis.  The
> statement can be found at <
> https://datatracker.ietf.org/documents/LIAISON/liaison-2013-11-25-ecma-tc=
39-json-ecma-tc39-comment-for-rfc-4727bis-attachment-1.pdf>.
>
> In response, the Chairs and sponsoring Area Director propose to send the
> following on behalf of the JSON Working Group.  We wish to send the
> response on December 10.  If there are any serious factual errors in the
> following response, let us know before then.  Note that we are *not* aski=
ng
> the WG to re-open any of the consensus discussions, simply to see if we
> misstated anything factual.
>
>
> Thank you,
>
> -- Paul Hoffman and Matt Miller
>
> -----BEGIN RESPONSE-----
> Thank you for your statement of concern about draft-ietf-json-rfc4627bis.
> The chairs of the IETF's JSON Working Group were not aware of any serious
> concerns that TC39 had with the update process. Over the past many months=
,
> we repeatedly contacted ECMA and TC39 members about the JSON WG and
> draft-ietf-json-rfc4627bis, but never received any significant reply. We
> know that some TC39 members joined the JSON WG mailing list but did not
> voice any process concerns in the WG -- or privately to the WG Chairs --
> before or during either of the Last Calls on the document.
>
> In the future, it would probably be useful for Ecma and the IETF to have =
a
> formal liaison relationship. We have heard that there were preliminary
> discussions several months ago, but stopped short of a formal relationshi=
p
> before the JSON Working Group was formed. Formalizing the liaison
> relationship will help both SDOs communicate with each other and thus avo=
id
> late surprises.
>
> As to your specific requests:
>
> - In IETF Last Call, there was consensus to change the definition of "JSO=
N
> text" in draft-ietf-json-rfc4627bis to match the one in ECMA-404. The
> latest draft reflects that change. At this point, we believe that there a=
re
> no syntactic differences between the two specifications.
>
> - The JSON WG decided to change the title of the document to better
> reflect its content. The current document is much more than a media type
> registration: it repeats the JSON syntax originally documented in RFC 462=
7,
> and has been stable for many years, it is a discussion of the JSON
> semantics important to freestanding encoders and parsers, it is a
> discussion of interoperability issues that have been encountered since RF=
C
> 4627 and ECMA-262 5th Edition were published, and it is a media type
> registration. Having a more accurate title on the document will help
> readers understand its contents and the difference between it and ECMA-40=
4.
>
> - After Ecma published ECMA-404, the JSON WG discussed whether to remove
> the ABNF version of the JSON syntax that was established in RFC 4627 from
> draft-ietf-json-rfc4627bis; it was decided not to do so. One reason is th=
at
> ECMA-404 uses "racetrack pictures" to define the syntax, whereas IETF
> documents have traditionally used ABNF, and many developers have expresse=
d
> a strong preference for the ABNF. This might be considered simply a matte=
r
> of style, but it was deemed important by many WG members. We intend to ke=
ep
> the discussion and reference to ECMA-404 in draft-ietf-json-rfc4627bis,
> even if Ecma continues to choose not to reciprocate in ECMA-262 6th
> Edition, because developers reading draft-ietf-json-rfc4627bis might inde=
ed
> prefer the racetrack pictures.
>
> - A normative reference to ECMA-404 would be premature without a clear an=
d
> well-understood document management process. Historically, when someone
> reading an RFC sees a normative reference to one version of another SDO's
> standards, they tend to think the reference will apply to future versions
> of that external standard as well. Given the closed process that resulted
> in ECMA-404, it seems quite possible that Ecma could later make changes t=
o
> ECMA-404 that would have a negative effect on interoperability from the
> Internet perspective. When the IETF normatively refers to other standards=
,
> it almost exclusively does so to standards that were developed with
> processes that are open to discussion and contribution by anyone.
>
> If the IETF believed that future development of ECMA-404 would involve a
> similar kind of open participation as seen with the development of
> draft-ietf-json-rfc4627bis, it could certainly revisit the topic of a
> normative reference in any subsequent update. Such a belief could be one =
of
> the positive products of a formal liaison relationship between the IETF a=
nd
> Ecma.
> -----END RESPONSE-----
>
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>
>

--047d7b5db26a181b6c04ecc26f61
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I=E2=80=99m OK with most of this it goes a bit off the rai=
ls in the last paragraph. =C2=A0I think the ECMA process is better describe=
d as =E2=80=9Copaque=E2=80=9D than =E2=80=9Cclosed=E2=80=9D, and the last p=
aragraph gets into speculative territory. =C2=A0While the not-necessarily-i=
mmutable nature of 404 is a good reason to avoid a normative reference, we =
don=E2=80=99t need to speculate on what we might do in a future alternative=
 universe. =C2=A0=C2=A0<div>
<br></div><div>I think that the most important reason to skip a normative r=
eference to 404 is that a normative reference implies that you have to read=
 that to understand this, which clearly simply is not true.</div><div><br>
</div><div>There are also obvious content concerns with 404, in particular =
its sloppy editing and its assertion that strings are composed of Unicode c=
ode points which, while probably an improvement, takes us outside our chart=
er which as I understand it doesn=E2=80=99t allow us to say that documents =
which formerly were JSON aren=E2=80=99t any more.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed,=
 Dec 4, 2013 at 6:57 PM, Matt Miller (mamille2) <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:mamille2@cisco.com" target=3D"_blank">mamille2@cisco.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hello All,<br>
<br>
The JSON Working Group has received a statement from Ecma International&#39=
;s Technical Committee 39 (TC39) regarding draft-ietf-json-rfc4627bis. =C2=
=A0The statement can be found at &lt; <a href=3D"https://datatracker.ietf.o=
rg/documents/LIAISON/liaison-2013-11-25-ecma-tc39-json-ecma-tc39-comment-fo=
r-rfc-4727bis-attachment-1.pdf" target=3D"_blank">https://datatracker.ietf.=
org/documents/LIAISON/liaison-2013-11-25-ecma-tc39-json-ecma-tc39-comment-f=
or-rfc-4727bis-attachment-1.pdf</a> &gt;.<br>

<br>
In response, the Chairs and sponsoring Area Director propose to send the fo=
llowing on behalf of the JSON Working Group. =C2=A0We wish to send the resp=
onse on December 10. =C2=A0If there are any serious factual errors in the f=
ollowing response, let us know before then. =C2=A0Note that we are *not* as=
king the WG to re-open any of the consensus discussions, simply to see if w=
e misstated anything factual.<br>

<br>
<br>
Thank you,<br>
<br>
-- Paul Hoffman and Matt Miller<br>
<br>
-----BEGIN RESPONSE-----<br>
Thank you for your statement of concern about draft-ietf-json-rfc4627bis. T=
he chairs of the IETF&#39;s JSON Working Group were not aware of any seriou=
s concerns that TC39 had with the update process. Over the past many months=
, we repeatedly contacted ECMA and TC39 members about the JSON WG and draft=
-ietf-json-rfc4627bis, but never received any significant reply. We know th=
at some TC39 members joined the JSON WG mailing list but did not voice any =
process concerns in the WG -- or privately to the WG Chairs -- before or du=
ring either of the Last Calls on the document.<br>

<br>
In the future, it would probably be useful for Ecma and the IETF to have a =
formal liaison relationship. We have heard that there were preliminary disc=
ussions several months ago, but stopped short of a formal relationship befo=
re the JSON Working Group was formed. Formalizing the liaison relationship =
will help both SDOs communicate with each other and thus avoid late surpris=
es.<br>

<br>
As to your specific requests:<br>
<br>
- In IETF Last Call, there was consensus to change the definition of &quot;=
JSON text&quot; in draft-ietf-json-rfc4627bis to match the one in ECMA-404.=
 The latest draft reflects that change. At this point, we believe that ther=
e are no syntactic differences between the two specifications.<br>

<br>
- The JSON WG decided to change the title of the document to better reflect=
 its content. The current document is much more than a media type registrat=
ion: it repeats the JSON syntax originally documented in RFC 4627, and has =
been stable for many years, it is a discussion of the JSON semantics import=
ant to freestanding encoders and parsers, it is a discussion of interoperab=
ility issues that have been encountered since RFC 4627 and ECMA-262 5th Edi=
tion were published, and it is a media type registration. Having a more acc=
urate title on the document will help readers understand its contents and t=
he difference between it and ECMA-404.<br>

<br>
- After Ecma published ECMA-404, the JSON WG discussed whether to remove th=
e ABNF version of the JSON syntax that was established in RFC 4627 from dra=
ft-ietf-json-rfc4627bis; it was decided not to do so. One reason is that EC=
MA-404 uses &quot;racetrack pictures&quot; to define the syntax, whereas IE=
TF documents have traditionally used ABNF, and many developers have express=
ed a strong preference for the ABNF. This might be considered simply a matt=
er of style, but it was deemed important by many WG members. We intend to k=
eep the discussion and reference to ECMA-404 in draft-ietf-json-rfc4627bis,=
 even if Ecma continues to choose not to reciprocate in ECMA-262 6th Editio=
n, because developers reading draft-ietf-json-rfc4627bis might indeed prefe=
r the racetrack pictures.<br>

<br>
- A normative reference to ECMA-404 would be premature without a clear and =
well-understood document management process. Historically, when someone rea=
ding an RFC sees a normative reference to one version of another SDO&#39;s =
standards, they tend to think the reference will apply to future versions o=
f that external standard as well. Given the closed process that resulted in=
 ECMA-404, it seems quite possible that Ecma could later make changes to EC=
MA-404 that would have a negative effect on interoperability from the Inter=
net perspective. When the IETF normatively refers to other standards, it al=
most exclusively does so to standards that were developed with processes th=
at are open to discussion and contribution by anyone.<br>

<br>
If the IETF believed that future development of ECMA-404 would involve a si=
milar kind of open participation as seen with the development of draft-ietf=
-json-rfc4627bis, it could certainly revisit the topic of a normative refer=
ence in any subsequent update. Such a belief could be one of the positive p=
roducts of a formal liaison relationship between the IETF and Ecma.<br>

-----END RESPONSE-----<br>
<br>
<br>_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
<br></blockquote></div><br></div>

--047d7b5db26a181b6c04ecc26f61--

From tbray@textuality.com  Wed Dec  4 21:08:24 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C351AE02F for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 21:08:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 GIMfVvxFrrnG for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 21:08:22 -0800 (PST)
Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id DA4951AE1BB for <json@ietf.org>; Wed,  4 Dec 2013 21:08:21 -0800 (PST)
Received: by mail-vc0-f179.google.com with SMTP id ie18so12390975vcb.38 for <json@ietf.org>; Wed, 04 Dec 2013 21:08:18 -0800 (PST)
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:content-type; bh=aFvzWXm5dhqutrEzToPhh9rYXMYhNjDXhgGHLP+b05g=; b=M25MG7a1Ldr7YVt6Eaaq4vN7S3YPMaFT2FqhjZ9/e+NV/AE/+byKrMH0bRVUB3kkPj DzX7gcTRWedOiCGNiYVfB+TpeIQ4boVGWOlHC7r8WmC/4D+AR+A8xz6wAcHV11ffOe1L X1dVg9HbIzg8KKzRnWPqRFtkSbmjEi3l0ZgKgQO5P7f3IzTKeDfcLMd4xjw44pYLS+cU 11TL+QGTgREogbVeW1tBdEEtZakOHIa7uOa7PHuKZ0nFmroBkD5clqDmlvlG18mQZn3B QiF4LP1y4+skcY2VXm8914xNu5Qz/hU+aLdmalEkAlcXAX1jbb3VNEUrnMKDC6a7BGj3 LQZg==
X-Gm-Message-State: ALoCoQmX/7CV0hVbcSQuBi3fNNJgqkAk1aCUHFRsEHBHG0t2Ncuvbalc8xO2AHoSR/o4IaHUrSXt
MIME-Version: 1.0
X-Received: by 10.220.74.69 with SMTP id t5mr46778424vcj.18.1386220098418; Wed, 04 Dec 2013 21:08:18 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Wed, 4 Dec 2013 21:08:18 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com>
Date: Wed, 4 Dec 2013 21:08:18 -0800
Message-ID: <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: "Matt Miller (mamille2)" <mamille2@cisco.com>
Content-Type: multipart/alternative; boundary=047d7b624cbe8c6a4d04ecc2840b
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 05:08:24 -0000

--047d7b624cbe8c6a4d04ecc2840b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 4, 2013 at 6:57 PM, Matt Miller (mamille2)
<mamille2@cisco.com>wrote:


> On the topic of JSON semantics, Ecma TC39 has said repeatedly that
> ECMA-404 is meant to only document the JSON syntax, with no description o=
f
> the semantics of encoding or parsing. On the other hand,
> draft-ietf-json-rfc4627bis and RFC 4627 before it express both syntax and
> semantics. For a format such as JSON, interoperability in encoders and
> parsers can only be achieved with descriptions of both syntax and semanti=
cs.
>

FWIW, I have never understood what the ECMAnauts mean by the word
=E2=80=9Csemantics=E2=80=9D in this context, so I have no idea whether I ag=
ree with this
statement.


>  A great deal of effort in the JSON WG process around
> draft-ietf-json-rfc4627bis has been to carefully describe differences
> between the new spec and ECMAScript.
>

Really? I don=E2=80=99t think I agree.  The only difference was the top-lev=
el
restriction, which took a small uncontroversial paragraph to describe.


>
>

--047d7b624cbe8c6a4d04ecc2840b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Dec 4, 2013 at 6:57 PM, Matt Miller (mamille2) <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:mamille2@cisco.com" target=3D"_blank">mamille2@cisco.com</a=
>&gt;</span> wrote:<br>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
On the topic of JSON semantics, Ecma TC39 has said repeatedly that ECMA-404=
 is meant to only document the JSON syntax, with no description of the sema=
ntics of encoding or parsing. On the other hand, draft-ietf-json-rfc4627bis=
 and RFC 4627 before it express both syntax and semantics. For a format suc=
h as JSON, interoperability in encoders and parsers can only be achieved wi=
th descriptions of both syntax and semantics.<br>
</blockquote><div><br></div><div>FWIW, I have never understood what the ECM=
Anauts mean by the word =E2=80=9Csemantics=E2=80=9D in this context, so I h=
ave no idea whether I agree with this statement. =C2=A0</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
=C2=A0A great deal of effort in the JSON WG process around draft-ietf-json-=
rfc4627bis has been to carefully describe differences between the new spec =
and ECMAScript.<br></blockquote><div><br></div><div>Really? I don=E2=80=99t=
 think I agree. =C2=A0The only difference was the top-level restriction, wh=
ich took a small uncontroversial paragraph to describe.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote></div></di=
v></div>

--047d7b624cbe8c6a4d04ecc2840b--

From nico@cryptonector.com  Wed Dec  4 21:15:26 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8B91AE344 for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 21:15:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 sZioylXgQT4e for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 21:15:25 -0800 (PST)
Received: from homiemail-a71.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 59A0B1AE261 for <json@ietf.org>; Wed,  4 Dec 2013 21:15:25 -0800 (PST)
Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 3566C428079 for <json@ietf.org>; Wed,  4 Dec 2013 21:15:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=W5Zg7jerCAh2wle4gzhz bsbpYi4=; b=Nev/1TKJCxWaX7LbjI+GcIgGB0axTN6zOZ/fHLXEq1rEW6AxClGC TRLcMgwAzMHcXm6HSnV6KWv8jcrd5hut2LQH/u/1PMNJL9QkSet1tXzyAXxuKwTV pwHyKQmbjDn4w88X5mZSJuWyv/wTNhMGBDkRVVkE9o6oY6VKXFuez90=
Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id C6F91428078 for <json@ietf.org>; Wed,  4 Dec 2013 21:15:21 -0800 (PST)
Received: by mail-wg0-f50.google.com with SMTP id a1so14276451wgh.29 for <json@ietf.org>; Wed, 04 Dec 2013 21:15:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6c5a5y/ANjBNm3pSOla0xUo5VSFle+2jc2rfyQEtAjk=; b=mhUGiY5ZlJSZq274YAOsisvpcLBTiMIUVaHfF7+t8JJFpz/JBZa2LyZIQJk5BN6Q5G bnV0z6f2ENgNGg54ywBnoEBErYDzZgPaUz71aaWR+xwEN1IkISVXapHqSqUUinZfhXuO gO+fJzvisM7yqK7AKx1uHT7fQuWdfvGtbw6o5ySWjo1tbQU0BmS+uKM2/oM96SK+0fXp K0BDig5QneFIYnRDs4GE4yoz6/KJvdYLsfRXPKhQVUZYm+LnG3Rty3oEVmJE1NHtWq+O 2I5CFjXFRXt7kAppxGL8wZFYOSAYQu5x2d4SfPO5w+UvYeJFkS/3YjsNMyMxdPJc/61s yk5A==
MIME-Version: 1.0
X-Received: by 10.194.240.41 with SMTP id vx9mr10464430wjc.70.1386220519735; Wed, 04 Dec 2013 21:15:19 -0800 (PST)
Received: by 10.217.10.6 with HTTP; Wed, 4 Dec 2013 21:15:19 -0800 (PST)
Received: by 10.217.10.6 with HTTP; Wed, 4 Dec 2013 21:15:19 -0800 (PST)
In-Reply-To: <20131205044253.GH21240@localhost>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <20131205044253.GH21240@localhost>
Date: Wed, 4 Dec 2013 23:15:19 -0600
Message-ID: <CAK3OfOiXdOpe+=DzxgD7HeyN0UTtMCiu+b3Cep4d1ftQPjrxww@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "Matt Miller, (mamille2)" <mamille2@cisco.com>
Content-Type: multipart/alternative; boundary=001a11c28dcca8c9b804ecc29d74
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 05:15:26 -0000

--001a11c28dcca8c9b804ecc29d74
Content-Type: text/plain; charset=UTF-8

Though I should add that i agree with the sentiment regarding open
processes.

Nico
--

--001a11c28dcca8c9b804ecc29d74
Content-Type: text/html; charset=UTF-8

<p dir="ltr">Though I should add that i agree with the sentiment regarding open processes.</p>
<p dir="ltr">Nico<br>
-- </p>

--001a11c28dcca8c9b804ecc29d74--

From duerst@it.aoyama.ac.jp  Wed Dec  4 22:23:32 2013
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3681AE36A for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 22:23:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level: 
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=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 XMJpp2hny_er for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 22:23:31 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id D1AF71AE1FF for <json@ietf.org>; Wed,  4 Dec 2013 22:23:29 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rB56N6BX007294; Thu, 5 Dec 2013 15:23:06 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 75b5_9648_b3f3eea2_5d75_11e3_b57b_001e6722eec2; Thu, 05 Dec 2013 15:23:05 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id A6062BF536; Thu,  5 Dec 2013 15:23:05 +0900 (JST)
Message-ID: <52A01BBA.2040809@it.aoyama.ac.jp>
Date: Thu, 05 Dec 2013 15:22:50 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <20131205044253.GH21240@localhost> <CAK3OfOiXdOpe+=DzxgD7HeyN0UTtMCiu+b3Cep4d1ftQPjrxww@mail.gmail.com>
In-Reply-To: <CAK3OfOiXdOpe+=DzxgD7HeyN0UTtMCiu+b3Cep4d1ftQPjrxww@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, Yehuda Katz <wycats@gmail.com>, JSON WG <json@ietf.org>, Alex Russell <slightlyoff@google.com>, "Matt Miller, \(mamille2\)" <mamille2@cisco.com>, Henri Sivonen <hsivonen@iki.fi>, Anne van Kesteren <annevk@annevk.nl>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 06:23:32 -0000

[Cc'ed to some people I know or suspect are involved in TC39, to 
hopefully get some clarifications.]

On 2013/12/05 14:15, Nico Williams wrote:
> Though I should add that i agree with the sentiment regarding open
> processes.

I had the same sentiment. But I think part of it comes from the fact 
that I just don't know what kind of process ECMA TC39 is using.

And the other part comes from the fact that I repeatedly got messages 
from es-discuss-owner@mozilla.org saying:

 >>>>
Messages from non-subscribers are automatically rejected. Please
subscribe to the list first before attempting to post, or ensure that
you are posting using the address you subscribed with.
 >>>>

Maybe I should just have tried to subscribe. Maybe I should have asked 
somebody. But frankly, it was the first time I can remember that in a 
standard-related mailing list, a mail was just automatically rejected.

I have managed mailing lists at both the W3C and the IETF, and in both 
cases, mails from addresses that don't match a whitelist (which is much 
wider than just the subscribers of the particular list) get sent through 
moderation. Maybe there are some specific reasons why this is different 
at ECMA, but it definitely doesn't help with inter-WG collaboration.

Regards,   Martin.

From cabo@tzi.org  Wed Dec  4 22:33:00 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4510C1AE384 for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 22:33:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.251
X-Spam-Level: 
X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001] autolearn=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 dvsmmwKQFQGK for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 22:32:56 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id ED7C81AE381 for <json@ietf.org>; Wed,  4 Dec 2013 22:32:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB56WSjZ010329; Thu, 5 Dec 2013 07:32:28 +0100 (CET)
Received: from [192.168.217.105] (p548901B4.dip0.t-ipconnect.de [84.137.1.180]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8C7407BD; Thu,  5 Dec 2013 07:32:25 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <52A01BBA.2040809@it.aoyama.ac.jp>
Date: Thu, 5 Dec 2013 07:32:20 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <242F63FA-EB68-42C0-A42E-C25E7C8576D5@tzi.org>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <20131205044253.GH21240@localhost> <CAK3OfOiXdOpe+=DzxgD7HeyN0UTtMCiu+b3Cep4d1ftQPjrxww@mail.gmail.com> <52A01BBA.2040809@it.aoyama.ac.jp>
To: =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>
X-Mailer: Apple Mail (2.1822)
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, Yehuda Katz <wycats@gmail.com>, Henri Sivonen <hsivonen@iki.fi>, JSON WG <json@ietf.org>, Alex Russell <slightlyoff@google.com>, "Matt Miller, \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, Anne van Kesteren <annevk@annevk.nl>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 06:33:00 -0000

On 05 Dec 2013, at 07:22, Martin J. D=FCrst <duerst@it.aoyama.ac.jp> =
wrote:

> repeatedly got messages from es-discuss-owner@mozilla.org

Yep.  And some messages from =93over there=94 read like they came out of =
a bubble.
Running a discussion on several mailing lists at the same time is never =
a great idea, but it gets much, much worse when a subgroup of the =
participants never gets to hear input from outside their own subgroup.

Gr=FC=DFe, Carsten


From cabo@tzi.org  Wed Dec  4 22:44:12 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A064E1AE393 for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 22:44:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 Upq8bj012B2d for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 22:44:11 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 58D2C1AE390 for <json@ietf.org>; Wed,  4 Dec 2013 22:44:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB56hv6o002874; Thu, 5 Dec 2013 07:43:57 +0100 (CET)
Received: from [192.168.217.105] (p548901B4.dip0.t-ipconnect.de [84.137.1.180]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 457327C6; Thu,  5 Dec 2013 07:43:55 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20131205044253.GH21240@localhost>
Date: Thu, 5 Dec 2013 07:43:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D4601105-6F83-4709-B309-298529E4B17E@tzi.org>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <20131205044253.GH21240@localhost>
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 06:44:12 -0000

On 05 Dec 2013, at 05:42, Nico Williams <nico@cryptonector.com> wrote:

> I don't think we ought to demand anything more than stability for
>   normatively referencing ECMA-404.=20

Whoa. =20
Actually, a major prerequisite is that any spec we rely on by =
referencing it normatively is a good specification.

Saying that the process leading to ECMA-404 wasn=92t open may also be a =
veiled expression of dissatisfaction with the outcome.  (I have said =
openly that ECMA-404 is a great tutorial, just not a very good =
specification; some others have been trying to be more diplomatic about =
this.)

I still haven=92t heard any argument that invalidates the very good ones =
made in http://lists.w3.org/Archives/Public/www-tag/2013Oct/0041.html =
(except for the fact that we are now tracking the gratuitous change that =
allows non-containers on the top-level).

Gr=FC=DFe, Carsten


From nico@cryptonector.com  Wed Dec  4 22:50:33 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA941A1F1A for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 22:50:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 AF2ksZfbvwXm for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 22:50:32 -0800 (PST)
Received: from homiemail-a70.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 3A31B1A1DFA for <json@ietf.org>; Wed,  4 Dec 2013 22:50:32 -0800 (PST)
Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 1263676805C; Wed,  4 Dec 2013 22:50:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=5ic7EA5ZqVH7zM/x2bxvvL+glaM=; b=h3QLECFXTGM PQm9taapH7w+jZ3f8Z3k7jlFsy29wOuJgV+VKmQolYcLTvB1C1U5VT0YhR8o4QtK UFcElh3OOwzANK41eqoB72d3tfHbBNZtAXdM8F1tZfCC8EBf6Rb4cbGRtv8uOAnN q0KKd/zDDo8iW6wkh8W3lT9zMgfCULUc=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPA id 3E08E768059; Wed,  4 Dec 2013 22:50:28 -0800 (PST)
Date: Thu, 5 Dec 2013 00:50:27 -0600
From: Nico Williams <nico@cryptonector.com>
To: =?iso-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= <duerst@it.aoyama.ac.jp>
Message-ID: <20131205065024.GL21240@localhost>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <20131205044253.GH21240@localhost> <CAK3OfOiXdOpe+=DzxgD7HeyN0UTtMCiu+b3Cep4d1ftQPjrxww@mail.gmail.com> <52A01BBA.2040809@it.aoyama.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <52A01BBA.2040809@it.aoyama.ac.jp>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, Yehuda Katz <wycats@gmail.com>, JSON WG <json@ietf.org>, Alex Russell <slightlyoff@google.com>, "Matt Miller, \(mamille2\)" <mamille2@cisco.com>, Henri Sivonen <hsivonen@iki.fi>, Anne van Kesteren <annevk@annevk.nl>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 06:50:34 -0000

On Thu, Dec 05, 2013 at 03:22:50PM +0900, "Martin J. D=FCrst" wrote:
> And the other part comes from the fact that I repeatedly got
> messages from es-discuss-owner@mozilla.org saying:

Some IETF lists also do that.  The IETF allows IETF list owners to set
their own preferences for this.  I personally think that any member [in
good standing] of any IETF list ought to be able to post to any IETF
list without having to subscribe.

Nico
--=20

From nico@cryptonector.com  Wed Dec  4 22:58:11 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2235B1A1F3E for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 22:58:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 ebCp4qLfi19V for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 22:58:09 -0800 (PST)
Received: from homiemail-a109.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8A47D1A1F3D for <json@ietf.org>; Wed,  4 Dec 2013 22:58:09 -0800 (PST)
Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id 81C292005D908; Wed,  4 Dec 2013 22:58:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=4gzmI0wNwCj8yl7SkaYPNS6zE6w=; b=eNUd6HiJUwm nt3hvdASYvNXEh5Ityp45p/ftOA+a7oLJisO194u7XrmtVVLI3zrzey85CVkjT8X 5Fxiw1SAmo0ftv39TV5R56jiXRlcAlHzEVH8Bb4Qqbm+bmumiKb/wi+JMVXW0+IQ ySqeW8VgR5t6g+6UTo/h9XjFZfbwiNzI=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPA id 2A58E2005D907; Wed,  4 Dec 2013 22:58:06 -0800 (PST)
Date: Thu, 5 Dec 2013 00:58:05 -0600
From: Nico Williams <nico@cryptonector.com>
To: Carsten Bormann <cabo@tzi.org>
Message-ID: <20131205065802.GM21240@localhost>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <20131205044253.GH21240@localhost> <D4601105-6F83-4709-B309-298529E4B17E@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <D4601105-6F83-4709-B309-298529E4B17E@tzi.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
Cc: JSON WG <json@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 06:58:11 -0000

On Thu, Dec 05, 2013 at 07:43:52AM +0100, Carsten Bormann wrote:
> On 05 Dec 2013, at 05:42, Nico Williams <nico@cryptonector.com> wrote:
> > I don't think we ought to demand anything more than stability for
> >   normatively referencing ECMA-404.=20
>=20
> Whoa. =20
> Actually, a major prerequisite is that any spec we rely on by
> referencing it normatively is a good specification.

OK, I grant that :)  I was referring to process, however.  We really
want to demand the stability of non-Internet standards normatively
referenced from Internet standards as we do of Internet standards
normatively [...].  IIRC the IETF does occasionally permit some
normative downrefs, but asking for a downref is asking for sturm und
drang.

> Saying that the process leading to ECMA-404 wasn=E2=80=99t open may als=
o be a
> veiled expression of dissatisfaction with the outcome.  [...]

Maybe so, but that's neither here nor there.  If ECMA-404's quality is
insufficient then we won't reference it normatively.  If it is
insufficiently stable then we won't reference it normatively.  That ECMA
is or is not as open as we'd like is irrelevant -- that was my point, in
particular that we ought not make demands about their process (or at
least not without having WG consensus for such a heavy-handed position,
and preferably more than WG consensus).

Nico
--=20

From cabo@tzi.org  Wed Dec  4 23:39:36 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5741E1AC3DD for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 23:39:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 iCA-cKLuurCW for <json@ietfa.amsl.com>; Wed,  4 Dec 2013 23:39:35 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 091CE1A8026 for <json@ietf.org>; Wed,  4 Dec 2013 23:39:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB57dPeJ023213; Thu, 5 Dec 2013 08:39:25 +0100 (CET)
Received: from [192.168.217.105] (p548901B4.dip0.t-ipconnect.de [84.137.1.180]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A013780E; Thu,  5 Dec 2013 08:39:22 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com>
Date: Thu, 5 Dec 2013 08:39:20 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 07:39:36 -0000

On 05 Dec 2013, at 06:08, Tim Bray <tbray@textuality.com> wrote:

> FWIW, I have never understood what the ECMAnauts mean by the word =
=93semantics=94 in this context, so I have no idea whether I agree with =
this statement.

You know this, but just for the record: we could be applying the meaning =
we have for these terms in CS.

The syntax just tells you which sequences of symbols are part of the =
language.
(This is what we have ABNF for; ECMA-404 uses racetracks plus some =
English language that maps the characters to the tokens in the =
syntax-level racetracks for value, object, and array, and to the English =
language components of the token-level racetracks for number and =
string.)

Semantics is needed to describe e.g. that some whitespace is =
=93insignificant=94 (not contributing to the semantics), describe the =
intended interpretation of escape sequences in strings, that the =
sequences of symbols enabled by the production =93number=94 are to be =
interpreted in base 10, or that =93the order of the values is =
significant=94 in arrays (which seems to be intended to contrast them to =
JSON objects, where ECMA-404 weasels out of saying whether the order is =
significant).

ECMA-404 does quite a bit of of the latter, so indeed I also have =
trouble interpreting such a statement.
(That doesn=92t mean that the chairs=92 echo of statements of this kind =
having been made is incorrect.)

Gr=FC=DFe, Carsten


From cabo@tzi.org  Thu Dec  5 00:20:23 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C721ACC8A for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 00:20:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 8uzt1aaOTfZT for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 00:20:22 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8521ACC7D for <json@ietf.org>; Thu,  5 Dec 2013 00:20:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB58KGkZ018059; Thu, 5 Dec 2013 09:20:16 +0100 (CET)
Received: from [192.168.217.105] (p548901B4.dip0.t-ipconnect.de [84.137.1.180]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0FF9285C; Thu,  5 Dec 2013 09:20:15 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com>
Date: Thu, 5 Dec 2013 09:20:10 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3461B710-B969-4315-854B-E2C30B2141FA@tzi.org>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
X-Mailer: Apple Mail (2.1822)
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Fwd: New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 08:20:23 -0000

Major new bug (apart from the one Rob found):

=97 A SHOULD-level requirement for BOM tolerance is a gratuitous change. =
 (I thought we were shooting for a MAY.)

=97 Even if the WG decides that change is warranted, the text on -08 =
will be read as =93JSON now allows BOMs=94 by anyone who is not a =
language lawyer.  The =93SHOULD accept=94 needs to be accompanied by a =
(redundant, but contextually necessary) =93MUST NOT send=94.

Gr=FC=DFe, Carsten


From julian.reschke@gmx.de  Thu Dec  5 01:57:23 2013
Return-Path: <julian.reschke@gmx.de>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D411ADBD0 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 01:57:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 w2_GRoFrfCD2 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 01:57:20 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 67A411AC7F0 for <json@ietf.org>; Thu,  5 Dec 2013 01:57:20 -0800 (PST)
Received: from [172.24.113.138] ([192.147.117.12]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MVNWU-1W5Wx00luo-00YjL1 for <json@ietf.org>; Thu, 05 Dec 2013 10:57:16 +0100
Message-ID: <52A04DFA.6080103@gmx.de>
Date: Thu, 05 Dec 2013 10:57:14 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: ietf@ietf.org
References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> <528234A4.2040004@gmx.de>
In-Reply-To: <528234A4.2040004@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:RXs1VBINBxvoVDxzkUqRZiSfRZmYqSO+dJmZ6A/B2J3KF7z7ajM D+Jj6y+MPiuTwMWvEsAnoqcotpej6RpPeqPtEaohiDYNVkZgvHzsGkSIBGmcq/pftk0f2aK a9Ia11TF7e0Whl5/vVV9cQljD2e77Cfx87A+uFwWhx5YsHmNwnW2QMBQK4XOpD3frUkIFTR 5yrquoOqjOFEwunccvDag==
Cc: json@ietf.org
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data	Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 09:57:23 -0000

Hi there,

I see only some of my LC comments have been addressed in -08; please 
have another look at those I list below.

Hi there,

below are my editorial comments:

Abstract

    JavaScript Object Notation (JSON) is a lightweight, text-based,
    language-independent data interchange format.  It was derived from
    the ECMAScript Programming Language Standard.  JSON defines a small
    set of formatting rules for the portable representation of structured
    data.

    This document makes no changes to the definition of JSON; it repairs
    specification errors and offers experience-based interoperability
    guidance.

I believe historical considerations do not belong into the abstract (but 
into the Introduction)

Status of This Memo

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    This Internet-Draft will expire on May 10, 2014.

Are we sure that we do not need the "pre-5378 escape clause" here? 
(Section 4 of <http://trustee.ietf.org/docs/IETF-Copyright-FAQ.pdf>)

    The grammatical rules in this document are to be interpreted as
    described in [RFC5234].

Maybe note which productions are imported as well (HEXDIG and DIGIT it 
seems).

    This revision does not change any of the rules of the specification;
    all texts which were legal JSON remain so, and none which were not
    JSON become JSON.  The revision's goal is to fix the errata and
    highlight practices which can lead to interoperability problems.

s/fix errata/apply errata/ ?

    Insignificant whitespace is allowed before or after any of the six
    structural characters.

    ws = *(
            %x20 /              ; Space
            %x09 /              ; Horizontal tab
            %x0A /              ; Line feed or New line
            %x0D )              ; Carriage return

We *could* use SP, HTAB, LF, and CR here.

    JSON text SHALL be encoded in Unicode...

That's a bit misleading. How do I "encode in Unicode"? I think what it 
tries to say is that one of the Unicode-compatible character encoding 
schemes needs to be used.

    An implementation may set limits on the size of texts that it
    accepts.  An implementation may set limits on the maximum depth of
    nesting.  An implementation may set limits on the range and precision
    of numbers.  An implementation may set limits on the length and
    character contents of strings.

Maybe this should be a bullet list?

10.  Generators

    A JSON generator produces JSON text.  The resulting text MUST
    strictly conform to the JSON grammar.

"strictly"?

    o  Changed Working Group attribution to JSON Working Group.

...this is a change that will not be visible in the RFC.

Best regards, Julian

From paul.hoffman@vpnc.org  Thu Dec  5 07:22:37 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443631AE066 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 07:22:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 yGAAYziY07b8 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 07:22:36 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC231AE064 for <json@ietf.org>; Thu,  5 Dec 2013 07:22:35 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB5FMREC012465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Dec 2013 08:22:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAChr6Sx0TzG6U4XNju91MZjFUnXmBWk5x6iic0c=HnFnCzoMZg@mail.gmail.com>
Date: Thu, 5 Dec 2013 07:22:28 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <3E8905B5-098E-4928-BF0A-CD4065738D99@vpnc.org>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com> <CAChr6Sx0TzG6U4XNju91MZjFUnXmBWk5x6iic0c=HnFnCzoMZg@mail.gmail.com>
To: R S <sayrer@gmail.com>
X-Mailer: Apple Mail (2.1822)
Cc: Tim Bray <tbray@textuality.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 15:22:37 -0000

<no hat>

On Dec 4, 2013, at 7:33 PM, R S <sayrer@gmail.com> wrote:

> Some of the text in this version looks contradictory:
>=20
> "This revision does not change any of the rules of the specification"
>=20
> vs.
>=20
> "Note that certain previous specifications of JSON constrained a JSON =
text to be an object or an array."
>=20
> Wouldn't one of those be RFC4627? It's right there in the diff.

Good catch, Rob. Given that we had consensus to make a significant =
change, I propose just removing that whole paragraph.

--Paul Hoffman=

From paul.hoffman@vpnc.org  Thu Dec  5 07:27:36 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5204A1ADF30 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 07:27:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 UtULrMnE5Nrg for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 07:27:35 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 717021ADF47 for <json@ietf.org>; Thu,  5 Dec 2013 07:27:35 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB5FRUQu012903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Dec 2013 08:27:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <3461B710-B969-4315-854B-E2C30B2141FA@tzi.org>
Date: Thu, 5 Dec 2013 07:27:30 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <28869F37-1FC4-4F05-A729-DAB14CDA3757@vpnc.org>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com> <3461B710-B969-4315-854B-E2C30B2141FA@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.1822)
Cc: Tim Bray <tbray@textuality.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 15:27:36 -0000

<hat on>

On Dec 5, 2013, at 12:20 AM, Carsten Bormann <cabo@tzi.org> wrote:

> Major new bug (apart from the one Rob found):
>=20
> =97 A SHOULD-level requirement for BOM tolerance is a gratuitous =
change.  (I thought we were shooting for a MAY.)

There was a reasonable number of people who were very concerned that =
JSON documents that were being sent around with a BOM would be rejected.

Given the current text:
   Implementations have been observed to generate JSON texts prefixed
   with a Byte Order Mark character.  While this is not allowed by the
   grammar in this specification, in the interests of interoperability
   it is RECOMMENDED that implementations which parse JSON texts ignore
   the presence of a byte order mark rather than treating it as an
   error.
what change would you make?

> =97 Even if the WG decides that change is warranted, the text on -08 =
will be read as =93JSON now allows BOMs=94 by anyone who is not a =
language lawyer.  The =93SHOULD accept=94 needs to be accompanied by a =
(redundant, but contextually necessary) =93MUST NOT send=94.

If it is redundant (and it is, given the carefully worded intro to that =
sentence), why do you feel it is "contextually necessary"?

--Paul Hoffman=

From paul.hoffman@vpnc.org  Thu Dec  5 07:34:55 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694AD1AE062 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 07:34:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 l3jh8tEkcjJv for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 07:34:53 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CEC3C1AE059 for <json@ietf.org>; Thu,  5 Dec 2013 07:34:53 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB5FYiAb013492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Dec 2013 08:34:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <52A04DFA.6080103@gmx.de>
Date: Thu, 5 Dec 2013 07:34:44 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <F6061C95-4C47-4274-8345-A523A263F755@vpnc.org>
References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> <528234A4.2040004@gmx.de> <52A04DFA.6080103@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1822)
Cc: Tim Bray <tbray@textuality.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data	Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 15:34:55 -0000

<no hat>

On Dec 5, 2013, at 1:57 AM, Julian Reschke <julian.reschke@gmx.de> =
wrote:

> Abstract
>=20
>   JavaScript Object Notation (JSON) is a lightweight, text-based,
>   language-independent data interchange format.  It was derived from
>   the ECMAScript Programming Language Standard.  JSON defines a small
>   set of formatting rules for the portable representation of =
structured
>   data.
>=20
>   This document makes no changes to the definition of JSON; it repairs
>   specification errors and offers experience-based interoperability
>   guidance.
>=20
> I believe historical considerations do not belong into the abstract =
(but into the Introduction)

This seems like bikeshedding, and the text has been where it is for a =
long time.

> Status of This Memo
>=20
>   This Internet-Draft is submitted in full conformance with the
>   provisions of BCP 78 and BCP 79.
>=20
>   Internet-Drafts are working documents of the Internet Engineering
>   Task Force (IETF).  Note that other groups may also distribute
>   working documents as Internet-Drafts.  The list of current Internet-
>   Drafts is at http://datatracker.ietf.org/drafts/current/.
>=20
>   Internet-Drafts are draft documents valid for a maximum of six =
months
>   and may be updated, replaced, or obsoleted by other documents at any
>   time.  It is inappropriate to use Internet-Drafts as reference
>   material or to cite them other than as "work in progress."
>=20
>   This Internet-Draft will expire on May 10, 2014.
>=20
> Are we sure that we do not need the "pre-5378 escape clause" here? =
(Section 4 of <http://trustee.ietf.org/docs/IETF-Copyright-FAQ.pdf>)

Good catch, yes.


>=20
>   The grammatical rules in this document are to be interpreted as
>   described in [RFC5234].
>=20
> Maybe note which productions are imported as well (HEXDIG and DIGIT it =
seems).

Sure.

>=20
>   This revision does not change any of the rules of the specification;
>   all texts which were legal JSON remain so, and none which were not
>   JSON become JSON.  The revision's goal is to fix the errata and
>   highlight practices which can lead to interoperability problems.
>=20
> s/fix errata/apply errata/ ?

Sure.

>=20
>   Insignificant whitespace is allowed before or after any of the six
>   structural characters.
>=20
>   ws =3D *(
>           %x20 /              ; Space
>           %x09 /              ; Horizontal tab
>           %x0A /              ; Line feed or New line
>           %x0D )              ; Carriage return
>=20
> We *could* use SP, HTAB, LF, and CR here.

...but we don't need to.

>=20
>   JSON text SHALL be encoded in Unicode...
>=20
> That's a bit misleading. How do I "encode in Unicode"? I think what it =
tries to say is that one of the Unicode-compatible character encoding =
schemes needs to be used.

This was a swamp where consensus seemed impossible to reach.

>=20
>   An implementation may set limits on the size of texts that it
>   accepts.  An implementation may set limits on the maximum depth of
>   nesting.  An implementation may set limits on the range and =
precision
>   of numbers.  An implementation may set limits on the length and
>   character contents of strings.
>=20
> Maybe this should be a bullet list?

Bikeshed

>=20
> 10.  Generators
>=20
>   A JSON generator produces JSON text.  The resulting text MUST
>   strictly conform to the JSON grammar.
>=20
> "strictly"?

You would prefer "squishily"?

>=20
>   o  Changed Working Group attribution to JSON Working Group.
>=20
> ...this is a change that will not be visible in the RFC.

Good point; that can be removed.

--Paul Hoffman=

From julian.reschke@gmx.de  Thu Dec  5 07:53:40 2013
Return-Path: <julian.reschke@gmx.de>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8C51AE03A for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 07:53:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 mbSwowMErZ0I for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 07:53:38 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6F01AE030 for <json@ietf.org>; Thu,  5 Dec 2013 07:53:38 -0800 (PST)
Received: from [172.24.113.138] ([192.147.117.12]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LomuB-1VMiTG2afj-00gm1J for <json@ietf.org>; Thu, 05 Dec 2013 16:53:34 +0100
Message-ID: <52A0A17B.30005@gmx.de>
Date: Thu, 05 Dec 2013 16:53:31 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> <528234A4.2040004@gmx.de> <52A04DFA.6080103@gmx.de> <F6061C95-4C47-4274-8345-A523A263F755@vpnc.org>
In-Reply-To: <F6061C95-4C47-4274-8345-A523A263F755@vpnc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:XeFHW6vAUdDWABIe3uf1Yu24Mwk6CrldUTM7MeFQw4eqYHNOf2J Fb+BIYm5/Z+wp8cheaJ+uRd60jYEo/pVm4He3++gscFDdbySEEbGiRiXHaDcZZwVkgWMZKL ryuH8I+DxzyzWnehtvkwhHeJ1mximnWx71Z7gU7U/T/5VqZJuqPAHnFwxFrUGBwINMpJxM3 HvjFg/5UFEU8WJyjCBLZw==
Cc: Tim Bray <tbray@textuality.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data	Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 15:53:40 -0000

On 2013-12-05 16:34, Paul Hoffman wrote:
> <no hat>
> ...
>>    JSON text SHALL be encoded in Unicode...
>>
>> That's a bit misleading. How do I "encode in Unicode"? I think what it tries to say is that one of the Unicode-compatible character encoding schemes needs to be used.
>
> This was a swamp where consensus seemed impossible to reach.

Nope. We discussed lots of other things but not this one.

This is about the sentence "JSON text SHALL be encoded in Unicode" which 
IMHO is meaningless. There is no "Unicode encoding" on the wire.

Alternatively, can you explain what it actually means?

> ...
>> 10.  Generators
>>
>>    A JSON generator produces JSON text.  The resulting text MUST
>>    strictly conform to the JSON grammar.
>>
>> "strictly"?
>
> You would prefer "squishily"?

I'd prefer not to say "strictly". Either you conform or you don't.

> ...

Best regards, Julian


From paul.hoffman@vpnc.org  Thu Dec  5 07:59:09 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B317D1AE071 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 07:59:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 23F5afTnkYqs for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 07:59:08 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 87EA51AE06F for <json@ietf.org>; Thu,  5 Dec 2013 07:59:08 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB5Fww9N014981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Dec 2013 08:59:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <20131205044253.GH21240@localhost>
Date: Thu, 5 Dec 2013 07:58:59 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <51F5DED3-A3CB-4AE3-9A1C-D9E25BFD822C@vpnc.org>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <20131205044253.GH21240@localhost>
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 15:59:09 -0000

On Dec 4, 2013, at 8:42 PM, Nico Williams <nico@cryptonector.com> wrote:

> On Thu, Dec 05, 2013 at 02:57:05AM +0000, Matt Miller (mamille2) =
wrote:
>> [...]
>=20
> Comments:
>=20
> - s/rfc4727/rfc4627/g  (the link to the attachment says 4727)

That's actually not part of the response we are sending, so there is =
nothing we can change. Yes, the link is wrong in the Liaison tool, but =
we'll just have to live with that.

> - I don't think we ought to demand anything more than stability for
>   normatively referencing ECMA-404.  In particular it seems odd to
>   demand that the other SDO (ECMA) establish open processes before
>   we'll consider referencing their documents -- a demand of that sort
>   ought to be backed up by a statement (as a published RFC) from the
>   IESG and/or IAB, not from a WG.
>=20
>   I know, you said "[the IETF] _almost_ exclusively...".
>=20
>   Are you asking the WG to demand that the ECMA commit to open
>   processes in regards to TC39's future updates of ECMA-404?  Is that =
a
>   consensus call?

I don't think any of the wording in the response "demands" anything. =
Ecma made a request, and we are turning down the request for stated =
reasons. People in the WG discussion expressed consternation with =
ECMA-404, and the undertone was that they expected it to be developed in =
an IETF-like fashion. It's fine that Ecma didn't do that, of course, but =
it is also fine for us to base our decision on their process. Having =
said that, which sentences about "demands" were you referring to?

> Is there documentation of "official" attempts to contact ECMA TC39.
> (I'm not sure what that would look like.)

Matt and I were told about it by at least three different people in the =
IETF leadership. It (thankfully) happened at a different layer.

>> We know that some TC39 members joined the JSON WG mailing list but =
did
>> not voice any process concerns in the WG -- or privately to the WG
>> Chairs -- before or during either of the Last Calls on the document.
>=20
> I've certainly seen complaints about direction or specific consensus
> calls.  Were any by TC39 members?  I'd not know.  Were they about
> process?  Perhaps if asked for clarification those voicing concerns
> might specify the process as a source of concern.

You can determine who is a TC39 member by looking at their roster.

--Paul Hoffman=

From cabo@tzi.org  Thu Dec  5 08:01:11 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEAB1AE071 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:01:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 SjJeomGs4XQL for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:01:09 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id F176C1AE07F for <json@ietf.org>; Thu,  5 Dec 2013 08:01:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB5G12fO021637; Thu, 5 Dec 2013 17:01:02 +0100 (CET)
Received: from [192.168.217.105] (p54890AEF.dip0.t-ipconnect.de [84.137.10.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0A0A2D5F; Thu,  5 Dec 2013 17:01:01 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <28869F37-1FC4-4F05-A729-DAB14CDA3757@vpnc.org>
Date: Thu, 5 Dec 2013 17:00:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <CF90FAA0-9E3C-42D1-8255-F8640782ACC9@tzi.org>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com> <3461B710-B969-4315-854B-E2C30B2141FA@tzi.org> <28869F37-1FC4-4F05-A729-DAB14CDA3757@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1822)
Cc: Tim Bray <tbray@textuality.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 16:01:11 -0000

On 05 Dec 2013, at 16:27, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> <hat on>
>=20
> On Dec 5, 2013, at 12:20 AM, Carsten Bormann <cabo@tzi.org> wrote:
>=20
>> Major new bug (apart from the one Rob found):
>>=20
>> =97 A SHOULD-level requirement for BOM tolerance is a gratuitous =
change.  (I thought we were shooting for a MAY.)
>=20
> There was a reasonable number of people who were very concerned that =
JSON documents that were being sent around with a BOM would be rejected.

As they should be.

One way to deal with a common mistake is to legitimize it.

Doing this too often leads to soup.

(The alternative is to point out the mistake is a mistake.)

However, I=92m not at all convinced that people adding BOMs to their =
JSON senders even is a common mistake.

I have seen way more HT characters (TABs) in strings, trailing commas =
etc., than BOMs in JSON documents.  Should we legitimize those, too?

> Given the current text:
>   Implementations have been observed to generate JSON texts prefixed
>   with a Byte Order Mark character.  While this is not allowed by the
>   grammar in this specification, in the interests of interoperability
>   it is RECOMMENDED that implementations which parse JSON texts ignore
>   the presence of a byte order mark rather than treating it as an
>   error.
> what change would you make?

it is RECOMMENDED that implementations which parse JSON texts ignore
->
implementations that parse JSON texts MAY WISH TO ignore

(OK, without the RFC 6919ism, as apt as that may be here, that becomes:)

implementations that parse JSON texts MAY ignore

(Maybe add that this is mostly relevant for parsers that are used to =
interpret JSON files entered by users, not so much for those used for =
data interchange.)

>> =97 Even if the WG decides that change is warranted, the text on -08 =
will be read as =93JSON now allows BOMs=94 by anyone who is not a =
language lawyer.  The =93SHOULD accept=94 needs to be accompanied by a =
(redundant, but contextually necessary) =93MUST NOT send=94.
>=20
> If it is redundant (and it is, given the carefully worded intro to =
that sentence), why do you feel it is "contextually necessary=94?

Because a number of decades of watching people interpret specifications =
teaches me that people will read this as =93JSON now allows BOMs=94, all =
careful wording aside.  So they will add BOMs to all JSON documents they =
send and then complain to the other JSON implementers that haven=92t =
changed their implementations for BOM tolerance that =93this is now =
valid JSON=94, as you "SHOULD ignore the BOM".

Adding the (theoretically redundant) =93MUST NOT send=94 makes it more =
likely that this obvious misunderstanding is nipped in the bud.

If the ensuing clarity creates too much cognitive dissonance, at least =
s/the grammar in//.

Gr=FC=DFe, Carsten


From paul.hoffman@vpnc.org  Thu Dec  5 08:03:32 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F071AE07C for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:03:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 x3tkHFTAN-tK for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:03:32 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E22F41AE071 for <json@ietf.org>; Thu,  5 Dec 2013 08:03:31 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB5G3PvV015855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Dec 2013 09:03:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAHBU6iva2H-ovjmfA7=7j2KxUuXAMjhCb8fcMgKxq6hk+A9BtQ@mail.gmail.com>
Date: Thu, 5 Dec 2013 08:03:27 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <36CB8652-80DB-4E67-A8F6-188801D2E13F@vpnc.org>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <CAHBU6iva2H-ovjmfA7=7j2KxUuXAMjhCb8fcMgKxq6hk+A9BtQ@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 16:03:32 -0000

On Dec 4, 2013, at 9:02 PM, Tim Bray <tbray@textuality.com> wrote:

> I=92m OK with most of this it goes a bit off the rails in the last =
paragraph.  I think the ECMA process is better described as =93opaque=94 =
than =93closed=94,

I was told that even if someone volunteered to help on a particular =
document from TC39, they would not be allowed to. That is "closed", not =
just "opaque".

> and the last paragraph gets into speculative territory. =20

Of course, but it is based on lots of IETF history. That is, when =
organizations make liaison relationships with the IETF, things often to =
get smoother.

> While the not-necessarily-immutable nature of 404 is a good reason to =
avoid a normative reference, we don=92t need to speculate on what we =
might do in a future alternative universe.  =20

We don't need to, but Matt and Pete and I thought that proposing a way =
forward that would lead to greater happiness was worthwhile.

--Paul Hoffman=

From tbray@textuality.com  Thu Dec  5 08:05:08 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BA31AE0B4 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:05:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 B7BXIgpA4goH for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:05:05 -0800 (PST)
Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id 94A381AE0B0 for <json@ietf.org>; Thu,  5 Dec 2013 08:05:05 -0800 (PST)
Received: by mail-ve0-f173.google.com with SMTP id oz11so13907888veb.18 for <json@ietf.org>; Thu, 05 Dec 2013 08:05:02 -0800 (PST)
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:content-type; bh=RnRm0pP01hJ8DlkZ/+boIjgqWaMEm2ytlGWOOIc7a2w=; b=a515rWYWHrxPrh53eOlBnEIdTXxwwKO9e8rFDHv5kdXyVwb5D+GE7WP0SJydEFm+me +mbFpALC8wFBFtZ34ztANTuATdqSw5aXYpVrabc0x4kxRwjbv6zddMqY1VpHKfme1/KY nt1Xx5i25zZdMKeRgPg+gcXhGNM2qizTErn0mwu/pzqIdDvlOkUn6wT8BUJdPyQ6QfcK ygrQO/4C0vyutBoUv7pi326W0wlE+syQV/94DeJrDpJUy8Sm2Z0SQ0+RXz4B9zqfA1Xb yoH4+bg5DOzt74RquKnQZQyTNCuG5Bo85Z1K/1h11votKeETlYsCqBh2gCismxN+Cvfz vHBA==
X-Gm-Message-State: ALoCoQmzLu3o/YK5pdMWTiaQ3cP4HvxIAQuXnnd38bDX8x2+rhJOyKgG39h8PPM19O6sF2w58NTm
MIME-Version: 1.0
X-Received: by 10.52.157.1 with SMTP id wi1mr29018102vdb.12.1386259501912; Thu, 05 Dec 2013 08:05:01 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Thu, 5 Dec 2013 08:05:01 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <F6061C95-4C47-4274-8345-A523A263F755@vpnc.org>
References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> <528234A4.2040004@gmx.de> <52A04DFA.6080103@gmx.de> <F6061C95-4C47-4274-8345-A523A263F755@vpnc.org>
Date: Thu, 5 Dec 2013 08:05:01 -0800
Message-ID: <CAHBU6ivhh+aXCnCPTnrAeYESp6t3CVfzqYccT7B1TN0UfXw50A@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary=089e0160bd3a2e2dbf04eccbb1d0
Cc: Julian Reschke <julian.reschke@gmx.de>, JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 16:05:08 -0000

--089e0160bd3a2e2dbf04eccbb1d0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 5, 2013 at 7:34 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> <no hat>
>
> >   This document makes no changes to the definition of JSON; it repairs
> >   specification errors and offers experience-based interoperability
> >   guidance.
> >
> > I believe historical considerations do not belong into the abstract (bu=
t
> into the Introduction)
>
> This seems like bikeshedding, and the text has been where it is for a lon=
g
> time.
>

Let me introduce an argument whiich I=E2=80=99ll label LNS.

LNS: This is not obviously incorrect, the text is reasonably idiomatic and
clear, and we=E2=80=99ve had excellent interoperability. Let=E2=80=99s not =
screw around
with it.

> Are we sure that we do not need the "pre-5378 escape clause" here?
> (Section 4 of <http://trustee.ietf.org/docs/IETF-Copyright-FAQ.pdf>)
>
> Good catch, yes.
>

Uh, I looked at that doc and I=E2=80=99m not sure I get it. What do you wan=
t to
change?


> > Maybe note which productions are imported as well (HEXDIG and DIGIT it
> seems).
>
> Sure.
>

LNS


> > s/fix errata/apply errata/ ?
>
> Sure.
>

An erratum is a description of an error.  We want to fix the error.
Also, LNS.


> >   JSON text SHALL be encoded in Unicode...
> >
> > That's a bit misleading. How do I "encode in Unicode"? I think what it
> tries to say is that one of the Unicode-compatible character encoding
> schemes needs to be used.
>
> This was a swamp where consensus seemed impossible to reach.
>

I thought about this one quite a bit.  Yes, this is flawed, but the actual
state of affairs is that per 4627, JSON can be encoded in any encoding of
Unicode and what=E2=80=99s being encoded aren=E2=80=99t code points but cod=
e units, and I
could write a 3-and-a-half sentence introduction which would make people
say WTF, but in fact this sentence fragment makes it reasonably obvious
what=E2=80=99s going on. Let=E2=80=99s not change it.

>   An implementation may set limits on the size of texts that it
> >   accepts.  An implementation may set limits on the maximum depth of
> >   nesting.  An implementation may set limits on the range and precision
> >   of numbers.  An implementation may set limits on the length and
> >   character contents of strings.
> >
> > Maybe this should be a bullet list?
>
> Bikeshed
>

LNS.


> > 10.  Generators
> >
> >   A JSON generator produces JSON text.  The resulting text MUST
> >   strictly conform to the JSON grammar.
> >
> > "strictly"?
>
> You would prefer "squishily"?
>

LNS.


> >   o  Changed Working Group attribution to JSON Working Group.
> >
> > ...this is a change that will not be visible in the RFC.
>
> OK. Oh, and drat, I totally forgot to update this section per -08.
>
> --Paul Hoffman

--089e0160bd3a2e2dbf04eccbb1d0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Dec 5, 2013 at 7:34 AM, Paul Hoffman <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:paul.hoffman@vpnc.org" target=3D"_blank">paul.hoffman@vpnc.org</a>&gt=
;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">&lt;no hat&gt;<br>
<div class=3D"im"><br>&gt; =C2=A0 This document makes no changes to the def=
inition of JSON; it repairs<br>
&gt; =C2=A0 specification errors and offers experience-based interoperabili=
ty<br>
&gt; =C2=A0 guidance.<br>
&gt;<br>
&gt; I believe historical considerations do not belong into the abstract (b=
ut into the Introduction)<br>
<br>
</div>This seems like bikeshedding, and the text has been where it is for a=
 long time.<br></blockquote><div><br></div><div>Let me introduce an argumen=
t whiich I=E2=80=99ll label LNS.</div><div><br></div><div>LNS: This is not =
obviously incorrect, the text is reasonably idiomatic and clear, and we=E2=
=80=99ve had excellent interoperability. Let=E2=80=99s not screw around wit=
h it.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div class=3D"im">&gt; Are we sure that we =
do not need the &quot;pre-5378 escape clause&quot; here? (Section 4 of &lt;=
<a href=3D"http://trustee.ietf.org/docs/IETF-Copyright-FAQ.pdf" target=3D"_=
blank">http://trustee.ietf.org/docs/IETF-Copyright-FAQ.pdf</a>&gt;)<br>

<br>
</div>Good catch, yes.<br></blockquote><div><br></div><div>Uh, I looked at =
that doc and I=E2=80=99m not sure I get it. What do you want to change?</di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex">

<div class=3D"im">&gt; Maybe note which productions are imported as well (H=
EXDIG and DIGIT it seems).<br>
<br>
</div>Sure.<br></blockquote><div><br></div><div>LNS</div><div>=C2=A0<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex">

<div class=3D"im">&gt; s/fix errata/apply errata/ ?<br>
<br>
</div>Sure.<br></blockquote><div><br></div><div>An erratum is a description=
 of an error. =C2=A0We want to fix the error.</div><div>Also, LNS.</div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">

<div class=3D"im">&gt; =C2=A0 JSON text SHALL be encoded in Unicode...<br><=
/div><div class=3D"im">
&gt;<br>
&gt; That&#39;s a bit misleading. How do I &quot;encode in Unicode&quot;? I=
 think what it tries to say is that one of the Unicode-compatible character=
 encoding schemes needs to be used.<br>
<br>
</div>This was a swamp where consensus seemed impossible to reach.<br></blo=
ckquote><div><br></div><div>I thought about this one quite a bit. =C2=A0Yes=
, this is flawed, but the actual state of affairs is that per 4627, JSON ca=
n be encoded in any encoding of Unicode and what=E2=80=99s being encoded ar=
en=E2=80=99t code points but code units, and I could write a 3-and-a-half s=
entence introduction which would make people say WTF, but in fact this sent=
ence fragment makes it reasonably obvious what=E2=80=99s going on. Let=E2=
=80=99s not change it.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div class=3D"im">&gt; =C2=A0 An implementa=
tion may set limits on the size of texts that it<br>

&gt; =C2=A0 accepts. =C2=A0An implementation may set limits on the maximum =
depth of<br>
&gt; =C2=A0 nesting. =C2=A0An implementation may set limits on the range an=
d precision<br>
&gt; =C2=A0 of numbers. =C2=A0An implementation may set limits on the lengt=
h and<br>
&gt; =C2=A0 character contents of strings.<br>
&gt;<br>
&gt; Maybe this should be a bullet list?<br>
<br>
</div>Bikeshed<br></blockquote><div><br></div><div>LNS.</div><div>=C2=A0<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:=
solid;padding-left:1ex">

<div class=3D"im">&gt; 10. =C2=A0Generators<br>
&gt;<br>
&gt; =C2=A0 A JSON generator produces JSON text. =C2=A0The resulting text M=
UST<br>
&gt; =C2=A0 strictly conform to the JSON grammar.<br>
&gt;<br>
&gt; &quot;strictly&quot;?<br>
<br>
</div>You would prefer &quot;squishily&quot;?<br></blockquote><div><br></di=
v><div>LNS.</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex">

<div class=3D"im">&gt; =C2=A0 o =C2=A0Changed Working Group attribution to =
JSON Working Group.<br>
&gt;<br>
&gt; ...this is a change that will not be visible in the RFC.<br>
<br>
</div>OK. Oh, and drat, I totally forgot to update this section per -08.<br=
>
<span class=3D""><font color=3D"#888888"><br>
--Paul Hoffman</font></span></blockquote></div><br></div></div>

--089e0160bd3a2e2dbf04eccbb1d0--

From tbray@textuality.com  Thu Dec  5 08:08:38 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4FE1AE0B6 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:08:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 bemTbUcYW6dZ for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:08:36 -0800 (PST)
Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6471AE0AA for <json@ietf.org>; Thu,  5 Dec 2013 08:08:35 -0800 (PST)
Received: by mail-ve0-f182.google.com with SMTP id jy13so14182340veb.13 for <json@ietf.org>; Thu, 05 Dec 2013 08:08:32 -0800 (PST)
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:content-type; bh=1pYCTvY2hHBtEk5lwnwVuWfgb5bhWRpjYvDRXKJNm14=; b=f543uWoveqrqZgoM3VJq/fsvpGnfKowUlEtl78wtOIcSsbruu3m+5QxeCj2i029sCe TVEh6V71nCZ/qFz1tT45YheOk/OQ2YkOEkFY4SRTYfMoYArKdfRbDRY2VI9/F1Haf3LZ Hhw0KfTCeKNUVhEkDHuvh7GQXL5n7IqF2g8Pi4pfW2rX4Wdjf9Svuo3f6Ra9LeI54kGy SBBaJpuJT8KZRf/Y8g5hllHRNjswsnRUtiB9RLv/eJjEcbqlXz9brAeFp05kGeBRwukN AZew/FnB3r/LTXj/AOxZB/A+Wxg21Dpw1pUZ6fh3ACHuGfvsaHhXxGNSn/CO56aGkPhf 4lHA==
X-Gm-Message-State: ALoCoQnXM1ElFb1IgL2f43v7k6M6NerxNfeU+RtStqBpaT5Cl3VgdKRhYM6mdHj4QsSsVs/R6IJ7
MIME-Version: 1.0
X-Received: by 10.52.163.65 with SMTP id yg1mr1454704vdb.58.1386259711909; Thu, 05 Dec 2013 08:08:31 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Thu, 5 Dec 2013 08:08:31 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <3E8905B5-098E-4928-BF0A-CD4065738D99@vpnc.org>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com> <CAChr6Sx0TzG6U4XNju91MZjFUnXmBWk5x6iic0c=HnFnCzoMZg@mail.gmail.com> <3E8905B5-098E-4928-BF0A-CD4065738D99@vpnc.org>
Date: Thu, 5 Dec 2013 08:08:31 -0800
Message-ID: <CAHBU6ivQPDQyftO+B=jvFoHZpU1Pdb7+Wpjgpu-_f+0juOodfA@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary=001a11c2cc58b24bd704eccbbd41
Cc: "json@ietf.org" <json@ietf.org>, R S <sayrer@gmail.com>
Subject: Re: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 16:08:38 -0000

--001a11c2cc58b24bd704eccbbd41
Content-Type: text/plain; charset=UTF-8

Yup.


On Thu, Dec 5, 2013 at 7:22 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> <no hat>
>
> On Dec 4, 2013, at 7:33 PM, R S <sayrer@gmail.com> wrote:
>
> > Some of the text in this version looks contradictory:
> >
> > "This revision does not change any of the rules of the specification"
> >
> > vs.
> >
> > "Note that certain previous specifications of JSON constrained a JSON
> text to be an object or an array."
> >
> > Wouldn't one of those be RFC4627? It's right there in the diff.
>
> Good catch, Rob. Given that we had consensus to make a significant change,
> I propose just removing that whole paragraph.
>
> --Paul Hoffman

--001a11c2cc58b24bd704eccbbd41
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Yup.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 5, 2013 at 7:22 AM, Paul Hoffman <span dir="ltr">&lt;<a href="mailto:paul.hoffman@vpnc.org" target="_blank">paul.hoffman@vpnc.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&lt;no hat&gt;<br>
<div class="im"><br>
On Dec 4, 2013, at 7:33 PM, R S &lt;<a href="mailto:sayrer@gmail.com">sayrer@gmail.com</a>&gt; wrote:<br>
<br>
&gt; Some of the text in this version looks contradictory:<br>
&gt;<br>
&gt; &quot;This revision does not change any of the rules of the specification&quot;<br>
&gt;<br>
&gt; vs.<br>
&gt;<br>
&gt; &quot;Note that certain previous specifications of JSON constrained a JSON text to be an object or an array.&quot;<br>
&gt;<br>
&gt; Wouldn&#39;t one of those be RFC4627? It&#39;s right there in the diff.<br>
<br>
</div>Good catch, Rob. Given that we had consensus to make a significant change, I propose just removing that whole paragraph.<br>
<span class="HOEnZb"><font color="#888888"><br>
--Paul Hoffman</font></span></blockquote></div><br></div>

--001a11c2cc58b24bd704eccbbd41--

From paul.hoffman@vpnc.org  Thu Dec  5 08:08:55 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A8F1AE0B6 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:08:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 FwAQZriHjyR7 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:08:54 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1E52C1AE0CC for <json@ietf.org>; Thu,  5 Dec 2013 08:08:50 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB5G8dsG016236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Dec 2013 09:08:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <20131205065024.GL21240@localhost>
Date: Thu, 5 Dec 2013 08:08:40 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <D0709E6C-E78F-4445-AF60-45A9F5BB8BD5@vpnc.org>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <20131205044253.GH21240@localhost> <CAK3OfOiXdOpe+=DzxgD7HeyN0UTtMCiu+b3Cep4d1ftQPjrxww@mail.gmail.com> <52A01BBA.2040809@it.aoyama.ac.jp> <20131205065024.GL21240@localhost>
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.1822)
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, "Matt Miller, \(mamille2\)" <mamille2@cisco.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 16:08:55 -0000

On Dec 4, 2013, at 10:50 PM, Nico Williams <nico@cryptonector.com> =
wrote:

> On Thu, Dec 05, 2013 at 03:22:50PM +0900, "Martin J. D=FCrst" wrote:
>> And the other part comes from the fact that I repeatedly got
>> messages from es-discuss-owner@mozilla.org saying:
>=20
> Some IETF lists also do that. =20

This is off-topic, but I think your statement above has not been true =
for many years. There was an (informal?) decision by the IESG at least =
five years ago to change this, and all IETF-run lists were changed, and =
ones that were run by other organization (such as ones that I ran via =
IMC and VPNC) were told to change.

--Paul Hoffman=

From cabo@tzi.org  Thu Dec  5 08:12:03 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2ACA1AE059 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:12:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 lwcV5OSTo6gz for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:12:03 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A1B861AE028 for <json@ietf.org>; Thu,  5 Dec 2013 08:12:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB5GBu9g012411; Thu, 5 Dec 2013 17:11:56 +0100 (CET)
Received: from [192.168.217.105] (p54890AEF.dip0.t-ipconnect.de [84.137.10.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F0D4DD77; Thu,  5 Dec 2013 17:11:55 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <52A0A17B.30005@gmx.de>
Date: Thu, 5 Dec 2013 17:11:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F9D7CB7-CF04-4542-B90F-59474FB05E0A@tzi.org>
References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> <528234A4.2040004@gmx.de> <52A04DFA.6080103@gmx.de> <F6061C95-4C47-4274-8345-A523A263F755@vpnc.org> <52A0A17B.30005@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1822)
Cc: Tim Bray <tbray@textuality.com>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data	Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 16:12:03 -0000

On 05 Dec 2013, at 16:53, Julian Reschke <julian.reschke@gmx.de> wrote:

> This is about the sentence "JSON text SHALL be encoded in Unicode" =
which IMHO is meaningless. There is no "Unicode encoding" on the wire.
>=20
> Alternatively, can you explain what it actually means?

The current text may not the most unambiguous way to say this, but I =
read it as =93encoded in one of the ways defined by the Unicode =
standard=94.  (Which defines seven of these ways, and not all are =
actually supported by JSON.  Ouch.)  I agree with Tim=92s =93LNS=94 =
here.

Gr=FC=DFe, Carsten


From julian.reschke@gmx.de  Thu Dec  5 08:14:08 2013
Return-Path: <julian.reschke@gmx.de>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50EC1AE0C5 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:14:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 bKMV9Ec5MRd0 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:14:06 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAA21AE0C2 for <json@ietf.org>; Thu,  5 Dec 2013 08:14:06 -0800 (PST)
Received: from [172.24.113.138] ([192.147.117.12]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MQR3s-1W0k6Q3CUG-00TpDv for <json@ietf.org>; Thu, 05 Dec 2013 17:14:02 +0100
Message-ID: <52A0A647.7050005@gmx.de>
Date: Thu, 05 Dec 2013 17:13:59 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Tim Bray <tbray@textuality.com>, Paul Hoffman <paul.hoffman@vpnc.org>
References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> <528234A4.2040004@gmx.de> <52A04DFA.6080103@gmx.de> <F6061C95-4C47-4274-8345-A523A263F755@vpnc.org> <CAHBU6ivhh+aXCnCPTnrAeYESp6t3CVfzqYccT7B1TN0UfXw50A@mail.gmail.com>
In-Reply-To: <CAHBU6ivhh+aXCnCPTnrAeYESp6t3CVfzqYccT7B1TN0UfXw50A@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:/TVXxNZkUxC9OfrxaU6Nuw8vKx4WU6UfkmM5xoFEfkTtHp/OmTj Fw+vuIoEnWEAibES1zYbAVC5lTxgcyNldRFgph8e6tETbZ2iMMlmCNS+hpTtF8me6q5TPzN teHMVEWEP4qTOilz67u5POUhLdBGmqNWbLa5XrqJclD4eUXt1itPwaVICnhSirB9j8EhsHL FmQsKiEYC6cW1xiFT8gOw==
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 16:14:08 -0000

On 2013-12-05 17:05, Tim Bray wrote:
> On Thu, Dec 5, 2013 at 7:34 AM, Paul Hoffman <paul.hoffman@vpnc.org
> <mailto:paul.hoffman@vpnc.org>> wrote:
>
>     <no hat>
>
>      >   This document makes no changes to the definition of JSON; it
>     repairs
>      >   specification errors and offers experience-based interoperability
>      >   guidance.
>      >
>      > I believe historical considerations do not belong into the
>     abstract (but into the Introduction)
>
>     This seems like bikeshedding, and the text has been where it is for
>     a long time.
>
>
> Let me introduce an argument whiich I’ll label LNS.
>
> LNS: This is not obviously incorrect, the text is reasonably idiomatic
> and clear, and we’ve had excellent interoperability. Let’s not screw
> around with it.

;-)

>      > Are we sure that we do not need the "pre-5378 escape clause"
>     here? (Section 4 of
>     <http://trustee.ietf.org/docs/IETF-Copyright-FAQ.pdf>)
>
>     Good catch, yes.
>
>
> Uh, I looked at that doc and I’m not sure I get it. What do you want to
> change?

See 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#attribute-ipr-pre5378Trust200902>.

>      > Maybe note which productions are imported as well (HEXDIG and
>     DIGIT it seems).
>
>     Sure.
>
>
> LNS
>
>      > s/fix errata/apply errata/ ?
>
>     Sure.
>
>
> An erratum is a description of an error.  We want to fix the error.
> Also, LNS.

Um, no. This is new text so the claim you have excellent interop doesn't 
work ;-). We are fixing the errors, not the descriptions of the errors.

>      >   JSON text SHALL be encoded in Unicode...
>      >
>      > That's a bit misleading. How do I "encode in Unicode"? I think
>     what it tries to say is that one of the Unicode-compatible character
>     encoding schemes needs to be used.
>
>     This was a swamp where consensus seemed impossible to reach.
>
>
> I thought about this one quite a bit.  Yes, this is flawed, but the
> actual state of affairs is that per 4627, JSON can be encoded in any
> encoding of Unicode and what’s being encoded aren’t code points but code
> units, and I could write a 3-and-a-half sentence introduction which
> would make people say WTF, but in fact this sentence fragment makes it
> reasonably obvious what’s going on. Let’s not change it.

I find it totally non-obvious to the point that I really have no idea 
what it means.

What we are concerned with is the wire format. If there is a requirement 
here (and it seems so because it says "SHALL"), can we rephrase it in 
terms of character encoding schemes?

> ...

Best regards, Julian

From julian.reschke@gmx.de  Thu Dec  5 08:16:26 2013
Return-Path: <julian.reschke@gmx.de>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355F91AE09C for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:16:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 6jICoj2xXgqe for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:16:24 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 47E571AE07F for <json@ietf.org>; Thu,  5 Dec 2013 08:16:24 -0800 (PST)
Received: from [172.24.113.138] ([192.147.117.12]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MD9J6-1VnUbv411Q-00Gc0p for <json@ietf.org>; Thu, 05 Dec 2013 17:16:20 +0100
Message-ID: <52A0A6D0.2020804@gmx.de>
Date: Thu, 05 Dec 2013 17:16:16 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Carsten Bormann <cabo@tzi.org>
References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> <528234A4.2040004@gmx.de> <52A04DFA.6080103@gmx.de> <F6061C95-4C47-4274-8345-A523A263F755@vpnc.org> <52A0A17B.30005@gmx.de> <4F9D7CB7-CF04-4542-B90F-59474FB05E0A@tzi.org>
In-Reply-To: <4F9D7CB7-CF04-4542-B90F-59474FB05E0A@tzi.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:09jJUbDByC1oPG1VeHXDLWsngLaFOiaDxeEhRrsaMPwD/uCwaX/ xxxVB+Xqmo4aACaLLoea3ueYBL9NCCx9lfa06dzT2ac5X1cv2ty1MU1yPpqGIVbMFS/g1v7 MQN43YZkHkUkD60xgVp1c3BbTCDGqE29hrktwVKiowDxN7h0G739iU9xHGdq2JEd1kSfPkQ V8RpFJYViZTuQkH2UVrBg==
Cc: Tim Bray <tbray@textuality.com>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data	Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 16:16:26 -0000

On 2013-12-05 17:11, Carsten Bormann wrote:
> On 05 Dec 2013, at 16:53, Julian Reschke <julian.reschke@gmx.de> wrote:
>
>> This is about the sentence "JSON text SHALL be encoded in Unicode" which IMHO is meaningless. There is no "Unicode encoding" on the wire.
>>
>> Alternatively, can you explain what it actually means?
>
> The current text may not the most unambiguous way to say this, but I read it as “encoded in one of the ways defined by the Unicode standard”.  (Which defines seven of these ways, and not all are actually supported by JSON.  Ouch.)  I agree with Tim’s “LNS” here.
>
> Grüße, Carsten
> ...

I still don't get it.

Unicode is about code points.

*This* document is about octets on the wire.

Just because the text "always has been link that" doesn't make it correct.

As far as I can tell we have a BCP14 keyword in a meaningless statement, 
and that is a problem.

Best regards, Julian

From paul.hoffman@vpnc.org  Thu Dec  5 08:19:59 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1E41AE07F for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:19:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 adSYieUrRaw2 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:19:58 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BF6A01AE059 for <json@ietf.org>; Thu,  5 Dec 2013 08:19:58 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB5GJpvF016907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Dec 2013 09:19:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com>
Date: Thu, 5 Dec 2013 08:19:52 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <C4BC4148-AE99-4F55-ADCB-D875780F17B0@vpnc.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 16:20:00 -0000

On Dec 4, 2013, at 9:08 PM, Tim Bray <tbray@textuality.com> wrote:

> > A great deal of effort in the JSON WG process around =
draft-ietf-json-rfc4627bis has been to carefully describe differences =
between the new spec and ECMAScript.
>=20
> Really? I don=92t think I agree.  The only difference was the =
top-level restriction, which took a small uncontroversial paragraph to =
describe.
> =20

The effort was about ECMAScript before TC39 split out ECMA-404. All =
those threads about characters-versus-codepoints, objects with duplicate =
keys, and so on, was about ECMAScript.

--Paul Hoffman=

From cabo@tzi.org  Thu Dec  5 08:21:57 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348D51AE09C for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:21:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 NPnGLE18TRsH for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:21:56 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 53CB31AE07C for <json@ietf.org>; Thu,  5 Dec 2013 08:21:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB5GLmJk002942; Thu, 5 Dec 2013 17:21:48 +0100 (CET)
Received: from [192.168.217.105] (p54890AEF.dip0.t-ipconnect.de [84.137.10.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F4208D8A; Thu,  5 Dec 2013 17:21:46 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <52A0A6D0.2020804@gmx.de>
Date: Thu, 5 Dec 2013 17:21:41 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D8C3FAC-4A6C-4261-BC5F-7A92F0EB5ED8@tzi.org>
References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> <528234A4.2040004@gmx.de> <52A04DFA.6080103@gmx.de> <F6061C95-4C47-4274-8345-A523A263F755@vpnc.org> <52A0A17B.30005@gmx.de> <4F9D7CB7-CF04-4542-B90F-59474FB05E0A@tzi.org> <52A0A6D0.2020804@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1822)
Cc: Tim Bray <tbray@textuality.com>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data	Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 16:21:57 -0000

On 05 Dec 2013, at 17:16, Julian Reschke <julian.reschke@gmx.de> wrote:

> Unicode is about code points.
>=20
> *This* document is about octets on the wire.

The Unicode standard is also very much about about bytes on the medium, =
or have section 2.5/2.6 recently been excised?

Gr=FC=DFe, Carsten


From julian.reschke@gmx.de  Thu Dec  5 08:32:02 2013
Return-Path: <julian.reschke@gmx.de>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E121AE0D4 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:32:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 zi5PaNy4ydqN for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:32:01 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id A56A01AE0A9 for <json@ietf.org>; Thu,  5 Dec 2013 08:32:00 -0800 (PST)
Received: from [172.24.113.138] ([192.147.117.12]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0McVns-1W6HDY3aaG-00HchD for <json@ietf.org>; Thu, 05 Dec 2013 17:31:56 +0100
Message-ID: <52A0AA7A.3010507@gmx.de>
Date: Thu, 05 Dec 2013 17:31:54 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: "json@ietf.org" <json@ietf.org>
References: <5281D65E.1080405@gmx.de>
In-Reply-To: <5281D65E.1080405@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:G4TMxOGlEr6PoJYrns5oxGqjaHdGhVHFPWzkSXG/2tJGYpNJU6k 2fRPhuwvN5dPKdTk3nu9fjAtS5cYCbeUsIR6l45OLomJv707PDq3yep+JaG+BQeP3C5VtY8 siDEilKWNpu5K4N6IgQSoF+ouFr+VpBDrSogn7/pn4JmOgCqBzU8D1B2YsJdltizQBJzZrh IfcngPSat/2XjNuMGib8A==
Subject: Re: [Json] LC comment on http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-07#section-11
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 16:32:02 -0000

On 2013-11-12 08:18, Julian Reschke wrote:
> <http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-07#section-11>:
>
>>    Encoding considerations:  8bit if UTF-8; binary if UTF-16 or UTF-32.
>>       JSON may be represented using UTF-8, UTF-16, or UTF-32.  When JSON
>>       is written in UTF-8, JSON is 8bit compatible.  When JSON is
>>       written in UTF-16 or UTF-32, the binary content-transfer-encoding
>>       must be used.
>
> That is a bit misleading, because content-transfer-encoding isn't needed
> (nor defined) if the transport allows binary anyway (such as HTTP).
>
> Related to this: a frequent question on stackoverflow is about the
> charset parameter on application/json. Maybe it's worth re-stating that
> it is not only not defined but also really really has no effect.

Hi there,

again, it would be great if we could add something like:

"Note: there really is no 'charset' parameter defined. Adding one really 
has no effect on compliant recipients."

Best regards, Julian

From cabo@tzi.org  Thu Dec  5 08:35:52 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7EE1AE0B3 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:35:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 YkRROvcZ7U7z for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:35:51 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 29A251AE0A9 for <json@ietf.org>; Thu,  5 Dec 2013 08:35:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB5GZj2p001357; Thu, 5 Dec 2013 17:35:45 +0100 (CET)
Received: from [192.168.217.105] (p54890AEF.dip0.t-ipconnect.de [84.137.10.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9AB2EDA7; Thu,  5 Dec 2013 17:35:44 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <52A0AA7A.3010507@gmx.de>
Date: Thu, 5 Dec 2013 17:35:42 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <EA0623CC-2842-4203-80F0-0E940498A870@tzi.org>
References: <5281D65E.1080405@gmx.de> <52A0AA7A.3010507@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1822)
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] LC comment on http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-07#section-11
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 16:35:52 -0000

On 05 Dec 2013, at 17:31, Julian Reschke <julian.reschke@gmx.de> wrote:

> "Note: there really is no 'charset' parameter defined. Adding one =
really has no effect on compliant recipients."

+1, another piece of redundancy that is well called for.

(I trust the editor will come up with a sentence without two =93really=94s=
 :*)

Gr=FC=DFe, Carsten


From julian.reschke@gmx.de  Thu Dec  5 08:39:23 2013
Return-Path: <julian.reschke@gmx.de>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C17A1AE0EF for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:39:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 jmOpu4uSk4OX for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:39:21 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 131561AE0EB for <json@ietf.org>; Thu,  5 Dec 2013 08:39:21 -0800 (PST)
Received: from [172.24.113.138] ([192.147.117.12]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LsUDg-1VQIlp1IZk-0123MW for <json@ietf.org>; Thu, 05 Dec 2013 17:39:17 +0100
Message-ID: <52A0AC32.1040906@gmx.de>
Date: Thu, 05 Dec 2013 17:39:14 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Carsten Bormann <cabo@tzi.org>
References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> <528234A4.2040004@gmx.de> <52A04DFA.6080103@gmx.de> <F6061C95-4C47-4274-8345-A523A263F755@vpnc.org> <52A0A17B.30005@gmx.de> <4F9D7CB7-CF04-4542-B90F-59474FB05E0A@tzi.org> <52A0A6D0.2020804@gmx.de> <6D8C3FAC-4A6C-4261-BC5F-7A92F0EB5ED8@tzi.org>
In-Reply-To: <6D8C3FAC-4A6C-4261-BC5F-7A92F0EB5ED8@tzi.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:Bbir1i31H7V2TmNBJdnuLTCK9Sg1I1+JBMkQQDE73QWlhA4z2Te MFyUkpkvQ8dmYszXv3OJInOsBJ2QxppcM5Or9VphvHR9qjDaKuU+PYdNbN7GuJNxZvTXZUr GaXA0LWGebneaPQd82QF6g40KkgYTO/zmermlcqcwRHyhh1IewvwitNSjRQRtDowr/qRDki X82oZbLQtjWFB5Wq+tvFQ==
Cc: Tim Bray <tbray@textuality.com>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data	Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 16:39:23 -0000

On 2013-12-05 17:21, Carsten Bormann wrote:
> On 05 Dec 2013, at 17:16, Julian Reschke <julian.reschke@gmx.de> wrote:
>
>> Unicode is about code points.
>>
>> *This* document is about octets on the wire.
>
> The Unicode standard is also very much about about bytes on the medium, or have section 2.5/2.6 recently been excised?

You are right.

OK then, if this is about the 7 encoding schemes mentioned in chapter 
2.6, can we then clarify what it exactly means?

2.6 mentions 7 character encoding schemes.

draft 08 says:

>    JSON text SHALL be encoded in Unicode.  The default encoding is
>    UTF-8, and JSON texts which are encoded in UTF-8 are interoperable in
>    the sense that they will be read successfully by the maximum number
>    of implementations; there are many implementations which cannot
>    successfully read texts in other encodings (such as UTF-16 and
>    UTF-32).
>
>    Implementations have been observed to generate JSON texts prefixed
>    with a Byte Order Mark character.  While this is not allowed by the
>    grammar in this specification, in the interests of interoperability
>    it is RECOMMENDED that implementations which parse JSON texts ignore
>    the presence of a byte order mark rather than treating it as an
>    error.

Can we create a table that says for each of the encoding schemes, both 
with and without BOM, what senders and receivers are supposed to support?

Best regards, Julian

PS: I may look stubborn here, but if the text manages to confuse me 
about encodings, it's likely to confuse most of the audience.


From tbray@textuality.com  Thu Dec  5 08:58:03 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106241AE0C9 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:58:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 ueA7bkIXS_lq for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 08:58:01 -0800 (PST)
Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5B71A1AE0C8 for <json@ietf.org>; Thu,  5 Dec 2013 08:58:01 -0800 (PST)
Received: by mail-vc0-f177.google.com with SMTP id hv10so12948265vcb.8 for <json@ietf.org>; Thu, 05 Dec 2013 08:57:57 -0800 (PST)
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:content-type; bh=xl4w4CVu/YMfg0xVlsHWo5ty1735Sl1lx1m8oQQKXZQ=; b=Nb/rYtvSk+hultTKessU2pLjVZjocg7dIw11vInW+YtaB5W1/MxYVuYR9WeLS3B83o p+DbimaFCnr3BOSXwoqzWHP1dzJAN+4MPIWWrGHQEqMhKQ4OBPu316ZiWKOJhpKLa65e THX9Ream2g9xWF7ZgijluE+m7sbW01NTcymE0Q8vXOsrgACtGiNPBHMEmnGiqKtKN1us LJQcURVXj55B55KWZRqUNX6LbTKgYjhKuppI8NhEbfNH6GNe5KDChUuAakd7xvNOnABQ tWbJc5RlXje1XJzAH/OB006AHkVwgm0r+eWUrl+tblS+oum2LwfrrdvsaBNFD8Fg0FKs h9bQ==
X-Gm-Message-State: ALoCoQlEXS2umQAzS3Bxg+fet5c86NYEyby7sQgXXG1Avz8Ah4uWScLOF7dX1PNfVn5TSGg1Ff1q
MIME-Version: 1.0
X-Received: by 10.52.189.139 with SMTP id gi11mr1593183vdc.72.1386262677625; Thu, 05 Dec 2013 08:57:57 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Thu, 5 Dec 2013 08:57:57 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <52A0AC32.1040906@gmx.de>
References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> <528234A4.2040004@gmx.de> <52A04DFA.6080103@gmx.de> <F6061C95-4C47-4274-8345-A523A263F755@vpnc.org> <52A0A17B.30005@gmx.de> <4F9D7CB7-CF04-4542-B90F-59474FB05E0A@tzi.org> <52A0A6D0.2020804@gmx.de> <6D8C3FAC-4A6C-4261-BC5F-7A92F0EB5ED8@tzi.org> <52A0AC32.1040906@gmx.de>
Date: Thu, 5 Dec 2013 08:57:57 -0800
Message-ID: <CAHBU6it-JT=MwM-Jpan4PPfq5n-WH27ddhTOzhJy9464KqeYMA@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: multipart/alternative; boundary=001a1133fd6a77929304eccc6e45
Cc: Carsten Bormann <cabo@tzi.org>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 16:58:03 -0000

--001a1133fd6a77929304eccc6e45
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 5, 2013 at 8:39 AM, Julian Reschke <julian.reschke@gmx.de>wrote=
:

> Can we create a table that says for each of the encoding schemes, both
> with and without BOM, what senders and receivers are supposed to support?
>

Please, please, no.

PS: I may look stubborn here, but if the text manages to confuse me about
> encodings, it's likely to confuse most of the audience.
>

Weirdly, you=E2=80=99re in a minority; more or less everyone surveyed the
landscape, decided to just use UTF-8, and interoperability is great.  I
think the draft reflects that reality very closely.

--001a1133fd6a77929304eccc6e45
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Dec 5, 2013 at 8:39 AM, Julian Reschke <span dir=3D"ltr">&lt;<a href=3D=
"mailto:julian.reschke@gmx.de" target=3D"_blank">julian.reschke@gmx.de</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5"><spa=
n style=3D"color:rgb(34,34,34)">Can we create a table that says for each of=
 the encoding schemes, both with and without BOM, what senders and receiver=
s are supposed to support?</span></div>
</div></blockquote><div><br></div><div>Please, please, no.</div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">PS: I may look stubborn here, but if the=
 text manages to confuse me about encodings, it&#39;s likely to confuse mos=
t of the audience.<br>
</blockquote><div><br></div><div>Weirdly, you=E2=80=99re in a minority; mor=
e or less everyone surveyed the landscape, decided to just use UTF-8, and i=
nteroperability is great. =C2=A0I think the draft reflects that reality ver=
y closely.</div>
<div>=C2=A0</div></div><br></div></div>

--001a1133fd6a77929304eccc6e45--

From julian.reschke@gmx.de  Thu Dec  5 09:08:35 2013
Return-Path: <julian.reschke@gmx.de>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C2A1AE10E for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 09:08:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 34NtUQ__Vzcq for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 09:08:34 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3FC1AE10C for <json@ietf.org>; Thu,  5 Dec 2013 09:08:33 -0800 (PST)
Received: from [172.24.113.138] ([192.147.117.12]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LgIWi-1VBw9h3A2e-00ngTp for <json@ietf.org>; Thu, 05 Dec 2013 18:08:29 +0100
Message-ID: <52A0B30B.8030504@gmx.de>
Date: Thu, 05 Dec 2013 18:08:27 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Tim Bray <tbray@textuality.com>
References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com>	<528234A4.2040004@gmx.de>	<52A04DFA.6080103@gmx.de>	<F6061C95-4C47-4274-8345-A523A263F755@vpnc.org>	<52A0A17B.30005@gmx.de>	<4F9D7CB7-CF04-4542-B90F-59474FB05E0A@tzi.org>	<52A0A6D0.2020804@gmx.de>	<6D8C3FAC-4A6C-4261-BC5F-7A92F0EB5ED8@tzi.org>	<52A0AC32.1040906@gmx.de> <CAHBU6it-JT=MwM-Jpan4PPfq5n-WH27ddhTOzhJy9464KqeYMA@mail.gmail.com>
In-Reply-To: <CAHBU6it-JT=MwM-Jpan4PPfq5n-WH27ddhTOzhJy9464KqeYMA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:b8de066sN+N+cYE0frSOc4PIjJsMKApL1vKxtwRhkkv1JprI4IF B2HUzFxvi6PmIPclNj5RWTUYPIb5HMXkggX76H+GPKYe9DvcS0YmA+6+6/GKTE3d0styfYK RjXcLankrOIOosiAXoGYikPl0KVgwvvhVfKDJOn0qkK5FsNI6g9VwoNV35p4V4Bh7l/hDTV djm9LBxzP53IbRlil6jLA==
Cc: Carsten Bormann <cabo@tzi.org>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 17:08:35 -0000

On 2013-12-05 17:57, Tim Bray wrote:
> On Thu, Dec 5, 2013 at 8:39 AM, Julian Reschke <julian.reschke@gmx.de
> <mailto:julian.reschke@gmx.de>> wrote:
>
>     Can we create a table that says for each of the encoding schemes,
>     both with and without BOM, what senders and receivers are supposed
>     to support?
>
>
> Please, please, no.
>
>     PS: I may look stubborn here, but if the text manages to confuse me
>     about encodings, it's likely to confuse most of the audience.
>
>
> Weirdly, you’re in a minority; more or less everyone surveyed the
> landscape, decided to just use UTF-8, and interoperability is great.  I
> think the draft reflects that reality very closely.

I totally agree what almost (*) everyone use UTF-8, and that that is a 
good thing.

What I'm complaining about is that the spec is unclear. I hear you 
saying "people use UTF-8 despite the spec being unclear, and that's why 
we don't need to fix it". However, the same argument could be used for 
almost every other change we made. Why is this different?

Can we at least

s/JSON text SHALL be encoded in Unicode./JSON text SHALL be encoded in 
one of the character encoding schemes defined by Unicode./

?

Best regards, Julian

(*) for some value of "almost"

From cowan@ccil.org  Thu Dec  5 09:12:35 2013
Return-Path: <cowan@ccil.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C19E1AE0C9 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 09:12:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 3vnGDsa7L5tD for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 09:12:31 -0800 (PST)
Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id C20CF1AE078 for <json@ietf.org>; Thu,  5 Dec 2013 09:12:31 -0800 (PST)
Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from <cowan@ccil.org>) id 1VocTM-0003cm-Sl; Thu, 05 Dec 2013 12:12:20 -0500
Date: Thu, 5 Dec 2013 12:12:20 -0500
From: John Cowan <cowan@mercury.ccil.org>
To: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <20131205171219.GA32757@mercury.ccil.org>
References: <528234A4.2040004@gmx.de> <52A04DFA.6080103@gmx.de> <F6061C95-4C47-4274-8345-A523A263F755@vpnc.org> <52A0A17B.30005@gmx.de> <4F9D7CB7-CF04-4542-B90F-59474FB05E0A@tzi.org> <52A0A6D0.2020804@gmx.de> <6D8C3FAC-4A6C-4261-BC5F-7A92F0EB5ED8@tzi.org> <52A0AC32.1040906@gmx.de> <CAHBU6it-JT=MwM-Jpan4PPfq5n-WH27ddhTOzhJy9464KqeYMA@mail.gmail.com> <52A0B30B.8030504@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52A0B30B.8030504@gmx.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <cowan@ccil.org>
Cc: Carsten Bormann <cabo@tzi.org>, Tim Bray <tbray@textuality.com>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 17:12:35 -0000

Julian Reschke scripsit:

> s/JSON text SHALL be encoded in Unicode./JSON text SHALL be encoded
> in one of the character encoding schemes defined by Unicode./

+1 to that wording.

-- 
John Cowan <cowan@ccil.org>             http://www.ccil.org/~cowan
"Make a case, man; you're full of naked assertions, just like Nietzsche."
"Oh, i suffer from that, too.  But you know, naked assertions or GTFO."
                        --heard on #scheme, sorta

From cabo@tzi.org  Thu Dec  5 09:18:24 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1D51AE11C for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 09:18:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 gLpf8KgSYR_4 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 09:18:24 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id AC7591AE116 for <json@ietf.org>; Thu,  5 Dec 2013 09:18:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB5HIGHY026486; Thu, 5 Dec 2013 18:18:16 +0100 (CET)
Received: from [192.168.217.105] (p54890AEF.dip0.t-ipconnect.de [84.137.10.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9E38BDE5; Thu,  5 Dec 2013 18:18:15 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20131205171219.GA32757@mercury.ccil.org>
Date: Thu, 5 Dec 2013 18:18:13 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <70D23A61-8796-428C-AB0D-8756139B7D8F@tzi.org>
References: <528234A4.2040004@gmx.de> <52A04DFA.6080103@gmx.de> <F6061C95-4C47-4274-8345-A523A263F755@vpnc.org> <52A0A17B.30005@gmx.de> <4F9D7CB7-CF04-4542-B90F-59474FB05E0A@tzi.org> <52A0A6D0.2020804@gmx.de> <6D8C3FAC-4A6C-4261-BC5F-7A92F0EB5ED8@tzi.org> <52A0AC32.1040906@gmx.de> <CAHBU6it-JT=MwM-Jpan4PPfq5n-WH27ddhTOzhJy9464KqeYMA@mail.gmail.com> <52A0B30B.8030504@gmx.de> <20131205171219.GA32757@mercury.ccil.org>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1822)
Cc: Tim Bray <tbray@textuality.com>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 17:18:24 -0000

s/JSON text SHALL be encoded in Unicode./JSON text SHALL be encoded
>> in one of the character encoding schemes defined by Unicode./

That sounds like we are disowning the rest of Unicode.

If we really must change this to mention the CES, how about

> JSON text SHALL be encoded in Unicode, which defines seven character =
encoding schemes.

Which leads nicely into the existing text:

> The default encoding is
>   UTF-8, and JSON texts which are encoded in UTF-8 are interoperable =
[=85]

Gr=FC=DFe, Carsten


From tbray@textuality.com  Thu Dec  5 09:33:40 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6060D1AE0AE for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 09:33:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 Eue47xTEgkHs for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 09:33:38 -0800 (PST)
Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id A42941AE009 for <json@ietf.org>; Thu,  5 Dec 2013 09:33:38 -0800 (PST)
Received: by mail-vc0-f177.google.com with SMTP id hv10so13003317vcb.8 for <json@ietf.org>; Thu, 05 Dec 2013 09:33:35 -0800 (PST)
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:content-type; bh=DoPAGkAn08yn4KISZeEJ6mhQ1sAh0D1WWPnApJW3NtQ=; b=IwpxpDzTfm10xRXwPSQ9QdEenQPNaxMvRBeOwJszB/jigdC5fy3kfL5qeBv+g4xpcq wqkDEDT/dJWPHe8jh98ICBUNjaTiVLrc1QWV31H8AV0h9KSF9D6/UFrOfdEHHl0sk/CZ E2D+f3Np7sdydCfentevrvsnjRITsJnsFFasMf2OBkIHWIcH16ZqGYVx6OsK8IvlzJPj EFT9+/1hK+7niUuWg78rIaTJBDM7E7qsPoHDDBUrrAS7lwWfw4VHeD4Xa9eY9Un4xgD4 VG1a1WhAtxCmzGgpIv9EW0dwQ/p4I5ryMda+Wt3TNGfDJlm8wEL6vdpzWquaBtAuU7/I VRNw==
X-Gm-Message-State: ALoCoQn5u27BNFpz0pRo+IqsFiPgs5Z4cj4IZwZ5clxfU0O9KXtlJ/OkaPnsEU0nxnlddrjDPmbP
MIME-Version: 1.0
X-Received: by 10.52.189.139 with SMTP id gi11mr1804480vdc.72.1386264814893; Thu, 05 Dec 2013 09:33:34 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Thu, 5 Dec 2013 09:33:34 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <52A0B30B.8030504@gmx.de>
References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> <528234A4.2040004@gmx.de> <52A04DFA.6080103@gmx.de> <F6061C95-4C47-4274-8345-A523A263F755@vpnc.org> <52A0A17B.30005@gmx.de> <4F9D7CB7-CF04-4542-B90F-59474FB05E0A@tzi.org> <52A0A6D0.2020804@gmx.de> <6D8C3FAC-4A6C-4261-BC5F-7A92F0EB5ED8@tzi.org> <52A0AC32.1040906@gmx.de> <CAHBU6it-JT=MwM-Jpan4PPfq5n-WH27ddhTOzhJy9464KqeYMA@mail.gmail.com> <52A0B30B.8030504@gmx.de>
Date: Thu, 5 Dec 2013 09:33:34 -0800
Message-ID: <CAHBU6itHi0qPJe1DWPVDKPR1w50NsKkSTnrKbN_HsOJVQyx5sA@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: multipart/alternative; boundary=001a1133fd6adb7baa04eccced52
Cc: Carsten Bormann <cabo@tzi.org>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 17:33:40 -0000

--001a1133fd6adb7baa04eccced52
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 5, 2013 at 9:08 AM, Julian Reschke <julian.reschke@gmx.de>wrote=
:

>
> s/JSON text SHALL be encoded in Unicode./JSON text SHALL be encoded in on=
e
> of the character encoding schemes defined by Unicode./
>

I=E2=80=99m not even sure that=E2=80=99s true, because JSON has this weird =
thing where
they=E2=80=99re doing code units not code points and and then there=E2=80=
=99s this other
layer of escaping with \u and astral planes via \u-encoded surrogates and
blecch blecch blecch.

I haven=E2=80=99t seen anything shakes my LNS sentiment.



>
> ?
>
> Best regards, Julian
>
> (*) for some value of "almost"
>

--001a1133fd6adb7baa04eccced52
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Dec 5, 2013 at 9:08 AM, Julian Reschke <span dir=3D"ltr">&lt;<a href=3D=
"mailto:julian.reschke@gmx.de" target=3D"_blank">julian.reschke@gmx.de</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><br></div>
s/JSON text SHALL be encoded in Unicode./JSON text SHALL be encoded in one =
of the character encoding schemes defined by Unicode./<br></blockquote><div=
><br></div><div>I=E2=80=99m not even sure that=E2=80=99s true, because JSON=
 has this weird thing where they=E2=80=99re doing code units not code point=
s and and then there=E2=80=99s this other layer of escaping with \u and ast=
ral planes via \u-encoded surrogates and blecch blecch blecch.</div>
<div><br></div><div>I haven=E2=80=99t seen anything shakes my LNS sentiment=
.</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
?<br>
<br>
Best regards, Julian<br>
<br>
(*) for some value of &quot;almost&quot;<br>
</blockquote></div><br></div></div>

--001a1133fd6adb7baa04eccced52--

From tbray@textuality.com  Thu Dec  5 09:40:40 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25081AE10F for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 09:40:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 xg3R8ddnnbAM for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 09:40:37 -0800 (PST)
Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9DE1AE107 for <json@ietf.org>; Thu,  5 Dec 2013 09:40:37 -0800 (PST)
Received: by mail-vc0-f170.google.com with SMTP id ht10so13666860vcb.1 for <json@ietf.org>; Thu, 05 Dec 2013 09:40:34 -0800 (PST)
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:content-type; bh=PPFxlJDBRgklaZ4bMc6ZATLrEXwB6gcYbc1SKWv6HWc=; b=PPACleua4jNyfQ/3YaXbtW8hOW/8DPNBRJDZQ/7H7pfIpMwdhuFY09lGselyfHwbQf 1RDqVEZkSdril9mMhcFPSuxar4fis3JsgZrmEJPOrYPyZBpCk8ftGyu9eI4tZ9wWxzMy FL/LpthnOUUkRs31xUMqdi760KnonDPhzZegi84PlJtNF176BHcCFk9a5XeMZXP0Dq4a M5FDcq0WCjG+ZntNrp6mObd+fOqc4QTa1E7SeJnB58Vf07A3KRVBCS9P8fyrgvTspC/h wIkSVM6R8tvgmLjjcZ6b7M+5Sz2TbiErS08xm5SSa1ACV6Wc60ERutJjvvR1KqGUcI05 5SmQ==
X-Gm-Message-State: ALoCoQmaryYRgagwVkLn41ywXGosq6KUqKrq9sI5OEUdgyDVvwMJGaMKw+LjBNPG5ZtMlwd36Hj8
MIME-Version: 1.0
X-Received: by 10.52.157.1 with SMTP id wi1mr29636514vdb.12.1386265233832; Thu, 05 Dec 2013 09:40:33 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Thu, 5 Dec 2013 09:40:33 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <CF90FAA0-9E3C-42D1-8255-F8640782ACC9@tzi.org>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com> <3461B710-B969-4315-854B-E2C30B2141FA@tzi.org> <28869F37-1FC4-4F05-A729-DAB14CDA3757@vpnc.org> <CF90FAA0-9E3C-42D1-8255-F8640782ACC9@tzi.org>
Date: Thu, 5 Dec 2013 09:40:33 -0800
Message-ID: <CAHBU6ivAkqO7NjE30aUC1kCJhnWhMtpgowgKBySWmD9GHweYew@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Carsten Bormann <cabo@tzi.org>
Content-Type: multipart/alternative; boundary=089e0160bd3ad4388404eccd0690
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 17:40:41 -0000

--089e0160bd3ad4388404eccd0690
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

How about changing it from

 in the interests of interoperability it is RECOMMENDED that
implementations which parse JSON texts ignore the presence of a byte order
mark rather than treating it as an error.

to

 in the interests of interoperability it is RECOMMENDED that
implementations which generate JSON texts not prepend a byte order mark,
and implementations which parse JSON texts ignore the presence of a byte
order mark rather than treating it as an error.


On Thu, Dec 5, 2013 at 8:00 AM, Carsten Bormann <cabo@tzi.org> wrote:

> On 05 Dec 2013, at 16:27, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>
> > <hat on>
> >
> > On Dec 5, 2013, at 12:20 AM, Carsten Bormann <cabo@tzi.org> wrote:
> >
> >> Major new bug (apart from the one Rob found):
> >>
> >> =E2=80=94 A SHOULD-level requirement for BOM tolerance is a gratuitous=
 change.
>  (I thought we were shooting for a MAY.)
> >
> > There was a reasonable number of people who were very concerned that
> JSON documents that were being sent around with a BOM would be rejected.
>
> As they should be.
>
> One way to deal with a common mistake is to legitimize it.
>
> Doing this too often leads to soup.
>
> (The alternative is to point out the mistake is a mistake.)
>
> However, I=E2=80=99m not at all convinced that people adding BOMs to thei=
r JSON
> senders even is a common mistake.
>
> I have seen way more HT characters (TABs) in strings, trailing commas
> etc., than BOMs in JSON documents.  Should we legitimize those, too?
>
> > Given the current text:
> >   Implementations have been observed to generate JSON texts prefixed
> >   with a Byte Order Mark character.  While this is not allowed by the
> >   grammar in this specification, in the interests of interoperability
> >   it is RECOMMENDED that implementations which parse JSON texts ignore
> >   the presence of a byte order mark rather than treating it as an
> >   error.
> > what change would you make?
>
> it is RECOMMENDED that implementations which parse JSON texts ignore
> ->
> implementations that parse JSON texts MAY WISH TO ignore
>
> (OK, without the RFC 6919ism, as apt as that may be here, that becomes:)
>
> implementations that parse JSON texts MAY ignore
>
> (Maybe add that this is mostly relevant for parsers that are used to
> interpret JSON files entered by users, not so much for those used for dat=
a
> interchange.)
>
> >> =E2=80=94 Even if the WG decides that change is warranted, the text on=
 -08 will
> be read as =E2=80=9CJSON now allows BOMs=E2=80=9D by anyone who is not a =
language lawyer.
>  The =E2=80=9CSHOULD accept=E2=80=9D needs to be accompanied by a (redund=
ant, but
> contextually necessary) =E2=80=9CMUST NOT send=E2=80=9D.
> >
> > If it is redundant (and it is, given the carefully worded intro to that
> sentence), why do you feel it is "contextually necessary=E2=80=9D?
>
> Because a number of decades of watching people interpret specifications
> teaches me that people will read this as =E2=80=9CJSON now allows BOMs=E2=
=80=9D, all
> careful wording aside.  So they will add BOMs to all JSON documents they
> send and then complain to the other JSON implementers that haven=E2=80=99=
t changed
> their implementations for BOM tolerance that =E2=80=9Cthis is now valid J=
SON=E2=80=9D, as
> you "SHOULD ignore the BOM".
>
> Adding the (theoretically redundant) =E2=80=9CMUST NOT send=E2=80=9D make=
s it more likely
> that this obvious misunderstanding is nipped in the bud.
>
> If the ensuing clarity creates too much cognitive dissonance, at least
> s/the grammar in//.
>
> Gr=C3=BC=C3=9Fe, Carsten
>
>

--089e0160bd3ad4388404eccd0690
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">How about changing it from=C2=A0<div><br></div><div>=C2=A0=
in the interests of interoperability it is RECOMMENDED that implementations=
 which parse JSON texts ignore the presence of a byte order mark rather tha=
n treating it as an error.<br>
</div><div><br></div><div>to=C2=A0</div><div><br></div><div>=C2=A0in the in=
terests of interoperability it is RECOMMENDED that implementations which ge=
nerate JSON texts not prepend a byte order mark, and implementations which =
parse JSON texts ignore the presence of a byte order mark rather than treat=
ing it as an error.<br>
</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">O=
n Thu, Dec 5, 2013 at 8:00 AM, Carsten Bormann <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:cabo@tzi.org" target=3D"_blank">cabo@tzi.org</a>&gt;</span> wro=
te:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 05 Dec 2013, at 16:27, =
Paul Hoffman &lt;<a href=3D"mailto:paul.hoffman@vpnc.org">paul.hoffman@vpnc=
.org</a>&gt; wrote:<br>

<br>
&gt; &lt;hat on&gt;<br>
&gt;<br>
&gt; On Dec 5, 2013, at 12:20 AM, Carsten Bormann &lt;<a href=3D"mailto:cab=
o@tzi.org">cabo@tzi.org</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; Major new bug (apart from the one Rob found):<br>
&gt;&gt;<br>
&gt;&gt; =E2=80=94 A SHOULD-level requirement for BOM tolerance is a gratui=
tous change. =C2=A0(I thought we were shooting for a MAY.)<br>
&gt;<br>
&gt; There was a reasonable number of people who were very concerned that J=
SON documents that were being sent around with a BOM would be rejected.<br>
<br>
</div>As they should be.<br>
<br>
One way to deal with a common mistake is to legitimize it.<br>
<br>
Doing this too often leads to soup.<br>
<br>
(The alternative is to point out the mistake is a mistake.)<br>
<br>
However, I=E2=80=99m not at all convinced that people adding BOMs to their =
JSON senders even is a common mistake.<br>
<br>
I have seen way more HT characters (TABs) in strings, trailing commas etc.,=
 than BOMs in JSON documents. =C2=A0Should we legitimize those, too?<br>
<div class=3D"im"><br>
&gt; Given the current text:<br>
&gt; =C2=A0 Implementations have been observed to generate JSON texts prefi=
xed<br>
&gt; =C2=A0 with a Byte Order Mark character. =C2=A0While this is not allow=
ed by the<br>
&gt; =C2=A0 grammar in this specification, in the interests of interoperabi=
lity<br>
&gt; =C2=A0 it is RECOMMENDED that implementations which parse JSON texts i=
gnore<br>
&gt; =C2=A0 the presence of a byte order mark rather than treating it as an=
<br>
&gt; =C2=A0 error.<br>
&gt; what change would you make?<br>
<br>
it is RECOMMENDED that implementations which parse JSON texts ignore<br>
</div>-&gt;<br>
implementations that parse JSON texts MAY WISH TO ignore<br>
<br>
(OK, without the RFC 6919ism, as apt as that may be here, that becomes:)<br=
>
<br>
implementations that parse JSON texts MAY ignore<br>
<br>
(Maybe add that this is mostly relevant for parsers that are used to interp=
ret JSON files entered by users, not so much for those used for data interc=
hange.)<br>
<div class=3D"im"><br>
&gt;&gt; =E2=80=94 Even if the WG decides that change is warranted, the tex=
t on -08 will be read as =E2=80=9CJSON now allows BOMs=E2=80=9D by anyone w=
ho is not a language lawyer. =C2=A0The =E2=80=9CSHOULD accept=E2=80=9D need=
s to be accompanied by a (redundant, but contextually necessary) =E2=80=9CM=
UST NOT send=E2=80=9D.<br>

&gt;<br>
&gt; If it is redundant (and it is, given the carefully worded intro to tha=
t sentence), why do you feel it is &quot;contextually necessary=E2=80=9D?<b=
r>
<br>
</div>Because a number of decades of watching people interpret specificatio=
ns teaches me that people will read this as =E2=80=9CJSON now allows BOMs=
=E2=80=9D, all careful wording aside. =C2=A0So they will add BOMs to all JS=
ON documents they send and then complain to the other JSON implementers tha=
t haven=E2=80=99t changed their implementations for BOM tolerance that =E2=
=80=9Cthis is now valid JSON=E2=80=9D, as you &quot;SHOULD ignore the BOM&q=
uot;.<br>

<br>
Adding the (theoretically redundant) =E2=80=9CMUST NOT send=E2=80=9D makes =
it more likely that this obvious misunderstanding is nipped in the bud.<br>
<br>
If the ensuing clarity creates too much cognitive dissonance, at least s/th=
e grammar in//.<br>
<br>
Gr=C3=BC=C3=9Fe, Carsten<br>
<br>
</blockquote></div><br></div>

--089e0160bd3ad4388404eccd0690--

From julian.reschke@gmx.de  Thu Dec  5 09:45:14 2013
Return-Path: <julian.reschke@gmx.de>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9129F1AE107 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 09:45:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 8fJk_8nJSDji for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 09:45:13 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id B15FC1ADE84 for <json@ietf.org>; Thu,  5 Dec 2013 09:45:12 -0800 (PST)
Received: from [172.24.113.138] ([192.147.117.12]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MdKkd-1W77LD3Tn9-00IS2X for <json@ietf.org>; Thu, 05 Dec 2013 18:45:09 +0100
Message-ID: <52A0BBA2.5090502@gmx.de>
Date: Thu, 05 Dec 2013 18:45:06 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Tim Bray <tbray@textuality.com>
References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> <528234A4.2040004@gmx.de> <52A04DFA.6080103@gmx.de> <F6061C95-4C47-4274-8345-A523A263F755@vpnc.org> <52A0A17B.30005@gmx.de> <4F9D7CB7-CF04-4542-B90F-59474FB05E0A@tzi.org> <52A0A6D0.2020804@gmx.de> <6D8C3FAC-4A6C-4261-BC5F-7A92F0EB5ED8@tzi.org> <52A0AC32.1040906@gmx.de> <CAHBU6it-JT=MwM-Jpan4PPfq5n-WH27ddhTOzhJy9464KqeYMA@mail.gmail.com> <52A0B30B.8030504@gmx.de> <CAHBU6itHi0qPJe1DWPVDKPR1w50NsKkSTnrKbN_HsOJVQyx5sA@mail.gmail.com>
In-Reply-To: <CAHBU6itHi0qPJe1DWPVDKPR1w50NsKkSTnrKbN_HsOJVQyx5sA@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:qKN6fasA1KXM9GbVA+qSw7KAzwqhN19zaToFRMn5/dsUQYSl8Gt x8K2D8KjIN58L61WtqgSyCDpJIUERjsLfn9YPLoKJ7kn1QkSr4VPUZzCY+ricRtCAvo/T1q DSXhK6UD2kMHCvZIAsPNdh5sUOy4Kr1B+oHHPSimh9BWC1vqfyy/kAAlvVf/5CkIosBNYdn nLqcwNszmr3jbgWq6kzLg==
Cc: Carsten Bormann <cabo@tzi.org>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 17:45:14 -0000

On 2013-12-05 18:33, Tim Bray wrote:
> On Thu, Dec 5, 2013 at 9:08 AM, Julian Reschke <julian.reschke@gmx.de
> <mailto:julian.reschke@gmx.de>> wrote:
>
>
>     s/JSON text SHALL be encoded in Unicode./JSON text SHALL be encoded
>     in one of the character encoding schemes defined by Unicode./
>
>
> I’m not even sure that’s true, because JSON has this weird thing where
> they’re doing code units not code points and and then there’s this other
> layer of escaping with \u and astral planes via \u-encoded surrogates
> and blecch blecch blecch.
>
> I haven’t seen anything shakes my LNS sentiment.

Tim,

can *you* explain what you think the text means (if it's not what 
Carsten said)?

If we collectively don't known what it means then it really really needs 
to be fixed.

Best regards, Julian



From cabo@tzi.org  Thu Dec  5 09:45:54 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1871C1AE12B for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 09:45:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 4dGymUv9CSLi for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 09:45:53 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 153AA1AE107 for <json@ietf.org>; Thu,  5 Dec 2013 09:45:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB5HjlY7024249; Thu, 5 Dec 2013 18:45:47 +0100 (CET)
Received: from [192.168.217.105] (p54890AEF.dip0.t-ipconnect.de [84.137.10.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DE481E03; Thu,  5 Dec 2013 18:45:46 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAHBU6ivAkqO7NjE30aUC1kCJhnWhMtpgowgKBySWmD9GHweYew@mail.gmail.com>
Date: Thu, 5 Dec 2013 18:45:44 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D421E7C2-6A1D-44DA-9EEC-9A0A58F7C37C@tzi.org>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com> <3461B710-B969-4315-854B-E2C30B2141FA@tzi.org> <28869F37-1FC4-4F05-A729-DAB14CDA3757@vpnc.org> <CF90FAA0-9E3C-42D1-8255-F8640782ACC9@tzi.org> <CAHBU6ivAkqO7NjE30aUC1kCJhnWhMtpgowgKBySWmD9GHweYew@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
X-Mailer: Apple Mail (2.1822)
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 17:45:54 -0000

On 05 Dec 2013, at 18:40, Tim Bray <tbray@textuality.com> wrote:

> How about changing it from=20
>=20
>  in the interests of interoperability it is RECOMMENDED that =
implementations which parse JSON texts ignore the presence of a byte =
order mark rather than treating it as an error.
>=20
> to=20
>=20
>  in the interests of interoperability it is RECOMMENDED that =
implementations which generate JSON texts not prepend a byte order mark,

Ouch, that changes the MUST NOT into a SHOULD.  No go.

> and implementations which parse JSON texts ignore the presence of a =
byte order mark rather than treating it as an error.

RECOMMENDED =3D SHOULD.  I think I have argued that turning BOM =
tolerance into a SHOULD is not a smart move.  (I have also said that I =
can live with that mistake.)

Gr=FC=DFe, Carsten


From nico@cryptonector.com  Thu Dec  5 09:52:58 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9461AE0AE for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 09:52:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 Wclk_wn5hr2h for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 09:52:57 -0800 (PST)
Received: from homiemail-a35.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id DE7721A1F66 for <json@ietf.org>; Thu,  5 Dec 2013 09:52:57 -0800 (PST)
Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 9A38554058 for <json@ietf.org>; Thu,  5 Dec 2013 09:52:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=NxFg1zwaE0y9X3jbFb9+ gXtUYhM=; b=nTkQgn3/4fxZzpPB2piRCCnd/lcjL+e/wNzKSOCRmmp+J8q5hd2S EdfU7ovs6cQKuqYH00pSwgvmXPhd6kWyZAaR9OMa+uRxVjGEgKUdEKgkLkzcvSpX PtT/lleKDJzdhZBWu+8/ul8b59LEHp/F5NEEqjIlaIgiNGqpCi0I6yk=
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 396C454073 for <json@ietf.org>; Thu,  5 Dec 2013 09:52:54 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id hn9so37752wib.13 for <json@ietf.org>; Thu, 05 Dec 2013 09:52:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VTZ3SWMJoxVKcHilVK1jbtu2NBLzj2PGsaxbCE0Zamw=; b=cJzdvKZ7iVWUsscIyQQfuBHd+OF3Jd88NoKxWlWQtRy2YPcVDMUhdAP2OSMzNYsNna MemKKvIGwlYOy9iXUgpjsztLqpINviFptv/X1xmsG/MaKb3jEcFig5Z0n43o9p2OrqI2 Y//ol0SE8OPAjOCn1WfnTHhYDS6S4H6xnl5UKbgky8Hg+SjuovcWR7zR/sxcCwXVVL/2 8rqZxnQYBI8ueI7SBZJCo9JwzlVY+X3RNZbttrrhq2WFgv1spclwLOSDSAjOsjSTh9cg IV9ekDhwXuKxpPWubsC7XHLisLsKy2x2Hze/xQOARgMN7uYmqyBaLd8f7Af3ZI0I4CpR cPFA==
MIME-Version: 1.0
X-Received: by 10.180.91.11 with SMTP id ca11mr13158096wib.39.1386265972408; Thu, 05 Dec 2013 09:52:52 -0800 (PST)
Received: by 10.217.10.6 with HTTP; Thu, 5 Dec 2013 09:52:52 -0800 (PST)
In-Reply-To: <52A0BBA2.5090502@gmx.de>
References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> <528234A4.2040004@gmx.de> <52A04DFA.6080103@gmx.de> <F6061C95-4C47-4274-8345-A523A263F755@vpnc.org> <52A0A17B.30005@gmx.de> <4F9D7CB7-CF04-4542-B90F-59474FB05E0A@tzi.org> <52A0A6D0.2020804@gmx.de> <6D8C3FAC-4A6C-4261-BC5F-7A92F0EB5ED8@tzi.org> <52A0AC32.1040906@gmx.de> <CAHBU6it-JT=MwM-Jpan4PPfq5n-WH27ddhTOzhJy9464KqeYMA@mail.gmail.com> <52A0B30B.8030504@gmx.de> <CAHBU6itHi0qPJe1DWPVDKPR1w50NsKkSTnrKbN_HsOJVQyx5sA@mail.gmail.com> <52A0BBA2.5090502@gmx.de>
Date: Thu, 5 Dec 2013 11:52:52 -0600
Message-ID: <CAK3OfOhd+wMPyB3aAYYZfS5v+3j+T8Twyewm5z+7Wks8J1jEiw@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: text/plain; charset=UTF-8
Cc: Carsten Bormann <cabo@tzi.org>, Tim Bray <tbray@textuality.com>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 17:52:58 -0000

OLD:

   JSON text SHALL be encoded in Unicode.  The default encoding is
   UTF-8.

NEW:

   JSON texts are composed of Unicode characters.  The default
encoding is UTF-8.  Note that other Unicode encodings may not
interoperate as well as UTF-8.

But I agree with Tim that while the old text is broken but its meaning
understood by all anyways, therefore it's best left alone,
particularly if fixing it leads to a large sub-thread.

Nico
--

From tbray@textuality.com  Thu Dec  5 09:59:26 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C18D1A1F66 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 09:59:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 1sap_vHQgeLR for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 09:59:23 -0800 (PST)
Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 537A81AE10F for <json@ietf.org>; Thu,  5 Dec 2013 09:59:23 -0800 (PST)
Received: by mail-ve0-f177.google.com with SMTP id db12so13923150veb.22 for <json@ietf.org>; Thu, 05 Dec 2013 09:59:19 -0800 (PST)
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:content-type; bh=jI+owlAqTNEKTjpI15yijpezrvZoxw8pPfAw7HivXV0=; b=P6v7DopZzheQzIUEmWq7tsqkamgRRtBmSUPueCtL0HvmCv0kxLquggRlgJ3WeGoXaV GYDfTY/BtOHZ4YdxYoq0ajN7OA0IkL/e0KvQA1hGroqVf9JAUI1AsyOi5U6fzsxLs0i2 N4Z647ofZ/5tiEXoyhopRTU8Ar1JvrmwSIh6mCni8D9n04E76kFHhvr3jZAyLK8sDeQP RTZGNOeL14rzVxKgZ3WOBdTO9gcyH4UDSOekBe7hCXvOFoExY0yxSbRm3dgpJ6tyiumB lGQYiMMFfw/VPQg2ILxyGl3OCYxh3fcpSNjsZC1I1nGyVychATeGnYFuBQlCzJw9mBnW 0d/w==
X-Gm-Message-State: ALoCoQlvLid/08LosP3VU1x6y8whkLyVOhqoCZ9fnrToigbZ+eeewCOWkP0GPdGHvcACM4t4zxSo
MIME-Version: 1.0
X-Received: by 10.52.232.8 with SMTP id tk8mr1940740vdc.76.1386266359487; Thu, 05 Dec 2013 09:59:19 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Thu, 5 Dec 2013 09:59:19 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <CAK3OfOhd+wMPyB3aAYYZfS5v+3j+T8Twyewm5z+7Wks8J1jEiw@mail.gmail.com>
References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> <528234A4.2040004@gmx.de> <52A04DFA.6080103@gmx.de> <F6061C95-4C47-4274-8345-A523A263F755@vpnc.org> <52A0A17B.30005@gmx.de> <4F9D7CB7-CF04-4542-B90F-59474FB05E0A@tzi.org> <52A0A6D0.2020804@gmx.de> <6D8C3FAC-4A6C-4261-BC5F-7A92F0EB5ED8@tzi.org> <52A0AC32.1040906@gmx.de> <CAHBU6it-JT=MwM-Jpan4PPfq5n-WH27ddhTOzhJy9464KqeYMA@mail.gmail.com> <52A0B30B.8030504@gmx.de> <CAHBU6itHi0qPJe1DWPVDKPR1w50NsKkSTnrKbN_HsOJVQyx5sA@mail.gmail.com> <52A0BBA2.5090502@gmx.de> <CAK3OfOhd+wMPyB3aAYYZfS5v+3j+T8Twyewm5z+7Wks8J1jEiw@mail.gmail.com>
Date: Thu, 5 Dec 2013 09:59:19 -0800
Message-ID: <CAHBU6itkDtism82qnkE49YZh9s9_gangjKJeAAtPL5tkzf4WLA@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary=089e01183906ec511204eccd4912
Cc: Julian Reschke <julian.reschke@gmx.de>, Carsten Bormann <cabo@tzi.org>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 17:59:26 -0000

--089e01183906ec511204eccd4912
Content-Type: text/plain; charset=UTF-8

Anyhow, JSON texts are *not* necessarily composed of Unicode characters:
"\uDEAD".


On Thu, Dec 5, 2013 at 9:52 AM, Nico Williams <nico@cryptonector.com> wrote:

> OLD:
>
>    JSON text SHALL be encoded in Unicode.  The default encoding is
>    UTF-8.
>
> NEW:
>
>    JSON texts are composed of Unicode characters.  The default
> encoding is UTF-8.  Note that other Unicode encodings may not
> interoperate as well as UTF-8.
>
> But I agree with Tim that while the old text is broken but its meaning
> understood by all anyways, therefore it's best left alone,
> particularly if fixing it leads to a large sub-thread.
>
> Nico
> --
>

--089e01183906ec511204eccd4912
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Anyhow, JSON texts are *not* necessarily composed of Unico=
de characters: &quot;\uDEAD&quot;.</div><div class=3D"gmail_extra"><br><br>=
<div class=3D"gmail_quote">On Thu, Dec 5, 2013 at 9:52 AM, Nico Williams <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:nico@cryptonector.com" target=3D"_bla=
nk">nico@cryptonector.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">OLD:<br>
<div class=3D"im"><br>
=C2=A0 =C2=A0JSON text SHALL be encoded in Unicode. =C2=A0The default encod=
ing is<br>
</div>=C2=A0 =C2=A0UTF-8.<br>
<br>
NEW:<br>
<br>
=C2=A0 =C2=A0JSON texts are composed of Unicode characters. =C2=A0The defau=
lt<br>
encoding is UTF-8. =C2=A0Note that other Unicode encodings may not<br>
interoperate as well as UTF-8.<br>
<br>
But I agree with Tim that while the old text is broken but its meaning<br>
understood by all anyways, therefore it&#39;s best left alone,<br>
particularly if fixing it leads to a large sub-thread.<br>
<br>
Nico<br>
--<br>
</blockquote></div><br></div>

--089e01183906ec511204eccd4912--

From julian.reschke@gmx.de  Thu Dec  5 10:10:54 2013
Return-Path: <julian.reschke@gmx.de>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089171AE107 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:10:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 Ht42m2yZERrj for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:10:52 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1D61AE105 for <json@ietf.org>; Thu,  5 Dec 2013 10:10:52 -0800 (PST)
Received: from [172.24.113.138] ([192.147.117.12]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MXZ4Q-1W3TNG1tZe-00WZE5 for <json@ietf.org>; Thu, 05 Dec 2013 19:10:48 +0100
Message-ID: <52A0C1A5.10900@gmx.de>
Date: Thu, 05 Dec 2013 19:10:45 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Tim Bray <tbray@textuality.com>,  Nico Williams <nico@cryptonector.com>
References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com>	<528234A4.2040004@gmx.de>	<52A04DFA.6080103@gmx.de>	<F6061C95-4C47-4274-8345-A523A263F755@vpnc.org>	<52A0A17B.30005@gmx.de>	<4F9D7CB7-CF04-4542-B90F-59474FB05E0A@tzi.org>	<52A0A6D0.2020804@gmx.de>	<6D8C3FAC-4A6C-4261-BC5F-7A92F0EB5ED8@tzi.org>	<52A0AC32.1040906@gmx.de>	<CAHBU6it-JT=MwM-Jpan4PPfq5n-WH27ddhTOzhJy9464KqeYMA@mail.gmail.com>	<52A0B30B.8030504@gmx.de>	<CAHBU6itHi0qPJe1DWPVDKPR1w50NsKkSTnrKbN_HsOJVQyx5sA@mail.gmail.com>	<52A0BBA2.5090502@gmx.de>	<CAK3OfOhd+wMPyB3aAYYZfS5v+3j+T8Twyewm5z+7Wks8J1jEiw@mail.gmail.com> <CAHBU6itkDtism82qnkE49YZh9s9_gangjKJeAAtPL5tkzf4WLA@mail.gmail.com>
In-Reply-To: <CAHBU6itkDtism82qnkE49YZh9s9_gangjKJeAAtPL5tkzf4WLA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:kgouVB1BZ2rfyQehZ137sCw3/1zGnoCY2ISM6Wd/Nhdg2Wn6LaZ dMiqpTc3lhsEwL2+5NfkR6wlgaEt6tTT9YOwTe88bLgMq5lfIkQRbfyRsLq9emsRqKOx7Wb Qt4kb968ZnSIKsWMYWpP/N4URQ24j5JXIKWgYoMbrfnP2d15cjUKMrG5SuqqwZ9ecxUMVnO vrJ5btGDzNvljONuJr8qg==
Cc: Carsten Bormann <cabo@tzi.org>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 18:10:54 -0000

On 2013-12-05 18:59, Tim Bray wrote:
> Anyhow, JSON texts are *not* necessarily composed of Unicode characters:
> "\uDEAD".

Yuck ;-) Are you saying that this is why it's a SHALL, not a MUST (or 
just a statement of fact, which I would prefer...)?

Best regards, Julian

From cowan@ccil.org  Thu Dec  5 10:12:25 2013
Return-Path: <cowan@ccil.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AD61ADF8A for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:12:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 nUqSgEQQRkho for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:12:24 -0800 (PST)
Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 40BA51ADE84 for <json@ietf.org>; Thu,  5 Dec 2013 10:12:24 -0800 (PST)
Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from <cowan@ccil.org>) id 1VodPK-0001Rn-T4; Thu, 05 Dec 2013 13:12:15 -0500
Date: Thu, 5 Dec 2013 13:12:14 -0500
From: John Cowan <cowan@mercury.ccil.org>
To: Tim Bray <tbray@textuality.com>
Message-ID: <20131205181214.GG32757@mercury.ccil.org>
References: <4F9D7CB7-CF04-4542-B90F-59474FB05E0A@tzi.org> <52A0A6D0.2020804@gmx.de> <6D8C3FAC-4A6C-4261-BC5F-7A92F0EB5ED8@tzi.org> <52A0AC32.1040906@gmx.de> <CAHBU6it-JT=MwM-Jpan4PPfq5n-WH27ddhTOzhJy9464KqeYMA@mail.gmail.com> <52A0B30B.8030504@gmx.de> <CAHBU6itHi0qPJe1DWPVDKPR1w50NsKkSTnrKbN_HsOJVQyx5sA@mail.gmail.com> <52A0BBA2.5090502@gmx.de> <CAK3OfOhd+wMPyB3aAYYZfS5v+3j+T8Twyewm5z+7Wks8J1jEiw@mail.gmail.com> <CAHBU6itkDtism82qnkE49YZh9s9_gangjKJeAAtPL5tkzf4WLA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHBU6itkDtism82qnkE49YZh9s9_gangjKJeAAtPL5tkzf4WLA@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <cowan@ccil.org>
Cc: Julian Reschke <julian.reschke@gmx.de>, Nico Williams <nico@cryptonector.com>, Carsten Bormann <cabo@tzi.org>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 18:12:25 -0000

Tim Bray scripsit:

> Anyhow, JSON texts are *not* necessarily composed of Unicode characters:
> "\uDEAD".

That text is composed of eight Unicode characters.  What goes on inside
strings has nothing to do with the encoding of JSON documents.  What is
forbidden is to represent them in EBCDIC or Windows-1252 or whatever.

-- 
The Unicode Standard does not encode            John Cowan
idiosyncratic, personal, novel, or private      http://www.ccil.org/~cowan
use characters, nor does it encode logos
or graphics.                                    cowan@ccil.org

From jhildebr@cisco.com  Thu Dec  5 10:13:26 2013
Return-Path: <jhildebr@cisco.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275EB1AE11A for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:13:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level: 
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 dgM3Uhfl6Ayw for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:13:23 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 2367E1AE107 for <json@ietf.org>; Thu,  5 Dec 2013 10:13:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=947; q=dns/txt; s=iport; t=1386267200; x=1387476800; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9Fpj7hNGfneCOGcTDMenL4ahE5H+n1ia8lWg0lQIbgo=; b=TcR8hGunYn7A4W+90OUcSKbyC9TxiTTrwivf4O3efipJT5PHjVFc7/mQ lF9nGsvEAXxVQmQb5xnSz0xme/5YqN9/l2ij++WfOjj/xLmGFOLPf0PTB G341CnNZTYMNJnmBNbM8JlRaJXhPW4wy3Wb2EedXdD53mxKVhv+dhsBuW U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhoFADDBoFKtJV2a/2dsb2JhbABZgweBC7htgRwWdIImAQEEOj8QAgEIDigFCzIlAgQBDQWIAsFjF48AB4QzA5gUkhOBa4E+gio
X-IronPort-AV: E=Sophos;i="4.93,834,1378857600";  d="scan'208";a="4613670"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 05 Dec 2013 18:13:18 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB5IDInq020493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 18:13:19 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 12:13:18 -0600
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: Tim Bray <tbray@textuality.com>, Nico Williams <nico@cryptonector.com>
Thread-Topic: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data Interchange Format) to Proposed Standard
Thread-Index: AQHO8dspLK31RQiXbUeQo9M6pnAR6ZpGOhiAgAAHBQCAAAM5AIAAAisAgAABzoD//46KAA==
Date: Thu, 5 Dec 2013 18:13:18 +0000
Message-ID: <CEC60E33.2EFEB%jhildebr@cisco.com>
References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> <528234A4.2040004@gmx.de> <52A04DFA.6080103@gmx.de> <F6061C95-4C47-4274-8345-A523A263F755@vpnc.org> <52A0A17B.30005@gmx.de> <4F9D7CB7-CF04-4542-B90F-59474FB05E0A@tzi.org> <52A0A6D0.2020804@gmx.de> <6D8C3FAC-4A6C-4261-BC5F-7A92F0EB5ED8@tzi.org> <52A0AC32.1040906@gmx.de> <CAHBU6it-JT=MwM-Jpan4PPfq5n-WH27ddhTOzhJy9464KqeYMA@mail.gmail.com> <52A0B30B.8030504@gmx.de> <CAHBU6itHi0qPJe1DWPVDKPR1w50NsKkSTnrKbN_HsOJVQyx5sA@mail.gmail.com> <52A0BBA2.5090502@gmx.de> <CAK3OfOhd+wMPyB3aAYYZfS5v+3j+T8Twyewm5z+7Wks8J1jEiw@mail.gmail.com> <CAHBU6itkDtism82qnkE49YZh9s9_gangjKJeAAtPL5tkzf4WLA@mail.gmail.com>
In-Reply-To: <CAHBU6itkDtism82qnkE49YZh9s9_gangjKJeAAtPL5tkzf4WLA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [64.101.72.75]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <445639B2E6727B4698812CF01647BCB3@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Julian Reschke <julian.reschke@gmx.de>, Carsten Bormann <cabo@tzi.org>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Last Call: <draft-ietf-json-rfc4627bis-07.txt> (The JSON Data Interchange Format) to Proposed Standard
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 18:13:27 -0000

On 12/5/13 10:59 AM, "Tim Bray" <tbray@textuality.com> wrote:

>Anyhow, JSON texts are *not* necessarily composed of Unicode characters:
>"\uDEAD".

I thought we decided that this is legal:

"\ud800"

but this is not (in hex):

22 ed a0 80 22

(that's the U+d800 improperly encoded as UTF-8 between quotes)

In which case, the syntax layer is always in a valid Unicode encoding.
It's at the semantic layer that all of the weirdness happens.


So, to tweak Nico's proposed text:

OLD:

   JSON text SHALL be encoded in Unicode.  The default encoding is
   UTF-8.

NEW:

JSON is transmitted in a valid Unicode encoding.  The default
encoding is UTF-8.  Note that other Unicode encodings may not
interoperate as well as UTF-8.


We could also add some sort of statement about the semantics of strings
not being quite Unicode, but I think that's too much detail for the
encoding section.


--=20
Joe Hildebrand




From paul.hoffman@vpnc.org  Thu Dec  5 10:35:23 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFFB1AD84D for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:35:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 W6EnGBlPb8ks for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:35:23 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA0E1AD7BF for <json@ietf.org>; Thu,  5 Dec 2013 10:35:23 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB5IZHKb025209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Dec 2013 11:35:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAHBU6ivAkqO7NjE30aUC1kCJhnWhMtpgowgKBySWmD9GHweYew@mail.gmail.com>
Date: Thu, 5 Dec 2013 10:35:17 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <C6A73D07-141B-414B-8D27-08E539941084@vpnc.org>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com> <3461B710-B969-4315-854B-E2C30B2141FA@tzi.org> <28869F37-1FC4-4F05-A729-DAB14CDA3757@vpnc.org> <CF90FAA0-9E3C-42D1-8255-F8640782ACC9@tzi.org> <CAHBU6ivAkqO7NjE30aUC1kCJhnWhMtpgowgKBySWmD9GHweYew@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
X-Mailer: Apple Mail (2.1822)
Cc: Carsten Bormann <cabo@tzi.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 18:35:24 -0000

<no hat>

On Dec 5, 2013, at 9:40 AM, Tim Bray <tbray@textuality.com> wrote:

> How about changing it from=20
>=20
>  in the interests of interoperability it is RECOMMENDED that =
implementations which parse JSON texts ignore the presence of a byte =
order mark rather than treating it as an error.
>=20
> to=20
>=20
>  in the interests of interoperability it is RECOMMENDED that =
implementations which generate JSON texts not prepend a byte order mark, =
and implementations which parse JSON texts ignore the presence of a byte =
order mark rather than treating it as an error.

I agree with Carsten: that first part is wrong. For interoperability =
with systems that had never heard of BOMs because we never mentioned =
them until now, you MUST NOT add one.

Proposed:

... in the interests of interoperability, implementations which parse =
JSON texts MAY ignore the presence of a byte order mark rather than =
treating it as an error. Implementations MUST NOT purposely add a byte =
order mark to the beginning of a JSON text.

--Paul Hoffman=

From tbray@textuality.com  Thu Dec  5 10:37:52 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E071AE10C for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:37:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 rMIhwb3YyJwO for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:37:50 -0800 (PST)
Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3721AE0D0 for <json@ietf.org>; Thu,  5 Dec 2013 10:37:50 -0800 (PST)
Received: by mail-ve0-f180.google.com with SMTP id jz11so14461152veb.11 for <json@ietf.org>; Thu, 05 Dec 2013 10:37:46 -0800 (PST)
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:content-type; bh=tywkBmilc/DB7IIR4O/YzA6nxyC+/cfaijT6txIQQaY=; b=ajoZaa53UtTLT1JxWwwtnBjO8HIN8MEAXzgB45j8KmV6cNDpDNRrrDdgIkNr1KD5bf B4O4jiZNJONP6bUYY1SGOR2kpylwXmU2+rvW+WLPIh9Y5gL6TQxqcn3zb9UCPmplh2OW VZ0jGygx5A0IrDMPv2EhPC9GqfrR9ylpk2XNjgNUX6F+ar2zquMQg4DL4dTLCT5ZZmIP nzR3fr9nDlu8WFo4+6RFeCN6AAqZPaBuqDjZfxOh1dK991/a67D/4gXdO5RVlJh1hIFz B2GP2HLIBEeyHpWJvyH++g1COn1UNkStNNUQvbw+bA61UWjUj8p4XZwBOlo6Ph0ACcYE 5/kw==
X-Gm-Message-State: ALoCoQkshIFpXcdj6/T3KT4jbAcoANgaRu2tNQSkwK9e+rxbyD8tSpevDJkBJyRCDLxM67EToxOf
MIME-Version: 1.0
X-Received: by 10.221.60.134 with SMTP id ws6mr2708536vcb.44.1386268666540; Thu, 05 Dec 2013 10:37:46 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Thu, 5 Dec 2013 10:37:46 -0800 (PST)
X-Originating-IP: [96.49.81.176]
In-Reply-To: <C6A73D07-141B-414B-8D27-08E539941084@vpnc.org>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com> <3461B710-B969-4315-854B-E2C30B2141FA@tzi.org> <28869F37-1FC4-4F05-A729-DAB14CDA3757@vpnc.org> <CF90FAA0-9E3C-42D1-8255-F8640782ACC9@tzi.org> <CAHBU6ivAkqO7NjE30aUC1kCJhnWhMtpgowgKBySWmD9GHweYew@mail.gmail.com> <C6A73D07-141B-414B-8D27-08E539941084@vpnc.org>
Date: Thu, 5 Dec 2013 10:37:46 -0800
Message-ID: <CAHBU6itpN=vjR4QN8CY737L71JEn-WoMwevVQbTS6W8t-hb4Dw@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary=001a113393a46f23f504eccdd38a
Cc: Carsten Bormann <cabo@tzi.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 18:37:52 -0000

--001a113393a46f23f504eccdd38a
Content-Type: text/plain; charset=UTF-8

Works for me.


On Thu, Dec 5, 2013 at 10:35 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> <no hat>
>
> On Dec 5, 2013, at 9:40 AM, Tim Bray <tbray@textuality.com> wrote:
>
> > How about changing it from
> >
> >  in the interests of interoperability it is RECOMMENDED that
> implementations which parse JSON texts ignore the presence of a byte order
> mark rather than treating it as an error.
> >
> > to
> >
> >  in the interests of interoperability it is RECOMMENDED that
> implementations which generate JSON texts not prepend a byte order mark,
> and implementations which parse JSON texts ignore the presence of a byte
> order mark rather than treating it as an error.
>
> I agree with Carsten: that first part is wrong. For interoperability with
> systems that had never heard of BOMs because we never mentioned them until
> now, you MUST NOT add one.
>
> Proposed:
>
> ... in the interests of interoperability, implementations which parse JSON
> texts MAY ignore the presence of a byte order mark rather than treating it
> as an error. Implementations MUST NOT purposely add a byte order mark to
> the beginning of a JSON text.
>
> --Paul Hoffman

--001a113393a46f23f504eccdd38a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Works for me.</div><div class=3D"gmail_extra"><br><br><div=
 class=3D"gmail_quote">On Thu, Dec 5, 2013 at 10:35 AM, Paul Hoffman <span =
dir=3D"ltr">&lt;<a href=3D"mailto:paul.hoffman@vpnc.org" target=3D"_blank">=
paul.hoffman@vpnc.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">&lt;no hat&gt;<br>
<div class=3D"im"><br>
On Dec 5, 2013, at 9:40 AM, Tim Bray &lt;<a href=3D"mailto:tbray@textuality=
.com">tbray@textuality.com</a>&gt; wrote:<br>
<br>
&gt; How about changing it from<br>
&gt;<br>
&gt; =C2=A0in the interests of interoperability it is RECOMMENDED that impl=
ementations which parse JSON texts ignore the presence of a byte order mark=
 rather than treating it as an error.<br>
&gt;<br>
&gt; to<br>
&gt;<br>
&gt; =C2=A0in the interests of interoperability it is RECOMMENDED that impl=
ementations which generate JSON texts not prepend a byte order mark, and im=
plementations which parse JSON texts ignore the presence of a byte order ma=
rk rather than treating it as an error.<br>

<br>
</div>I agree with Carsten: that first part is wrong. For interoperability =
with systems that had never heard of BOMs because we never mentioned them u=
ntil now, you MUST NOT add one.<br>
<br>
Proposed:<br>
<br>
... in the interests of interoperability, implementations which parse JSON =
texts MAY ignore the presence of a byte order mark rather than treating it =
as an error. Implementations MUST NOT purposely add a byte order mark to th=
e beginning of a JSON text.<br>

<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--Paul Hoffman</font></span></blockquote></div><br></div>

--001a113393a46f23f504eccdd38a--

From jhildebr@cisco.com  Thu Dec  5 10:39:23 2013
Return-Path: <jhildebr@cisco.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D261AE0D0 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:39:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 lGGIMNeh6gdl for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:39:20 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C82FD1AD7BF for <json@ietf.org>; Thu,  5 Dec 2013 10:39:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=457; q=dns/txt; s=iport; t=1386268757; x=1387478357; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TSILKxcsOdSUsUWVSTqMztzZsFBtvAuxlWbfL2f5qPw=; b=c4YWQHQU4PFF3O/8dkO941F0RKKdSALzikggL6ZpNOHoidQGZs+wcn9M x4pek5scSg4IvLHYFPlz/UPPWtLdA+XMqtVJIslQO3W3j7p7dnAgE/AYW S+81rLR6y3CfyWYvkW1szHKwSvoek/GwB9XpsTC01GYunV4iZ6a4SzV7l I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhoFAPrHoFKtJXHA/2dsb2JhbABZgweBC7htgRwWdIImAQEEOj0CEAIBCDYQMiUCBAENBYgCwWIXjwAHhDMDlDGDY5ITgymCKg
X-IronPort-AV: E=Sophos;i="4.93,835,1378857600"; d="scan'208";a="289658344"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 05 Dec 2013 18:39:17 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB5IdHfC011802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 18:39:17 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 12:39:17 -0600
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>, Tim Bray <tbray@textuality.com>
Thread-Topic: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt
Thread-Index: AQHO8elNb3MDtQ1YskaWLHJHINDmxg==
Date: Thu, 5 Dec 2013 18:39:16 +0000
Message-ID: <CEC615C6.2F02D%jhildebr@cisco.com>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com> <3461B710-B969-4315-854B-E2C30B2141FA@tzi.org> <28869F37-1FC4-4F05-A729-DAB14CDA3757@vpnc.org> <CF90FAA0-9E3C-42D1-8255-F8640782ACC9@tzi.org> <CAHBU6ivAkqO7NjE30aUC1kCJhnWhMtpgowgKBySWmD9GHweYew@mail.gmail.com> <C6A73D07-141B-414B-8D27-08E539941084@vpnc.org>
In-Reply-To: <C6A73D07-141B-414B-8D27-08E539941084@vpnc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [64.101.72.75]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7ECDA4F9FD6DE9458E3897BBD5146647@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Carsten Bormann <cabo@tzi.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 18:39:23 -0000

On 12/5/13 11:35 AM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:

>Proposed:
>
>... in the interests of interoperability, implementations which parse
>JSON texts MAY ignore the presence of a byte order mark rather than
>treating it as an error. Implementations MUST NOT purposely add a byte
>order mark to the beginning of a JSON text.

Just remove "purposely", or change MUST NOT to "REALLY SHOULD NOT" from
RFC 6919.

--=20
Joe Hildebrand




From tbray@textuality.com  Thu Dec  5 10:40:34 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A181AD7BF for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:40:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 c_pTIQCX0jmL for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:40:32 -0800 (PST)
Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id AEEF81AD66E for <json@ietf.org>; Thu,  5 Dec 2013 10:40:32 -0800 (PST)
Received: by mail-vc0-f175.google.com with SMTP id ld13so13269640vcb.20 for <json@ietf.org>; Thu, 05 Dec 2013 10:40:29 -0800 (PST)
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:content-type; bh=qnq/wxOZDVGdXUpsvl/uE8uIMZRQeZi5O/5dIhIzr9U=; b=Kiwtij90rPrYhaaqyaDqXqMDcwEwMMuBB00mTz5TAUmqBzDrp5OloyXAUtAV3cyp/Z 4qJC1CYpMYW7fH6B4ziiLXZ34ETuuJzzPjOi0R+lK19yP/eQh+3tToCFXtiACx5wc/s1 zOPayboGjnY2PXiqjrshGB/kZ7yKRQsvnKM5xv9nuN4yLQWCO6I7uqfh0cdr03Yvtsi+ BRnM8G/PP5VBOGKxJX4Wrx6K6tVRivU1Dh9v8ZHD+fd9Yn0o+exuhCN47s0EBOiGU7wE JuzsJltnK9QGQ6eLvdbvYct02MTWRZaKFyM7LaKKvLDPB0KnL60sSH4tDblaKbY8yNRL A6PQ==
X-Gm-Message-State: ALoCoQkij15bagoJCAA5wv4CxtgSCPzC/OMl4CyDgwBI6zEQ+OXXXWmfD6piVpYmwZ9WeGQLNMF+
MIME-Version: 1.0
X-Received: by 10.52.97.35 with SMTP id dx3mr56336699vdb.18.1386268829014; Thu, 05 Dec 2013 10:40:29 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Thu, 5 Dec 2013 10:40:28 -0800 (PST)
X-Originating-IP: [96.49.81.176]
In-Reply-To: <CEC615C6.2F02D%jhildebr@cisco.com>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com> <3461B710-B969-4315-854B-E2C30B2141FA@tzi.org> <28869F37-1FC4-4F05-A729-DAB14CDA3757@vpnc.org> <CF90FAA0-9E3C-42D1-8255-F8640782ACC9@tzi.org> <CAHBU6ivAkqO7NjE30aUC1kCJhnWhMtpgowgKBySWmD9GHweYew@mail.gmail.com> <C6A73D07-141B-414B-8D27-08E539941084@vpnc.org> <CEC615C6.2F02D%jhildebr@cisco.com>
Date: Thu, 5 Dec 2013 10:40:28 -0800
Message-ID: <CAHBU6iuZKGg3hhDNXofjdT9hBrDD53+cWZ0Mb=rSLBCkVDhKFw@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
Content-Type: multipart/alternative; boundary=20cf307f31a81e4ac204eccddd3c
Cc: Carsten Bormann <cabo@tzi.org>, Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 18:40:35 -0000

--20cf307f31a81e4ac204eccddd3c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yeah, =E2=80=9Cpurposely=E2=80=9D isn=E2=80=99t actually a word. Purposeful=
ly is, but just lose it.


On Thu, Dec 5, 2013 at 10:39 AM, Joe Hildebrand (jhildebr) <
jhildebr@cisco.com> wrote:

> On 12/5/13 11:35 AM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:
>
> >Proposed:
> >
> >... in the interests of interoperability, implementations which parse
> >JSON texts MAY ignore the presence of a byte order mark rather than
> >treating it as an error. Implementations MUST NOT purposely add a byte
> >order mark to the beginning of a JSON text.
>
> Just remove "purposely", or change MUST NOT to "REALLY SHOULD NOT" from
> RFC 6919.
>
> --
> Joe Hildebrand
>
>
>
>

--20cf307f31a81e4ac204eccddd3c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yeah, =E2=80=9Cpurposely=E2=80=9D isn=E2=80=99t actually a=
 word. Purposefully is, but just lose it.</div><div class=3D"gmail_extra"><=
br><br><div class=3D"gmail_quote">On Thu, Dec 5, 2013 at 10:39 AM, Joe Hild=
ebrand (jhildebr) <span dir=3D"ltr">&lt;<a href=3D"mailto:jhildebr@cisco.co=
m" target=3D"_blank">jhildebr@cisco.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 12/5/13 11:35 AM, &quot=
;Paul Hoffman&quot; &lt;<a href=3D"mailto:paul.hoffman@vpnc.org">paul.hoffm=
an@vpnc.org</a>&gt; wrote:<br>

<br>
&gt;Proposed:<br>
&gt;<br>
&gt;... in the interests of interoperability, implementations which parse<b=
r>
&gt;JSON texts MAY ignore the presence of a byte order mark rather than<br>
&gt;treating it as an error. Implementations MUST NOT purposely add a byte<=
br>
&gt;order mark to the beginning of a JSON text.<br>
<br>
</div>Just remove &quot;purposely&quot;, or change MUST NOT to &quot;REALLY=
 SHOULD NOT&quot; from<br>
RFC 6919.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Joe Hildebrand<br>
<br>
<br>
<br>
</font></span></blockquote></div><br></div>

--20cf307f31a81e4ac204eccddd3c--

From tbray@textuality.com  Thu Dec  5 10:47:32 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620D21AE0CC for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:47:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 ppraukSGDcu9 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:47:29 -0800 (PST)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 21E061AE06C for <json@ietf.org>; Thu,  5 Dec 2013 10:47:29 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id hz11so13325584vcb.17 for <json@ietf.org>; Thu, 05 Dec 2013 10:47:25 -0800 (PST)
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:content-type; bh=m/tjb9fosjshuPYR7IUr2TVAe+JgfIBvFslMRuL9l9U=; b=kU3RR/Ywq/yddpcpzi/9X+qwzeiENS7OJZi7s8hjoYsZEVRGZErtno059iJsRANDVD jlb3KgVQMXRdqBSqqh3OTuXW4CNtTkBrCkgXl81pLmqfd4jZyf0L4HjRBWOqNGlASE+l OWhanq8SlBTM8/raDiIq3UmtWQp7fPSAESF6yux+R9oHSjRlY1s4EWO/uJ55cngrUQ/I 9k4qEJMhDgcWsKayXshZ9Dm/S1pOixI3RAooJMHao/7929XUL8Aj3+vk7N+xYEIPQASt EjhkgwK7L1qE+J20S8V14hRbXYeNGCXgRGBduLb9PHTpQZwTEeDVMKWAgro3q1XlzuZX 6vfw==
X-Gm-Message-State: ALoCoQkjxJmPluScdMgx9hIuabaUdHinI4h+ru/Q+vfdgTB7H1kgRbtT8XLpD48edNUBZzU4Z+rj
MIME-Version: 1.0
X-Received: by 10.220.144.80 with SMTP id y16mr65642126vcu.4.1386269245455; Thu, 05 Dec 2013 10:47:25 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Thu, 5 Dec 2013 10:47:25 -0800 (PST)
X-Originating-IP: [96.49.81.176]
In-Reply-To: <CAHBU6iuZKGg3hhDNXofjdT9hBrDD53+cWZ0Mb=rSLBCkVDhKFw@mail.gmail.com>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com> <3461B710-B969-4315-854B-E2C30B2141FA@tzi.org> <28869F37-1FC4-4F05-A729-DAB14CDA3757@vpnc.org> <CF90FAA0-9E3C-42D1-8255-F8640782ACC9@tzi.org> <CAHBU6ivAkqO7NjE30aUC1kCJhnWhMtpgowgKBySWmD9GHweYew@mail.gmail.com> <C6A73D07-141B-414B-8D27-08E539941084@vpnc.org> <CEC615C6.2F02D%jhildebr@cisco.com> <CAHBU6iuZKGg3hhDNXofjdT9hBrDD53+cWZ0Mb=rSLBCkVDhKFw@mail.gmail.com>
Date: Thu, 5 Dec 2013 10:47:25 -0800
Message-ID: <CAHBU6is8MyYMin59nhQAX0ZAOyNpTD4q8Mp4ri7jqScO0xjUkQ@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
Content-Type: multipart/alternative; boundary=047d7b343974f0b56404eccdf56a
Cc: Carsten Bormann <cabo@tzi.org>, Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 18:47:32 -0000

--047d7b343974f0b56404eccdf56a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

OK, I=E2=80=99m wrong, it is so a word, but let=E2=80=99s drop it anyhow.


On Thu, Dec 5, 2013 at 10:40 AM, Tim Bray <tbray@textuality.com> wrote:

> Yeah, =E2=80=9Cpurposely=E2=80=9D isn=E2=80=99t actually a word. Purposef=
ully is, but just lose it.
>
>
> On Thu, Dec 5, 2013 at 10:39 AM, Joe Hildebrand (jhildebr) <
> jhildebr@cisco.com> wrote:
>
>> On 12/5/13 11:35 AM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:
>>
>> >Proposed:
>> >
>> >... in the interests of interoperability, implementations which parse
>> >JSON texts MAY ignore the presence of a byte order mark rather than
>> >treating it as an error. Implementations MUST NOT purposely add a byte
>> >order mark to the beginning of a JSON text.
>>
>> Just remove "purposely", or change MUST NOT to "REALLY SHOULD NOT" from
>> RFC 6919.
>>
>> --
>> Joe Hildebrand
>>
>>
>>
>>
>

--047d7b343974f0b56404eccdf56a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">OK, I=E2=80=99m wrong, it is so a word, but let=E2=80=99s =
drop it anyhow.</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, Dec 5, 2013 at 10:40 AM, Tim Bray <span dir=3D"ltr">&lt;<a =
href=3D"mailto:tbray@textuality.com" target=3D"_blank">tbray@textuality.com=
</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Yeah, =E2=80=9Cpurposely=E2=
=80=9D isn=E2=80=99t actually a word. Purposefully is, but just lose it.</d=
iv><div class=3D"HOEnZb"><div class=3D"h5">
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Dec 5=
, 2013 at 10:39 AM, Joe Hildebrand (jhildebr) <span dir=3D"ltr">&lt;<a href=
=3D"mailto:jhildebr@cisco.com" target=3D"_blank">jhildebr@cisco.com</a>&gt;=
</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On 12/5/13 11:35 AM, &quot;Paul Hoffman=
&quot; &lt;<a href=3D"mailto:paul.hoffman@vpnc.org" target=3D"_blank">paul.=
hoffman@vpnc.org</a>&gt; wrote:<br>


<br>
&gt;Proposed:<br>
&gt;<br>
&gt;... in the interests of interoperability, implementations which parse<b=
r>
&gt;JSON texts MAY ignore the presence of a byte order mark rather than<br>
&gt;treating it as an error. Implementations MUST NOT purposely add a byte<=
br>
&gt;order mark to the beginning of a JSON text.<br>
<br>
</div>Just remove &quot;purposely&quot;, or change MUST NOT to &quot;REALLY=
 SHOULD NOT&quot; from<br>
RFC 6919.<br>
<span><font color=3D"#888888"><br>
--<br>
Joe Hildebrand<br>
<br>
<br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--047d7b343974f0b56404eccdf56a--

From sayrer@gmail.com  Thu Dec  5 10:49:30 2013
Return-Path: <sayrer@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1331AE116 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:49:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
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 BzDsTvthb92Y for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:49:28 -0800 (PST)
Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id CC2B51AE049 for <json@ietf.org>; Thu,  5 Dec 2013 10:49:27 -0800 (PST)
Received: by mail-qe0-f52.google.com with SMTP id ne12so17715560qeb.39 for <json@ietf.org>; Thu, 05 Dec 2013 10:49:24 -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:content-type; bh=MprYXzwmMDDa6hGQUGDogxTDjS5kh9ei8rN8J9zQcj4=; b=aIv5O6HyCN1g9sKxxzGL2Cr5A78DZgdDvcF26FW3W3OcwShmJnLVBWj/3L/mlTdGoQ K6Vxaj+J4WFa1hRjt+I4kRKj28lTMEsFQaE3efbxPPoRg3zRO9TZLxpw9GJof7feylzQ S0FGccskk0KNqyGL/9mzBzFkaWEOHzWcagi8YKX/t+u8J5ZqKDh5HPXXbs0J1JTHcFtW Q7CeWLNn/mHFgohC7TiJMdqTb+SXH1EoQYQM5nYpAK56/3ydVoDZqhkH2f3U4a61wXqZ e02wnPvSj/kzoVWrV52M6qBiWEtIpkKE4C/nLYq4eMbv6bF+sv8XMMrRIAucDghibDhU NPng==
MIME-Version: 1.0
X-Received: by 10.49.30.197 with SMTP id u5mr150037284qeh.33.1386269364224; Thu, 05 Dec 2013 10:49:24 -0800 (PST)
Received: by 10.140.101.40 with HTTP; Thu, 5 Dec 2013 10:49:24 -0800 (PST)
In-Reply-To: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com>
Date: Thu, 5 Dec 2013 10:49:24 -0800
Message-ID: <CAChr6Sx2g=DtwJbnMHugsoU4Rti_MsPjpOmG+=jWMBaPR3xs7g@mail.gmail.com>
From: R S <sayrer@gmail.com>
To: "Matt Miller (mamille2)" <mamille2@cisco.com>
Content-Type: multipart/alternative; boundary=047d7bd75b8a04a22004eccdfd39
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 18:49:30 -0000

--047d7bd75b8a04a22004eccdfd39
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Dec 4, 2013 at 6:57 PM, Matt Miller (mamille2)
<mamille2@cisco.com>wrote:

> Hello All,
>
> The JSON Working Group has received a statement from Ecma International's
> Technical Committee 39 (TC39) regarding draft-ietf-json-rfc4627bis.  The
> statement can be found at <
> https://datatracker.ietf.org/documents/LIAISON/liaison-2013-11-25-ecma-tc39-json-ecma-tc39-comment-for-rfc-4727bis-attachment-1.pdf>.
>
> In response, the Chairs and sponsoring Area Director propose to send the
> following on behalf of the JSON Working Group.  We wish to send the
> response on December 10.  If there are any serious factual errors in the
> following response, let us know before then.  Note that we are *not* asking
> the WG to re-open any of the consensus discussions, simply to see if we
> misstated anything factual.
>

...


>
>
>  When the IETF normatively refers to other standards, it almost
> exclusively does so to standards that were developed with processes that
> are open to discussion and contribution by anyone.


A quick search turned up numerous IETF documents that normatively reference
ECMA standards. There are also *many* IETF documents that normatively
reference standards developed behind closed doors. Further, it seems like
this entire paragraph refusing to normatively reference ECMA-404 is full of
reasons that don't necessarily reflect the consensus of this WG (unless it
reflects a decision this WG took earlier--I didn't see one, though).


As an IETF participant and erstwhile TC-39 member , I don't think there is
a meaningful delta in "openness".

The IETF has a more regular process for establishing mailing lists and
taking bug reports (the easiest kind of "contribution" to accept). However,
TC-39 also happens to run an open mailing list and shares their meeting
minutes widely. When it comes to decision making, both organizations
operate in roughly the same way: some people's opinions count more than
others, and those people tend to have a lot of customers/money/etc.
Frankly, I think ECMA is more open about this.

- Rob

--047d7bd75b8a04a22004eccdfd39
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Dec 4, 2013 at 6:57 PM, Matt Miller (mamille2) <span dir=3D=
"ltr">&lt;<a href=3D"mailto:mamille2@cisco.com" target=3D"_blank">mamille2@=
cisco.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">Hello All,<br>
<br>
The JSON Working Group has received a statement from Ecma International&#39=
;s Technical Committee 39 (TC39) regarding draft-ietf-json-rfc4627bis. =A0T=
he statement can be found at &lt; <a href=3D"https://datatracker.ietf.org/d=
ocuments/LIAISON/liaison-2013-11-25-ecma-tc39-json-ecma-tc39-comment-for-rf=
c-4727bis-attachment-1.pdf" target=3D"_blank">https://datatracker.ietf.org/=
documents/LIAISON/liaison-2013-11-25-ecma-tc39-json-ecma-tc39-comment-for-r=
fc-4727bis-attachment-1.pdf</a> &gt;.<br>


<br>
In response, the Chairs and sponsoring Area Director propose to send the fo=
llowing on behalf of the JSON Working Group. =A0We wish to send the respons=
e on December 10. =A0If there are any serious factual errors in the followi=
ng response, let us know before then. =A0Note that we are *not* asking the =
WG to re-open any of the consensus discussions, simply to see if we misstat=
ed anything factual.<br>

</blockquote><div><br></div><div>...</div><div>=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<br>

<br>=A0When the IETF normatively refers to other standards, it almost exclu=
sively does so to standards that were developed with processes that are ope=
n to discussion and contribution by anyone.</blockquote><div><br></div><div=
>
A quick search turned up numerous IETF documents that normatively reference=
 ECMA standards. There are also *many* IETF documents that normatively refe=
rence standards developed behind closed doors. Further, it seems like this =
entire paragraph refusing to normatively reference ECMA-404 is full of reas=
ons that don&#39;t necessarily reflect the consensus of this WG (unless it =
reflects a decision this WG took earlier--I didn&#39;t see one, though).</d=
iv>
<div><br></div><div><br></div><div>As an IETF participant and erstwhile TC-=
39 member=A0, I don&#39;t think there is a meaningful delta in &quot;openne=
ss&quot;.</div><div><br></div><div>The IETF has a more regular process for =
establishing mailing lists and taking bug reports (the easiest kind of &quo=
t;contribution&quot; to accept). However, TC-39 also happens to run an open=
 mailing list and shares their meeting minutes widely. When it comes to dec=
ision making, both organizations operate in roughly the same way: some peop=
le&#39;s opinions count more than others, and those people tend to have a l=
ot of customers/money/etc. Frankly, I think ECMA is more open about this.</=
div>
<div><br></div><div>- Rob</div><div><br></div></div></div></div>

--047d7bd75b8a04a22004eccdfd39--

From paul.hoffman@vpnc.org  Thu Dec  5 10:54:30 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4461AE123 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:54:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 L4pl-eYoDpRR for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 10:54:30 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0F55B1AE116 for <json@ietf.org>; Thu,  5 Dec 2013 10:54:30 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB5IsPw6026051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <json@ietf.org>; Thu, 5 Dec 2013 11:54:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <E20F62B4-7F96-42F6-98CC-E560D81A44AC@vpnc.org>
Date: Thu, 5 Dec 2013 10:54:26 -0800
To: JSON WG <json@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
X-Mailer: Apple Mail (2.1822)
Subject: [Json] That encoding thing
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 18:54:31 -0000

<hat on>

The following is technically correct and should at least partially =
appease the pedants among us.=20

s/JSON text SHALL be encoded in Unicode./JSON text SHALL be encoded in =
one of the character encoding schemes defined by Unicode./

--Paul Hoffman=

From cabo@tzi.org  Thu Dec  5 11:02:01 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2ED1AE136 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:02:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 Q1EnggE7xjNX for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:02:00 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A1F371AE10A for <json@ietf.org>; Thu,  5 Dec 2013 11:01:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB5J1lD1026830; Thu, 5 Dec 2013 20:01:47 +0100 (CET)
Received: from [192.168.217.105] (p54890AEF.dip0.t-ipconnect.de [84.137.10.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 826A8E51; Thu,  5 Dec 2013 20:01:46 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <E20F62B4-7F96-42F6-98CC-E560D81A44AC@vpnc.org>
Date: Thu, 5 Dec 2013 20:01:44 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <850EC0FE-F009-47A6-9C62-9D4394B7C29B@tzi.org>
References: <E20F62B4-7F96-42F6-98CC-E560D81A44AC@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] That encoding thing
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 19:02:02 -0000

On 05 Dec 2013, at 19:54, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> The following is technically correct and should at least partially =
appease the pedants among us.=20
>=20
> s/JSON text SHALL be encoded in Unicode./JSON text SHALL be encoded in =
one of the character encoding schemes defined by Unicode./

Both statements are technically correct (unless read with =97pedantic).  =
The second statement says less than the first.  I don=92t think that =
change is intended.  We are not only importing the CES from Unicode.  =
(Now that attention to detail may be pedantic in its own right, sorry =
about that, but I=92m again trying to anticipate how this will be read.)

Gr=FC=DFe, Carsten


From tbray@textuality.com  Thu Dec  5 11:02:35 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C290C1AE148 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:02:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 UyZaJX_4UmqP for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:02:33 -0800 (PST)
Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0571AE13E for <json@ietf.org>; Thu,  5 Dec 2013 11:02:33 -0800 (PST)
Received: by mail-ve0-f171.google.com with SMTP id pa12so14504756veb.30 for <json@ietf.org>; Thu, 05 Dec 2013 11:02:29 -0800 (PST)
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:content-type; bh=IDqbPslnYzYiQLr3AsWZWQyXQEipagsG6a4ZTMxc1ok=; b=gRrIV+7RjNLefC03dKCB3DEf5Bx5f0pPT/kmAd1ZrZ3qevCpz0mJPdPsfVyv/YMoSZ 09L51tAdgGd9BBT+nQJv8p2b2Qv8LTf2W0Nra3+ETCHT7zeQhQqH7cEPzKhnJUFNr0Tn rP0YfwLyOLOt70JP3tHCD8IE82I2GRpoh8LSUEAP70ZDUP63gLh7cpLPrNsA7LsNOJBb X5tqwb+aWyWYtXWsqswFg8+ww/l7Kn4wwDilUlx0Rxc/zs0fMM2AZf8yiY4SrpIKOlQj oKGk6wHae6PoAcxW6n0ybdM4bG/oTWkOi0RFWcP8aEcspSxUzyIIU8MjilyqW4nx+X+W mULA==
X-Gm-Message-State: ALoCoQkaeei0qryZIMnEIqBLpwesf4EPrO8Xb6weGn1MdYL8aEkXhjkC8aa1N5euVFdpbqZp36np
MIME-Version: 1.0
X-Received: by 10.220.58.1 with SMTP id e1mr65969695vch.0.1386270149558; Thu, 05 Dec 2013 11:02:29 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Thu, 5 Dec 2013 11:02:29 -0800 (PST)
X-Originating-IP: [96.49.81.176]
In-Reply-To: <CAChr6Sx0TzG6U4XNju91MZjFUnXmBWk5x6iic0c=HnFnCzoMZg@mail.gmail.com>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com> <CAChr6Sx0TzG6U4XNju91MZjFUnXmBWk5x6iic0c=HnFnCzoMZg@mail.gmail.com>
Date: Thu, 5 Dec 2013 11:02:29 -0800
Message-ID: <CAHBU6ivoE22niuO6jCDDU+GbXB6GGNQ9atCh8Xom=9TL0BmzRQ@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: R S <sayrer@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2c7dad433c004ecce2bbe
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Fwd: New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 19:02:36 -0000

--001a11c2c7dad433c004ecce2bbe
Content-Type: text/plain; charset=UTF-8

Rob is right. I propose we replace that text with:

<t>This document removes inconsistencies with other specifications of JSON,
repairs specification errors, and offers experience-based interoperability
guidance.</t>


On Wed, Dec 4, 2013 at 7:33 PM, R S <sayrer@gmail.com> wrote:

> Some of the text in this version looks contradictory:
>
> "This revision does not change any of the rules of the specification"
>
> vs.
>
> "Note that certain previous specifications of JSON constrained a JSON text
> to be an object or an array."
>
> Wouldn't one of those be RFC4627? It's right there in the diff.
>
> - Rob
>
>
>
>
> On Wed, Dec 4, 2013 at 6:10 PM, Tim Bray <tbray@textuality.com> wrote:
>
>>
>>
>> ---------- Forwarded message ----------
>> From: <internet-drafts@ietf.org>
>> Date: Wed, Dec 4, 2013 at 6:09 PM
>> Subject: New Version Notification - draft-ietf-json-rfc4627bis-08.txt
>> To: json-chairs@tools.ietf.org, draft-ietf-json-rfc4627bis@tools.ietf.org,
>> presnick@qti.qualcomm.com
>>
>>
>>
>> A new version (-08) has been submitted for draft-ietf-json-rfc4627bis:
>> http://www.ietf.org/internet-drafts/draft-ietf-json-rfc4627bis-08.txt
>>
>>
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis/
>>
>> Diff from previous version:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-json-rfc4627bis-08
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> IETF Secretariat.
>>
>>
>>
>> _______________________________________________
>> json mailing list
>> json@ietf.org
>> https://www.ietf.org/mailman/listinfo/json
>>
>>
>

--001a11c2c7dad433c004ecce2bbe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Rob is right. I propose we replace that text with:<div><br=
></div><div>&lt;t&gt;This document removes inconsistencies with other speci=
fications of JSON, repairs specification errors, and offers experience-base=
d interoperability guidance.&lt;/t&gt;<br>
</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">O=
n Wed, Dec 4, 2013 at 7:33 PM, R S <span dir=3D"ltr">&lt;<a href=3D"mailto:=
sayrer@gmail.com" target=3D"_blank">sayrer@gmail.com</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">Some of the text in this version looks contradictory:<div>=
<br></div><div>&quot;<span style=3D"font-size:13px;font-family:verdana,helv=
etica,arial,sans-serif">This revision does not change any of the rules of t=
he specification&quot;</span></div>

<div><span style=3D"font-size:13px;font-family:verdana,helvetica,arial,sans=
-serif"><br></span></div><div><font color=3D"#000000" face=3D"verdana, helv=
etica, arial, sans-serif">vs.</font></div><div><span style=3D"font-size:13p=
x;font-family:verdana,helvetica,arial,sans-serif"><br>

</span></div><div>&quot;Note that certain previous specifications of JSON c=
onstrained a JSON text to be an object or an array.&quot;<br></div><div><br=
></div><div>Wouldn&#39;t one of those be RFC4627? It&#39;s right there in t=
he diff.</div>

<div><br></div><div>- Rob</div><div><br></div><div><br></div></div><div cla=
ss=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On =
Wed, Dec 4, 2013 at 6:10 PM, Tim Bray <span dir=3D"ltr">&lt;<a href=3D"mail=
to:tbray@textuality.com" target=3D"_blank">tbray@textuality.com</a>&gt;</sp=
an> wrote:<br>

</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr=
"><br><br><div class=3D"gmail_quote">---------- Forwarded message ---------=
-<br>
From: <b class=3D"gmail_sendername"></b> <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:internet-drafts@ietf.org" target=3D"_blank">internet-drafts@ietf.org<=
/a>&gt;</span><br>

Date: Wed, Dec 4, 2013 at 6:09 PM<br>Subject: New Version Notification - dr=
aft-ietf-json-rfc4627bis-08.txt<br>To: <a href=3D"mailto:json-chairs@tools.=
ietf.org" target=3D"_blank">json-chairs@tools.ietf.org</a>, <a href=3D"mail=
to:draft-ietf-json-rfc4627bis@tools.ietf.org" target=3D"_blank">draft-ietf-=
json-rfc4627bis@tools.ietf.org</a>, <a href=3D"mailto:presnick@qti.qualcomm=
.com" target=3D"_blank">presnick@qti.qualcomm.com</a><br>


<br><br><br>
A new version (-08) has been submitted for draft-ietf-json-rfc4627bis:<br>
<a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-json-rfc4627bis-0=
8.txt" target=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-jso=
n-rfc4627bis-08.txt</a><br>
<br>
<br>
The IETF datatracker page for this Internet-Draft is:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis/" ta=
rget=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis=
/</a><br>
<br>
Diff from previous version:<br>
<a href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-08=
" target=3D"_blank">http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4=
627bis-08</a><br>
<br>
Please note that it may take a couple of minutes from the time of submissio=
n<br>
until the htmlized version and diff are available at <a href=3D"http://tool=
s.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br>
<br>
IETF Secretariat.<br>
<br>
</div><br></div>
<br></div></div>_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org" target=3D"_blank">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>

--001a11c2c7dad433c004ecce2bbe--

From paul.hoffman@vpnc.org  Thu Dec  5 11:03:57 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942BF1AE13E for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:03:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 pt2aBSKR18Yy for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:03:56 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B2B161AE148 for <json@ietf.org>; Thu,  5 Dec 2013 11:03:56 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB5J3pbG026496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Dec 2013 12:03:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <EA0623CC-2842-4203-80F0-0E940498A870@tzi.org>
Date: Thu, 5 Dec 2013 11:03:52 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <561A6BF9-84D5-4C12-91A3-B511CA5FFE5D@vpnc.org>
References: <5281D65E.1080405@gmx.de> <52A0AA7A.3010507@gmx.de> <EA0623CC-2842-4203-80F0-0E940498A870@tzi.org>
To: "json@ietf.org" <json@ietf.org>
X-Mailer: Apple Mail (2.1822)
Cc: Tim Bray <tbray@textuality.com>
Subject: Re: [Json] LC comment on http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-07#section-11
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 19:03:57 -0000

<hat on>

Tim: please add the following to the end of Section 11.

   Note: no "charset" parameter is defined for this registration.
   Adding one really has no effect on compliant recipients.

This will probably cause a delay in the RFC being issued, and the IESG =
might ask us to remove it, but if it keeps coming up on StackOverflow, =
we should at least make a stab at answering it.

--Paul Hoffman=

From paul.hoffman@vpnc.org  Thu Dec  5 11:08:27 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6500D1AE168 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:08:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 VHn-GrUlAixT for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:08:26 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8212D1AE15D for <json@ietf.org>; Thu,  5 Dec 2013 11:08:22 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB5J8GKR026682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Dec 2013 12:08:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAHBU6ivoE22niuO6jCDDU+GbXB6GGNQ9atCh8Xom=9TL0BmzRQ@mail.gmail.com>
Date: Thu, 5 Dec 2013 11:08:18 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <961A30CC-7193-4CB9-885A-E894A8935820@vpnc.org>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com> <CAChr6Sx0TzG6U4XNju91MZjFUnXmBWk5x6iic0c=HnFnCzoMZg@mail.gmail.com> <CAHBU6ivoE22niuO6jCDDU+GbXB6GGNQ9atCh8Xom=9TL0BmzRQ@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
X-Mailer: Apple Mail (2.1822)
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Fwd: New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 19:08:28 -0000

<hat on>

On Dec 5, 2013, at 11:02 AM, Tim Bray <tbray@textuality.com> wrote:

> Rob is right. I propose we replace that text with:
>=20
> <t>This document removes inconsistencies with other specifications of =
JSON, repairs specification errors, and offers experience-based =
interoperability guidance.</t>

That seems fine.

--Paul Hoffman=

From paul.hoffman@vpnc.org  Thu Dec  5 11:14:48 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374561AE13A for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:14:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 e43JunAyRKVj for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:14:47 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 36BC01AE169 for <json@ietf.org>; Thu,  5 Dec 2013 11:14:06 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB5JDv4D026894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Dec 2013 12:13:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAChr6Sx2g=DtwJbnMHugsoU4Rti_MsPjpOmG+=jWMBaPR3xs7g@mail.gmail.com>
Date: Thu, 5 Dec 2013 11:13:58 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <4110D5CF-3720-4215-914E-0F0395207BB5@vpnc.org>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <CAChr6Sx2g=DtwJbnMHugsoU4Rti_MsPjpOmG+=jWMBaPR3xs7g@mail.gmail.com>
To: R S <sayrer@gmail.com>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 19:14:48 -0000

On Dec 5, 2013, at 10:49 AM, R S <sayrer@gmail.com> wrote:

>  When the IETF normatively refers to other standards, it almost =
exclusively does so to standards that were developed with processes that =
are open to discussion and contribution by anyone.
>=20
> A quick search turned up numerous IETF documents that normatively =
reference ECMA standards. There are also *many* IETF documents that =
normatively reference standards developed behind closed doors.

Fair point. We'll change "almost exclusively does" to "usually tries to =
do".=20

> Further, it seems like this entire paragraph refusing to normatively =
reference ECMA-404 is full of reasons that don't necessarily reflect the =
consensus of this WG (unless it reflects a decision this WG took =
earlier--I didn't see one, though).

The topic of "should we just refer to Ecma" came up multiple times =
before Ecma produced ECMA-404, and each time the consensus was to keep =
our definition.

--Paul Hoffman=

From derhoermi@gmx.net  Thu Dec  5 11:28:26 2013
Return-Path: <derhoermi@gmx.net>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B0F1AE0DE for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:28:26 -0800 (PST)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 L115N3VVsOhd for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:28:24 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 58AC51A802A for <json@ietf.org>; Thu,  5 Dec 2013 11:28:24 -0800 (PST)
Received: from netb.Speedport_W_700V ([91.35.7.188]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0McPvw-1W6BRj23DU-00HgGZ for <json@ietf.org>; Thu, 05 Dec 2013 20:28:20 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Date: Thu, 05 Dec 2013 20:28:22 +0100
Message-ID: <6ii1a9lj7ke30himmkc1d31eab0mvv62t8@hive.bjoern.hoehrmann.de>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com> <3461B710-B969-4315-854B-E2C30B2141FA@tzi.org> <28869F37-1FC4-4F05-A729-DAB14CDA3757@vpnc.org>
In-Reply-To: <28869F37-1FC4-4F05-A729-DAB14CDA3757@vpnc.org>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:G8ZigimsN302iB4bZOzTl+5o7Qw6O4taC/6aEOZq9tpe+BekGe0 TKLXkdNMENFQQNYvBBo8CSYEDgmDwya1/FOw3dONLIJhVR80MrxVr5lF2jiwLaKuWNhb0Cc +vaiEgJn3xmFvIi0q2guukDdyFjzGc9KJ7Vp81NwIJiiUnO/HqsFHanFZxwdops4phtXmSb uY68NdKUCTnsvKg0h/20A==
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 19:28:26 -0000

* Paul Hoffman wrote:
><hat on>
>
>On Dec 5, 2013, at 12:20 AM, Carsten Bormann <cabo@tzi.org> wrote:
>
>> Major new bug (apart from the one Rob found):
>> 
>> — A SHOULD-level requirement for BOM tolerance is a gratuitous change.  (I thought we were shooting for a MAY.)
>
>There was a reasonable number of people who were very concerned that 
>JSON documents that were being sent around with a BOM would be rejected.
>
>Given the current text:
>   Implementations have been observed to generate JSON texts prefixed
>   with a Byte Order Mark character.  While this is not allowed by the
>   grammar in this specification, in the interests of interoperability
>   it is RECOMMENDED that implementations which parse JSON texts ignore
>   the presence of a byte order mark rather than treating it as an
>   error.
>what change would you make?

I wanted to make an example to demonstrate how the text above is non-
sensical and checked the latest draft to make sure I get it right, only
to find that the encoding detection requirements have been removed. I
believe my concerns in this area are not receiving due consideration.

I am happy to take suggestions about available means of appeal.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From cromis@gmail.com  Thu Dec  5 11:35:43 2013
Return-Path: <cromis@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE511AE043 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:35:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 rpa7Psdmhl3R for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:35:42 -0800 (PST)
Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 546FC1AC829 for <json@ietf.org>; Thu,  5 Dec 2013 11:35:42 -0800 (PST)
Received: by mail-pb0-f41.google.com with SMTP id jt11so26695628pbb.0 for <json@ietf.org>; Thu, 05 Dec 2013 11:35:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=LxTdB6t7FtnVlOI9lVMctIWcrmtvXBrFUsEJymjWfeI=; b=h0DjEpbGdRSxzv/vd2j148Lt153Sqv0cPAY2J6KSVcngTIEsY2gD/WborrDvxH8xUG 5S3fU18l9uZGGnHayS65NBJQ+tL1bH6RxA6LSjOb+LM+ArfhN5dS2F5t92Has6x6kOOP jlFZHN6hzQxUX1dp19wh1+xnvdyaIsIcq31Hr/AkONfrXiXqQIW17FnPubFy2YUZZeWL XJdHwMiJeSIp47Wai+Ltc/L2TCApFDI6Dyv7wrkTWwwLyT8eozzg91TjWOjk8ebALHgN ZwOAZsTvbarsM/dvBMqxpEX2XM0eUqXA8jUYoukfUQSgciI2vA000DInYH9OConeoMpX +Wgw==
X-Received: by 10.66.2.66 with SMTP id 2mr91816711pas.72.1386272138764; Thu, 05 Dec 2013 11:35:38 -0800 (PST)
MIME-Version: 1.0
Sender: cromis@gmail.com
Received: by 10.70.93.228 with HTTP; Thu, 5 Dec 2013 11:35:17 -0800 (PST)
In-Reply-To: <6ii1a9lj7ke30himmkc1d31eab0mvv62t8@hive.bjoern.hoehrmann.de>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com> <3461B710-B969-4315-854B-E2C30B2141FA@tzi.org> <28869F37-1FC4-4F05-A729-DAB14CDA3757@vpnc.org> <6ii1a9lj7ke30himmkc1d31eab0mvv62t8@hive.bjoern.hoehrmann.de>
From: Jacob Davies <jacob@well.com>
Date: Thu, 5 Dec 2013 11:35:17 -0800
X-Google-Sender-Auth: mlh2wPwgti_J09u-vqde1WX_vPg
Message-ID: <CAO1wJ5S9L=dDZMj5MUfswr7nejC+m5p9EtB+wowb1nCrEreCPw@mail.gmail.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 19:35:44 -0000

Is your concern that the language now says "ignore the BOM" but has no
other method of determining the encoding of the text? Because yeah.

It seems to me that if you claim to continue to support UTF-16 &
UTF-32 (which I think is pointless, but anyway) you need some way of
indicating that. In the absence of the hacky first-two-bytes table
from the original spec (which doesn't work if you allow strings at the
top level) then don't you need to support BOMs, rather than ignore
them?

On Thu, Dec 5, 2013 at 11:28 AM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote=
:
> * Paul Hoffman wrote:
>><hat on>
>>
>>On Dec 5, 2013, at 12:20 AM, Carsten Bormann <cabo@tzi.org> wrote:
>>
>>> Major new bug (apart from the one Rob found):
>>>
>>> =97 A SHOULD-level requirement for BOM tolerance is a gratuitous change=
.  (I thought we were shooting for a MAY.)
>>
>>There was a reasonable number of people who were very concerned that
>>JSON documents that were being sent around with a BOM would be rejected.
>>
>>Given the current text:
>>   Implementations have been observed to generate JSON texts prefixed
>>   with a Byte Order Mark character.  While this is not allowed by the
>>   grammar in this specification, in the interests of interoperability
>>   it is RECOMMENDED that implementations which parse JSON texts ignore
>>   the presence of a byte order mark rather than treating it as an
>>   error.
>>what change would you make?
>
> I wanted to make an example to demonstrate how the text above is non-
> sensical and checked the latest draft to make sure I get it right, only
> to find that the encoding detection requirements have been removed. I
> believe my concerns in this area are not receiving due consideration.
>
> I am happy to take suggestions about available means of appeal.
> --
> Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr=
mann.de
> Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld=
.de
> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev=
.de/
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json

From tbray@textuality.com  Thu Dec  5 11:39:28 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB281AE15C for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:39:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 USKuH_27wBkS for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:39:23 -0800 (PST)
Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id B1FB61AE0E4 for <json@ietf.org>; Thu,  5 Dec 2013 11:39:23 -0800 (PST)
Received: by mail-ve0-f173.google.com with SMTP id oz11so14265388veb.18 for <json@ietf.org>; Thu, 05 Dec 2013 11:39:20 -0800 (PST)
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:content-type; bh=HP32HnYkLq0SnNrceGIuMpKz3Aw+ekEVKiX3VYeHaXo=; b=MQ5FarkCRCD2d68tlRNIp13CQLa/na72TN7YHjy90s9PfrvL6lko/9qoaR0ZiclNNy QTTmYJ1xoaXDcT1C4D9uiWyN6u27IWe4CPgUzjIdVDIbguLqNBOHa14IoIqKGcAJRqzr imvcwJ06g0atUBDkiOHESxT1z9USNA9xAJWg6T57XQ4zwfPj50+BvT3LYZ8g+Nbf2dXb 2u9dnH6a8Hc8bNPX7fDbc91U2K4ABaPMBsZnkmB/0FNcLKpKeSkB6uwP1oY0PrPDZ1fx O0FuZwGPpSL9mGVm8gAkPAFgMnh8mROtBCbFb+lC+UMJjrv6vh8kgGqo0bK7ke5D9adS t+JA==
X-Gm-Message-State: ALoCoQnx9JkKp4V6HU2qNhNZOHAo4EsaH2ip2qCzEjragKt3ViKLSioRnRAw3ZKfnSPdjgS4kh6S
MIME-Version: 1.0
X-Received: by 10.52.166.6 with SMTP id zc6mr12126431vdb.10.1386272359775; Thu, 05 Dec 2013 11:39:19 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Thu, 5 Dec 2013 11:39:19 -0800 (PST)
X-Originating-IP: [96.49.81.176]
In-Reply-To: <CAO1wJ5S9L=dDZMj5MUfswr7nejC+m5p9EtB+wowb1nCrEreCPw@mail.gmail.com>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com> <3461B710-B969-4315-854B-E2C30B2141FA@tzi.org> <28869F37-1FC4-4F05-A729-DAB14CDA3757@vpnc.org> <6ii1a9lj7ke30himmkc1d31eab0mvv62t8@hive.bjoern.hoehrmann.de> <CAO1wJ5S9L=dDZMj5MUfswr7nejC+m5p9EtB+wowb1nCrEreCPw@mail.gmail.com>
Date: Thu, 5 Dec 2013 11:39:19 -0800
Message-ID: <CAHBU6ivrGdWZQE2tNFs0Y-5JFquHGBZWe9UgEXTX_FTHLerAeQ@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Jacob Davies <jacob@well.com>
Content-Type: multipart/alternative; boundary=001a11c2c54491c3d604ecceaf57
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 19:39:28 -0000

--001a11c2c54491c3d604ecceaf57
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

There=E2=80=99s a lot of history in this list on how we got to where we are=
.  Since
we dropped the top-level restriction to objects/arrays, the assertion that
the first two characters must be ASCII no longer holds, so the table would
have to be reconstructed to handle things like "=DA=83". And that=E2=80=99s=
 not
cost-effective, since nobody ever sends anything but UTF-8 over the wire,
so the whole thing is a red herring.  The spec is more useful the way it is=
.


On Thu, Dec 5, 2013 at 11:35 AM, Jacob Davies <jacob@well.com> wrote:

> Is your concern that the language now says "ignore the BOM" but has no
> other method of determining the encoding of the text? Because yeah.
>
> It seems to me that if you claim to continue to support UTF-16 &
> UTF-32 (which I think is pointless, but anyway) you need some way of
> indicating that. In the absence of the hacky first-two-bytes table
> from the original spec (which doesn't work if you allow strings at the
> top level) then don't you need to support BOMs, rather than ignore
> them?
>
> On Thu, Dec 5, 2013 at 11:28 AM, Bjoern Hoehrmann <derhoermi@gmx.net>
> wrote:
> > * Paul Hoffman wrote:
> >><hat on>
> >>
> >>On Dec 5, 2013, at 12:20 AM, Carsten Bormann <cabo@tzi.org> wrote:
> >>
> >>> Major new bug (apart from the one Rob found):
> >>>
> >>> =E2=80=94 A SHOULD-level requirement for BOM tolerance is a gratuitou=
s change.
>  (I thought we were shooting for a MAY.)
> >>
> >>There was a reasonable number of people who were very concerned that
> >>JSON documents that were being sent around with a BOM would be rejected=
.
> >>
> >>Given the current text:
> >>   Implementations have been observed to generate JSON texts prefixed
> >>   with a Byte Order Mark character.  While this is not allowed by the
> >>   grammar in this specification, in the interests of interoperability
> >>   it is RECOMMENDED that implementations which parse JSON texts ignore
> >>   the presence of a byte order mark rather than treating it as an
> >>   error.
> >>what change would you make?
> >
> > I wanted to make an example to demonstrate how the text above is non-
> > sensical and checked the latest draft to make sure I get it right, only
> > to find that the encoding detection requirements have been removed. I
> > believe my concerns in this area are not receiving due consideration.
> >
> > I am happy to take suggestions about available means of appeal.
> > --
> > Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http:=
//bjoern.hoehrmann.de
> > Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoe=
rnsworld.de
> > 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www=
.websitedev.de/
> > _______________________________________________
> > json mailing list
> > json@ietf.org
> > https://www.ietf.org/mailman/listinfo/json
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>

--001a11c2c54491c3d604ecceaf57
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">There=E2=80=99s a lot of history in this list on how we go=
t to where we are. =C2=A0Since we dropped the top-level restriction to obje=
cts/arrays, the assertion that the first two characters must be ASCII no lo=
nger holds, so the table would have to be reconstructed to handle things li=
ke &quot;=DA=83&quot;. And that=E2=80=99s not cost-effective, since nobody =
ever sends anything but UTF-8 over the wire, so the whole thing is a red he=
rring. =C2=A0The spec is more useful the way it is.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Dec 5=
, 2013 at 11:35 AM, Jacob Davies <span dir=3D"ltr">&lt;<a href=3D"mailto:ja=
cob@well.com" target=3D"_blank">jacob@well.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
Is your concern that the language now says &quot;ignore the BOM&quot; but h=
as no<br>
other method of determining the encoding of the text? Because yeah.<br>
<br>
It seems to me that if you claim to continue to support UTF-16 &amp;<br>
UTF-32 (which I think is pointless, but anyway) you need some way of<br>
indicating that. In the absence of the hacky first-two-bytes table<br>
from the original spec (which doesn&#39;t work if you allow strings at the<=
br>
top level) then don&#39;t you need to support BOMs, rather than ignore<br>
them?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Thu, Dec 5, 2013 at 11:28 AM, Bjoern Hoehrmann &lt;<a href=3D"mailto:der=
hoermi@gmx.net">derhoermi@gmx.net</a>&gt; wrote:<br>
&gt; * Paul Hoffman wrote:<br>
&gt;&gt;&lt;hat on&gt;<br>
&gt;&gt;<br>
&gt;&gt;On Dec 5, 2013, at 12:20 AM, Carsten Bormann &lt;<a href=3D"mailto:=
cabo@tzi.org">cabo@tzi.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; Major new bug (apart from the one Rob found):<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =E2=80=94 A SHOULD-level requirement for BOM tolerance is a gr=
atuitous change. =C2=A0(I thought we were shooting for a MAY.)<br>
&gt;&gt;<br>
&gt;&gt;There was a reasonable number of people who were very concerned tha=
t<br>
&gt;&gt;JSON documents that were being sent around with a BOM would be reje=
cted.<br>
&gt;&gt;<br>
&gt;&gt;Given the current text:<br>
&gt;&gt; =C2=A0 Implementations have been observed to generate JSON texts p=
refixed<br>
&gt;&gt; =C2=A0 with a Byte Order Mark character. =C2=A0While this is not a=
llowed by the<br>
&gt;&gt; =C2=A0 grammar in this specification, in the interests of interope=
rability<br>
&gt;&gt; =C2=A0 it is RECOMMENDED that implementations which parse JSON tex=
ts ignore<br>
&gt;&gt; =C2=A0 the presence of a byte order mark rather than treating it a=
s an<br>
&gt;&gt; =C2=A0 error.<br>
&gt;&gt;what change would you make?<br>
&gt;<br>
&gt; I wanted to make an example to demonstrate how the text above is non-<=
br>
&gt; sensical and checked the latest draft to make sure I get it right, onl=
y<br>
&gt; to find that the encoding detection requirements have been removed. I<=
br>
&gt; believe my concerns in this area are not receiving due consideration.<=
br>
&gt;<br>
&gt; I am happy to take suggestions about available means of appeal.<br>
&gt; --<br>
&gt; Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:<a href=3D"mailto:bjoern@hoehrm=
ann.de">bjoern@hoehrmann.de</a> =C2=B7 <a href=3D"http://bjoern.hoehrmann.d=
e" target=3D"_blank">http://bjoern.hoehrmann.de</a><br>
&gt; Am Badedeich 7 =C2=B7 Telefon: <a href=3D"tel:%2B49%280%29160%2F441568=
1" value=3D"+491604415681">+49(0)160/4415681</a> =C2=B7 <a href=3D"http://w=
ww.bjoernsworld.de" target=3D"_blank">http://www.bjoernsworld.de</a><br>
&gt; 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 <a href=
=3D"http://www.websitedev.de/" target=3D"_blank">http://www.websitedev.de/<=
/a><br>
&gt; _______________________________________________<br>
&gt; json mailing list<br>
&gt; <a href=3D"mailto:json@ietf.org">json@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/json</a><br>
_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
</div></div></blockquote></div><br></div>

--001a11c2c54491c3d604ecceaf57--

From nico@cryptonector.com  Thu Dec  5 11:46:09 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB0D1AE142 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:46:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 rk01x1HdoUhZ for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:46:07 -0800 (PST)
Received: from homiemail-a110.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7511AE100 for <json@ietf.org>; Thu,  5 Dec 2013 11:46:07 -0800 (PST)
Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id C1EBB2005D909; Thu,  5 Dec 2013 11:46:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=VaXuYgwXIQZP88 tu8U/KNztZ21g=; b=Pi2kHkHroY+KW/g0piBinJ12oOmmCyMLdO2u8XFUuGBRVY TYtKHpFzJTKZKrdG4rmGeDxaBfcJnM+1FoyTzNjT80v4ZRYdidHrYFDH+DW65K4k xoTmYKLCMXl+qJcSD61VlKdGXHGQ0aU7v5l8cjX8zbd6As2lGBgc4SXyHCHYo=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPA id 557FF2005D903; Thu,  5 Dec 2013 11:46:03 -0800 (PST)
Date: Thu, 5 Dec 2013 13:46:01 -0600
From: Nico Williams <nico@cryptonector.com>
To: Jacob Davies <jacob@well.com>
Message-ID: <20131205194558.GV21240@localhost>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com> <3461B710-B969-4315-854B-E2C30B2141FA@tzi.org> <28869F37-1FC4-4F05-A729-DAB14CDA3757@vpnc.org> <6ii1a9lj7ke30himmkc1d31eab0mvv62t8@hive.bjoern.hoehrmann.de> <CAO1wJ5S9L=dDZMj5MUfswr7nejC+m5p9EtB+wowb1nCrEreCPw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAO1wJ5S9L=dDZMj5MUfswr7nejC+m5p9EtB+wowb1nCrEreCPw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 19:46:10 -0000

On Thu, Dec 05, 2013 at 11:35:17AM -0800, Jacob Davies wrote:
> Is your concern that the language now says "ignore the BOM" but has no
> other method of determining the encoding of the text? Because yeah.
> 
> It seems to me that if you claim to continue to support UTF-16 &
> UTF-32 (which I think is pointless, but anyway) you need some way of
> indicating that. In the absence of the hacky first-two-bytes table
> from the original spec (which doesn't work if you allow strings at the
> top level) then don't you need to support BOMs, rather than ignore
> them?

Starting with at least one ASCII character (which JSON texts will
continue to do) is sufficient to determine which of UTF-8/16/32 is used
and byte order.  The table is unnecessary: programmers can figure it
out.

BOMs are therefore unnecessary.  I get that some implementations send
it.  I *feel* that the best thing to do would be to be silent as to
BOMs, but if we must say something we should say that parsers MUST
ignore BOMs and encoders SHOULD NOT include BOMs.

Nico
-- 

From allen@wirfs-brock.com  Thu Dec  5 11:51:25 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439241AE026 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:51:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
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 Ahbv2ZfGmPZ8 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:51:21 -0800 (PST)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id AB2121AE0DE for <json@ietf.org>; Thu,  5 Dec 2013 11:51:21 -0800 (PST)
Received: from [192.168.0.15] (069-064-236-244.pdx.net [69.64.236.244]) (Authenticated sender: allenwb@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id C839FF2255; Thu,  5 Dec 2013 11:51:16 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-160--56020837
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org>
Date: Thu, 5 Dec 2013 11:51:12 -0800
Message-Id: <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.1085)
Cc: "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 19:51:25 -0000

--Apple-Mail-160--56020837
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Dec 4, 2013, at 11:39 PM, Carsten Bormann wrote:

> On 05 Dec 2013, at 06:08, Tim Bray <tbray@textuality.com> wrote:
>=20
>> FWIW, I have never understood what the ECMAnauts mean by the word =
=93semantics=94 in this context, so I have no idea whether I agree with =
this statement.

As one of the contributors to ECMA-404 I'd be happy to elaborate

>=20
> You know this, but just for the record: we could be applying the =
meaning we have for these terms in CS.

Yes, that is indeed the starting point.  However, TC39 is largely =
composed of language designers and language implementors so the meaning =
of "semantics" we use is generally the one used within that branch of =
CS.

>=20
> The syntax just tells you which sequences of symbols are part of the =
language.
> (This is what we have ABNF for; ECMA-404 uses racetracks plus some =
English language that maps the characters to the tokens in the =
syntax-level racetracks for value, object, and array, and to the English =
language components of the token-level racetracks for number and =
string.)

Agreed.  I would state this as:  the syntax tells you which sequences of =
symbols form valid statements within the language.

Language designer also use the term "static semantics".  The static =
semantics of a language are a set of rules that further restrict  which =
sequences of symbols form valid statements within the language.  For =
example, a rule that the 'member' names must be disjoint within an =
'object' production could be a static semantic rule (however, there is =
intentionally no such rule in ECMA-404).

The line between syntax and static semantics can be fuzzy.  Static =
semantic rules are typically used to express rules that cannot be =
technically expressed using the chosen syntactic formalism or rules =
which are simply inconvenient to express using that formalism.  For =
example, the editor of ECMA-404 chose to simplify the RR track =
expression of the JSON syntax by using static semantic rules for =
whitespace rather than incorporating them into RR diagrams.=20

Another form of static semantic rules are equivalences that state when =
two or more different sequences of symbols must be considered as =
equivalent.  For example, the rules that state equivalencies between =
escape sequences and individual code points within an JSON 'string'.  =
Such equivalences are not strictly necessary at this level, but it it =
simplifies the specification of higher level semantics if equivalent =
symbol sequences can be normalized at this level of specification.

When we talk about the "semantics" of a language (rather than "static =
semantics") we are talking about attributing meaning (in some domain and =
context) to well-formed (as specified via syntax and static semantics) =
statements expressed in that language.

ECMA-404 intentionally restricts itself to specify the syntax and static =
semantics of the JSON language.  More below on why.

>=20
> Semantics is needed to describe e.g. that some whitespace is =
=93insignificant=94 (not contributing to the semantics), describe the =
intended interpretation of escape sequences in strings,
Yes these are static semantic rules (although whitespace rules could be =
expressed using syntactic formalisms).

> that the sequences of symbols enabled by the production =93number=94 =
are to be interpreted in base 10,
Yes, ECMA-404 includes this as a static semantic statement although it =
is arguably could be classified as a semantic statement above the level =
of static semantics.  Whether "77" is semantically interpreted as the =
mathematical value 63 or 77 isn't really relevant to whether "77" is a =
well-formed JSON number.

> or that =93the order of the values is significant=94 in arrays (which =
seems to be intended to contrast them to JSON objects, where ECMA-404 =
weasels out of saying whether the order is significant).

ECMA-404 removed the statement "an object is an unordered collection..." =
that exists in RFC-6427.  Arguably, ECMA-404 should not have made the =
statement "the the order of values is significant" WRT arrays.  I'll =
file a bug ticket on that.  The reason that neither of these statements =
is appropriate at this level of specification is that they are pure =
semantic statements that have no impact upon determining whether a =
sequence of symbols are well-formed JSON text.

Objectively, the members of a JSON 'object' do occur in a specific order =
and a semantic interpreter of an object might ascribe meaning to that =
ordering.  Similarly, a JSON 'array' also has an objectively observable =
ordering of its contained values. It is again up to a semantic =
interpreter as to whether or not it ascribes meaning to that ordering.

>=20
> ECMA-404 does quite a bit of of the latter, so indeed I also have =
trouble interpreting such a statement.

So back to "semantics" and why ECMA-404 tries (perhaps imperfectly) to =
avoid describing JSON beyond the level of static semantics.=20

ECMA-404 see JSON as "a text format that facilitates structured data =
interchange between all programming languages. JSON
is syntax of braces, brackets, colons, and commas that is useful in many =
contexts, profiles, and applications".

There are many possible semantics and categories of semantics that can =
be applied to well-formed statements expressed using the JSON syntax.

One type of semantics are language bindings that specify how a JSON text =
might be translated into the data types and structures of some =
particular programming language or runtime environment. The translation =
of a JavaScript string encoding of a JSON text into JavaScript objects =
and values by JSON.parse is one specific example of this kind of =
semantic application of JSON.  But there are many languages that can be =
supported by such language bindings and there is not necessarily a best =
or canonical JSON binding for any language.

Another form of semantics imposes schema based meaning and restrictions =
upon a well-formed JSON text.  A schema explicitly defines an =
application level  meaning to the elements for some specific subset of =
well-formed SON texts. It might require only certain forms of JSON =
values, provide specific meaning to JSON numbers or strings that occur =
in specified positions, require the occurrence of certain object =
members, apply meaning to the ordering of object members or array =
elements, etc. This is probably  most common form of semantics applied =
to JSON and is used by almost all real world JSON use cases.

The problem with trying to standardize JSON semantics is that the =
various semantics that can be usefully be imposed upon JSON are often =
mutually incompatible with each other. At a trivial level, we see this =
with issues like the size of numbers or duplicate object member keys.  =
It is very hard to decide whose semantics are acceptable and whose is =
not.

What we can do, is draw a bright-line just above the level of static =
semantics.This is what ECMA-404 attempts to do. If defines a small set =
of structuring elements that can be recursively composed and represent =
in a textual encoding. It provides a common vocabulary upon which =
various semantics can be overlaid and nothing else.  The intent of =
ECMA-404 is to provide the definitive specification of the syntax and =
static semantic of the JSON format that can be used by higher level =
semantic specifications.

Allen Wirfs-Brock
ECMA-262 project editor=

--Apple-Mail-160--56020837
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Dec 4, 2013, at 11:39 PM, Carsten Bormann =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>On 05 Dec 2013, at 06:08, Tim Bray &lt;<a =
href=3D"mailto:tbray@textuality.com">tbray@textuality.com</a>&gt; =
wrote:<br><br><blockquote type=3D"cite">FWIW, I have never understood =
what the ECMAnauts mean by the word =93semantics=94 in this context, so =
I have no idea whether I agree with this =
statement.<br></blockquote></div></blockquote><div><br></div><div>As one =
of the contributors to ECMA-404 I'd be happy to =
elaborate</div><div><br></div><blockquote type=3D"cite"><div><br>You =
know this, but just for the record: we could be applying the meaning we =
have for these terms in =
CS.<br></div></blockquote><div><br></div><div>Yes, that is indeed the =
starting point. &nbsp;However, TC39 is largely composed of language =
designers and language implementors so the meaning of "semantics" we use =
is generally the one used within that branch of =
CS.</div><div><br></div><blockquote type=3D"cite"><div><br>The syntax =
just tells you which sequences of symbols are part of the =
language.<br>(This is what we have ABNF for; ECMA-404 uses racetracks =
plus some English language that maps the characters to the tokens in the =
syntax-level racetracks for value, object, and array, and to the English =
language components of the token-level racetracks for number and =
string.)<br></div></blockquote><div><br></div><div>Agreed. &nbsp;I would =
state this as: &nbsp;the syntax tells you which sequences of symbols =
form valid statements within the =
language.</div><div><br></div><div>Language designer also use the term =
"static semantics". &nbsp;The static semantics of a language are a set =
of rules that further restrict &nbsp;which sequences of symbols form =
valid statements within the language. &nbsp;For example, a rule that the =
'member' names must be disjoint within an 'object' production could be a =
static semantic rule (however, there is intentionally no such rule in =
ECMA-404).</div><div><br></div><div>The line between syntax and static =
semantics can be fuzzy. &nbsp;Static semantic rules are typically used =
to express rules that cannot be technically expressed using the chosen =
syntactic formalism or rules which are simply inconvenient to express =
using that formalism. &nbsp;For example, the editor of ECMA-404 chose to =
simplify the RR track expression of the JSON syntax by using static =
semantic rules for whitespace rather than incorporating them into RR =
diagrams.&nbsp;</div><div><br></div><div>Another form of static semantic =
rules are equivalences that state when two or more different sequences =
of symbols must be considered as equivalent. &nbsp;For example, the =
rules that state equivalencies between escape sequences and individual =
code points within an JSON 'string'. &nbsp;Such equivalences are not =
strictly necessary at this level, but it it simplifies the specification =
of higher level semantics if equivalent symbol sequences can be =
normalized at this level of specification.</div><div><br></div><div>When =
we talk about the "semantics" of a language (rather than "static =
semantics") we are talking about attributing meaning (in some domain and =
context) to well-formed (as specified via syntax and static semantics) =
statements expressed in that language.</div><div><br></div><div>ECMA-404 =
intentionally restricts itself to specify the syntax and static =
semantics of the JSON language. &nbsp;More below on =
why.</div><div><br></div><blockquote =
type=3D"cite"><div><br></div></blockquote><blockquote =
type=3D"cite"><div>Semantics is needed to describe e.g. that some =
whitespace is =93insignificant=94 (not contributing to the semantics), =
describe the intended interpretation of escape sequences in strings, =
</div></blockquote><div>Yes these are static semantic rules (although =
whitespace rules could be expressed using syntactic =
formalisms).</div><br><blockquote type=3D"cite"><div>that the sequences =
of symbols enabled by the production =93number=94 are to be interpreted =
in base 10, </div></blockquote>Yes, ECMA-404 includes this as a static =
semantic statement although it is arguably could be classified as a =
semantic statement above the level of static semantics. &nbsp;Whether =
"77" is semantically interpreted as the mathematical value 63 or 77 =
isn't really relevant to whether "77" is a well-formed JSON =
number.<br><div><br></div><blockquote type=3D"cite"><div>or that =93the =
order of the values is significant=94 in arrays (which seems to be =
intended to contrast them to JSON objects, where ECMA-404 weasels out of =
saying whether the order is =
significant).<br></div></blockquote><div><br></div><div>ECMA-404 removed =
the statement "an object is an unordered collection..." that exists in =
RFC-6427. &nbsp;Arguably, ECMA-404 should not have made the statement =
"the the order of values is significant" WRT arrays. &nbsp;I'll file a =
bug ticket on that. &nbsp;The reason that neither of these statements is =
appropriate at this level of specification is that they are pure =
semantic statements that have no impact upon determining whether a =
sequence of symbols are well-formed JSON =
text.</div><div><br></div><div>Objectively, the members of a JSON =
'object' do occur in a specific order and a semantic interpreter of an =
object might ascribe meaning to that ordering. &nbsp;Similarly, a JSON =
'array' also has an objectively observable ordering of its contained =
values. It is again up to a semantic interpreter as to whether or not it =
ascribes meaning to that ordering.</div><div><br></div><blockquote =
type=3D"cite"><div><br>ECMA-404 does quite a bit of of the latter, so =
indeed I also have trouble interpreting such a =
statement.<br></div></blockquote><div><br></div><div>So back to =
"semantics" and why ECMA-404 tries (perhaps imperfectly) to avoid =
describing JSON beyond the level of static =
semantics.&nbsp;</div><div><br></div><div>ECMA-404 see JSON as "<span =
class=3D"Apple-style-span" style=3D"font-family: sans-serif; font-size: =
13px; ">a text format that facilitates structured data =
intercha</span><span class=3D"Apple-style-span" style=3D"font-family: =
sans-serif; font-size: 13px; ">nge between all programming languages. =
JSON</span></div><div dir=3D"ltr" style=3D"font-size: 13.28px; =
font-family: sans-serif; left: 49.12px; top: 240.507px; transform: =
rotate(0deg) scale(1.02235, 1); transform-origin: 0% 0% 0px;" =
data-angle=3D"0" data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"652.9908994606445">is syntax of braces, brackets, =
colons, and commas that is useful in many contexts, profiles, and =
applications".</div><div dir=3D"ltr" style=3D"font-size: 13.28px; =
font-family: sans-serif; left: 49.12px; top: 240.507px; transform: =
rotate(0deg) scale(1.02235, 1); transform-origin: 0% 0% 0px;" =
data-angle=3D"0" data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"652.9908994606445"><br></div><div dir=3D"ltr" =
style=3D"font-size: 13.28px; font-family: sans-serif; left: 49.12px; =
top: 240.507px; transform: rotate(0deg) scale(1.02235, 1); =
transform-origin: 0% 0% 0px;" data-angle=3D"0" =
data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"652.9908994606445">There are many possible =
semantics and categories of semantics that can be applied to well-formed =
statements expressed using the JSON syntax.</div><div dir=3D"ltr" =
style=3D"font-size: 13.28px; font-family: sans-serif; left: 49.12px; =
top: 240.507px; transform: rotate(0deg) scale(1.02235, 1); =
transform-origin: 0% 0% 0px;" data-angle=3D"0" =
data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"652.9908994606445"><br></div><div dir=3D"ltr" =
style=3D"font-size: 13.28px; font-family: sans-serif; left: 49.12px; =
top: 240.507px; transform: rotate(0deg) scale(1.02235, 1); =
transform-origin: 0% 0% 0px;" data-angle=3D"0" =
data-font-name=3D"g_font_5_0" data-canvas-width=3D"652.9908994606445">One =
type of semantics are language bindings that specify how a JSON text =
might be translated into the data types and structures of some =
particular programming language or runtime environment. The translation =
of a JavaScript string encoding of a JSON text into JavaScript objects =
and values by JSON.parse is one specific example of this kind of =
semantic application of JSON. &nbsp;But there are many languages that =
can be supported by such language bindings and there is not necessarily =
a best or canonical JSON binding for any language.</div><div dir=3D"ltr" =
style=3D"font-size: 13.28px; font-family: sans-serif; left: 49.12px; =
top: 240.507px; transform: rotate(0deg) scale(1.02235, 1); =
transform-origin: 0% 0% 0px;" data-angle=3D"0" =
data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"652.9908994606445"><br></div><div dir=3D"ltr" =
style=3D"font-size: 13.28px; font-family: sans-serif; left: 49.12px; =
top: 240.507px; transform: rotate(0deg) scale(1.02235, 1); =
transform-origin: 0% 0% 0px;" data-angle=3D"0" =
data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"652.9908994606445">Another form of semantics =
imposes schema based meaning and restrictions upon a well-formed JSON =
text. &nbsp;A schema explicitly defines an application level =
&nbsp;meaning to the elements for some specific subset of well-formed =
SON texts. It might require only certain forms of JSON values, provide =
specific meaning to JSON numbers or strings that occur in specified =
positions, require the occurrence of certain object members, apply =
meaning to the ordering of object members or array elements, etc. This =
is probably &nbsp;most common form of semantics applied to JSON and is =
used by almost all real world JSON use cases.</div><div dir=3D"ltr" =
style=3D"font-size: 13.28px; font-family: sans-serif; left: 49.12px; =
top: 240.507px; transform: rotate(0deg) scale(1.02235, 1); =
transform-origin: 0% 0% 0px;" data-angle=3D"0" =
data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"652.9908994606445"><br></div><div dir=3D"ltr" =
style=3D"font-size: 13.28px; font-family: sans-serif; left: 49.12px; =
top: 240.507px; transform: rotate(0deg) scale(1.02235, 1); =
transform-origin: 0% 0% 0px;" data-angle=3D"0" =
data-font-name=3D"g_font_5_0" data-canvas-width=3D"652.9908994606445">The =
problem with trying to standardize JSON semantics is that the various =
semantics that can be usefully be imposed upon JSON are often mutually =
incompatible with each other. At a trivial level, we see this with =
issues like the size of numbers or duplicate object member keys. =
&nbsp;It is very hard to decide whose semantics are acceptable and whose =
is not.</div><div dir=3D"ltr" style=3D"font-size: 13.28px; font-family: =
sans-serif; left: 49.12px; top: 240.507px; transform: rotate(0deg) =
scale(1.02235, 1); transform-origin: 0% 0% 0px;" data-angle=3D"0" =
data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"652.9908994606445"><br></div><div dir=3D"ltr" =
style=3D"font-size: 13.28px; font-family: sans-serif; left: 49.12px; =
top: 240.507px; transform: rotate(0deg) scale(1.02235, 1); =
transform-origin: 0% 0% 0px;" data-angle=3D"0" =
data-font-name=3D"g_font_5_0" data-canvas-width=3D"652.9908994606445">What=
 we can do, is draw a bright-line just above the level of static =
semantics.This is what ECMA-404 attempts to do. If defines a small set =
of structuring elements that can be recursively composed and represent =
in a textual encoding. It provides a common vocabulary upon which =
various semantics can be overlaid and nothing else. &nbsp;The intent of =
ECMA-404 is to provide the definitive specification of the syntax and =
static semantic of the JSON format that can be used by higher level =
semantic specifications.</div><div dir=3D"ltr" style=3D"font-size: =
13.28px; font-family: sans-serif; left: 49.12px; top: 240.507px; =
transform: rotate(0deg) scale(1.02235, 1); transform-origin: 0% 0% 0px;" =
data-angle=3D"0" data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"652.9908994606445"><br></div><div dir=3D"ltr" =
style=3D"font-size: 13.28px; font-family: sans-serif; left: 49.12px; =
top: 240.507px; transform: rotate(0deg) scale(1.02235, 1); =
transform-origin: 0% 0% 0px;" data-angle=3D"0" =
data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"652.9908994606445">Allen Wirfs-Brock</div><div =
dir=3D"ltr" style=3D"font-size: 13.28px; font-family: sans-serif; left: =
49.12px; top: 240.507px; transform: rotate(0deg) scale(1.02235, 1); =
transform-origin: 0% 0% 0px;" data-angle=3D"0" =
data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"652.9908994606445">ECMA-262 project =
editor</div></div></body></html>=

--Apple-Mail-160--56020837--

From derhoermi@gmx.net  Thu Dec  5 11:54:09 2013
Return-Path: <derhoermi@gmx.net>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379CB1AD947 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:54:09 -0800 (PST)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 d4M0HW-fwcu4 for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 11:54:06 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id AB7611A802A for <json@ietf.org>; Thu,  5 Dec 2013 11:54:03 -0800 (PST)
Received: from netb.Speedport_W_700V ([91.35.7.188]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MCL6r-1VgAYI2ViD-0095Iv for <json@ietf.org>; Thu, 05 Dec 2013 20:53:59 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Carsten Bormann <cabo@tzi.org>
Date: Thu, 05 Dec 2013 20:54:02 +0100
Message-ID: <cil1a9hjeto50m2vfgdi8s2d7nrgp6mtvn@hive.bjoern.hoehrmann.de>
References: <E20F62B4-7F96-42F6-98CC-E560D81A44AC@vpnc.org> <850EC0FE-F009-47A6-9C62-9D4394B7C29B@tzi.org>
In-Reply-To: <850EC0FE-F009-47A6-9C62-9D4394B7C29B@tzi.org>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:X9dYVPoYtL8xCym2PGo9KFuKdtQBtyc+9dGITwFlC0cHg/J97oM cGrXIxrvz+h5QPQ+Zk66dzE6ojYDzQYQw1TcVqBH5uJXLoYSOfuFWERFjtXodyKEh+849Qu LOX3hRYEnELaXnUMm1zf2xCkYNh5leJR1gywxKKTRWGIH0Q3GtM8spKCiTH4i7ruUl6Q1CX RLcaqKIVJpb9KVzUvmINw==
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] That encoding thing
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 19:54:09 -0000

* Carsten Bormann wrote:
>On 05 Dec 2013, at 19:54, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>
>> The following is technically correct and should at least partially appease the pedants among us. 
>> 
>> s/JSON text SHALL be encoded in Unicode./JSON text SHALL be encoded in one of the character encoding schemes defined by Unicode./
>
>Both statements are technically correct (unless read with —pedantic).  
>The second statement says less than the first.  I don’t think that 
>change is intended.  We are not only importing the CES from Unicode.  
>(Now that attention to detail may be pedantic in its own right, sorry 
>about that, but I’m again trying to anticipate how this will be read.)

It is necessary to enumerate the encodings because "Unicode" defines
character encoding schemes that cannot be used for application/json
under the rules of RFC 4627. An example is CESU-8. In effect the text
should say that an application/json entity is malformed unless it is a
properly encoded string in UTF-8/UTF-16LE/UTF-16BE/UTF-32LE/UTF-32BE
as far as the rules in RFC 4627 go.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From derhoermi@gmx.net  Thu Dec  5 12:10:42 2013
Return-Path: <derhoermi@gmx.net>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBA91AE13E for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 12:10:42 -0800 (PST)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 ethSLurEuBiu for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 12:10:39 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id EE1431AD947 for <json@ietf.org>; Thu,  5 Dec 2013 12:10:38 -0800 (PST)
Received: from netb.Speedport_W_700V ([91.35.7.188]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0MXllr-1W3jYL0LPL-00WoYl for <json@ietf.org>; Thu, 05 Dec 2013 21:10:34 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Date: Thu, 05 Dec 2013 21:10:36 +0100
Message-ID: <89n1a9d46vtku9uqhcim6ssg43muth7h1g@hive.bjoern.hoehrmann.de>
References: <5281D65E.1080405@gmx.de> <52A0AA7A.3010507@gmx.de> <EA0623CC-2842-4203-80F0-0E940498A870@tzi.org> <561A6BF9-84D5-4C12-91A3-B511CA5FFE5D@vpnc.org>
In-Reply-To: <561A6BF9-84D5-4C12-91A3-B511CA5FFE5D@vpnc.org>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:WgBrclu0TbbeI4MA9eCeV2qC2UG8TCj0tDom/kI3dtaedLdiuv3 tlcacyKOWipXxA50DivMhMD0iRhcEtzxdA4RWhL+ew3W+vhRORrbVKkITPEIFHYQi5aj4Ef L5qDVXkDtVg7nsIDIPBbKenNErX6L18SnbBU/gscGHzvbO4sUoldK7wkZ9L3xbYMA71uql1 PankJcfsJiZbBJy8G6MXQ==
Cc: Tim Bray <tbray@textuality.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] LC comment on http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-07#section-11
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 20:10:42 -0000

* Paul Hoffman wrote:
><hat on>
>
>Tim: please add the following to the end of Section 11.
>
>   Note: no "charset" parameter is defined for this registration.
>   Adding one really has no effect on compliant recipients.

I think such a statement is not supported by the requirements in the
specification. It would have to say that is incorrect to use the value
of a charset parameter to determine the encoding of the document.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From derhoermi@gmx.net  Thu Dec  5 16:27:45 2013
Return-Path: <derhoermi@gmx.net>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517B01AE16F for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 16:27:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level: 
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 hZhwtvtccs0A for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 16:27:43 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 750201AE082 for <json@ietf.org>; Thu,  5 Dec 2013 16:27:43 -0800 (PST)
Received: from netb.Speedport_W_700V ([91.35.7.188]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0Mh9cj-1WAVEx1VSL-00MPFG for <json@ietf.org>; Fri, 06 Dec 2013 01:27:38 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Jacob Davies <jacob@well.com>
Date: Fri, 06 Dec 2013 01:27:40 +0100
Message-ID: <7r12a9pnuh2f5bf662k8dlfmiunsqkf49q@hive.bjoern.hoehrmann.de>
References: <20131205020911.25035.18142.idtracker@ietfa.amsl.com> <CAHBU6ivc-Jewruz4GYsYC3R0K5-tneMp20fRYv13j8ii+CZS2Q@mail.gmail.com> <3461B710-B969-4315-854B-E2C30B2141FA@tzi.org> <28869F37-1FC4-4F05-A729-DAB14CDA3757@vpnc.org> <6ii1a9lj7ke30himmkc1d31eab0mvv62t8@hive.bjoern.hoehrmann.de> <CAO1wJ5S9L=dDZMj5MUfswr7nejC+m5p9EtB+wowb1nCrEreCPw@mail.gmail.com>
In-Reply-To: <CAO1wJ5S9L=dDZMj5MUfswr7nejC+m5p9EtB+wowb1nCrEreCPw@mail.gmail.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:yjVj3efKrTky6HUx37cicpxYdgQR+TRo7yCEH/Cg9luLuNC9sXA tHyNqX6Zu0bq2nEDS8TEd1aVbeLE5xo279oe0NPchrq3TtKNnnGS4qoETqT6cQp5/MDJbnh XNHvm6jMYuTsWmpXNxLhlHHdxZqnbnUYB14MdrXCo8n+rQE4Jz2R9zt4Xr92E71bg/aO6/N bFIRkhYP4wV3LHquKkckw==
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] New Version Notification - draft-ietf-json-rfc4627bis-08.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 00:27:45 -0000

* Jacob Davies wrote:
>Is your concern that the language now says "ignore the BOM" but has no
>other method of determining the encoding of the text? Because yeah.
>
>It seems to me that if you claim to continue to support UTF-16 &
>UTF-32 (which I think is pointless, but anyway) you need some way of
>indicating that. In the absence of the hacky first-two-bytes table
>from the original spec (which doesn't work if you allow strings at the
>top level) then don't you need to support BOMs, rather than ignore
>them?

Say you have two application/json processors and pass them the same byte
sequence and one says "Oh, it's an array with no members" and the other
says "No, it's an object with no members". Some argue that there should
be no mandatory-to-implement mechanism to tell arrays and objects in
application/json entities apart. Without such a mechanism, it would not
be possible to consult the application/json specification and determine
whether the byte sequence represents `{}` or `[]`, and in fact both pro-
cessors may be fully conforming. I think that's bad for interoperability
and may open up attack vectors in systems when they process maliciously
crafted input. As an example,

  data:application/json,+AFsAXQ-

If an implementation treats that as `[]` then it fully conforms with all
requirements in draft-ietf-json-rfc4627bis-08 and so does the entity, it
is "encoded in Unicode", specifically, in UTF-7. Another example:

  data:application/json,+/v8-...

This is a UTF-7 encoded document that starts with a U+FEFF character. Is
that a "Byte Order Mark character" that should be ignored? It might seem
silly to assume UTF-7 but web browsers and mail clients used to do silly
things like that. Another funny Unicode encoding is CESU-8. Is it okay
to generate CESU-8 encoded application/json entities? To parse them as
if they were CESU-8 encoded? That might seem crazy, but

  https://code.google.com/p/v8/issues/detail?id=2875

such is the world of character encodings. With a mandatory-to-implement
encoding detection mechanism others might not repeat Google's mistakes.

As for Unicode signatures, I am not aware anything has changed since

  http://www.ietf.org/mail-archive/web/json/current/msg02044.html

I also do not understand what is being proposed. As an example, I can't
tell whether under the rules in draft-ietf-json-rfc4627bis-08

  data:application/json,%FE%FF...

implementations "SHOULD" use the initial byte sequence to determine the
encoding, and if so, how that is consistent with the idea to remove the
mandatory-to-implement encoding detection mechanism. As I pointed out in

  http://www.ietf.org/mail-archive/web/json/current/msg01983.html

implementations do not actually do this. Why require something that is
not needed and not useful and not actually done in practise?
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From cabo@tzi.org  Thu Dec  5 22:15:00 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F391A1AE2CF for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 22:14:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 DANx5LTWPu4H for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 22:14:58 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 465AE1AE2C8 for <json@ietf.org>; Thu,  5 Dec 2013 22:14:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB66EmT7024387; Fri, 6 Dec 2013 07:14:48 +0100 (CET)
Received: from [192.168.217.105] (p54890AEF.dip0.t-ipconnect.de [84.137.10.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 29AC0F41; Fri,  6 Dec 2013 07:14:48 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <cil1a9hjeto50m2vfgdi8s2d7nrgp6mtvn@hive.bjoern.hoehrmann.de>
Date: Fri, 6 Dec 2013 07:14:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C95E1028-8164-4FD0-B682-C4205E0E34F9@tzi.org>
References: <E20F62B4-7F96-42F6-98CC-E560D81A44AC@vpnc.org> <850EC0FE-F009-47A6-9C62-9D4394B7C29B@tzi.org> <cil1a9hjeto50m2vfgdi8s2d7nrgp6mtvn@hive.bjoern.hoehrmann.de>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
X-Mailer: Apple Mail (2.1822)
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] That encoding thing
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 06:15:00 -0000

On 05 Dec 2013, at 20:54, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

> It is necessary to enumerate the encodings because "Unicode" defines
> character encoding schemes that cannot be used for application/json
> under the rules of RFC 4627. An example is CESU-8.

Well, the Unicode standard doesn=92t define them, but there are UTRs =
that do.
Certainly, neither UTF-EBCDIC nor CESU-8 are valid CES for JSON =
interchange, and I agree this needs to be more explicit.

> In effect the text
> should say that an application/json entity is malformed unless it is a
> properly encoded string in UTF-8/UTF-16LE/UTF-16BE/UTF-32LE/UTF-32BE
> as far as the rules in RFC 4627 go.

Indeed.  RFC 4627 says so in section 3, and we seem to have lost this =
information.  (The important observation is that only five out of the =
seven CES of Unicode are explicitly supported, even though the text =
elsewhere sloppily talks about the other two, UTF-16 and UTF-32, =
apparently meaning =93UTF-16BE or UTF-16LE=94 and =93UTF-32BE or =
UTF-32LE=94, respectively.  This is all moot in practice where only =
UTF-8 is used, but important to the language lawyers.)

Gr=FC=DFe, Carsten


From duerst@it.aoyama.ac.jp  Thu Dec  5 22:20:34 2013
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEBB1AE2ED for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 22:20:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level: 
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=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 d8-5ZsyKMVcs for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 22:20:32 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id D8A0F1AE2EB for <json@ietf.org>; Thu,  5 Dec 2013 22:20:31 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rB66KIdn012848; Fri, 6 Dec 2013 15:20:18 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 0421_a883_7a0ba29c_5e3e_11e3_a918_001e6722eec2; Fri, 06 Dec 2013 15:20:17 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 5E780BF4DD; Fri,  6 Dec 2013 15:20:17 +0900 (JST)
Message-ID: <52A16C91.2040802@it.aoyama.ac.jp>
Date: Fri, 06 Dec 2013 15:20:01 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Bjoern Hoehrmann <derhoermi@gmx.net>
References: <E20F62B4-7F96-42F6-98CC-E560D81A44AC@vpnc.org> <850EC0FE-F009-47A6-9C62-9D4394B7C29B@tzi.org> <cil1a9hjeto50m2vfgdi8s2d7nrgp6mtvn@hive.bjoern.hoehrmann.de>
In-Reply-To: <cil1a9hjeto50m2vfgdi8s2d7nrgp6mtvn@hive.bjoern.hoehrmann.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: Carsten Bormann <cabo@tzi.org>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] That encoding thing
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 06:20:34 -0000

On 2013/12/06 4:54, Bjoern Hoehrmann wrote:
> * Carsten Bormann wrote:
>> On 05 Dec 2013, at 19:54, Paul Hoffman<paul.hoffman@vpnc.org>  wrote:
>>
>>> The following is technically correct and should at least partially ap=
pease the pedants among us.
>>>
>>> s/JSON text SHALL be encoded in Unicode./JSON text SHALL be encoded i=
n one of the character encoding schemes defined by Unicode./

I think this change is a significant and necessary improvement. But it=20
seems both Carsten and Bj=C3=B6rn disagree. I think this may be because=20
"character encoding schemes defined by Unicode" is still slightly=20
ambiguous (because it's circumscriptive, rather than using an=20
established term). I propose to change this to:

JSON text SHALL be encoded in one of the Unicode Encoding Schemes.
(see Section 2.6 of Unicode 6.3=20
(http://www.unicode.org/versions/Unicode6.2.0/ch02.pdf))

This will clearly exclude CESU-8 and UTF-7, as desired.

Regards,   Martin.

>> Both statements are technically correct (unless read with =E2=80=94ped=
antic).
>> The second statement says less than the first.  I don=E2=80=99t think =
that
>> change is intended.  We are not only importing the CES from Unicode.
>> (Now that attention to detail may be pedantic in its own right, sorry
>> about that, but I=E2=80=99m again trying to anticipate how this will b=
e read.)
>
> It is necessary to enumerate the encodings because "Unicode" defines
> character encoding schemes that cannot be used for application/json
> under the rules of RFC 4627. An example is CESU-8. In effect the text
> should say that an application/json entity is malformed unless it is a
> properly encoded string in UTF-8/UTF-16LE/UTF-16BE/UTF-32LE/UTF-32BE
> as far as the rules in RFC 4627 go.

From cabo@tzi.org  Thu Dec  5 23:35:12 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EE71AE2FF for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 23:35:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.951
X-Spam-Level: 
X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_45=0.6, SPF_HELO_PASS=-0.001] autolearn=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 QS9KtM8gQ7WZ for <json@ietfa.amsl.com>; Thu,  5 Dec 2013 23:35:09 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 276031A1F5E for <json@ietf.org>; Thu,  5 Dec 2013 23:35:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB67Yt8s005030; Fri, 6 Dec 2013 08:34:55 +0100 (CET)
Received: from [192.168.217.105] (p54890AEF.dip0.t-ipconnect.de [84.137.10.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AA0A5F7C; Fri,  6 Dec 2013 08:34:53 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com>
Date: Fri, 6 Dec 2013 08:34:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 07:35:12 -0000

Allen,

thank you a lot for this elaborate response.  It really helps me =
understand the different points of view that have emerged.  I=92ll go =
ahead and insert my personal point of view in this response to maybe =
make that more understandable as well (I=92m not speaking for the JSON =
WG at all here, of course).  Maybe you can relay this to es-discuss so =
both mailing lists benefit from it.

>> The syntax just tells you which sequences of symbols are part of the =
language.
>> (This is what we have ABNF for; ECMA-404 uses racetracks plus some =
English language that maps the characters to the tokens in the =
syntax-level racetracks for value, object, and array, and to the English =
language components of the token-level racetracks for number and =
string.)
>=20
> Agreed.  I would state this as:  the syntax tells you which sequences =
of symbols form valid statements within the language.
>=20
> Language designer also use the term "static semantics".  The static =
semantics of a language are a set of rules that further restrict  which =
sequences of symbols form valid statements within the language.=20

Right, the "static semantics" is used to form a subset of what we =
arbitrarily call =93syntax=94, further restricting what sequence of =
symbols is in the language.=20

>  For example, a rule that the 'member' names must be disjoint within =
an 'object' production could be a static semantic rule (however, there =
is intentionally no such rule in ECMA-404).

Thanks, it is interesting to hear that this was a deliberate omission.

> The line between syntax and static semantics can be fuzzy.  Static =
semantic rules are typically used to express rules that cannot be =
technically expressed using the chosen syntactic formalism or rules =
which are simply inconvenient to express using that formalism.  For =
example, the editor of ECMA-404 chose to simplify the RR track =
expression of the JSON syntax by using static semantic rules for =
whitespace rather than incorporating them into RR diagrams.=20

No, that isn=92t static semantics.  The racetracks don=92t have a useful =
meaning (i.e., express a different, more restricted syntax) without the =
English language rules about whitespace,  (More specifically, three of =
the racetracks operate on a different domain than the other two, without =
that having made explicit.)  Static semantics can only serve to restrict =
the set of syntactically valid symbol sequences.  Accepting whitespace =
is on the syntax level.  (Then ignoring it is indeed semantics.)

> Another form of static semantic rules are equivalences that state when =
two or more different sequences of symbols must be considered as =
equivalent.  For example, the rules that state equivalencies between =
escape sequences and individual code points within an JSON 'string'.  =
Such equivalences are not strictly necessary at this level, but it it =
simplifies the specification of higher level semantics if equivalent =
symbol sequences can be normalized at this level of specification.

It may be convenient to lump this under static semantics (the static =
semantics may need to rely on such rules), but we are now in the area of =
semantic interpretation, no longer in the area of what should be =
strictly syntax but has been split into =93syntax" and "static =
semantics" for notational convenience.

> When we talk about the "semantics" of a language (rather than "static =
semantics") we are talking about attributing meaning (in some domain and =
context) to well-formed (as specified via syntax and static semantics) =
statements expressed in that language.

Exactly.

> ECMA-404 intentionally restricts itself to specify the syntax and =
static semantics of the JSON language.  More below on why.

If that was the intention, that didn=92t work out too well.

>> Semantics is needed to describe e.g. that some whitespace is =
=93insignificant=94 (not contributing to the semantics), describe the =
intended interpretation of escape sequences in strings,
> Yes these are static semantic rules (although whitespace rules could =
be expressed using syntactic formalisms).

The syntax allows the whitespace.  The semantics tells you it doesn=92t =
make a difference with respect to the meaning.  (OK, if you lump in =
semantic equivalence under static semantics, you can say the above, but =
this muddies the terms.)

>> that the sequences of symbols enabled by the production =93number=94 =
are to be interpreted in base 10,
> Yes, ECMA-404 includes this as a static semantic statement although it =
is arguably could be classified as a semantic statement above the level =
of static semantics.  Whether "77" is semantically interpreted as the =
mathematical value 63 or 77 isn't really relevant to whether "77" is a =
well-formed JSON number.

ECMA-404 indeed does not provide the full semantics of its numbers, just =
saying that they are =93represented in base 10=94, appealing to a deeply =
rooted common understanding of what that means (which by the way has =
been codified in ECMA-63 and then ISO 6093).  Note that there is no =
meaning of =93represented in=94 outside of the domain of semantics =97 =
the text clearly is about mapping the abstract (semantic) concept of a =
number to its base-10 representation using JSON=92s syntax.  It seems =
that this phrasing is a remnant from a time when the semantics was =
intended to be part of the specification.

>> or that =93the order of the values is significant=94 in arrays (which =
seems to be intended to contrast them to JSON objects, where ECMA-404 =
weasels out of saying whether the order is significant).
>=20
> ECMA-404 removed the statement "an object is an unordered =
collection..." that exists in RFC-6427. =20

Indeed, it is again interesting to note that this was an intentional =
change from the existing JSON specifications.

> Arguably, ECMA-404 should not have made the statement "the the order =
of values is significant" WRT arrays.  I'll file a bug ticket on that.  =
The reason that neither of these statements is appropriate at this level =
of specification is that they are pure semantic statements that have no =
impact upon determining whether a sequence of symbols are well-formed =
JSON text.

Well, in your definition of static semantics that includes semantic =
equivalence, the statement is appropriate.  It is, however, somewhat =
random whether ECMA-404 provides statements about semantic equivalence =
or not; it is certainly not trying for any completeness.

> Objectively, the members of a JSON 'object' do occur in a specific =
order and a semantic interpreter of an object might ascribe meaning to =
that ordering.  Similarly, a JSON 'array' also has an objectively =
observable ordering of its contained values. It is again up to a =
semantic interpreter as to whether or not it ascribes meaning to that =
ordering.

It is also up to a semantic interpreter as to whether it interprets =
base-10 numbers from left to right or from right to left.  However, I =
would argue that some of the potential interpretations are violating the =
principle of least surprise.   More so, JSON in the real world benefits =
from a significant amount of common interpretation.  A reasonable way to =
capture this at the specification level is to define a generic =93JSON =
data model=94 and define the semantic processing that leads up to this, =
but then of course leave it up to the application how to interpret the =
elements of the JSON data model.  A JSON array would be delivered as an =
ordered sequence to the (application-independent) JSON data model, but =
the application could still interpret that information as a set or as a =
record structure, depending on application context.

>> ECMA-404 does quite a bit of of the latter, so indeed I also have =
trouble interpreting such a statement.
>=20
> So back to "semantics" and why ECMA-404 tries (perhaps imperfectly) to =
avoid describing JSON beyond the level of static semantics.=20
>=20
> ECMA-404 see JSON as "a text format that facilitates structured data =
interchange between all programming languages. JSON
> is syntax of braces, brackets, colons, and commas that is useful in =
many contexts, profiles, and applications=94.

I hope by now it should be clear that ECMA-404 is neither very =
successful in focusing on the syntax only, nor is it a particularly good =
specification of that syntax due to its mix of English language and =
racetrack graphics.  (I still like it as a tutorial for the syntax.)

> There are many possible semantics and categories of semantics that can =
be applied to well-formed statements expressed using the JSON syntax.

The problem with this approach is that much of the interoperability of =
JSON stems from implementations having derived a common data model.  =
Some of this is in the spec (RFC 4627), some if it has been derived by =
implementers drawing analogies with its ancestor JavaScript, some of it =
stems from the fact that the syntax is simply suggestive of a specific =
data model.

Much more would be gained in documenting that (common) data model =
(including documenting the differences that have ensued, and selecting =
some deviations as canonical and others as mistakes) than from =
retracting some of the explicit semantics (while keeping some of them as =
well as the implicit ones weakly in place).

> One type of semantics are language bindings that specify how a JSON =
text might be translated into the data types and structures of some =
particular programming language or runtime environment. The translation =
of a JavaScript string encoding of a JSON text into JavaScript objects =
and values by JSON.parse is one specific example of this kind of =
semantic application of JSON.  But there are many languages that can be =
supported by such language bindings and there is not necessarily a best =
or canonical JSON binding for any language.

Leaving out the common data model and going directly from syntax to =
language binding is a recipe for creating interoperability problems.  =
The approach =93works=94 from the view of a single specific language =
(and thus may seem palatable for a group of experts in a specific =
language, such as TC39), but it is not aiding in interoperability of =
JSON at large.

> Another form of semantics imposes schema based meaning and =
restrictions upon a well-formed JSON text.  A schema explicitly defines =
an application level  meaning to the elements for some specific subset =
of well-formed SON texts. It might require only certain forms of JSON =
values, provide specific meaning to JSON numbers or strings that occur =
in specified positions, require the occurrence of certain object =
members, apply meaning to the ordering of object members or array =
elements, etc. This is probably  most common form of semantics applied =
to JSON and is used by almost all real world JSON use cases.

Again, leaving out the common data model and leaping from the syntax to =
a specific application semantics negates all the real-world advantages =
of having a common data interchange format.

> The problem with trying to standardize JSON semantics is that the =
various semantics that can be usefully be imposed upon JSON are often =
mutually incompatible with each other. At a trivial level, we see this =
with issues like the size of numbers or duplicate object member keys.  =
It is very hard to decide whose semantics are acceptable and whose is =
not.

Completely agree.  The next step in the evolution of JSON should have =
been to actually do this hard work based on the experience we have after =
a decade of usage, instead of punting on it.

> What we can do, is draw a bright-line just above the level of static =
semantics.This is what ECMA-404 attempts to do. If defines a small set =
of structuring elements that can be recursively composed and represent =
in a textual encoding. It provides a common vocabulary upon which =
various semantics can be overlaid and nothing else.  The intent of =
ECMA-404 is to provide the definitive specification of the syntax and =
static semantic of the JSON format that can be used by higher level =
semantic specifications.

It might have been a good idea to do just that as a first step, but =
rushing out ECMA-404 with little feedback from the wider community has =
apparently compromised the quality of the result.  As it stands, the =
seven-year old RFC 4627 continues to fulfill this very objective in a =
better way.

Gr=FC=DFe, Carsten


From paul.hoffman@vpnc.org  Fri Dec  6 08:39:54 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6B01AE08D for <json@ietfa.amsl.com>; Fri,  6 Dec 2013 08:39:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 giAE8hjx4C8U for <json@ietfa.amsl.com>; Fri,  6 Dec 2013 08:39:52 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CE6221ADFFB for <json@ietf.org>; Fri,  6 Dec 2013 08:39:52 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB6GdetZ072716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Dec 2013 09:39:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <52A16C91.2040802@it.aoyama.ac.jp>
Date: Fri, 6 Dec 2013 08:39:40 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <7C2DA70F-4DB8-4C19-81DE-B90005ACF9FA@vpnc.org>
References: <E20F62B4-7F96-42F6-98CC-E560D81A44AC@vpnc.org> <850EC0FE-F009-47A6-9C62-9D4394B7C29B@tzi.org> <cil1a9hjeto50m2vfgdi8s2d7nrgp6mtvn@hive.bjoern.hoehrmann.de> <52A16C91.2040802@it.aoyama.ac.jp>
To: Martin Duerst <duerst@it.aoyama.ac.jp>
X-Mailer: Apple Mail (2.1822)
Cc: Carsten Bormann <cabo@tzi.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, JSON WG <json@ietf.org>
Subject: Re: [Json] That encoding thing
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 16:39:54 -0000

On Dec 5, 2013, at 10:20 PM, Martin J. D=FCrst <duerst@it.aoyama.ac.jp> =
wrote:

> On 2013/12/06 4:54, Bjoern Hoehrmann wrote:
>> * Carsten Bormann wrote:
>>> On 05 Dec 2013, at 19:54, Paul Hoffman<paul.hoffman@vpnc.org>  =
wrote:
>>>=20
>>>> The following is technically correct and should at least partially =
appease the pedants among us.
>>>>=20
>>>> s/JSON text SHALL be encoded in Unicode./JSON text SHALL be encoded =
in one of the character encoding schemes defined by Unicode./
>=20
> I think this change is a significant and necessary improvement. But it =
seems both Carsten and Bj=F6rn disagree. I think this may be because =
"character encoding schemes defined by Unicode" is still slightly =
ambiguous (because it's circumscriptive, rather than using an =
established term). I propose to change this to:
>=20
> JSON text SHALL be encoded in one of the Unicode Encoding Schemes.
> (see Section 2.6 of Unicode 6.3 =
(http://www.unicode.org/versions/Unicode6.2.0/ch02.pdf))
>=20
> This will clearly exclude CESU-8 and UTF-7, as desired.

The sentence that follows the changed one says:

   The default encoding is
   UTF-8, and JSON texts which are encoded in UTF-8 are interoperable in
   the sense that they will be read successfully by the maximum number
   of implementations; there are many implementations which cannot
   successfully read texts in other encodings (such as UTF-16 and
   UTF-32).

If someone wants to encode in UTF-7, they are going to do it regardless =
of the wording here. Us spending effort to make it harder for them to do =
something stupid (and some people here felt that someone using UTF-16 =
was also stupid) is wasted effort.

--Paul Hoffman=

From allen@wirfs-brock.com  Fri Dec  6 11:50:31 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C24A1AE108 for <json@ietfa.amsl.com>; Fri,  6 Dec 2013 11:50:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 21t2qlw3k0br for <json@ietfa.amsl.com>; Fri,  6 Dec 2013 11:50:26 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 19D171ADF81 for <json@ietf.org>; Fri,  6 Dec 2013 11:50:26 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1Vp1Pp-000IZK-7s; Fri, 06 Dec 2013 19:50:22 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/aIqdGSMY2BATIMR/Gj1QqDjDywMqd0RM=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-163-30320549
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org>
Date: Fri, 6 Dec 2013 11:50:13 -0800
Message-Id: <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.1085)
Cc: "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 19:50:31 -0000

--Apple-Mail-163-30320549
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Dec 5, 2013, at 11:34 PM, Carsten Bormann wrote:

> Allen,
>=20
> thank you a lot for this elaborate response.  It really helps me =
understand the different points of view that have emerged.  I=92ll go =
ahead and insert my personal point of view in this response to maybe =
make that more understandable as well (I=92m not speaking for the JSON =
WG at all here, of course).  Maybe you can relay this to es-discuss so =
both mailing lists benefit from it.

Did your reply bounce from es-discuss?  I won't elide any of you =
comments below, just in case.

if you or anybody else know of actual bugs or ambiguities in ECMA-404 =
the best way to communicate that to TC39 and the ECMA-404 project editor =
is to open a ticket at bugs.ecmascript.org.  Product: "ECMA-404  JSON", =
Component: "1st Edition".

>=20
>>> The syntax just tells you which sequences of symbols are part of the =
language.
>>> (This is what we have ABNF for; ECMA-404 uses racetracks plus some =
English language that maps the characters to the tokens in the =
syntax-level racetracks for value, object, and array, and to the English =
language components of the token-level racetracks for number and =
string.)
>>=20
>> Agreed.  I would state this as:  the syntax tells you which sequences =
of symbols form valid statements within the language.
>>=20
>> Language designer also use the term "static semantics".  The static =
semantics of a language are a set of rules that further restrict  which =
sequences of symbols form valid statements within the language.=20
>=20
> Right, the "static semantics" is used to form a subset of what we =
arbitrarily call =93syntax=94, further restricting what sequence of =
symbols is in the language.=20
>=20
>> For example, a rule that the 'member' names must be disjoint within =
an 'object' production could be a static semantic rule (however, there =
is intentionally no such rule in ECMA-404).
>=20
> Thanks, it is interesting to hear that this was a deliberate omission.
>=20
>> The line between syntax and static semantics can be fuzzy.  Static =
semantic rules are typically used to express rules that cannot be =
technically expressed using the chosen syntactic formalism or rules =
which are simply inconvenient to express using that formalism.  For =
example, the editor of ECMA-404 chose to simplify the RR track =
expression of the JSON syntax by using static semantic rules for =
whitespace rather than incorporating them into RR diagrams.=20
>=20
> No, that isn=92t static semantics.  The racetracks don=92t have a =
useful meaning (i.e., express a different, more restricted syntax) =
without the English language rules about whitespace,  (More =
specifically, three of the racetracks operate on a different domain than =
the other two, without that having made explicit.)  Static semantics can =
only serve to restrict the set of syntactically valid symbol sequences.  =
Accepting whitespace is on the syntax level.  (Then ignoring it is =
indeed semantics.)

I think we're quibble here about unimportant points. Multiple level =
specifications is a common practice for language specification.  For =
example, using regular expressions to define the lexical productions =
(the tokens) and a BNF grammar to define the syntactic level. It is also =
common practice to use prose to describe the role of whitespace at the =
lexical level.  For example see =
http://www.ecma-international.org/ecma-262/5.1/#sec-5.1.2=20

The important point is whether or not ECMA-404 under specifies the =
language, is ambiguous, or has any other errors. If it does, please file =
bug reports so corrections can be made in a revised editions.=20

>=20
>> Another form of static semantic rules are equivalences that state =
when two or more different sequences of symbols must be considered as =
equivalent.  For example, the rules that state equivalencies between =
escape sequences and individual code points within an JSON 'string'.  =
Such equivalences are not strictly necessary at this level, but it it =
simplifies the specification of higher level semantics if equivalent =
symbol sequences can be normalized at this level of specification.
>=20
> It may be convenient to lump this under static semantics (the static =
semantics may need to rely on such rules), but we are now in the area of =
semantic interpretation, no longer in the area of what should be =
strictly syntax but has been split into =93syntax" and "static =
semantics" for notational convenience.

I disagree. It is useful at the syntactic/static semantic level to =
specify that two symbol sequences must be equivalent for semantic =
purposes.  And we can do this without providing any actual semantics for =
the symbol sequences.  For example:

We can say that
   "abc"
and
   "\u0061\u0062\u0063"
must be assigned identical semantics without actually specify what that =
semantics is. Whether you prefer to call it static semantics or =
something else, it is independent of any specific semantic domain and =
reasonably at the level of concerns addressed by ECMA-404.

>=20
>> When we talk about the "semantics" of a language (rather than "static =
semantics") we are talking about attributing meaning (in some domain and =
context) to well-formed (as specified via syntax and static semantics) =
statements expressed in that language.
>=20
> Exactly.
>=20
>> ECMA-404 intentionally restricts itself to specify the syntax and =
static semantics of the JSON language.  More below on why.
>=20
> If that was the intention, that didn=92t work out too well.

specific bugs please...

>=20
>>> Semantics is needed to describe e.g. that some whitespace is =
=93insignificant=94 (not contributing to the semantics), describe the =
intended interpretation of escape sequences in strings,
>> Yes these are static semantic rules (although whitespace rules could =
be expressed using syntactic formalisms).
>=20
> The syntax allows the whitespace.  The semantics tells you it doesn=92t =
make a difference with respect to the meaning.  (OK, if you lump in =
semantic equivalence under static semantics, you can say the above, but =
this muddies the terms.)
>=20
>>> that the sequences of symbols enabled by the production =93number=94 =
are to be interpreted in base 10,
>> Yes, ECMA-404 includes this as a static semantic statement although =
it is arguably could be classified as a semantic statement above the =
level of static semantics.  Whether "77" is semantically interpreted as =
the mathematical value 63 or 77 isn't really relevant to whether "77" is =
a well-formed JSON number.
>=20
> ECMA-404 indeed does not provide the full semantics of its numbers, =
just saying that they are =93represented in base 10=94, appealing to a =
deeply rooted common understanding of what that means (which by the way =
has been codified in ECMA-63 and then ISO 6093).  Note that there is no =
meaning of =93represented in=94 outside of the domain of semantics =97 =
the text clearly is about mapping the abstract (semantic) concept of a =
number to its base-10 representation using JSON=92s syntax.  It seems =
that this phrasing is a remnant from a time when the semantics was =
intended to be part of the specification.

"represented in base 10" probably would be better stated as "represented =
as a sequence of decimal digits" which would eliminate the semantic =
implication.=20

Yes, there are remnants in ECMA-404 (and in REF-6427bis) from the days =
when the JSON format and its language binding to ECMAScript tended to be =
equated. One of the things we should be trying to do is eliminate those =
remnants.

> \
>>> or that =93the order of the values is significant=94 in arrays =
(which seems to be intended to contrast them to JSON objects, where =
ECMA-404 weasels out of saying whether the order is significant).
>>=20
>> ECMA-404 removed the statement "an object is an unordered =
collection..." that exists in RFC-6427. =20
>=20
> Indeed, it is again interesting to note that this was an intentional =
change from the existing JSON specifications.
>=20
>> Arguably, ECMA-404 should not have made the statement "the the order =
of values is significant" WRT arrays.  I'll file a bug ticket on that.  =
The reason that neither of these statements is appropriate at this level =
of specification is that they are pure semantic statements that have no =
impact upon determining whether a sequence of symbols are well-formed =
JSON text.
>=20
> Well, in your definition of static semantics that includes semantic =
equivalence, the statement is appropriate.  It is, however, somewhat =
random whether ECMA-404 provides statements about semantic equivalence =
or not; it is certainly not trying for any completeness.

More specifics please.  I don't see how semantic equivalence enters into =
this discussion of arrays. What equivalences comes into play?  As I said =
above, I think the existence of that phase "the order of values is =
significant" is a bug.  "significant" to what?  Certainly the intent =
wasn't to forbid a schema level semantics from considering [1,2] and =
[2,1] as being equivalent in some particular field position.

>=20
>> Objectively, the members of a JSON 'object' do occur in a specific =
order and a semantic interpreter of an object might ascribe meaning to =
that ordering.  Similarly, a JSON 'array' also has an objectively =
observable ordering of its contained values. It is again up to a =
semantic interpreter as to whether or not it ascribes meaning to that =
ordering.
>=20
> It is also up to a semantic interpreter as to whether it interprets =
base-10 numbers from left to right or from right to left.  However, I =
would argue that some of the potential interpretations are violating the =
principle of least surprise.  More so, JSON in the real world benefits =
from a significant amount of common interpretation.

Agreed.  I believe we have this today, at this level.

> A reasonable way to capture this at the specification level is to =
define a generic =93JSON data model=94 and define the semantic =
processing that leads up to this, but then of course leave it up to the =
application how to interpret the elements of the JSON data model.  A =
JSON array would be delivered as an ordered sequence to the =
(application-independent) JSON data model, but the application could =
still interpret that information as a set or as a record structure, =
depending on application context.

What do you mean by "delivered" in your second sentence.  It sounds like =
you are either talking about a language binding or perhaps a JSON parser =
interface. The former is clearly in the realm that I classify as =
semantics and I would expect any reasonable parser-based interface to =
preserve all ordering relationships that exist in the parsed text. =20

As another example, the JSON to ECMAScript language binding defined by =
ECMA-262 implicitly defines an ordering of the properties of the =
ECMAScript objects that are created corresponding to JSON objects even =
though RFC-6427 said that an array is an unordered set of values.  It =
just falls out of the ECMAScript data model.=20

We could try to say that all semantics applied to the JSON format MUST =
preserve the ordering of JSON array elements. But is seems unnecessary =
and in some cases excessively restrictive.

Defining a complete and universal "JSON data model" is hard.  It is =
possible to defined a normative JSON syntax without providing such a =
model and that is the direction that ECMA-404 has taken. If somebody =
wants to attempt to define such a data model they are welcome to write a =
spec. layered above ECMA-404 and to demonstrate its utility.=20

In practice, JSON is almost useless without schema level semantic =
agreement between the producer and consumer of a JSON text. Most of the =
issues we are discussing here are easily subsumed by such schema level =
agreements.

>=20
>>> ECMA-404 does quite a bit of of the latter, so indeed I also have =
trouble interpreting such a statement.
>>=20
>> So back to "semantics" and why ECMA-404 tries (perhaps imperfectly) =
to avoid describing JSON beyond the level of static semantics.=20
>>=20
>> ECMA-404 see JSON as "a text format that facilitates structured data =
interchange between all programming languages. JSON
>> is syntax of braces, brackets, colons, and commas that is useful in =
many contexts, profiles, and applications=94.
>=20
> I hope by now it should be clear that ECMA-404 is neither very =
successful in focusing on the syntax only, nor is it a particularly good =
specification of that syntax due to its mix of English language and =
racetrack graphics.  (I still like it as a tutorial for the syntax.)

No, it isn't clear.  Specific bugs would help clarify. I didn't choose =
to use racetracks in the specification and I might not have made that =
choice myself. But I will defend it as a valid formalism and one that is =
well understood.  A grammar expressed using ovals and arrows is just as =
valid as one expressed using ASCII characters.=20

It's silly to be squabbling over such a notational issues and =
counter-productive if such squabbles results multiple different =
normative standards for the same language/format.

TC39 would likely be receptive to a request to add to ECMA-404 an =
informative annex with a BNF grammar for JSON (even ABNF, even though it =
isn't TC39's normal BNF conventions). Asking is likely to produce better =
results than throwing stones.

>=20
>> There are many possible semantics and categories of semantics that =
can be applied to well-formed statements expressed using the JSON =
syntax.
>=20
> The problem with this approach is that much of the interoperability of =
JSON stems from implementations having derived a common data model.  =
Some of this is in the spec (RFC 4627), some if it has been derived by =
implementers drawing analogies with its ancestor JavaScript, some of it =
stems from the fact that the syntax is simply suggestive of a specific =
data model.
>=20
> Much more would be gained in documenting that (common) data model =
(including documenting the differences that have ensued, and selecting =
some deviations as canonical and others as mistakes) than from =
retracting some of the explicit semantics (while keeping some of them as =
well as the implicit ones weakly in place).

This is where I disagree.  Do you have any examples of interoperability =
problems occurring at this level? As I said above.  Successful JSON =
interoperability is most dependent upon schema level semantic agreement =
and good language bindings. In practice, those levels easily can =
encompass the sort of data model issues you seem to be concerned about.

However, I don't think TC39 wants to put any barriers in front of =
somebody trying to specify such a data model or models.  We tried to =
avoid such barriers is by not including unnecessary semantic =
restrictions in ECMA-404.

>=20
>> One type of semantics are language bindings that specify how a JSON =
text might be translated into the data types and structures of some =
particular programming language or runtime environment. The translation =
of a JavaScript string encoding of a JSON text into JavaScript objects =
and values by JSON.parse is one specific example of this kind of =
semantic application of JSON.  But there are many languages that can be =
supported by such language bindings and there is not necessarily a best =
or canonical JSON binding for any language.
>=20
> Leaving out the common data model and going directly from syntax to =
language binding is a recipe for creating interoperability problems.  =
The approach =93works=94 from the view of a single specific language =
(and thus may seem palatable for a group of experts in a specific =
language, such as TC39), but it is not aiding in interoperability of =
JSON at large.

Examples? The language expertise within TC39 certainly extends beyond =
just ECMAScript and that expertise informs the consensus decisions we =
make.

A counter example we have actually discussed is any limitation on the =
number of digits in a JSON number.   While some applications of JSON =
might want to limit the precision other have a need for arbitrary large =
digit sequences.  Such restrictions and allowances must be dealt with at =
the schema specification level so there is no need to arbitrarily =
restrict precision at the format/language level of specification.

That's it for now. I think I've already addressed any substantive issues =
you raise below.

Happy to continue the conversation.=20

Allen

>=20
>> Another form of semantics imposes schema based meaning and =
restrictions upon a well-formed JSON text.  A schema explicitly defines =
an application level  meaning to the elements for some specific subset =
of well-formed SON texts. It might require only certain forms of JSON =
values, provide specific meaning to JSON numbers or strings that occur =
in specified positions, require the occurrence of certain object =
members, apply meaning to the ordering of object members or array =
elements, etc. This is probably  most common form of semantics applied =
to JSON and is used by almost all real world JSON use cases.
>=20
> Again, leaving out the common data model and leaping from the syntax =
to a specific application semantics negates all the real-world =
advantages of having a common data interchange format.
>=20
>> The problem with trying to standardize JSON semantics is that the =
various semantics that can be usefully be imposed upon JSON are often =
mutually incompatible with each other. At a trivial level, we see this =
with issues like the size of numbers or duplicate object member keys.  =
It is very hard to decide whose semantics are acceptable and whose is =
not.
>=20
> Completely agree.  The next step in the evolution of JSON should have =
been to actually do this hard work based on the experience we have after =
a decade of usage, instead of punting on it.
>=20
>> What we can do, is draw a bright-line just above the level of static =
semantics.This is what ECMA-404 attempts to do. If defines a small set =
of structuring elements that can be recursively composed and represent =
in a textual encoding. It provides a common vocabulary upon which =
various semantics can be overlaid and nothing else.  The intent of =
ECMA-404 is to provide the definitive specification of the syntax and =
static semantic of the JSON format that can be used by higher level =
semantic specifications.
>=20
> It might have been a good idea to do just that as a first step, but =
rushing out ECMA-404 with little feedback from the wider community has =
apparently compromised the quality of the result.  As it stands, the =
seven-year old RFC 4627 continues to fulfill this very objective in a =
better way.
>=20
> Gr=FC=DFe, Carsten
>=20
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>=20


--Apple-Mail-163-30320549
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Dec 5, 2013, at 11:34 PM, Carsten Bormann =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>Allen,<br><br>thank you a lot for this elaborate =
response. &nbsp;It really helps me understand the different points of =
view that have emerged. &nbsp;I=92ll go ahead and insert my personal =
point of view in this response to maybe make that more understandable as =
well (I=92m not speaking for the JSON WG at all here, of course). =
&nbsp;Maybe you can relay this to es-discuss so both mailing lists =
benefit from it.<br></div></blockquote><div><br></div><div>Did your =
reply bounce from es-discuss? &nbsp;I won't elide any of you comments =
below, just in case.</div><div><br></div><div>if you or anybody else =
know of actual bugs or ambiguities in ECMA-404 the best way to =
communicate that to TC39 and the ECMA-404 project editor is to open a =
ticket at <a href=3D"http://bugs.ecmascript.org">bugs.ecmascript.org</a>. =
&nbsp;Product: "ECMA-404 &nbsp;JSON", Component: "1st =
Edition".</div><br><blockquote type=3D"cite"><div><br><blockquote =
type=3D"cite"><blockquote type=3D"cite">The syntax just tells you which =
sequences of symbols are part of the =
language.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">(This is what we have ABNF for; =
ECMA-404 uses racetracks plus some English language that maps the =
characters to the tokens in the syntax-level racetracks for value, =
object, and array, and to the English language components of the =
token-level racetracks for number and =
string.)<br></blockquote></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Agreed. &nbsp;I =
would state this as: &nbsp;the syntax tells you which sequences of =
symbols form valid statements within the =
language.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Language =
designer also use the term "static semantics". &nbsp;The static =
semantics of a language are a set of rules that further restrict =
&nbsp;which sequences of symbols form valid statements within the =
language. <br></blockquote><br>Right, the "static semantics" is used to =
form a subset of what we arbitrarily call =93syntax=94, further =
restricting what sequence of symbols is in the language. =
<br><br><blockquote type=3D"cite"> For example, a rule that the 'member' =
names must be disjoint within an 'object' production could be a static =
semantic rule (however, there is intentionally no such rule in =
ECMA-404).<br></blockquote><br>Thanks, it is interesting to hear that =
this was a deliberate omission.<br><br><blockquote type=3D"cite">The =
line between syntax and static semantics can be fuzzy. &nbsp;Static =
semantic rules are typically used to express rules that cannot be =
technically expressed using the chosen syntactic formalism or rules =
which are simply inconvenient to express using that formalism. &nbsp;For =
example, the editor of ECMA-404 chose to simplify the RR track =
expression of the JSON syntax by using static semantic rules for =
whitespace rather than incorporating them into RR diagrams. =
<br></blockquote><br>No, that isn=92t static semantics. &nbsp;The =
racetracks don=92t have a useful meaning (i.e., express a different, =
more restricted syntax) without the English language rules about =
whitespace, &nbsp;(More specifically, three of the racetracks operate on =
a different domain than the other two, without that having made =
explicit.) &nbsp;Static semantics can only serve to restrict the set of =
syntactically valid symbol sequences. &nbsp;Accepting whitespace is on =
the syntax level. &nbsp;(Then ignoring it is indeed =
semantics.)<br></div></blockquote><div><br></div><div>I think we're =
quibble here about unimportant points. Multiple level specifications is =
a common practice for language specification. &nbsp;For example, using =
regular expressions to define the lexical productions (the tokens) and a =
BNF grammar to define the syntactic level. It is also common practice to =
use prose to describe the role of whitespace at the lexical level. =
&nbsp;For example see&nbsp;<a =
href=3D"http://www.ecma-international.org/ecma-262/5.1/#sec-5.1.2">http://=
www.ecma-international.org/ecma-262/5.1/#sec-5.1.2</a>&nbsp;</div><div><br=
></div><div>The important point is whether or not ECMA-404 under =
specifies the language, is ambiguous, or has any other errors. If it =
does, please file bug reports so corrections can be made in a revised =
editions.&nbsp;</div><div><br></div><blockquote =
type=3D"cite"><div><br><blockquote type=3D"cite">Another form of static =
semantic rules are equivalences that state when two or more different =
sequences of symbols must be considered as equivalent. &nbsp;For =
example, the rules that state equivalencies between escape sequences and =
individual code points within an JSON 'string'. &nbsp;Such equivalences =
are not strictly necessary at this level, but it it simplifies the =
specification of higher level semantics if equivalent symbol sequences =
can be normalized at this level of specification.<br></blockquote><br>It =
may be convenient to lump this under static semantics (the static =
semantics may need to rely on such rules), but we are now in the area of =
semantic interpretation, no longer in the area of what should be =
strictly syntax but has been split into =93syntax" and "static =
semantics" for notational =
convenience.<br></div></blockquote><div><br></div><div>I disagree. It is =
useful at the syntactic/static semantic level to specify that two symbol =
sequences must be equivalent for semantic purposes. &nbsp;And we can do =
this without providing any actual semantics for the symbol sequences. =
&nbsp;For example:</div><div><br></div><div>We can say =
that</div><div>&nbsp; &nbsp;"abc"</div><div>and</div><div>&nbsp; =
&nbsp;"\u0061\u0062\u0063"</div><div>must be assigned identical =
semantics without actually specify what that semantics is. Whether you =
prefer to call it static semantics or something else, it is independent =
of any specific semantic domain and reasonably at the level of concerns =
addressed by ECMA-404.</div><div><br></div><blockquote =
type=3D"cite"><div><br><blockquote type=3D"cite">When we talk about the =
"semantics" of a language (rather than "static semantics") we are =
talking about attributing meaning (in some domain and context) to =
well-formed (as specified via syntax and static semantics) statements =
expressed in that =
language.<br></blockquote><br>Exactly.<br><br><blockquote =
type=3D"cite">ECMA-404 intentionally restricts itself to specify the =
syntax and static semantics of the JSON language. &nbsp;More below on =
why.<br></blockquote><br>If that was the intention, that didn=92t work =
out too well.<br></div></blockquote><div><br></div>specific bugs =
please...</div><div><br><blockquote type=3D"cite"><div><br><blockquote =
type=3D"cite"><blockquote type=3D"cite">Semantics is needed to describe =
e.g. that some whitespace is =93insignificant=94 (not contributing to =
the semantics), describe the intended interpretation of escape sequences =
in strings,<br></blockquote></blockquote><blockquote type=3D"cite">Yes =
these are static semantic rules (although whitespace rules could be =
expressed using syntactic formalisms).<br></blockquote><br>The syntax =
allows the whitespace. &nbsp;The semantics tells you it doesn=92t make a =
difference with respect to the meaning. &nbsp;(OK, if you lump in =
semantic equivalence under static semantics, you can say the above, but =
this muddies the terms.)<br><br><blockquote type=3D"cite"><blockquote =
type=3D"cite">that the sequences of symbols enabled by the production =
=93number=94 are to be interpreted in base =
10,<br></blockquote></blockquote><blockquote type=3D"cite">Yes, ECMA-404 =
includes this as a static semantic statement although it is arguably =
could be classified as a semantic statement above the level of static =
semantics. &nbsp;Whether "77" is semantically interpreted as the =
mathematical value 63 or 77 isn't really relevant to whether "77" is a =
well-formed JSON number.<br></blockquote><br>ECMA-404 indeed does not =
provide the full semantics of its numbers, just saying that they are =
=93represented in base 10=94, appealing to a deeply rooted common =
understanding of what that means (which by the way has been codified in =
ECMA-63 and then ISO 6093). &nbsp;Note that there is no meaning of =
=93represented in=94 outside of the domain of semantics =97 the text =
clearly is about mapping the abstract (semantic) concept of a number to =
its base-10 representation using JSON=92s syntax. &nbsp;It seems that =
this phrasing is a remnant from a time when the semantics was intended =
to be part of the =
specification.<br></div></blockquote><div><br></div><div>"represented in =
base 10" probably would be better stated as "represented as a sequence =
of decimal digits" which would eliminate the semantic =
implication.&nbsp;</div><div><br></div><div>Yes, there are remnants in =
ECMA-404 (and in REF-6427bis) from the days when the JSON format and its =
language binding to ECMAScript tended to be equated. One of the things =
we should be trying to do is eliminate those =
remnants.</div><div><br></div><blockquote =
type=3D"cite"><div>\<br><blockquote type=3D"cite"><blockquote =
type=3D"cite">or that =93the order of the values is significant=94 in =
arrays (which seems to be intended to contrast them to JSON objects, =
where ECMA-404 weasels out of saying whether the order is =
significant).<br></blockquote></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">ECMA-404 =
removed the statement "an object is an unordered collection..." that =
exists in RFC-6427. &nbsp;<br></blockquote><br>Indeed, it is again =
interesting to note that this was an intentional change from the =
existing JSON specifications.<br><br><blockquote type=3D"cite">Arguably, =
ECMA-404 should not have made the statement "the the order of values is =
significant" WRT arrays. &nbsp;I'll file a bug ticket on that. &nbsp;The =
reason that neither of these statements is appropriate at this level of =
specification is that they are pure semantic statements that have no =
impact upon determining whether a sequence of symbols are well-formed =
JSON text.<br></blockquote><br>Well, in your definition of static =
semantics that includes semantic equivalence, the statement is =
appropriate. &nbsp;It is, however, somewhat random whether ECMA-404 =
provides statements about semantic equivalence or not; it is certainly =
not trying for any =
completeness.<br></div></blockquote><div><br></div><div>More specifics =
please. &nbsp;I don't see how semantic equivalence enters into this =
discussion of arrays. What equivalences comes into play? &nbsp;As I said =
above, I think the existence of that phase "the order of values is =
significant" is a bug. &nbsp;"significant" to what? &nbsp;Certainly the =
intent wasn't to forbid a schema level semantics from considering [1,2] =
and [2,1] as being equivalent in some particular field =
position.</div><div><br></div><blockquote =
type=3D"cite"><div><br><blockquote type=3D"cite">Objectively, the =
members of a JSON 'object' do occur in a specific order and a semantic =
interpreter of an object might ascribe meaning to that ordering. =
&nbsp;Similarly, a JSON 'array' also has an objectively observable =
ordering of its contained values. It is again up to a semantic =
interpreter as to whether or not it ascribes meaning to that =
ordering.<br></blockquote><br>It is also up to a semantic interpreter as =
to whether it interprets base-10 numbers from left to right or from =
right to left. &nbsp;However, I would argue that some of the potential =
interpretations are violating the principle of least surprise.&nbsp; =
More so, JSON in the real world benefits from a significant amount of =
common interpretation.</div></blockquote><div><br></div><div>Agreed. =
&nbsp;I believe we have this today, at this =
level.</div><div><br></div><blockquote type=3D"cite"><div>A reasonable =
way to capture this at the specification level is to define a generic =
=93JSON data model=94 and define the semantic processing that leads up =
to this, but then of course leave it up to the application how to =
interpret the elements of the JSON data model. &nbsp;A JSON array would =
be delivered as an ordered sequence to the (application-independent) =
JSON data model, but the application could still interpret that =
information as a set or as a record structure, depending on application =
context.</div></blockquote><div><br></div><div>What do you mean by =
"delivered" in your second sentence. &nbsp;It sounds like you are either =
talking about a language binding or perhaps a JSON parser interface. The =
former is clearly in the realm that I classify as semantics and I would =
expect any reasonable parser-based interface to preserve all ordering =
relationships that exist in the parsed text. =
&nbsp;</div><div><br></div><div>As another example, the JSON to =
ECMAScript language binding defined by ECMA-262 implicitly defines an =
ordering of the properties of the ECMAScript objects that are created =
corresponding to JSON objects even though RFC-6427 said that an array is =
an unordered set of values. &nbsp;It just falls out of the ECMAScript =
data model.&nbsp;</div><div><br></div><div>We could try to say that all =
semantics applied to the JSON format MUST preserve the ordering of JSON =
array elements. But is seems unnecessary and in some cases excessively =
restrictive.</div><div><br></div><div>Defining a complete and universal =
"JSON data model" is hard. &nbsp;It is possible to defined a normative =
JSON syntax without providing such a model and that is the direction =
that ECMA-404 has taken. If somebody wants to attempt to define such a =
data model they are welcome to write a spec. layered above ECMA-404 and =
to demonstrate its utility.&nbsp;</div><div><br></div><div>In practice, =
JSON is almost useless without schema level semantic agreement between =
the producer and consumer of a JSON text. Most of the issues we are =
discussing here are easily subsumed by such schema level =
agreements.</div><div><br></div><blockquote =
type=3D"cite"><div><br><blockquote type=3D"cite"><blockquote =
type=3D"cite">ECMA-404 does quite a bit of of the latter, so indeed I =
also have trouble interpreting such a =
statement.<br></blockquote></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">So back to =
"semantics" and why ECMA-404 tries (perhaps imperfectly) to avoid =
describing JSON beyond the level of static semantics. =
<br></blockquote><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">ECMA-404 see JSON as "a text format that facilitates =
structured data interchange between all programming languages. =
JSON<br></blockquote><blockquote type=3D"cite">is syntax of braces, =
brackets, colons, and commas that is useful in many contexts, profiles, =
and applications=94.<br></blockquote><br>I hope by now it should be =
clear that ECMA-404 is neither very successful in focusing on the syntax =
only, nor is it a particularly good specification of that syntax due to =
its mix of English language and racetrack graphics. &nbsp;(I still like =
it as a tutorial for the =
syntax.)<br></div></blockquote><div><br></div><div>No, it isn't clear. =
&nbsp;Specific bugs would help clarify. I didn't choose to use =
racetracks in the specification and I might not have made that choice =
myself. But I will defend it as a valid formalism and one that is well =
understood. &nbsp;A grammar expressed using ovals and arrows is just as =
valid as one expressed using ASCII =
characters.&nbsp;</div><div><br></div><div>It's silly to be squabbling =
over such a notational issues and counter-productive if such squabbles =
results multiple different normative standards for the same =
language/format.</div><div><br></div><div>TC39 would likely be receptive =
to a request to add to ECMA-404 an informative annex with a BNF grammar =
for JSON (even ABNF, even though it isn't TC39's normal BNF =
conventions). Asking is likely to produce better results than throwing =
stones.</div><div><br></div><blockquote type=3D"cite"><div><br><blockquote=
 type=3D"cite">There are many possible semantics and categories of =
semantics that can be applied to well-formed statements expressed using =
the JSON syntax.<br></blockquote><br>The problem with this approach is =
that much of the interoperability of JSON stems from implementations =
having derived a common data model. &nbsp;Some of this is in the spec =
(RFC 4627), some if it has been derived by implementers drawing =
analogies with its ancestor JavaScript, some of it stems from the fact =
that the syntax is simply suggestive of a specific data =
model.<br><br>Much more would be gained in documenting that (common) =
data model (including documenting the differences that have ensued, and =
selecting some deviations as canonical and others as mistakes) than from =
retracting some of the explicit semantics (while keeping some of them as =
well as the implicit ones weakly in =
place).<br></div></blockquote><div><br></div><div>This is where I =
disagree. &nbsp;Do you have any examples of interoperability problems =
occurring at this level?&nbsp;As I said above. &nbsp;Successful JSON =
interoperability is most dependent upon schema level semantic agreement =
and good language bindings. In practice, those levels easily can =
encompass the sort of data model issues you seem to be concerned =
about.</div><div><br></div><div>However, I don't think TC39 wants to put =
any barriers in front of somebody trying to specify such a data model or =
models. &nbsp;We tried to avoid such barriers is by not including =
unnecessary semantic restrictions =
in&nbsp;ECMA-404.</div><div><br></div><blockquote =
type=3D"cite"><div><br><blockquote type=3D"cite">One type of semantics =
are language bindings that specify how a JSON text might be translated =
into the data types and structures of some particular programming =
language or runtime environment. The translation of a JavaScript string =
encoding of a JSON text into JavaScript objects and values by JSON.parse =
is one specific example of this kind of semantic application of JSON. =
&nbsp;But there are many languages that can be supported by such =
language bindings and there is not necessarily a best or canonical JSON =
binding for any language.<br></blockquote><br>Leaving out the common =
data model and going directly from syntax to language binding is a =
recipe for creating interoperability problems. &nbsp;The approach =
=93works=94 from the view of a single specific language (and thus may =
seem palatable for a group of experts in a specific language, such as =
TC39), but it is not aiding in interoperability of JSON at =
large.<br></div></blockquote><div><br></div><div>Examples? The language =
expertise within TC39 certainly extends beyond just ECMAScript and that =
expertise informs the consensus decisions we =
make.</div><div><br></div><div>A counter example we have actually =
discussed is any limitation on the number of digits in a JSON number. =
&nbsp; While some applications of JSON might want to limit the precision =
other have a need for arbitrary large digit sequences. &nbsp;Such =
restrictions and allowances must be dealt with at the schema =
specification level so there is no need to arbitrarily restrict =
precision at the&nbsp;format/language level of =
specification.</div><div><br></div><div>That's it for now. I think I've =
already addressed any substantive issues you raise =
below.</div><div><br></div><div>Happy to continue the =
conversation.&nbsp;</div><div><br></div><div>Allen</div><div><br></div><bl=
ockquote type=3D"cite"><div><br><blockquote type=3D"cite">Another form =
of semantics imposes schema based meaning and restrictions upon a =
well-formed JSON text. &nbsp;A schema explicitly defines an application =
level &nbsp;meaning to the elements for some specific subset of =
well-formed SON texts. It might require only certain forms of JSON =
values, provide specific meaning to JSON numbers or strings that occur =
in specified positions, require the occurrence of certain object =
members, apply meaning to the ordering of object members or array =
elements, etc. This is probably &nbsp;most common form of semantics =
applied to JSON and is used by almost all real world JSON use =
cases.<br></blockquote><br>Again, leaving out the common data model and =
leaping from the syntax to a specific application semantics negates all =
the real-world advantages of having a common data interchange =
format.<br><br><blockquote type=3D"cite">The problem with trying to =
standardize JSON semantics is that the various semantics that can be =
usefully be imposed upon JSON are often mutually incompatible with each =
other. At a trivial level, we see this with issues like the size of =
numbers or duplicate object member keys. &nbsp;It is very hard to decide =
whose semantics are acceptable and whose is =
not.<br></blockquote><br>Completely agree. &nbsp;The next step in the =
evolution of JSON should have been to actually do this hard work based =
on the experience we have after a decade of usage, instead of punting on =
it.<br><br><blockquote type=3D"cite">What we can do, is draw a =
bright-line just above the level of static semantics.This is what =
ECMA-404 attempts to do. If defines a small set of structuring elements =
that can be recursively composed and represent in a textual encoding. It =
provides a common vocabulary upon which various semantics can be =
overlaid and nothing else. &nbsp;The intent of ECMA-404 is to provide =
the definitive specification of the syntax and static semantic of the =
JSON format that can be used by higher level semantic =
specifications.<br></blockquote><br>It might have been a good idea to do =
just that as a first step, but rushing out ECMA-404 with little feedback =
from the wider community has apparently compromised the quality of the =
result. &nbsp;As it stands, the seven-year old RFC 4627 continues to =
fulfill this very objective in a better =
way.<br></div></blockquote><blockquote type=3D"cite"><div><br>Gr=FC=DFe, =
Carsten<br><br>_______________________________________________<br>json =
mailing list<br><a =
href=3D"mailto:json@ietf.org">json@ietf.org</a><br>https://www.ietf.org/ma=
ilman/listinfo/json<br><br></div></blockquote></div><br></body></html>=

--Apple-Mail-163-30320549--


From nico@cryptonector.com  Fri Dec  6 12:56:24 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13D21AE04F for <json@ietfa.amsl.com>; Fri,  6 Dec 2013 12:56:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.121
X-Spam-Level: **
X-Spam-Status: No, score=2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FSL_HELO_FAKE=3.499, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 1SLnoDaRN5Zi for <json@ietfa.amsl.com>; Fri,  6 Dec 2013 12:56:24 -0800 (PST)
Received: from homiemail-a36.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 114DC1AE03E for <json@ietf.org>; Fri,  6 Dec 2013 12:56:24 -0800 (PST)
Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 52E3C77805F; Fri,  6 Dec 2013 12:56:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=nclwl+YrPxpL+f YURtHzieQqeCo=; b=r2S9uxIJiW7su8mpfBcDCAPo+vDHvKA5owhN5N+ugemmWs Fh8e+etuNaXaYYTKhEFi4tyfywBgu3vxaV2Nr4R7vtB4S2BwT00LSYVOqk1+9DrG qBtG61Ge7lZ9cGK9Czzk3W5E21ZJ99omG1e7ECEpIrBgAxOMRyOkV9UjhOFfA=
Received: from gmail.com (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 9C7C6778057; Fri,  6 Dec 2013 12:56:19 -0800 (PST)
Date: Fri, 6 Dec 2013 14:56:16 -0600
From: Nico Williams <nico@cryptonector.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Message-ID: <20131206205613.GA3577@gmail.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: JSON WG <json@ietf.org>, Carsten Bormann <cabo@tzi.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 20:56:25 -0000

On Fri, Dec 06, 2013 at 11:50:13AM -0800, Allen Wirfs-Brock wrote:
> In practice, JSON is almost useless without schema level semantic
> agreement between the producer and consumer of a JSON text. Most of

Yes.

> the issues we are discussing here are easily subsumed by such schema
> level agreements.

Hmmm, well, there has to be some meta-schema.

That arrays preserve order is meta-schema for JSON, else we'd have no
interop -- and this is critical for comparisons, so specifying this bit
of meta-schema/ semantics enables very important semantics: arrays can
be compared for equivalence without having to sort them (which would
require further specification of collation for all JSON values!).

That whitespace (outside strings) is not significant may be expressed
syntactically or semantically, but this has to be universally agreed if
we'll have any chance of interoperating.

That object names (keys) are not dups is trickier: for on-line
processing there may be no way to detect dups or do anything about them,
but for many common implementations object name uniqueness is very much
a requirement.  So here, finally, we have a bit of semantics that could
be in the spec but could be left out (we spent a lot of time on the
current consensus for RFC4627bis, and I think it's safe to say that
we're all happy with it)

That objects name order is irrelevant and non-deterministic is widely
assumed/accepted (though often users ask that JSON filters preserve
object name order from input to output).  (And, of course, for on-line
encoders and parsers name order could well be made significant, but
building schemas that demand ordered names means vastly limiting the
world of JSON tooling that can be used to interoperably implement such
schemas.)

Similarly for numbers, the *interoperable* number ranges and precisions
are not really syntactic (they could be expressed via syntax, but it'd
be a pain to do it that way).

I think it's clear that we have consensus in the IETF JSON WG for:

 - whitespace semantics (not significant outside strings)
 - array element order semantics (elements are "ordered")
 - object name dups/order semantics (names SHOULD be unique, but interop
   considerations described; name/value pairs are "unordered")
 - no real constraints on numeric values but interoperable
   range/precision described

If ECMA-404 differs in any way that does not impose more/different
semantics, then maybe we don't care as far as RFC4627bis goes.  If
ECMA-404 does impose more/different semantics then we'll care a great
deal.  Since ECMA-404 targets just the syntax and minimal semantics,
it's probably just fine for RFC4627bis to reference ECMA-404, but since
RFC4627bis would be specifying a bit more semantics, we'd probably not
want to make that reference be normative, at least not with some text
excplaining that it's normative only because we believe that the JSON
syntax given in both docs are equivalent.

Nico
-- 

From sayrer@gmail.com  Fri Dec  6 14:44:26 2013
Return-Path: <sayrer@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FB71AE09C for <json@ietfa.amsl.com>; Fri,  6 Dec 2013 14:44:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
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 kfzFRXHQ5W_y for <json@ietfa.amsl.com>; Fri,  6 Dec 2013 14:44:25 -0800 (PST)
Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 20E111AE08E for <json@ietf.org>; Fri,  6 Dec 2013 14:44:24 -0800 (PST)
Received: by mail-qc0-f176.google.com with SMTP id i8so986659qcq.7 for <json@ietf.org>; Fri, 06 Dec 2013 14:44:21 -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:content-type; bh=UCp6dKE2hL6Dhu4OFvACUaL0o1IE4+F5dKZ0Adk/Y9k=; b=EK5hr5MuiVxx3rrcpwh5DnbO5J0UJKiT6FuMOzFRI5UsnT+hHVS5oHZ9cCqzSx0aM0 M4wqpbconXzVE1383js+m3BS3QE47lXVN381FkHEY33CW2j19F2MhmVLqVt6yK91GylM NnCLuXhjcUFGxY4P/2RGnxhPOHtr62NXqfG9IwkmzWf08ucazKRwjmWcVrn7zADgVchL UwvL6A7cP/0RgB4PWyz8vumW3p39gS6k/HBI1u2DpxEyFtkgbjQWvv5CA8kQf/pvRKnT KD7QfNEaGOTZGsaWFIYrj93mmE9lJKkvLQqh3iVRCjLYnzrReQMBXuF1p/XlTpoWRP42 KCmg==
MIME-Version: 1.0
X-Received: by 10.224.51.196 with SMTP id e4mr10876416qag.16.1386369861031; Fri, 06 Dec 2013 14:44:21 -0800 (PST)
Received: by 10.140.101.40 with HTTP; Fri, 6 Dec 2013 14:44:20 -0800 (PST)
In-Reply-To: <4110D5CF-3720-4215-914E-0F0395207BB5@vpnc.org>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <CAChr6Sx2g=DtwJbnMHugsoU4Rti_MsPjpOmG+=jWMBaPR3xs7g@mail.gmail.com> <4110D5CF-3720-4215-914E-0F0395207BB5@vpnc.org>
Date: Fri, 6 Dec 2013 14:44:20 -0800
Message-ID: <CAChr6Swv1LE0qSOZFd7YG_O78Qoa-nZpbCHNWMKJPG_XoacBLA@mail.gmail.com>
From: R S <sayrer@gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary=001a11c29e50183a6604ece5633b
Cc: JSON WG <json@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 22:44:27 -0000

--001a11c29e50183a6604ece5633b
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Dec 5, 2013 at 11:13 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

>
> The topic of "should we just refer to Ecma" came up multiple times before
> Ecma produced ECMA-404, and each time the consensus was to keep our
> definition.


In that case, I don't understand what the factual basis for the text in
this paragraph is. It sounds like editorializing.

- Rob

--001a11c29e50183a6604ece5633b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Dec 5, 2013 at 11:13 AM, Paul Hoffman <span dir=3D=
"ltr">&lt;<a href=3D"mailto:paul.hoffman@vpnc.org" target=3D"_blank">paul.h=
offman@vpnc.org</a>&gt;</span> wrote:<div class=3D"gmail_extra"><div class=
=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div>

<br>
</div>The topic of &quot;should we just refer to Ecma&quot; came up multipl=
e times before Ecma produced ECMA-404, and each time the consensus was to k=
eep our definition.</blockquote><div><br></div><div>In that case, I don&#39=
;t understand what the factual basis for the text in this paragraph is. It =
sounds like editorializing.</div>
<div><br></div><div><span style=3D"font-size:13px;font-family:arial,sans-se=
rif">- Rob</span></div></div></div></div>

--001a11c29e50183a6604ece5633b--

From allen@wirfs-brock.com  Fri Dec  6 15:00:49 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4001AE108 for <json@ietfa.amsl.com>; Fri,  6 Dec 2013 15:00:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 eCNyWmCqaGD1 for <json@ietfa.amsl.com>; Fri,  6 Dec 2013 15:00:46 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0271AE09C for <json@ietf.org>; Fri,  6 Dec 2013 15:00:46 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1Vp4Ny-0009kM-Sz; Fri, 06 Dec 2013 23:00:39 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18G/1895qVRy+toGFeFYr5Qr0d5cdJ73tg=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <20131206205613.GA3577@gmail.com>
Date: Fri, 6 Dec 2013 15:00:31 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com>
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.1085)
Cc: JSON WG <json@ietf.org>, Carsten Bormann <cabo@tzi.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 23:00:49 -0000

On Dec 6, 2013, at 12:56 PM, Nico Williams wrote:

> On Fri, Dec 06, 2013 at 11:50:13AM -0800, Allen Wirfs-Brock wrote:
>> In practice, JSON is almost useless without schema level semantic
>> agreement between the producer and consumer of a JSON text. Most of
>=20
> Yes.
>=20
>> the issues we are discussing here are easily subsumed by such schema
>> level agreements.
>=20
> Hmmm, well, there has to be some meta-schema.
>=20
> That arrays preserve order is meta-schema for JSON, else we'd have no
> interop -- and this is critical for comparisons, so specifying this =
bit
> of meta-schema/ semantics enables very important semantics: arrays can
> be compared for equivalence without having to sort them (which would
> require further specification of collation for all JSON values!).

What "array" are you talking about.  The an 'array' symbol sequence in a =
JSON text? A language-specific array-like data structure generated from =
such a symbol sequence by the parser for a specific JSON language =
binding?  A domain data structure generate by a schema aware parser?=20

Why shouldn't an schema be allowed to consider the following to be =
semantically equivalent:
      {"unordered-list": [0,1]}
and
      {"unordered-list": [1,0]}

Besides, we already agreed above that if you don't have schema-level =
agreement then JSON is almost useless.  So why not just let schema =
specifications or schema language specifications handle this.=20

>=20
> That whitespace (outside strings) is not significant may be expressed
> syntactically or semantically, but this has to be universally agreed =
if
> we'll have any chance of interoperating.

ECMA-404 states where insignificant whitespace is allowed. Is there any =
disagreement about this?

>=20
> That object names (keys) are not dups is trickier: for on-line
> processing there may be no way to detect dups or do anything about =
them,
> but for many common implementations object name uniqueness is very =
much
> a requirement.  So here, finally, we have a bit of semantics that =
could
> be in the spec but could be left out (we spent a lot of time on the
> current consensus for RFC4627bis, and I think it's safe to say that
> we're all happy with it)

Should be left out.  Both because of legacy precedent and because it can =
be dealt with that a language binding or schema semantics specification.

But I think we are already in agreement on leaving this out at the =
static semantic level.=20

>=20
> That objects name order is irrelevant and non-deterministic is widely
> assumed/accepted (though often users ask that JSON filters preserve
> object name order from input to output).  (And, of course, for on-line
> encoders and parsers name order could well be made significant, but
> building schemas that demand ordered names means vastly limiting the
> world of JSON tooling that can be used to interoperably implement such
> schemas.)

Object name ordering is significant to widely used JSON language =
bindings (eg, the ECMA-262 JSON parser).  But again this is a semantic =
issue.

Because ECMA-404 is trying to restrict itself to describe the space of =
well-formed JSON text there really is nothing to say about object name =
ordering at that level. It's a semantic issue.=20

>=20
> Similarly for numbers, the *interoperable* number ranges and =
precisions
> are not really syntactic (they could be expressed via syntax, but it'd
> be a pain to do it that way).
>=20
> I think it's clear that we have consensus in the IETF JSON WG for:
>=20
> - whitespace semantics (not significant outside strings)
this is a syntactic issue that is covered by ECMA-404
> - array element order semantics (elements are "ordered")
> - object name dups/order semantics (names SHOULD be unique, but =
interop
>   considerations described; name/value pairs are "unordered")
> - no real constraints on numeric values but interoperable
>   range/precision described
the rest are semantic issues that ECMA-404 does not want to address.  =
The one place it arguably over steps, by saying that "the order of array =
values is significant", really has no associated semantics. This is one =
place where I prefer the current draft language in RFC-4627bis clause 5 =
over the corresponding language in ECMA-404. The Introduction (is the =
intro normative?)  to 4627bis says "an array is an ordered sequence" and =
 "an object is an unordered collection" but I don't see any actual =
contextual meaning given to either "ordered" or "unordered" within the =
document.=20

>=20
> If ECMA-404 differs in any way that does not impose more/different
> semantics, then maybe we don't care as far as RFC4627bis goes. If
> ECMA-404 does impose more/different semantics then we'll care a great
> deal.
If it does, that's unintended and a correctable bug in ECMA-404.
>  Since ECMA-404 targets just the syntax and minimal semantics,
> it's probably just fine for RFC4627bis to reference ECMA-404, but =
since
> RFC4627bis would be specifying a bit more semantics, we'd probably not
> want to make that reference be normative, at least not with some text
> excplaining that it's normative only because we believe that the JSON
> syntax given in both docs are equivalent.

The semantics you want to specify can be layered upon a normative =
reference to ECMA-404. Rather have competing and potentially divergence =
specifications we should be looking a clean separation of concerns.=20

The position stated by TC39 that ECMA-404 already exists as a normative =
specification of the JSON syntax and we have requested that RFC4627bis =
normatively reference it as such and that any restatement of ECMA-404 =
subject matter should be marked as informative.  We think that dueling =
normative specifications would be a bad thing. Seeing that the form of =
expression used by ECMA-404 seems to be a issue for some JSON WG =
participants I have suggested that TC39 could probably be convinced to =
revise ECMA-404 to include a BNF style formalism for the syntax.  If =
there is interest in this alternative I'd be happy to champion it within =
TC39.

Allen=

From mnot@mnot.net  Fri Dec  6 21:20:28 2013
Return-Path: <mnot@mnot.net>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4131AE209 for <json@ietfa.amsl.com>; Fri,  6 Dec 2013 21:20:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 GdbZR3IVtbd2 for <json@ietfa.amsl.com>; Fri,  6 Dec 2013 21:20:24 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id BAEED1ADDDA for <json@ietf.org>; Fri,  6 Dec 2013 21:20:24 -0800 (PST)
Received: from [192.168.1.57] (unknown [118.209.134.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CDDCD509B6; Sat,  7 Dec 2013 00:20:18 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAHBU6iva2H-ovjmfA7=7j2KxUuXAMjhCb8fcMgKxq6hk+A9BtQ@mail.gmail.com>
Date: Sat, 7 Dec 2013 16:20:17 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5D573C1A-BC67-4E00-9EFC-B57172CB0478@mnot.net>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <CAHBU6iva2H-ovjmfA7=7j2KxUuXAMjhCb8fcMgKxq6hk+A9BtQ@mail.gmail.com>
To: "Matt Miller (mamille2)" <mamille2@cisco.com>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Dec 2013 05:20:28 -0000

Hi Matt,

Personal response below.

Generally, negotiation-through-liaison-statement is the WORST possible =
way to communicate. Why don=92t we suggest a joint meeting, or appoint a =
temporary representative on both sides to work through the situation and =
report back, or=85?


On Wed, Dec 4, 2013 at 6:57 PM, Matt Miller (mamille2) =
<mamille2@cisco.com> wrote:

> Hello All,
>=20
> The JSON Working Group has received a statement from Ecma =
International's Technical Committee 39 (TC39) regarding =
draft-ietf-json-rfc4627bis.  The statement can be found at < =
https://datatracker.ietf.org/documents/LIAISON/liaison-2013-11-25-ecma-tc3=
9-json-ecma-tc39-comment-for-rfc-4727bis-attachment-1.pdf >.
>=20
> In response, the Chairs and sponsoring Area Director propose to send =
the following on behalf of the JSON Working Group.  We wish to send the =
response on December 10.  If there are any serious factual errors in the =
following response, let us know before then.  Note that we are *not* =
asking the WG to re-open any of the consensus discussions, simply to see =
if we misstated anything factual.
>=20
>=20
> Thank you,
>=20
> -- Paul Hoffman and Matt Miller
>=20
> -----BEGIN RESPONSE-----
> Thank you for your statement of concern about =
draft-ietf-json-rfc4627bis. The chairs of the IETF's JSON Working Group =
were not aware of any serious concerns that TC39 had with the update =
process. Over the past many months, we repeatedly contacted ECMA and =
TC39 members about the JSON WG and draft-ietf-json-rfc4627bis, but never =
received any significant reply.

Yes, the lack of communication has been unfortunate; I=92m not sure =
driving that point too deeply here is really doing any good.

> We know that some TC39 members joined the JSON WG mailing list but did =
not voice any process concerns in the WG -- or privately to the WG =
Chairs -- before or during either of the Last Calls on the document.

Why the focus on =93process=94 here? I=92d like to believe that we=92re =
engineers focusing on doing the right thing, not just enforcing a =
process.=20

> In the future, it would probably be useful for Ecma and the IETF to =
have a formal liaison relationship. We have heard that there were =
preliminary discussions several months ago, but stopped short of a =
formal relationship before the JSON Working Group was formed. =
Formalizing the liaison relationship will help both SDOs communicate =
with each other and thus avoid late surprises.

Once JSON is done, will there be need for such a liaison in the future?

> As to your specific requests:
>=20
> - In IETF Last Call, there was consensus to change the definition of =
"JSON text" in draft-ietf-json-rfc4627bis to match the one in ECMA-404. =
The latest draft reflects that change. At this point, we believe that =
there are no syntactic differences between the two specifications.
>=20
> - The JSON WG decided to change the title of the document to better =
reflect its content. The current document is much more than a media type =
registration: it repeats the JSON syntax originally documented in RFC =
4627, and has been stable for many years, it is a discussion of the JSON =
semantics important to freestanding encoders and parsers, it is a =
discussion of interoperability issues that have been encountered since =
RFC 4627 and ECMA-262 5th Edition were published, and it is a media type =
registration. Having a more accurate title on the document will help =
readers understand its contents and the difference between it and =
ECMA-404.
>=20
> - After Ecma published ECMA-404, the JSON WG discussed whether to =
remove the ABNF version of the JSON syntax that was established in RFC =
4627 from draft-ietf-json-rfc4627bis; it was decided not to do so. One =
reason is that ECMA-404 uses "racetrack pictures" to define the syntax, =
whereas IETF documents have traditionally used ABNF, and many developers =
have expressed a strong preference for the ABNF. This might be =
considered simply a matter of style, but it was deemed important by many =
WG members. We intend to keep the discussion and reference to ECMA-404 =
in draft-ietf-json-rfc4627bis, even if Ecma continues to choose not to =
reciprocate in ECMA-262 6th Edition, because developers reading =
draft-ietf-json-rfc4627bis might indeed prefer the racetrack pictures.
>=20
> - A normative reference to ECMA-404 would be premature without a clear =
and well-understood document management process. Historically, when =
someone reading an RFC sees a normative reference to one version of =
another SDO's standards, they tend to think the reference will apply to =
future versions of that external standard as well. Given the closed =
process that resulted in ECMA-404, it seems quite possible that Ecma =
could later make changes to ECMA-404 that would have a negative effect =
on interoperability from the Internet perspective. When the IETF =
normatively refers to other standards, it almost exclusively does so to =
standards that were developed with processes that are open to discussion =
and contribution by anyone.

As others have pointed out, this is misleading about the IETF=92s =
requirements for references, and furthermore has a very patronising =
tone. Why don=92t we ask what their intent is for the future of 404, =
rather than tell them what we deem it might be?

> If the IETF believed that future development of ECMA-404 would involve =
a similar kind of open participation as seen with the development of =
draft-ietf-json-rfc4627bis, it could certainly revisit the topic of a =
normative reference in any subsequent update. Such a belief could be one =
of the positive products of a formal liaison relationship between the =
IETF and Ecma.

Getting into an our-process-is-more-open-than-your process fight is =
completely inappropriate, and does not represent the IETF well.=20

Regards,

--
Mark Nottingham   http://www.mnot.net/




From nico@cryptonector.com  Sat Dec  7 03:55:54 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5191AE2C3 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 03:55:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 y8ZsTgqVC3E8 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 03:55:51 -0800 (PST)
Received: from homiemail-a110.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id BCAD01AE197 for <json@ietf.org>; Sat,  7 Dec 2013 03:55:51 -0800 (PST)
Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id 8A3A22005D906; Sat,  7 Dec 2013 03:55:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=PZ3ck1kzTR2pdH eYX5wZKXhd6u0=; b=inYDt1R7KnFCa2K08aUD+FdyCBn6s593Vrqb/PXIOa3H0x LuAg9OJaApAlAq3LuUAcYY4Ch/H59/Q2aX6g5ouPxRVu4g7RQ/0CT4Yw8pRBwsBR Q5lhXFu0yESLFCfF1wnwMXkDMa0XCqKxhtpAxojf2YwoSMesstzrg3zsv756w=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPA id ECBE22005D903; Sat,  7 Dec 2013 03:55:46 -0800 (PST)
Date: Sat, 7 Dec 2013 05:55:46 -0600
From: Nico Williams <nico@cryptonector.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Message-ID: <20131207115542.GA4067@localhost>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: JSON WG <json@ietf.org>, Carsten Bormann <cabo@tzi.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Dec 2013 11:55:54 -0000

On Fri, Dec 06, 2013 at 03:00:31PM -0800, Allen Wirfs-Brock wrote:
> On Dec 6, 2013, at 12:56 PM, Nico Williams wrote:
> > Hmmm, well, there has to be some meta-schema.
> > 
> > That arrays preserve order is meta-schema for JSON, else we'd have no
> > interop -- and this is critical for comparisons, so specifying this bit
> > of meta-schema/ semantics enables very important semantics: arrays can
> > be compared for equivalence without having to sort them (which would
> > require further specification of collation for all JSON values!).
> 
> What "array" are you talking about.  The an 'array' symbol sequence in
> a JSON text? A language-specific array-like data structure generated
> from such a symbol sequence by the parser for a specific JSON language
> binding?  A domain data structure generate by a schema aware parser? 

Not the symbol sequence.  The structure normally denoted by the word
"array" in everyday speech.

> Why shouldn't an schema be allowed to consider the following to be semantically equivalent:
>       {"unordered-list": [0,1]}
> and
>       {"unordered-list": [1,0]}

A *schema* is so allowed.

However, if a schema is also to be allowed to treat them as distinct
then the *meta-schema* must treat them as distinct.  I.e., no matter
what generic programming language bindings of JSON one users, the above
two JSON texts must produce equivalent results when parsed!

The application is clearly free to then re-order those arrays' elements,
or to compare them as equivalent.  The application cannot consider them
not equivalent if the parsers/encoders don't either.

> Besides, we already agreed above that if you don't have schema-level
> agreement then JSON is almost useless.  So why not just let schema
> specifications or schema language specifications handle this. 

Because generic filters/tools/apps exist that would be non-conformant if
they have any expectation about array order preservation in *parsers*
and *encoders* of related tooling.

I.e., I very much expect these jq filters to repeat their inputs as-is
without re-ordering any arrays in them (but they may definitely change
things like whitespace and it may re-order names in objects):

    jq .
    jq '[.[]]'

I also expect all of the C JSON libraries I know and have written code
to (I think that's four C JSON libraries) to preserve array order when
parsing / encoding JSON texts.  It'd be extremely strange to not be able
to implement a JSON-using application that cares about array order!

> > That whitespace (outside strings) is not significant may be expressed
> > syntactically or semantically, but this has to be universally agreed if
> > we'll have any chance of interoperating.
> 
> ECMA-404 states where insignificant whitespace is allowed. Is there
> any disagreement about this?

No.  I was listing some cases where there can be significant differences
in the "syntax only" vs. "syntax and [some] semantics" approaches.

If ECMA TC39 were to insist that arrays in JSON texts do not denote
order, that parsers may re-order array elements at will, say, then I
suspect I'd bet this WG would just... note that difference and move on.
There's no chance, I think, that the IETF would accept such a departure
from RFC4627 (which says that an array "is an ordered sequence of zero
or more values").  The proposal that the original RFC title be restored
is much less controversial than the idea that JSON arrays are not
ordered.

> > That object names (keys) are not dups is trickier: for on-line
> > processing there may be no way to detect dups or do anything about them,
> > but for many common implementations object name uniqueness is very much
> > a requirement.  So here, finally, we have a bit of semantics that could
> > be in the spec but could be left out (we spent a lot of time on the
> > current consensus for RFC4627bis, and I think it's safe to say that
> > we're all happy with it)
> 
> Should be left out.  Both because of legacy precedent and because it
> can be dealt with that a language binding or schema semantics
> specification.

I believe the current consensus on this is just right.  I disagreed with
the old consensus regarding top-level values, but it is easier to make a
strong argument for relaxing a requirement that's routinely violated
than for relaxing a recommendation regardless of how commonly the latter
gets ignored.  (And that is precisely why the consensus regarding the
top-level value constraint changed.)

> But I think we are already in agreement on leaving this out at the
> static semantic level. 

No, we aren't.  We're in agreement that there shouldn't be a requirement
to not have dup names.  That's as far as we can go.

> > That objects name order is irrelevant and non-deterministic is widely
> > assumed/accepted (though often users ask that JSON filters preserve
> > object name order from input to output).  (And, of course, for on-line
> > encoders and parsers name order could well be made significant, but
> > building schemas that demand ordered names means vastly limiting the
> > world of JSON tooling that can be used to interoperably implement such
> > schemas.)
> 
> Object name ordering is significant to widely used JSON language
> bindings (eg, the ECMA-262 JSON parser).  But again this is a semantic
> issue.

But there's no general requirement that object name order be preserved.
Or at least I don't see you asserting that there is.  (But if you were,
you'd care a lot about this semantic issue, and you'd want that bit of
semantics specified somewhere, surely.)

That specific programming language bindings/APIs/implementations make
object name significant (or preserve it) does not impose a requirement
to preserve object name order on other implementations that don't do so
today.  A great many implementations use hash tables to represent
objects internally, and they lose any other object name ordering.

> Because ECMA-404 is trying to restrict itself to describe the space of
> well-formed JSON text there really is nothing to say about object name
> ordering at that level. It's a semantic issue. 

Of course.  And RFC4627 does deal with semantics.  It is appropriate for
RFC4627bis to do so as well.  Even if we agreed to drop all RFC2119
language as to semantics we'd still keep interoperability notes about
the old (and widely-deployed) semantics.

> The semantics you want to specify can be layered upon a normative
> reference to ECMA-404. Rather have competing and potentially
> divergence specifications we should be looking a clean separation of
> concerns. 

We already have a clean separation in RFC4627bis: there's the ABNF
(syntax) and everything else (semantics).  And we all now seem to agree
that the ABNF in draft-ietf-json-rfc4627bis-08 is equivalent to the
syntax in ECMA-404.  If the title of RFC4627 is restored then what ECMA
concerns remain?

> The position stated by TC39 that ECMA-404 already exists as a
> normative specification of the JSON syntax and we have requested that
> RFC4627bis normatively reference it as such and that any restatement
> of ECMA-404 subject matter should be marked as informative.  We think
> that dueling normative specifications would be a bad thing. Seeing
> that the form of expression used by ECMA-404 seems to be a issue for
> some JSON WG participants I have suggested that TC39 could probably be
> convinced to revise ECMA-404 to include a BNF style formalism for the
> syntax.  If there is interest in this alternative I'd be happy to
> champion it within TC39.

Is there an assertion that ECMA-404 and draft-ietf-json-rfc4627bis-08
disagree as to syntax?  I don't think so.  There's a concern that they
might, and the easiest way to resolve that concern is to use the same
syntax specification in both cases.  It would help a lot if TC39 were to
publish an ABNF syntax for JSON texts, but even without that it's pretty
clear that the two documents do not disagree as to syntax.

Nico
-- 

From cabo@tzi.org  Sat Dec  7 04:11:11 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB451AE2D3 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 04:11:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 dUC0EgKLWKte for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 04:11:09 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 999CA1AE197 for <json@ietf.org>; Sat,  7 Dec 2013 04:11:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB7CAt14002709; Sat, 7 Dec 2013 13:10:55 +0100 (CET)
Received: from [192.168.217.143] (p54893CB8.dip0.t-ipconnect.de [84.137.60.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3B6084F5; Sat,  7 Dec 2013 13:10:54 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20131207115542.GA4067@localhost>
Date: Sat, 7 Dec 2013 13:10:51 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost>
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.1822)
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Dec 2013 12:11:11 -0000

On 07 Dec 2013, at 12:55, Nico Williams <nico@cryptonector.com> wrote:

> And we all now seem to agree
> that the ABNF in draft-ietf-json-rfc4627bis-08 is equivalent to the
> syntax in ECMA-404.

Yes, we like to believe that.
The thing that worries me is that nobody knows whether that is actually =
true.

(At least I=92d hope someone who is comfortable with the description =
methods in ECMA-404 makes a serious pass at establishing this =
equivalence, even when it=92s ultimately not possible to actually prove =
it.  That someone will not be me.)

Gr=FC=DFe, Carsten


From paul.hoffman@vpnc.org  Sat Dec  7 08:10:19 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70ACF1AE39E for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 08:10:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 h0pxHSafXCaQ for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 08:10:18 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 97B0B1AE399 for <json@ietf.org>; Sat,  7 Dec 2013 08:10:17 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB7GABtO014069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 7 Dec 2013 09:10:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <5D573C1A-BC67-4E00-9EFC-B57172CB0478@mnot.net>
Date: Sat, 7 Dec 2013 08:10:09 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <E456E2BC-477A-4306-B676-8BDD52637CFB@vpnc.org>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <CAHBU6iva2H-ovjmfA7=7j2KxUuXAMjhCb8fcMgKxq6hk+A9BtQ@mail.gmail.com> <5D573C1A-BC67-4E00-9EFC-B57172CB0478@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Dec 2013 16:10:19 -0000

<hat on>
<acknowledgement that Matt might disagree with some parts and can speak =
for himself>

On Dec 6, 2013, at 9:20 PM, Mark Nottingham <mnot@mnot.net> wrote:

> Generally, negotiation-through-liaison-statement is the WORST possible =
way to communicate.

Fully agree. The response we propose to give is not "negotiation", it's =
a definitive response.

> Why don=92t we suggest a joint meeting, or appoint a temporary =
representative on both sides to work through the situation and report =
back, or=85?

We've had two face-to-face WG meetings since Ecma, and TC39 in specific, =
was actively and repeatedly invited to participate. If those weren't =
convenient, TC39 could have invited us to their face-to-face meetings, =
or asked for an interim or virtual interim.

>> -----BEGIN RESPONSE-----
>> Thank you for your statement of concern about =
draft-ietf-json-rfc4627bis. The chairs of the IETF's JSON Working Group =
were not aware of any serious concerns that TC39 had with the update =
process. Over the past many months, we repeatedly contacted ECMA and =
TC39 members about the JSON WG and draft-ietf-json-rfc4627bis, but never =
received any significant reply.
>=20
> Yes, the lack of communication has been unfortunate; I=92m not sure =
driving that point too deeply here is really doing any good.

The lack of communication up to this point, despite efforts on the part =
of the IETF, seems quite relevant in that Ecma is asking for substantial =
changes to the document at the last minute. If their statement was =
"we've asked for this repeatedly and you haven't given a good response", =
or "we didn't know that the IETF was working on this", those would be =
highly germane, but they are saying neither.

>> We know that some TC39 members joined the JSON WG mailing list but =
did not voice any process concerns in the WG -- or privately to the WG =
Chairs -- before or during either of the Last Calls on the document.
>=20
> Why the focus on =93process=94 here? I=92d like to believe that we=92re =
engineers focusing on doing the right thing, not just enforcing a =
process.=20

All of the Ecma requests are for process items (title of the RFC and =
normative referencing). It would be inappropriate for us to ignore their =
requests because they were on process items.

>> In the future, it would probably be useful for Ecma and the IETF to =
have a formal liaison relationship. We have heard that there were =
preliminary discussions several months ago, but stopped short of a =
formal relationship before the JSON Working Group was formed. =
Formalizing the liaison relationship will help both SDOs communicate =
with each other and thus avoid late surprises.
>=20
> Once JSON is done, will there be need for such a liaison in the =
future?

Absolutely. First, Ecma is much more than TC39. But, even if the liaison =
relationship was just for TC39, decisions that TC39 makes about the =
semantics of JSON in ECMAScript have a large affect the interoperability =
of JSON in other areas. Having a much better form of communication than =
we have now could certainly lead to better interoperability in the =
future.

>  . . .
>=20
> As others have pointed out, this is misleading about the IETF=92s =
requirements for references, and furthermore has a very patronising =
tone.

We heard that, and both are being fixed in the final message.

> Why don=92t we ask what their intent is for the future of 404, rather =
than tell them what we deem it might be?

Because their intent might change over time, just as anyone's might. =
Intention are not promises, nor should they be. If Ecma had looked at =
our intent for rfc4627bis nine months ago and thought they were =
promises, they would be really pissed at us. SDOs doing technical work =
are often surprised by what they find when a lot of different eyes focus =
on the topic, as you are well aware from your current experience in =
httpbis.=20

>> If the IETF believed that future development of ECMA-404 would =
involve a similar kind of open participation as seen with the =
development of draft-ietf-json-rfc4627bis, it could certainly revisit =
the topic of a normative reference in any subsequent update. Such a =
belief could be one of the positive products of a formal liaison =
relationship between the IETF and Ecma.
>=20
> Getting into an our-process-is-more-open-than-your process fight is =
completely inappropriate, and does not represent the IETF well.=20

We heard that, and we will are softening this bit as well.

--Paul Hoffman=

From allen@wirfs-brock.com  Sat Dec  7 10:05:39 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7FA1AE3CA for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 10:05:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 7fg39-X6weE7 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 10:05:35 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id C7CD81AE3BC for <json@ietf.org>; Sat,  7 Dec 2013 10:05:34 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1VpMFq-0006Fe-BN; Sat, 07 Dec 2013 18:05:26 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX198vwt8AzrBzHHSfsaq7R+a6mxt+tVBGQ8=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <20131207115542.GA4067@localhost>
Date: Sat, 7 Dec 2013 10:05:19 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost>
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.1085)
Cc: JSON WG <json@ietf.org>, Carsten Bormann <cabo@tzi.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Dec 2013 18:05:39 -0000

On Dec 7, 2013, at 3:55 AM, Nico Williams wrote:

> On Fri, Dec 06, 2013 at 03:00:31PM -0800, Allen Wirfs-Brock wrote:
>> On Dec 6, 2013, at 12:56 PM, Nico Williams wrote:
>>> ...
>=20
>> Why shouldn't an schema be allowed to consider the following to be =
semantically equivalent:
>>      {"unordered-list": [0,1]}
>> and
>>      {"unordered-list": [1,0]}
>=20
> A *schema* is so allowed.
>=20
> However, if a schema is also to be allowed to treat them as distinct
> then the *meta-schema* must treat them as distinct.  I.e., no matter
> what generic programming language bindings of JSON one users, the =
above
> two JSON texts must produce equivalent results when parsed!

"Equivalent" according to what definition?

The most basic form of parsing translator, beyond a simple recognizer =
that reports valid/invalid, is a translator that produces a parse tree. =
So lets assume that we create such a parse tree generator using the =
4627bis grammar.  The parse trees for the two JSON arrays shown above =
will be different.  As you correctly state, if they weren't then any =
down stream semantics could not apply different meaning to them.  So, in =
what sense are you saying that the result of parsing (in this case the =
parse trees) must be equivalent?

>=20
> The application is clearly free to then re-order those arrays' =
elements,
> or to compare them as equivalent.  The application cannot consider =
them
> not equivalent if the parsers/encoders don't either.

Similarly, the JSON texts:
   {"1":  1, "2", 2}
and
   {"2":  2, "1": 1}

or the JSON texts:
   {"a": 1, "a": 2}
and
   {"a": 2, "a": 1}

have an ordering of the object members that must be preserved by the =
parser in order for downstream semantics to be applied.  And, in the =
real world, this ordering can be quite significant.  For example, for =
both of these cases, the standard JSON to JavaScript language binding =
produces observably different results.=20

I think that if we cut through the rhetoric we are probably in =
agreement.   Within a JSON text, there is a clearly observable ordering =
to both the values that are elements of a JSON array and to the members =
of a JSON object.   Parsing must preserve this order, in both cases, =
because downstream semantics may be dependent upon the orderings.

If we agree to that, then at the level of defining JSON syntax it seems =
that an assertion that JSON arrays are ordered is redundant (the grammar =
already tells us that) and an assertion that the members of a JSON =
object are unordered is incorrect.=20

Where we seem to disagree is on if or where any such ordering =
requirements might be imposed. My contention is that they don't belong =
in a syntactic level specification such as ECMA-404 but do belong in =
downstream specifications for data models, language bindings, or =
application level schema.=20

>=20
>> Besides, we already agreed above that if you don't have schema-level
>> agreement then JSON is almost useless.  So why not just let schema
>> specifications or schema language specifications handle this.=20
>=20
> Because generic filters/tools/apps exist that would be non-conformant =
if
> they have any expectation about array order preservation in *parsers*
> and *encoders* of related tooling.
>=20
> I.e., I very much expect these jq filters to repeat their inputs as-is
> without re-ordering any arrays in them (but they may definitely change
> things like whitespace and it may re-order names in objects):

No, this is where we diverge.  Ordering of names within objects can and =
does, in the real world, have significance. A generic tools that changes =
member order within a JSON object will break things.

>=20
>    jq .
>    jq '[.[]]'
>=20
> I also expect all of the C JSON libraries I know and have written code
> to (I think that's four C JSON libraries) to preserve array order when
> parsing / encoding JSON texts.  It'd be extremely strange to not be =
able
> to implement a JSON-using application that cares about array order!

and similarly for JSON-using applications that care about object member =
order

>=20
>>> That whitespace (outside strings) is not significant may be =
expressed
>>> syntactically or semantically, but this has to be universally agreed =
if
>>> we'll have any chance of interoperating.
>>=20
>> ECMA-404 states where insignificant whitespace is allowed. Is there
>> any disagreement about this?
>=20
> No.  I was listing some cases where there can be significant =
differences
> in the "syntax only" vs. "syntax and [some] semantics" approaches.
>=20
> If ECMA TC39 were to insist that arrays in JSON texts do not denote
> order, that parsers may re-order array elements at will, say, then I
> suspect I'd bet this WG would just... note that difference and move =
on.
> There's no chance, I think, that the IETF would accept such a =
departure
> from RFC4627 (which says that an array "is an ordered sequence of zero
> or more values").  The proposal that the original RFC title be =
restored
> is much less controversial than the idea that JSON arrays are not
> ordered.

Hopefully, it is now clear that this is not what I'm arguing for.  Any =
statement about array ordering is redundant because the grammar already =
covers that. The only harm is in somebody misconstruing it to be a =
requirement about downstream semantics.  However, the same is true about =
Object members.  You assertion that a generic filter is free to reorder =
members is a good example of how a statement about ordering, at this =
level of specification, can be misconstrued.=20

... [snipping back and forth that I think is already addressed above]
>>=20
>> Object name ordering is significant to widely used JSON language
>> bindings (eg, the ECMA-262 JSON parser).  But again this is a =
semantic
>> issue.
>=20
> But there's no general requirement that object name order be =
preserved.
> Or at least I don't see you asserting that there is.  (But if you =
were,
> you'd care a lot about this semantic issue, and you'd want that bit of
> semantics specified somewhere, surely.)

It's hopefully clear by now that, yes I am asserting that object name =
order is important.=20

And I do care about the semantic issues.  They just don't belong in a =
syntactic level specification of the JSON format such as ECMA-404. A =
problem I see with the RFC4627bis is that it conflates a syntactic level =
specification with a just little bit of semantic data model. It is =
neither a pure syntactic specification nor a complete data model.

> That specific programming language bindings/APIs/implementations make
> object name significant (or preserve it) does not impose a requirement
> to preserve object name order on other implementations that don't do =
so
> today.  A great many implementations use hash tables to represent
> objects internally, and they lose any other object name ordering.
>=20
>> Because ECMA-404 is trying to restrict itself to describe the space =
of
>> well-formed JSON text there really is nothing to say about object =
name
>> ordering at that level. It's a semantic issue.=20
>=20
> Of course.  And RFC4627 does deal with semantics.  It is appropriate =
for
> RFC4627bis to do so as well.  Even if we agreed to drop all RFC2119
> language as to semantics we'd still keep interoperability notes about
> the old (and widely-deployed) semantics.
>=20
>> The semantics you want to specify can be layered upon a normative
>> reference to ECMA-404. Rather have competing and potentially
>> divergence specifications we should be looking a clean separation of
>> concerns.=20
>=20
> We already have a clean separation in RFC4627bis: there's the ABNF
> (syntax) and everything else (semantics).  And we all now seem to =
agree
> that the ABNF in draft-ietf-json-rfc4627bis-08 is equivalent to the
> syntax in ECMA-404.  If the title of RFC4627 is restored then what =
ECMA
> concerns remain?

Multiple normative definitions of the same material.  Whether they are =
equivalent is a matter of interpretation and opinion that can lead to =
confusion and possibly divergence over time. A solution to this was =
requested in the TC39 feedback.  RFC4627bis should normatively reference =
ECMA-404 WRT to the syntax and static semantics of JSON. If it chooses =
to also restate the ECMA-404 grammar in a different notation (ie, ABNF) =
that material should be designate as informative with ECMA-404 serving =
as the normative specification of that material.

>=20
>> The position stated by TC39 that ECMA-404 already exists as a
>> normative specification of the JSON syntax and we have requested that
>> RFC4627bis normatively reference it as such and that any restatement
>> of ECMA-404 subject matter should be marked as informative.  We think
>> that dueling normative specifications would be a bad thing. Seeing
>> that the form of expression used by ECMA-404 seems to be a issue for
>> some JSON WG participants I have suggested that TC39 could probably =
be
>> convinced to revise ECMA-404 to include a BNF style formalism for the
>> syntax.  If there is interest in this alternative I'd be happy to
>> champion it within TC39.
>=20
> Is there an assertion that ECMA-404 and draft-ietf-json-rfc4627bis-08
> disagree as to syntax?  I don't think so.  There's a concern that they
> might, and the easiest way to resolve that concern is to use the same
> syntax specification in both cases.  It would help a lot if TC39 were =
to
> publish an ABNF syntax for JSON texts, but even without that it's =
pretty
> clear that the two documents do not disagree as to syntax.

Then I think we should be close to agreement.  Does the JSON WG wish to =
formally request that TC39 add a ABNF specification to a new edition of =
ECMA-404?  Would RFC4627bis then normatively reference ECMA-404?

Allen=

From cabo@tzi.org  Sat Dec  7 12:30:27 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D921AE078 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 12:30:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 Zz1uT4vLTuB4 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 12:30:26 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C61541AE3E9 for <json@ietf.org>; Sat,  7 Dec 2013 12:30:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB7KUCDw007988; Sat, 7 Dec 2013 21:30:12 +0100 (CET)
Received: from [192.168.217.105] (p54893CB8.dip0.t-ipconnect.de [84.137.60.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3AC5E5E6; Sat,  7 Dec 2013 21:30:11 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com>
Date: Sat, 7 Dec 2013 21:30:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
X-Mailer: Apple Mail (2.1822)
Cc: Nico Williams <nico@cryptonector.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Dec 2013 20:30:27 -0000

On 07 Dec 2013, at 19:05, Allen Wirfs-Brock <allen@wirfs-brock.com> =
wrote:

> Parsing must preserve this order, in both cases, because downstream =
semantics may be dependent upon the orderings.

That would be a major breaking change.  The JSON WG is chartered not to =
do those.

If the purpose of removing semantics from the specification is to create =
a derivative of JSON where this matters, I can finally have my binary =
data in JSON.  You see, I have proposed for a while that any string that =
is immediately preceded by two newlines is interpreted as a base64url =
representation of a binary string instead of a text string.  Problem =
solved.

If this usage of whitespace seems somehow revolting, maybe you get an =
idea of how unacceptable reducing the definition of JSON to its syntax =
is.  Interoperability requires more than common syntax.

In JSON, objects are unordered collections or sets of name/value pairs.  =
It says so right there on json.org (=93sets=94), and it says so in RFC =
4627 (=93collections=94)*).  We may not like it, but it has been a =
promise for a decade.  We need to heed it.  (Another promise was that =
JSON doesn=92t change**).)

Data interchange formats where this is not the case may be using the =
JSON syntax, but aren=92t JSON.

Gr=FC=DFe, Carsten

*) (The difference is unfortunate, but a fact that we need to deal =
with.)

**) Which can=92t be strictly true, as JSON is as much defined by the =
collection of its implementations as by its specification.  But that=92s =
just limiting the extent of the promise, not giving us a free get out of =
jail card.


From allen@wirfs-brock.com  Sat Dec  7 15:05:29 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF80E1AE44A for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 15:05:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 PQWjGt9-VyCC for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 15:05:27 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 808D91AE401 for <json@ietf.org>; Sat,  7 Dec 2013 15:05:26 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1VpQw2-000IUv-Q2; Sat, 07 Dec 2013 23:05:19 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/ufTmGkY99NLMWaWy9dt1oYefbMerUENM=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=windows-1252
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org>
Date: Sat, 7 Dec 2013 15:05:11 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.1085)
Cc: JSON WG <json@ietf.org>, Nico Williams <nico@cryptonector.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Dec 2013 23:05:29 -0000

On Dec 7, 2013, at 12:30 PM, Carsten Bormann wrote:

> On 07 Dec 2013, at 19:05, Allen Wirfs-Brock <allen@wirfs-brock.com> =
wrote:
>=20
>> Parsing must preserve this order, in both cases, because downstream =
semantics may be dependent upon the orderings.
>=20
> That would be a major breaking change.  The JSON WG is chartered not =
to do those.

It is also a major breaking change if downstream semantics can't depend =
upon the ordering of object members.  In particular, it means that the =
standard built-in ECMAScript JSON parsers as well as the classic =
JavaScript eval-based processing will be non-conforming.  The latter is =
particularly puzzling as that was the original basis upon which JSON was =
defined.

In fact, the only place that either the current RFC-4627bis draft or the =
original RFC-4627 says anything about object name/value pairs being =
"unordered" is the their introductions  The 4627bis language appears to =
have been directly copied from the original RFC.  i  It isn't clear =
whether or not the introduction to 4627bis is intended to be normative.  =
If it is, then I note that it also says in both the new and old =
documents) that JSON's design goals were for it to be "a subset of =
JavaScript".  The syntactic elements of JavaScript that correspond to =
the JSON object syntax do have  a specified ordering semantics.

When we prepared ECMA-404 we concluded that characterizing JSON objects =
as unordered was a mistake in the original RFC.  The original author did =
not object to this interpretation.=20

>=20
> If the purpose of removing semantics from the specification is to =
create a derivative of JSON where this matters,

No the purpose is to ensure that the specification remains compatible =
with the most widely deployed JSON parsers.  Specifically, the ECMA-262 =
conforming parsers that are implemented by JavaScript engines in all =
major browsers.=20

> I can finally have my binary data in JSON.  You see, I have proposed =
for a while that any string that is immediately preceded by two newlines =
is interpreted as a base64url representation of a binary string instead =
of a text string.  Problem solved.
>=20
> If this usage of whitespace seems somehow revolting, maybe you get an =
idea of how unacceptable reducing the definition of JSON to its syntax =
is.  Interoperability requires more than common syntax.
>=20
> In JSON, objects are unordered collections or sets of name/value =
pairs.  It says so right there on json.org (=93sets=94), and it says so =
in RFC 4627 (=93collections=94)*).  We may not like it, but it has been =
a promise for a decade.  We need to heed it.  (Another promise was that =
JSON doesn=92t change**).)

You also need to look at objective reality and consider the possibility =
that the informal (and non-normative text) on both the json.org website =
and in the original RFC never actually matched reality.

JSON is derived from JavaSript (whose standard is ECMA-262) and since =
2009, ECMA-262 (and its clone ISO/IEC-16262) has included a normative =
specification for parsing JSON text that includes an ordering semantics =
for object members.

>=20
> Data interchange formats where this is not the case may be using the =
JSON syntax, but aren=92t JSON.

I disagree with this conclusion, but I think you are approaching an =
important point of possible agreement.  The JSON syntax  is used in many =
ways and for many purposes  and if worthy of independent =
standardization.  That is what ECMA-404 does.  The JSON WG is certainly =
free (actually encouraged) to issue a  normative standard that addresses =
interchange requirements for the MIME type application/json.  But that =
should be view only as a spec. for application/json interchange, not the =
one and only JSON specification.

Allen=

From derhoermi@gmx.net  Sat Dec  7 15:50:36 2013
Return-Path: <derhoermi@gmx.net>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04A01AE457 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 15:50:36 -0800 (PST)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 eSCGdLD2STeq for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 15:50:31 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 02FFF1AE45C for <json@ietf.org>; Sat,  7 Dec 2013 15:50:31 -0800 (PST)
Received: from netb.Speedport_W_700V ([91.35.26.74]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0M8JyQ-1Vbc1L3EFG-00vyka for <json@ietf.org>; Sun, 08 Dec 2013 00:50:26 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Sun, 08 Dec 2013 00:50:28 +0100
Message-ID: <bg87a99u4q15ege12m46nf45smatomtsus@hive.bjoern.hoehrmann.de>
References: <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com>
In-Reply-To: <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:G4TAP9wkqmdX563tK33XMQcHR4Q1OehYVKOP+F/AAH3FwpWpwu5 sTnlz9AlpZAWl6rQPg5YajviAnN1uTLMIoMkMQbBvNs5gUDQna8lBhiJiwQKE41K7BI+LiX P+FDmhLXPyvTqdHfSjii00lNFcIV7gJ3gWn2LPrFJlWu2qnXdWEsY5Lq7+1AJZjGXNeqtii HRnS/jc9F2Yro8KN793MA==
Cc: Nico Williams <nico@cryptonector.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Dec 2013 23:50:37 -0000

* Allen Wirfs-Brock wrote:
>On Dec 7, 2013, at 3:55 AM, Nico Williams wrote:
>> However, if a schema is also to be allowed to treat them as distinct
>> then the *meta-schema* must treat them as distinct.  I.e., no matter
>> what generic programming language bindings of JSON one users, the above
>> two JSON texts must produce equivalent results when parsed!
>
>"Equivalent" according to what definition?

I suspect intended was "must not produce".

>And I do care about the semantic issues.  They just don't belong in a 
>syntactic level specification of the JSON format such as ECMA-404. A 
>problem I see with the RFC4627bis is that it conflates a syntactic level 
>specification with a just little bit of semantic data model. It is 
>neither a pure syntactic specification nor a complete data model.

  JSON_texts = {     x | x is a JSON text }

  JSON_diffs = { (a,b) | a and b are elements of JSON_texts and
                         a is significantly different from b }

A pure specification in your sense above defines only membership in the
`JSON_texts` set. ECMA-404 is not pure in this sense because it defines
that e.g. `("[]", "[ ]")` is not a member of `JSON_diffs`. 

ECMA-404 does not define that

  ('{"x":1,"y":2}', '{"y":2,"x":1}')

is not a member of `JSON_diffs`. Right? It says the white space in the
example is insignificant, but it does not say order of key-value-pairs
in objects is insignificant. Carsten Bormann gave other examples like
ECMA-404's definition of equivalent escape sequences.

Readers of ECMA-404 might assume that it gives a complete description
of what people developing and operating JSON-based systems agree are
significant differences. They might build systems that rely on the order
of key-value-pairs in objects because of this, for instance

  http://wiki.apache.org/solr/UpdateJSON#Solr_3.1_Example

Systems like ecmascript's `JSON.stringify` API cannot ordinarily create
such JSON texts and would be unable to interact with such a system. That
is something the IETF JSON Working Group wishes to avoid, accordingly
they provide a more complete definition of the `JSON_diffs` equivalence
relation that better reflects rough consensus and running code of the
JSON community.

I believe the combination of impurity and incompleteness in ECMA-404 is
harmful to the JSON community.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From nico@cryptonector.com  Sat Dec  7 15:52:03 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF6E1AE457 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 15:52:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 9TORF-GmX-1K for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 15:52:01 -0800 (PST)
Received: from homiemail-a95.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 39C511AE133 for <json@ietf.org>; Sat,  7 Dec 2013 15:52:01 -0800 (PST)
Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 18C2E1E05C; Sat,  7 Dec 2013 15:51:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Y6ytmBrwjwM1CE 9NbHQLb4n/qdg=; b=x6UkcmPG4il0atwN4YS+MjQ3jQkjr3ILuMQFiFQmLMxoiY VxLYYyiHfnSN11gRu6gpb25k9Uapz0YjFypXBjOKZRzy3CBlMHkahs2ggnbhBauk ZoC8K7/JfOOGbvMjSiyZTParKWHzxH6r0omay+d5pap9pJ6JHs33Eg9bxZKqQ=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPA id 6C7551E059; Sat,  7 Dec 2013 15:51:56 -0800 (PST)
Date: Sat, 7 Dec 2013 17:51:55 -0600
From: Nico Williams <nico@cryptonector.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Message-ID: <20131207235151.GB4067@localhost>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: JSON WG <json@ietf.org>, Carsten Bormann <cabo@tzi.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Dec 2013 23:52:03 -0000

BTW, could someone please see to it that the es-discuss accept posts
from all json@ietf.org subscribers, or at least active participants?
(And vice-versa.)

On Sat, Dec 07, 2013 at 10:05:19AM -0800, Allen Wirfs-Brock wrote:
> On Dec 7, 2013, at 3:55 AM, Nico Williams wrote:
> > A *schema* is so allowed.
> > 
> > However, if a schema is also to be allowed to treat them as distinct
> > then the *meta-schema* must treat them as distinct.  I.e., no matter
> > what generic programming language bindings of JSON one users, the above
> > two JSON texts must produce equivalent results when parsed!
> 
> "Equivalent" according to what definition?
> 
> The most basic form of parsing translator, beyond a simple recognizer
> that reports valid/invalid, is a translator that produces a parse
> tree. So lets assume that we create such a parse tree generator using
> the 4627bis grammar.  The parse trees for the two JSON arrays shown
> above will be different.  As you correctly state, if they weren't then
> [...]

Can you please explaing how the RFC4627bis ABNF allows parsers to treat
two differently-ordered (but otherwise equivalent) arrays as equivalent?

(Keeping in mind that a parser does not deal in equivalence, which means
that the only way a parser could do this would be by re-ordering arrays
at will.)

I think you're saying that the ABNF implies ordering within JSON *texts*
for the obvious reason that JSON texts are themselves ordered sequences
of tokens (for the obvious reason that JSON texts are ordered sequences
of characters) but the ABNF does not specify semantics and that an
implementor could choose any semantics they'd like.  That way non-
interoperability lies; we won't go there.


> Similarly, the JSON texts:
>    [examples elided]
> 
> have an ordering of the object members that must be preserved by the
> parser in order for downstream semantics to be applied.  And, in the
> real world, this ordering can be quite significant.  For example, for
> both of these cases, the standard JSON to JavaScript language binding
> produces observably different results. 

I don't recall if you participated in the *very* long threads we had on
this subject.  The mailing list archives are available.  If you didn't
read or participate, please go read those threads, otherwise we'll
simply be retreading and consuming others' precious brain bandwidth.

It's out of perversity that RFC4627bis retains the original's text as to
duplicate object names but adds an interop note.

BTW, this is a very useful link:

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=rfc4627&url2=draft-ietf-json-rfc4627bis-08.txt

> I think that if we cut through the rhetoric we are probably in
> agreement.   Within a JSON text, there is a clearly observable
> ordering to both the values that are elements of a JSON array and to
> the members of a JSON object.   Parsing must preserve this order, in
> both cases, because downstream semantics may be dependent upon the
> orderings.

Yes as to arrays.

As to objects there will be parsers that don't preserve order... because
there are -and long have been- parsers that don't preserve order and
we're NOT going to break them (because the charter doesn't allow it, for
one, but also because we shouldn't do that anyways, and that's why the
charter doesn't allow it).

> If we agree to that, then at the level of defining JSON syntax it
> seems that an assertion that JSON arrays are ordered is redundant (the
> grammar already tells us that) and an assertion that the members of a

Above you argue that the grammar doesn't tell us that.  Which is it?  I
realize that you're being pedantic, but at some point we have to specify
semantics.

> JSON object are unordered is incorrect. 

    NOTE: I don't speak for the WG.  You can read the list archives to
          get your own sense of this.

I'm certain that the WG would agree to updating the interop note in
section 4 to indicate that object name order is significant for some
applications, not just dups.

I'm certain that the WG would not agree to either not specifying this
bit of semantics at all or saying that object name order is significant
and the parsers/encoders MUST preserve it.

At most I could see the WG dropping the "SHOULD be unique"
recommendation.  In that case I would like RFC4627bis to instead say
that applications should specify whether object name order/dups are
significant to them.

> Where we seem to disagree is on if or where any such ordering
> requirements might be imposed. My contention is that they don't belong
> in a syntactic level specification such as ECMA-404 but do belong in
> downstream specifications for data models, language bindings, or
> application level schema. 

If no array ordering requirement is imposed then JSON is useless.  Full stop.

> > If ECMA TC39 were to insist that arrays in JSON texts do not denote
> > order, [...]
> 
> Hopefully, it is now clear that this is not what I'm arguing for.  Any
> statement about array ordering is redundant because the grammar
> already covers that. The only harm is in somebody misconstruing it to
> [...]

It wasn't and still isn't.  Your response is confusing.  You seem to
want us to specify nothing more than syntax and then insist on specific
semantics while wanting them to not be specified.  This is not a recipe
for interoperability -- something we care very much about.

> And I do care about the semantic issues.  They just don't belong in a
> syntactic level specification of the JSON format such as ECMA-404. A
> problem I see with the RFC4627bis is that it conflates a syntactic
> level specification with a just little bit of semantic data model. It
> is neither a pure syntactic specification nor a complete data model.

It is enough of a data model.  It's wishy-washy about object name dups
because it can't be made less so: there are widely deployed
implementations that will not get modified to behave otherwise no matter
what we say.  Reality matters.

> >              [...].  If the title of RFC4627 is restored then what ECMA
> > concerns remain?
> 
> Multiple normative definitions of the same material.  Whether they are
> equivalent is a matter of interpretation and opinion that can lead to
> confusion and possibly divergence over time. A solution to this was
> requested in the TC39 feedback.  RFC4627bis should normatively
> reference ECMA-404 WRT to the syntax and static semantics of JSON. If
> it chooses to also restate the ECMA-404 grammar in a different
> notation (ie, ABNF) that material should be designate as informative
> with ECMA-404 serving as the normative specification of that material.

If ECMA-404 switches to use ABNF then I would agree as to syntax.  I
would not agree that RFC4627bis should not specify semantics (which you
don't demand in the above paragraph, but implied elsewhere) nor that it
specify the semantics you favor (also elsewhere) for the reasons given
above and discussed ad-nauseum on the list.

> > Is there an assertion that ECMA-404 and draft-ietf-json-rfc4627bis-08
> > disagree as to syntax?  I don't think so.  There's a concern that they
> > might, and the easiest way to resolve that concern is to use the same
> > syntax specification in both cases.  It would help a lot if TC39 were to
> > publish an ABNF syntax for JSON texts, but even without that it's pretty
> > clear that the two documents do not disagree as to syntax.
> 
> Then I think we should be close to agreement.  Does the JSON WG wish
> to formally request that TC39 add a ABNF specification to a new
> edition of ECMA-404?  Would RFC4627bis then normatively reference
> ECMA-404?

Both would be good questions for the WG chairs to run a consensus call
on.  I would support an affirmative answer to both, with the caveat that
RFC4627bis should continue to specify semantics with all the
interoperability notes we need to describe reality.

Nico
-- 

From nico@cryptonector.com  Sat Dec  7 16:02:37 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388091AE460 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 16:02:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 BE1WZSfN8zYH for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 16:02:36 -0800 (PST)
Received: from homiemail-a95.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 603AC1AE454 for <json@ietf.org>; Sat,  7 Dec 2013 16:02:36 -0800 (PST)
Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 48AAC1E05C; Sat,  7 Dec 2013 16:02:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=kXXLXLqkxC75oY 6UgYs2m38Wfjk=; b=e2/X4EcB0XM7zF6NDSsT2dxPRCUEGQhvt/9xoJL9LDvzJh QWz0J/qQyna4TNuwq7LWM4eZ261W0zieTIV3WZQV7pnQGk03hTWb1rbvOcCAR/pM nLkX79mRzQhyW2TlROLkgjRGNqWX0P0fvUaF1KKoOQO86e7zp6x3BbhO9fZaY=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPA id 9FABE1E059; Sat,  7 Dec 2013 16:02:31 -0800 (PST)
Date: Sat, 7 Dec 2013 18:02:30 -0600
From: Nico Williams <nico@cryptonector.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Message-ID: <20131208000226.GC4067@localhost>
References: <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: JSON WG <json@ietf.org>, Carsten Bormann <cabo@tzi.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 00:02:37 -0000

On Sat, Dec 07, 2013 at 03:05:11PM -0800, Allen Wirfs-Brock wrote:
> On Dec 7, 2013, at 12:30 PM, Carsten Bormann wrote:
> > On 07 Dec 2013, at 19:05, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote:
> >> Parsing must preserve this order, in both cases, because downstream
> >> semantics may be dependent upon the orderings.
> > 
> > That would be a major breaking change.  The JSON WG is chartered not
> > to do those.
> 
> It is also a major breaking change if downstream semantics can't
> depend upon the ordering of object members.  In particular, it means
> that the standard built-in ECMAScript JSON parsers as well as the
> classic JavaScript eval-based processing will be non-conforming.  The
> latter is particularly puzzling as that was the original basis upon
> which JSON was defined.

We know there are apps that care about object name dups (and, evidently,
order).  We can have a note about them.  We might even have a way to
denote this in schemata or MIME parameters.  But we cannot undo what
RFC4627 said -- it is many years too late to do that.

It would be much more productive to discuss how to accomodate apps for
which object name dups/order is significant than to demand that those
always be significant.  This isn't a personal demand of mine; it's my
description of the WG's consensus and its openness to changing it,
derived from actually having read those 2,000+ messages.  (Note that WG
consensus has changed on various points at times.)

Nico
-- 

From cabo@tzi.org  Sat Dec  7 16:06:04 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849851AE460 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 16:06:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 o5f5eowIR9EA for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 16:06:03 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 137961AE454 for <json@ietf.org>; Sat,  7 Dec 2013 16:06:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB805lx9015372; Sun, 8 Dec 2013 01:05:47 +0100 (CET)
Received: from [192.168.217.105] (p54893CB8.dip0.t-ipconnect.de [84.137.60.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6316360C; Sun,  8 Dec 2013 01:05:46 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com>
Date: Sun, 8 Dec 2013 01:05:44 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <06CE067A-B410-4D36-84A5-6F378EB64D9C@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>, Nico Williams <nico@cryptonector.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 00:06:04 -0000

On 08 Dec 2013, at 00:05, Allen Wirfs-Brock <allen@wirfs-brock.com> =
wrote:

>=20
> On Dec 7, 2013, at 12:30 PM, Carsten Bormann wrote:
>=20
>> On 07 Dec 2013, at 19:05, Allen Wirfs-Brock <allen@wirfs-brock.com> =
wrote:
>>=20
>>> Parsing must preserve this order, in both cases, because downstream =
semantics may be dependent upon the orderings.
>>=20
>> That would be a major breaking change.  The JSON WG is chartered not =
to do those.
>=20
> It is also a major breaking change if downstream semantics can't =
depend upon the ordering of object members. =20

Wait a minute.  It can=92t be a breaking change because it is not a =
change.

JSON parsers are free to implement extensions (section 4), so none of =
the JavaScript extensions make them non-conforming JSON parsers.
Many JSON parsers won=92t implement these extensions, and many JSON =
generators won=92t be able to generate them, so arguing they have become =
part of JSON because they are in one parser doesn=92t quite work.

> When we prepared ECMA-404 we concluded that characterizing JSON =
objects as unordered was a mistake in the original RFC. =20

Silently making this breaking change is a nice illustration for the =
process issues that might make some of us a bit reluctant to use =
ECMA-404 as a normative reference, even if it were turned into a =
technically superior spec.

> The original author did not object to this interpretation.=20

It is, however, still on json.org, so we seem to have a bit of a =
communication problem here.

> JSON is derived from JavaSript

=93Was originally derived=94 would be closer; after JavaScript changed, =
JSON is not even a subset of JavaScript any more.
And that historical ancestry doesn=92t make JavaScript specifications =
the specification for JSON.

> (whose standard is ECMA-262) and since 2009, ECMA-262 (and its clone =
ISO/IEC-16262) has included a normative specification for parsing JSON =
text that includes an ordering semantics for object members.

As it is free to do; that doesn=92t change JSON the data interchange =
format though.

Gr=FC=DFe, Carsten


From tbray@textuality.com  Sat Dec  7 16:43:10 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF841AE46D for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 16:43:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 W4GYGYgC_Jmm for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 16:43:08 -0800 (PST)
Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id DF24D1AE469 for <json@ietf.org>; Sat,  7 Dec 2013 16:43:07 -0800 (PST)
Received: by mail-vc0-f179.google.com with SMTP id ie18so2258490vcb.10 for <json@ietf.org>; Sat, 07 Dec 2013 16:43:03 -0800 (PST)
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:content-type; bh=Ah1tZCrXEwcexj1yScTR22sejhl0wlwsWr+OL+tC5g0=; b=iL349KvQg+FUKtcS+9DFQDJpkrxQbi7qdTYc/4C0kjU54E6cHIq+CB02UzldDcvXAq 1IMS4JBp2t3wRqqcHoD+AqbaP6hkWETv8nsS3vupRYcyU9FY5NmyuXKG48WL+fmAxb+y Wy70BJxYegMEqKmRaQuY+G+0fidIx8BuvAOJ6qjWChd0oIgN9LUb7Mcw6iL6Tnon4djC DyXZqofqMLz0iYAmYb6nL+qJ0fcp317sjCurZ3WijvX3IUd9nH6w0zz+STGdhhZCeWG7 NirtNlncDhnXhB5UpK/wlacghFCxTCAPHi+2GBGIeAzEJl1h0eWwXt8uxZy7iuN2/1c4 q0ow==
X-Gm-Message-State: ALoCoQmLwF9HX6DDnODR7n5EA9uynlzsdV5wnioJKi+1bg3arrQ+Tk8TOHdGxH/O3rIyDjxsaiFu
MIME-Version: 1.0
X-Received: by 10.220.58.1 with SMTP id e1mr6910434vch.0.1386463383329; Sat, 07 Dec 2013 16:43:03 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Sat, 7 Dec 2013 16:43:03 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com>
Date: Sat, 7 Dec 2013 16:43:03 -0800
Message-ID: <CAHBU6it=NXw4EBgxmN-1xA_7hUdMMs77iYaXQs_q0SwkBv_A8Q@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Content-Type: multipart/alternative; boundary=001a11c2c7da758e6604ecfb2948
Cc: JSON WG <json@ietf.org>, Nico Williams <nico@cryptonector.com>, Carsten Bormann <cabo@tzi.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 00:43:11 -0000

--001a11c2c7da758e6604ecfb2948
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I assume all parties to the discussion know that in 100% of all
programming-language libraries in use for dealing with JSON as transmitted
on the wire, JSON objects are loaded into hash tables or dicts or whatever
your language idiom is, and there is no way for software using those
libraries to discover what order they were serialized in, and any
suggestion that this order should be considered significant for application
usage would be regarded as insane.

This gives a close match to the semantics of the built-in
hash/dictionary/associate-array/whatever in popular programming languages,
and is one of the reasons why JSON has been so successful.

It would be completely unacceptable for the RFC to pretend that software
MUST or SHOULD care about the ordering of object members.



On Sat, Dec 7, 2013 at 3:05 PM, Allen Wirfs-Brock <allen@wirfs-brock.com>wr=
ote:

>
> On Dec 7, 2013, at 12:30 PM, Carsten Bormann wrote:
>
> > On 07 Dec 2013, at 19:05, Allen Wirfs-Brock <allen@wirfs-brock.com>
> wrote:
> >
> >> Parsing must preserve this order, in both cases, because downstream
> semantics may be dependent upon the orderings.
> >
> > That would be a major breaking change.  The JSON WG is chartered not to
> do those.
>
> It is also a major breaking change if downstream semantics can't depend
> upon the ordering of object members.  In particular, it means that the
> standard built-in ECMAScript JSON parsers as well as the classic JavaScri=
pt
> eval-based processing will be non-conforming.  The latter is particularly
> puzzling as that was the original basis upon which JSON was defined.
>
> In fact, the only place that either the current RFC-4627bis draft or the
> original RFC-4627 says anything about object name/value pairs being
> "unordered" is the their introductions  The 4627bis language appears to
> have been directly copied from the original RFC.  i  It isn't clear wheth=
er
> or not the introduction to 4627bis is intended to be normative.  If it is=
,
> then I note that it also says in both the new and old documents) that
> JSON's design goals were for it to be "a subset of JavaScript".  The
> syntactic elements of JavaScript that correspond to the JSON object synta=
x
> do have  a specified ordering semantics.
>
> When we prepared ECMA-404 we concluded that characterizing JSON objects a=
s
> unordered was a mistake in the original RFC.  The original author did not
> object to this interpretation.
>
> >
> > If the purpose of removing semantics from the specification is to creat=
e
> a derivative of JSON where this matters,
>
> No the purpose is to ensure that the specification remains compatible wit=
h
> the most widely deployed JSON parsers.  Specifically, the ECMA-262
> conforming parsers that are implemented by JavaScript engines in all majo=
r
> browsers.
>
> > I can finally have my binary data in JSON.  You see, I have proposed fo=
r
> a while that any string that is immediately preceded by two newlines is
> interpreted as a base64url representation of a binary string instead of a
> text string.  Problem solved.
> >
> > If this usage of whitespace seems somehow revolting, maybe you get an
> idea of how unacceptable reducing the definition of JSON to its syntax is=
.
>  Interoperability requires more than common syntax.
> >
> > In JSON, objects are unordered collections or sets of name/value pairs.
>  It says so right there on json.org (=E2=80=9Csets=E2=80=9D), and it says=
 so in RFC 4627
> (=E2=80=9Ccollections=E2=80=9D)*).  We may not like it, but it has been a=
 promise for a
> decade.  We need to heed it.  (Another promise was that JSON doesn=E2=80=
=99t
> change**).)
>
> You also need to look at objective reality and consider the possibility
> that the informal (and non-normative text) on both the json.org website
> and in the original RFC never actually matched reality.
>
> JSON is derived from JavaSript (whose standard is ECMA-262) and since
> 2009, ECMA-262 (and its clone ISO/IEC-16262) has included a normative
> specification for parsing JSON text that includes an ordering semantics f=
or
> object members.
>
> >
> > Data interchange formats where this is not the case may be using the
> JSON syntax, but aren=E2=80=99t JSON.
>
> I disagree with this conclusion, but I think you are approaching an
> important point of possible agreement.  The JSON syntax  is used in many
> ways and for many purposes  and if worthy of independent standardization.
>  That is what ECMA-404 does.  The JSON WG is certainly free (actually
> encouraged) to issue a  normative standard that addresses interchange
> requirements for the MIME type application/json.  But that should be view
> only as a spec. for application/json interchange, not the one and only JS=
ON
> specification.
>
> Allen

--001a11c2c7da758e6604ecfb2948
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I assume all parties to the discussion know that in 100% o=
f all programming-language libraries in use for dealing with JSON as transm=
itted on the wire, JSON objects are loaded into hash tables or dicts or wha=
tever your language idiom is, and there is no way for software using those =
libraries to discover what order they were serialized in, and any suggestio=
n that this order should be considered significant for application usage wo=
uld be regarded as insane. =C2=A0<div>
<br></div><div>This gives a close match to the semantics of the built-in ha=
sh/dictionary/associate-array/whatever in popular programming languages, an=
d is one of the reasons why JSON has been so successful.=C2=A0</div><div><b=
r>
</div><div>It would be completely unacceptable for the RFC to pretend that =
software MUST or SHOULD care about the ordering of object members.</div><di=
v><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_qu=
ote">
On Sat, Dec 7, 2013 at 3:05 PM, Allen Wirfs-Brock <span dir=3D"ltr">&lt;<a =
href=3D"mailto:allen@wirfs-brock.com" target=3D"_blank">allen@wirfs-brock.c=
om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><br>
On Dec 7, 2013, at 12:30 PM, Carsten Bormann wrote:<br>
<br>
&gt; On 07 Dec 2013, at 19:05, Allen Wirfs-Brock &lt;<a href=3D"mailto:alle=
n@wirfs-brock.com">allen@wirfs-brock.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; Parsing must preserve this order, in both cases, because downstrea=
m semantics may be dependent upon the orderings.<br>
&gt;<br>
&gt; That would be a major breaking change. =C2=A0The JSON WG is chartered =
not to do those.<br>
<br>
</div>It is also a major breaking change if downstream semantics can&#39;t =
depend upon the ordering of object members. =C2=A0In particular, it means t=
hat the standard built-in ECMAScript JSON parsers as well as the classic Ja=
vaScript eval-based processing will be non-conforming. =C2=A0The latter is =
particularly puzzling as that was the original basis upon which JSON was de=
fined.<br>

<br>
In fact, the only place that either the current RFC-4627bis draft or the or=
iginal RFC-4627 says anything about object name/value pairs being &quot;uno=
rdered&quot; is the their introductions =C2=A0The 4627bis language appears =
to have been directly copied from the original RFC. =C2=A0i =C2=A0It isn&#3=
9;t clear whether or not the introduction to 4627bis is intended to be norm=
ative. =C2=A0If it is, then I note that it also says in both the new and ol=
d documents) that JSON&#39;s design goals were for it to be &quot;a subset =
of JavaScript&quot;. =C2=A0The syntactic elements of JavaScript that corres=
pond to the JSON object syntax do have =C2=A0a specified ordering semantics=
.<br>

<br>
When we prepared ECMA-404 we concluded that characterizing JSON objects as =
unordered was a mistake in the original RFC. =C2=A0The original author did =
not object to this interpretation.<br>
<div class=3D"im"><br>
&gt;<br>
&gt; If the purpose of removing semantics from the specification is to crea=
te a derivative of JSON where this matters,<br>
<br>
</div>No the purpose is to ensure that the specification remains compatible=
 with the most widely deployed JSON parsers. =C2=A0Specifically, the ECMA-2=
62 conforming parsers that are implemented by JavaScript engines in all maj=
or browsers.<br>

<div class=3D"im"><br>
&gt; I can finally have my binary data in JSON. =C2=A0You see, I have propo=
sed for a while that any string that is immediately preceded by two newline=
s is interpreted as a base64url representation of a binary string instead o=
f a text string. =C2=A0Problem solved.<br>

&gt;<br>
&gt; If this usage of whitespace seems somehow revolting, maybe you get an =
idea of how unacceptable reducing the definition of JSON to its syntax is. =
=C2=A0Interoperability requires more than common syntax.<br>
&gt;<br>
&gt; In JSON, objects are unordered collections or sets of name/value pairs=
. =C2=A0It says so right there on <a href=3D"http://json.org" target=3D"_bl=
ank">json.org</a> (=E2=80=9Csets=E2=80=9D), and it says so in RFC 4627 (=E2=
=80=9Ccollections=E2=80=9D)*). =C2=A0We may not like it, but it has been a =
promise for a decade. =C2=A0We need to heed it. =C2=A0(Another promise was =
that JSON doesn=E2=80=99t change**).)<br>

<br>
</div>You also need to look at objective reality and consider the possibili=
ty that the informal (and non-normative text) on both the <a href=3D"http:/=
/json.org" target=3D"_blank">json.org</a> website and in the original RFC n=
ever actually matched reality.<br>

<br>
JSON is derived from JavaSript (whose standard is ECMA-262) and since 2009,=
 ECMA-262 (and its clone ISO/IEC-16262) has included a normative specificat=
ion for parsing JSON text that includes an ordering semantics for object me=
mbers.<br>

<div class=3D"im"><br>
&gt;<br>
&gt; Data interchange formats where this is not the case may be using the J=
SON syntax, but aren=E2=80=99t JSON.<br>
<br>
</div>I disagree with this conclusion, but I think you are approaching an i=
mportant point of possible agreement. =C2=A0The JSON syntax =C2=A0is used i=
n many ways and for many purposes =C2=A0and if worthy of independent standa=
rdization. =C2=A0That is what ECMA-404 does. =C2=A0The JSON WG is certainly=
 free (actually encouraged) to issue a =C2=A0normative standard that addres=
ses interchange requirements for the MIME type application/json. =C2=A0But =
that should be view only as a spec. for application/json interchange, not t=
he one and only JSON specification.<br>

<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Allen</font></span></blockquote></div><br></div>

--001a11c2c7da758e6604ecfb2948--

From cowan@ccil.org  Sat Dec  7 16:49:43 2013
Return-Path: <cowan@ccil.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49ECA1AE46E for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 16:49:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 ZGKxzmc2jlee for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 16:49:41 -0800 (PST)
Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1D51AE46D for <json@ietf.org>; Sat,  7 Dec 2013 16:49:41 -0800 (PST)
Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from <cowan@ccil.org>) id 1VpSYw-00077p-W5; Sat, 07 Dec 2013 19:49:35 -0500
Date: Sat, 7 Dec 2013 19:49:34 -0500
From: John Cowan <cowan@mercury.ccil.org>
To: Tim Bray <tbray@textuality.com>
Message-ID: <20131208004934.GB23243@mercury.ccil.org>
References: <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com> <CAHBU6it=NXw4EBgxmN-1xA_7hUdMMs77iYaXQs_q0SwkBv_A8Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHBU6it=NXw4EBgxmN-1xA_7hUdMMs77iYaXQs_q0SwkBv_A8Q@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <cowan@ccil.org>
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, JSON WG <json@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 00:49:43 -0000

Tim Bray scripsit:

> I assume all parties to the discussion know that in 100% of all
> programming-language libraries in use for dealing with JSON as
> transmitted on the wire, JSON objects are loaded into hash tables
> or dicts or whatever your language idiom is, and there is no way
> for software using those libraries to discover what order they were
> serialized in,

Well, no, not 100%.  In Lisp-family languages, JSON objects are often
deserialized to ordered constructs.  Nevertheless:

> any suggestion that this order should be considered significant for
> application usage would be regarded as insane.

+1 to that.

-- 
Note that nobody these days would clamor for fundamental laws        John Cowan
of *the theory of kangaroos*, showing why pseudo-kangaroos are   cowan@ccil.org
physically, logically, metaphysically impossible.    http://www.ccil.org/~cowan
Kangaroos are wonderful, but not *that* wonderful.     --Dan Dennett on zombies

From cowan@ccil.org  Sat Dec  7 16:55:29 2013
Return-Path: <cowan@ccil.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635CB1AE46D for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 16:55:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 pzg1TvSn2kfY for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 16:55:28 -0800 (PST)
Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2C47A1AE470 for <json@ietf.org>; Sat,  7 Dec 2013 16:55:28 -0800 (PST)
Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from <cowan@ccil.org>) id 1VpSeX-0007e6-Og; Sat, 07 Dec 2013 19:55:21 -0500
Date: Sat, 7 Dec 2013 19:55:21 -0500
From: John Cowan <cowan@mercury.ccil.org>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Message-ID: <20131208005521.GC23243@mercury.ccil.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <cowan@ccil.org>
Cc: JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 00:55:29 -0000

Allen Wirfs-Brock scripsit:

> Similarly, the JSON texts:
>    {"1":  1, "2", 2}
> and
>    {"2":  2, "1": 1}
> 
> or the JSON texts:
>    {"a": 1, "a": 2}
> and
>    {"a": 2, "a": 1}
> 
> have an ordering of the object members that must be preserved by the
> parser in order for downstream semantics to be applied.

I cannot accept this statement without proof.  Where in the ECMAscript
definition does it say this?

-- 
John Cowan              cowan@ccil.org          http://www.ccil.org/~cowan
C'est la` pourtant que se livre le sens du dire, de ce que, s'y conjuguant
le nyania qui bruit des sexes en compagnie, il supplee a ce qu'entre eux,
de rapport nyait pas.               --Jacques Lacan, "L'Etourdit"

From allen@wirfs-brock.com  Sat Dec  7 18:12:26 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531B01AE489 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 18:12:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 R5Gsmm7ZlI1n for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 18:12:23 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9572D1AE450 for <json@ietf.org>; Sat,  7 Dec 2013 18:12:23 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1VpTqz-0007ok-Au; Sun, 08 Dec 2013 02:12:17 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+DKWfR5MLTYMjN97PtU3H06PMXdfU0+/g=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-165-139636692
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <20131208005521.GC23243@mercury.ccil.org>
Date: Sat, 7 Dec 2013 18:12:09 -0800
Message-Id: <646E66F1-5E35-4491-8D51-2462C84C1CDF@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <20131208005521.GC23243@mercury.ccil.org>
To: John Cowan <cowan@mercury.ccil.org>
X-Mailer: Apple Mail (2.1085)
Cc: JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 02:12:26 -0000

--Apple-Mail-165-139636692
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Dec 7, 2013, at 4:55 PM, John Cowan wrote:

> Allen Wirfs-Brock scripsit:
>=20
>> Similarly, the JSON texts:
>>   {"1":  1, "2", 2}
>> and
>>   {"2":  2, "1": 1}
>>=20
>> or the JSON texts:
>>   {"a": 1, "a": 2}
>> and
>>   {"a": 2, "a": 1}
>>=20
>> have an ordering of the object members that must be preserved by the
>> parser in order for downstream semantics to be applied.
>=20
> I cannot accept this statement without proof.  Where in the ECMAscript
> definition does it say this?

First, the console out from an experiment run from the developer console =
of Firefox 27

17:22:24.873 var jsonText1 =3D '{"a": 1, "a": 2}';
17:22:25.244 undefined                                     <----- ignore =
these, they are a console artifact
17:22:50.107 console.log(jsonText1);
17:22:50.124 undefined
17:22:50.125 "{"a": 1, "a": 2}"    <-----note that the console doesn't =
property escape embedded quotes
17:23:45.060 var jsonText2 =3D '{"a": 2, "a": 1}';
17:23:45.062 undefined
17:24:18.594 console.log(jsonText2);
17:24:18.649 undefined
17:24:18.649 "{"a": 2, "a": 1}"
17:25:31.540 var parsedText1 =3D JSON.parse(jsonText1);
17:25:31.577 undefined
17:26:36.429 console.log(parsedText1.a)
17:26:36.568 undefined
17:26:36.569 2
17:27:13.754 var parsedText2 =3D JSON.parse(jsonText2);
17:27:13.882 undefined
17:27:37.533 console.log(parsedText2.a)
17:27:37.660 undefined
17:27:37.661 1

Note that the value of the 'a' property on the JavaScript object =
produced by JSON.parse is either 1 or 2 depending upon the ordering of =
the member definitions with duplicate names.   I'll leave it to you to =
try using your favorite browser.  However, I'm confident that you will =
see the same result as this is what ECMA-262, 5th Edition requires.  I =
happen to be fairly familiar with that document, so I can explain how =
that is:

1) JSON.parse is specified in by the algorithms in section 15.12.2 =
http://www.ecma-international.org/ecma-262/5.1/#sec-15.12.2 starting =
with the first algorithm in that section.
2) Step 2 of that algorithm requires validation the input string against =
the JSON grammar provided in =
http://www.ecma-international.org/ecma-262/5.1/#sec-15.12.1=20
3) If the input text cannot be recognized by a parser for that grammar, =
an exception must be thrown at that point.
4) If the input text is recognized by the parser, then step 3 says to =
parse and evaluate the input text as with it was ECMAScript source code. =
 The result of that evaluation is what is normally returned from the =
function.  The ECMAScript parsing and evaluation rules can be used in =
this manner because a well-formed JSON text (that is verified in step 2) =
is a subset of an ECMAScript PrimaryExpression =
http://www.ecma-international.org/ecma-262/5.1/#sec-11.1 .
5)  The text of a JSON object definition will be parsed and evaluated as =
if it was an EMAScript ObjectLiteral as specified at =
http://www.ecma-international.org/ecma-262/5.1/#sec-11.1.5 The =
evaluation semantics are specified by the algorithms that follow the BNF =
in that section.
6) Note that the body of an ObjectLiteral is described by the =
PropertyNameAndValueList production which produces a comma separated =
list of PropertyAssignment productions.=20
7) The PropertyAssignments of a PropertyNameAndValueList are evaluated =
in left to right order, as specified by 4th algorithm on this section.=20=

8) As each PropertyAssignment is evaluated, it performs a =
[[DefineOwnProperty]] operation up on the result object using the =
property name and value provided by the PropertyAssignment.
9) [[DefineOwnProperty]] is defined in =
http://www.ecma-international.org/ecma-262/5.1/#sec-8.12.9 . It is a =
fairly complex operation but the short story is that if a property of =
that name does not already exist one is created and assigned the =
associated value. If a property of that name does already exist, the =
existing value is overwritten with the current value.=20

In other words, ECMA-262 explicitly specifies that when multiple =
occurrences of the same member name occurs in a JSON object, the value =
associated with the last (right-most) occurrence is used. Order matters.

A similar analysis applies to the first example. =20

Allen

=20











>=20
> --=20
> John Cowan              cowan@ccil.org          =
http://www.ccil.org/~cowan
> C'est la` pourtant que se livre le sens du dire, de ce que, s'y =
conjuguant
> le nyania qui bruit des sexes en compagnie, il supplee a ce qu'entre =
eux,
> de rapport nyait pas.               --Jacques Lacan, "L'Etourdit"
>=20


--Apple-Mail-165-139636692
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Dec 7, 2013, at 4:55 PM, John Cowan wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>Allen =
Wirfs-Brock scripsit:<br><br><blockquote type=3D"cite">Similarly, the =
JSON texts:<br></blockquote><blockquote type=3D"cite"> &nbsp;&nbsp;{"1": =
&nbsp;1, "2", 2}<br></blockquote><blockquote =
type=3D"cite">and<br></blockquote><blockquote type=3D"cite"> =
&nbsp;&nbsp;{"2": &nbsp;2, "1": 1}<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">or the JSON =
texts:<br></blockquote><blockquote type=3D"cite"> &nbsp;&nbsp;{"a": 1, =
"a": 2}<br></blockquote><blockquote =
type=3D"cite">and<br></blockquote><blockquote type=3D"cite"> =
&nbsp;&nbsp;{"a": 2, "a": 1}<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">have an =
ordering of the object members that must be preserved by =
the<br></blockquote><blockquote type=3D"cite">parser in order for =
downstream semantics to be applied.<br></blockquote><br>I cannot accept =
this statement without proof. &nbsp;Where in the =
ECMAscript<br>definition does it say =
this?<br></div></blockquote><div><br></div><div>First, the console out =
from an experiment run from the developer console of Firefox =
27</div><div><br></div><div><div>17:22:24.873 var jsonText1 =3D '{"a": =
1, "a": 2}';</div><div>17:22:25.244 undefined &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;----- ignore these, they are a =
console artifact</div><div>17:22:50.107 =
console.log(jsonText1);</div><div>17:22:50.124 =
undefined</div><div>17:22:50.125 "{"a": 1, "a": 2}" &nbsp; =
&nbsp;&lt;-----note that the console doesn't property escape embedded =
quotes</div><div>17:23:45.060 var jsonText2 =3D '{"a": 2, "a": =
1}';</div><div>17:23:45.062 undefined</div><div>17:24:18.594 =
console.log(jsonText2);</div><div>17:24:18.649 =
undefined</div><div>17:24:18.649 "{"a": 2, "a": =
1}"</div><div>17:25:31.540 var parsedText1 =3D =
JSON.parse(jsonText1);</div><div>17:25:31.577 =
undefined</div><div>17:26:36.429 =
console.log(parsedText1.a)</div><div>17:26:36.568 =
undefined</div><div>17:26:36.569 2</div><div>17:27:13.754 var =
parsedText2 =3D JSON.parse(jsonText2);</div><div>17:27:13.882 =
undefined</div><div>17:27:37.533 =
console.log(parsedText2.a)</div><div>17:27:37.660 =
undefined</div><div>17:27:37.661 1</div></div><div><br></div><div>Note =
that the value of the 'a' property on the JavaScript object produced by =
JSON.parse is either 1 or 2 depending upon the ordering of the member =
definitions with duplicate names. &nbsp; I'll leave it to you to try =
using your favorite browser. &nbsp;However, I'm confident that you will =
see the same result as this is what ECMA-262, 5th Edition requires. =
&nbsp;I happen to be fairly familiar with that document, so I can =
explain how that is:</div><div><br></div><div>1) JSON.parse is specified =
in by the algorithms in section 15.12.2&nbsp;<a =
href=3D"http://www.ecma-international.org/ecma-262/5.1/#sec-15.12.2">http:=
//www.ecma-international.org/ecma-262/5.1/#sec-15.12.2</a>&nbsp;starting =
with the first algorithm in that section.</div><div>2) Step 2 of that =
algorithm requires validation the input string against the JSON grammar =
provided in&nbsp;<a =
href=3D"http://www.ecma-international.org/ecma-262/5.1/#sec-15.12.1">http:=
//www.ecma-international.org/ecma-262/5.1/#sec-15.12.1</a>&nbsp;</div><div=
>3) If the input text cannot be recognized by a parser for that grammar, =
an exception must be thrown at that point.</div><div>4) If the input =
text is recognized by the parser, then step 3 says to parse and evaluate =
the input text as with it was ECMAScript source code. &nbsp;The result =
of that evaluation is what is normally returned from the function. =
&nbsp;The ECMAScript parsing and evaluation rules can be used in this =
manner because a well-formed JSON text (that is verified in step 2) is a =
subset of an ECMAScript PrimaryExpression <a =
href=3D"http://www.ecma-international.org/ecma-262/5.1/#sec-11.1">http://w=
ww.ecma-international.org/ecma-262/5.1/#sec-11.1</a> .</div><div>5) =
&nbsp;The text of a JSON object definition will be parsed and evaluated =
as if it was an EMAScript ObjectLiteral as specified at <a =
href=3D"http://www.ecma-international.org/ecma-262/5.1/#sec-11.1.5">http:/=
/www.ecma-international.org/ecma-262/5.1/#sec-11.1.5</a>&nbsp;The =
evaluation semantics are specified by the algorithms that follow the BNF =
in that section.</div><div>6) Note that the body of an ObjectLiteral is =
described by the PropertyNameAndValueList production which produces a =
comma separated list of PropertyAssignment =
productions.&nbsp;</div><div>7) The PropertyAssignments of a =
PropertyNameAndValueList are evaluated in left to right order, as =
specified by 4th algorithm on this section.&nbsp;</div><div>8) As each =
PropertyAssignment is evaluated, it performs a [[DefineOwnProperty]] =
operation up on the result object using the property name and value =
provided by the PropertyAssignment.</div><div>9) [[DefineOwnProperty]] =
is defined in <a =
href=3D"http://www.ecma-international.org/ecma-262/5.1/#sec-8.12.9">http:/=
/www.ecma-international.org/ecma-262/5.1/#sec-8.12.9</a> . It is a =
fairly complex operation but the short story is that if a property of =
that name does not already exist one is created and assigned the =
associated value. If a property of that name does already exist, the =
existing value is overwritten with the current =
value.&nbsp;</div><div><br></div><div>In other words, ECMA-262 =
explicitly specifies that when multiple occurrences of the same member =
name occurs in a JSON object, the value associated with the last =
(right-most) occurrence is used. Order =
matters.</div><div><br></div><div>A similar analysis applies to the =
first example. =
&nbsp;</div><div><br></div><div>Allen</div><div><br></div><div>&nbsp;</div=
><div><br></div><div><br></div><div><br></div><div><br></div><div><br></di=
v><div><br></div><div><br></div><div><br></div><div><br></div><div><br></d=
iv><br><blockquote type=3D"cite"><div><br>-- <br>John Cowan =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;<a href=3D"mailto:cowan@ccil.org">cowan@ccil.org</a> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"http://www.ccil.org/~cowan">http://www.ccil.org/~cowan</a><br>C'es=
t la` pourtant que se livre le sens du dire, de ce que, s'y =
conjuguant<br>le nyania qui bruit des sexes en compagnie, il supplee a =
ce qu'entre eux,<br>de rapport nyait pas. =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;--Jacques Lacan, =
"L'Etourdit"<br><br></div></blockquote></div><br></body></html>=

--Apple-Mail-165-139636692--

From derhoermi@gmx.net  Sat Dec  7 18:39:34 2013
Return-Path: <derhoermi@gmx.net>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58541AE493 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 18:39:34 -0800 (PST)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 PBqpZE8ZrUOF for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 18:39:33 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id AC2031AE492 for <json@ietf.org>; Sat,  7 Dec 2013 18:39:32 -0800 (PST)
Received: from netb.Speedport_W_700V ([91.35.26.74]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0MXEs5-1W3SlG0pNN-00WJ9X for <json@ietf.org>; Sun, 08 Dec 2013 03:39:27 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Sun, 08 Dec 2013 03:39:25 +0100
Message-ID: <mfl7a95ln19f1utk5ah7hd7grocue3mp3u@hive.bjoern.hoehrmann.de>
References: <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <20131208005521.GC23243@mercury.ccil.org> <646E66F1-5E35-4491-8D51-2462C84C1CDF@wirfs-brock.com>
In-Reply-To: <646E66F1-5E35-4491-8D51-2462C84C1CDF@wirfs-brock.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:X8xAQYL5iLCE8k6KXq5ltNopkFv+B5/3xZAX+5Kjb6RYFXLlr8L GSV+4Sb0R/LhbKS//YUTStfvkZbjc0HvmTjiFmx0iIjZZvUjLjB1y51/49M4X4atBkD66wd IT8AzpCs+24zH0ygyLLkxwuJSVJnSftXT4eLjp3k4q2J8IIjXv7kv49tacFFpf94c3YG5b5 6zLnggEkInHELXLbwKsvA==
Cc: "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 02:39:35 -0000

* Allen Wirfs-Brock wrote:
>On Dec 7, 2013, at 4:55 PM, John Cowan wrote:
>> Allen Wirfs-Brock scripsit:
>> 
>>> Similarly, the JSON texts:
>>>   {"1":  1, "2", 2}
>>> and
>>>   {"2":  2, "1": 1}
>>> 
>>> or the JSON texts:
>>>   {"a": 1, "a": 2}
>>> and
>>>   {"a": 2, "a": 1}
>>> 
>>> have an ordering of the object members that must be preserved by the
>>> parser in order for downstream semantics to be applied.
>> 
>> I cannot accept this statement without proof.  Where in the ECMAscript
>> definition does it say this?

>In other words, ECMA-262 explicitly specifies that when multiple 
>occurrences of the same member name occurs in a JSON object, the value 
>associated with the last (right-most) occurrence is used. Order matters.
>
>A similar analysis applies to the first example.  

Your analysis does not demonstrate that `JSON.parse` preserves ordering.
I am confident that even in the current ES6 draft `JSON.stringify` does
not preserve ordering even if `JSON.parse` somehow did. It's based on
`Object.keys` which does not define ordering as currently proposed. If
you can re-create the key-value-pair order in your first example from
the output of `JSON.parse` without depending on implementation-defined
behavior, seeing the code for that would be most instructive.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From cowan@ccil.org  Sat Dec  7 19:22:31 2013
Return-Path: <cowan@ccil.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F9F1A1F61 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 19:22:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 V8KYEV87jqlC for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 19:22:30 -0800 (PST)
Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id F26B91A1F5D for <json@ietf.org>; Sat,  7 Dec 2013 19:22:29 -0800 (PST)
Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from <cowan@ccil.org>) id 1VpUwp-0005Mf-Nl; Sat, 07 Dec 2013 22:22:23 -0500
Date: Sat, 7 Dec 2013 22:22:23 -0500
From: John Cowan <cowan@mercury.ccil.org>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Message-ID: <20131208032223.GG23243@mercury.ccil.org>
References: <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <20131208005521.GC23243@mercury.ccil.org> <646E66F1-5E35-4491-8D51-2462C84C1CDF@wirfs-brock.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <646E66F1-5E35-4491-8D51-2462C84C1CDF@wirfs-brock.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <cowan@ccil.org>
Cc: JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 03:22:31 -0000

Allen Wirfs-Brock scripsit:

> In other words, ECMA-262 explicitly specifies that when multiple
> occurrences of the same member name occurs in a JSON object, the value
> associated with the last (right-most) occurrence is used. Order matters.

Okay, I concede that order matters *when* there are duplicate names.
I still deny that it matters otherwise.

-- 
He made the Legislature meet at one-horse       John Cowan
tank-towns out in the alfalfa belt, so that     cowan@ccil.org
hardly nobody could get there and most of       http://www.ccil.org/~cowan
the leaders would stay home and let him go      --H.L. Mencken's
to work and do things as he pleased.              Declaration of Independence

From allen@wirfs-brock.com  Sat Dec  7 19:58:24 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507F71AC4C5 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 19:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 iyR6EHGkRoaa for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 19:58:22 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 37B891AC4C1 for <json@ietf.org>; Sat,  7 Dec 2013 19:58:21 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1VpVVX-000LKV-Tt; Sun, 08 Dec 2013 03:58:16 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+FxPBm2c9zhBoOoeyfJ0tEwlExwNhhk64=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-166-145996081
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <mfl7a95ln19f1utk5ah7hd7grocue3mp3u@hive.bjoern.hoehrmann.de>
Date: Sat, 7 Dec 2013 19:58:09 -0800
Message-Id: <D9FC6908-E4B0-4411-8C2A-297EA66B651F@wirfs-brock.com>
References: <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <20131208005521.GC23243@mercury.ccil.org> <646E66F1-5E35-4491-8D51-2462C84C1CDF@wirfs-brock.com> <mfl7a95ln19f1utk5ah7hd7grocue3mp3u@hive.bjoern.hoehrmann.de>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
X-Mailer: Apple Mail (2.1085)
Cc: JSON WG <json@ietf.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 03:58:24 -0000

--Apple-Mail-166-145996081
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Dec 7, 2013, at 6:39 PM, Bjoern Hoehrmann wrote:

> * Allen Wirfs-Brock wrote:
>> On Dec 7, 2013, at 4:55 PM, John Cowan wrote:
>>> Allen Wirfs-Brock scripsit:
>>>=20
>>>> Similarly, the JSON texts:
>>>>  {"1":  1, "2", 2}
>>>> and
>>>>  {"2":  2, "1": 1}
>>>>=20
>>>> or the JSON texts:
>>>>  {"a": 1, "a": 2}
>>>> and
>>>>  {"a": 2, "a": 1}
>>>>=20
>>>> have an ordering of the object members that must be preserved by =
the
>>>> parser in order for downstream semantics to be applied.
>>>=20
>>> I cannot accept this statement without proof.  Where in the =
ECMAscript
>>> definition does it say this?
>=20
>> In other words, ECMA-262 explicitly specifies that when multiple=20
>> occurrences of the same member name occurs in a JSON object, the =
value=20
>> associated with the last (right-most) occurrence is used. Order =
matters.
>>=20
>> A similar analysis applies to the first example. =20
>=20
> Your analysis does not demonstrate that `JSON.parse` preserves =
ordering.
> I am confident that even in the current ES6 draft `JSON.stringify` =
does
> not preserve ordering even if `JSON.parse` somehow did. It's based on
> `Object.keys` which does not define ordering as currently proposed. If
> you can re-create the key-value-pair order in your first example from
> the output of `JSON.parse` without depending on implementation-defined
> behavior, seeing the code for that would be most instructive.


You are correct that, ES5 does not define the for-in enumeration order.  =
But it does say that the Object.keys ordering must be the same as  =
for-in enumeration order. and there is a defacto standard for a partial =
enumeration order that all browsers implement.

Quoting from  =
https://mail.mozilla.org/htdig/es-discuss/2009-October/010060.html=20
"The common behavior subset here is: for objects with no properties =20
that look like array indices, and no enumerable prototype properties, =20=

for..in enumeration returns properties in insertion order. That =20
particular behavior is a de facto standard and required for Web =20
compatibility. A future standard should specify at least that much. "

Also =
https://mail.mozilla.org/pipermail/es-discuss/2010-December/012469.html=20=

"We did identify one situation where enumeration order will be the same =
across all major implementation that are currently in use (including =
IE6):

The enumeration order of an object's properties will be the order in =
which the properties were added if all the following conditions hold:
	The object has no inherited enumerable properties
	The object has no array indexed properties
	No properties have been deleted
	No property has had its attributes modified or been changed from =
a data property to an accessor property or visa versa
"

Also see =
https://mail.mozilla.org/pipermail/es-discuss/2011-March/012965.html =
must other discussion history you can find in the es-discuss archives.

In practice, JavaScript implementation do have a standard enumeration =
order that applies for the cases that most commonly when parsing and =
generating JSON text. Application do depend upon that ordering.

Allen



--Apple-Mail-166-145996081
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Dec 7, 2013, at 6:39 PM, Bjoern Hoehrmann =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>* Allen Wirfs-Brock wrote:<br><blockquote =
type=3D"cite">On Dec 7, 2013, at 4:55 PM, John Cowan =
wrote:<br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">Allen Wirfs-Brock =
scripsit:<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">Similarly, the JSON =
texts:<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;{"1": &nbsp;1, "2", =
2}<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">and<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;{"2": &nbsp;2, "1": =
1}<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">or the =
JSON texts:<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;{"a": 1, "a": =
2}<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">and<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"> =
&nbsp;{"a": 2, "a": =
1}<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">have =
an ordering of the object members that must be preserved by =
the<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">parser =
in order for downstream semantics to be =
applied.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">I cannot accept this statement =
without proof. &nbsp;Where in the =
ECMAscript<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">definition does it say =
this?<br></blockquote></blockquote><br><blockquote type=3D"cite">In =
other words, ECMA-262 explicitly specifies that when multiple =
<br></blockquote><blockquote type=3D"cite">occurrences of the same =
member name occurs in a JSON object, the value =
<br></blockquote><blockquote type=3D"cite">associated with the last =
(right-most) occurrence is used. Order =
matters.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">A similar =
analysis applies to the first example. &nbsp;<br></blockquote><br>Your =
analysis does not demonstrate that `JSON.parse` preserves ordering.<br>I =
am confident that even in the current ES6 draft `JSON.stringify` =
does<br>not preserve ordering even if `JSON.parse` somehow did. It's =
based on<br>`Object.keys` which does not define ordering as currently =
proposed. If<br>you can re-create the key-value-pair order in your first =
example from<br>the output of `JSON.parse` without depending on =
implementation-defined<br>behavior, seeing the code for that would be =
most instructive.</div></blockquote></div><div><br></div><div>You are =
correct that, ES5 does not define the for-in enumeration order. =
&nbsp;But it does say that the Object.keys ordering must be the same as =
&nbsp;for-in enumeration order. and there is a&nbsp;defacto standard for =
a partial enumeration order that all browsers =
implement.</div><div><br></div><div>Quoting from &nbsp;<a =
href=3D"https://mail.mozilla.org/htdig/es-discuss/2009-October/010060.html=
">https://mail.mozilla.org/htdig/es-discuss/2009-October/010060.html</a>&n=
bsp;</div><div>"The common behavior subset here is: for objects with no =
properties &nbsp;</div><div>that look like array indices, and no =
enumerable prototype properties, &nbsp;</div><div>for..in enumeration =
returns properties in insertion order. That &nbsp;</div><div>particular =
behavior is a de facto standard and required for Web =
&nbsp;</div><div>compatibility. A future standard should specify at =
least that much.&nbsp;"</div><div><br></div><div>Also&nbsp;<a =
href=3D"https://mail.mozilla.org/pipermail/es-discuss/2010-December/012469=
.html">https://mail.mozilla.org/pipermail/es-discuss/2010-December/012469.=
html</a>&nbsp;</div><div>"We did identify one situation where =
enumeration order will be the same across all major implementation that =
are currently in use (including IE6):</div><div><br></div><div>The =
enumeration order of an object's properties will be the order in which =
the properties were added if all the following conditions =
hold:</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>The object has no inherited enumerable properties</div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>The =
object has no array indexed properties</div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>No =
properties have been deleted</div><div><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>No property has had its =
attributes modified or been changed from a data property to an accessor =
property or visa versa</div><div>"</div><div><br></div><div>Also =
see&nbsp;<a =
href=3D"https://mail.mozilla.org/pipermail/es-discuss/2011-March/012965.ht=
ml">https://mail.mozilla.org/pipermail/es-discuss/2011-March/012965.html</=
a>&nbsp;must other discussion history you can find in the es-discuss =
archives.</div><div><br></div><div>In practice, JavaScript =
implementation do have a standard enumeration order that applies for the =
cases that most commonly when parsing and generating JSON text. =
Application do depend upon that =
ordering.</div><div><br></div><div>Allen</div><div><br></div><br></body></=
html>=

--Apple-Mail-166-145996081--

From allen@wirfs-brock.com  Sat Dec  7 20:06:33 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834441AC7F3 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 20:06:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 yOjGqoOuBySh for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 20:06:32 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 95DE61AC4AB for <json@ietf.org>; Sat,  7 Dec 2013 20:06:32 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1VpVdU-000LU5-7i; Sun, 08 Dec 2013 04:06:28 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+GDWVVDQztFS9qdpxkWPcS7e5Shu0YW44=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <20131208032223.GG23243@mercury.ccil.org>
Date: Sat, 7 Dec 2013 20:06:24 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <A35D96DE-FFA7-4B33-A927-DD5775E999E6@wirfs-brock.com>
References: <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <20131208005521.GC23243@mercury.ccil.org> <646E66F1-5E35-4491-8D51-2462C84C1CDF@wirfs-brock.com> <20131208032223.GG23243@mercury.ccil.org>
To: John Cowan <cowan@mercury.ccil.org>
X-Mailer: Apple Mail (2.1085)
Cc: JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 04:06:33 -0000

On Dec 7, 2013, at 7:22 PM, John Cowan wrote:

> Allen Wirfs-Brock scripsit:
>=20
>> In other words, ECMA-262 explicitly specifies that when multiple
>> occurrences of the same member name occurs in a JSON object, the =
value
>> associated with the last (right-most) occurrence is used. Order =
matters.
>=20
> Okay, I concede that order matters *when* there are duplicate names.
> I still deny that it matters otherwise.

In reality it defines the JavaScript for-in enumeration order over the =
JS object property generated by JSON.parse.

Try this in your favorite browser:

   var jText =3D '{"b": 1, "a": 2, "c": 3};
   for (var key in JSON.parse(jText) console.log(key);

You will get as output:
     b
     a
     c

I can assure you that code exists on the web that depends, whether =
intentionally or not, on this ordering.  Past experience among browser =
implementations is that site break when attempts are made to change this =
ordering.

Allen



From duerst@it.aoyama.ac.jp  Sat Dec  7 23:01:16 2013
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B79A1ADEA6 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 23:01:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level: 
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=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 SjhBGLF6NbBN for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 23:01:14 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8860A1ADE8B for <json@ietf.org>; Sat,  7 Dec 2013 23:01:13 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rB870tcd003899; Sun, 8 Dec 2013 16:00:55 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 684b_b82f_7bf31f2e_5fd6_11e3_b0f9_001e6722eec2; Sun, 08 Dec 2013 16:00:55 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 12E1FBF54B; Sun,  8 Dec 2013 16:00:55 +0900 (JST)
Message-ID: <52A4191D.7000905@it.aoyama.ac.jp>
Date: Sun, 08 Dec 2013 16:00:45 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: John Cowan <cowan@mercury.ccil.org>
References: <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com> <CAHBU6it=NXw4EBgxmN-1xA_7hUdMMs77iYaXQs_q0SwkBv_A8Q@mail.gmail.com> <20131208004934.GB23243@mercury.ccil.org>
In-Reply-To: <20131208004934.GB23243@mercury.ccil.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 07:01:16 -0000

On 2013/12/08 9:49, John Cowan wrote:
> Tim Bray scripsit:
>
>> I assume all parties to the discussion know that in 100% of all
>> programming-language libraries in use for dealing with JSON as
>> transmitted on the wire, JSON objects are loaded into hash tables
>> or dicts or whatever your language idiom is, and there is no way
>> for software using those libraries to discover what order they were
>> serialized in,
>
> Well, no, not 100%.  In Lisp-family languages, JSON objects are often
> deserialized to ordered constructs.  Nevertheless:

Similarly, as of somewhere around version 1.9.x or 2.0, Hash entries in 
Ruby are ordered, and one would assume that the original order in JSON 
would be reflected in the order of the Hash entries.

>> any suggestion that this order should be considered significant for
>> application usage would be regarded as insane.
>
> +1 to that.

+1 here, too.

From nico@cryptonector.com  Sat Dec  7 23:01:39 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F065F1ADEB1 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 23:01:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 MEPvaoeE_3b7 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 23:01:37 -0800 (PST)
Received: from homiemail-a30.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id D4A361ADE8B for <json@ietf.org>; Sat,  7 Dec 2013 23:01:37 -0800 (PST)
Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 933E221DE65 for <json@ietf.org>; Sat,  7 Dec 2013 23:01:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=Ij7CqwQ2Ack0h+IcGbT/D1Aw1oM=; b=YhCilbsTe/R ydoUD+hVVJHh8gNjTv9hPvKrZVxcG0eE0tYuHJ90s6RbWkgtAF00Tp+eqHuHr5tN jA6XrSj3OcLKT50geONm2UE6ZcO07uM8rFUilyQc88MF1hDD3oEiEq/2yIKaRUb9 FPfbJjIyB7X0vwLzechbeWxrz/puaAac=
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 33F3D21DE58 for <json@ietf.org>; Sat,  7 Dec 2013 23:01:33 -0800 (PST)
Received: by mail-wg0-f47.google.com with SMTP id n12so2223024wgh.14 for <json@ietf.org>; Sat, 07 Dec 2013 23:01:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=zmT69q2uOkteAYIAVseCbwn/tNO2R6/N7ZB1JoHV4NU=; b=HJxtpuSs16rydiICNAqrj4u73/5WGevWU/pO7pYl8ODw/7kpiwKa0yCiDypdGsbFrB fQOSadJkLTdMNwXk2QtrD6YTVzzyo8HFD/Rg0KGaT3xqcmeGoNW3lrCHmrjtsSvNlXwl rfcbWUQ+ENjGhwPLmTIBVHEt1APYYJ5KpIyArYbX40yGbNoIdIIqdIfghOOo4/PdQJ4V iOLM+ZBGicgwnbMG2Eqi9gHduIQESCm9m1UnO+YgodAZlqnkJm5kGJ+AG0gH0QfK2Sls ia0xu7zH2l4QB8Yn1XlZ7uy1OvsilWzXSSWLQeyhB8DFYCtwlIdH2El3kdrQ9g4hvKUG fjdw==
MIME-Version: 1.0
X-Received: by 10.194.240.41 with SMTP id vx9mr727872wjc.70.1386486091436; Sat, 07 Dec 2013 23:01:31 -0800 (PST)
Received: by 10.217.10.6 with HTTP; Sat, 7 Dec 2013 23:01:31 -0800 (PST)
Date: Sun, 8 Dec 2013 01:01:31 -0600
Message-ID: <CAK3OfOiQ_MGOzSgQwOjqJUp_SxS_tCp_PrPHw5peGBCmp6Oq1Q@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Content-Type: text/plain; charset=UTF-8
Cc: John Cowan <cowan@mercury.ccil.org>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: [Json] Object names, once more (Re:  Response to Statement from W3C TAG)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 07:01:39 -0000

On Sat, Dec 7, 2013 at 8:12 PM, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote:
> First, the console out from an experiment run from the developer console of
> Firefox 27

I (and many others) can show you examples of JSON tooling that doesn't
preserve either duplicate object names and/or object name ordering.
Examples are nice but not normative.  Even of some ECMA document
somewhere strongly says or implies what you say, at best we'll
conclude that there are *two* JSONs, and then we need to decide how to
signal which any one app/document uses (in some cases there may no way
to do so other than via schema).

Once more, speaking for myself, my sense of the WG is that we're not
going to change RFC4627 to say that object name ordering and
duplicates are significant.  There are other options, but none will
make everyone happy.  If JSON got forked over the past seven years,
there won't be any stuffing of the genie back into the bottle.

Nico
--

From duerst@it.aoyama.ac.jp  Sat Dec  7 23:09:25 2013
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E641ADEBF for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 23:09:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level: 
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=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 O3Oe0XHc2gJi for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 23:09:24 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF4E1ADEB7 for <json@ietf.org>; Sat,  7 Dec 2013 23:09:24 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rB879ErK010307; Sun, 8 Dec 2013 16:09:14 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 6847_aa7f_a5327618_5fd7_11e3_9413_001e6722eec2; Sun, 08 Dec 2013 16:09:14 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id B6E12BF54B; Sun,  8 Dec 2013 16:09:13 +0900 (JST)
Message-ID: <52A41B10.4080701@it.aoyama.ac.jp>
Date: Sun, 08 Dec 2013 16:09:04 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com>
In-Reply-To: <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 07:09:25 -0000

[Somebody please forward this message to es-discuss@mozilla.org, unless=20
it's not rejected.]

On 2013/12/08 8:05, Allen Wirfs-Brock wrote:

>> In JSON, objects are unordered collections or sets of name/value pairs=
.  It says so right there on json.org (=E2=80=9Csets=E2=80=9D), and it sa=
ys so in RFC 4627 (=E2=80=9Ccollections=E2=80=9D)*).  We may not like it,=
 but it has been a promise for a decade.  We need to heed it.  (Another p=
romise was that JSON doesn=E2=80=99t change**).)
>
> You also need to look at objective reality and consider the possibility=
 that the informal (and non-normative text) on both the json.org website =
and in the original RFC never actually matched reality.
>
> JSON is derived from JavaSript (whose standard is ECMA-262) and since 2=
009, ECMA-262 (and its clone ISO/IEC-16262) has included a normative spec=
ification for parsing JSON text that includes an ordering semantics for o=
bject members.

RFC 4627 was published in July 2006, so the ECMA-262 version of 2009 may=20
not be very relevant.

Regards,   Martin.

From cabo@tzi.org  Sat Dec  7 23:19:32 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D681A1ADEA7 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 23:19:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 c-ESRzlspe5x for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 23:19:31 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 72F161ADE8B for <json@ietf.org>; Sat,  7 Dec 2013 23:19:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB87JHEf009001; Sun, 8 Dec 2013 08:19:17 +0100 (CET)
Received: from [192.168.217.105] (p54893CB8.dip0.t-ipconnect.de [84.137.60.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 46160624; Sun,  8 Dec 2013 08:19:16 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAK3OfOiQ_MGOzSgQwOjqJUp_SxS_tCp_PrPHw5peGBCmp6Oq1Q@mail.gmail.com>
Date: Sun, 8 Dec 2013 08:19:13 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C6B143D5-CC7C-478F-A684-456615DC7721@tzi.org>
References: <CAK3OfOiQ_MGOzSgQwOjqJUp_SxS_tCp_PrPHw5peGBCmp6Oq1Q@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.1822)
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, John Cowan <cowan@mercury.ccil.org>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Object names, once more (Re:  Response to Statement from W3C TAG)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 07:19:33 -0000

On 08 Dec 2013, at 08:01, Nico Williams <nico@cryptonector.com> wrote:

> *two* JSONs

I think ESON is still pretty much free as an abbreviation (apart from an =
obscure JSON-based configuration file language).

Gr=FC=DFe, Carsten


From nico@cryptonector.com  Sat Dec  7 23:21:54 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8011ADEB5 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 23:21:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 msfL59TQRJo6 for <json@ietfa.amsl.com>; Sat,  7 Dec 2013 23:21:53 -0800 (PST)
Received: from homiemail-a72.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 918031ADEA7 for <json@ietf.org>; Sat,  7 Dec 2013 23:21:53 -0800 (PST)
Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 68B056B0078; Sat,  7 Dec 2013 23:21:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=RaSVVGLV4ukG+aZ6otSKuPhV/HI=; b=qbRs0WZ/PiM wFpDFbUR9eJh+Ft/ofHS2HdeZbt5816ib9LJc7XYup3HOUqY24supAoPXumW8JwJ 0YdQGTlVMjlGs7ZpQtkA+mkPWRKUiqzgvMv5gfNbMBeMOz/2tvGAXavjUBuqjGWH 8DwMpzmZht9PC2ks8O2Cr96zLoXI93d0=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPA id BB87F6B0070; Sat,  7 Dec 2013 23:21:48 -0800 (PST)
Date: Sun, 8 Dec 2013 01:21:48 -0600
From: Nico Williams <nico@cryptonector.com>
To: =?iso-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= <duerst@it.aoyama.ac.jp>
Message-ID: <20131208072144.GF4067@localhost>
References: <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com> <52A41B10.4080701@it.aoyama.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <52A41B10.4080701@it.aoyama.ac.jp>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 07:21:54 -0000

On Sun, Dec 08, 2013 at 04:09:04PM +0900, "Martin J. D=FCrst" wrote:
> On 2013/12/08 8:05, Allen Wirfs-Brock wrote:
> >JSON is derived from JavaSript (whose standard is ECMA-262) and since
> >2009, ECMA-262 (and its clone ISO/IEC-16262) has included a normative
> >specification for parsing JSON text that includes an ordering
> >semantics for object members.
>=20
> RFC 4627 was published in July 2006, so the ECMA-262 version of 2009
> may not be very relevant.

ECMA-262 may well have been a codification of older behavior -- there's
winning this sort of argument.  If there really is an unreconcilable
divergence as-deployed, then we ought to document that.  A simple
addition to the last paragraph (or a new paragraph after it) of section
4 of RFC4627bis-08 should suffice.

Nico
--=20

From duerst@it.aoyama.ac.jp  Sun Dec  8 01:59:11 2013
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0981ADDD3 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 01:59:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level: 
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=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 qn95P0dfilvd for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 01:59:10 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id CA3DE1AD8F6 for <json@ietf.org>; Sun,  8 Dec 2013 01:59:09 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rB89wrWu010806; Sun, 8 Dec 2013 18:58:53 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 684b_ed88_587db7b6_5fef_11e3_b0f9_001e6722eec2; Sun, 08 Dec 2013 18:58:53 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 56786BF54B; Sun,  8 Dec 2013 18:58:50 +0900 (JST)
Message-ID: <52A442CF.6060309@it.aoyama.ac.jp>
Date: Sun, 08 Dec 2013 18:58:39 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Carsten Bormann <cabo@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org>
In-Reply-To: <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 09:59:11 -0000

[Somebody please forward this to es-discuss@mozilla.org, unless it gets=20
delivered automatically.]

On 2013/12/07 21:10, Carsten Bormann wrote:
> On 07 Dec 2013, at 12:55, Nico Williams<nico@cryptonector.com>  wrote:
>
>> And we all now seem to agree
>> that the ABNF in draft-ietf-json-rfc4627bis-08 is equivalent to the
>> syntax in ECMA-404.
>
> Yes, we like to believe that.
> The thing that worries me is that nobody knows whether that is actually=
 true.
>
> (At least I=E2=80=99d hope someone who is comfortable with the descript=
ion methods in ECMA-404 makes a serious pass at establishing this equival=
ence, even when it=E2=80=99s ultimately not possible to actually prove it=
.  That someone will not be me.)

There are two description methods is ECMA-404: text and "railroad"=20
diagrams. The railroad diagrams are in no way referenced from the text=20
of the specification, and so in a strict interpretation, it's completely=20
unclear what they are doing there (it's not usual to spice up a standard=20
document with a few pretty pictures).

The textual descriptions are in some cases quite precise, but in some=20
other cases, leave quite a bit of ambiguity. And stuff like "It may have=20
an exponent of ten, prefixed by e (U+0065) or E (U+0045) and optionally=20
+ (U+002B) or =E2=80=93 (U+002D)." (in particlar the first clause of that=
=20
sentence) doesn't make much sense. If e.g. 1.2 has an exponent of 10,=20
it's going to be 6.1917 or so, not at all what this notation is usually=20
used for.

As for the railroad tracks, besides just floating in the spec without=20
references, the notation is also not at all explained. If one took the=20
most straightforward and obvious interpretation (that's not how=20
standards work, but anyway), it's not too difficult to come up with a=20
formally precise way of converting each of them into a diagrams for a=20
finite state machine. From there, conversion to the ABNF, or showing=20
equivalence, on a quite formal level, shouldn't be too much a problem.

Regards,   Martin.


From cabo@tzi.org  Sun Dec  8 02:27:17 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5271AD8EA for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 02:27:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.251
X-Spam-Level: 
X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001] autolearn=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 lB93aFTUW-00 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 02:27:15 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B931F1A1F1B for <json@ietf.org>; Sun,  8 Dec 2013 02:27:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB8AQvti021991; Sun, 8 Dec 2013 11:26:57 +0100 (CET)
Received: from [192.168.217.144] (p54891006.dip0.t-ipconnect.de [84.137.16.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 742F866F; Sun,  8 Dec 2013 11:26:55 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <52A442CF.6060309@it.aoyama.ac.jp>
Date: Sun, 8 Dec 2013 11:26:53 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E19BDE18-DA46-4C00-AA6C-205C348326AD@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp>
To: =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>
X-Mailer: Apple Mail (2.1822)
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 10:27:17 -0000

On 08 Dec 2013, at 10:58, Martin J. D=FCrst <duerst@it.aoyama.ac.jp> =
wrote:

> There are two description methods is ECMA-404: text and "railroad" =
diagrams.

There are actually two quite different kinds of racetracks (=93railroad =
diagrams=94), the first three at the parser level and the second two at =
the scanner level.  This is nowhere explained (it just happens to be the =
only one of the many potential interpretations of ECMA-404 that yields a =
result getting close to current practice), and you have to piece =
together from section 4 what the interface between the two levels might =
be.

> The textual descriptions are in some cases quite precise, but in some =
other cases, leave quite a bit of ambiguity. And stuff like "It may have =
an exponent of ten, prefixed by e (U+0065) or E (U+0045) and optionally =
+ (U+002B) or =96 (U+002D)." (in particlar the first clause of that =
sentence) doesn't make much sense.

I read them mainly as a way to give meaning to the bubbles in the =
racetracks.
All the statements that define the semantics of the data are really =
errata anyway, we have learned.
(If one were to do the semantics properly for section 8, one could =
simply reference ISO 6093.
RFC 4627 does that implicitly by saying "The representation of numbers =
is similar to that used in most programming languages.".)

> As for the railroad tracks, besides just floating in the spec without =
references, the notation is also not at all explained. If one took the =
most straightforward and obvious interpretation (that's not how =
standards work, but anyway), it's not too difficult to come up with a =
formally precise way of converting each of them into a diagrams for a =
finite state machine. =46rom there, conversion to the ABNF, or showing =
equivalence, on a quite formal level, shouldn't be too much a problem.

Yes, please.  I was asking for someone to do that work, maybe in the =
process generating some guidance on how to read ECMA-404.  It won=92t be =
me.

Gr=FC=DFe, Carsten


From derhoermi@gmx.net  Sun Dec  8 06:44:48 2013
Return-Path: <derhoermi@gmx.net>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EAB1ADF94 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 06:44:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 ObP4VsluW-4t for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 06:44:47 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id D0C4F1ADF5A for <json@ietf.org>; Sun,  8 Dec 2013 06:44:46 -0800 (PST)
Received: from netb.Speedport_W_700V ([91.35.46.128]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MfVzj-1WEmx93vR5-00P8wY for <json@ietf.org>; Sun, 08 Dec 2013 15:44:41 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>
Date: Sun, 08 Dec 2013 15:44:37 +0100
Message-ID: <gv09a91nc0uuvj5gdlsbcnuctuu5mq2q9d@hive.bjoern.hoehrmann.de>
References: <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp>
In-Reply-To: <52A442CF.6060309@it.aoyama.ac.jp>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:LaZ1U0RmD4F2fi+BRgeEF4A0OqOy0b5Qu5NK8vivw4nz+EeDOhK +PhBe0q53TmQaum/OxdzhXKTWjvR/JyWdZ2w26zSmzGBtWBbf2QNwf1PrzPgveo2IDlq/v4 slNKyMyLWsl595eGROkfK7CivJfHN2Sb7QaGd9fCh10pDK1uCcrwdKZziNac6xjFQYf6Pau L7n12hU4KBUCFuObO7yiQ==
Cc: "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 14:44:48 -0000

* Martin J. Dürst wrote:
>The textual descriptions are in some cases quite precise, but in some 
>other cases, leave quite a bit of ambiguity. And stuff like "It may have 
>an exponent of ten, prefixed by e (U+0065) or E (U+0045) and optionally 
>+ (U+002B) or – (U+002D)." (in particlar the first clause of that 
>sentence) doesn't make much sense. If e.g. 1.2 has an exponent of 10, 
>it's going to be 6.1917 or so, not at all what this notation is usually 
>used for.

Apparently in `x²` 2 is "an exponent of" x. That does not make much
sense to me either, but it does appear to be a common english idiom.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From cabo@tzi.org  Sun Dec  8 07:27:15 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDE61ADFAE for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 07:27:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.151
X-Spam-Level: 
X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 EEwUX2GAE2oW for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 07:27:14 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id AC1621ADFA5 for <json@ietf.org>; Sun,  8 Dec 2013 07:27:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB8FR1DZ022587; Sun, 8 Dec 2013 16:27:01 +0100 (CET)
Received: from [192.168.217.144] (p54891006.dip0.t-ipconnect.de [84.137.16.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4B39A6FA; Sun,  8 Dec 2013 16:27:00 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com>
Date: Sun, 8 Dec 2013 16:26:57 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A9B8F35-E67C-41B9-8CD9-9CE4D726FEBE@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
X-Mailer: Apple Mail (2.1822)
Cc: "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 15:27:15 -0000

Hi Allen,

here are some replies to your messages that I promised.  I opted not to
use line-by-line responses; I hope they are easier to read this way.
Two technical, and two more general points.

* Processing model

You are presenting a processing model that is based on a generic
parser that creates an AST and then application-specific
post-processing.  This is pretty much how XML worked.

One of the major advances of JSON was that it has a data model (even
if it is somewhat vaguely specified =97 implementers were still quick in
picking it up).  JSON implementations typically go right from the
characters to a representation of that data model that is appropriate
for the platform, and encoders typically go all the way back in one
step.  Interoperability happens as a result of this processing.

That's a major reason why it is so important to think about JSON in
terms of its data model.  The IETF JSON WG has elected not to flesh
out the model any more for 4627bis than it is in RFC 4627 (which I
personally don't agree with, but it would have been more hard work).
Dismantling what is there in the way of a data model, and thus falling
back into an XML mindset, would be a major regression, though.

* Description techniques

You are right that programming language designers have been used to
two-level grammars (scanner/parser) for a long time.  One thing that
RFC 4627 got right was not doing this, but using the single-level
ABNF.  (Technically, there still is an UTF-8 decoder below the ABNF,
but that is a rather well-understood, separable machine.)  JSON is
simple enough to enable single-level description, and RFC 5234 ABNF
provides a rigorous yet understandable way to do this.  There are
tools that operate on that ABNF and produce useful results, because it
has a defined meaning.

Let me be very frank here, because I get the impression that previous
statements about this were too diplomatic to be clear.

There is no way on earth that anyone can argue that the description of
the JSON syntax in ECMA-404 is in any way superior to that in RFC
4627.  By a large margin.  This is not about possibly finding bugs in
the hodge-podge that ECMA-404 is; thank you for offering to do ECMA's
work here, but I'm not biting.  This is about making sure from a start
that the spec is right.  Making 4627bis reference ECMA-404 would be a
major regression.  There is no reason for incurring this regression
seven years after it already was done right.  The IETF isn't known for
doing things that are unjustifiable on a technical level.

* Stewardship

You mention that there is significant programming language expertise
in TC39.  I couldn't agree more (actually, the previous sentence is a
wild understatement), and I can say that I have been using ECMA-262
(ES3 is the last version with which I have significant experience) as
a model for programming language standards.

My point was not at all about lack of experience, it is about
attention.  By its nature, TC39's work on JSON will always focus on
the narrower needs of JavaScript.  That makes TC39 less qualified for
the stewardship of a standard that transcends language barriers than
one might like to admit.  I'm not going to illustrate this point
further; there is ample illustration in the mailing list archives.

* Way forward

As always, only the chairs can speak for the JSON WG, and even they
need to confirm any needed consensus in the WG beforehand.  But I
think I can say that we are still only guessing what TC39 is trying to
achieve with the sudden creation of ECMA-404.  I think we need to have
a frank discussion about the objectives of further work on JSON.  The
JSON WG has a charter that defines its objectives, which is focusing
on stability and interoperability.  I'd like to understand TC39's
objectives with respect to JSON, so we can find out whether there is
common ground or not.

Gr=FC=DFe, Carsten


From cowan@ccil.org  Sun Dec  8 07:44:47 2013
Return-Path: <cowan@ccil.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463051ADFBA for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 07:44:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 mC2phOzt_OaX for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 07:44:45 -0800 (PST)
Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8D51ADFB8 for <json@ietf.org>; Sun,  8 Dec 2013 07:44:45 -0800 (PST)
Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from <cowan@ccil.org>) id 1VpgX5-00010H-Ur; Sun, 08 Dec 2013 10:44:36 -0500
Date: Sun, 8 Dec 2013 10:44:35 -0500
From: John Cowan <cowan@mercury.ccil.org>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Message-ID: <20131208154435.GH23243@mercury.ccil.org>
References: <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <20131208005521.GC23243@mercury.ccil.org> <646E66F1-5E35-4491-8D51-2462C84C1CDF@wirfs-brock.com> <mfl7a95ln19f1utk5ah7hd7grocue3mp3u@hive.bjoern.hoehrmann.de> <D9FC6908-E4B0-4411-8C2A-297EA66B651F@wirfs-brock.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D9FC6908-E4B0-4411-8C2A-297EA66B651F@wirfs-brock.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <cowan@ccil.org>
Cc: "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 15:44:47 -0000

Allen Wirfs-Brock scripsit:

> You are correct that, ES5 does not define the for-in enumeration order.
> But it does say that the Object.keys ordering must be the same as
> for-in enumeration order. and there is a defacto standard for a partial
> enumeration order that all browsers implement.

In short, half a dozen or so JSON implementations in a JavaScript
environment agree.  That hardly means that all other JSON implementations
in whatever environment should be dragged along with them.

-- 
John Cowan              http://www.ccil.org/~cowan      cowan@ccil.org
"After all, would you consider a man without honor wealthy, even if his
Dinar laid end to end would reach from here to the Temple of Toplat?"
"No, I wouldn't", the beggar replied.  "Why is that?" the Master asked.
"A Dinar doesn't go very far these days, Master.        --Kehlog Albran
Besides, the Temple of Toplat is across the street."      The Profit

From jorge@jorgechamorro.com  Sun Dec  8 07:59:30 2013
Return-Path: <jorge@jorgechamorro.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF2A1ADFC2 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 07:59:30 -0800 (PST)
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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 7LfgPYJkCrFh for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 07:59:29 -0800 (PST)
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id A442D1ADFBF for <json@ietf.org>; Sun,  8 Dec 2013 07:59:28 -0800 (PST)
Received: by mail-wi0-f171.google.com with SMTP id bz8so2648177wib.4 for <json@ietf.org>; Sun, 08 Dec 2013 07:59:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=gFDF5aTpI3x6PGplQe6zSB5JvFg+bcaUfz24+uNcXg4=; b=Irvngpbn2sfDqNxB/uAZ6LKhi0lf/upjZ8VqcF6lQHVAUHlw7tAnjJOTVpwHxQerAo ni5wq3ErXUwACAk251YgEVCyJeBC5+o3HH+f9ESWlz0biiw7o7cjlWA+rF4Iic34Yti9 igaj+QwRqopQytvRPJgGFZ8dJVUEiXssnwLAJaE3xZZKmi+Gqy71Nv2IaA4wkBZ9oMql R2Ooc8+dpNtpMvUqs/k4DWUQIzXUCg8AhmLpGpOE/RVzYgEG7eZklX/ITLqfgW0MEHnE i5G8smQ/VdUx9xGndwy0yy2hE19mUEPaQ2hLeNRTmMYFeU5GfoJGKUdEboBxY6C4mAMM C75Q==
X-Gm-Message-State: ALoCoQno/uZ8BoR0Z9YyoN8MyBpDWRmNSK4aq/Oc8aQu2e0utH3oKbEvpR9a3t7b44arAHYM1XzQ
X-Received: by 10.180.206.41 with SMTP id ll9mr10347082wic.7.1386518363579; Sun, 08 Dec 2013 07:59:23 -0800 (PST)
Received: from [192.168.10.50] (239.Red-81-36-17.dynamicIP.rima-tde.net. [81.36.17.239]) by mx.google.com with ESMTPSA id dn2sm16200427wid.1.2013.12.08.07.59.21 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Dec 2013 07:59:22 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Jorge Chamorro <jorge@jorgechamorro.com>
In-Reply-To: <4A9B8F35-E67C-41B9-8CD9-9CE4D726FEBE@tzi.org>
Date: Sun, 8 Dec 2013 16:59:20 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9BE9E6A1-ACB0-4F88-A89C-35B532FF1EED@jorgechamorro.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <4A9B8F35-E67C-41B9-8CD9-9CE4D726FEBE@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.1085)
X-Mailman-Approved-At: Sun, 08 Dec 2013 08:44:16 -0800
Cc: JSON WG <json@ietf.org>, Allen Wirfs-Brock <allen@wirfs-brock.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 15:59:30 -0000

On 08/12/2013, at 16:26, Carsten Bormann wrote:
>=20
> * Way forward
>=20
> As always, only the chairs can speak for the JSON WG, and even they
> need to confirm any needed consensus in the WG beforehand.  But I
> think I can say that we are still only guessing what TC39 is trying to
> achieve with the sudden creation of ECMA-404.  I think we need to have
> a frank discussion about the objectives of further work on JSON.  The
> JSON WG has a charter that defines its objectives, which is focusing
> on stability and interoperability.  I'd like to understand TC39's
> objectives with respect to JSON, so we can find out whether there is
> common ground or not.


Here's the message from the very same inventor of JSON telling exactly =
what's ECMA-404 "trying to achieve". Hope it helps:


Begin forwarded message:

> From: Douglas Crockford <douglas@crockford.com>
> Date: 13 de junio de 2013 17:50:33 GMT+02:00
> To: "json@ietf.org" <json@ietf.org>
> Subject: [Json] Two Documents
> content-type: text/plain; charset=3D"us-ascii"; Format=3D"flowed"
>=20
> The confusion and controversy around this work is due to a mistake =
that I
> made in RFC 4627. The purpose of the RFC, which is clearly indicated
> in the title, was to establish a MIME type. I also gave a description =
of
> the JSON Data Interchange Format. My mistake was in conflating the =
two,
> putting details about the MIME type into the description of the =
format. My
> intention was to add clarity. That obviously was not the result.
>=20
> JSON is just a format. It describes a syntax of brackets and commas =
that
> is useful in many contexts, profiles, and applications. JSON is =
agnostic
> about all of that stuff. JSON shouldn't even care about character =
encoding.
> Its only dependence on Unicode in the hex numbers used in the \u =
notation.
> JSON can be encoded in ASCII or EBCDIC or even Hollerith codes. JSON =
can
> be used in contexts where there is no character encoding at all, such =
as
> paper documents and marble monuments.
>=20
> There are uses of JSON however in which such choices matter, and where
> behavior needs to be attached to or derived from the syntax. That is
> important stuff, and it belongs in different documents. Such documents
> will place necessary restrictions on JSON's potential. No such =
document
> can fit all applications, which causes much of the controversy we've =
seen
> here. One size cannot fit all. JSON the format is universal. But real
> applications require reasonable restrictions.
>=20
> So we should be working on at least two documents, which is something =
we have
> discussed earlier. The first is The JSON Data Interchange Format, =
which is
> a simple grammar. The second is a best practices document, which =
recommends
> specific conventions of usage.
>=20
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json


From allen@wirfs-brock.com  Sun Dec  8 09:26:53 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D0C1AE020 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 09:26:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 ngu5_FC2mYSV for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 09:26:52 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 869F11AE01F for <json@ietf.org>; Sun,  8 Dec 2013 09:26:52 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1Vpi7x-0006FZ-Ru; Sun, 08 Dec 2013 17:26:45 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/RRf6C3pBMvIIBkjM0yynW5itDI7Acgxo=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <20131208154435.GH23243@mercury.ccil.org>
Date: Sun, 8 Dec 2013 09:26:39 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <F14161D6-CF60-4B11-B2F2-6A946419D481@wirfs-brock.com>
References: <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <20131208005521.GC23243@mercury.ccil.org> <646E66F1-5E35-4491-8D51-2462C84C1CDF@wirfs-brock.com> <mfl7a95ln19f1utk5ah7hd7grocue3mp3u@hive.bjoern.hoehrmann.de> <D9FC6908-E4B0-4411-8C2A-297EA66B651F@wirfs-brock.com> <20131208154435.GH23243@mercury.ccil.org>
To: John Cowan <cowan@mercury.ccil.org>
X-Mailer: Apple Mail (2.1085)
Cc: "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 17:26:53 -0000

On Dec 8, 2013, at 7:44 AM, John Cowan wrote:

> Allen Wirfs-Brock scripsit:
>=20
>> You are correct that, ES5 does not define the for-in enumeration =
order.
>> But it does say that the Object.keys ordering must be the same as
>> for-in enumeration order. and there is a defacto standard for a =
partial
>> enumeration order that all browsers implement.
>=20
> In short, half a dozen or so JSON implementations in a JavaScript
> environment agree.  That hardly means that all other JSON =
implementations
> in whatever environment should be dragged along with them.
>=20

Right, from an interoperability perspective, the half dozen or so user =
agents used by essentially the entire world to run web applications =
really aren't significant at all...

Allen=

From cowan@ccil.org  Sun Dec  8 09:37:42 2013
Return-Path: <cowan@ccil.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC021AE036 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 09:37:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 5FnpD7zjN-Jp for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 09:37:41 -0800 (PST)
Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 172A41AE033 for <json@ietf.org>; Sun,  8 Dec 2013 09:37:41 -0800 (PST)
Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from <cowan@ccil.org>) id 1VpiIO-0003Tp-Li; Sun, 08 Dec 2013 12:37:32 -0500
Date: Sun, 8 Dec 2013 12:37:32 -0500
From: John Cowan <cowan@mercury.ccil.org>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Message-ID: <20131208173732.GN23243@mercury.ccil.org>
References: <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <20131208005521.GC23243@mercury.ccil.org> <646E66F1-5E35-4491-8D51-2462C84C1CDF@wirfs-brock.com> <mfl7a95ln19f1utk5ah7hd7grocue3mp3u@hive.bjoern.hoehrmann.de> <D9FC6908-E4B0-4411-8C2A-297EA66B651F@wirfs-brock.com> <20131208154435.GH23243@mercury.ccil.org> <F14161D6-CF60-4B11-B2F2-6A946419D481@wirfs-brock.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F14161D6-CF60-4B11-B2F2-6A946419D481@wirfs-brock.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <cowan@ccil.org>
Cc: "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 17:37:42 -0000

Allen Wirfs-Brock scripsit:

> Right, from an interoperability perspective, the half dozen or so user
> agents used by essentially the entire world to run web applications
> really aren't significant at all...

"By George, I do believe you've got it!"

-- 
An observable characteristic is not necessarily         John Cowan
a functional requirement.  --John Hudson                cowan@ccil.org

From tbray@textuality.com  Sun Dec  8 09:49:15 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087811AE04F for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 09:49:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 xTEoTYpz_jsG for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 09:49:14 -0800 (PST)
Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id D0FEE1AE026 for <json@ietf.org>; Sun,  8 Dec 2013 09:49:13 -0800 (PST)
Received: by mail-vc0-f174.google.com with SMTP id id10so2669417vcb.19 for <json@ietf.org>; Sun, 08 Dec 2013 09:49:09 -0800 (PST)
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:content-type; bh=ty6rzz4E/BH+FPOScEmAej1LR9eg1Co9cTrq1ou2jU0=; b=Z8C3BrnFcEW5vs/1cWaqwDE51kmhXBjKyjZ1pnxeLp0toduqAiQ/3kxPRn3kmv+8Ny SOJ6lg9BExwllFvvaHGmC69nsq3wveXHbPHmupj6BjqsEZnsIbDo2dXO9oDFi/AJthnj eJlRFIqSEGkPyEcNI8InelQO8TiJxHkEPdV9vXvV5W/8npPgVuizQU7dQWuVzR04yL5z GXNLhYl7X5Ue1YO8xxce7eK7/6EXJm127dtflNTiuNhKn8mwHOtEZ7bpc5Jh+SDWJ3Z4 pQBUOdleGUiE8q29UA4FM85fyBp3rG5USmG8iypACcka/ptHKGihlqJcDm5a+rjCcl8z QcXA==
X-Gm-Message-State: ALoCoQkmLCOvFeyEztOir7j2fzqOQIdwsLpjv5CiyJzUQyxASgtXJ/TPaIRtghHBPKr4g+LfxGV2
MIME-Version: 1.0
X-Received: by 10.220.11.7 with SMTP id r7mr9464768vcr.12.1386524948968; Sun, 08 Dec 2013 09:49:08 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Sun, 8 Dec 2013 09:49:08 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <A35D96DE-FFA7-4B33-A927-DD5775E999E6@wirfs-brock.com>
References: <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <20131208005521.GC23243@mercury.ccil.org> <646E66F1-5E35-4491-8D51-2462C84C1CDF@wirfs-brock.com> <20131208032223.GG23243@mercury.ccil.org> <A35D96DE-FFA7-4B33-A927-DD5775E999E6@wirfs-brock.com>
Date: Sun, 8 Dec 2013 09:49:08 -0800
Message-ID: <CAHBU6iscM+ks64LqmHUdenSfuOfk_KDfn4zYcQ3VLvjpmxtceg@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Content-Type: multipart/alternative; boundary=001a11c3e47c0e49dd04ed097f48
Cc: John Cowan <cowan@mercury.ccil.org>, JSON WG <json@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 17:49:15 -0000

--001a11c3e47c0e49dd04ed097f48
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Allen is describing the semantics of JSON when generated/parsed by
JavaScript. The ordering property he describes seems to me like a
reasonable consequence of the non-traditional semantics of JavaScript
objects.   These semantics are properly defined, I think we can all agree,
in theECMAScript family of specifications.

However, in virtually all of the popular libraries that are used to
generate and parse the JSON that is being interchanged in very high volumes
right now, a JSON object is a serialized hash/dictionary/associative-array,
and that=E2=80=99s all it is.  This approach has led to the excellent
interoperability we observe today in interchanging JSON-packaged data.

It=E2=80=99s obvious that it would be inappropriate to impose object member
ordering in RFC4627bis, and I think it has also become obvious that the RFC
should not make a normative reference to any other document that might
decide to retroactively tell the rest of the JSON-using world to start
adopting idiosyncratic JavaScript semantics or be branded as non-conforming=
.


On Sat, Dec 7, 2013 at 8:06 PM, Allen Wirfs-Brock <allen@wirfs-brock.com>wr=
ote:

>
> On Dec 7, 2013, at 7:22 PM, John Cowan wrote:
>
> > Allen Wirfs-Brock scripsit:
> >
> >> In other words, ECMA-262 explicitly specifies that when multiple
> >> occurrences of the same member name occurs in a JSON object, the value
> >> associated with the last (right-most) occurrence is used. Order matter=
s.
> >
> > Okay, I concede that order matters *when* there are duplicate names.
> > I still deny that it matters otherwise.
>
> In reality it defines the JavaScript for-in enumeration order over the JS
> object property generated by JSON.parse.
>
> Try this in your favorite browser:
>
>    var jText =3D '{"b": 1, "a": 2, "c": 3};
>    for (var key in JSON.parse(jText) console.log(key);
>
> You will get as output:
>      b
>      a
>      c
>
> I can assure you that code exists on the web that depends, whether
> intentionally or not, on this ordering.  Past experience among browser
> implementations is that site break when attempts are made to change this
> ordering.
>
> Allen
>
>
>

--001a11c3e47c0e49dd04ed097f48
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Allen is describing the semantics of JSON when generated/p=
arsed by JavaScript.=C2=A0The ordering property he describes seems to me li=
ke a reasonable consequence of the non-traditional semantics of JavaScript =
objects. =C2=A0=C2=A0These semantics are properly defined, I think we can a=
ll agree, in theECMAScript family of specifications.=C2=A0=C2=A0<div>
<br></div><div>However, in virtually all of the popular libraries that are =
used to generate and parse the JSON that is being interchanged in very high=
 volumes right now, a JSON object is a serialized hash/dictionary/associati=
ve-array, and that=E2=80=99s all it is. =C2=A0This approach has led to the =
excellent interoperability we observe today in interchanging JSON-packaged =
data.</div>
<div><br></div><div>It=E2=80=99s obvious that it would be inappropriate to =
impose object member ordering in RFC4627bis, and I think it has also become=
 obvious that the RFC should not make a normative reference to any other do=
cument that might decide to retroactively tell the rest of the JSON-using w=
orld to start adopting idiosyncratic JavaScript semantics or be branded as =
non-conforming.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat,=
 Dec 7, 2013 at 8:06 PM, Allen Wirfs-Brock <span dir=3D"ltr">&lt;<a href=3D=
"mailto:allen@wirfs-brock.com" target=3D"_blank">allen@wirfs-brock.com</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><br>
On Dec 7, 2013, at 7:22 PM, John Cowan wrote:<br>
<br>
&gt; Allen Wirfs-Brock scripsit:<br>
&gt;<br>
&gt;&gt; In other words, ECMA-262 explicitly specifies that when multiple<b=
r>
&gt;&gt; occurrences of the same member name occurs in a JSON object, the v=
alue<br>
&gt;&gt; associated with the last (right-most) occurrence is used. Order ma=
tters.<br>
&gt;<br>
&gt; Okay, I concede that order matters *when* there are duplicate names.<b=
r>
&gt; I still deny that it matters otherwise.<br>
<br>
</div>In reality it defines the JavaScript for-in enumeration order over th=
e JS object property generated by JSON.parse.<br>
<br>
Try this in your favorite browser:<br>
<br>
=C2=A0 =C2=A0var jText =3D &#39;{&quot;b&quot;: 1, &quot;a&quot;: 2, &quot;=
c&quot;: 3};<br>
=C2=A0 =C2=A0for (var key in JSON.parse(jText) console.log(key);<br>
<br>
You will get as output:<br>
=C2=A0 =C2=A0 =C2=A0b<br>
=C2=A0 =C2=A0 =C2=A0a<br>
=C2=A0 =C2=A0 =C2=A0c<br>
<br>
I can assure you that code exists on the web that depends, whether intentio=
nally or not, on this ordering. =C2=A0Past experience among browser impleme=
ntations is that site break when attempts are made to change this ordering.=
<br>

<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Allen<br>
<br>
<br>
</font></span></blockquote></div><br></div>

--001a11c3e47c0e49dd04ed097f48--

From julian.reschke@gmx.de  Sun Dec  8 10:07:48 2013
Return-Path: <julian.reschke@gmx.de>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589811AE05C for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 10:07:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 43KV5GP3FZK5 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 10:07:47 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id D00541AE03F for <json@ietf.org>; Sun,  8 Dec 2013 10:07:46 -0800 (PST)
Received: from [192.168.2.117] ([84.187.35.98]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LyzW8-1VTbPJ1KyW-014DuT for <json@ietf.org>; Sun, 08 Dec 2013 19:07:41 +0100
Message-ID: <52A4B56A.4020805@gmx.de>
Date: Sun, 08 Dec 2013 19:07:38 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Allen Wirfs-Brock <allen@wirfs-brock.com>,  John Cowan <cowan@mercury.ccil.org>
References: <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <20131208005521.GC23243@mercury.ccil.org> <646E66F1-5E35-4491-8D51-2462C84C1CDF@wirfs-brock.com> <mfl7a95ln19f1utk5ah7hd7grocue3mp3u@hive.bjoern.hoehrmann.de> <D9FC6908-E4B0-4411-8C2A-297EA66B651F@wirfs-brock.com> <20131208154435.GH23243@mercury.ccil.org> <F14161D6-CF60-4B11-B2F2-6A946419D481@wirfs-brock.com>
In-Reply-To: <F14161D6-CF60-4B11-B2F2-6A946419D481@wirfs-brock.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:METiqO5m1WkqDw2dnSrjvC9ufJaUIfkV+Dnuhy4GHWUUHUuPYDV b7u0fkWj8VEGDwcFH0NbxsZXBdRjosHKgmMrZhlUWIzI2zaSTslzvKB0hJB3PbO00ZTpyc3 hGeMaauGIr2f1ZB0+wvK4P2dI4+Wo8iWhx1t0j2q8AZ04SUBwPr+GcwcSSYncItNoiVkZiD 1tdHZyUyv3/aa2MLo22rA==
Cc: JSON WG <json@ietf.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 18:07:48 -0000

On 2013-12-08 18:26, Allen Wirfs-Brock wrote:
>
> On Dec 8, 2013, at 7:44 AM, John Cowan wrote:
>
>> Allen Wirfs-Brock scripsit:
>>
>>> You are correct that, ES5 does not define the for-in enumeration order.
>>> But it does say that the Object.keys ordering must be the same as
>>> for-in enumeration order. and there is a defacto standard for a partial
>>> enumeration order that all browsers implement.
>>
>> In short, half a dozen or so JSON implementations in a JavaScript
>> environment agree.  That hardly means that all other JSON implementations
>> in whatever environment should be dragged along with them.
>>
>
> Right, from an interoperability perspective, the half dozen or so user agents used by essentially the entire world to run web applications really aren't significant at all...

There are two parts to a web application; the browser is just one of 
them. The point of JSON as an interchange format is to enable browsers 
to talk to *servers* (or servers to servers, or servers to other kinds 
of clients), not browsers to browsers.

If you really believe this is the way to go, why don't you start by 
asking Douglas Crockford to remove

   "An object is an unordered set of name/value pairs."

from JSON.org?

Best regards, Julian

From allen@wirfs-brock.com  Sun Dec  8 10:57:42 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C237E1AE071 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 10:57:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 6CWxV9canz2d for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 10:57:41 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id BC2B71AE021 for <json@ietf.org>; Sun,  8 Dec 2013 10:57:41 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1VpjXq-000MsK-10; Sun, 08 Dec 2013 18:57:34 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+JpGZqdNRgRqQezgAepnIPNwhCGdK1TnE=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <52A4191D.7000905@it.aoyama.ac.jp>
Date: Sun, 8 Dec 2013 10:57:25 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <8B80875D-8FF5-48D9-BD8E-EE2F1363CCFE@wirfs-brock.com>
References: <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com> <CAHBU6it=NXw4EBgxmN-1xA_7hUdMMs77iYaXQs_q0SwkBv_A8Q@mail.gmail.com> <20131208004934.GB23243@mercury.ccil.org> <52A4191D.7000905@it.aoyama.ac.jp>
To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= <duerst@it.aoyama.ac.jp>
X-Mailer: Apple Mail (2.1085)
Cc: John Cowan <cowan@mercury.ccil.org>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 18:57:42 -0000

On Dec 7, 2013, at 11:00 PM, Martin J. D=FCrst wrote:

> On 2013/12/08 9:49, John Cowan wrote:
>> Tim Bray scripsit:
>>=20
>>> I assume all parties to the discussion know that in 100% of all
>>> programming-language libraries in use for dealing with JSON as
>>> transmitted on the wire, JSON objects are loaded into hash tables
>>> or dicts or whatever your language idiom is, and there is no way
>>> for software using those libraries to discover what order they were
>>> serialized in,
>>=20
>> Well, no, not 100%.  In Lisp-family languages, JSON objects are often
>> deserialized to ordered constructs.  Nevertheless:
>=20
> Similarly, as of somewhere around version 1.9.x or 2.0, Hash entries =
in Ruby are ordered, and one would assume that the original order in =
JSON would be reflected in the order of the Hash entries.
>=20
>>> any suggestion that this order should be considered significant for
>>> application usage would be regarded as insane.
>>=20
>> +1 to that.
>=20
> +1 here, too.

Millions of web developers write code with these sorts of dependencies.  =
Not because they are insane, more often it is because then are unaware =
of the bit falls.  However, its not an interoperability issue if they =
are writing web application code that is only intended run in a web =
browser and all browsers behave the same on that code.

More broadly, the JSON language binding parsers that I'm most familiar =
with do not generate a high fidelity  view of all valid JSON texts that =
they are presented with. It would be a mistake to depend upon such =
parsers to interchange data using JSON schemas that assign meaning to =
the ordering of object members.  However, that would not necessarily be =
the case for an application that is using a streaming JSON parser.

Consider this informal description of a data schema that is =
representable using JSON.

Conversation Schema:  A Conversation is a JSON text consisting of a =
single JSON object. The object may have an arbitrary number of members. =
The members represent a natural language conversation where the key part =
of each member identifies participant in the conversation and the value =
part of each member is a JSON string value that captures a statement by =
the associated participant. Multiple members may have the same key =
value, corresponding to multiple statements by the same participant. The =
order of the members corresponding to the order in which the statements =
were made during the conversation. =20

And here is an example of such a JSON text:

------------start JSON text-------------
{
"allenwb":  "there is an objectively observable order to the members of =
a JSON object",
"JSON WG participant 1":  "It would be insane to depend upon that =
ordering",
"allenwb":  "not if there is agreement between a producer and consumer =
on the meaning of the ordering",
"JSON WG participant 2":  "But JSON.parse and similar language bindings =
don't preserve order",
"allenwb":  "A streaming JSON parser would naturally preserve member =
order",
"JSON WG participant 2": "I din't think there are any such parsers",
"allenwb": "But someone might decide to create one, and if they do it =
will expose object members, in order",
"allenwb": "Plus, in this particular case the schema is so simple the =
application developer might well design to write a custom, schema =
specific streaming parser."
}
-----------end JSON text-------

Allen


From allen@wirfs-brock.com  Sun Dec  8 11:03:58 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4D81AE071 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 11:03:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 J9gahTaB-mPU for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 11:03:57 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 61CFD1AE03E for <json@ietf.org>; Sun,  8 Dec 2013 11:03:57 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1Vpjdv-000PhD-Di; Sun, 08 Dec 2013 19:03:51 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/fhVmCP1+q4r/An5c4yiGIKgHfHoIBbEs=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=windows-1252
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <52A41B10.4080701@it.aoyama.ac.jp>
Date: Sun, 8 Dec 2013 11:03:44 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <477FE4F2-AE4B-4DFB-969F-D09BA7DAC383@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com> <52A41B10.4080701@it.aoyama.ac.jp>
To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= <duerst@it.aoyama.ac.jp>
X-Mailer: Apple Mail (2.1085)
Cc: JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 19:03:58 -0000

On Dec 7, 2013, at 11:09 PM, Martin J. D=FCrst wrote:

> [Somebody please forward this message to es-discuss@mozilla.org, =
unless it's not rejected.]
>=20
> On 2013/12/08 8:05, Allen Wirfs-Brock wrote:
>=20
>>> In JSON, objects are unordered collections or sets of name/value =
pairs.  It says so right there on json.org (=93sets=94), and it says so =
in RFC 4627 (=93collections=94)*).  We may not like it, but it has been =
a promise for a decade.  We need to heed it.  (Another promise was that =
JSON doesn=92t change**).)
>>=20
>> You also need to look at objective reality and consider the =
possibility that the informal (and non-normative text) on both the =
json.org website and in the original RFC never actually matched reality.
>>=20
>> JSON is derived from JavaSript (whose standard is ECMA-262) and since =
2009, ECMA-262 (and its clone ISO/IEC-16262) has included a normative =
specification for parsing JSON text that includes an ordering semantics =
for object members.
>=20
> RFC 4627 was published in July 2006, so the ECMA-262 version of 2009 =
may not be very relevant.
>=20
My understanding was that one of reasons for activating the JSONWG was =
the perceived need for a JSON grammar that could be normatively =
referenced.  RFC 4627 (2006) was not a normative document.  ECMA-262, =
5th Edition (2009) aka ISO/IEC-16262-3 (2011) is a normative document.  =
So is ECMA-404.

Allen=20


From tbray@textuality.com  Sun Dec  8 11:06:23 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2488A1AE073 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 11:06:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 Iyzs3izAlYcN for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 11:06:21 -0800 (PST)
Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5361AE071 for <json@ietf.org>; Sun,  8 Dec 2013 11:06:21 -0800 (PST)
Received: by mail-ve0-f181.google.com with SMTP id oy12so2836565veb.40 for <json@ietf.org>; Sun, 08 Dec 2013 11:06:16 -0800 (PST)
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:content-type; bh=saOQlW7oXS7miwDqmeQjBPzhZ28M9U8fYWobuk/ujkE=; b=EOHZggSV1IoQ3SzxmC3bteC4h69ydG5RwF/sdtAd8lIyYOY7zyDd93O3ggVM5S+NJT NHrySl2vFglZmvfV6OrGYjifWfLMQ0pZBL+oXG0V9oWLkG7GGubFFjyxmnPjLw0NsY02 DHjxib8fzdWZqkkO8Wx36l6PtKisv1LwEiSR8gimUjDgwI/Fr8Nczc60s66Yb5yclMKh hIsB2WZnDS13q83XVqJdO9HnlbxK3iIrXixHpy3R0jcMcVgPKAY5PIumRxi/FwK6OJpK 8ab2VRGCtbBSr1nkwkFM75tcTCxby+CsaeRkw4me26fKDkeffQ0cKnPOBhj2E22hT1xp n3fQ==
X-Gm-Message-State: ALoCoQnk4CpIAa/K22tQAdXJcqviHdhWtvjlyixcqmP6gJEdxkJyUQ2bVCP9jm2Bc0s3bWvYRQR4
MIME-Version: 1.0
X-Received: by 10.58.146.71 with SMTP id ta7mr129697veb.23.1386529576484; Sun, 08 Dec 2013 11:06:16 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Sun, 8 Dec 2013 11:06:16 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <8B80875D-8FF5-48D9-BD8E-EE2F1363CCFE@wirfs-brock.com>
References: <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com> <CAHBU6it=NXw4EBgxmN-1xA_7hUdMMs77iYaXQs_q0SwkBv_A8Q@mail.gmail.com> <20131208004934.GB23243@mercury.ccil.org> <52A4191D.7000905@it.aoyama.ac.jp> <8B80875D-8FF5-48D9-BD8E-EE2F1363CCFE@wirfs-brock.com>
Date: Sun, 8 Dec 2013 11:06:16 -0800
Message-ID: <CAHBU6issN9T-rHGYtZ-4pXgHABXqTU6rwbmuvaBA3-51BFCHaQ@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Content-Type: multipart/alternative; boundary=047d7b5d4a30e094c304ed0a92c3
Cc: John Cowan <cowan@mercury.ccil.org>, JSON WG <json@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= <duerst@it.aoyama.ac.jp>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 19:06:23 -0000

--047d7b5d4a30e094c304ed0a92c3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Dec 8, 2013 at 10:57 AM, Allen Wirfs-Brock <allen@wirfs-brock.com>w=
rote:

> Conversation Schema:
>
...

> And here is an example of such a JSON text:
>
> {
> "allenwb":  "there is an objectively observable order to the members of a
> JSON object",
> "JSON WG participant 1":  "It would be insane to depend upon that
> ordering",
>

...

If this turns out to work when both ends of the conversation are JavaScript
implementations, that=E2=80=99s a pleasant accident.  I think it would be a=
 mistake
to design anything for use on the Internet which relies on the choice of
language used to implement the endpoints.  This would fail to work on every
JSON implementation I=E2=80=99ve used in recent years.  It hardly needs poi=
nting
out that something like the following would be a better model, and would
work in all known generators and parsers, streaming or otherwise.

{
   "protocol-version" : 2.3
   "conversation" : [
     { "who" : "Allen", "remark" : "there is an objectively observable
order to the members of a JSON object" },
     { "who" : "Tim", "remark" : "but very few JSON implementations
preserve it, so nobody should rely on it" }
   ]
}


>
>
> Allen
>
>

--047d7b5d4a30e094c304ed0a92c3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Dec 8, 2013 at 10:57 AM, Allen Wirfs-Brock <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:allen@wirfs-brock.com" target=3D"_blank">allen@wirfs-brock.com<=
/a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im"><span style=3D"color:rgb(34,34,34)">Conv=
ersation Schema:</span></div>
</blockquote><div>...=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><div class=3D"im"><span s=
tyle=3D"color:rgb(34,34,34)">And here is an example of such a JSON text:</s=
pan><br>
</div>
<br>{<br>
&quot;allenwb&quot;: =C2=A0&quot;there is an objectively observable order t=
o the members of a JSON object&quot;,<br>
&quot;JSON WG participant 1&quot;: =C2=A0&quot;It would be insane to depend=
 upon that ordering&quot;,<br></blockquote><div>=C2=A0</div><div>...</div><=
div><br></div><div>If this turns out to work when both ends of the conversa=
tion are JavaScript implementations, that=E2=80=99s a pleasant accident. =
=C2=A0I think it would be a mistake to design anything for use on the Inter=
net which relies on the choice of language used to implement the endpoints.=
 =C2=A0This would fail to work on every JSON implementation I=E2=80=99ve us=
ed in recent years. =C2=A0It hardly needs pointing out that something like =
the following would be a better model, and would work in all known generato=
rs and parsers, streaming or otherwise.</div>
<div><br></div><div>{=C2=A0</div><div>=C2=A0 =C2=A0&quot;protocol-version&q=
uot; : 2.3</div><div>=C2=A0 =C2=A0&quot;conversation&quot; : [</div><div>=
=C2=A0 =C2=A0 =C2=A0{ &quot;who&quot; : &quot;Allen&quot;, &quot;remark&quo=
t; : &quot;there is an objectively observable order to the members of a JSO=
N object&quot; },</div>
<div>=C2=A0 =C2=A0 =C2=A0{ &quot;who&quot; : &quot;Tim&quot;, &quot;remark&=
quot; : &quot;but very few JSON implementations preserve it, so nobody shou=
ld rely on it&quot; }</div><div>=C2=A0 =C2=A0]<br></div><div>}</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">
<br>
<br>
Allen<br>
<br>
</blockquote></div><br></div></div>

--047d7b5d4a30e094c304ed0a92c3--

From allen@wirfs-brock.com  Sun Dec  8 11:13:29 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5781AE073 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 11:13:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 kc4he4hG8rdy for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 11:13:28 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id E05661AE009 for <json@ietf.org>; Sun,  8 Dec 2013 11:13:27 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1Vpjn8-0006oi-9M; Sun, 08 Dec 2013 19:13:22 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19uMk+ZFl/vW1GIdP4Hr9Dmq3tPYiDMaPc=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <20131208072144.GF4067@localhost>
Date: Sun, 8 Dec 2013 11:13:12 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <1DEF983B-E5F1-47C1-A466-CDA0C2B179D0@wirfs-brock.com>
References: <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com> <52A41B10.4080701@it.aoyama.ac.jp> <20131208072144.GF4067@localhost>
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.1085)
Cc: JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 19:13:29 -0000

On Dec 7, 2013, at 11:21 PM, Nico Williams wrote:

> On Sun, Dec 08, 2013 at 04:09:04PM +0900, "Martin J. D=FCrst" wrote:
>> On 2013/12/08 8:05, Allen Wirfs-Brock wrote:
>>> JSON is derived from JavaSript (whose standard is ECMA-262) and =
since
>>> 2009, ECMA-262 (and its clone ISO/IEC-16262) has included a =
normative
>>> specification for parsing JSON text that includes an ordering
>>> semantics for object members.
>>=20
>> RFC 4627 was published in July 2006, so the ECMA-262 version of 2009
>> may not be very relevant.
>=20
> ECMA-262 may well have been a codification of older behavior -- =
there's
> winning this sort of argument.  If there really is an unreconcilable
> divergence as-deployed, then we ought to document that.  A simple
> addition to the last paragraph (or a new paragraph after it) of =
section
> 4 of RFC4627bis-08 should suffice.

I agree.  Fundamentally I have been asking what is the technical meaning =
of the statement "an object is an unordered collection" that occurs in =
section 1 (Introduction) of the current draft for 4627bis.  No one has =
yet responded to my question regarding whether or not statements in the =
Introduction are considered normative. =20

Section 4 which presumably is supplying the normative specification of a =
JSON object currently says nothing about member ordering. =20

If the intent is for the statement in the introduction to have some =
normative mean, then please make that meaning technically clear in =
section 4.=20

Allen


From cabo@tzi.org  Sun Dec  8 11:13:38 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C831AE08B for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 11:13:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.951
X-Spam-Level: 
X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_45=0.6, SPF_HELO_PASS=-0.001] autolearn=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 P7EyEjzbWfQL for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 11:13:37 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9E75D1AE087 for <json@ietf.org>; Sun,  8 Dec 2013 11:13:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB8JDN64026720; Sun, 8 Dec 2013 20:13:23 +0100 (CET)
Received: from [192.168.217.144] (p54891006.dip0.t-ipconnect.de [84.137.16.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C8A0C79D; Sun,  8 Dec 2013 20:13:21 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <8B80875D-8FF5-48D9-BD8E-EE2F1363CCFE@wirfs-brock.com>
Date: Sun, 8 Dec 2013 20:13:19 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2812A1F8-362B-4095-A6D5-D388DF9E0A3A@tzi.org>
References: <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com> <CAHBU6it=NXw4EBgxmN-1xA_7hUdMMs77iYaXQs_q0SwkBv_A8Q@mail.gmail.com> <20131208004934.GB23243@mercury.ccil.org> <52A4191D.7000905@it.aoyama.ac.jp> <8B80875D-8FF5-48D9-BD8E-EE2F1363CCFE@wirfs-brock.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
X-Mailer: Apple Mail (2.1822)
Cc: John Cowan <cowan@mercury.ccil.org>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 19:13:38 -0000

On 08 Dec 2013, at 19:57, Allen Wirfs-Brock <allen@wirfs-brock.com> =
wrote:

> {
> "allenwb":  "there is an objectively observable order to the members =
of a JSON object",
> "JSON WG participant 1":  "It would be insane to depend upon that =
ordering",
> "allenwb":  "not if there is agreement between a producer and consumer =
on the meaning of the ordering",
> "JSON WG participant 2":  "But JSON.parse and similar language =
bindings don't preserve order",
> "allenwb":  "A streaming JSON parser would naturally preserve member =
order",
> "JSON WG participant 2": "I din't think there are any such parsers",
> "allenwb": "But someone might decide to create one, and if they do it =
will expose object members, in order",
> "allenwb": "Plus, in this particular case the schema is so simple the =
application developer might well design to write a custom, schema =
specific streaming parser."
> }

Which by at least one JSON decoder*) is decoded as:

---
allenwb: Plus, in this particular case the schema is so simple the =
application developer
  might well design to write a custom, schema specific streaming parser.
JSON WG participant 1: It would be insane to depend upon that ordering
JSON WG participant 2: I din't think there are any such parsers

(For readability, this one encoded in YAML, another JSON extension.)

Nice demonstration of the point here.

Gr=FC=DFe, Carsten

*) ruby -rjson -ryaml -e 'puts =
JSON.parse(File.read("allen.json")).to_yaml' >allen.yaml


From tbray@textuality.com  Sun Dec  8 11:26:54 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CC31AE07F for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 11:26:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 OI84n21PAQ2L for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 11:26:52 -0800 (PST)
Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id EA7F01AE079 for <json@ietf.org>; Sun,  8 Dec 2013 11:26:51 -0800 (PST)
Received: by mail-ve0-f171.google.com with SMTP id pa12so2920803veb.30 for <json@ietf.org>; Sun, 08 Dec 2013 11:26:47 -0800 (PST)
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:content-type; bh=MBcTWdFhVcJTJ6J/4IQzojCzAhekPuj56oGnagHyHXs=; b=KjIIlpyR6O2cIeN/6k7cn0uZeYeCIEm6zr9bntcH1PZrD/ZSPL+jXA4OGjst8eYHZw zsFg9e45AJQGWb6me5ZcYpLML3LQZinMHhvQG5Ev7HWMWpyZq8v9rKHcJDikW7QwHzNE PIsV+pv52HcgQqfRGZgm6dB9QSeP7bJ27azO/TwfO2T/9aV0pnwj+18N+FMR4VJnhaiS sknKxKvHt54fp8NZA7pUqXLL4+az4+y+yi3TA1trMZLmTr7b8aW68bjX1plrOjq9w2Vp iVXU+sT5aG1/GqV7f26L1PMdQYBWhfeuYLI6qvCkm+9D8NhVVnkjEjVutFh2B5dBp64c Dr8Q==
X-Gm-Message-State: ALoCoQnXGKLqgtOD8LenmSiNMLH88LgslccgYf8eHdgAL6npfvH060QNsT1Fa6uptEpZtBUp79YK
MIME-Version: 1.0
X-Received: by 10.52.52.137 with SMTP id t9mr135803vdo.22.1386530807228; Sun, 08 Dec 2013 11:26:47 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Sun, 8 Dec 2013 11:26:47 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <1DEF983B-E5F1-47C1-A466-CDA0C2B179D0@wirfs-brock.com>
References: <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com> <52A41B10.4080701@it.aoyama.ac.jp> <20131208072144.GF4067@localhost> <1DEF983B-E5F1-47C1-A466-CDA0C2B179D0@wirfs-brock.com>
Date: Sun, 8 Dec 2013 11:26:47 -0800
Message-ID: <CAHBU6it_yF2uiOZoLpAkYBoND=zoUQuc4Jp1rz_Bz4uN0e4h7A@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Content-Type: multipart/alternative; boundary=089e0122f65e3c417504ed0adc3a
Cc: JSON WG <json@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= <duerst@it.aoyama.ac.jp>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 19:26:54 -0000

--089e0122f65e3c417504ed0adc3a
Content-Type: text/plain; charset=UTF-8

On Sun, Dec 8, 2013 at 11:13 AM, Allen Wirfs-Brock <allen@wirfs-brock.com>wrote:

> I agree.  Fundamentally I have been asking what is the technical meaning
> of the statement "an object is an unordered collection" that occurs in
> section 1 (Introduction) of the current draft for 4627bis.  No one has yet
> responded to my question regarding whether or not statements in the
> Introduction are considered normative.
>
> Section 4 which presumably is supplying the normative specification of a
> JSON object currently says nothing about member ordering.
>
> If the intent is for the statement in the introduction to have some
> normative mean, then please make that meaning technically clear in section
> 4.
>

I find it hard to disagree.  How about adding this to the end of section 4:

Some JSON parser implementations, including those which conform to
ECMAScript specifications starting with [Allen, what goes here?], preserve
the order of object members and make it available to application code.
 However, implementations in many other languages do not.  Application code
which does not rely on detecting the order of object members will be
interoperable in the sense that its behavior will be the same when using
either class of parser.



>
> Allen
>
>

--089e0122f65e3c417504ed0adc3a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Dec 8, 2013 at 11:13 AM, Allen Wirfs-Brock <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:allen@wirfs-brock.com" target=3D"_blank">allen@wirfs-brock.com<=
/a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5"><spa=
n style=3D"color:rgb(34,34,34)">I agree. =C2=A0Fundamentally I have been as=
king what is the technical meaning of the statement &quot;an object is an u=
nordered collection&quot; that occurs in section 1 (Introduction) of the cu=
rrent draft for 4627bis. =C2=A0No one has yet responded to my question rega=
rding whether or not statements in the Introduction are considered normativ=
e.</span><br>
</div></div>
<br>
Section 4 which presumably is supplying the normative specification of a JS=
ON object currently says nothing about member ordering.<br>
<br>
If the intent is for the statement in the introduction to have some normati=
ve mean, then please make that meaning technically clear in section 4.<br><=
/blockquote><div><br></div><div>I find it hard to disagree. =C2=A0How about=
 adding this to the end of section 4:</div>
<div><br></div><div>Some JSON parser implementations, including those which=
 conform to ECMAScript specifications starting with [Allen, what goes here?=
], preserve the order of object members and make it available to applicatio=
n code. =C2=A0However, implementations in many other languages do not. =C2=
=A0Application code which does not rely on detecting the order of object me=
mbers will be interoperable in the sense that its behavior will be the same=
 when using either class of parser.</div>
<div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Allen<br>
<br>
</font></span></blockquote></div><br></div></div>

--089e0122f65e3c417504ed0adc3a--

From derhoermi@gmx.net  Sun Dec  8 12:00:13 2013
Return-Path: <derhoermi@gmx.net>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7805E1AE104 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 12:00:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level: 
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 97vhYNEl-8rH for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 12:00:12 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1491AE0D7 for <json@ietf.org>; Sun,  8 Dec 2013 12:00:10 -0800 (PST)
Received: from netb.Speedport_W_700V ([91.35.8.216]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0MgoiC-1WBhDw3zhA-00M56h for <json@ietf.org>; Sun, 08 Dec 2013 21:00:05 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Sun, 08 Dec 2013 21:00:04 +0100
Message-ID: <lvh9a9hvvad6p01rlklup9smdocho39bm0@hive.bjoern.hoehrmann.de>
References: <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com> <CAHBU6it=NXw4EBgxmN-1xA_7hUdMMs77iYaXQs_q0SwkBv_A8Q@mail.gmail.com> <20131208004934.GB23243@mercury.ccil.org> <52A4191D.7000905@it.aoyama.ac.jp> <8B80875D-8FF5-48D9-BD8E-EE2F1363CCFE@wirfs-brock.com>
In-Reply-To: <8B80875D-8FF5-48D9-BD8E-EE2F1363CCFE@wirfs-brock.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:T4PdamGNk3OGNvGNNR+6ilBONiQXp70j81mnUP7/h+8M88Kz2R8 EOOn/j1+wuOZCO40TzZXahutZRtxBO5R009rP7Hy571Dq8ZtvlL5qsm1HcQ//Xdw4zBNoKp zC4qlbSvbRExFRRo6ew2Nb7sAcQ4PLloH/wILuH+tS4y0Gf3eYfQpEvTfCyxaYjYVqfiysM lz1pcsLBMumKiEckedllQ==
Cc: "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 20:00:13 -0000

* Allen Wirfs-Brock wrote:
>------------start JSON text-------------
>{
>"allenwb":  "there is an objectively observable order to the members of a JSON object",
>"JSON WG participant 1":  "It would be insane to depend upon that ordering",
>"allenwb":  "not if there is agreement between a producer and consumer on the meaning of the ordering",
>"JSON WG participant 2":  "But JSON.parse and similar language bindings don't preserve order",
>"allenwb":  "A streaming JSON parser would naturally preserve member order",
>"JSON WG participant 2": "I din't think there are any such parsers",
>"allenwb": "But someone might decide to create one, and if they do it will expose object members, in order",
>"allenwb": "Plus, in this particular case the schema is so simple the application developer might well design to write a custom, schema specific streaming parser."
>}
>-----------end JSON text-------

There is observable white space outside strings in JSON texts. It would
be insane to depend on the placement of white space outside strings. Not
if there is agreement on the meaning of that white space. Most parsers
do not preserve such white space. A generic ABNF parser would naturally
preserve it...

It is quite possible that there are steganographic or cryptographic pro-
tocols that use insignificant white space in JSON texts as subtle form
of communication or for integrity protection, just like they might use
order of object members for the same purpose.

However, what we are discussing here is what people should assume when
we say "We use JSON!" so there do not have to be detailed negotiations
to establish agreements, i.e., a Standard. And people should very much
assume that the ordering of object members is as insignificant as the
placement of white space outside strings.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From julian.reschke@gmx.de  Sun Dec  8 12:34:48 2013
Return-Path: <julian.reschke@gmx.de>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73DDF1AE0C8 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 12:34:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 YdGj7djOWz4y for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 12:34:47 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2165E1AE0CF for <json@ietf.org>; Sun,  8 Dec 2013 12:34:47 -0800 (PST)
Received: from [192.168.2.117] ([84.187.35.98]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LZiQy-1V8lH844eC-00lSoZ for <json@ietf.org>; Sun, 08 Dec 2013 21:34:41 +0100
Message-ID: <52A4D7DB.3050604@gmx.de>
Date: Sun, 08 Dec 2013 21:34:35 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Allen Wirfs-Brock <allen@wirfs-brock.com>, =?windows-1252?Q?=22Martin?= =?windows-1252?Q?_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com> <52A41B10.4080701@it.aoyama.ac.jp> <477FE4F2-AE4B-4DFB-969F-D09BA7DAC383@wirfs-brock.com>
In-Reply-To: <477FE4F2-AE4B-4DFB-969F-D09BA7DAC383@wirfs-brock.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:L7HVV4SZdCQmj6zyx6HAQe1miUzV7f+OtCrtTQUmc/b2eTGznQV FGRMI8sPH8/A7265lw8m9ifrxtwwUi7x+B12jPvXUOvnSSd9/85dU8Znska/b9pS4vNHV9Q H8en1TQvkCRD+EqIfCv2ZOvy6eKfIEwS+eeVrNmOjYOtAEuOFuwqtaVQMLVsRd833Y+dkBE WhuX1ioM1COty1PlUXDZg==
Cc: JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Dec 2013 20:34:48 -0000

On 2013-12-08 20:03, Allen Wirfs-Brock wrote:
>
> On Dec 7, 2013, at 11:09 PM, Martin J. Dürst wrote:
>
>> [Somebody please forward this message to es-discuss@mozilla.org, unless it's not rejected.]
>>
>> On 2013/12/08 8:05, Allen Wirfs-Brock wrote:
>>
>>>> In JSON, objects are unordered collections or sets of name/value pairs.  It says so right there on json.org (“sets”), and it says so in RFC 4627 (“collections”)*).  We may not like it, but it has been a promise for a decade.  We need to heed it.  (Another promise was that JSON doesn’t change**).)
>>>
>>> You also need to look at objective reality and consider the possibility that the informal (and non-normative text) on both the json.org website and in the original RFC never actually matched reality.
>>>
>>> JSON is derived from JavaSript (whose standard is ECMA-262) and since 2009, ECMA-262 (and its clone ISO/IEC-16262) has included a normative specification for parsing JSON text that includes an ordering semantics for object members.
>>
>> RFC 4627 was published in July 2006, so the ECMA-262 version of 2009 may not be very relevant.
>>
> My understanding was that one of reasons for activating the JSONWG was the perceived need for a JSON grammar that could be normatively referenced.  RFC 4627 (2006) was not a normative document.  ECMA-262, 5th Edition (2009) aka ISO/IEC-16262-3 (2011) is a normative document.  So is ECMA-404.

RFC 4627 is a normative document in that it defines the wire format for 
application/json. That it wasn't on the IETF standards tracks is an 
entirely orthogonal issue.

Best regards, Julian


From James.H.Manger@team.telstra.com  Sun Dec  8 16:09:26 2013
Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6545A1AE0EE for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 16:09:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.398
X-Spam-Level: 
X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=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 UjKbmy2DwJE6 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 16:09:24 -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 735841A1F4C for <json@ietf.org>; Sun,  8 Dec 2013 16:09:23 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.93,853,1378821600"; d="scan'208";a="179766585"
Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 09 Dec 2013 11:09:17 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,7283"; a="180157395"
Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipccvi.tcif.telstra.com.au with ESMTP; 09 Dec 2013 11:09:17 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Mon, 9 Dec 2013 11:09:16 +1100
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Mon, 9 Dec 2013 11:09:15 +1100
Thread-Topic: [Json] Response to Statement from W3C TAG
Thread-Index: Ac70R2FwY3Gabms4QrW8nx4ihO5ibQAIfcWA
Message-ID: <255B9BB34FB7D647A506DC292726F6E115371D5C11@WSMSG3153V.srv.dir.telstra.com>
References: <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com> <CAHBU6it=NXw4EBgxmN-1xA_7hUdMMs77iYaXQs_q0SwkBv_A8Q@mail.gmail.com> <20131208004934.GB23243@mercury.ccil.org> <52A4191D.7000905@it.aoyama.ac.jp> <8B80875D-8FF5-48D9-BD8E-EE2F1363CCFE@wirfs-brock.com>
In-Reply-To: <8B80875D-8FF5-48D9-BD8E-EE2F1363CCFE@wirfs-brock.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 00:09:26 -0000

VGhhbmtzIGZvciB0aGlzIGRpc2N1c3Npb24gQWxsZW4uDQoNCj4gQW5kIGhlcmUgaXMgYW4gZXhh
bXBsZSBvZiBzdWNoIGEgSlNPTiB0ZXh0Og0KPiANCj4gLS0tLS0tLS0tLS0tc3RhcnQgSlNPTiB0
ZXh0LS0tLS0tLS0tLS0tLQ0KPiB7DQo+ICJhbGxlbndiIjogICJ0aGVyZSBpcyBhbiBvYmplY3Rp
dmVseSBvYnNlcnZhYmxlIG9yZGVyIHRvIHRoZSBtZW1iZXJzIG9mDQo+IGEgSlNPTiBvYmplY3Qi
LA0KPiAiSlNPTiBXRyBwYXJ0aWNpcGFudCAxIjogICJJdCB3b3VsZCBiZSBpbnNhbmUgdG8gZGVw
ZW5kIHVwb24gdGhhdA0KPiBvcmRlcmluZyIsDQo+ICJhbGxlbndiIjogICJub3QgaWYgdGhlcmUg
aXMgYWdyZWVtZW50IGJldHdlZW4gYSBwcm9kdWNlciBhbmQgY29uc3VtZXINCj4gb24gdGhlIG1l
YW5pbmcgb2YgdGhlIG9yZGVyaW5nIiwNCj4gIkpTT04gV0cgcGFydGljaXBhbnQgMiI6ICAiQnV0
IEpTT04ucGFyc2UgYW5kIHNpbWlsYXIgbGFuZ3VhZ2UgYmluZGluZ3MNCj4gZG9uJ3QgcHJlc2Vy
dmUgb3JkZXIiLA0KPiAiYWxsZW53YiI6ICAiQSBzdHJlYW1pbmcgSlNPTiBwYXJzZXIgd291bGQg
bmF0dXJhbGx5IHByZXNlcnZlIG1lbWJlcg0KPiBvcmRlciIsDQo+ICJKU09OIFdHIHBhcnRpY2lw
YW50IDIiOiAiSSBkaW4ndCB0aGluayB0aGVyZSBhcmUgYW55IHN1Y2ggcGFyc2VycyIsDQo+ICJh
bGxlbndiIjogIkJ1dCBzb21lb25lIG1pZ2h0IGRlY2lkZSB0byBjcmVhdGUgb25lLCBhbmQgaWYg
dGhleSBkbyBpdA0KPiB3aWxsIGV4cG9zZSBvYmplY3QgbWVtYmVycywgaW4gb3JkZXIiLA0KPiAi
YWxsZW53YiI6ICJQbHVzLCBpbiB0aGlzIHBhcnRpY3VsYXIgY2FzZSB0aGUgc2NoZW1hIGlzIHNv
IHNpbXBsZSB0aGUNCj4gYXBwbGljYXRpb24gZGV2ZWxvcGVyIG1pZ2h0IHdlbGwgZGVzaWduIHRv
IHdyaXRlIGEgY3VzdG9tLCBzY2hlbWENCj4gc3BlY2lmaWMgc3RyZWFtaW5nIHBhcnNlci4iDQo+
IH0NCj4gLS0tLS0tLS0tLS1lbmQgSlNPTiB0ZXh0LS0tLS0tLQ0KDQpUaGlzIEpTT04gdGV4dCBk
b2VzbuKAmXQgaW50ZXJvcGVyYXRlIHdpdGggRUNNQVNjcmlwdOKAmXMgSlNPTi5wYXJzZSBmdW5j
dGlvbiwgb3IgbW9zdCBKU09OIGxpYnJhcmllcywgYXMgdGhleSBzaWxlbnRseSBkcm9wIGFsbCBi
dXQgMSB2YWx1ZSBmb3IgZWFjaCBuYW1lLg0KDQpIZW5jZSBhIGRlc2lnbiBjaG9vc2luZyBtZXNz
YWdlcyBsaWtlIHRoaXMgaGFzIG1hZGUgYSBwb29yIGNob2ljZSBpZiB0aGV5IGV4cGVjdCB0byBi
ZSBhYmxlIHRvIHVzZSBKU09OIHRvb2xzLiBJIGRvbuKAmXQgd2FudCB0aGlzIGRlc2lnbiBjaG9p
Y2UgdG8gYmUgbGFiZWxsZWQgInZhbGlkIEpTT04iIGFzIGl0IGhhcm1zIEpTT07igJlzIGdyZWF0
IHJlcHV0YXRpb24gYXMgYSBzaW1wbGUsIHdpZGVseS1zdXBwb3J0ZWQsIGRhdGEgaW50ZXJjaGFu
Z2UgZm9ybWF0Lg0KDQpFQ01BLTQwNCBtYXkgaGF2ZSBkZWxpYmVyYXRlbHkgZHJvcHBlZCBhbnkg
bGFuZ3VhZ2UgYWJvdXQgb2JqZWN0IG5hbWVzIGJlaW5nIHVuaXF1ZSBhbmQgdW5vcmRlcmVkLiBI
b3dldmVyLCBFQ01BLTQwNCBzdGlsbCBleHBsaWNpdGx5IG1lbnRpb25zIDYgcHJvZ3JhbW1pbmcg
bGFuZ3VhZ2UgY29uc3RydWN0cyBjb21tb25seSB1c2VkIGZvciByZXByZXNlbnRpbmcgb2JqZWN0
czogInJlY29yZCwgc3RydWN0LCBkaWN0LCBtYXAsIGhhc2gsIG9yIG9iamVjdCIuIFRoZXNlIGNv
bnN0cnVjdHMgcHJldHR5IG11Y2ggYWx3YXlzIG9ubHkgc3VwcG9ydCAxIGVsZW1lbnQgZm9yIGFu
eSBuYW1lLiBNZXNzYWdlIGRlc2lnbmVycyBuZWVkIHRvIGtub3cgdGhpcyBzbyB0aGUgc3BlYyBz
aG91bGQgZXhwbGljaXRseSBzdGF0ZSB0aGlzIGNvbnN0cmFpbnQuDQoNCg0KQXMgZm9yIGVsZW1l
bnQgb3JkZXIgKG90aGVyIHRoYW4gZm9yIGR1cGxpY2F0ZXMpIGJlaW5nIHNpZ25pZmljYW50Li4u
DQpJIHJlYWxseSBsaWtlIHRoYXQgRUNNQVNjcmlwdCBzcGVjaWZpZXMgMSB3YXkgdG8gc2VyaWFs
aXplIGEgbnVtYmVyIGluIEpTT04uIEZvciBpbnN0YW5jZSwgSlNPTi5zdHJpbmdpZnkoMWU5KSB3
aWxsIGFsd2F5cyBwcm9kdWNlICIxMDAwMDAwMDAwIiwgbmV2ZXIgIjFlOSIgb3IgIjEwMC4wRSsw
NyIuIEhvd2V2ZXIgSlNPTi5wYXJzZSB3aWxsIGhhcHBpbHkgYWNjZXB0IHRob3NlIDMgc3RyaW5n
cyBhbmQgY3JlYXRlIGlkZW50aWNhbCB2YWx1ZXMgKGllIGNvbXBhcmluZyB0aGUgcmVzdWx0cyB3
aXRoID09PSByZXR1cm5zIHRydWUpLiBTaW1pbGFybHksIGl0IGlzIG5pY2UgdGhhdCBFQ01BU2Ny
aXB0IHNwZWNpZmllcyB0aGUgcHJlc2VydmF0aW9uIG9mIGVsZW1lbnQgb3JkZXIgaW4gc29tZSBz
aXR1YXRpb25zIC0tIGVnIGl0IG1ha2VzIGRlYnVnZ2luZywgZGlmZnMgZXRjIGVhc2llci4gSG93
ZXZlciwgSSBhc3N1bWUgOTkuOTkuLiUgb2YgRUNNQVNjcmlwdCBhcHBzIHdpbGwgaGFuZGxlIG1l
c3NhZ2VzIHRoZSBzYW1lIHdheSByZWdhcmRsZXNzIG9mIGVsZW1lbnQgb3JkZXIuIEkgZG9u4oCZ
dCB0aGluayBFQ01BU2NyaXB0IG9mZmVycyBhbiBlYXN5IHdheSB0byBzcGVjaWZ5IHRoZSBlbGVt
ZW50IG9yZGVyLiBGb3IgaW5zdGFuY2UsIGNhbiB5b3UgZWFzaWx5IGFkZCBhbiBlbGVtZW50IHRv
IGFuIGV4aXN0aW5nIG9iamVjdCBhdCBhIHNwZWNpZmljIHBsYWNlIGluIHRoZSBvcmRlcj8gQ2Fu
IHlvdSBlYXNpbHkgYXNrIGlmIGVsZW1lbnQgImEiIHdhcyBiZWZvcmUgb3IgYWZ0ZXIgZWxlbWVu
dCAiYiI/IEluIEVDTUFTY3JpcHQgQXJyYXkgaGFzIGEgc29ydCBtZXRob2QsIGJ1dCBPYmplY3Qg
ZG9lcyBub3QuDQoNCg0KLS0NCkphbWVzIE1hbmdlcg0K

From nico@cryptonector.com  Sun Dec  8 16:49:55 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B0D1AE186 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 16:49:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 g5ez-1mVIunT for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 16:49:54 -0800 (PST)
Received: from homiemail-a35.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 46BCA1AE12C for <json@ietf.org>; Sun,  8 Dec 2013 16:49:54 -0800 (PST)
Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id BF8865405B; Sun,  8 Dec 2013 16:49:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=sH3C5Aki9S/nhE 2Wl7VWgG747pE=; b=m0HHRk9AEkVA66jGm70+b0BO6WUXfQhBsJtjjNsEH29UAU TqBEJPpiTtH10V4HRD0Z0Ls5GCtvZ81eTymDKhj7wfiWAF/rm9k7l1vbzZ6jaJqP o1q172aUsw/VU+Ki7FWkNvpHNmMatrr4uWOV8I67zh5XVCqPnGHbMv8/ppuAs=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPA id 20B2654057; Sun,  8 Dec 2013 16:49:49 -0800 (PST)
Date: Sun, 8 Dec 2013 18:49:48 -0600
From: Nico Williams <nico@cryptonector.com>
To: Tim Bray <tbray@textuality.com>
Message-ID: <20131209004943.GI4067@localhost>
References: <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com> <52A41B10.4080701@it.aoyama.ac.jp> <20131208072144.GF4067@localhost> <1DEF983B-E5F1-47C1-A466-CDA0C2B179D0@wirfs-brock.com> <CAHBU6it_yF2uiOZoLpAkYBoND=zoUQuc4Jp1rz_Bz4uN0e4h7A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHBU6it_yF2uiOZoLpAkYBoND=zoUQuc4Jp1rz_Bz4uN0e4h7A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, JSON WG <json@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Martin =?iso-8859-1?Q?J=2E_D=FCrst?= <duerst@it.aoyama.ac.jp>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 00:49:55 -0000

On Sun, Dec 08, 2013 at 11:26:47AM -0800, Tim Bray wrote:
> I find it hard to disagree.  How about adding this to the end of section 4:
> 
> Some JSON parser implementations, including those which conform to
> ECMAScript specifications starting with [Allen, what goes here?], preserve
> the order of object members and make it available to application code.
>  However, implementations in many other languages do not.  Application code
> which does not rely on detecting the order of object members will be
> interoperable in the sense that its behavior will be the same when using
> either class of parser.

+1.

From nico@cryptonector.com  Sun Dec  8 16:54:56 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D451AE187 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 16:54:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 yqY72n4HXXgl for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 16:54:55 -0800 (PST)
Received: from homiemail-a55.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2425A1AE12C for <json@ietf.org>; Sun,  8 Dec 2013 16:54:55 -0800 (PST)
Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 6F6CA1601; Sun,  8 Dec 2013 16:54:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=0nn1t8ono6j3WO VpVMtQZOqICXc=; b=tg4T+muA5e3NAp+hEvcwf7pCag76ffdDvtG+uF6lGOybh0 VqsFtednJHhvGl+CpAj9c3Ox3cQ6PYrHCUEdcg6uNtY7mHwa2RoE9ySe6hqsqUr/ hJUFZsUzz1wA9InHEkcTLay22oErrhcpfgJtfoEoGIs6G6oeGccPOEjTJfqaI=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id BB7C41600; Sun,  8 Dec 2013 16:54:49 -0800 (PST)
Date: Sun, 8 Dec 2013 18:54:49 -0600
From: Nico Williams <nico@cryptonector.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Message-ID: <20131209005444.GJ4067@localhost>
References: <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com> <0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org> <B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com> <52A41B10.4080701@it.aoyama.ac.jp> <20131208072144.GF4067@localhost> <1DEF983B-E5F1-47C1-A466-CDA0C2B179D0@wirfs-brock.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1DEF983B-E5F1-47C1-A466-CDA0C2B179D0@wirfs-brock.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, =?iso-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= <duerst@it.aoyama.ac.jp>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 00:54:56 -0000

On Sun, Dec 08, 2013 at 11:13:12AM -0800, Allen Wirfs-Brock wrote:
> I agree.  Fundamentally I have been asking what is the technical
> meaning of the statement "an object is an unordered collection" that
> occurs in section 1 (Introduction) of the current draft for 4627bis.
> No one has yet responded to my question regarding whether or not
> statements in the Introduction are considered normative.  

Tim's proposed addition to section 4 should address this.

Specifically, "unordered" means that interoperable implementations can't
rely on object name ordering (nor duplicate handing, for that matter).
Note that there's no SHOULD or MUST as to this.  We had long, long
discussions over this where some insisted on stronger language
forbidding duplicates, and we settled for this description instead.

> Section 4 which presumably is supplying the normative specification of
> a JSON object currently says nothing about member ordering.  

Tim's proposed addition to section 4 should address this.  I support it.

> If the intent is for the statement in the introduction to have some
> normative mean, then please make that meaning technically clear in
> section 4. 

It's not intended to have normative meaning in the sense of an RFC2119
MUST.  See those long, long discussions in the archives.

Nico
-- 

From mnot@mnot.net  Sun Dec  8 18:54:42 2013
Return-Path: <mnot@mnot.net>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734CD1AE151 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 18:54:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 uUxHqQyQqB_3 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 18:54:40 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id B67621AE06A for <json@ietf.org>; Sun,  8 Dec 2013 18:54:40 -0800 (PST)
Received: from [192.168.1.57] (unknown [118.209.134.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2BC0750A84; Sun,  8 Dec 2013 21:54:33 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <E456E2BC-477A-4306-B676-8BDD52637CFB@vpnc.org>
Date: Mon, 9 Dec 2013 13:54:29 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F87F544A-DD2E-46A4-B682-E84E86ADB74B@mnot.net>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <CAHBU6iva2H-ovjmfA7=7j2KxUuXAMjhCb8fcMgKxq6hk+A9BtQ@mail.gmail.com> <5D573C1A-BC67-4E00-9EFC-B57172CB0478@mnot.net> <E456E2BC-477A-4306-B676-8BDD52637CFB@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 02:54:42 -0000

On 8 Dec 2013, at 3:10 am, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

>> Why don=92t we ask what their intent is for the future of 404, rather =
than tell them what we deem it might be?
>=20
> Because their intent might change over time, just as anyone's might. =
Intention are not promises, nor should they be. If Ecma had looked at =
our intent for rfc4627bis nine months ago and thought they were =
promises, they would be really pissed at us. SDOs doing technical work =
are often surprised by what they find when a lot of different eyes focus =
on the topic, as you are well aware from your current experience in =
httpbis.=20

I don=92t disagree with your logic, but fully applied, we couldn=92t =
reference our own publications, much less external ones.

Cheers,


--
Mark Nottingham   http://www.mnot.net/




From sayrer@gmail.com  Sun Dec  8 18:58:27 2013
Return-Path: <sayrer@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0153F1AE072 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 18:58:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
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 U1SDebzNQxmP for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 18:58:25 -0800 (PST)
Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id EEEF41A1DFA for <json@ietf.org>; Sun,  8 Dec 2013 18:58:24 -0800 (PST)
Received: by mail-qe0-f42.google.com with SMTP id b4so2435248qen.1 for <json@ietf.org>; Sun, 08 Dec 2013 18:58:20 -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:content-type; bh=Lq9TnYW0OKZruJUV/wcMagZri/IETZroTeKeP4zvgGo=; b=Wz3LkWCqwKmXfmCOU4WYv5kv++g/FiPXuBfcLdhyP33NwurK2ae0wi8T1UIDJ4W/c0 //SRi9xuUoPbtn+AlBVIWtBfD7VWdhGsWg8/5XVnUzRtmJIGn/z8J+kSnjLz2jHdy2Ai cesruwNvpi2hWx7YgC7JLZk5AzOkpSWyWLvxGADRoLni18wVorCgXTEa3S6Ahr+LB/gb puEmsmmCNVjM1qq2d9cadoRK+7vYJ3tor+KSKb4uwIQ+vlkYeYsopNfGcvxqcT1/C7r+ vvoadQg1KWBnbe5yP3DCisuco/EC6nhduAYRgSqBbQx1fIaI2SQmDXedaCeXX9DuR/EQ 41eA==
MIME-Version: 1.0
X-Received: by 10.224.7.10 with SMTP id b10mr30796677qab.12.1386557900135; Sun, 08 Dec 2013 18:58:20 -0800 (PST)
Received: by 10.140.101.40 with HTTP; Sun, 8 Dec 2013 18:58:20 -0800 (PST)
In-Reply-To: <F87F544A-DD2E-46A4-B682-E84E86ADB74B@mnot.net>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <CAHBU6iva2H-ovjmfA7=7j2KxUuXAMjhCb8fcMgKxq6hk+A9BtQ@mail.gmail.com> <5D573C1A-BC67-4E00-9EFC-B57172CB0478@mnot.net> <E456E2BC-477A-4306-B676-8BDD52637CFB@vpnc.org> <F87F544A-DD2E-46A4-B682-E84E86ADB74B@mnot.net>
Date: Sun, 8 Dec 2013 18:58:20 -0800
Message-ID: <CAChr6Szz-N3KBWo6xTg21gcAH2TV9VM1rDex0OXWPTaOnMY59g@mail.gmail.com>
From: R S <sayrer@gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Content-Type: multipart/alternative; boundary=001a11c24d761922da04ed112bb0
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 02:58:27 -0000

--001a11c24d761922da04ed112bb0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Has the WG debated a normative reference to ECMA-404?

It is worth considering.

- Rob


On Sun, Dec 8, 2013 at 6:54 PM, Mark Nottingham <mnot@mnot.net> wrote:

>
> On 8 Dec 2013, at 3:10 am, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>
> >> Why don=92t we ask what their intent is for the future of 404, rather
> than tell them what we deem it might be?
> >
> > Because their intent might change over time, just as anyone's might.
> Intention are not promises, nor should they be. If Ecma had looked at our
> intent for rfc4627bis nine months ago and thought they were promises, the=
y
> would be really pissed at us. SDOs doing technical work are often surpris=
ed
> by what they find when a lot of different eyes focus on the topic, as you
> are well aware from your current experience in httpbis.
>
> I don=92t disagree with your logic, but fully applied, we couldn=92t refe=
rence
> our own publications, much less external ones.
>
> Cheers,
>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>

--001a11c24d761922da04ed112bb0
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Has the WG debated a normative reference to ECMA-404?<div>=
<br></div><div>It is worth considering.</div><div><br></div><div>- Rob</div=
></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun=
, Dec 8, 2013 at 6:54 PM, Mark Nottingham <span dir=3D"ltr">&lt;<a href=3D"=
mailto:mnot@mnot.net" target=3D"_blank">mnot@mnot.net</a>&gt;</span> wrote:=
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><br>
On 8 Dec 2013, at 3:10 am, Paul Hoffman &lt;<a href=3D"mailto:paul.hoffman@=
vpnc.org">paul.hoffman@vpnc.org</a>&gt; wrote:<br>
<br>
&gt;&gt; Why don=92t we ask what their intent is for the future of 404, rat=
her than tell them what we deem it might be?<br>
&gt;<br>
&gt; Because their intent might change over time, just as anyone&#39;s migh=
t. Intention are not promises, nor should they be. If Ecma had looked at ou=
r intent for rfc4627bis nine months ago and thought they were promises, the=
y would be really pissed at us. SDOs doing technical work are often surpris=
ed by what they find when a lot of different eyes focus on the topic, as yo=
u are well aware from your current experience in httpbis.<br>

<br>
</div>I don=92t disagree with your logic, but fully applied, we couldn=92t =
reference our own publications, much less external ones.<br>
<br>
Cheers,<br>
<div class=3D"im HOEnZb"><br>
<br>
--<br>
Mark Nottingham =A0 <a href=3D"http://www.mnot.net/" target=3D"_blank">http=
://www.mnot.net/</a><br>
<br>
<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">_____________________________=
__________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
</div></div></blockquote></div><br></div>

--001a11c24d761922da04ed112bb0--

From tbray@textuality.com  Sun Dec  8 19:04:36 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB33F1AE17D for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 19:04:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 chF3_eG1u8iO for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 19:04:34 -0800 (PST)
Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id A03CE1AE072 for <json@ietf.org>; Sun,  8 Dec 2013 19:04:34 -0800 (PST)
Received: by mail-vc0-f179.google.com with SMTP id ie18so2897947vcb.24 for <json@ietf.org>; Sun, 08 Dec 2013 19:04:29 -0800 (PST)
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:content-type; bh=dmddDe1hLdgWMHPw/YyEQRoX1z5WiShcdK7eR+RTTlA=; b=Hqma2XnjWEq5kI/xSEkZnxltuZhVXkQ/acSveWGKezKT1QodhdGaObGegqyFc4tPgO wDzzzEVYOPLhGJx4Ishjml1nVX3Twqek91JFt1mhi7cVCkRFAjvWweNCI/LAMM85yJID VGh6H7iEtUkJ9Uhby38lrHR7En+T5swAUSvwezv/aUhiemfSuNsyiTBSs/RQl1ZaL/Xg 3FIgwC1Rqm1WWhc4TnzrV5nz6daTb1GpwKTcI7uEeFqtc2FiI9kMflDxXIOOn6dq4iiM WXAXmplAce/n2F/L9hQFqRMWoOeA1Yr/6QetnCddDE8m2CvsaM9xrg6B9sTMpsGHWmBH lwEg==
X-Gm-Message-State: ALoCoQlmta2HaZvDqIDYh/aZwxuHE5dc6/MbTdPbfHigbmeSNH4dDTVk3uTcpZm9sxeXCzwh13yK
MIME-Version: 1.0
X-Received: by 10.220.74.69 with SMTP id t5mr749658vcj.18.1386558269826; Sun, 08 Dec 2013 19:04:29 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Sun, 8 Dec 2013 19:04:29 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <CAChr6Szz-N3KBWo6xTg21gcAH2TV9VM1rDex0OXWPTaOnMY59g@mail.gmail.com>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <CAHBU6iva2H-ovjmfA7=7j2KxUuXAMjhCb8fcMgKxq6hk+A9BtQ@mail.gmail.com> <5D573C1A-BC67-4E00-9EFC-B57172CB0478@mnot.net> <E456E2BC-477A-4306-B676-8BDD52637CFB@vpnc.org> <F87F544A-DD2E-46A4-B682-E84E86ADB74B@mnot.net> <CAChr6Szz-N3KBWo6xTg21gcAH2TV9VM1rDex0OXWPTaOnMY59g@mail.gmail.com>
Date: Sun, 8 Dec 2013 19:04:29 -0800
Message-ID: <CAHBU6it_Yek95Jr+w86LDNQTZsdAaYanduKgPqMZx-vjnF8=wQ@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: R S <sayrer@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b624cbe226eef04ed1141aa
Cc: Mark Nottingham <mnot@mnot.net>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 03:04:37 -0000

--047d7b624cbe226eef04ed1141aa
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Um, yes. Repeatedly.  Current hot thread is the one with =E2=80=9CW3C TAG=
=E2=80=9D in the
title.


On Sun, Dec 8, 2013 at 6:58 PM, R S <sayrer@gmail.com> wrote:

> Has the WG debated a normative reference to ECMA-404?
>
> It is worth considering.
>
> - Rob
>
>
> On Sun, Dec 8, 2013 at 6:54 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
>>
>> On 8 Dec 2013, at 3:10 am, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>>
>> >> Why don=E2=80=99t we ask what their intent is for the future of 404, =
rather
>> than tell them what we deem it might be?
>> >
>> > Because their intent might change over time, just as anyone's might.
>> Intention are not promises, nor should they be. If Ecma had looked at ou=
r
>> intent for rfc4627bis nine months ago and thought they were promises, th=
ey
>> would be really pissed at us. SDOs doing technical work are often surpri=
sed
>> by what they find when a lot of different eyes focus on the topic, as yo=
u
>> are well aware from your current experience in httpbis.
>>
>> I don=E2=80=99t disagree with your logic, but fully applied, we couldn=
=E2=80=99t
>> reference our own publications, much less external ones.
>>
>> Cheers,
>>
>>
>> --
>> Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>> _______________________________________________
>> json mailing list
>> json@ietf.org
>> https://www.ietf.org/mailman/listinfo/json
>>
>
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>
>

--047d7b624cbe226eef04ed1141aa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Um, yes. Repeatedly. =C2=A0Current hot thread is the one w=
ith =E2=80=9CW3C TAG=E2=80=9D in the title. =C2=A0</div><div class=3D"gmail=
_extra"><br><br><div class=3D"gmail_quote">On Sun, Dec 8, 2013 at 6:58 PM, =
R S <span dir=3D"ltr">&lt;<a href=3D"mailto:sayrer@gmail.com" target=3D"_bl=
ank">sayrer@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Has the WG debated a normat=
ive reference to ECMA-404?<div><br></div><div>It is worth considering.</div=
><div>
<br></div><div>- Rob</div></div><div class=3D"HOEnZb"><div class=3D"h5"><di=
v class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, Dec 8, 2=
013 at 6:54 PM, Mark Nottingham <span dir=3D"ltr">&lt;<a href=3D"mailto:mno=
t@mnot.net" target=3D"_blank">mnot@mnot.net</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><br>
On 8 Dec 2013, at 3:10 am, Paul Hoffman &lt;<a href=3D"mailto:paul.hoffman@=
vpnc.org" target=3D"_blank">paul.hoffman@vpnc.org</a>&gt; wrote:<br>
<br>
&gt;&gt; Why don=E2=80=99t we ask what their intent is for the future of 40=
4, rather than tell them what we deem it might be?<br>
&gt;<br>
&gt; Because their intent might change over time, just as anyone&#39;s migh=
t. Intention are not promises, nor should they be. If Ecma had looked at ou=
r intent for rfc4627bis nine months ago and thought they were promises, the=
y would be really pissed at us. SDOs doing technical work are often surpris=
ed by what they find when a lot of different eyes focus on the topic, as yo=
u are well aware from your current experience in httpbis.<br>


<br>
</div>I don=E2=80=99t disagree with your logic, but fully applied, we could=
n=E2=80=99t reference our own publications, much less external ones.<br>
<br>
Cheers,<br>
<div><br>
<br>
--<br>
Mark Nottingham =C2=A0 <a href=3D"http://www.mnot.net/" target=3D"_blank">h=
ttp://www.mnot.net/</a><br>
<br>
<br>
<br>
</div><div><div>_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org" target=3D"_blank">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
<br></blockquote></div><br></div>

--047d7b624cbe226eef04ed1141aa--

From sayrer@gmail.com  Sun Dec  8 19:26:44 2013
Return-Path: <sayrer@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3971AE1B3 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 19:26:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
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 pa688pnjsCrD for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 19:26:41 -0800 (PST)
Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id A72901A1EF9 for <json@ietf.org>; Sun,  8 Dec 2013 19:26:41 -0800 (PST)
Received: by mail-qe0-f54.google.com with SMTP id cy11so2357575qeb.13 for <json@ietf.org>; Sun, 08 Dec 2013 19:26:36 -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:content-type; bh=k8sTJM1UCyVqHJHOG9jCQN9151I4affCqiXkomKMesw=; b=oYsOe5r8oB6dDY2zWTsdxIbSgB19XwkKZM4vNlwt7MjNKDXoJQrjsi9P/43MOkHvpw guMoTrJpEXrKVad6RZbEW8jnj7BWZmvGX6TH896uwaTXUdNtgi/rMKAADywPxZHDO58E C7DXuXlxVUaI5jNl1twRtmL9Kwzya/zdgwuMUM24WwL21/pBcfDLY7xVI85L38FMJYh9 BrfsSDRIVjdMrEzQxjks9TuxBrE7hRyNh+KXeMm+LnM5N+qG3ySRd3WAR+lYreok0qth VZ0asyX6SQLZzH/tWo92izszcLXlR5J1l+ZjA3ca0iFBrC55TqoKF1Pk+laTud2L7+gU 7G5w==
MIME-Version: 1.0
X-Received: by 10.224.51.196 with SMTP id e4mr29983104qag.16.1386559596888; Sun, 08 Dec 2013 19:26:36 -0800 (PST)
Received: by 10.140.101.40 with HTTP; Sun, 8 Dec 2013 19:26:36 -0800 (PST)
In-Reply-To: <CAHBU6it_Yek95Jr+w86LDNQTZsdAaYanduKgPqMZx-vjnF8=wQ@mail.gmail.com>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <CAHBU6iva2H-ovjmfA7=7j2KxUuXAMjhCb8fcMgKxq6hk+A9BtQ@mail.gmail.com> <5D573C1A-BC67-4E00-9EFC-B57172CB0478@mnot.net> <E456E2BC-477A-4306-B676-8BDD52637CFB@vpnc.org> <F87F544A-DD2E-46A4-B682-E84E86ADB74B@mnot.net> <CAChr6Szz-N3KBWo6xTg21gcAH2TV9VM1rDex0OXWPTaOnMY59g@mail.gmail.com> <CAHBU6it_Yek95Jr+w86LDNQTZsdAaYanduKgPqMZx-vjnF8=wQ@mail.gmail.com>
Date: Sun, 8 Dec 2013 19:26:36 -0800
Message-ID: <CAChr6SxC_DH8tSXk9wy2R=PmnMeoax-DwegMc+_8dyJcWrMEpQ@mail.gmail.com>
From: R S <sayrer@gmail.com>
To: Tim Bray <tbray@textuality.com>
Content-Type: multipart/alternative; boundary=001a11c29e503b884a04ed11905c
Cc: Mark Nottingham <mnot@mnot.net>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 03:26:44 -0000

--001a11c29e503b884a04ed11905c
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I see a few of the more vocal members of this WG emailing with TC39 there.
The fact of the matter is that you'll need to use the equivalent of a
LinkedHashMap (Java/Dart) to get good interoperability with JSON texts that
include duplicate names (JavaScript object implmentations are largely
compatible with this--I think V8 behaves differently with keys that could
pass as array indices). I happen to agree with Crockford[0] that this was a
mistake, but we're left with it.

In this thread, one of the chairs said "The topic of 'should we just refer
to Ecma' came up multiple times before Ecma produced ECMA-404, and each
time the consensus was to keep our definition." That is an unsatisfactory
answer, because ECMA-404 is a materially different specification than
ECMA-262, edition 5.1.

- Rob

[0] http://www.ietf.org/mail-archive/web/json/current/msg00351.html




On Sun, Dec 8, 2013 at 7:04 PM, Tim Bray <tbray@textuality.com> wrote:

> Um, yes. Repeatedly.  Current hot thread is the one with =93W3C TAG=94 in=
 the
> title.
>
>
> On Sun, Dec 8, 2013 at 6:58 PM, R S <sayrer@gmail.com> wrote:
>
>> Has the WG debated a normative reference to ECMA-404?
>>
>> It is worth considering.
>>
>> - Rob
>>
>>
>> On Sun, Dec 8, 2013 at 6:54 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>
>>>
>>> On 8 Dec 2013, at 3:10 am, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>>>
>>> >> Why don=92t we ask what their intent is for the future of 404, rathe=
r
>>> than tell them what we deem it might be?
>>> >
>>> > Because their intent might change over time, just as anyone's might.
>>> Intention are not promises, nor should they be. If Ecma had looked at o=
ur
>>> intent for rfc4627bis nine months ago and thought they were promises, t=
hey
>>> would be really pissed at us. SDOs doing technical work are often surpr=
ised
>>> by what they find when a lot of different eyes focus on the topic, as y=
ou
>>> are well aware from your current experience in httpbis.
>>>
>>> I don=92t disagree with your logic, but fully applied, we couldn=92t
>>> reference our own publications, much less external ones.
>>>
>>> Cheers,
>>>
>>>
>>> --
>>> Mark Nottingham   http://www.mnot.net/
>>>
>>>
>>>
>>> _______________________________________________
>>> json mailing list
>>> json@ietf.org
>>> https://www.ietf.org/mailman/listinfo/json
>>>
>>
>>
>> _______________________________________________
>> json mailing list
>> json@ietf.org
>> https://www.ietf.org/mailman/listinfo/json
>>
>>
>

--001a11c29e503b884a04ed11905c
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I see a few of the more vocal members of this WG emailing =
with TC39 there. The fact of the matter is that you&#39;ll need to use the =
equivalent of a LinkedHashMap (Java/Dart) to get good interoperability with=
 JSON texts that include duplicate names (JavaScript object implmentations =
are largely compatible with this--I think V8 behaves differently with keys =
that could pass as array indices). I happen to agree with Crockford[0] that=
 this was a mistake, but we&#39;re left with it.<div>
<br></div><div>In this thread, one of the chairs said &quot;<span style=3D"=
font-family:arial,sans-serif;font-size:13px">The topic of &#39;should we ju=
st refer to Ecma&#39; came up multiple times before Ecma produced ECMA-404,=
 and each time the consensus was to keep our definition.&quot; That is an u=
nsatisfactory answer, because ECMA-404 is a materially different specificat=
ion than ECMA-262, edition 5.1.</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">- R=
ob</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:1=
3px"><br>
</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p=
x">[0]=A0</span><a href=3D"http://www.ietf.org/mail-archive/web/json/curren=
t/msg00351.html">http://www.ietf.org/mail-archive/web/json/current/msg00351=
.html</a></div>
<div><font face=3D"arial, sans-serif">=A0</font></div><div><span style=3D"f=
ont-family:arial,sans-serif;font-size:13px"><br></span></div></div><div cla=
ss=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, Dec 8, 2013 a=
t 7:04 PM, Tim Bray <span dir=3D"ltr">&lt;<a href=3D"mailto:tbray@textualit=
y.com" target=3D"_blank">tbray@textuality.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Um, yes. Repeatedly. =A0Cur=
rent hot thread is the one with =93W3C TAG=94 in the title. =A0</div><div c=
lass=3D"HOEnZb">
<div class=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_qu=
ote">On Sun, Dec 8, 2013 at 6:58 PM, R S <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:sayrer@gmail.com" target=3D"_blank">sayrer@gmail.com</a>&gt;</span> w=
rote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Has the WG debated a normat=
ive reference to ECMA-404?<div><br></div><div>It is worth considering.</div=
>
<div>
<br></div><div>- Rob</div></div><div><div><div class=3D"gmail_extra"><br><b=
r><div class=3D"gmail_quote">On Sun, Dec 8, 2013 at 6:54 PM, Mark Nottingha=
m <span dir=3D"ltr">&lt;<a href=3D"mailto:mnot@mnot.net" target=3D"_blank">=
mnot@mnot.net</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><br>
On 8 Dec 2013, at 3:10 am, Paul Hoffman &lt;<a href=3D"mailto:paul.hoffman@=
vpnc.org" target=3D"_blank">paul.hoffman@vpnc.org</a>&gt; wrote:<br>
<br>
&gt;&gt; Why don=92t we ask what their intent is for the future of 404, rat=
her than tell them what we deem it might be?<br>
&gt;<br>
&gt; Because their intent might change over time, just as anyone&#39;s migh=
t. Intention are not promises, nor should they be. If Ecma had looked at ou=
r intent for rfc4627bis nine months ago and thought they were promises, the=
y would be really pissed at us. SDOs doing technical work are often surpris=
ed by what they find when a lot of different eyes focus on the topic, as yo=
u are well aware from your current experience in httpbis.<br>



<br>
</div>I don=92t disagree with your logic, but fully applied, we couldn=92t =
reference our own publications, much less external ones.<br>
<br>
Cheers,<br>
<div><br>
<br>
--<br>
Mark Nottingham =A0 <a href=3D"http://www.mnot.net/" target=3D"_blank">http=
://www.mnot.net/</a><br>
<br>
<br>
<br>
</div><div><div>_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org" target=3D"_blank">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org" target=3D"_blank">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--001a11c29e503b884a04ed11905c--

From sayrer@gmail.com  Sun Dec  8 19:39:09 2013
Return-Path: <sayrer@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653EF1A1F3E for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 19:39:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
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 wZHlpfGE2aT1 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 19:39:07 -0800 (PST)
Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id C62CE1AE1D3 for <json@ietf.org>; Sun,  8 Dec 2013 19:39:06 -0800 (PST)
Received: by mail-qa0-f48.google.com with SMTP id w5so2271184qac.0 for <json@ietf.org>; Sun, 08 Dec 2013 19:39: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:content-type; bh=4QGV5UAAxghUODeotE7KMKbfobSau4Arf2s98SAjwnc=; b=xSJQ/7SK5zV2Gj5CE5HAeZlVhgUvb9dr0Gv4haDgELvVrorkoQit+LmQIDVOLFIki/ uZJ/NoLvJeQX2DFrk26oUZYwPKKegK+3AktRAj9LN+XkMiCYwx/mPLP/Avqcmay6UP6T ZkVYaFVz8KRku0QAh9B2Uar+Igjs1Ge7Dpx/sLAvfh1S6M20XHFuK63llhSOiZUfbAZ0 b7/m1QzljkxBFPWTphfBD2GAfY0aTux32HYAzt4Bc7sbhERPmORy4gU4uVo7ye5VBIKz uDc1byHMF07mxacrDlzdNn/wNQpJj0lZ4Dzpqlt8OKPkVB9SDsSUC1FYkavhz5gklzfv SqXg==
MIME-Version: 1.0
X-Received: by 10.224.65.130 with SMTP id j2mr30090037qai.4.1386560341979; Sun, 08 Dec 2013 19:39:01 -0800 (PST)
Received: by 10.140.101.40 with HTTP; Sun, 8 Dec 2013 19:39:01 -0800 (PST)
In-Reply-To: <CAChr6SxC_DH8tSXk9wy2R=PmnMeoax-DwegMc+_8dyJcWrMEpQ@mail.gmail.com>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <CAHBU6iva2H-ovjmfA7=7j2KxUuXAMjhCb8fcMgKxq6hk+A9BtQ@mail.gmail.com> <5D573C1A-BC67-4E00-9EFC-B57172CB0478@mnot.net> <E456E2BC-477A-4306-B676-8BDD52637CFB@vpnc.org> <F87F544A-DD2E-46A4-B682-E84E86ADB74B@mnot.net> <CAChr6Szz-N3KBWo6xTg21gcAH2TV9VM1rDex0OXWPTaOnMY59g@mail.gmail.com> <CAHBU6it_Yek95Jr+w86LDNQTZsdAaYanduKgPqMZx-vjnF8=wQ@mail.gmail.com> <CAChr6SxC_DH8tSXk9wy2R=PmnMeoax-DwegMc+_8dyJcWrMEpQ@mail.gmail.com>
Date: Sun, 8 Dec 2013 19:39:01 -0800
Message-ID: <CAChr6SwnU4U_pv9pM-DEr9=7NHcBVOfbowYbBsN7GkfPnkEQfA@mail.gmail.com>
From: R S <sayrer@gmail.com>
To: Tim Bray <tbray@textuality.com>
Content-Type: multipart/alternative; boundary=001a11c2c08ca4b72a04ed11bcc1
Cc: Mark Nottingham <mnot@mnot.net>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 03:39:09 -0000

--001a11c2c08ca4b72a04ed11bcc1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Sun, Dec 8, 2013 at 7:26 PM, R S <sayrer@gmail.com> wrote:

> I see a few of the more vocal members of this WG emailing with TC39 there=
.
> The fact of the matter is that you'll need to use the equivalent of a
> LinkedHashMap (Java/Dart) to get good interoperability with JSON texts th=
at
> include duplicate names
>

This is wrong: key order often matters, but I should have written that
overwriting duplicates in key order is what matters for parsers in this
case.

- Rob



> (JavaScript object implmentations are largely compatible with this--I
> think V8 behaves differently with keys that could pass as array indices).=
 I
> happen to agree with Crockford[0] that this was a mistake, but we're left
> with it.
>
> In this thread, one of the chairs said "The topic of 'should we just
> refer to Ecma' came up multiple times before Ecma produced ECMA-404, and
> each time the consensus was to keep our definition." That is an
> unsatisfactory answer, because ECMA-404 is a materially different
> specification than ECMA-262, edition 5.1.
>
> - Rob
>
> [0] http://www.ietf.org/mail-archive/web/json/current/msg00351.html
>
>
>
>
> On Sun, Dec 8, 2013 at 7:04 PM, Tim Bray <tbray@textuality.com> wrote:
>
>> Um, yes. Repeatedly.  Current hot thread is the one with =93W3C TAG=94 i=
n the
>> title.
>>
>>
>> On Sun, Dec 8, 2013 at 6:58 PM, R S <sayrer@gmail.com> wrote:
>>
>>> Has the WG debated a normative reference to ECMA-404?
>>>
>>> It is worth considering.
>>>
>>> - Rob
>>>
>>>
>>> On Sun, Dec 8, 2013 at 6:54 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>>
>>>>
>>>> On 8 Dec 2013, at 3:10 am, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>>>>
>>>> >> Why don=92t we ask what their intent is for the future of 404, rath=
er
>>>> than tell them what we deem it might be?
>>>> >
>>>> > Because their intent might change over time, just as anyone's might.
>>>> Intention are not promises, nor should they be. If Ecma had looked at =
our
>>>> intent for rfc4627bis nine months ago and thought they were promises, =
they
>>>> would be really pissed at us. SDOs doing technical work are often surp=
rised
>>>> by what they find when a lot of different eyes focus on the topic, as =
you
>>>> are well aware from your current experience in httpbis.
>>>>
>>>> I don=92t disagree with your logic, but fully applied, we couldn=92t
>>>> reference our own publications, much less external ones.
>>>>
>>>> Cheers,
>>>>
>>>>
>>>> --
>>>> Mark Nottingham   http://www.mnot.net/
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> json mailing list
>>>> json@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/json
>>>>
>>>
>>>
>>> _______________________________________________
>>> json mailing list
>>> json@ietf.org
>>> https://www.ietf.org/mailman/listinfo/json
>>>
>>>
>>
>

--001a11c2c08ca4b72a04ed11bcc1
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Dec 8, 2013 at 7:26 PM, R S <span dir=3D"ltr">&lt;<a href=3D"mailto:say=
rer@gmail.com" target=3D"_blank">sayrer@gmail.com</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr">I see a few of the more vocal members of this WG emailing =
with TC39 there. The fact of the matter is that you&#39;ll need to use the =
equivalent of a LinkedHashMap (Java/Dart) to get good interoperability with=
 JSON texts that include duplicate names</div>
</blockquote><div><br></div><div>This is wrong: key order often matters, bu=
t I should have written that overwriting duplicates in key order is what ma=
tters for parsers in this case.</div><div><br></div><div>- Rob</div><div>
<br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"> (J=
avaScript object implmentations are largely compatible with this--I think V=
8 behaves differently with keys that could pass as array indices). I happen=
 to agree with Crockford[0] that this was a mistake, but we&#39;re left wit=
h it.<div>

<br></div><div>In this thread, one of the chairs said &quot;<span style=3D"=
font-family:arial,sans-serif;font-size:13px">The topic of &#39;should we ju=
st refer to Ecma&#39; came up multiple times before Ecma produced ECMA-404,=
 and each time the consensus was to keep our definition.&quot; That is an u=
nsatisfactory answer, because ECMA-404 is a materially different specificat=
ion than ECMA-262, edition 5.1.</span></div>

<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">- R=
ob</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:1=
3px"><br>

</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p=
x">[0]=A0</span><a href=3D"http://www.ietf.org/mail-archive/web/json/curren=
t/msg00351.html" target=3D"_blank">http://www.ietf.org/mail-archive/web/jso=
n/current/msg00351.html</a></div>

<div><font face=3D"arial, sans-serif">=A0</font></div><div><span style=3D"f=
ont-family:arial,sans-serif;font-size:13px"><br></span></div></div><div cla=
ss=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><br><div cla=
ss=3D"gmail_quote">
On Sun, Dec 8, 2013 at 7:04 PM, Tim Bray <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:tbray@textuality.com" target=3D"_blank">tbray@textuality.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Um, yes. Repeatedly. =A0Cur=
rent hot thread is the one with =93W3C TAG=94 in the title. =A0</div><div>
<div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, =
Dec 8, 2013 at 6:58 PM, R S <span dir=3D"ltr">&lt;<a href=3D"mailto:sayrer@=
gmail.com" target=3D"_blank">sayrer@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Has the WG debated a normat=
ive reference to ECMA-404?<div><br></div><div>It is worth considering.</div=
>

<div>
<br></div><div>- Rob</div></div><div><div><div class=3D"gmail_extra"><br><b=
r><div class=3D"gmail_quote">On Sun, Dec 8, 2013 at 6:54 PM, Mark Nottingha=
m <span dir=3D"ltr">&lt;<a href=3D"mailto:mnot@mnot.net" target=3D"_blank">=
mnot@mnot.net</a>&gt;</span> wrote:<br>



<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><br>
On 8 Dec 2013, at 3:10 am, Paul Hoffman &lt;<a href=3D"mailto:paul.hoffman@=
vpnc.org" target=3D"_blank">paul.hoffman@vpnc.org</a>&gt; wrote:<br>
<br>
&gt;&gt; Why don=92t we ask what their intent is for the future of 404, rat=
her than tell them what we deem it might be?<br>
&gt;<br>
&gt; Because their intent might change over time, just as anyone&#39;s migh=
t. Intention are not promises, nor should they be. If Ecma had looked at ou=
r intent for rfc4627bis nine months ago and thought they were promises, the=
y would be really pissed at us. SDOs doing technical work are often surpris=
ed by what they find when a lot of different eyes focus on the topic, as yo=
u are well aware from your current experience in httpbis.<br>




<br>
</div>I don=92t disagree with your logic, but fully applied, we couldn=92t =
reference our own publications, much less external ones.<br>
<br>
Cheers,<br>
<div><br>
<br>
--<br>
Mark Nottingham =A0 <a href=3D"http://www.mnot.net/" target=3D"_blank">http=
://www.mnot.net/</a><br>
<br>
<br>
<br>
</div><div><div>_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org" target=3D"_blank">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org" target=3D"_blank">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>

--001a11c2c08ca4b72a04ed11bcc1--

From duerst@it.aoyama.ac.jp  Sun Dec  8 19:56:57 2013
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729171A1F4A for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 19:56:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level: 
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=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 6sMPm55z-qBE for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 19:56:55 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5B41A1F3E for <json@ietf.org>; Sun,  8 Dec 2013 19:56:54 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rB93udOU022105; Mon, 9 Dec 2013 12:56:39 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 31e5_767c_e86a8bf6_6085_11e3_84af_001e6722eec2; Mon, 09 Dec 2013 12:56:38 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 400C2BFBBA; Mon,  9 Dec 2013 12:56:39 +0900 (JST)
Message-ID: <52A53F6D.2030101@it.aoyama.ac.jp>
Date: Mon, 09 Dec 2013 12:56:29 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Tim Bray <tbray@textuality.com>
References: <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com>	<FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org>	<0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com>	<20131206205613.GA3577@gmail.com>	<83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com>	<20131207115542.GA4067@localhost>	<5CE05DC9-8748-47F5-BFEA-674C5DF44C9D@wirfs-brock.com>	<0CB7BD9D-A5BE-460B-86FC-890EABE60536@tzi.org>	<B6131BB2-4C3F-426C-97F9-0F7B787BDAF0@wirfs-brock.com>	<52A41B10.4080701@it.aoyama.ac.jp>	<20131208072144.GF4067@localhost>	<1DEF983B-E5F1-47C1-A466-CDA0C2B179D0@wirfs-brock.com> <CAHBU6it_yF2uiOZoLpAkYBoND=zoUQuc4Jp1rz_Bz4uN0e4h7A@mail.gmail.com>
In-Reply-To: <CAHBU6it_yF2uiOZoLpAkYBoND=zoUQuc4Jp1rz_Bz4uN0e4h7A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, JSON WG <json@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 03:56:57 -0000

On 2013/12/09 4:26, Tim Bray wrote:
> On Sun, Dec 8, 2013 at 11:13 AM, Allen Wirfs-Brock<allen@wirfs-brock.com>wrote:

>> If the intent is for the statement in the introduction to have some
>> normative mean, then please make that meaning technically clear in section
>> 4.
>>
>
> I find it hard to disagree.  How about adding this to the end of section 4:
>
> Some JSON parser implementations, including those which conform to
> ECMAScript specifications starting with [Allen, what goes here?], preserve
> the order of object members and make it available to application code.
>   However, implementations in many other languages do not.  Application code
> which does not rely on detecting the order of object members will be
> interoperable in the sense that its behavior will be the same when using
> either class of parser.

Adding something like this is a good idea. Unfortunately, as far as I 
understood Allen, the citation you'd need is currently only on a 
Mozilla.org page.

Regards,   Martin.

From tbray@textuality.com  Sun Dec  8 20:05:59 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A361AE1C7 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 20:05:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 NZ0yZ8A-enRh for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 20:05:57 -0800 (PST)
Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id D3A261AC7F1 for <json@ietf.org>; Sun,  8 Dec 2013 20:05:56 -0800 (PST)
Received: by mail-vb0-f43.google.com with SMTP id p6so145821vbe.16 for <json@ietf.org>; Sun, 08 Dec 2013 20:05:52 -0800 (PST)
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:content-type; bh=+ZnuAJAKLuf1dhrlE4AkgrGqLm+V+ml8F9YtXr2dVds=; b=gdM9tY/O3HlREpsKVv4/3pODNCqWIexyOFkC2OoKuPX899sdx/+IkPllechexJGcXJ vwXJmu2pGI8R7+DwioCtkYssGUDXIOQujBxs1Vt+eJJkoeEB+uduyx75CwsmOMJ3+xJ0 vuBnIWP72ZTe894GcubHacJANrB9qsIx9ONHc9vqfwQ+DQbiPbt2DGovppsDieKmKqp0 rzvezYleDXRonADmZLOTYTuBhX3XIsFyLkAyxZrL/6MwxV7xdBZfC/H7d4eKQaG1Lx7a HWM/ijx9yAN+c0NPL1HsROWFah5TbiUmdp4Mdp8Q+2p1uLAedus55qjIfkfWIlA0eY2d fxdw==
X-Gm-Message-State: ALoCoQn8MuNGax2V+xZ+gJoruziN6BViYPChlucA4HrJBbNJ3L/JK4ZFs/m3cbAzTa7t2xSGGnwo
MIME-Version: 1.0
X-Received: by 10.220.74.69 with SMTP id t5mr833592vcj.18.1386561952026; Sun, 08 Dec 2013 20:05:52 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Sun, 8 Dec 2013 20:05:51 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <CAChr6SwnU4U_pv9pM-DEr9=7NHcBVOfbowYbBsN7GkfPnkEQfA@mail.gmail.com>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <CAHBU6iva2H-ovjmfA7=7j2KxUuXAMjhCb8fcMgKxq6hk+A9BtQ@mail.gmail.com> <5D573C1A-BC67-4E00-9EFC-B57172CB0478@mnot.net> <E456E2BC-477A-4306-B676-8BDD52637CFB@vpnc.org> <F87F544A-DD2E-46A4-B682-E84E86ADB74B@mnot.net> <CAChr6Szz-N3KBWo6xTg21gcAH2TV9VM1rDex0OXWPTaOnMY59g@mail.gmail.com> <CAHBU6it_Yek95Jr+w86LDNQTZsdAaYanduKgPqMZx-vjnF8=wQ@mail.gmail.com> <CAChr6SxC_DH8tSXk9wy2R=PmnMeoax-DwegMc+_8dyJcWrMEpQ@mail.gmail.com> <CAChr6SwnU4U_pv9pM-DEr9=7NHcBVOfbowYbBsN7GkfPnkEQfA@mail.gmail.com>
Date: Sun, 8 Dec 2013 20:05:51 -0800
Message-ID: <CAHBU6isZsvJAbpHtuv10AMsAaV6npHFB9zxrZHoHC4CU1Z+L+g@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: R S <sayrer@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b624cbe9c224604ed121c8b
Cc: Mark Nottingham <mnot@mnot.net>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 04:05:59 -0000

--047d7b624cbe9c224604ed121c8b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

My sense of the consensus is that key order matters when JSON is parsed by
JavaScript; but the vast majority of software that deals with JSON
transmitted over the wire does not make key order information available to
applications, nor does it make any guarantee of what happens in the case of
dupe keys.  Thus, that is what the -bis should say: That some software
does, some doesn=E2=80=99t, and the most interoperable thing is to not rely=
 on any
particular behavior in these cases.

Put another way, when JSON is used as a message format, objects are
serializations of hash tables, that=E2=80=99s all they are, and asking for =
anything
more than that is not interoperable.


On Sun, Dec 8, 2013 at 7:39 PM, R S <sayrer@gmail.com> wrote:

> On Sun, Dec 8, 2013 at 7:26 PM, R S <sayrer@gmail.com> wrote:
>
>> I see a few of the more vocal members of this WG emailing with TC39
>> there. The fact of the matter is that you'll need to use the equivalent =
of
>> a LinkedHashMap (Java/Dart) to get good interoperability with JSON texts
>> that include duplicate names
>>
>
> This is wrong: key order often matters, but I should have written that
> overwriting duplicates in key order is what matters for parsers in this
> case.
>
> - Rob
>
>
>
>> (JavaScript object implmentations are largely compatible with this--I
>> think V8 behaves differently with keys that could pass as array indices)=
. I
>> happen to agree with Crockford[0] that this was a mistake, but we're lef=
t
>> with it.
>>
>> In this thread, one of the chairs said "The topic of 'should we just
>> refer to Ecma' came up multiple times before Ecma produced ECMA-404, and
>> each time the consensus was to keep our definition." That is an
>> unsatisfactory answer, because ECMA-404 is a materially different
>> specification than ECMA-262, edition 5.1.
>>
>> - Rob
>>
>> [0] http://www.ietf.org/mail-archive/web/json/current/msg00351.html
>>
>>
>>
>>
>> On Sun, Dec 8, 2013 at 7:04 PM, Tim Bray <tbray@textuality.com> wrote:
>>
>>> Um, yes. Repeatedly.  Current hot thread is the one with =E2=80=9CW3C T=
AG=E2=80=9D in
>>> the title.
>>>
>>>
>>> On Sun, Dec 8, 2013 at 6:58 PM, R S <sayrer@gmail.com> wrote:
>>>
>>>> Has the WG debated a normative reference to ECMA-404?
>>>>
>>>> It is worth considering.
>>>>
>>>> - Rob
>>>>
>>>>
>>>> On Sun, Dec 8, 2013 at 6:54 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>>>
>>>>>
>>>>> On 8 Dec 2013, at 3:10 am, Paul Hoffman <paul.hoffman@vpnc.org> wrote=
:
>>>>>
>>>>> >> Why don=E2=80=99t we ask what their intent is for the future of 40=
4, rather
>>>>> than tell them what we deem it might be?
>>>>> >
>>>>> > Because their intent might change over time, just as anyone's might=
.
>>>>> Intention are not promises, nor should they be. If Ecma had looked at=
 our
>>>>> intent for rfc4627bis nine months ago and thought they were promises,=
 they
>>>>> would be really pissed at us. SDOs doing technical work are often sur=
prised
>>>>> by what they find when a lot of different eyes focus on the topic, as=
 you
>>>>> are well aware from your current experience in httpbis.
>>>>>
>>>>> I don=E2=80=99t disagree with your logic, but fully applied, we could=
n=E2=80=99t
>>>>> reference our own publications, much less external ones.
>>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>> --
>>>>> Mark Nottingham   http://www.mnot.net/
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> json mailing list
>>>>> json@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/json
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> json mailing list
>>>> json@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/json
>>>>
>>>>
>>>
>>
>

--047d7b624cbe9c224604ed121c8b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">My sense of the consensus is that key order matters when J=
SON is parsed by JavaScript; but the vast majority of software that deals w=
ith JSON transmitted over the wire does not make key order information avai=
lable to applications, nor does it make any guarantee of what happens in th=
e case of dupe keys. =C2=A0Thus, that is what the -bis should say: That som=
e software does, some doesn=E2=80=99t, and the most interoperable thing is =
to not rely on any particular behavior in these cases.<div>
<br></div><div>Put another way, when JSON is used as a message format, obje=
cts are serializations of hash tables, that=E2=80=99s all they are, and ask=
ing for anything more than that is not interoperable.</div></div><div class=
=3D"gmail_extra">
<br><br><div class=3D"gmail_quote">On Sun, Dec 8, 2013 at 7:39 PM, R S <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:sayrer@gmail.com" target=3D"_blank">say=
rer@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 class=3D"im">On Sun, Dec 8, 2013 at 7:26 PM, R S <span dir=3D"ltr">&lt;<a =
href=3D"mailto:sayrer@gmail.com" target=3D"_blank">sayrer@gmail.com</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr">I see a few of the more vocal members of this WG emailing =
with TC39 there. The fact of the matter is that you&#39;ll need to use the =
equivalent of a LinkedHashMap (Java/Dart) to get good interoperability with=
 JSON texts that include duplicate names</div>

</blockquote><div><br></div></div><div>This is wrong: key order often matte=
rs, but I should have written that overwriting duplicates in key order is w=
hat matters for parsers in this case.</div><div><br></div><div>- Rob</div>
<div><div class=3D"h5"><div>
<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
 (JavaScript object implmentations are largely compatible with this--I thin=
k V8 behaves differently with keys that could pass as array indices). I hap=
pen to agree with Crockford[0] that this was a mistake, but we&#39;re left =
with it.<div>


<br></div><div>In this thread, one of the chairs said &quot;<span style=3D"=
font-family:arial,sans-serif;font-size:13px">The topic of &#39;should we ju=
st refer to Ecma&#39; came up multiple times before Ecma produced ECMA-404,=
 and each time the consensus was to keep our definition.&quot; That is an u=
nsatisfactory answer, because ECMA-404 is a materially different specificat=
ion than ECMA-262, edition 5.1.</span></div>


<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">- R=
ob</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:1=
3px"><br>


</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p=
x">[0]=C2=A0</span><a href=3D"http://www.ietf.org/mail-archive/web/json/cur=
rent/msg00351.html" target=3D"_blank">http://www.ietf.org/mail-archive/web/=
json/current/msg00351.html</a></div>


<div><font face=3D"arial, sans-serif">=C2=A0</font></div><div><span style=
=3D"font-family:arial,sans-serif;font-size:13px"><br></span></div></div><di=
v><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">
On Sun, Dec 8, 2013 at 7:04 PM, Tim Bray <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:tbray@textuality.com" target=3D"_blank">tbray@textuality.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Um, yes. Repeatedly. =C2=A0=
Current hot thread is the one with =E2=80=9CW3C TAG=E2=80=9D in the title. =
=C2=A0</div><div>
<div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, =
Dec 8, 2013 at 6:58 PM, R S <span dir=3D"ltr">&lt;<a href=3D"mailto:sayrer@=
gmail.com" target=3D"_blank">sayrer@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Has the WG debated a normat=
ive reference to ECMA-404?<div><br></div><div>It is worth considering.</div=
>


<div>
<br></div><div>- Rob</div></div><div><div><div class=3D"gmail_extra"><br><b=
r><div class=3D"gmail_quote">On Sun, Dec 8, 2013 at 6:54 PM, Mark Nottingha=
m <span dir=3D"ltr">&lt;<a href=3D"mailto:mnot@mnot.net" target=3D"_blank">=
mnot@mnot.net</a>&gt;</span> wrote:<br>




<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><br>
On 8 Dec 2013, at 3:10 am, Paul Hoffman &lt;<a href=3D"mailto:paul.hoffman@=
vpnc.org" target=3D"_blank">paul.hoffman@vpnc.org</a>&gt; wrote:<br>
<br>
&gt;&gt; Why don=E2=80=99t we ask what their intent is for the future of 40=
4, rather than tell them what we deem it might be?<br>
&gt;<br>
&gt; Because their intent might change over time, just as anyone&#39;s migh=
t. Intention are not promises, nor should they be. If Ecma had looked at ou=
r intent for rfc4627bis nine months ago and thought they were promises, the=
y would be really pissed at us. SDOs doing technical work are often surpris=
ed by what they find when a lot of different eyes focus on the topic, as yo=
u are well aware from your current experience in httpbis.<br>





<br>
</div>I don=E2=80=99t disagree with your logic, but fully applied, we could=
n=E2=80=99t reference our own publications, much less external ones.<br>
<br>
Cheers,<br>
<div><br>
<br>
--<br>
Mark Nottingham =C2=A0 <a href=3D"http://www.mnot.net/" target=3D"_blank">h=
ttp://www.mnot.net/</a><br>
<br>
<br>
<br>
</div><div><div>_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org" target=3D"_blank">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org" target=3D"_blank">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>

--047d7b624cbe9c224604ed121c8b--

From duerst@it.aoyama.ac.jp  Sun Dec  8 20:10:26 2013
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753551AE1D6 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 20:10:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level: 
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=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 9B7ibf9JCOB8 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 20:10:25 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5819C1AE1D5 for <json@ietf.org>; Sun,  8 Dec 2013 20:10:25 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rB94ACXk000303; Mon, 9 Dec 2013 13:10:13 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 31e9_69b0_cceed8bc_6087_11e3_be53_001e6722eec2; Mon, 09 Dec 2013 13:10:11 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 0930FBFBBA; Mon,  9 Dec 2013 13:10:12 +0900 (JST)
Message-ID: <52A5429A.6010204@it.aoyama.ac.jp>
Date: Mon, 09 Dec 2013 13:10:02 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Bjoern Hoehrmann <derhoermi@gmx.net>
References: <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp> <gv09a91nc0uuvj5gdlsbcnuctuu5mq2q9d@hive.bjoern.hoehrmann.de>
In-Reply-To: <gv09a91nc0uuvj5gdlsbcnuctuu5mq2q9d@hive.bjoern.hoehrmann.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 04:10:26 -0000

On 2013/12/08 23:44, Bjoern Hoehrmann wrote:
> * Martin J. D=C3=BCrst wrote:
>> The textual descriptions are in some cases quite precise, but in some
>> other cases, leave quite a bit of ambiguity. And stuff like "It may ha=
ve
>> an exponent of ten, prefixed by e (U+0065) or E (U+0045) and optionall=
y
>> + (U+002B) or =E2=80=93 (U+002D)." (in particlar the first clause of t=
hat
>> sentence) doesn't make much sense. If e.g. 1.2 has an exponent of 10,
>> it's going to be 6.1917 or so, not at all what this notation is usuall=
y
>> used for.
>
> Apparently in `x=C2=B2` 2 is "an exponent of" x. That does not make muc=
h
> sense to me either, but it does appear to be a common english idiom.

Ah, I see. The problem is not with the idiom. In your example, it's okay=20
to say "2 is an exponent of x" (although "2 is the exponent of x" feels=20
better in some ways), as well as it's okay to say "x has an exponent of 2=
".

In the original text, neither are these two usages disambiguated, nor is=20
there any explanation about where the "10" is coming from or how it has=20
to be used.

Regards,    Martin.

From prvs=0048efaad2=johnl@iecc.com  Sun Dec  8 20:25:47 2013
Return-Path: <prvs=0048efaad2=johnl@iecc.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4529C1AE144 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 20:25:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.793
X-Spam-Level: 
X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=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 qdLwqB1BlxMV for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 20:25:45 -0800 (PST)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7F98C1AE129 for <json@ietf.org>; Sun,  8 Dec 2013 20:25:44 -0800 (PST)
Received: (qmail 35782 invoked from network); 9 Dec 2013 04:25:39 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 Dec 2013 04:25:39 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52a54643.xn--hew.k1310; i=johnl@user.iecc.com; bh=lfl9Sp6oZ+r7nRAEJXrdqQZoGokGA+pm4UwMu7ewQU4=; b=dKuBVh539iL6aU/i+GfOZ+Hvrnb2NOEKCY6wXFxDPSOROLW3hBgfgzdhJaIg/Lvj06PDANNpRToYQY1uaCJgGorNhlIKf7tkLugusOmxwtwgQ2tjOD/GTwr9ckS/R5SoQyTfYVH2wpfU4GXszeI+LZvBHhQ6jtQBXWPUBD1puXKraL6994BoMzwBwO60W/lFniEfZo+YMxC8ff9TaBzQrIjXt1UtOZAc7mS2Mo9xuWlr35ggXAldelbmFk8K1ot4
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52a54643.xn--hew.k1310; olt=johnl@user.iecc.com; bh=lfl9Sp6oZ+r7nRAEJXrdqQZoGokGA+pm4UwMu7ewQU4=; b=AgAi7qywxaeIe2yqBlZ9aVhyA9g4Ja0fxLYp5QVlhijWwjhhJrM1pTDsoY7VfCQDTiK5gLdoYw9OKnCYmgV1+navAyQAZQQ9LxogR8CUSPwCTyV1xD+ZNydmiDpfdq15rpLxbPJCvKI5J1LCt5Ku/VHeUzd6SBiZaSKmKnng/e9n5c2jg+9miBIxcZsQMGafQVKuwrAeWUp8oFa7VmWY8fTkgedXIaeA39bhxp+QM0uRC/ZMCDGyN66yZXrEFJVo
Date: 9 Dec 2013 04:25:17 -0000
Message-ID: <20131209042517.93270.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: json@ietf.org
In-Reply-To: <CAHBU6isZsvJAbpHtuv10AMsAaV6npHFB9zxrZHoHC4CU1Z+L+g@mail.gmail.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Cc: tbray@textuality.com
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 04:25:47 -0000

>Put another way, when JSON is used as a message format, objects are
>serializations of hash tables, that’s all they are, and asking for anything
>more than that is not interoperable.

Yeah.  Unless I've missed something in the past 100,000 messages (you
never know) our goal is to tell people how to write code that has the
greatest chance of interoperating with other JSON producers and
consumers, not to tell people how to be bug-compatible with specific
implementations.  Not even very popular specific implementations.

R's,
John

From sayrer@gmail.com  Sun Dec  8 22:24:34 2013
Return-Path: <sayrer@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8721AE1EE for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 22:24:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
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 TBJx7Ep5GQT4 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 22:24:32 -0800 (PST)
Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 474BE1AE0F7 for <json@ietf.org>; Sun,  8 Dec 2013 22:24:32 -0800 (PST)
Received: by mail-qe0-f45.google.com with SMTP id 6so2510927qea.32 for <json@ietf.org>; Sun, 08 Dec 2013 22:24:27 -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:content-type; bh=fA6jmNEF/MsCQa0O7hzDs1dmH/9OQGMds2d2e8jqUzs=; b=GltCiM0gqAtbSFnVEZIILwXa+dnA+qFxGSLGZgl5W5FUAaFLMBUtMCBM5MNoTZDvyi SzrC9euDAwsVtp3YSsHUciVzsj7xVC+UhlBIjS4Czcqpn4iwc3eFfqHR/9ZdVE87xyVx vfG2IJ6Eq/fBAG5BK10gKDWMJ9eMIxno0ktGitVzpE/lbRMVDLtl1i8CAzGJ6JuYVO55 Std1vKSkyhGTegdRgJIuPH/QA/5qE0lZDvyt+i2LaPeqMz7ca12vTbN+b8n8n92iDilJ 8MiPuZzOJwggkjtS4tVfs/731LkB+Noyd6FVi2Iy70W1krGcuYrAL1P+oNhmzJgsDtRo 0ydg==
MIME-Version: 1.0
X-Received: by 10.224.32.131 with SMTP id c3mr19370976qad.3.1386570267231; Sun, 08 Dec 2013 22:24:27 -0800 (PST)
Received: by 10.140.101.40 with HTTP; Sun, 8 Dec 2013 22:24:27 -0800 (PST)
In-Reply-To: <20131209042517.93270.qmail@joyce.lan>
References: <CAHBU6isZsvJAbpHtuv10AMsAaV6npHFB9zxrZHoHC4CU1Z+L+g@mail.gmail.com> <20131209042517.93270.qmail@joyce.lan>
Date: Sun, 8 Dec 2013 22:24:27 -0800
Message-ID: <CAChr6Syb9gDYt_BUFMf+g92a_xs-xBG+dd6=h5Bmdo-ibcN4LA@mail.gmail.com>
From: R S <sayrer@gmail.com>
To: John Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary=001a11c2bf383c08af04ed140c89
Cc: Tim Bray <tbray@textuality.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 06:24:35 -0000

--001a11c2bf383c08af04ed140c89
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Sun, Dec 8, 2013 at 8:25 PM, John Levine <johnl@taugh.com> wrote:

> >Put another way, when JSON is used as a message format, objects are
> >serializations of hash tables, that=92s all they are, and asking for
> anything
> >more than that is not interoperable.
>
> Yeah.  Unless I've missed something in the past 100,000 messages (you
> never know) our goal is to tell people how to write code that has the
> greatest chance of interoperating with other JSON producers and
> consumers, not to tell people how to be bug-compatible with specific
> implementations.  Not even very popular specific implementations.
>


RFC 4627 currently says: "The names within an object SHOULD be unique."

That sounds like what you two are saying. No change is needed.

ECMA-404 says:

"It is expected that other standards will refer to this one, strictly
adhering to the JSON text format, while
imposing restrictions on various encoding details. Such standards may
require specific behaviours. JSON
itself specifies no behaviour."

IETF email threads often rathole on tangential points. Sometimes, this
happens because certain participants are very focused on certain technical
issues.

It seems obvious that the main point I made was:

"The topic of 'should we just refer to Ecma' came up multiple times before
Ecma produced ECMA-404, and each time the consensus was to keep our
definition." That is an unsatisfactory answer, because ECMA-404 is a
materially different specification than ECMA-262, edition 5.1.

For example, ECMA-262 specified required handling for duplicate keys, while
ECMA-404 does not.

Are there changes other than adding ABNF that the JSON WG would like to
make?

- Rob

--001a11c2bf383c08af04ed140c89
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Dec 8, 2013 at 8:25 PM, John Levine <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:johnl@taugh.com" target=3D"_blank">johnl@taugh.com</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex">
<div class=3D"im">&gt;Put another way, when JSON is used as a message forma=
t, objects are<br>
&gt;serializations of hash tables, that=92s all they are, and asking for an=
ything<br>
&gt;more than that is not interoperable.<br>
<br>
</div>Yeah. =A0Unless I&#39;ve missed something in the past 100,000 message=
s (you<br>
never know) our goal is to tell people how to write code that has the<br>
greatest chance of interoperating with other JSON producers and<br>
consumers, not to tell people how to be bug-compatible with specific<br>
implementations. =A0Not even very popular specific implementations.<br></bl=
ockquote><div><br></div><div><br></div><div>RFC 4627 currently says: &quot;=
The names within an object SHOULD be unique.&quot;</div><div><br></div><div=
>
That sounds like what you two are saying. No change is needed.</div><div><b=
r></div><div>ECMA-404 says:</div><div><br></div><div>&quot;It is expected t=
hat other standards will refer to this one, strictly adhering to the JSON t=
ext format, while=A0</div>
<div>imposing restrictions on various encoding details. Such standards may =
require specific behaviours. JSON=A0</div><div>itself specifies no behaviou=
r.&quot;</div><div><br></div><div>IETF email threads often rathole on tange=
ntial points. Sometimes, this happens because certain participants are very=
 focused on certain technical issues.=A0</div>
<div><br></div><div>It seems obvious that the main point I made was:</div><=
div><br></div><div><span style=3D"font-family:arial,sans-serif;font-size:13=
px">&quot;</span><span style=3D"font-family:arial,sans-serif;font-size:13px=
">The topic of &#39;should we just refer to Ecma&#39; came up multiple time=
s before Ecma produced ECMA-404, and each time the consensus was to keep ou=
r definition.&quot; That is an unsatisfactory answer, because ECMA-404 is a=
 materially different specification than ECMA-262, edition 5.1.</span><br>
</div><div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br>=
</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p=
x">For example, ECMA-262 specified required handling for duplicate keys, wh=
ile ECMA-404 does not.</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">Are=
 there changes other than adding ABNF that the JSON WG would like to make?<=
/span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">- R=
ob</span></div></div></div></div>

--001a11c2bf383c08af04ed140c89--

From duerst@it.aoyama.ac.jp  Sun Dec  8 22:46:11 2013
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB9C1AE1F5 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 22:46:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level: 
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=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 nbsjWWCCAJsN for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 22:46:09 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 819351AE1C8 for <json@ietf.org>; Sun,  8 Dec 2013 22:46:08 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rB96jt2a024109; Mon, 9 Dec 2013 15:45:55 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 31e9_9a53_8de0a810_609d_11e3_be53_001e6722eec2; Mon, 09 Dec 2013 15:45:55 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 2CAC3BFBBA; Mon,  9 Dec 2013 15:45:55 +0900 (JST)
Message-ID: <52A56719.1020106@it.aoyama.ac.jp>
Date: Mon, 09 Dec 2013 15:45:45 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <20131205044253.GH21240@localhost> <51F5DED3-A3CB-4AE3-9A1C-D9E25BFD822C@vpnc.org>
In-Reply-To: <51F5DED3-A3CB-4AE3-9A1C-D9E25BFD822C@vpnc.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Nico Williams <nico@cryptonector.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 06:46:11 -0000

On 2013/12/06 0:58, Paul Hoffman wrote:
> On Dec 4, 2013, at 8:42 PM, Nico Williams<nico@cryptonector.com>  wrote:

>> Comments:
>>
>> - s/rfc4727/rfc4627/g  (the link to the attachment says 4727)
>
> That's actually not part of the response we are sending, so there is nothing we can change. Yes, the link is wrong in the Liaison tool, but we'll just have to live with that.

I'm sure somebody is in charge of that tool, and can fix this. If the 
chairs don't know how to request this, please ask your ADs.

Regards,   Martin.

From cabo@tzi.org  Sun Dec  8 22:59:35 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63761AE039 for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 22:59:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.251
X-Spam-Level: 
X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001] autolearn=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 OZgzplzTPn4S for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 22:59:33 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE691ADBCF for <json@ietf.org>; Sun,  8 Dec 2013 22:59:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB96xPu2018172; Mon, 9 Dec 2013 07:59:25 +0100 (CET)
Received: from [192.168.217.105] (p54891006.dip0.t-ipconnect.de [84.137.16.6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E9AA9888; Mon,  9 Dec 2013 07:59:24 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <52A5429A.6010204@it.aoyama.ac.jp>
Date: Mon, 9 Dec 2013 07:59:23 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B5EEAD35-A3BD-44B0-874C-1182A32402F9@tzi.org>
References: <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp> <gv09a91nc0uuvj5gdlsbcnuctuu5mq2q9d@hive.bjoern.hoehrmann.de> <52A5429A.6010204@it.aoyama.ac.jp>
To: =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 06:59:36 -0000

On 09 Dec 2013, at 05:10, Martin J. D=FCrst <duerst@it.aoyama.ac.jp> =
wrote:

> In the original text, neither are these two usages disambiguated, nor =
is there any explanation about where the "10" is coming from or how it =
has to be used.

I think this is symptomatic of a larger problem that we occasionally =
fall for when writing specs.

ECMA-404 appears to be a textbook example of a =93trapdoor spec=94 =97 =
if you already know what it is supposed to say, then it reads fine, but =
if you approach it as a fresh spec, it is undecipherable, as it relies =
on tacit knowledge to connect the dots.

Now in this case that may not be as big a problem because everybody =
already does know what JSON is*).
I=92m still not thrilled to use it as a normative reference.

More importantly, reducing JSON to its surface syntax, and removing a =
few points about the data model (even though much of it remains in the =
form of allusions) opens the door to forking the data model.
This will allow all kinds of cool things to be done by repurposing the =
JSON syntax, but will damage the JSON ecosystem that is built around =
that data model.

One wonders whether that is the point.

Gr=FC=DFe, Carsten

*) Here specifically, we all know how to write numbers in programming =
languages, and (as long as you don=92t address the hard problems like =
exactness) the idiosyncratic syntax details (decimal only, no leading =
zeroes on mantissa, no plus, but leading zeroes or plus are allowed on =
the exponent, E can be upper or lower case) are all that is needed to =
detail this spec, even though there is much more to actual =
interoperability.  Few implementers will get the semantics wrong from =
that skimpy spec.


From presnick@qti.qualcomm.com  Sun Dec  8 23:34:33 2013
Return-Path: <presnick@qti.qualcomm.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40831AE20C for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 23:34:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.002
X-Spam-Level: 
X-Spam-Status: No, score=-4.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 Q7KqWRdiVNVs for <json@ietfa.amsl.com>; Sun,  8 Dec 2013 23:34:32 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 49C2E1AE039 for <json@ietf.org>; Sun,  8 Dec 2013 23:34:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1386574468; x=1418110468; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=6lTA22IRecmD8FOP9G2Yw5Z49HOVEK/fYmN9a771H8g=; b=LPZP54sGaqWJ36J96S7PBbKEPfviklhYKpE1FDn9xHAPvjbsWFHnLV0Q P34akIi63ua6ELpjQ8vr4aPCTflVqcY7I0UDWCaq9YY4LP9F8htNp38sn gRYdxpg3W5t7p8Ag1OdUITsKZ2d8ag8tLyN+nuk0hIqX3lw/uqRFNjeWP M=;
X-IronPort-AV: E=McAfee;i="5400,1158,7283"; a="811712"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 08 Dec 2013 23:34:28 -0800
X-IronPort-AV: E=McAfee;i="5400,1158,7283"; a="648781786"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Dec 2013 23:34:26 -0800
Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 8 Dec 2013 23:34:25 -0800
Message-ID: <52A57280.5040206@qti.qualcomm.com>
Date: Mon, 9 Dec 2013 01:34:24 -0600
From: Pete Resnick <presnick@qti.qualcomm.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <20131205044253.GH21240@localhost> <51F5DED3-A3CB-4AE3-9A1C-D9E25BFD822C@vpnc.org> <52A56719.1020106@it.aoyama.ac.jp>
In-Reply-To: <52A56719.1020106@it.aoyama.ac.jp>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [172.30.48.1]
Cc: Nico Williams <nico@cryptonector.com>, JSON WG <json@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 07:34:33 -0000

On 12/9/13 12:45 AM, "Martin J. Dürst" wrote:
> On 2013/12/06 0:58, Paul Hoffman wrote:
>> On Dec 4, 2013, at 8:42 PM, Nico Williams<nico@cryptonector.com>  wrote:
>
>>> Comments:
>>>
>>> - s/rfc4727/rfc4627/g  (the link to the attachment says 4727)
>>
>> That's actually not part of the response we are sending, so there is 
>> nothing we can change. Yes, the link is wrong in the Liaison tool, 
>> but we'll just have to live with that.
>
> I'm sure somebody is in charge of that tool, and can fix this. If the 
> chairs don't know how to request this, please ask your ADs.

Actually, that was an error in the liaison as submitted that I failed to 
correct. I've let the secretariat know to fix it.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478


From duerst@it.aoyama.ac.jp  Mon Dec  9 01:54:27 2013
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFE71A1F48 for <json@ietfa.amsl.com>; Mon,  9 Dec 2013 01:54:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.908
X-Spam-Level: 
X-Spam-Status: No, score=0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=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 p9OIDA3sc3rr for <json@ietfa.amsl.com>; Mon,  9 Dec 2013 01:54:25 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 750AF1A1F58 for <json@ietf.org>; Mon,  9 Dec 2013 01:54:25 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id rB99sAuM023651; Mon, 9 Dec 2013 18:54:10 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 31e9_d56a_d9f88118_60b7_11e3_be53_001e6722eec2; Mon, 09 Dec 2013 18:54:10 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 95616BFBBA; Mon,  9 Dec 2013 18:54:09 +0900 (JST)
Message-ID: <52A59337.4050609@it.aoyama.ac.jp>
Date: Mon, 09 Dec 2013 18:53:59 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Carsten Bormann <cabo@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp> <E19BDE18-DA46-4C00-AA6C-205C348326AD@tzi.org>
In-Reply-To: <E19BDE18-DA46-4C00-AA6C-205C348326AD@tzi.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Nico Williams <nico@cryptonector.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 09:54:28 -0000

On 2013/12/08 19:26, Carsten Bormann wrote:
> On 08 Dec 2013, at 10:58, Martin J. D=C3=BCrst<duerst@it.aoyama.ac.jp> =
 wrote:
>
>> There are two description methods is ECMA-404: text and "railroad" dia=
grams.
>
> There are actually two quite different kinds of racetracks (=E2=80=9Cra=
ilroad diagrams=E2=80=9D), the first three at the parser level and the se=
cond two at the scanner level.  This is nowhere explained (it just happen=
s to be the only one of the many potential interpretations of ECMA-404 th=
at yields a result getting close to current practice), and you have to pi=
ece together from section 4 what the interface between the two levels mig=
ht be.

I wanted to explain that there's no need to distinguish two levels=20
(scanner and parser), but in a later message, you mentioned this=20
yourself (for ABNF).

So what's the reason you talk about two levels? The only relevant=20
difference I can see is whitespace, and I think the spec text on=20
whitespace is quite clear, and it's easy to add the missing whitespace=20
to the railroad tracks if that's what one wants to do.

Also, the spec uses the word 'token', which is also the word used for=20
the entities passed from a lexer to a parser. But while certainly many=20
programming language specs are written with an implementation with=20
separate lexer and parser in mind, I don't think any programming=20
language spec requires such an implementation.

And if such a two-level implementation were necessary, or if a=20
description of the two levels were necessary, ABNF would surely fail, too=
.

>> The textual descriptions are in some cases quite precise, but in some =
other cases, leave quite a bit of ambiguity. And stuff like "It may have =
an exponent of ten, prefixed by e (U+0065) or E (U+0045) and optionally +=
 (U+002B) or =E2=80=93 (U+002D)." (in particlar the first clause of that =
sentence) doesn't make much sense.
>
> I read them mainly as a way to give meaning to the bubbles in the racet=
racks.
> All the statements that define the semantics of the data are really err=
ata anyway, we have learned.
> (If one were to do the semantics properly for section 8, one could simp=
ly reference ISO 6093.

Yes. One would expect something like this from a spec that is or is=20
expected to become an ISO spec.

> RFC 4627 does that implicitly by saying "The representation of numbers =
is similar to that used in most programming languages.".)

That's not very precise either, but it's at least telling the reader=20
where to look further if s/he doesn't understand what's intended.

Another problem is that it's not scalable, in the sense that it won't=20
work anymore if everybody would do it.

>> As for the railroad tracks, besides just floating in the spec without =
references, the notation is also not at all explained. If one took the mo=
st straightforward and obvious interpretation (that's not how standards w=
ork, but anyway), it's not too difficult to come up with a formally preci=
se way of converting each of them into a diagrams for a finite state mach=
ine. From there, conversion to the ABNF, or showing equivalence, on a qui=
te formal level, shouldn't be too much a problem.
>
> Yes, please.  I was asking for someone to do that work, maybe in the pr=
ocess generating some guidance on how to read ECMA-404.  It won=E2=80=99t=
 be me.

I'm not planning to do any work. I was just trying to point out that the=20
technical work is not that difficult (after some leaps of faith to take=20
the 'most obvious' interpretation of racetracks,...).

Regards,   Martin.

From cabo@tzi.org  Mon Dec  9 03:54:04 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C4E1ADF57 for <json@ietfa.amsl.com>; Mon,  9 Dec 2013 03:54:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.251
X-Spam-Level: 
X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001] autolearn=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 oI8F3JbY31DB for <json@ietfa.amsl.com>; Mon,  9 Dec 2013 03:54:03 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9041ADF5F for <json@ietf.org>; Mon,  9 Dec 2013 03:54:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rB9Brsl6016664; Mon, 9 Dec 2013 12:53:54 +0100 (CET)
Received: from [192.168.217.144] (p54890261.dip0.t-ipconnect.de [84.137.2.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8056DB97; Mon,  9 Dec 2013 12:53:53 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <52A59337.4050609@it.aoyama.ac.jp>
Date: Mon, 9 Dec 2013 12:53:51 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2AA6AE6A-C76D-4B61-BFE1-0EBDFB715D6D@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp> <E19BDE18-DA46-4C00-AA6C-205C348326AD@tzi.org> <52A59337.4050609@it.aoyama.ac.jp>
To: =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>
X-Mailer: Apple Mail (2.1822)
Cc: "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 11:54:04 -0000

> So what's the reason you talk about two levels?

If you interpret the first three racetracks as generating a sequence of =
characters, or the last two as generating a sequence of tokens, you get =
the wrong result.

>> RFC 4627 does that implicitly by saying "The representation of =
numbers is similar to that used in most programming languages.".)
>=20
> That's not very precise either, but it's at least telling the reader =
where to look further if s/he doesn't understand what's intended.

Actually, to the extent that RFC 4627 does define JSON's data model, the =
result of this simple statement is surprisingly precise.
It only stops helping you much when you reach the limits of precision or =
range (e.g., what to do with 1e400.)

> Another problem is that it's not scalable, in the sense that it won't =
work anymore if everybody would do it.

Right.  But then, section 11.8.3.1 of the ES6 draft is an example for =
why it is tedious to do this.
(It is also, I believe, a nice example how easy it would be to get this =
wrong and that nobody would actually notice a mistake buried in there, =
unless they do the work to systematically check every detail or to =
translate it into a machine-checkable form.  Fortunately, our number =
system is relatively stable; I=92d hate to maintain a spec that has this =
level of tedium on something that actually evolves.  For added fun, =
compare with 7.1.3.1.1, which is mostly saying the same thing, but does =
it in a subtly different way.  That=92s why ES6 is 531 pages...)

> I'm not planning to do any work. I was just trying to point out that =
the technical work is not that difficult (after some leaps of faith to =
take the 'most obvious' interpretation of racetracks,=85).

Yep.  But if nobody does that work (or, more precisely, admits to having =
done that work), we simply don=92t know whether the statement that =
triggered this little subthread is true or not.  I have made too many =
stupid mistakes in seemingly simple specs that became obvious only as =
soon as I used a tool to check the spec.

Gr=FC=DFe, Carsten


From allen@wirfs-brock.com  Mon Dec  9 16:32:53 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6AE1AD944 for <json@ietfa.amsl.com>; Mon,  9 Dec 2013 16:32:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 OcgOJLBbFJKs for <json@ietfa.amsl.com>; Mon,  9 Dec 2013 16:32:50 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 11AB81ADFD5 for <json@ietf.org>; Mon,  9 Dec 2013 16:32:49 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1VqBFe-0008MM-RP; Tue, 10 Dec 2013 00:32:39 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19NBv4H28quY9+T8ICSK+XQWwVhhujWXY8=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-185-306457961
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <2AA6AE6A-C76D-4B61-BFE1-0EBDFB715D6D@tzi.org>
Date: Mon, 9 Dec 2013 16:32:30 -0800
Message-Id: <8E4C7969-7868-4DE9-A9B0-C7FD484075B1@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp> <E19BDE18-DA46-4C00-AA6C-205C348326AD@tzi.org> <52A59337.4050609@it.aoyama.ac.jp> <2AA6AE6A-C76D-4B61-BFE1-0EBDFB715D6D@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.1085)
Cc: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>, JSON WG <json@ietf.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 00:32:53 -0000

--Apple-Mail-185-306457961
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Dec 9, 2013, at 3:53 AM, Carsten Bormann wrote:

>> So what's the reason you talk about two levels?
>=20
> If you interpret the first three racetracks as generating a sequence =
of characters, or the last two as generating a sequence of tokens, you =
get the wrong result.
>=20
>>> RFC 4627 does that implicitly by saying "The representation of =
numbers is similar to that used in most programming languages.".)
>>=20
>> That's not very precise either, but it's at least telling the reader =
where to look further if s/he doesn't understand what's intended.
>=20
> Actually, to the extent that RFC 4627 does define JSON's data model, =
the result of this simple statement is surprisingly precise.
> It only stops helping you much when you reach the limits of precision =
or range (e.g., what to do with 1e400.)
>=20
>> Another problem is that it's not scalable, in the sense that it won't =
work anymore if everybody would do it.
>=20
> Right.  But then, section 11.8.3.1 of the ES6 draft is an example for =
why it is tedious to do this.
> (It is also, I believe, a nice example how easy it would be to get =
this wrong and that nobody would actually notice a mistake buried in =
there, unless they do the work to systematically check every detail or =
to translate it into a machine-checkable form.  Fortunately, our number =
system is relatively stable; I=92d hate to maintain a spec that has this =
level of tedium on something that actually evolves.  For added fun, =
compare with 7.1.3.1.1, which is mostly saying the same thing, but does =
it in a subtly different way.  That=92s why ES6 is 531 pages...)
>=20
>> I'm not planning to do any work. I was just trying to point out that =
the technical work is not that difficult (after some leaps of faith to =
take the 'most obvious' interpretation of racetracks,=85).
>=20
> Yep.  But if nobody does that work (or, more precisely, admits to =
having done that work), we simply don=92t know whether the statement =
that triggered this little subthread is true or not.  I have made too =
many stupid mistakes in seemingly simple specs that became obvious only =
as soon as I used a tool to check the spec.
>=20
> Gr=FC=DFe, Carsten

I want to address a few points brought up in this subthread, primarily =
between Carsten and Martin.

First Syntax Diagrams (aks, RailRoad Diagrams and called racetracks in =
this thread) are a well known formalism for expressing a context free =
grammar.  For example see http://en.wikipedia.org/wiki/Syntax_diagram =
Any competent software engineer should be able to recognize and read a =
syntax diagram of this sort. There is no mystery about them. Any grammar =
that can be expressed using BNF can also be expressed using a Syntax =
Diagram although I think most would agree that  BNF is a better =
alternative for large grammars.=20

This whole issue of the use of Syntax Diagrams rather than BNF is a =
stylist debate that is hard to take seriously. If TC39 informed you that =
we are converting the notation used in ECMA-404 to a BNF formalism would =
that end the objections  to normatively referencing  ECMA-404 from =
4627bis?  Unfortunately, I'm pretty sure it wouldn't.

Regarding, using of a multiply level definition within ECMA-404.  That =
is a standard practice within language specification where the "tokens" =
of a language are often described using a FSM level formalism and the =
syntactic structure is described using a PDA level formalism.  However, =
there is nothing that prevents a PDA level abstraction such as a BNF =
from being using to describe "tokens" even with the full power of a PDA =
isn't used.  The ECMA-262 specification is an example of a language =
specification that using a BNF to describe both its lexical and =
syntactic structure.

In the case of ECMA-404, clause 4 is clearly defining the lexical level =
of the language (it is talking about "tokens") and it clearly states =
that numbers and strings are tokens. Hence there is no ambiguity about =
how to interpret the syntax diagrams for number and string in clauses 8 =
and 9.  None of the subelements of diagrams are "tokens" so there is no =
plausible way they could be misconstrued as generating or recognizing a =
sequence of tokens.

The only normative purpose of the first paragraph in clause 8 (Numbers) =
is to identify the code points that  are symbolically referenced by the =
Syntax diagram. Everything else in that paragraph is either redundant =
(describe by the diagram) or pseudo-semantics that are outside the scope =
of what ECMA-404 defines.=20

This is a common problem seen in many specification that try to clarify =
a formalism with supplementary prose and instead ends up sowing =
confusion.  If a bug was filed against this for ECMA-404 it will =
probably be cleaned up in the next edition. Note that the current =
4627bis draft is very similar in this regard.  It talks about an =
"exponent part" with out defining that term. (it doesn't appear in the =
grammar).  It doesn't specify how to actually interpret a number token =
as a mathematical  value or how to generate one from a mathematical =
value.  It only says that JSON numbers  are  similar to those in most =
programming languages (which includes a very wide range of =
possibilities).

Specs. can have both technical and editorial bugs.  If you think there =
are bugs in ECMA-404 the best thing to do is to submit a bug ticket at =
bugs.ecmascript.org. If there is a critical bug that you think prevents =
4627bis from normatively referencing ECMA-404 say so and assign the bug =
a high priority in the initial ticket.  But please, start with actual =
errors, ambiguities, inconsistencies, or similar substantive issue.  =
Stylistic issues won't be ignore but they are less important and harder =
to reach agreement on.

Allen


--Apple-Mail-185-306457961
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Dec 9, 2013, at 3:53 AM, Carsten Bormann =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div><blockquote type=3D"cite">So what's the reason you =
talk about two levels?<br></blockquote><br>If you interpret the first =
three racetracks as generating a sequence of characters, or the last two =
as generating a sequence of tokens, you get the wrong =
result.<br><br><blockquote type=3D"cite"><blockquote type=3D"cite">RFC =
4627 does that implicitly by saying "The representation of numbers is =
similar to that used in most programming =
languages.".)<br></blockquote></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">That's not very =
precise either, but it's at least telling the reader where to look =
further if s/he doesn't understand what's =
intended.<br></blockquote><br>Actually, to the extent that RFC 4627 does =
define JSON's data model, the result of this simple statement is =
surprisingly precise.<br>It only stops helping you much when you reach =
the limits of precision or range (e.g., what to do with =
1e400.)<br><br><blockquote type=3D"cite">Another problem is that it's =
not scalable, in the sense that it won't work anymore if everybody would =
do it.<br></blockquote><br>Right. &nbsp;But then, section 11.8.3.1 of =
the ES6 draft is an example for why it is tedious to do this.<br>(It is =
also, I believe, a nice example how easy it would be to get this wrong =
and that nobody would actually notice a mistake buried in there, unless =
they do the work to systematically check every detail or to translate it =
into a machine-checkable form. &nbsp;Fortunately, our number system is =
relatively stable; I=92d hate to maintain a spec that has this level of =
tedium on something that actually evolves. &nbsp;For added fun, compare =
with 7.1.3.1.1, which is mostly saying the same thing, but does it in a =
subtly different way. &nbsp;That=92s why ES6 is 531 =
pages...)<br><br><blockquote type=3D"cite">I'm not planning to do any =
work. I was just trying to point out that the technical work is not that =
difficult (after some leaps of faith to take the 'most obvious' =
interpretation of racetracks,=85).<br></blockquote><br>Yep. &nbsp;But if =
nobody does that work (or, more precisely, admits to having done that =
work), we simply don=92t know whether the statement that triggered this =
little subthread is true or not. &nbsp;I have made too many stupid =
mistakes in seemingly simple specs that became obvious only as soon as I =
used a tool to check the spec.<br><br>Gr=FC=DFe, =
Carsten<br></div></blockquote><br></div><div>I want to address a few =
points brought up in this subthread, primarily between Carsten and =
Martin.</div><div><br></div><div>First Syntax Diagrams (aks, RailRoad =
Diagrams and called racetracks in this thread) are a well known =
formalism for expressing a context free grammar. &nbsp;For example =
see&nbsp;<a =
href=3D"http://en.wikipedia.org/wiki/Syntax_diagram">http://en.wikipedia.o=
rg/wiki/Syntax_diagram</a>&nbsp;Any competent software engineer should =
be able to recognize and read a syntax diagram of this sort. There is no =
mystery about them. Any grammar that can be expressed using BNF can also =
be expressed using a Syntax Diagram although I think most would agree =
that &nbsp;BNF is a better alternative for large =
grammars.&nbsp;</div><div><br></div><div>This whole issue of the use of =
Syntax Diagrams rather than BNF is a stylist debate that is hard to take =
seriously. If TC39 informed you that we are converting the notation used =
in ECMA-404 to a BNF formalism would that end the objections &nbsp;to =
normatively referencing &nbsp;ECMA-404 from 4627bis? =
&nbsp;Unfortunately, I'm pretty sure it =
wouldn't.</div><div><br></div><div>Regarding, using of a multiply level =
definition within ECMA-404. &nbsp;That is a standard practice within =
language specification where the "tokens" of a language are often =
described using a FSM level formalism and the syntactic structure is =
described using a PDA level formalism. &nbsp;However, there is nothing =
that prevents a PDA level abstraction such as a BNF from being using to =
describe "tokens" even with the full power of a PDA isn't used. =
&nbsp;The ECMA-262 specification is an example of a language =
specification that using a BNF to describe both its lexical and =
syntactic structure.</div><div><br></div><div>In the case of ECMA-404, =
clause 4 is clearly defining the lexical level of the language (it is =
talking about "tokens") and it clearly states that numbers and strings =
are tokens. Hence there is no ambiguity about how to interpret the =
syntax diagrams for number and string in clauses 8 and 9. &nbsp;None of =
the subelements of diagrams are "tokens" so there is no plausible way =
they could be misconstrued as generating or recognizing a sequence of =
tokens.</div><div><br></div><div>The only normative purpose of the first =
paragraph in clause 8 (Numbers) is to identify the code points that =
&nbsp;are symbolically referenced by the Syntax diagram. Everything else =
in that paragraph is either redundant (describe by the diagram) or =
pseudo-semantics that are outside the scope of what ECMA-404 =
defines.&nbsp;</div><div><br></div><div>This is a common problem seen in =
many specification that try to clarify a formalism with supplementary =
prose and instead ends up sowing confusion. &nbsp;If a bug was filed =
against this for ECMA-404 it will probably be cleaned up in the next =
edition. Note that the current 4627bis draft is very similar in this =
regard. &nbsp;It talks about an "exponent part" with out defining that =
term. (it doesn't appear in the grammar). &nbsp;It doesn't specify how =
to actually interpret a number token as a mathematical &nbsp;value or =
how to generate one from a mathematical value. &nbsp;It only says that =
JSON numbers &nbsp;are &nbsp;similar to those in most programming =
languages (which includes a very wide range of =
possibilities).</div><div><br></div><div>Specs. can have both technical =
and editorial bugs. &nbsp;If you think there are bugs in ECMA-404 the =
best thing to do is to submit a bug ticket at <a =
href=3D"http://bugs.ecmascript.org">bugs.ecmascript.org</a>. If there is =
a critical bug that you think prevents 4627bis from normatively =
referencing ECMA-404 say so and assign the bug a high priority in the =
initial ticket. &nbsp;But please, start with actual errors, ambiguities, =
inconsistencies, or similar substantive issue. &nbsp;Stylistic issues =
won't be ignore but they are less important and harder to reach =
agreement on.</div><div><br></div><div>Allen</div><br></body></html>=

--Apple-Mail-185-306457961--

From derhoermi@gmx.net  Mon Dec  9 17:41:05 2013
Return-Path: <derhoermi@gmx.net>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6291ADFE1 for <json@ietfa.amsl.com>; Mon,  9 Dec 2013 17:41:05 -0800 (PST)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 j__-WPxQCdez for <json@ietfa.amsl.com>; Mon,  9 Dec 2013 17:41:03 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 626391ADF38 for <json@ietf.org>; Mon,  9 Dec 2013 17:41:03 -0800 (PST)
Received: from netb.Speedport_W_700V ([84.180.228.227]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MJSuF-1Vs8G31jQJ-0033lB for <json@ietf.org>; Tue, 10 Dec 2013 02:40:57 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Tue, 10 Dec 2013 02:40:55 +0100
Message-ID: <serca9lle8m19n7ikdhf9ldlcoo8b9mpos@hive.bjoern.hoehrmann.de>
References: <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp> <E19BDE18-DA46-4C00-AA6C-205C348326AD@tzi.org> <52A59337.4050609@it.aoyama.ac.jp> <2AA6AE6A-C76D-4B61-BFE1-0EBDFB715D6D@tzi.org> <8E4C7969-7868-4DE9-A9B0-C7FD484075B1@wirfs-brock.com>
In-Reply-To: <8E4C7969-7868-4DE9-A9B0-C7FD484075B1@wirfs-brock.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:o/aMBH1gx7VPuDLji89Cgo9bMLuKE3rn5CRre5N3Zy7U2BI6cjJ JSnUs4Ey96jID9HBRSRTk7nTPPr353C8api9xA9LePbEqII+Fv+QoNrl3J7RmQdcp+9q5/b 7bJhHPdM8zskMCINajVpPcLO9jSTIhn6Ll7U5SuRTbxQkKlKWJDIRmt828YXuhOTHSvkUFy 1bi8cGtuHUNVxid5sluog==
Cc: "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, www-tag@w3.org, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 01:41:05 -0000

* Allen Wirfs-Brock wrote:
>This whole issue of the use of Syntax Diagrams rather than BNF is a 
>stylist debate that is hard to take seriously. If TC39 informed you that 
>we are converting the notation used in ECMA-404 to a BNF formalism would 
>that end the objections  to normatively referencing  ECMA-404 from 
>4627bis?  Unfortunately, I'm pretty sure it wouldn't.

If TC39 said ECMA-404 is going to be replaced by a verbatim copy of the
ABNF grammar in draft-ietf-json-rfc4627bis-08 with pretty much no other
discussion of JSON and a clear indication that future editions will not
add such discussion, and will not change the grammar without IETF con-
sensus, I would be willing to entertain the idea of making ECMA-404 a
normative reference.

How soon would TC39 be able to make such a decision and publish a re-
vised edition of ECMA-404 as described above?
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From allen@wirfs-brock.com  Mon Dec  9 18:43:43 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F091AE107 for <json@ietfa.amsl.com>; Mon,  9 Dec 2013 18:43:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.899
X-Spam-Level: 
X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 iHmy88I05cCb for <json@ietfa.amsl.com>; Mon,  9 Dec 2013 18:43:40 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 62A4D1ADED7 for <json@ietf.org>; Mon,  9 Dec 2013 18:43:39 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1VqDIJ-0000vY-Vp; Tue, 10 Dec 2013 02:43:32 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+Ghp7tl02+80lMCv++3Ab312h/yafc6QM=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-186-314311930
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <serca9lle8m19n7ikdhf9ldlcoo8b9mpos@hive.bjoern.hoehrmann.de>
Date: Mon, 9 Dec 2013 18:43:24 -0800
Message-Id: <1E12FB6A-BD61-4E51-89E9-4398F943FF8F@wirfs-brock.com>
References: <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp> <E19BDE18-DA46-4C00-AA6C-205C348326AD@tzi.org> <52A59337.4050609@it.aoyama.ac.jp> <2AA6AE6A-C76D-4B61-BFE1-0EBDFB715D6D@tzi.org> <8E4C7969-7868-4DE9-A9B0-C7FD484075B1@wirfs-brock.com> <serca9lle8m19n7ikdhf9ldlcoo8b9mpos@hive.bjoern.hoehrmann.de>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
X-Mailer: Apple Mail (2.1085)
Cc: JSON WG <json@ietf.org>, www-tag@w3.org, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 02:43:44 -0000

--Apple-Mail-186-314311930
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Dec 9, 2013, at 5:40 PM, Bjoern Hoehrmann wrote:

> * Allen Wirfs-Brock wrote:
>> This whole issue of the use of Syntax Diagrams rather than BNF is a=20=

>> stylist debate that is hard to take seriously. If TC39 informed you =
that=20
>> we are converting the notation used in ECMA-404 to a BNF formalism =
would=20
>> that end the objections  to normatively referencing  ECMA-404 from=20
>> 4627bis?  Unfortunately, I'm pretty sure it wouldn't.
>=20
> If TC39 said ECMA-404 is going to be replaced by a verbatim copy of =
the
> ABNF grammar in draft-ietf-json-rfc4627bis-08 with pretty much no =
other
> discussion of JSON and a clear indication that future editions will =
not
> add such discussion, and will not change the grammar without IETF con-
> sensus, I would be willing to entertain the idea of making ECMA-404 a
> normative reference.

Note that ECMA-404 already says (in the introduction):

"It is expected that other standards will refer to this one, strictly =
adhering to the JSON text format, while imposing restrictions on various =
encoding details. Such standards may require specific behaviours. JSON =
itself specifies no behaviour.

Because it is so simple, it is not expected that the JSON grammar will =
ever change. This gives JSON, as a foundational notation, tremendous =
stability."

The second paragraph is speaking about the language described by the =
grammar, not the actual formalism used to express the grammar. I'm quite =
sure that there is no interest at all within TC39 to ever change the =
actual JSON language.  If you are looking for some sort of contractual =
commitment from ECMA, I suspect you are wasting your time. Does the IETF =
make such commitments?

TC39 is a consensus based organization so I can't make commitments for =
it or the ECMA-404 project editor. But,  let me quote two previous =
statements I've made on this thread concerning the grammar notation:

"It's silly to be squabbling over such a notational issues and =
counter-productive if such squabbles results multiple different =
normative standards for the same language/format. TC39 would likely be =
receptive to a request to add to ECMA-404 an informative annex with a =
BNF grammar for JSON (even ABNF, even though it isn't TC39's normal BNF =
conventions). Asking is likely to produce better results than throwing =
stones."

"The position stated by TC39 that ECMA-404 already exists as a normative =
specification of the JSON syntax and we have requested that RFC4627bis =
normatively reference it as such and that any restatement of ECMA-404 =
subject matter should be marked as informative.  We think that dueling =
normative specifications would be a bad thing. Seeing that the form of =
expression used by ECMA-404 seems to be a issue for some JSON WG =
participants I have suggested that TC39 could probably be convinced to =
revise ECMA-404 to include a BNF style formalism for the syntax.  If =
there is interest in this alternative I'd be happy to champion it within =
TC39."

This doesn't mean that TC39 would necessarily agree to eliminate the =
Syntax Diagrams,  or that we wouldn't carefully audit any grammar =
contribution to make sure that it is describing the same language.  =
There may also be minor issues that need to be resolved. But we seem to =
agree that we already are both accurately describing the same language =
so this is really about notational agreement.

>=20
> How soon would TC39 be able to make such a decision and publish a re-
> vised edition of ECMA-404 as described above?

As a base line, ECMA-404 was created in less than a week.  It takes a =
couple months to push through a letter ballot to above a revised =
standard.=20

Allen=

--Apple-Mail-186-314311930
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Dec 9, 2013, at 5:40 PM, Bjoern Hoehrmann =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>* Allen Wirfs-Brock wrote:<br><blockquote =
type=3D"cite">This whole issue of the use of Syntax Diagrams rather than =
BNF is a <br></blockquote><blockquote type=3D"cite">stylist debate that =
is hard to take seriously. If TC39 informed you that =
<br></blockquote><blockquote type=3D"cite">we are converting the =
notation used in ECMA-404 to a BNF formalism would =
<br></blockquote><blockquote type=3D"cite">that end the objections =
&nbsp;to normatively referencing &nbsp;ECMA-404 from =
<br></blockquote><blockquote type=3D"cite">4627bis? &nbsp;Unfortunately, =
I'm pretty sure it wouldn't.<br></blockquote><br>If TC39 said ECMA-404 =
is going to be replaced by a verbatim copy of the<br>ABNF grammar in =
draft-ietf-json-rfc4627bis-08 with pretty much no other<br>discussion of =
JSON and a clear indication that future editions will not<br>add such =
discussion, and will not change the grammar without IETF con-<br>sensus, =
I would be willing to entertain the idea of making ECMA-404 =
a<br>normative reference.<br></div></blockquote><div><br></div><div>Note =
that ECMA-404 already says (in the =
introduction):</div><div><br></div><div><div dir=3D"ltr" =
style=3D"font-size: 13.28px; font-family: sans-serif; left: 49.12px; =
top: 708.093px; transform: rotate(0deg) scale(0.977445, 1); =
transform-origin: 0% 0% 0px;" data-angle=3D"0" =
data-font-name=3D"g_font_5_0" data-canvas-width=3D"653.0307394618321">"It =
 is  expected  that  other  standards  will  refer  to  this  one,  =
strictly  adhering  to  the  JSON  text  format,  while&nbsp;imposing  =
restrictions  on  various  encoding  details.  Such  standards may  =
require  specific  behaviours.  JSON&nbsp;itself specifies no =
behaviour.</div><div dir=3D"ltr" style=3D"font-size: 13.28px; =
font-family: sans-serif; left: 49.12px; top: 708.093px; transform: =
rotate(0deg) scale(0.977445, 1); transform-origin: 0% 0% 0px;" =
data-angle=3D"0" data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"653.0307394618321"><br></div><div dir=3D"ltr" =
style=3D"font-size: 13.28px; font-family: sans-serif; left: 49.12px; =
top: 770.053px; transform: rotate(0deg) scale(1.04256, 1); =
transform-origin: 0% 0% 0px;" data-angle=3D"0" =
data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"159.14752474296574">Because it is so simple, =
it&nbsp;is&nbsp;not expected that the JSON grammar will ever change. =
This gives JSON, as a&nbsp;foundational notation, tremendous =
stability."</div><div dir=3D"ltr" style=3D"font-size: 13.28px; =
font-family: sans-serif; left: 49.12px; top: 770.053px; transform: =
rotate(0deg) scale(1.04256, 1); transform-origin: 0% 0% 0px;" =
data-angle=3D"0" data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"159.14752474296574"><br></div><div dir=3D"ltr" =
style=3D"font-size: 13.28px; font-family: sans-serif; left: 49.12px; =
top: 770.053px; transform: rotate(0deg) scale(1.04256, 1); =
transform-origin: 0% 0% 0px;" data-angle=3D"0" =
data-font-name=3D"g_font_5_0" data-canvas-width=3D"159.14752474296574">The=
 second paragraph is speaking about the language described by the =
grammar, not the actual formalism used to express the grammar. I'm quite =
sure that there is no interest at all within TC39 to ever change the =
actual JSON language. &nbsp;If you are looking for some sort of =
contractual commitment from ECMA, I suspect you are wasting your time. =
Does the IETF make such commitments?</div><div dir=3D"ltr" =
style=3D"font-size: 13.28px; font-family: sans-serif; left: 49.12px; =
top: 770.053px; transform: rotate(0deg) scale(1.04256, 1); =
transform-origin: 0% 0% 0px;" data-angle=3D"0" =
data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"159.14752474296574"><br></div><div dir=3D"ltr" =
style=3D"font-size: 13.28px; font-family: sans-serif; left: 49.12px; =
top: 770.053px; transform: rotate(0deg) scale(1.04256, 1); =
transform-origin: 0% 0% 0px;" data-angle=3D"0" =
data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"159.14752474296574">TC39 is a consensus based =
organization so I can't make commitments for it or the ECMA-404 project =
editor. But, &nbsp;let me quote two previous statements I've made on =
this thread concerning the grammar notation:</div><div dir=3D"ltr" =
style=3D"font-size: 13.28px; font-family: sans-serif; left: 49.12px; =
top: 770.053px; transform: rotate(0deg) scale(1.04256, 1); =
transform-origin: 0% 0% 0px;" data-angle=3D"0" =
data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"159.14752474296574"><br></div><div>"It's silly to =
be squabbling over such a notational issues and counter-productive if =
such squabbles results multiple different normative standards for the =
same language/format.&nbsp;TC39 would likely be receptive to a request =
to add to ECMA-404 an informative annex with a BNF grammar for JSON =
(even ABNF, even though it isn't TC39's normal BNF conventions). Asking =
is likely to produce better results than throwing stones."</div><div =
dir=3D"ltr" style=3D"font-size: 13.28px; font-family: sans-serif; left: =
49.12px; top: 770.053px; transform: rotate(0deg) scale(1.04256, 1); =
transform-origin: 0% 0% 0px;" data-angle=3D"0" =
data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"159.14752474296574"><span class=3D"Apple-style-span" =
style=3D"font-family: Helvetica; font-size: medium; =
"><br></span></div><div dir=3D"ltr" style=3D"font-size: 13.28px; =
font-family: sans-serif; left: 49.12px; top: 770.053px; transform: =
rotate(0deg) scale(1.04256, 1); transform-origin: 0% 0% 0px;" =
data-angle=3D"0" data-font-name=3D"g_font_5_0" =
data-canvas-width=3D"159.14752474296574"><span class=3D"Apple-style-span" =
style=3D"font-family: Helvetica; font-size: medium; ">"The position =
stated by TC39 that ECMA-404 already exists as a normative specification =
of the JSON syntax and we have requested that RFC4627bis normatively =
reference it as such and that any restatement of ECMA-404 subject matter =
should be marked as informative. &nbsp;We think that dueling normative =
specifications would be a bad thing. Seeing that the form of expression =
used by ECMA-404 seems to be a issue for some JSON WG participants I =
have suggested that TC39 could probably be convinced to revise ECMA-404 =
to include a BNF style formalism for the syntax. &nbsp;If there is =
interest in this alternative I'd be happy to champion it within =
TC39."</span></div></div><div><br></div><div>This doesn't mean that TC39 =
would necessarily agree to eliminate the Syntax Diagrams, &nbsp;or that =
we wouldn't carefully audit any grammar contribution to make sure that =
it is describing the same language. &nbsp;There may also be minor issues =
that need to be resolved. But we seem to agree that we already are both =
accurately describing the same language so this is really about =
notational agreement.</div><br><blockquote type=3D"cite"><div><br>How =
soon would TC39 be able to make such a decision and publish a =
re-<br>vised edition of ECMA-404 as described =
above?<br></div></blockquote><div><br></div><div>As a base line, =
ECMA-404 was created in less than a week. &nbsp;It takes a couple months =
to push through a letter ballot to above a revised =
standard.&nbsp;</div><div><br></div><div>Allen</div></div></body></html>=

--Apple-Mail-186-314311930--

From brendan@mozilla.com  Mon Dec  9 17:58:50 2013
Return-Path: <brendan@mozilla.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6B21ADFE1 for <json@ietfa.amsl.com>; Mon,  9 Dec 2013 17:58:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.279
X-Spam-Level: 
X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 wbLOuhuQcSgl for <json@ietfa.amsl.com>; Mon,  9 Dec 2013 17:58:48 -0800 (PST)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 89ADF1AE0B6 for <json@ietf.org>; Mon,  9 Dec 2013 17:58:48 -0800 (PST)
Received: from beich-10880.local (244.sub-70-197-13.myvzw.com [70.197.13.244]) (Authenticated sender: brendan@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id D7BA2F2372; Mon,  9 Dec 2013 17:58:42 -0800 (PST)
Message-ID: <52A67552.3070405@mozilla.com>
Date: Mon, 09 Dec 2013 17:58:42 -0800
From: Brendan Eich <brendan@mozilla.com>
User-Agent: Postbox 3.0.8 (Macintosh/20130427)
MIME-Version: 1.0
To: Bjoern Hoehrmann <derhoermi@gmx.net>
References: <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp> <E19BDE18-DA46-4C00-AA6C-205C348326AD@tzi.org> <52A59337.4050609@it.aoyama.ac.jp> <2AA6AE6A-C76D-4B61-BFE1-0EBDFB715D6D@tzi.org> <8E4C7969-7868-4DE9-A9B0-C7FD484075B1@wirfs-brock.com> <serca9lle8m19n7ikdhf9ldlcoo8b9mpos@hive.bjoern.hoehrmann.de>
In-Reply-To: <serca9lle8m19n7ikdhf9ldlcoo8b9mpos@hive.bjoern.hoehrmann.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 09 Dec 2013 19:18:50 -0800
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, JSON WG <json@ietf.org>, www-tag@w3.org, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 02:20:59 -0000

http://bugs.ecmascript.org/ -- please use it, you will be amazed at how 
quickly the bug is resolved. Thanks,

/be

Bjoern Hoehrmann wrote:
> If TC39 said ECMA-404 is going to be replaced by a verbatim copy of the
> ABNF grammar in draft-ietf-json-rfc4627bis-08 with pretty much no other
> discussion of JSON and a clear indication that future editions will not
> add such discussion, and will not change the grammar without IETF con-
> sensus, I would be willing to entertain the idea of making ECMA-404 a
> normative reference.
>
> How soon would TC39 be able to make such a decision and publish a re-
> vised edition of ECMA-404 as described above?

From cabo@tzi.org  Tue Dec 10 00:54:27 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCF81AE12E for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 00:54:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 dJD_9eG-XhNH for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 00:54:26 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D2E271ADF33 for <json@ietf.org>; Tue, 10 Dec 2013 00:54:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBA8sDjS005112; Tue, 10 Dec 2013 09:54:13 +0100 (CET)
Received: from [192.168.217.105] (p54890261.dip0.t-ipconnect.de [84.137.2.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 78D7F15C; Tue, 10 Dec 2013 09:54:12 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <8E4C7969-7868-4DE9-A9B0-C7FD484075B1@wirfs-brock.com>
Date: Tue, 10 Dec 2013 09:54:12 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <293E4703-19F9-4AD0-8D46-BDA943332DFE@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp> <E19BDE18-DA46-4C00-AA6C-205C348326AD@tzi.org> <52A59337.4050609@it.aoyama.ac.jp> <2AA6AE6A-C76D-4B61-BFE1-0EBDFB715D6D@tzi.org> <8E4C7969-7868-4DE9-A9B0-C7FD484075B1@wirfs-brock.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
X-Mailer: Apple Mail (2.1822)
Cc: =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 08:54:27 -0000

On 10 Dec 2013, at 01:32, Allen Wirfs-Brock <allen@wirfs-brock.com> =
wrote:

> Stylistic issues=20

Well, for 4627bis, we have tools that allowed us to fuzz the ABNF =
against a set of existing JSON implementations.
This is the kind of care I expect from spec writers.
Nobody has fessed up to having done equivalent work for ECMA-404.
Matter of style?  Yes, but in quite another sense.

Gr=FC=DFe, Carsten


From cabo@tzi.org  Tue Dec 10 01:12:41 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F8F1AD83F for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 01:12:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 mB7fVIkjgWvg for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 01:12:40 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id EE3E61AD6BF for <json@ietf.org>; Tue, 10 Dec 2013 01:12:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBA9CQaO012252; Tue, 10 Dec 2013 10:12:26 +0100 (CET)
Received: from [192.168.217.105] (p54890261.dip0.t-ipconnect.de [84.137.2.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7B338194; Tue, 10 Dec 2013 10:12:25 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com>
Date: Tue, 10 Dec 2013 10:12:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com>
To: James Clark <jjc@jclark.com>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>, Allen Wirfs-Brock <allen@wirfs-brock.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 09:12:41 -0000

On 10 Dec 2013, at 07:52, James Clark <jjc@jclark.com> wrote:

> Infoset

Not a bad idea to lead us out of this quagmire.

So a JSON infoset would capture a processed AST, but not yet the =
transformation to the data model level.

JSON implementations would create the JSON data model from that infoset =
(typically without actually reifying the latter as an AST), and JSON =
extensions like ECMAscript's would be free to do whatever they want.
It is just important to distinguish the two, so people don=92t confuse =
the data model with the infoset, or think that a JSON implementation =
needs to provide access to the infoset.

Re the infoset for JSON numbers:  That is clearly a rational, expressed =
as a pair of two integers: a numerator and a (power of ten) denominator. =
 (JSON cannot express any other rationals, or any irrationals for that =
matter.)

1.23 is [123, 100]
1.5 is [15, 10]
1e4 is [10000, 1]
1e-4 is [1, 10000]

Now one could argue whether the infoset should distinguish 1 and 1.0.
Naively, that would be
1 is [1, 1]
1.0 is [10, 10]
I=92d argue that you want to reduce toward the denominator being the =
minimal power of ten, i.e.
1 is [1, 1]
1.0 is [1, 1]
1.5 is [15, 10]

Gr=FC=DFe, Carsten


From cabo@tzi.org  Tue Dec 10 01:22:46 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9CA1ABBB1 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 01:22:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 0R-F1D8JgMZf for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 01:22:41 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4E75C1A1F7B for <json@ietf.org>; Tue, 10 Dec 2013 01:22:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBA9MSW4002579 for <json@ietf.org>; Tue, 10 Dec 2013 10:22:28 +0100 (CET)
Received: from [192.168.217.105] (p54890261.dip0.t-ipconnect.de [84.137.2.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 57D6C1BE; Tue, 10 Dec 2013 10:22:28 +0100 (CET)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Carsten Bormann <cabo@tzi.org>
Date: Tue, 10 Dec 2013 10:22:26 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7895D7DA-E608-49DF-8984-FFC91AFDBF04@tzi.org>
References: <7FD8497D-5E19-4EFE-B66E-538FC42B7478@nuance.com>
To: JSON WG <json@ietf.org>
X-Mailer: Apple Mail (2.1822)
Subject: [Json] Fwd: two comments on JSON, ECMA-404, 1st edition / October 2013
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 09:22:46 -0000

FYI for those who haven=92t surrendered into subscribing to es-discuss =
yet:

Begin forwarded message:

> From: "Patel-Schneider, Peter" <Peter.Patel-Schneider@nuance.com>
> Subject: two comments on JSON, ECMA-404, 1st edition / October 2013
> Date: 10 Dec 2013 06:00:34 +0100
> To: "es-discuss@mozilla.org" <es-discuss@mozilla.org>
>=20
> 1/ According to ECMA-404, 1st edition / October 2013, a JSON text is a =
sequence
> of Unicode code points.   The code points that can appear in a JSON =
text
> include all code point except the control characters (the text says =
U+0000
> to U+001F but the syntax diagram just says control character, which in
> Unicode 6.3 also includes U+007F to U+009F).  Therefore, the code
> point sequence <0022, DEAD, 0022> is a valid JSON text.
>=20
> However, this code point sequence cannot be represented in UTF-8, =
UTF-16, or
> UTF-32, as it is not a sequence of Unicode scalar values, and=20
> Unicode encoding forms are only defined on Unicode scalar values. =20
>=20
>=20
> 2/ The unescaping of strings in JSON is ill-defined as there are =
quoted=20
> JSON strings that are the escaped version of two different sequences =
of
> Unicode code points.  For example both <D834, DD1E> and <1D11E> can be
> represented as "\uD834\uDD1E".=20
>=20
>=20
> Both of these appear to be bugs that should be fixed.
>=20
> Peter F. Patel-Schneider
>=20
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>=20


From duerst@it.aoyama.ac.jp  Tue Dec 10 02:08:30 2013
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912B31AD9AD for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 02:08:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.908
X-Spam-Level: 
X-Spam-Status: No, score=0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=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 tt7zS0fM6aoo for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 02:08:28 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id B4E2E1ACCDF for <json@ietf.org>; Tue, 10 Dec 2013 02:08:27 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id rBAA8Jq1003180; Tue, 10 Dec 2013 19:08:20 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 336a_f5dd_fec32d92_6182_11e3_8bc8_001e6722eec2; Tue, 10 Dec 2013 19:08:19 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 2DE1ABF4DE; Tue, 10 Dec 2013 19:08:19 +0900 (JST)
Message-ID: <52A6E807.9050103@it.aoyama.ac.jp>
Date: Tue, 10 Dec 2013 19:08:07 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp> <E19BDE18-DA46-4C00-AA6C-205C348326AD@tzi.org> <52A59337.4050609@it.aoyama.ac.jp> <2AA6AE6A-C76D-4B61-BFE1-0EBDFB715D6D@tzi.org> <8E4C7969-7868-4DE9-A9B0-C7FD484075B1@wirfs-brock.com>
In-Reply-To: <8E4C7969-7868-4DE9-A9B0-C7FD484075B1@wirfs-brock.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Carsten Bormann <cabo@tzi.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 10:08:30 -0000

On 2013/12/10 9:32, Allen Wirfs-Brock wrote:

> I want to address a few points brought up in this subthread, primarily between Carsten and Martin.

Thanks!

> First Syntax Diagrams (aks, RailRoad Diagrams and called racetracks in this thread) are a well known formalism for expressing a context free grammar.  For example see http://en.wikipedia.org/wiki/Syntax_diagram Any competent software engineer should be able to recognize and read a syntax diagram of this sort. There is no mystery about them. Any grammar that can be expressed using BNF can also be expressed using a Syntax Diagram although I think most would agree that  BNF is a better alternative for large grammars.

Railroad diagrams are pretty well-known indeed, but that would mean that 
there's probably a good, stable description for them somewhere, and that 
would mean that it would probably be a good idea for the spec to include 
a reference to said description.

> This whole issue of the use of Syntax Diagrams rather than BNF is a stylist debate that is hard to take seriously.

Except for the fact that (A)BNF is accessible to people with limited 
vision (unless it uses font differences too much), but railroad diagrams 
are not. And (A)BNF can be checked automatically, and text can be 
checked against (A)BNF automatically, but that doesn't work with 
railroad diagrams.

> If TC39 informed you that we are converting the notation used in ECMA-404 to a BNF formalism would that end the objections  to normatively referencing  ECMA-404 from 4627bis?  Unfortunately, I'm pretty sure it wouldn't.

I'm pretty sure of this, too.

This goes into a different pile of issues, but from my perspective of a 
simple participant on the IETF side, it's kind of surprising that first, 
the WG is started under the assumption that the spec(s) will be 
developed in parallel, and much later, the other side tells us to 
normatively reference their version, which some people say was produced 
in a hurry.

> Regarding, using of a multiply level definition within ECMA-404.  That is a standard practice within language specification where the "tokens" of a language are often described using a FSM level formalism and the syntactic structure is described using a PDA level formalism.  However, there is nothing that prevents a PDA level abstraction such as a BNF from being using to describe "tokens" even with the full power of a PDA isn't used.  The ECMA-262 specification is an example of a language specification that using a BNF to describe both its lexical and syntactic structure.

That's perfectly okay with me, and should be okay with the IETF in 
general, because we do the same thing with ABNF.

> In the case of ECMA-404, clause 4 is clearly defining the lexical level of the language (it is talking about "tokens") and it clearly states that numbers and strings are tokens. Hence there is no ambiguity about how to interpret the syntax diagrams for number and string in clauses 8 and 9.  None of the subelements of diagrams are "tokens" so there is no plausible way they could be misconstrued as generating or recognizing a sequence of tokens.

The only way in which "token" is relevant in ECMA-404 is with respect to 
whitespace. The definitive way in which to distinguish between terminals 
and non-terminals is that the former are round, and the later are boxes.

> The only normative purpose of the first paragraph in clause 8 (Numbers) is to identify the code points that  are symbolically referenced by the Syntax diagram. Everything else in that paragraph is either redundant (describe by the diagram) or pseudo-semantics that are outside the scope of what ECMA-404 defines.

Who says that the syntax diagram is normative and the text is (mostly) 
redundant, and not the other way round? I have not found any wording in 
ECMA-404 to that effect, but I might have overlooked something.

Also, my overall experience with standards would definitely start with 
the assumption that the text is normative, and the figures are 
illustrative. Sections 5, 6, and 7 would work okay that way. The fact 
that the text contains details that are not in the diagrams would also 
point that way. To have the reader infer the opposite based on the 
sloppyness of the wording in section 8 seems quite demanding.


> This is a common problem seen in many specification that try to clarify a formalism with supplementary prose and instead ends up sowing confusion.  If a bug was filed against this for ECMA-404 it will probably be cleaned up in the next edition. Note that the current 4627bis draft is very similar in this regard.  It talks about an "exponent part" with out defining that term. (it doesn't appear in the grammar).  It doesn't specify how to actually interpret a number token as a mathematical  value or how to generate one from a mathematical value.  It only says that JSON numbers  are  similar to those in most programming languages (which includes a very wide range of possibilities).

I agree this isn't the best part of the spec, and wouldn't mind fixing 
it. But at least "exponent part" isn't as broken as "exponent of 10". 
Also, the "wide range of possibilities" is in some ways intended (in 
that some actual implementations in the field convert all numbers to 
floats, whereas others convert to different types depending on the 
details of syntax and value).

On the other hand, if by "wide range of possibilities", you mean that 
there are many fundamentally different ways in which programming 
languages interpret a notation such as 1234.56E-78, then please provide 
examples.

> Specs. can have both technical and editorial bugs.  If you think there are bugs in ECMA-404 the best thing to do is to submit a bug ticket at bugs.ecmascript.org. If there is a critical bug that you think prevents 4627bis from normatively referencing ECMA-404 say so and assign the bug a high priority in the initial ticket.  But please, start with actual errors, ambiguities, inconsistencies, or similar substantive issue.  Stylistic issues won't be ignore but they are less important and harder to reach agreement on.

I'll submit some. What about the ECMA people submitting some bug reports 
on 4627bis in return?

Regards,   Martin.

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

From duerst@it.aoyama.ac.jp  Tue Dec 10 02:19:24 2013
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751D51AD944 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 02:19:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.392
X-Spam-Level: 
X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 XdboZJBd6IO7 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 02:19:17 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id E3E3B1ADF2F for <json@ietf.org>; Tue, 10 Dec 2013 02:19:00 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rBAAItnX014489; Tue, 10 Dec 2013 19:18:55 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 3366_aad0_7963afee_6184_11e3_a73e_001e6722eec2; Tue, 10 Dec 2013 19:18:55 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 64DBEBF4DE; Tue, 10 Dec 2013 19:18:54 +0900 (JST)
Message-ID: <52A6EA82.5030408@it.aoyama.ac.jp>
Date: Tue, 10 Dec 2013 19:18:42 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Carsten Bormann <cabo@tzi.org>
References: <7FD8497D-5E19-4EFE-B66E-538FC42B7478@nuance.com> <7895D7DA-E608-49DF-8984-FFC91AFDBF04@tzi.org>
In-Reply-To: <7895D7DA-E608-49DF-8984-FFC91AFDBF04@tzi.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] Fwd: two comments on JSON, ECMA-404, 1st edition / October 2013
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 10:19:24 -0000

On 2013/12/10 18:22, Carsten Bormann wrote:
> FYI for those who haven=E2=80=99t surrendered into subscribing to es-di=
scuss yet:

I just get the rejection messages. I didn't get any information about=20
how to subscribe, or any invitation, nor any information that this is=20
the open mailing list that some earlier contribution on this mailing=20
list has alluded to.

Also, I fear that guessing from the name, it's a mailing list discussing=20
all of ECMAScript. Although I think that's a very interesting subject, I=20
don't think I have the bandwidth to subscribe to it just for following=20
JSON-related issues.

But maybe there's a public archive? A pointer would be appreciated.

Regards,   Martin.

> Begin forwarded message:
>
>> From: "Patel-Schneider, Peter"<Peter.Patel-Schneider@nuance.com>
>> Subject: two comments on JSON, ECMA-404, 1st edition / October 2013
>> Date: 10 Dec 2013 06:00:34 +0100
>> To: "es-discuss@mozilla.org"<es-discuss@mozilla.org>
>>
>> 1/ According to ECMA-404, 1st edition / October 2013, a JSON text is a=
 sequence
>> of Unicode code points.   The code points that can appear in a JSON te=
xt
>> include all code point except the control characters (the text says U+=
0000
>> to U+001F but the syntax diagram just says control character, which in
>> Unicode 6.3 also includes U+007F to U+009F).  Therefore, the code
>> point sequence<0022, DEAD, 0022>  is a valid JSON text.
>>
>> However, this code point sequence cannot be represented in UTF-8, UTF-=
16, or
>> UTF-32, as it is not a sequence of Unicode scalar values, and
>> Unicode encoding forms are only defined on Unicode scalar values.
>>
>>
>> 2/ The unescaping of strings in JSON is ill-defined as there are quote=
d
>> JSON strings that are the escaped version of two different sequences o=
f
>> Unicode code points.  For example both<D834, DD1E>  and<1D11E>  can be
>> represented as "\uD834\uDD1E".
>>
>>
>> Both of these appear to be bugs that should be fixed.
>>
>> Peter F. Patel-Schneider
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>

From cabo@tzi.org  Tue Dec 10 02:32:34 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791141ACCE7 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 02:32:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Level: 
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001] autolearn=ham
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 ozG5hE8d-Hih for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 02:32:32 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9869F1AC403 for <json@ietf.org>; Tue, 10 Dec 2013 02:32:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBAAWKQN024374; Tue, 10 Dec 2013 11:32:20 +0100 (CET)
Received: from [192.168.217.105] (p54892614.dip0.t-ipconnect.de [84.137.38.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9C2F2298; Tue, 10 Dec 2013 11:32:19 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <52A6EA82.5030408@it.aoyama.ac.jp>
Date: Tue, 10 Dec 2013 11:32:17 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <035D367A-323E-4799-AB6B-B83CC2E8DBF4@tzi.org>
References: <7FD8497D-5E19-4EFE-B66E-538FC42B7478@nuance.com> <7895D7DA-E608-49DF-8984-FFC91AFDBF04@tzi.org> <52A6EA82.5030408@it.aoyama.ac.jp>
To: =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] Fwd: two comments on JSON, ECMA-404, 1st edition / October 2013
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 10:32:34 -0000

On 10 Dec 2013, at 11:18, Martin J. D=FCrst <duerst@it.aoyama.ac.jp> =
wrote:

> On 2013/12/10 18:22, Carsten Bormann wrote:
>> FYI for those who haven=92t surrendered into subscribing to =
es-discuss yet:
>=20
> I just get the rejection messages. I didn't get any information about =
how to subscribe, or any invitation, nor any information that this is =
the open mailing list that some earlier contribution on this mailing =
list has alluded to.

I found it:
https://mail.mozilla.org/listinfo/es-discuss

> Also, I fear that guessing from the name, it's a mailing list =
discussing all of ECMAScript.

Yes. I feel twenty years younger already :-)

> Although I think that's a very interesting subject, I don't think I =
have the bandwidth to subscribe to it just for following JSON-related =
issues.

You need a good mail reader.

> But maybe there's a public archive? A pointer would be appreciated.

https://mail.mozilla.org/pipermail/es-discuss/

Gr=FC=DFe, Carsten


From petejson@codalogic.com  Tue Dec 10 02:34:27 2013
Return-Path: <petejson@codalogic.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61981AD8F4 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 02:34:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.597
X-Spam-Level: **
X-Spam-Status: No, score=2.597 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 IOqE03hzZv1P for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 02:34:26 -0800 (PST)
Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 991FD1AC403 for <json@ietf.org>; Tue, 10 Dec 2013 02:34:25 -0800 (PST)
Received: (qmail 10304 invoked from network); 10 Dec 2013 10:33:57 +0000
Received: from host86-169-210-69.range86-169.btcentralplus.com (HELO codalogic) (86.169.210.69) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 10 Dec 2013 10:33:57 +0000
Message-ID: <7D348EC2A6DB48CBAD89BBABDD114EBD@codalogic>
From: "Pete Cordell" <petejson@codalogic.com>
To: =?iso-8859-1?Q?=22Martin_J._D=FCrst=22?= <duerst@it.aoyama.ac.jp>, "Allen Wirfs-Brock" <allen@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp> <E19BDE18-DA46-4C00-AA6C-205C348326AD@tzi.org> <52A59337.4050609@it.aoyama.ac.jp> <2AA6AE6A-C76D-4B61-BFE1-0EBDFB715D6D@tzi.org> <8E4C7969-7868-4DE9-A9B0-C7FD484075B1@wirfs-brock.com> <52A6E807.9050103@it.aoyama.ac.jp>
X-Unsent: 1
Date: Tue, 10 Dec 2013 10:35:10 -0000
MIME-Version: 1.0
x-vipre-scanned: 005F6BFA005E8C005F6D47
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Cc: Carsten Bormann <cabo@tzi.org>, JSON WG <json@ietf.org>, es-discuss@mozilla.org
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 10:34:27 -0000

Original Message From: ""Martin J. Dürst""
> On 2013/12/10 9:32, Allen Wirfs-Brock wrote:
>> This whole issue of the use of Syntax Diagrams rather than BNF is a 
>> stylist debate that is hard to take seriously.
>
> Except for the fact that (A)BNF is accessible to people with limited 
> vision (unless it uses font differences too much), but railroad diagrams 
> are not. And (A)BNF can be checked automatically, and text can be checked 
> against (A)BNF automatically, but that doesn't work with railroad 
> diagrams.


And ABNF can be cut and pasted into code to aid implementation, and removes 
an unnecessary, often error prone, implementation step.  So it's a very 
practical issue, not just one of style.

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


From jjc@jclark.com  Tue Dec 10 03:40:15 2013
Return-Path: <jjc@jclark.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B081ADFCA for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 03:40:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 qkSvzU4bglg9 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 03:40:13 -0800 (PST)
Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 773D61ADFC9 for <json@ietf.org>; Tue, 10 Dec 2013 03:40:13 -0800 (PST)
Received: by mail-ve0-f176.google.com with SMTP id oz11so4709938veb.35 for <json@ietf.org>; Tue, 10 Dec 2013 03:40:08 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=q+nGWWhQL41Qwb8bcBFaBsOeWFO459HOcOlvN+hZ/BQ=; b=grqRgZIRV41tey/GqNsa9E8R7a+n1XJSeWtYTEUzYRvA/jYWwc/ah0BreRWQGsCjFC cQIDPlBH3u0yYHLf/5HQdE21nlmZzeHPi/LGNti7IQW5yH64xc6KYU9/gYjyHJKlk6Bw Unekdm4RRgU+QAchVF1LBA3UEtHPhPruGqvtVOtITB8UTpJLrqWQOFYq2AxTMRXHNqo8 hCRgH4qLl0OPeI4iHl3WUSC9M4XaKQNBihJtM14ib5EffOaEWlqbH7+r7y2bCKpAmmTP l4ldzcmGTvs38iCaTryhMCqlwDhCXVweRRY+cHkEV+n9T9WqdM9CkCblIdRTlcOMG61b o0Yg==
X-Gm-Message-State: ALoCoQkK+gYF6dZnirz2dbeuVuWQV1ipTKgsJIUaTtb2SOsYGpcHXJvsPMMswYK7EYxypNwaYj/U
X-Received: by 10.58.46.18 with SMTP id r18mr13386427vem.4.1386675608045; Tue, 10 Dec 2013 03:40:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.164.231 with HTTP; Tue, 10 Dec 2013 03:39:47 -0800 (PST)
In-Reply-To: <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org>
From: James Clark <jjc@jclark.com>
Date: Tue, 10 Dec 2013 18:39:47 +0700
Message-ID: <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Content-Type: multipart/alternative; boundary=089e0129448209626204ed2c93d7
Cc: JSON WG <json@ietf.org>, Allen Wirfs-Brock <allen@wirfs-brock.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 11:40:15 -0000

--089e0129448209626204ed2c93d7
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 10, 2013 at 4:12 PM, Carsten Bormann <cabo@tzi.org> wrote:

So a JSON infoset would capture a processed AST, but not yet the
> transformation to the data model level.
>
> JSON implementations would create the JSON data model from that infoset
> (typically without actually reifying the latter as an AST), and JSON
> extensions like ECMAscript's would be free to do whatever they want.
> It is just important to distinguish the two, so people don=92t confuse th=
e
> data model with the infoset, or think that a JSON implementation needs to
> provide access to the infoset.


I agree it would reduce confusion to use a different term for the infoset
versus the data model. "Infoset"/"data model" is one possible choice of
terms, though I wonder whether the XML heritage of "infoset" might be off
putting to many.  Another possibility would be "abstract data
model"/"concrete data model".


> I=92d argue that you want to reduce toward the denominator being the mini=
mal
> power of ten, i.e.
> 1 is [1, 1]
> 1.0 is [1, 1]
> 1.5 is [15, 10]
>

That would be my preference too.

The only thing that makes me hesitate is that I could imagine
implementations that distinguish integers and floats, and use C-style rules
to distinguish the two. For example, 1 is an integer but 1.0 or 1e0 is a
float. I don't know whether any such implementations exist.

James

--089e0129448209626204ed2c93d7
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Dec 10, 2013 at 4:12 PM, Carsten Bormann <span dir=3D"ltr">&lt;<a href=
=3D"mailto:cabo@tzi.org" target=3D"_blank">cabo@tzi.org</a>&gt;</span> wrot=
e:</div><div class=3D"gmail_quote">


<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><span style=3D"font-f=
amily:arial,sans-serif;font-size:13px">So a JSON infoset would capture a pr=
ocessed AST, but not yet the transformation to the data model level.</span>=
<br style=3D"font-family:arial,sans-serif;font-size:13px">


<br style=3D"font-family:arial,sans-serif;font-size:13px"><span style=3D"fo=
nt-family:arial,sans-serif;font-size:13px">JSON implementations would creat=
e the JSON data model from that infoset (typically without actually reifyin=
g the latter as an AST), and JSON extensions like ECMAscript&#39;s would be=
 free to do whatever they want.</span><br style=3D"font-family:arial,sans-s=
erif;font-size:13px">


<span style=3D"font-family:arial,sans-serif;font-size:13px">It is just impo=
rtant to distinguish the two, so people don=92t confuse the data model with=
 the infoset, or think that a JSON implementation needs to provide access t=
o the infoset.</span></blockquote>


<div><br></div><div>I agree it would reduce confusion to use a different te=
rm for the infoset versus the data model. &quot;Infoset&quot;/&quot;data mo=
del&quot; is one possible choice of terms, though I wonder whether the XML =
heritage of &quot;infoset&quot; might be off putting to many. =A0Another po=
ssibility would be &quot;abstract data model&quot;/&quot;concrete data mode=
l&quot;.</div>


<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">
I=92d argue that you want to reduce toward the denominator being the minima=
l power of ten, i.e.<br>
1 is [1, 1]<br>
1.0 is [1, 1]<br>
1.5 is [15, 10]<br></blockquote><div><br></div><div>That would be my prefer=
ence too.</div><div><br></div><div>The only thing that makes me hesitate is=
 that I could imagine implementations that distinguish integers and floats,=
 and use C-style rules to distinguish the two. For example, 1 is an integer=
 but 1.0 or 1e0 is a float. I don&#39;t know whether any such implementatio=
ns exist.</div>


<div><br></div><div>James</div><div><br></div><div><br></div><div>=A0</div>=
</div></div></div>

--089e0129448209626204ed2c93d7--

From cabo@tzi.org  Tue Dec 10 03:41:48 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076D41ADDD2 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 03:41:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 anDbRYZcPkN7 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 03:41:47 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id BFAC51AC7F0 for <json@ietf.org>; Tue, 10 Dec 2013 03:41:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBABfUnr015392; Tue, 10 Dec 2013 12:41:30 +0100 (CET)
Received: from [192.168.217.105] (p54892614.dip0.t-ipconnect.de [84.137.38.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5AA6E33F; Tue, 10 Dec 2013 12:41:29 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com>
Date: Tue, 10 Dec 2013 12:41:27 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6B43CA50-6C39-4663-AADC-42830E1AC93C@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com>
To: James Clark <jjc@jclark.com>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>, Allen Wirfs-Brock <allen@wirfs-brock.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 11:41:48 -0000

On 10 Dec 2013, at 07:52, James Clark <jjc@jclark.com> wrote:

> Most users of XML deal with higher-level semantic abstractions rather =
than directly with the XML Infoset, but it has proven very useful to be =
able to specify these higher-level semantic abstractions in terms of the =
XML Infoset rather than having to specify them directly in terms of the =
XML syntax.=20

The XML infoset is very much tied to the needs (and idiosyncrasies) of =
the serialization that XML uses.  There are many ways this infoset is =
mapped into the data model used by an XML-based application.

The main innovation of JSON was to actually supply such a data model as =
part of the format.
I would argue that his property was what made JSON =93win=94 over XML.

Turning back the clock and trying to use JSON as a conveyer of an =
infoset instead of using it with its data model could be considered =
unproductive.  On the other hand, some people want to do alternative =
data models with the JSON syntax, so maybe standardization has to cater =
for that.

One of the reasons many people react so violently to such a proposal is =
that it is bound to cause confusion that these alternative data models =
are now also =93JSON data models=94, reducing the value of the JSON data =
model as the hingepin of interoperability.

I don=92t know how to counteract that confusion while also enabling the =
use of alternative data models by the definition of the infoset.  But =
maybe we can find a way.

Gr=FC=DFe, Carsten


From cabo@tzi.org  Tue Dec 10 03:52:17 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256D41ADBCB for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 03:52:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 yWyIrOQQBfmW for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 03:52:16 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A9D4C1ADFBA for <json@ietf.org>; Tue, 10 Dec 2013 03:52:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBABpsYf006400; Tue, 10 Dec 2013 12:51:54 +0100 (CET)
Received: from [192.168.217.105] (p54892614.dip0.t-ipconnect.de [84.137.38.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2FD54354; Tue, 10 Dec 2013 12:51:53 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com>
Date: Tue, 10 Dec 2013 12:51:51 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0FF5AD3A-75AD-40FF-8478-E79CCFE7D6C3@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com>
To: James Clark <jjc@jclark.com>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>, Allen Wirfs-Brock <allen@wirfs-brock.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 11:52:17 -0000

On 10 Dec 2013, at 12:39, James Clark <jjc@jclark.com> wrote:

> The only thing that makes me hesitate is that I could imagine =
implementations that distinguish integers and floats, and use C-style =
rules to distinguish the two. For example, 1 is an integer but 1.0 or =
1e0 is a float. I don't know whether any such implementations exist.

Absolutely, they do, and they all differ in how exactly they do the =
distinction.
http://www.ietf.org/mail-archive/web/json/current/msg01523.html

This is a cause of real interoperability problems.

The question is how to find out of that maze of different =
interpretations.
There is no way this can be done so that none of them =93breaks=94.=20

It may seem natural to stick to the way numbers are interpreted in many =
programming languages that distinguish floating point values from =
integer values.  However, JavaScript doesn=92t so it can=92t supply =
guidance.  And that leads to exactly the problem documented in
https://jira.talendforge.org/browse/TDI-26517 =97 interoperability =
broken when a non-distinguishing sender accidentally chooses the =
representation that triggers the wrong behavior at the receiver.

It is probably better to suggest handling 1.0 as 1.

When we are done with that, there is still negative zero.
http://www.ietf.org/mail-archive/web/json/current/msg01661.html

Gr=FC=DFe, Carsten


From lhotka@nic.cz  Tue Dec 10 03:59:36 2013
Return-Path: <lhotka@nic.cz>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522601ADFDF for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 03:59:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.652
X-Spam-Level: 
X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=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 O4nRb-3TF8XU for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 03:59:34 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B51E21ADF5E for <json@ietf.org>; Tue, 10 Dec 2013 03:59:34 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id BDE6B13F98D; Tue, 10 Dec 2013 12:59:28 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1386676769; bh=rxG0PIxdVypa6+H+4i+W+6CWvy35PWoDidm6PGySerw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Vlkfv0L4cemdrDXC8uTXjKksC870PCXpUIVFdznMnDdgd5aW6Uus4+8vX/HdcpAYK Q81VxuiaIOrzCw8IwxNVPMT0eQ8bYF+T7+hQFoTtLLbEd2fUyE1erwhke7RF+gRz35 NdSbulPghTr9kmpJCoCATERFqteOaH5m7OG57SIM=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com>
Date: Tue, 10 Dec 2013 12:59:27 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com>
To: James Clark <jjc@jclark.com>
X-Mailer: Apple Mail (2.1822)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, Carsten Bormann <cabo@tzi.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 11:59:36 -0000

On 10 Dec 2013, at 12:39, James Clark <jjc@jclark.com> wrote:

> On Tue, Dec 10, 2013 at 4:12 PM, Carsten Bormann <cabo@tzi.org> wrote:
>=20
> So a JSON infoset would capture a processed AST, but not yet the =
transformation to the data model level.
>=20
> JSON implementations would create the JSON data model from that =
infoset (typically without actually reifying the latter as an AST), and =
JSON extensions like ECMAscript's would be free to do whatever they =
want.
> It is just important to distinguish the two, so people don=92t confuse =
the data model with the infoset, or think that a JSON implementation =
needs to provide access to the infoset.
>=20
> I agree it would reduce confusion to use a different term for the =
infoset versus the data model. "Infoset"/"data model" is one possible =
choice of terms, though I wonder whether the XML heritage of "infoset" =
might be off putting to many.  Another possibility would be "abstract =
data model"/"concrete data model=94.

How about =93information model=94/=93data model=94 (cf. RFC 3444)?

Lada

> =20
> I=92d argue that you want to reduce toward the denominator being the =
minimal power of ten, i.e.
> 1 is [1, 1]
> 1.0 is [1, 1]
> 1.5 is [15, 10]
>=20
> That would be my preference too.
>=20
> The only thing that makes me hesitate is that I could imagine =
implementations that distinguish integers and floats, and use C-style =
rules to distinguish the two. For example, 1 is an integer but 1.0 or =
1e0 is a float. I don't know whether any such implementations exist.
>=20
> James
>=20
>=20
> =20
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From cabo@tzi.org  Tue Dec 10 04:06:51 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A6D1AE002 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 04:06:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 DVI7shinhDW5 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 04:06:49 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEA41ADDBD for <json@ietf.org>; Tue, 10 Dec 2013 04:06:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBAC6YMc005415; Tue, 10 Dec 2013 13:06:34 +0100 (CET)
Received: from [192.168.217.105] (p54892614.dip0.t-ipconnect.de [84.137.38.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5013137B; Tue, 10 Dec 2013 13:06:33 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz>
Date: Tue, 10 Dec 2013 13:06:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz>
To: Ladislav Lhotka <lhotka@nic.cz>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>, Allen Wirfs-Brock <allen@wirfs-brock.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, James Clark <jjc@jclark.com>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 12:06:51 -0000

On 10 Dec 2013, at 12:59, Ladislav Lhotka <lhotka@nic.cz> wrote:

> How about =93information model=94/=93data model=94 (cf. RFC 3444)?

Well, the information model is the more abstract one, so in this =
dichotomy today=92s data model would become the information model and =
the infoset would become the data model.  Ouch.

Maybe we can find those terms later instead of muddling our current =
discussion with the search for terms.  We know exactly what infoset and =
data model mean in this context, so let=92s continue to use these terms =
until some stroke of genius supplies us with better ones.

Gr=FC=DFe, Carsten


From jjc@jclark.com  Mon Dec  9 22:52:40 2013
Return-Path: <jjc@jclark.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790FE1AE04D for <json@ietfa.amsl.com>; Mon,  9 Dec 2013 22:52:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 tdRPfhNyESnB for <json@ietfa.amsl.com>; Mon,  9 Dec 2013 22:52:36 -0800 (PST)
Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 873261AD8D8 for <json@ietf.org>; Mon,  9 Dec 2013 22:52:36 -0800 (PST)
Received: by mail-ve0-f182.google.com with SMTP id jy13so4459253veb.41 for <json@ietf.org>; Mon, 09 Dec 2013 22:52:31 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=lb3jC075iNGrISxb5dQ9loAXEt3MxK3o/REca0BRB0c=; b=iD9Uh8YKpREaiNGPax6Y95GBduDx3esphiUTl2Sz3abTX6rvPoUNThIMKTVq7Bi6hb 0dhXQFey3z9X6bQ876N1o9clT7NcAZC843Ml39b7MjYTcid42Rb4nn5VP9KcDpcSerem uk7of9Qv2ZzPoSoOIb1XomrM7BkNkl9MBKZ+Cfn5jBjogaVs2FvSb5ibqHm8d1x4wvyD 9xWERAOEqT5Qir8Sh3/Zyx2OfwMHH/FxH+ZlbcGuDWyOHiJVrPkN/TwiWXTv/DXJxubH d3qY5dCbxnOcoodqqjCb6jyMTdnBU/fkopVFzz/lsLDuVl+txsofr6UiWuQ12faBXRXA fPZQ==
X-Gm-Message-State: ALoCoQnLGwXFAsxxZQIRzMR7QRDhO9dCym18kOpfJyBAqYqJFMm5MMWom80guDH7zKAVaeIGIIKw
X-Received: by 10.52.120.81 with SMTP id la17mr80245vdb.44.1386658351098; Mon, 09 Dec 2013 22:52:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.164.231 with HTTP; Mon, 9 Dec 2013 22:52:10 -0800 (PST)
In-Reply-To: <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com>
From: James Clark <jjc@jclark.com>
Date: Tue, 10 Dec 2013 13:52:10 +0700
Message-ID: <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Content-Type: multipart/alternative; boundary=089e013a1b9a71455104ed288ea8
X-Mailman-Approved-At: Tue, 10 Dec 2013 07:34:49 -0800
Cc: JSON WG <json@ietf.org>, Carsten Bormann <cabo@tzi.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 06:53:58 -0000

--089e013a1b9a71455104ed288ea8
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Dec 6, 2013 at 2:51 AM, Allen Wirfs-Brock <allen@wirfs-brock.com>wrote:

>
> The static semantics of a language are a set of rules that further
> restrict  which sequences of symbols form valid statements within the
> language.  For example, a rule that the 'member' names must be disjoint
> within an 'object' production could be a static semantic rule (however,
> there is intentionally no such rule in ECMA-404).
>
> The line between syntax and static semantics can be fuzzy.  Static
> semantic rules are typically used to express rules that cannot be
> technically expressed using the chosen syntactic formalism or rules which
> are simply inconvenient to express using that formalism.  For example, the
> editor of ECMA-404 chose to simplify the RR track expression of the JSON
> syntax by using static semantic rules for whitespace rather than
> incorporating them into RR diagrams.
>
> Another form of static semantic rules are equivalences that state when two
> or more different sequences of symbols must be considered as equivalent.
>  For example, the rules that state equivalencies between escape sequences
> and individual code points within an JSON 'string'.  Such equivalences are
> not strictly necessary at this level, but it it simplifies the
> specification of higher level semantics if equivalent symbol sequences can
> be normalized at this level of specification.
>


When we talk about the "semantics" of a language (rather than "static
> semantics") we are talking about attributing meaning (in some domain and
> context) to well-formed (as specified via syntax and static semantics)
> statements expressed in that language.
>
...

> What we can do, is draw a bright-line just above the level of static
> semantics.This is what ECMA-404 attempts to do.


I don't see how you can accommodate the second kind of static semantic rule
within the definition of conformance that you have chosen for ECMA-404.
Section 2 defines conformance in terms of whether a sequence of Unicode
code points conforms to the grammar.  This doesn't even accommodate the
first kind of static semantic rule, but it is obviously easy to extend it
so that it does.  However, to accommodate the second kind of static
semantic rule, you would need a notion of conformance that deals with how
conforming parsers interpret a valid sequence of code points.

I think it is coherent to draw a bright-line just above the first level of
static semantics.  If you did that, then most of the prose of section 9 (on
Strings) would have to be removed; but this would be rather inconvenient,
because most specifications of higher-level semantics would end up having
to specify it themselves.

However, I find it hard to see any bright-line above the second level of
static semantics and below semantics generally.  Let's consider section 9.
I would argue that this section should define a "semantics" for string
tokens, by defining a mapping from sequences of code points matching the
production _string_ (what I would call the "lexical space") into arbitrary
sequences of code points (what I would call the "value space"). The spec
sometimes seems to be doing this and sometimes seems to be doing something
more like your second kind of static semantics. Sometimes it uses the term
"code point" or "character" to refer to code points in the lexical space
("A string is a sequence of Unicode code points wrapped with quotation
marks"), and sometimes it uses those terms to refer to code points in the
value space ("Any code point may be represented as a hexadecimal number").
  You could redraft so that it was expressed purely in terms of code points
in the lexical space, but that would be awkward and unnatural: for example,
an hexadecimal escape would represent either one or two code points in the
lexical space.  Furthermore I don't see what you would gain by this.  Once
you talk about equivalences between sequences, you are into semantics and
you need a richer notion of conformance.

So back to "semantics" and why ECMA-404 tries (perhaps imperfectly) to
> avoid describing JSON beyond the level of static semantics.
>
> ECMA-404 see JSON as "a text format that facilitates structured data
> interchange between all programming languages. JSON
> is syntax of braces, brackets, colons, and commas that is useful in many
> contexts, profiles, and applications".
>
> There are many possible semantics and categories of semantics that can be
> applied to well-formed statements expressed using the JSON syntax.
>
...

>
> The problem with trying to standardize JSON semantics is that the various
> semantics that can be usefully be imposed upon JSON are often mutually
> incompatible with each other. At a trivial level, we see this with issues
> like the size of numbers or duplicate object member keys.  It is very hard
> to decide whose semantics are acceptable and whose is not.
>

I would argue that ECMA-404 should define the least restrictive reasonable
semantics: the semantics should not treat as identical any values that
higher layers might reasonably want to treat as distinct.  This is not the
one, true JSON semantics: it is merely a semantic layer on which other
higher-level semantic layers can in turn be built.  I don't think it's so
hard to define this:

1. a value is an object, array, number, string, boolean or null.
2. an object is an ordered sequence of <string, value> pairs
3. an array is an ordered sequence of values
4. a string is an ordered sequence of Unicode code points

Item 2 maybe surprising to some people, but there's not really much choice
given that JS preserves the order of object keys.  The difficult case is
number. But even with number, I would argue that there are clearly some
lexical values that can uncontroversially be specified to be equivalent
(for example, 1e1 with 1E1 or 1e1 with 1e+1).  A set of decisions on
lexical equivalence effectively determines a value space for numbers.  For
example, you might reasonably decide that two values are equivalent if they
represent real numbers with the same mathematical value.

If ECMA-404 doesn't provide such a semantic layer, it becomes quite
challenging for higher-level language bindings to specify their semantics
in a truly rigorous way.  Take strings for example.  I think by far the
cleanest way to rigorously define a mapping from string tokens to sequences
of code points is to have a BNF and a syntax-directed mapping as the
ECMAScript spec does very nicely in 7.8.4 (
http://www.ecma-international.org/ecma-262/5.1/#sec-7.8.4).  If ECMA-404
provides merely a syntax and a specification of string equivalence, it
becomes quite a challenge to draft a specification that somehow expresses
the mapping while still normatively relying on the ECMA-404 spec for the
syntax. What will happen in practice is that these higher level mapping
will not be specified rigorously.

I think ECMA-404 would be significantly more useful for its intended
purpose if it provided the kind of semantics I am suggesting.

I know XML is not very fashionable these days but we have a couple of
decades of experience with XML and SGML which I think do have some
relevance to a specification of "structured data interchange between
programming language".   One conclusion I would draw from this experience
is that the concept of an XML Infoset or something like it is very useful.
 Most users of XML deal with higher-level semantic abstractions rather than
directly with the XML Infoset, but it has proven very useful to be able to
specify these higher-level semantic abstractions in terms of the XML
Infoset rather than having to specify them directly in terms of the XML
syntax.  Another conclusion I would draw is that it would have worked much
better to integrate the XML Infoset specification into the main XML
specification.  The approach of having a separate XML Infoset specification
has meant that there is no proper rigorous specification how to map from
the XML syntax to the XML Infoset (it seems to be assumed to be so obvious
that it does not need stating).  I tried an integrated approach of
specifying the syntax and data model together in the MicroXML spec (
https://dvcs.w3.org/hg/microxml/raw-file/tip/spec/microxml.html), and I
think it works much better. The current approach of ECMA-404 is a bit like
that of the XML Recommendation: it pretends at times to be just specifying
when a sequence of code points is valid, and yet the specification contains
a fairly random selection of statements of how a valid sequence should be
interpreted.

James

--089e013a1b9a71455104ed288ea8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Dec 6, 2013 at 2:51 AM, Allen Wirfs-Brock <span dir=3D"ltr">&lt;<a href=
=3D"mailto:allen@wirfs-brock.com" target=3D"_blank">allen@wirfs-brock.com</=
a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div style=3D"word-wrap:break-word"><br><div><div>The stat=
ic semantics of a language are a set of rules that further restrict =A0whic=
h sequences of symbols form valid statements within the language. =A0For ex=
ample, a rule that the &#39;member&#39; names must be disjoint within an &#=
39;object&#39; production could be a static semantic rule (however, there i=
s intentionally no such rule in ECMA-404).<br>


</div><div><br></div><div>The line between syntax and static semantics can =
be fuzzy. =A0Static semantic rules are typically used to express rules that=
 cannot be technically expressed using the chosen syntactic formalism or ru=
les which are simply inconvenient to express using that formalism. =A0For e=
xample, the editor of ECMA-404 chose to simplify the RR track expression of=
 the JSON syntax by using static semantic rules for whitespace rather than =
incorporating them into RR diagrams.=A0</div>


<div><br></div><div>Another form of static semantic rules are equivalences =
that state when two or more different sequences of symbols must be consider=
ed as equivalent. =A0For example, the rules that state equivalencies betwee=
n escape sequences and individual code points within an JSON &#39;string&#3=
9;. =A0Such equivalences are not strictly necessary at this level, but it i=
t simplifies the specification of higher level semantics if equivalent symb=
ol sequences can be normalized at this level of specification.</div>


</div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex">=A0=A0</blockquote><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e=
x">


<div style=3D"word-wrap:break-word"><div><div>When we talk about the &quot;=
semantics&quot; of a language (rather than &quot;static semantics&quot;) we=
 are talking about attributing meaning (in some domain and context) to well=
-formed (as specified via syntax and static semantics) statements expressed=
 in that language.=A0</div>


</div></div></blockquote><div>...=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style=3D"f=
ont-family:sans-serif;font-size:13px">What we can do, is draw a bright-line=
 just above the level of static semantics.This is what ECMA-404 attempts to=
 do.</span>=A0</blockquote>


<div><br></div><div>I don&#39;t see how you can accommodate the second kind=
 of static semantic rule within the definition of conformance that you have=
 chosen for ECMA-404. Section 2 defines conformance in terms of whether a s=
equence of Unicode code points conforms to the grammar. =A0This doesn&#39;t=
 even accommodate the first kind of static semantic rule, but it is obvious=
ly easy to extend it so that it does. =A0However, to accommodate the second=
 kind of static semantic rule, you would need a notion of conformance that =
deals with how conforming parsers interpret a valid sequence of code points=
.</div>


<div><br></div><div>I think it is coherent to draw a bright-line just above=
 the first level of static semantics. =A0If you did that, then most of the =
prose of section 9 (on Strings) would have to be removed; but this would be=
 rather inconvenient, because most specifications of higher-level semantics=
 would end up having to specify it themselves.</div>


<div><br></div><div>However, I find it hard to see any bright-line above th=
e second level of static semantics and below semantics generally. =A0Let&#3=
9;s consider section 9. I would argue that this section should define a &qu=
ot;semantics&quot; for string tokens, by defining a mapping from sequences =
of code points matching the production _string_ (what I would call the &quo=
t;lexical space&quot;) into arbitrary sequences of code points (what I woul=
d call the &quot;value space&quot;). The spec sometimes seems to be doing t=
his and sometimes seems to be doing something more like your second kind of=
 static semantics. Sometimes it uses the term &quot;code point&quot; or &qu=
ot;character&quot; to refer to code points in the lexical space (&quot;A st=
ring is a sequence of Unicode code points wrapped with quotation marks&quot=
;), and sometimes it uses those terms to refer to code points in the value =
space (&quot;Any code point may be represented as a hexadecimal number&quot=
;). =A0 You could redraft so that it was expressed purely in terms of code =
points in the lexical space, but that would be awkward and unnatural: for e=
xample, an hexadecimal escape would represent either one or two code points=
 in the lexical space. =A0Furthermore I don&#39;t see what you would gain b=
y this. =A0Once you talk about equivalences between sequences, you are into=
 semantics and you need a richer notion of conformance.</div>


<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div><d=
iv>


So back to &quot;semantics&quot; and why ECMA-404 tries (perhaps imperfectl=
y) to avoid describing JSON beyond the level of static semantics.=A0</div><=
div><br></div><div>ECMA-404 see JSON as &quot;<span style=3D"font-family:sa=
ns-serif;font-size:13px">a text format that facilitates structured data int=
ercha</span><span style=3D"font-family:sans-serif;font-size:13px">nge betwe=
en all programming languages. JSON</span></div>


<div dir=3D"ltr" style=3D"font-size:13.28px;font-family:sans-serif">is synt=
ax of braces, brackets, colons, and commas that is useful in many contexts,=
 profiles, and applications&quot;.</div><div dir=3D"ltr" style=3D"font-size=
:13.28px;font-family:sans-serif">


<br></div><div dir=3D"ltr" style=3D"font-size:13.28px;font-family:sans-seri=
f">There are many possible semantics and categories of semantics that can b=
e applied to well-formed statements expressed using the JSON syntax.</div>

</div>
</div></blockquote><div>...</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><div style=3D"word-wrap:b=
reak-word">


<div dir=3D"ltr" style=3D"font-size:13.28px;font-family:sans-serif"><br></d=
iv><div dir=3D"ltr" style=3D"font-size:13.28px;font-family:sans-serif">The =
problem with trying to standardize JSON semantics is that the various seman=
tics that can be usefully be imposed upon JSON are often mutually incompati=
ble with each other. At a trivial level, we see this with issues like the s=
ize of numbers or duplicate object member keys. =A0It is very hard to decid=
e whose semantics are acceptable and whose is not.</div>


</div></blockquote><div><br></div><div>I would argue that ECMA-404 should d=
efine the least restrictive reasonable semantics: the semantics should not =
treat as identical any values that higher layers might reasonably want to t=
reat as distinct. =A0This is not the one, true JSON semantics: it is merely=
 a semantic layer on which other higher-level semantic layers can in turn b=
e built. =A0I don&#39;t think it&#39;s so hard to define this:</div>


<div><br></div><div>1. a value is an object, array, number, string, boolean=
 or null.</div><div>2. an object is an ordered sequence of &lt;string, valu=
e&gt; pairs</div><div>3. an array is an ordered sequence of values</div>


<div>4. a string is an ordered sequence of Unicode code points</div><div><b=
r></div><div>Item 2 maybe surprising to some people, but there&#39;s not re=
ally much choice given that JS preserves the order of object keys. =A0The d=
ifficult case is number. But even with number, I would argue that there are=
 clearly some lexical values that can uncontroversially be specified to be =
equivalent (for example, 1e1 with 1E1 or 1e1 with 1e+1). =A0A set of decisi=
ons on lexical equivalence effectively determines a value space for numbers=
. =A0For example, you might reasonably decide that two values are equivalen=
t if they represent real numbers with the same mathematical value.</div>


<div><br></div><div>If ECMA-404 doesn&#39;t provide such a semantic layer, =
it becomes quite challenging for higher-level language bindings to specify =
their semantics in a truly rigorous way. =A0Take strings for example. =A0I =
think by far the cleanest way to rigorously define a mapping from string to=
kens to sequences of code points is to have a BNF and a syntax-directed map=
ping as the ECMAScript spec does very nicely in 7.8.4 (<a href=3D"http://ww=
w.ecma-international.org/ecma-262/5.1/#sec-7.8.4" target=3D"_blank">http://=
www.ecma-international.org/ecma-262/5.1/#sec-7.8.4</a>). =A0If ECMA-404 pro=
vides merely a syntax and a specification of string equivalence, it becomes=
 quite a challenge to draft a specification that somehow expresses the mapp=
ing while still normatively relying on the ECMA-404 spec for the syntax. Wh=
at will happen in practice is that these higher level mapping will not be s=
pecified rigorously.</div>


<div><br></div><div>I think ECMA-404 would be significantly more useful for=
 its intended purpose if it provided the kind of semantics I am suggesting.=
</div><div><br></div><div>I know XML is not very fashionable these days but=
 we have a couple of decades of experience with XML and SGML which I think =
do have some relevance to a specification of &quot;structured data intercha=
nge between programming language&quot;. =A0 One conclusion I would draw fro=
m this experience is that the concept of an XML Infoset or something like i=
t is very useful. =A0Most users of XML deal with higher-level semantic abst=
ractions rather than directly with the XML Infoset, but it has proven very =
useful to be able to specify these higher-level semantic abstractions in te=
rms of the XML Infoset rather than having to specify them directly in terms=
 of the XML syntax. =A0Another conclusion I would draw is that it would hav=
e worked much better to integrate the XML Infoset specification into the ma=
in XML specification. =A0The approach of having a separate XML Infoset spec=
ification has meant that there is no proper rigorous specification how to m=
ap from the XML syntax to the XML Infoset (it seems to be assumed to be so =
obvious that it does not need stating). =A0I tried an integrated approach o=
f specifying the syntax and data model together in the MicroXML spec (<a hr=
ef=3D"https://dvcs.w3.org/hg/microxml/raw-file/tip/spec/microxml.html" targ=
et=3D"_blank">https://dvcs.w3.org/hg/microxml/raw-file/tip/spec/microxml.ht=
ml</a>), and I think it works much better. The current approach of ECMA-404=
 is a bit like that of the XML Recommendation: it pretends at times to be j=
ust specifying when a sequence of code points is valid, and yet the specifi=
cation contains a fairly random selection of statements of how a valid sequ=
ence should be interpreted.=A0</div>


<div><br></div><div>James</div><div><br></div></div></div></div>

--089e013a1b9a71455104ed288ea8--

From allen@wirfs-brock.com  Tue Dec 10 08:12:32 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147891ADF4F for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 08:12:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 pn6Zk7IQ1v_T for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 08:12:30 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 374341ADF34 for <json@ietf.org>; Tue, 10 Dec 2013 08:12:30 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1VqPv5-0004BE-IO; Tue, 10 Dec 2013 16:12:23 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/LmOtEEvQS3xNio9nVaIykryNFt0riV3k=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-188-362843053
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <035D367A-323E-4799-AB6B-B83CC2E8DBF4@tzi.org>
Date: Tue, 10 Dec 2013 08:12:15 -0800
Message-Id: <0D6F9BFD-A54C-4D79-91D4-E50F5D87B13B@wirfs-brock.com>
References: <7FD8497D-5E19-4EFE-B66E-538FC42B7478@nuance.com> <7895D7DA-E608-49DF-8984-FFC91AFDBF04@tzi.org> <52A6EA82.5030408@it.aoyama.ac.jp> <035D367A-323E-4799-AB6B-B83CC2E8DBF4@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.1085)
Cc: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>, JSON WG <json@ietf.org>
Subject: Re: [Json] Fwd: two comments on JSON, ECMA-404, 1st edition / October 2013
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 16:12:32 -0000

--Apple-Mail-188-362843053
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Dec 10, 2013, at 2:32 AM, Carsten Bormann wrote:
> ...
>=20
>> But maybe there's a public archive? A pointer would be appreciated.
>=20
> https://mail.mozilla.org/pipermail/es-discuss/
>=20

A formated version of the archive is also available here =
http://esdiscuss.org/=20

Allen


--Apple-Mail-188-362843053
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 10, 2013, at 2:32 AM, Carsten Bormann wrote:</div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000">...<br></font><br><blockquote type="cite">But maybe there's a public archive? A pointer would be appreciated.<br></blockquote><br><a href="https://mail.mozilla.org/pipermail/es-discuss/">https://mail.mozilla.org/pipermail/es-discuss/</a><br><br></div></blockquote><br></div><div>A formated version of the archive is also available here&nbsp;<a href="http://esdiscuss.org/">http://esdiscuss.org/</a>&nbsp;</div><div><br></div><div>Allen</div><br></body></html>
--Apple-Mail-188-362843053--

From tbray@textuality.com  Tue Dec 10 09:34:03 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0A71ADFE2 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 09:34:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 E3tVi5QqZ7xf for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 09:34:01 -0800 (PST)
Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 899661ADFFB for <json@ietf.org>; Tue, 10 Dec 2013 09:34:01 -0800 (PST)
Received: by mail-ve0-f177.google.com with SMTP id db12so5051966veb.36 for <json@ietf.org>; Tue, 10 Dec 2013 09:33:56 -0800 (PST)
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:content-type; bh=XtYOSQwndqtmG+CPRE2HCnOWIMbPGs2glAj0dw2hb00=; b=mErmY8KUAMyAns0G0s1qUrkGDNJMaPViYCLXaZDvrn8A4D7fTcQONZtFuLMqAI1zAE 5stYngeekW4i3d5dA3TWhOP15bIkN3wf+ysFa29dFtE0xZ4AzByKJCw3Y1wENtyzOnDs Iv/OMYCi+iANEyX4vG4sJjm2tqr7nTUHANuUSXKqbHpogqJONxXOYJAHgp3p+21bd2uG BvizI+GFQnjCRS/thaoWJyWky5joG0Mnfm3TvSG2Gc4EsvHs6kSvLuG3lfRwdKkkpCzx ohSPlIBqP4BqXdvHH6fXe8/Cc4TBFIIDm/EblvLbS3YavkSkCRjb5ORFBQP1cHEbBC5Q erSw==
X-Gm-Message-State: ALoCoQkfuz1xvKgDzYBH7TTvM6aAI7boGRZHaV5uOcbZuIpGSWTnL66vNGpek67+K1SBCKDAHRF4
MIME-Version: 1.0
X-Received: by 10.58.208.130 with SMTP id me2mr14574548vec.13.1386696836067; Tue, 10 Dec 2013 09:33:56 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Tue, 10 Dec 2013 09:33:55 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org>
Date: Tue, 10 Dec 2013 09:33:55 -0800
Message-ID: <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Carsten Bormann <cabo@tzi.org>
Content-Type: multipart/alternative; boundary=047d7bdc192c5348d704ed318474
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Ladislav Lhotka <lhotka@nic.cz>, James Clark <jjc@jclark.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 17:34:03 -0000

--047d7bdc192c5348d704ed318474
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This discussion feels like a waste of time.  The XML Infoset was necessary
because it was essentially impossible to write specs for XML-based
languages because the syntax spec didn=E2=80=99t provide words to talk abou=
t them.
 I have dealt with loads of protocol specs that depend on JSON and the
equivalent stress doesn=E2=80=99t exist: =E2=80=9DX will be encoded as an o=
bject with the
following keys required and the following optional=E2=80=9D. =E2=80=9CY wil=
l be encoded as
a list all of whose members are X=E2=80=99s=E2=80=9D. =E2=80=9CY will be a =
number which can be
represented in a signed 16-bit integer=E2=80=9D. Etc.

I see no benefits to the actual users of JSON coming out of this.


On Tue, Dec 10, 2013 at 4:06 AM, Carsten Bormann <cabo@tzi.org> wrote:

> On 10 Dec 2013, at 12:59, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > How about =E2=80=9Cinformation model=E2=80=9D/=E2=80=9Cdata model=E2=80=
=9D (cf. RFC 3444)?
>
> Well, the information model is the more abstract one, so in this dichotom=
y
> today=E2=80=99s data model would become the information model and the inf=
oset would
> become the data model.  Ouch.
>
> Maybe we can find those terms later instead of muddling our current
> discussion with the search for terms.  We know exactly what infoset and
> data model mean in this context, so let=E2=80=99s continue to use these t=
erms until
> some stroke of genius supplies us with better ones.
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>

--047d7bdc192c5348d704ed318474
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This discussion feels like a waste of time. =C2=A0The XML =
Infoset was necessary because it was essentially impossible to write specs =
for XML-based languages because the syntax spec didn=E2=80=99t provide word=
s to talk about them. =C2=A0I have dealt with loads of protocol specs that =
depend on JSON and the equivalent stress doesn=E2=80=99t exist: =E2=80=9DX =
will be encoded as an object with the following keys required and the follo=
wing optional=E2=80=9D. =E2=80=9CY will be encoded as a list all of whose m=
embers are X=E2=80=99s=E2=80=9D. =E2=80=9CY will be a number which can be r=
epresented in a signed 16-bit integer=E2=80=9D. Etc.<div>
<br></div><div>I see no benefits to the actual users of JSON coming out of =
this.</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quo=
te">On Tue, Dec 10, 2013 at 4:06 AM, Carsten Bormann <span dir=3D"ltr">&lt;=
<a href=3D"mailto:cabo@tzi.org" target=3D"_blank">cabo@tzi.org</a>&gt;</spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 10 Dec 2013, at 12:59, =
Ladislav Lhotka &lt;<a href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; =
wrote:<br>

<br>
&gt; How about =E2=80=9Cinformation model=E2=80=9D/=E2=80=9Cdata model=E2=
=80=9D (cf. RFC 3444)?<br>
<br>
</div>Well, the information model is the more abstract one, so in this dich=
otomy today=E2=80=99s data model would become the information model and the=
 infoset would become the data model. =C2=A0Ouch.<br>
<br>
Maybe we can find those terms later instead of muddling our current discuss=
ion with the search for terms. =C2=A0We know exactly what infoset and data =
model mean in this context, so let=E2=80=99s continue to use these terms un=
til some stroke of genius supplies us with better ones.<br>

<br>
Gr=C3=BC=C3=9Fe, Carsten<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
</div></div></blockquote></div><br></div>

--047d7bdc192c5348d704ed318474--

From cromis@gmail.com  Tue Dec 10 10:00:42 2013
Return-Path: <cromis@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE6B1AE1BC for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 10:00:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 d6pewmDjfALZ for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 10:00:37 -0800 (PST)
Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC021AE18D for <json@ietf.org>; Tue, 10 Dec 2013 10:00:34 -0800 (PST)
Received: by mail-pd0-f173.google.com with SMTP id p10so7785366pdj.4 for <json@ietf.org>; Tue, 10 Dec 2013 10:00:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=5y30QKqqTLJvYiW2FPeIzgwS49GmsqwK5QTuMad4NSU=; b=D/YE+wBquQjkldsk2+7JA28j08lGyofOClWNbCpSK5uReivRnCroojHvatYhg7sfvU Ql0MRb3rvy+thgfheQrAFe3/pmXixavR1HcywkCjTCZpkhNwL4PQbzRf5B6hFBRe7NtB 4SySOS+QYBQLR7wBS2QlR+vBvFSTwJhpHsWf6CHeSI3B7WkysXsDGcOQg4Ac7eBHfxr9 OSHaoW1nURumQ6+Z0m8PyEZfAwKXCPt9Cnj/ER5uGCVZqo88t3oc7iTlOjlshrdUVaLS 2IE6KMGDTmESUGDPtRqaekodoLIRwuj27HgSElhlMP48g1miQCINTDIvhcGs9eFfZ88p HMIA==
X-Received: by 10.68.176.65 with SMTP id cg1mr29547878pbc.145.1386698428839; Tue, 10 Dec 2013 10:00:28 -0800 (PST)
MIME-Version: 1.0
Sender: cromis@gmail.com
Received: by 10.70.93.228 with HTTP; Tue, 10 Dec 2013 10:00:08 -0800 (PST)
In-Reply-To: <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com>
From: Jacob Davies <jacob@well.com>
Date: Tue, 10 Dec 2013 10:00:08 -0800
X-Google-Sender-Auth: z64rFenKLFpiUHJ_X_SjgHTp4bg
Message-ID: <CAO1wJ5SO21RVrjjeN2dKoZdFe9Pg43xL15_NZuU4tbw3enZ4kQ@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, James Clark <jjc@jclark.com>, Ladislav Lhotka <lhotka@nic.cz>, JSON WG <json@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Carsten Bormann <cabo@tzi.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 18:00:43 -0000

I think it would be an interesting exercise and I think it's a useful
way to think about JSON, but the last few months of discussion here
have illustrated that agreement over what such an infoset would
actually consist of would be hard to come by, and most implementations
would not implement it fully because they restrict their numeric value
space, ignore duplicates, do not preserve ordering, don't verify
Unicode escapes, and so on. I've looked at a lot of JSON
implementations and I don't think I've seen a single one that could
actually represent all JSON number values, for instance.


On Tue, Dec 10, 2013 at 9:33 AM, Tim Bray <tbray@textuality.com> wrote:
> This discussion feels like a waste of time.  The XML Infoset was necessar=
y
> because it was essentially impossible to write specs for XML-based langua=
ges
> because the syntax spec didn=92t provide words to talk about them.  I hav=
e
> dealt with loads of protocol specs that depend on JSON and the equivalent
> stress doesn=92t exist: =94X will be encoded as an object with the follow=
ing
> keys required and the following optional=94. =93Y will be encoded as a li=
st all
> of whose members are X=92s=94. =93Y will be a number which can be represe=
nted in a
> signed 16-bit integer=94. Etc.
>
> I see no benefits to the actual users of JSON coming out of this.
>
>
> On Tue, Dec 10, 2013 at 4:06 AM, Carsten Bormann <cabo@tzi.org> wrote:
>>
>> On 10 Dec 2013, at 12:59, Ladislav Lhotka <lhotka@nic.cz> wrote:
>>
>> > How about =93information model=94/=93data model=94 (cf. RFC 3444)?
>>
>> Well, the information model is the more abstract one, so in this dichoto=
my
>> today=92s data model would become the information model and the infoset =
would
>> become the data model.  Ouch.
>>
>> Maybe we can find those terms later instead of muddling our current
>> discussion with the search for terms.  We know exactly what infoset and =
data
>> model mean in this context, so let=92s continue to use these terms until=
 some
>> stroke of genius supplies us with better ones.
>>
>> Gr=FC=DFe, Carsten
>>
>> _______________________________________________
>> json mailing list
>> json@ietf.org
>> https://www.ietf.org/mailman/listinfo/json
>
>
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>

From Peter.Patel-Schneider@nuance.com  Tue Dec 10 14:14:45 2013
Return-Path: <Peter.Patel-Schneider@nuance.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06A01AE08B for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 14:14:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 WbNp5Yops0EO for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 14:14:43 -0800 (PST)
Received: from som-mx-a.nuance.com (som-mx-a.nuance.com [198.71.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 88AD21AE06D for <json@ietf.org>; Tue, 10 Dec 2013 14:14:43 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqAEANB8p1IKHBQY/2dsb2JhbABZhBK5HYE3dIIlAQEEAXkFCwIBCA0BAwMBAg0iMh0IAgQOBYd8wScXjlIIKwcGgxuBEwSYFIZsjlCCKg
Received: from unknown (HELO SOM-CAS01.nuance.com) ([10.28.20.24]) by som-mx-a.nuance.com with ESMTP/TLS/AES128-SHA; 10 Dec 2013 17:14:36 -0500
Received: from SOM-CAS03.nuance.com (10.28.20.26) by SOM-CAS01.nuance.com (10.28.20.24) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 17:14:37 -0500
Received: from SOM-EXCH03.nuance.com ([fe80::9e:afcc:f198:709f]) by SOM-CAS03.nuance.com ([::1]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 17:14:37 -0500
From: "Patel-Schneider, Peter" <Peter.Patel-Schneider@nuance.com>
To: Carsten Bormann <cabo@tzi.org>
Thread-Topic: [Json] Fwd: two comments on JSON, ECMA-404, 1st edition / October 2013
Thread-Index: AQHO9WTCmeV6ONdMjEOW4Rr0kfhZew==
Date: Tue, 10 Dec 2013 22:14:36 +0000
Message-ID: <932988A1-588C-48BF-A35A-829B7CE2021F@nuance.com>
References: <7FD8497D-5E19-4EFE-B66E-538FC42B7478@nuance.com> <7895D7DA-E608-49DF-8984-FFC91AFDBF04@tzi.org>
In-Reply-To: <7895D7DA-E608-49DF-8984-FFC91AFDBF04@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.28.16.110]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <AFFA2295243121459EA018746103D89F@nuance.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 10 Dec 2013 14:59:00 -0800
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] Fwd: two comments on JSON, ECMA-404, 1st edition / October 2013
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 22:15:31 -0000

Thanks for forwarding my message to this group.

However, I was hoping for a discussion on what to do about these bugs (or c=
omplaints that my analysis is not correct), not how to subscribe to es-disc=
uss.  :-)

peter

On Dec 10, 2013, at 1:22 AM, Carsten Bormann <cabo@tzi.org> wrote:

> FYI for those who haven=92t surrendered into subscribing to es-discuss ye=
t:
>=20
> Begin forwarded message:
>=20
>> From: "Patel-Schneider, Peter" <Peter.Patel-Schneider@nuance.com>
>> Subject: two comments on JSON, ECMA-404, 1st edition / October 2013
>> Date: 10 Dec 2013 06:00:34 +0100
>> To: "es-discuss@mozilla.org" <es-discuss@mozilla.org>
>>=20
>> 1/ According to ECMA-404, 1st edition / October 2013, a JSON text is a s=
equence
>> of Unicode code points.   The code points that can appear in a JSON text
>> include all code point except the control characters (the text says U+00=
00
>> to U+001F but the syntax diagram just says control character, which in
>> Unicode 6.3 also includes U+007F to U+009F).  Therefore, the code
>> point sequence <0022, DEAD, 0022> is a valid JSON text.
>>=20
>> However, this code point sequence cannot be represented in UTF-8, UTF-16=
, or
>> UTF-32, as it is not a sequence of Unicode scalar values, and=20
>> Unicode encoding forms are only defined on Unicode scalar values. =20
>>=20
>>=20
>> 2/ The unescaping of strings in JSON is ill-defined as there are quoted=
=20
>> JSON strings that are the escaped version of two different sequences of
>> Unicode code points.  For example both <D834, DD1E> and <1D11E> can be
>> represented as "\uD834\uDD1E".=20
>>=20
>>=20
>> Both of these appear to be bugs that should be fixed.
>>=20
>> Peter F. Patel-Schneider
>>=20

From paul.hoffman@vpnc.org  Tue Dec 10 14:59:02 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749CD1AE28C for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 14:59:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 uFuSqOlzyed0 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 14:59:01 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AEB0A1AE28B for <json@ietf.org>; Tue, 10 Dec 2013 14:59:01 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rBAMwHns065075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Dec 2013 15:58:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <1385505093.3251.101.camel@chacal>
Date: Tue, 10 Dec 2013 14:58:16 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <84C8F008-DB86-4C5B-8158-FD0C6BEE0BB0@vpnc.org>
References: <1385505093.3251.101.camel@chacal>
To: Philippe Le Hegaret <plh@w3.org>
X-Mailer: Apple Mail (2.1822)
X-Mailman-Approved-At: Tue, 10 Dec 2013 15:00:07 -0800
Cc: Tim Berners-Lee <timbl@w3.org>, Daniel Appelquist <daniel.appelquist@telefonica.com>, Peter Linss <peter.linss@hp.com>, JSON WG <json@ietf.org>, Mark Nottingham <mnot@mnot.net>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Yves Lafon <ylafon@w3.org>, public-ietf-w3c <public-ietf-w3c@w3.org>, Wendy Seltzer <wseltzer@w3.org>
Subject: Re: [Json] Concerns from the W3C Technical Architecture Group regarding JSON
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 22:59:02 -0000

Thank you for your statement of concern about =
draft-ietf-json-rfc4627bis. We hope that this response from the chairs =
of the IETF's JSON Working Group allays those concerns.

The TAG expresses concerns about differences between ECMA-404 and =
draft-ietf-json-rfc4627bis. It says "the two specs vary slightly", which =
is no longer true of the syntax in the latest draft of =
draft-ietf-json-rfc4627bis. The TAG gives an example of its concern as =
being about what is allowed in a JSON text. That concern has already =
been met in the latest draft of draft-ietf-json-rfc4627bis: the two =
specifications now have no more syntax differences. During the IETF Last =
Call, it became clear that the consensus was that it was acceptable for =
the definition in draft-ietf-json-rfc4627bis be changed to match that of =
ECMA-404, namely that a JSON text can consist of any single JSON token =
(including the four-character string "42" and the two-digit number 42).

On the topic of JSON semantics, Ecma TC39 has said repeatedly that =
ECMA-404 is meant to only document the JSON syntax, with no description =
of the semantics of encoding or parsing. On the other hand, =
draft-ietf-json-rfc4627bis and RFC 4627 before it express both syntax =
and semantics. For a format such as JSON, interoperability in encoders =
and parsers can only be achieved with descriptions of both syntax and =
semantics.

The statement "we believe this could lead to interoperability issues" is =
of course true: ECMA chose to make JSON as described in the ECMAScript =
standard have different semantics than were expressed in RFC 4627. The =
JSON WG did not, and does not, object to ECMA choosing to have a =
non-interoperable semantics for JSON in its specifications: different =
SDOs are welcome to do so. A great deal of effort in the JSON WG process =
around draft-ietf-json-rfc4627bis has been to carefully describe =
differences between the new spec and ECMAScript.

Lastly, the TAG says "We suggest that the IETF JSON working group should =
re-enter discussions with ECMA TC39 in order to facilitate aligning RFC =
4627bis with the current ECMA-404 specification." The syntax in the =
current IETF draft and the current version of ECMA-404 are believed to =
agree completely.

We also note that "discussions with ECMA TC39" never actually happened: =
the chairs of the IETF JSON WG attempted repeatedly to engage members of =
TC39, but were met almost completely with silence. Further, TC39 never =
engaged the IETF JSON Working Group for any input on ECMA-404. We =
understand that outside the JSON WG, the IETF (through the IAB) and Ecma =
had some early discussions on making a formal liaison relationship; if =
those discussions become fruitful in the future, the sort of =
non-discussion that happened in this work can be avoided.

--Paul Hoffman and Matt Miller=

From derhoermi@gmx.net  Tue Dec 10 15:08:16 2013
Return-Path: <derhoermi@gmx.net>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9683B1AE147 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 15:08:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level: 
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 X7sepc0t9H9f for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 15:08:14 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4EF1ACCDE for <json@ietf.org>; Tue, 10 Dec 2013 15:08:13 -0800 (PST)
Received: from netb.Speedport_W_700V ([84.180.225.47]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0LkP8Z-1VIYEn3rz9-00cOYr for <json@ietf.org>; Wed, 11 Dec 2013 00:08:07 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Wed, 11 Dec 2013 00:08:06 +0100
Message-ID: <905fa99h0ub9bu39sj8ada6m4aa6t2actn@hive.bjoern.hoehrmann.de>
References: <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp> <E19BDE18-DA46-4C00-AA6C-205C348326AD@tzi.org> <52A59337.4050609@it.aoyama.ac.jp> <2AA6AE6A-C76D-4B61-BFE1-0EBDFB715D6D@tzi.org> <8E4C7969-7868-4DE9-A9B0-C7FD484075B1@wirfs-brock.com> <serca9lle8m19n7ikdhf9ldlcoo8b9mpos@hive.bjoern.hoehrmann.de> <1E12FB6A-BD61-4E51-89E9-4398F943FF8F@wirfs-brock.com>
In-Reply-To: <1E12FB6A-BD61-4E51-89E9-4398F943FF8F@wirfs-brock.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:1VC12C1TAXpkebVuq+7n7qUrpsDmBir2Gl5c7PTfc4Yt/bDj7zM 95dHfRhE7RoZc/2KAxbeJjV77E6GDpuyAV9WTcGLzOOjyN3BmfH6VzqjOxTBDR3EWl2jmBu Z9b+B79VlI0H9mIUoFFVwBynjMdLVu+z/q3HUoMR8/zUsnHJd63DdDRcbn3ZFmkeeT0MOds vMauwq6khlI5AO30DEcnQ==
Cc: JSON WG <json@ietf.org>, www-tag@w3.org, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 23:08:16 -0000

* Allen Wirfs-Brock wrote:
>On Dec 9, 2013, at 5:40 PM, Bjoern Hoehrmann wrote:
>> If TC39 said ECMA-404 is going to be replaced by a verbatim copy of the
>> ABNF grammar in draft-ietf-json-rfc4627bis-08 with pretty much no other
>> discussion of JSON and a clear indication that future editions will not
>> add such discussion, and will not change the grammar without IETF con-
>> sensus, I would be willing to entertain the idea of making ECMA-404 a
>> normative reference.

>The second paragraph is speaking about the language described by the 
>grammar, not the actual formalism used to express the grammar. I'm quite 
>sure that there is no interest at all within TC39 to ever change the 
>actual JSON language.  If you are looking for some sort of contractual 
>commitment from ECMA, I suspect you are wasting your time. Does the IETF 
>make such commitments?

As you know, the charter of the JSON Working Group says

  The resulting document will be jointly published as an RFC and by
  ECMA. ECMA participants will be participating in the working group 
  editing through the normal process of working group participation.  
  The responsible AD will coordinate the approval process with ECMA so 
  that the versions of the document that are approved by each body are 
  the same.

If things had gone according to plan, it seems likely that Ecma would
have requested the IANA registration for application/json jointly lists
the IETF and Ecma International has holding Change Control over it, and
it seems unlikely there would have been much disagreement about that.

It is normal to award change control to other organisations, for
instance, RFC 3023 gives change control for the XML media types to the
W3C. I can look up examples for jointly held change control if that
would help.

And no, I am not looking for an enforceable contract, just a clear
formal decision and statement.

>This doesn't mean that TC39 would necessarily agree to eliminate the 
>Syntax Diagrams,  or that we wouldn't carefully audit any grammar 
>contribution to make sure that it is describing the same language.  
>There may also be minor issues that need to be resolved. But we seem to 
>agree that we already are both accurately describing the same language 
>so this is really about notational agreement.

Having non-normative syntax diagrams in addition to the ABNF grammar
would be fine if they can automatically be generated from the ABNF.

I was talking about removing most of the prose, leaving only boiler-
plate, a very short introduction, and references. Then it would be a
specification of only the syntax and most technical concerns would be
addressed on both sides. If you see this as a viable way forward, then
I think the JSON WG should explore this option further.

>As a base line, ECMA-404 was created in less than a week.  It takes a 
>couple months to push through a letter ballot to above a revised 
>standard. 

The RFC4627bis draft could be approved and be held for normatives re-
ferences to materialise; this is not uncommon for IETF standards. It
usually takes a couple of months for the RFC editor to process the
document anyway, so personally a couple of months of waiting for a
revised edition of ECMA-404 would be okay with me.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From paul.hoffman@vpnc.org  Tue Dec 10 15:15:06 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FC71AE225 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 15:15:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 zYynTu2FZHFI for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 15:15:05 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA0D1AE147 for <json@ietf.org>; Tue, 10 Dec 2013 15:15:05 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rBANErWs065486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Dec 2013 16:14:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <52938515.6070702@qti.qualcomm.com>
Date: Tue, 10 Dec 2013 15:14:53 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <E10A9134-FC6A-4C00-9B9A-44A2C380C911@vpnc.org>
References: <52938515.6070702@qti.qualcomm.com>
To: Istvan Sebestyen <istvan@ecma-international.org>
X-Mailer: Apple Mail (2.1822)
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Ecma TC39 Comments on RFC 4727bis
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 23:15:06 -0000

We have replied to the original message using the IETF liaison tool. =
Please see <https://datatracker.ietf.org/liaison/1297/>.

--Paul Hoffman and Matt Miller


From allen@wirfs-brock.com  Tue Dec 10 17:29:39 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7B81ADFDD for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 17:29:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 FEDehpAO8XLT for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 17:29:36 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id A47861ADED8 for <json@ietf.org>; Tue, 10 Dec 2013 17:29:36 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1VqYcD-00033q-Ao; Wed, 11 Dec 2013 01:29:30 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18STDFoyWmZf6FLguTd6wJiTEUyO1mNfUw=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-190-396269705
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <932988A1-588C-48BF-A35A-829B7CE2021F@nuance.com>
Date: Tue, 10 Dec 2013 17:29:22 -0800
Message-Id: <EC9703BD-27A8-4EED-9BAB-2F91660D5330@wirfs-brock.com>
References: <7FD8497D-5E19-4EFE-B66E-538FC42B7478@nuance.com> <7895D7DA-E608-49DF-8984-FFC91AFDBF04@tzi.org> <932988A1-588C-48BF-A35A-829B7CE2021F@nuance.com>
To: "Patel-Schneider, Peter" <Peter.Patel-Schneider@nuance.com>
X-Mailer: Apple Mail (2.1085)
Cc: Carsten Bormann <cabo@tzi.org>, es-discuss list <es-discuss@mozilla.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] Fwd: two comments on JSON, ECMA-404, 1st edition / October 2013
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 01:29:39 -0000

--Apple-Mail-190-396269705
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Peter,
I would be idea if you registered submitted these issues to =
bugs.ecmascrip.org as tickets against ECMA-404.  That way you would be =
copied on any discussion regarding them that took place via the bug =
tracking systems.

Regardless, I'll make some preliminary responses below.

Allen

On Dec 10, 2013, at 2:14 PM, Patel-Schneider, Peter wrote:

> Thanks for forwarding my message to this group.
>=20
> However, I was hoping for a discussion on what to do about these bugs =
(or complaints that my analysis is not correct), not how to subscribe to =
es-discuss.  :-)
>=20
> peter
>=20
> On Dec 10, 2013, at 1:22 AM, Carsten Bormann <cabo@tzi.org> wrote:
>=20
>> FYI for those who haven=92t surrendered into subscribing to =
es-discuss yet:
>>=20
>> Begin forwarded message:
>>=20
>>> From: "Patel-Schneider, Peter" <Peter.Patel-Schneider@nuance.com>
>>> Subject: two comments on JSON, ECMA-404, 1st edition / October 2013
>>> Date: 10 Dec 2013 06:00:34 +0100
>>> To: "es-discuss@mozilla.org" <es-discuss@mozilla.org>
>>>=20
>>> 1/ According to ECMA-404, 1st edition / October 2013, a JSON text is =
a sequence
>>> of Unicode code points.   The code points that can appear in a JSON =
text
>>> include all code point except the control characters (the text says =
U+0000
>>> to U+001F but the syntax diagram just says control character, which =
in
>>> Unicode 6.3 also includes U+007F to U+009F).  Therefore, the code
>>> point sequence <0022, DEAD, 0022> is a valid JSON text.

Strictly speaking, ECMA-404 only allows control characters (that are not =
also whitespace characters)  any code point can appear as part of a JSON =
string value. They can't occur anywhere else within a JSON text.   The =
normative text that precedes the Syntax Diagram defines "control =
character" as U+0000 to U+001F so that must be the meaning that applies =
to the diagram.  It should be pretty clear to any reader that a local =
definitions takes precedences over any other.  There is always room to =
improve the clarity of requirements.  So a bug asking to make this =
clearer is a fine request.  In reality, I don't think think anyone =
reading clause 9 of ECMA-404 would actually come to the conclusion that =
U+007F is exclude from a JSON strong value.  The text is explicit and it =
does not say that.

>>>=20
>>> However, this code point sequence cannot be represented in UTF-8, =
UTF-16, or
>>> UTF-32, as it is not a sequence of Unicode scalar values, and=20
>>> Unicode encoding forms are only defined on Unicode scalar values. =20=


The code point sequence <0022, DEAD, 0022> is indeed, and intentionally, =
a a valid JSON text according ECMA-404.  JSON parsers do not exclusively =
operate upon sequences of Unicode scalar values.  =46rom its earliest =
days JSON as been parse using input sources (such as program language =
string abstractions)  that can are actually used to encode code points =
that are not Unicode Scalar Values. (For example, JavaScript strings =
UTF-16 encode supplementary characters but also allow unpaired =
surrogates)  The intent of ECMA-404 is to provide a grammar that is =
usable in such implementation as well as implementation that only deal =
with well formed UTF encodings.

Just because the grammar defines the how to parse JSON texts that =
include code points that are not Unicode scalar values, that doesn't =
mean that that all implementation must be able to process such JSON =
texts. Implementation may impose restrictions on the forms of input they =
can process and as is alluded to in the Introduction to ECMA-404 other =
standards can impose encoding restrictions  that apply in specific =
circumstances.  For example, 4627bis is certainly free to both reference =
ECMA-404 and to say that application/json text must only contain Unicode =
scalar values.


>>>=20
>>>=20
>>> 2/ The unescaping of strings in JSON is ill-defined as there are =
quoted=20
>>> JSON strings that are the escaped version of two different sequences =
of
>>> Unicode code points.  For example both <D834, DD1E> and <1D11E> can =
be
>>> represented as "\uD834\uDD1E".=20

As I said above, clarity can always be improved.  However, ECMA-404 =
clause 9 says "To escape a code point that is not in the Basic =
Multilingual Plane, the character is represented as a twelve character =
[bug should be "code point"] sequence, encoding the UTF-16 surrogate =
pair."  This seems pretty clear that if you see, "\uD834\uDD1E" as a =
JSON string value it must be interpreter as a JSON string containing the =
single character U+1D11E.  If you wish to express JSON string value =
containing the two code points U+D834 and U+DD1E then you must directly =
express at least one of them without using an escape sequence.=20

Note that this is all independent of any transcoding that might take =
place prior or subsequent to JSON parsing.  For example, the ECMAScript =
6 draft specifies that an expression like:
   JSON.parse(' "\uD834\uDD1E" ');
would first parse the argument to this function call as a ECMAScript =
string literal that produces a string value of length 2 that contains =
the UTF-16 encoding of code point U+1D11E.  In then specifies that =
JSON.parse, prior to actual parsing, must interpret that ECMAScript =
string value as UTF-16 (plus possibly with unpaired surrogates) and then =
process it as if it was transcoded an into an equivalent sequence of =
unencoded Unicode code points. So JSON.parse must (logically) process =
<U+0022, U+1D11E, U+0022> which it should recognize as a JSON string =
value consisting of one code point.  The output of JSON.parse is the =
corresponding ECMAScript string value so that single code point is =
return as an ECMAScript string of length 2 that contains the two code =
units U+D834 and U+DD1E.

Allen



--Apple-Mail-190-396269705
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
">Peter,<div>I would be idea if you registered submitted these issues to =
<a href=3D"http://bugs.ecmascrip.org">bugs.ecmascrip.org</a>&nbsp;as =
tickets against ECMA-404. &nbsp;That way you would be copied on any =
discussion regarding them that took place via the bug tracking =
systems.</div><div><br></div><div>Regardless, I'll make some preliminary =
responses =
below.</div><div><br></div><div>Allen</div><div><br><div><div>On Dec 10, =
2013, at 2:14 PM, Patel-Schneider, Peter wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>Thanks =
for forwarding my message to this group.<br><br>However, I was hoping =
for a discussion on what to do about these bugs (or complaints that my =
analysis is not correct), not how to subscribe to es-discuss. =
&nbsp;:-)<br><br>peter<br><br>On Dec 10, 2013, at 1:22 AM, Carsten =
Bormann &lt;<a href=3D"mailto:cabo@tzi.org">cabo@tzi.org</a>&gt; =
wrote:<br><br><blockquote type=3D"cite">FYI for those who haven=92t =
surrendered into subscribing to es-discuss =
yet:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Begin forwarded =
message:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">From: "Patel-Schneider, Peter" &lt;<a =
href=3D"mailto:Peter.Patel-Schneider@nuance.com">Peter.Patel-Schneider@nua=
nce.com</a>&gt;<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">Subject: two comments on JSON, =
ECMA-404, 1st edition / October =
2013<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">Date: 10 Dec 2013 06:00:34 =
+0100<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">To: "<a =
href=3D"mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>" =
&lt;<a =
href=3D"mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>&gt;<br><=
/blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">1/ According to ECMA-404, 1st =
edition / October 2013, a JSON text is a =
sequence<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">of Unicode code points. =
&nbsp;&nbsp;The code points that can appear in a JSON =
text<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">include all code point except the control characters (the =
text says U+0000<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">to U+001F but the syntax diagram =
just says control character, which =
in<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">Unicode 6.3 also includes U+007F to U+009F). =
&nbsp;Therefore, the code<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">point sequence &lt;0022, DEAD, =
0022&gt; is a valid JSON =
text.<br></blockquote></blockquote></div></blockquote><div><br></div><div>=
Strictly speaking, ECMA-404 only allows control characters (that are not =
also whitespace characters) &nbsp;any code point can appear as part of a =
JSON string value. They can't occur anywhere else within a JSON text. =
&nbsp; The normative text that precedes the Syntax Diagram defines =
"control character" as U+0000 to U+001F so that must be the meaning that =
applies to the diagram. &nbsp;It should be pretty clear to any reader =
that a local definitions takes precedences over any other. &nbsp;There =
is always room to improve the clarity of requirements. &nbsp;So a bug =
asking to make this clearer is a fine request. &nbsp;In reality, I don't =
think think anyone reading clause 9 of ECMA-404 would actually come to =
the conclusion that U+007F is exclude from a JSON strong value. =
&nbsp;The text is explicit and it does not say =
that.</div><div><br></div><blockquote type=3D"cite"><div><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">However, this code point =
sequence cannot be represented in UTF-8, UTF-16, =
or<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">UTF-32, as it is not a sequence of Unicode scalar values, =
and <br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">Unicode encoding forms are only defined on Unicode scalar =
values. =
&nbsp;<br></blockquote></blockquote></div></blockquote><div><br></div><div=
><div><div>The code point sequence &lt;0022, DEAD, 0022&gt; is indeed, =
and intentionally, a a valid JSON text according ECMA-404. &nbsp;JSON =
parsers do not exclusively operate upon sequences of Unicode scalar =
values. &nbsp;=46rom its earliest days JSON as been parse using input =
sources (such as program language string abstractions) &nbsp;that can =
are actually used to encode code points that are not Unicode Scalar =
Values. (For example, JavaScript strings UTF-16 encode supplementary =
characters but also allow unpaired surrogates) &nbsp;The intent of =
ECMA-404 is to provide a grammar that is usable in such implementation =
as well as implementation that only deal with well formed UTF =
encodings.</div><div><br></div><div>Just because the grammar defines the =
how to parse JSON texts that include code points that are not Unicode =
scalar values, that doesn't mean that that all implementation must be =
able to process such JSON texts. Implementation may impose restrictions =
on the forms of input they can process and as is alluded to in the =
Introduction to ECMA-404 other standards can impose encoding =
restrictions &nbsp;that apply in specific circumstances. &nbsp;For =
example, 4627bis is certainly free to both reference ECMA-404 and to say =
that application/json text must only contain Unicode scalar =
values.</div><div><br></div></div></div><br><blockquote =
type=3D"cite"><div><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">2/ The unescaping of strings in =
JSON is ill-defined as there are quoted =
<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">JSON strings that are the escaped version of two different =
sequences of<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">Unicode code points. &nbsp;For =
example both &lt;D834, DD1E&gt; and &lt;1D11E&gt; can =
be<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">represented as =
"\uD834\uDD1E".&nbsp;</blockquote></blockquote></div></blockquote><div><br=
></div>As I said above, clarity can always be improved. &nbsp;However, =
ECMA-404 clause 9 says "<span class=3D"Apple-style-span" =
style=3D"font-family: sans-serif; font-size: 13px; ">To escape a code =
point that is not in the Basic Multilingual Plane, the character is =
represented as a twelve&nbsp;</span><span class=3D"Apple-style-span" =
style=3D"font-family: sans-serif; font-size: 13px; ">character [bug =
should be "code point"] sequence, encoding the UTF</span><span =
class=3D"Apple-style-span" style=3D"font-family: sans-serif; font-size: =
13px; ">-1</span><span class=3D"Apple-style-span" style=3D"font-family: =
sans-serif; font-size: 13px; ">6 surrogate p</span><span =
class=3D"Apple-style-span" style=3D"font-family: sans-serif; font-size: =
13px; ">air.</span>" &nbsp;This seems pretty clear that if you =
see,&nbsp;"\uD834\uDD1E"&nbsp;as a JSON string value it must be =
interpreter as a JSON string containing the single character U+1D11E. =
&nbsp;If you wish to express JSON string value containing the two code =
points U+D834 and U+DD1E then you must directly express at least one of =
them without using an escape =
sequence.&nbsp;</div><div><br></div><div>Note that this is all =
independent of any transcoding that might take place prior or subsequent =
to JSON parsing. &nbsp;For example, the ECMAScript 6 draft specifies =
that an expression like:</div><div>&nbsp; &nbsp;JSON.parse(' =
"\uD834\uDD1E" ');</div><div>would first parse the argument to this =
function call as a ECMAScript string literal that produces a string =
value of length 2 that contains the UTF-16 encoding of code point =
U+1D11E. &nbsp;In then specifies that JSON.parse, prior to actual =
parsing, must interpret that ECMAScript string value as UTF-16 (plus =
possibly with unpaired surrogates) and then process it as if it was =
transcoded an&nbsp;into an&nbsp;equivalent&nbsp;sequence of unencoded =
Unicode code points. So JSON.parse must (logically) process &lt;U+0022, =
U+1D11E, U+0022&gt; which it should recognize as a JSON string value =
consisting of one code point. &nbsp;The output of JSON.parse is the =
corresponding ECMAScript string value so that single code point is =
return as an ECMAScript string of length 2 that contains the two code =
units U+D834 and =
U+DD1E.</div><div><div><br></div><div>Allen</div><div><br></div><div><br><=
/div></div></div></body></html>=

--Apple-Mail-190-396269705--

From allen@wirfs-brock.com  Tue Dec 10 18:06:35 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEE31AE0AA for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 18:06:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 1asu-wknutAU for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 18:06:31 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 430851AE309 for <json@ietf.org>; Tue, 10 Dec 2013 18:06:31 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1VqZBu-000OpO-3w; Wed, 11 Dec 2013 02:06:22 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19xb55nLiREIIiB5ZYdL0HhdWwNJkAyxoY=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-191-398480966
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com>
Date: Tue, 10 Dec 2013 18:06:13 -0800
Message-Id: <BBB35237-A122-4C4B-8000-5565DBDDDE0D@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com>
To: James Clark <jjc@jclark.com>
X-Mailer: Apple Mail (2.1085)
Cc: JSON WG <json@ietf.org>, Carsten Bormann <cabo@tzi.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Tim Bray <tbray@textuality.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 02:06:36 -0000

--Apple-Mail-191-398480966
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Dec 9, 2013, at 10:52 PM, James Clark wrote:

> On Fri, Dec 6, 2013 at 2:51 AM, Allen Wirfs-Brock =
<allen@wirfs-brock.com> wrote:
>=20
> The static semantics of a language are a set of rules that further =
restrict  which sequences of symbols form valid statements within the =
language.  For example, a rule that the 'member' names must be disjoint =
within an 'object' production could be a static semantic rule (however, =
there is intentionally no such rule in ECMA-404).
>=20
> The line between syntax and static semantics can be fuzzy.  Static =
semantic rules are typically used to express rules that cannot be =
technically expressed using the chosen syntactic formalism or rules =
which are simply inconvenient to express using that formalism.  For =
example, the editor of ECMA-404 chose to simplify the RR track =
expression of the JSON syntax by using static semantic rules for =
whitespace rather than incorporating them into RR diagrams.=20
>=20
> Another form of static semantic rules are equivalences that state when =
two or more different sequences of symbols must be considered as =
equivalent.  For example, the rules that state equivalencies between =
escape sequences and individual code points within an JSON 'string'.  =
Such equivalences are not strictly necessary at this level, but it it =
simplifies the specification of higher level semantics if equivalent =
symbol sequences can be normalized at this level of specification.
>  =20
> When we talk about the "semantics" of a language (rather than "static =
semantics") we are talking about attributing meaning (in some domain and =
context) to well-formed (as specified via syntax and static semantics) =
statements expressed in that language.=20
> ...=20
> What we can do, is draw a bright-line just above the level of static =
semantics.This is what ECMA-404 attempts to do.=20
>=20
> I don't see how you can accommodate the second kind of static semantic =
rule within the definition of conformance that you have chosen for =
ECMA-404. Section 2 defines conformance in terms of whether a sequence =
of Unicode code points conforms to the grammar.  This doesn't even =
accommodate the first kind of static semantic rule, but it is obviously =
easy to extend it so that it does.  However, to accommodate the second =
kind of static semantic rule, you would need a notion of conformance =
that deals with how conforming parsers interpret a valid sequence of =
code points.

Well, its certainly is a nit to pick, but in context I interpret the =
term "grammar" as used in clause 2 (and also the Introduction) as =
meaning the full normative content of clauses 4 to 9. This includes the =
actual CFG specification and the associated static semantic rules.=20

The notion of a conforming parser could be added, I less sure that it is =
really necessary.  We don't even need to consider string escapes to get =
into the issue of equivalent JSON texts as it also exists because of =
optional white space.

>=20
> I think it is coherent to draw a bright-line just above the first =
level of static semantics.  If you did that, then most of the prose of =
section 9 (on Strings) would have to be removed; but this would be =
rather inconvenient, because most specifications of higher-level =
semantics would end up having to specify it themselves.

I generally agree with this, including the convenience perspective.  It =
essentially also applies to the decimal interpretation of numbers.  =
There is an argument to be made that both should just be discussed =
informatively and leave to higher level semantic specs. to make those =
interpretation normative.

>=20
> However, I find it hard to see any bright-line above the second level =
of static semantics and below semantics generally.  Let's consider =
section 9. I would argue that this section should define a "semantics" =
for string tokens, by defining a mapping from sequences of code points =
matching the production _string_ (what I would call the "lexical space") =
into arbitrary sequences of code points (what I would call the "value =
space"). The spec sometimes seems to be doing this and sometimes seems =
to be doing something more like your second kind of static semantics. =
Sometimes it uses the term "code point" or "character" to refer to code =
points in the lexical space ("A string is a sequence of Unicode code =
points wrapped with quotation marks"), and sometimes it uses those terms =
to refer to code points in the value space ("Any code point may be =
represented as a hexadecimal number").   You could redraft so that it =
was expressed purely in terms of code points in the lexical space, but =
that would be awkward and unnatural: for example, an hexadecimal escape =
would represent either one or two code points in the lexical space.  =
Furthermore I don't see what you would gain by this.  Once you talk =
about equivalences between sequences, you are into semantics and you =
need a richer notion of conformance.

Generally agree. We are probably seeing some editorial confusion as =
feedback (including mine)  was integrated into the editor's initial =
draft. This can all be improved in a subsequent edition

>=20
> So back to "semantics" and why ECMA-404 tries (perhaps imperfectly) to =
avoid describing JSON beyond the level of static semantics.=20
>=20
> ECMA-404 see JSON as "a text format that facilitates structured data =
interchange between all programming languages. JSON
> is syntax of braces, brackets, colons, and commas that is useful in =
many contexts, profiles, and applications".
>=20
> There are many possible semantics and categories of semantics that can =
be applied to well-formed statements expressed using the JSON syntax.
> ...
>=20
> The problem with trying to standardize JSON semantics is that the =
various semantics that can be usefully be imposed upon JSON are often =
mutually incompatible with each other. At a trivial level, we see this =
with issues like the size of numbers or duplicate object member keys.  =
It is very hard to decide whose semantics are acceptable and whose is =
not.
>=20
> I would argue that ECMA-404 should define the least restrictive =
reasonable semantics: the semantics should not treat as identical any =
values that higher layers might reasonably want to treat as distinct.  =
This is not the one, true JSON semantics: it is merely a semantic layer =
on which other higher-level semantic layers can in turn be built.  I =
don't think it's so hard to define this:
>=20
> 1. a value is an object, array, number, string, boolean or null.
> 2. an object is an ordered sequence of <string, value> pairs
> 3. an array is an ordered sequence of values
> 4. a string is an ordered sequence of Unicode code points

Indeed, this aligns very well with my perspective

>=20
> Item 2 maybe surprising to some people, but there's not really much =
choice given that JS preserves the order of object keys.  The difficult =
case is number. But even with number, I would argue that there are =
clearly some lexical values that can uncontroversially be specified to =
be equivalent (for example, 1e1 with 1E1 or 1e1 with 1e+1).  A set of =
decisions on lexical equivalence effectively determines a value space =
for numbers.  For example, you might reasonably decide that two values =
are equivalent if they represent real numbers with the same mathematical =
value.
>=20
> If ECMA-404 doesn't provide such a semantic layer, it becomes quite =
challenging for higher-level language bindings to specify their =
semantics in a truly rigorous way.  Take strings for example.  I think =
by far the cleanest way to rigorously define a mapping from string =
tokens to sequences of code points is to have a BNF and a =
syntax-directed mapping as the ECMAScript spec does very nicely in 7.8.4 =
(http://www.ecma-international.org/ecma-262/5.1/#sec-7.8.4).  If =
ECMA-404 provides merely a syntax and a specification of string =
equivalence, it becomes quite a challenge to draft a specification that =
somehow expresses the mapping while still normatively relying on the =
ECMA-404 spec for the syntax. What will happen in practice is that these =
higher level mapping will not be specified rigorously.
>=20
> I think ECMA-404 would be significantly more useful for its intended =
purpose if it provided the kind of semantics I am suggesting.
>=20
> I know XML is not very fashionable these days but we have a couple of =
decades of experience with XML and SGML which I think do have some =
relevance to a specification of "structured data interchange between =
programming language".   One conclusion I would draw from this =
experience is that the concept of an XML Infoset or something like it is =
very useful.  Most users of XML deal with higher-level semantic =
abstractions rather than directly with the XML Infoset, but it has =
proven very useful to be able to specify these higher-level semantic =
abstractions in terms of the XML Infoset rather than having to specify =
them directly in terms of the XML syntax.  Another conclusion I would =
draw is that it would have worked much better to integrate the XML =
Infoset specification into the main XML specification.  The approach of =
having a separate XML Infoset specification has meant that there is no =
proper rigorous specification how to map from the XML syntax to the XML =
Infoset (it seems to be assumed to be so obvious that it does not need =
stating).  I tried an integrated approach of specifying the syntax and =
data model together in the MicroXML spec =
(https://dvcs.w3.org/hg/microxml/raw-file/tip/spec/microxml.html), and I =
think it works much better. The current approach of ECMA-404 is a bit =
like that of the XML Recommendation: it pretends at times to be just =
specifying when a sequence of code points is valid, and yet the =
specification contains a fairly random selection of statements of how a =
valid sequence should be interpreted.=20

Thank you, this is very useful feedback.  Would you mind submit this as =
a bug report against ECMA-404 at bugs.ecmascript.org ? I can do it, but =
community feedback is important and I'd like to to be on the CC list for =
the bug.

Allen


>=20
> James
>=20


--Apple-Mail-191-398480966
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Dec 9, 2013, at 10:52 PM, James Clark wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On =
Fri, Dec 6, 2013 at 2:51 AM, Allen Wirfs-Brock <span dir=3D"ltr">&lt;<a =
href=3D"mailto:allen@wirfs-brock.com" =
target=3D"_blank">allen@wirfs-brock.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word"><br><div><div>The static semantics of a =
language are a set of rules that further restrict &nbsp;which sequences =
of symbols form valid statements within the language. &nbsp;For example, =
a rule that the 'member' names must be disjoint within an 'object' =
production could be a static semantic rule (however, there is =
intentionally no such rule in ECMA-404).<br>


</div><div><br></div><div>The line between syntax and static semantics =
can be fuzzy. &nbsp;Static semantic rules are typically used to express =
rules that cannot be technically expressed using the chosen syntactic =
formalism or rules which are simply inconvenient to express using that =
formalism. &nbsp;For example, the editor of ECMA-404 chose to simplify =
the RR track expression of the JSON syntax by using static semantic =
rules for whitespace rather than incorporating them into RR =
diagrams.&nbsp;</div>


<div><br></div><div>Another form of static semantic rules are =
equivalences that state when two or more different sequences of symbols =
must be considered as equivalent. &nbsp;For example, the rules that =
state equivalencies between escape sequences and individual code points =
within an JSON 'string'. &nbsp;Such equivalences are not strictly =
necessary at this level, but it it simplifies the specification of =
higher level semantics if equivalent symbol sequences can be normalized =
at this level of specification.</div>


</div></div></blockquote><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">&nbsp;&nbsp;</blockquote><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">


<div style=3D"word-wrap:break-word"><div><div>When we talk about the =
"semantics" of a language (rather than "static semantics") we are =
talking about attributing meaning (in some domain and context) to =
well-formed (as specified via syntax and static semantics) statements =
expressed in that language.&nbsp;</div>


</div></div></blockquote><div>...&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><span =
style=3D"font-family:sans-serif;font-size:13px">What we can do, is draw =
a bright-line just above the level of static semantics.This is what =
ECMA-404 attempts to do.</span>&nbsp;</blockquote>


<div><br></div><div>I don't see how you can accommodate the second kind =
of static semantic rule within the definition of conformance that you =
have chosen for ECMA-404. Section 2 defines conformance in terms of =
whether a sequence of Unicode code points conforms to the grammar. =
&nbsp;This doesn't even accommodate the first kind of static semantic =
rule, but it is obviously easy to extend it so that it does. =
&nbsp;However, to accommodate the second kind of static semantic rule, =
you would need a notion of conformance that deals with how conforming =
parsers interpret a valid sequence of code =
points.</div></div></div></div></blockquote><div><br></div><div>Well, =
its certainly is a nit to pick, but in context I interpret the term =
"grammar" as used in clause 2 (and also the Introduction) as meaning the =
full normative content of clauses 4 to 9. This includes the actual CFG =
specification and the associated static semantic =
rules.&nbsp;</div><div><br></div><div>The notion of a conforming parser =
could be added, I less sure that it is really necessary. &nbsp;We don't =
even need to consider string escapes to get into the issue of equivalent =
JSON texts as it also exists because of optional white =
space.</div><div><br></div><blockquote type=3D"cite"><div dir=3D"ltr"><div=
 class=3D"gmail_extra"><div class=3D"gmail_quote">


<div><br></div><div>I think it is coherent to draw a bright-line just =
above the first level of static semantics. &nbsp;If you did that, then =
most of the prose of section 9 (on Strings) would have to be removed; =
but this would be rather inconvenient, because most specifications of =
higher-level semantics would end up having to specify it =
themselves.</div></div></div></div></blockquote><div><br></div><div>I =
generally agree with this, including the convenience perspective. =
&nbsp;It essentially also applies to the decimal interpretation of =
numbers. &nbsp;There is an argument to be made that both should just be =
discussed informatively and leave to higher level semantic specs. to =
make those interpretation normative.</div><div><br></div><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote">


<div><br></div><div>However, I find it hard to see any bright-line above =
the second level of static semantics and below semantics generally. =
&nbsp;Let's consider section 9. I would argue that this section should =
define a "semantics" for string tokens, by defining a mapping from =
sequences of code points matching the production _string_ (what I would =
call the "lexical space") into arbitrary sequences of code points (what =
I would call the "value space"). The spec sometimes seems to be doing =
this and sometimes seems to be doing something more like your second =
kind of static semantics. Sometimes it uses the term "code point" or =
"character" to refer to code points in the lexical space ("A string is a =
sequence of Unicode code points wrapped with quotation marks"), and =
sometimes it uses those terms to refer to code points in the value space =
("Any code point may be represented as a hexadecimal number"). &nbsp; =
You could redraft so that it was expressed purely in terms of code =
points in the lexical space, but that would be awkward and unnatural: =
for example, an hexadecimal escape would represent either one or two =
code points in the lexical space. &nbsp;Furthermore I don't see what you =
would gain by this. &nbsp;Once you talk about equivalences between =
sequences, you are into semantics and you need a richer notion of =
conformance.</div></div></div></div></blockquote><div><br></div><div>Gener=
ally agree. We are probably seeing some editorial confusion as feedback =
(including mine) &nbsp;was integrated into the editor's initial draft. =
This can all be improved in a subsequent =
edition</div><div><br></div><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word"><div><div>


So back to "semantics" and why ECMA-404 tries (perhaps imperfectly) to =
avoid describing JSON beyond the level of static =
semantics.&nbsp;</div><div><br></div><div>ECMA-404 see JSON as "<span =
style=3D"font-family:sans-serif;font-size:13px">a text format that =
facilitates structured data intercha</span><span =
style=3D"font-family:sans-serif;font-size:13px">nge between all =
programming languages. JSON</span></div>


<div dir=3D"ltr" style=3D"font-size:13.28px;font-family:sans-serif">is =
syntax of braces, brackets, colons, and commas that is useful in many =
contexts, profiles, and applications".</div><div dir=3D"ltr" =
style=3D"font-size:13.28px;font-family:sans-serif">


<br></div><div dir=3D"ltr" =
style=3D"font-size:13.28px;font-family:sans-serif">There are many =
possible semantics and categories of semantics that can be applied to =
well-formed statements expressed using the JSON syntax.</div>

</div>
</div></blockquote><div>...</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word">


<div dir=3D"ltr" =
style=3D"font-size:13.28px;font-family:sans-serif"><br></div><div =
dir=3D"ltr" style=3D"font-size:13.28px;font-family:sans-serif">The =
problem with trying to standardize JSON semantics is that the various =
semantics that can be usefully be imposed upon JSON are often mutually =
incompatible with each other. At a trivial level, we see this with =
issues like the size of numbers or duplicate object member keys. =
&nbsp;It is very hard to decide whose semantics are acceptable and whose =
is not.</div>


</div></blockquote><div><br></div><div>I would argue that ECMA-404 =
should define the least restrictive reasonable semantics: the semantics =
should not treat as identical any values that higher layers might =
reasonably want to treat as distinct. &nbsp;This is not the one, true =
JSON semantics: it is merely a semantic layer on which other =
higher-level semantic layers can in turn be built. &nbsp;I don't think =
it's so hard to define this:</div>


<div><br></div><div>1. a value is an object, array, number, string, =
boolean or null.</div><div>2. an object is an ordered sequence of =
&lt;string, value&gt; pairs</div><div>3. an array is an ordered sequence =
of values</div>


<div>4. a string is an ordered sequence of Unicode code =
points</div></div></div></div></blockquote><div><br></div><div>Indeed, =
this aligns very well with my =
perspective</div><div><br></div><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div><br></div><div>Item 2 maybe surprising to =
some people, but there's not really much choice given that JS preserves =
the order of object keys. &nbsp;The difficult case is number. But even =
with number, I would argue that there are clearly some lexical values =
that can uncontroversially be specified to be equivalent (for example, =
1e1 with 1E1 or 1e1 with 1e+1). &nbsp;A set of decisions on lexical =
equivalence effectively determines a value space for numbers. &nbsp;For =
example, you might reasonably decide that two values are equivalent if =
they represent real numbers with the same mathematical value.</div>


<div><br></div><div>If ECMA-404 doesn't provide such a semantic layer, =
it becomes quite challenging for higher-level language bindings to =
specify their semantics in a truly rigorous way. &nbsp;Take strings for =
example. &nbsp;I think by far the cleanest way to rigorously define a =
mapping from string tokens to sequences of code points is to have a BNF =
and a syntax-directed mapping as the ECMAScript spec does very nicely in =
7.8.4 (<a =
href=3D"http://www.ecma-international.org/ecma-262/5.1/#sec-7.8.4" =
target=3D"_blank">http://www.ecma-international.org/ecma-262/5.1/#sec-7.8.=
4</a>). &nbsp;If ECMA-404 provides merely a syntax and a specification =
of string equivalence, it becomes quite a challenge to draft a =
specification that somehow expresses the mapping while still normatively =
relying on the ECMA-404 spec for the syntax. What will happen in =
practice is that these higher level mapping will not be specified =
rigorously.</div>


<div><br></div><div>I think ECMA-404 would be significantly more useful =
for its intended purpose if it provided the kind of semantics I am =
suggesting.</div><div><br></div><div>I know XML is not very fashionable =
these days but we have a couple of decades of experience with XML and =
SGML which I think do have some relevance to a specification of =
"structured data interchange between programming language". &nbsp; One =
conclusion I would draw from this experience is that the concept of an =
XML Infoset or something like it is very useful. &nbsp;Most users of XML =
deal with higher-level semantic abstractions rather than directly with =
the XML Infoset, but it has proven very useful to be able to specify =
these higher-level semantic abstractions in terms of the XML Infoset =
rather than having to specify them directly in terms of the XML syntax. =
&nbsp;Another conclusion I would draw is that it would have worked much =
better to integrate the XML Infoset specification into the main XML =
specification. &nbsp;The approach of having a separate XML Infoset =
specification has meant that there is no proper rigorous specification =
how to map from the XML syntax to the XML Infoset (it seems to be =
assumed to be so obvious that it does not need stating). &nbsp;I tried =
an integrated approach of specifying the syntax and data model together =
in the MicroXML spec (<a =
href=3D"https://dvcs.w3.org/hg/microxml/raw-file/tip/spec/microxml.html" =
target=3D"_blank">https://dvcs.w3.org/hg/microxml/raw-file/tip/spec/microx=
ml.html</a>), and I think it works much better. The current approach of =
ECMA-404 is a bit like that of the XML Recommendation: it pretends at =
times to be just specifying when a sequence of code points is valid, and =
yet the specification contains a fairly random selection of statements =
of how a valid sequence should be =
interpreted.&nbsp;</div></div></div></div></blockquote><div><br></div><div=
>Thank you, this is very useful feedback. &nbsp;Would you mind submit =
this as a bug report against ECMA-404 at <a =
href=3D"http://bugs.ecmascript.org">bugs.ecmascript.org</a>&nbsp;? I can =
do it, but community feedback is important and I'd like to to be on the =
CC list for the =
bug.</div><div><br></div><div>Allen</div><div><br></div><br><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote">


<div><br></div><div>James</div><div><br></div></div></div></div>
</blockquote></div><br></body></html>=

--Apple-Mail-191-398480966--

From allen@wirfs-brock.com  Tue Dec 10 18:14:41 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1F41AE309 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 18:14:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 o6-hzgTkIj0f for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 18:14:40 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id A476E1AC829 for <json@ietf.org>; Tue, 10 Dec 2013 18:14:40 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1VqZJo-0002v2-UD; Wed, 11 Dec 2013 02:14:33 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/R/sBeyqwcJXv5e+qMPb2IEPvKD76NimA=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <52A6E807.9050103@it.aoyama.ac.jp>
Date: Tue, 10 Dec 2013 18:14:23 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <5D031FF2-D94D-4381-8DA7-DC3195D5E005@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp> <E19BDE18-DA46-4C00-AA6C-205C348326AD@tzi.org> <52A59337.4050609@it.aoyama.ac.jp> <2AA6AE6A-C76D-4B61-BFE1-0EBDFB715D6D@tzi.org> <8E4C7969-7868-4DE9-A9B0-C7FD484075B1@wirfs-brock.com> <52A6E807.9050103@it.aoyama.ac.jp>
To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= <duerst@it.aoyama.ac.jp>
X-Mailer: Apple Mail (2.1085)
Cc: Carsten Bormann <cabo@tzi.org>, JSON WG <json@ietf.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 02:14:41 -0000

On Dec 10, 2013, at 2:08 AM, Martin J. D=FCrst wrote:

> On 2013/12/10 9:32, Allen Wirfs-Brock wrote:
>=20
>> ...
>=20
>> Specs. can have both technical and editorial bugs.  If you think =
there are bugs in ECMA-404 the best thing to do is to submit a bug =
ticket at bugs.ecmascript.org. If there is a critical bug that you think =
prevents 4627bis from normatively referencing ECMA-404 say so and assign =
the bug a high priority in the initial ticket.  But please, start with =
actual errors, ambiguities, inconsistencies, or similar substantive =
issue.  Stylistic issues won't be ignore but they are less important and =
harder to reach agreement on.
>=20
> I'll submit some. What about the ECMA people submitting some bug =
reports on 4627bis in return?

Is there a bug tracking system or are perceived bugs simply submitted to =
the mailing list.

I'm  some of the friction around here is simply a mater of poorly =
understood processes and differing social conventions.

Allen


From allen@wirfs-brock.com  Tue Dec 10 18:45:23 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828E31AE0EA for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 18:45:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level: 
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 N9jnm2Hy78Lj for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 18:45:20 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4981ADFEE for <json@ietf.org>; Tue, 10 Dec 2013 18:45:20 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1VqZnW-000KIo-Jz; Wed, 11 Dec 2013 02:45:15 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19L2Rqqci/3lmPNyOa6OWqleHQsoEg8tUk=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <905fa99h0ub9bu39sj8ada6m4aa6t2actn@hive.bjoern.hoehrmann.de>
Date: Tue, 10 Dec 2013 18:45:11 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <C9EC9A07-E416-4017-AD97-93B8AC6029EE@wirfs-brock.com>
References: <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp> <E19BDE18-DA46-4C00-AA6C-205C348326AD@tzi.org> <52A59337.4050609@it.aoyama.ac.jp> <2AA6AE6A-C76D-4B61-BFE1-0EBDFB715D6D@tzi.org> <8E4C7969-7868-4DE9-A9B0-C7FD484075B1@wirfs-brock.com> <serca9lle8m19n7ikdhf9ldlcoo8b9mpos@hive.bjoern.hoehrmann.de> <1E12FB6A-BD61-4E51-89E9-4398F943FF8F@wirfs-brock.com> <905fa99h0ub9bu39sj8ada6m4aa6t2actn@hive.bjoern.hoehrmann.de>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
X-Mailer: Apple Mail (2.1085)
Cc: "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, www-tag@w3.org, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 02:45:23 -0000

On Dec 10, 2013, at 3:08 PM, Bjoern Hoehrmann wrote:

> * Allen Wirfs-Brock wrote:
>> On Dec 9, 2013, at 5:40 PM, Bjoern Hoehrmann wrote:
>>> If TC39 said ECMA-404 is going to be replaced by a verbatim copy of =
the
>>> ABNF grammar in draft-ietf-json-rfc4627bis-08 with pretty much no =
other
>>> discussion of JSON and a clear indication that future editions will =
not
>>> add such discussion, and will not change the grammar without IETF =
con-
>>> sensus, I would be willing to entertain the idea of making ECMA-404 =
a
>>> normative reference.
>=20
>> The second paragraph is speaking about the language described by the=20=

>> grammar, not the actual formalism used to express the grammar. I'm =
quite=20
>> sure that there is no interest at all within TC39 to ever change the=20=

>> actual JSON language.  If you are looking for some sort of =
contractual=20
>> commitment from ECMA, I suspect you are wasting your time. Does the =
IETF=20
>> make such commitments?
>=20
> As you know, the charter of the JSON Working Group says
>=20
>  The resulting document will be jointly published as an RFC and by
>  ECMA. ECMA participants will be participating in the working group=20
>  editing through the normal process of working group participation. =20=

>  The responsible AD will coordinate the approval process with ECMA so=20=

>  that the versions of the document that are approved by each body are=20=

>  the same.
>=20
> If things had gone according to plan, it seems likely that Ecma would
> have requested the IANA registration for application/json jointly =
lists
> the IETF and Ecma International has holding Change Control over it, =
and
> it seems unlikely there would have been much disagreement about that.
>=20
> It is normal to award change control to other organisations, for
> instance, RFC 3023 gives change control for the XML media types to the
> W3C. I can look up examples for jointly held change control if that
> would help.
>=20
> And no, I am not looking for an enforceable contract, just a clear
> formal decision and statement.

Obviously, the originally envisioned process broke down, but I don't =
think we need to discuss that right here, right now.

It isn't clear to me that TC39 is particularly interested in holding =
changing control for the application/json media type just like it =
apparently doesn't have change control for the application/ecmascript or =
application/javascript. In practice those registrations simply have not =
been of particular concern.  Maybe they should be.  Does anybody =
actually lookup the application/javascript media type actually think =
that the relevant reference is still Netscape Communications Corp., =
"Core JavaScript Reference 1.5", September 2000

TC39's concern seems to be both narrower (just the JSON syntax and =
static semantics, not wire encodings) and wider (implementations that =
aren't tied to the application/json media type) than the JSON WG's. I =
know that the TC39 consensus is that ECMA-404 (probably with some =
revision)  should be serviceable as a foundation for other specs that =
address other issues.

>=20
>> This doesn't mean that TC39 would necessarily agree to eliminate the=20=

>> Syntax Diagrams,  or that we wouldn't carefully audit any grammar=20
>> contribution to make sure that it is describing the same language. =20=

>> There may also be minor issues that need to be resolved. But we seem =
to=20
>> agree that we already are both accurately describing the same =
language=20
>> so this is really about notational agreement.
>=20
> Having non-normative syntax diagrams in addition to the ABNF grammar
> would be fine if they can automatically be generated from the ABNF.
>=20
> I was talking about removing most of the prose, leaving only boiler-
> plate, a very short introduction, and references. Then it would be a
> specification of only the syntax and most technical concerns would be
> addressed on both sides. If you see this as a viable way forward, then
> I think the JSON WG should explore this option further.

I agree, this sounds plausible to me.

>=20
>> As a base line, ECMA-404 was created in less than a week.  It takes a=20=

>> couple months to push through a letter ballot to above a revised=20
>> standard.=20
>=20
> The RFC4627bis draft could be approved and be held for normatives re-
> ferences to materialise; this is not uncommon for IETF standards. It
> usually takes a couple of months for the RFC editor to process the
> document anyway, so personally a couple of months of waiting for a
> revised edition of ECMA-404 would be okay with me.

I don't see why we should be about to mutually resolve this.=20

Allen



> --=20
> Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 =
http://bjoern.hoehrmann.de
> Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 =
http://www.bjoernsworld.de
> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 =
http://www.websitedev.de/=20
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>=20


From allen@wirfs-brock.com  Tue Dec 10 18:53:08 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243221AE0FF for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 18:53:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level: 
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 g3GEaVSE0nm0 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 18:53:05 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0471AE0D8 for <json@ietf.org>; Tue, 10 Dec 2013 18:53:05 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1VqZv1-000Njb-Of; Wed, 11 Dec 2013 02:53:00 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19S751iOGJHHO2EFtqh2ArRiO2T1cImq0U=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <905fa99h0ub9bu39sj8ada6m4aa6t2actn@hive.bjoern.hoehrmann.de>
Date: Tue, 10 Dec 2013 18:52:53 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <B86533F4-DEFB-47A0-A2A1-A92F9B9C0CBD@wirfs-brock.com>
References: <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp> <E19BDE18-DA46-4C00-AA6C-205C348326AD@tzi.org> <52A59337.4050609@it.aoyama.ac.jp> <2AA6AE6A-C76D-4B61-BFE1-0EBDFB715D6D@tzi.org> <8E4C7969-7868-4DE9-A9B0-C7FD484075B1@wirfs-brock.com> <serca9lle8m19n7ikdhf9ldlcoo8b9mpos@hive.bjoern.hoehrmann.de> <1E12FB6A-BD61-4E51-89E9-4398F943FF8F@wirfs-brock.com> <905fa99h0ub9bu39sj8ada6m4aa6t2actn@hive.bjoern.hoehrmann.de>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
X-Mailer: Apple Mail (2.1085)
Cc: "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, www-tag@w3.org, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 02:53:08 -0000

(important typo correction in last paragraph)=20
On Dec 10, 2013, at 3:08 PM, Bjoern Hoehrmann wrote:

> * Allen Wirfs-Brock wrote:
>> On Dec 9, 2013, at 5:40 PM, Bjoern Hoehrmann wrote:
>>> If TC39 said ECMA-404 is going to be replaced by a verbatim copy of =
the
>>> ABNF grammar in draft-ietf-json-rfc4627bis-08 with pretty much no =
other
>>> discussion of JSON and a clear indication that future editions will =
not
>>> add such discussion, and will not change the grammar without IETF =
con-
>>> sensus, I would be willing to entertain the idea of making ECMA-404 =
a
>>> normative reference.
>=20
>> The second paragraph is speaking about the language described by the=20=

>> grammar, not the actual formalism used to express the grammar. I'm =
quite=20
>> sure that there is no interest at all within TC39 to ever change the=20=

>> actual JSON language.  If you are looking for some sort of =
contractual=20
>> commitment from ECMA, I suspect you are wasting your time. Does the =
IETF=20
>> make such commitments?
>=20
> As you know, the charter of the JSON Working Group says
>=20
> The resulting document will be jointly published as an RFC and by
> ECMA. ECMA participants will be participating in the working group=20
> editing through the normal process of working group participation. =20
> The responsible AD will coordinate the approval process with ECMA so=20=

> that the versions of the document that are approved by each body are=20=

> the same.
>=20
> If things had gone according to plan, it seems likely that Ecma would
> have requested the IANA registration for application/json jointly =
lists
> the IETF and Ecma International has holding Change Control over it, =
and
> it seems unlikely there would have been much disagreement about that.
>=20
> It is normal to award change control to other organisations, for
> instance, RFC 3023 gives change control for the XML media types to the
> W3C. I can look up examples for jointly held change control if that
> would help.
>=20
> And no, I am not looking for an enforceable contract, just a clear
> formal decision and statement.

Obviously, the originally envisioned process broke down, but I don't =
think we need to discuss that right here, right now.

It isn't clear to me that TC39 is particularly interested in holding =
changing control for the application/json media type just like it =
apparently doesn't have change control for the application/ecmascript or =
application/javascript. In practice those registrations simply have not =
been of particular concern.  Maybe they should be.  Does anybody =
actually lookup the application/javascript media type actually think =
that the relevant reference is still Netscape Communications Corp., =
"Core JavaScript Reference 1.5", September 2000

TC39's concern seems to be both narrower (just the JSON syntax and =
static semantics, not wire encodings) and wider (implementations that =
aren't tied to the application/json media type) than the JSON WG's. I =
know that the TC39 consensus is that ECMA-404 (probably with some =
revision)  should be serviceable as a foundation for other specs that =
address other issues.

>=20
>> This doesn't mean that TC39 would necessarily agree to eliminate the=20=

>> Syntax Diagrams,  or that we wouldn't carefully audit any grammar=20
>> contribution to make sure that it is describing the same language. =20=

>> There may also be minor issues that need to be resolved. But we seem =
to=20
>> agree that we already are both accurately describing the same =
language=20
>> so this is really about notational agreement.
>=20
> Having non-normative syntax diagrams in addition to the ABNF grammar
> would be fine if they can automatically be generated from the ABNF.
>=20
> I was talking about removing most of the prose, leaving only boiler-
> plate, a very short introduction, and references. Then it would be a
> specification of only the syntax and most technical concerns would be
> addressed on both sides. If you see this as a viable way forward, then
> I think the JSON WG should explore this option further.

I agree, this sounds plausible to me.

>=20
>> As a base line, ECMA-404 was created in less than a week.  It takes a=20=

>> couple months to push through a letter ballot to above a revised=20
>> standard.=20
>=20
> The RFC4627bis draft could be approved and be held for normatives re-
> ferences to materialise; this is not uncommon for IETF standards. It
> usually takes a couple of months for the RFC editor to process the
> document anyway, so personally a couple of months of waiting for a
> revised edition of ECMA-404 would be okay with me.

I don't see why we >shouldn't< be about to mutually resolve this.=20

Allen



> --=20
> Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 =
http://bjoern.hoehrmann.de
> Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 =
http://www.bjoernsworld.de
> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 =
http://www.websitedev.de/=20
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>=20


From jjc@jclark.com  Tue Dec 10 20:45:26 2013
Return-Path: <jjc@jclark.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7891AE183 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 20:45:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 0hPLdreFl5SJ for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 20:45:23 -0800 (PST)
Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by ietfa.amsl.com (Postfix) with ESMTP id 931061A1F5F for <json@ietf.org>; Tue, 10 Dec 2013 20:45:23 -0800 (PST)
Received: by mail-vb0-f49.google.com with SMTP id x11so1233049vbb.8 for <json@ietf.org>; Tue, 10 Dec 2013 20:45:18 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=2N2X+eAnCanoDvos2zuzae2PKZ9XTxDjueZO3zZtgFk=; b=mzb5VYuGGsdjfmfBk1GXk/JNXn65twWyFRh235Q0t+xE3NgVmZnNobj8r3VPKEZfEU nSLf/gadNqkp9aL+CWnbZXKbAr1mDjiFX6nKcAHOdr4okWj8bAdXsHh4WWLwYfAX0Txy p9aGKmNg6fWjrq2s8LPDypWvQU4X3OgG8rDSn3LIyT6yF6aybf1hdJtCk357U/WwRsT9 NXeUXjWWq3gwrWpO5bvJkmATvyPrSMDXfcvQeKNmWXRd62Vs8KzysbcBHCJu4o8xhjzE iRo5bOkMYO/gCipxUQg2L83sBobiwTbq5y2ZP0B8GTZFziO1/sdJpHwYOkj6SXUa99jL 35FQ==
X-Gm-Message-State: ALoCoQnJY+L9+9kiHEVWSL+IFmf8gmL0a4QmUD5uLT8jeFOtMGj6Gu21gmf8s/fUHVcKHXRKsUPx
X-Received: by 10.220.91.10 with SMTP id k10mr15817574vcm.7.1386737117926; Tue, 10 Dec 2013 20:45:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.164.231 with HTTP; Tue, 10 Dec 2013 20:44:57 -0800 (PST)
In-Reply-To: <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com>
From: James Clark <jjc@jclark.com>
Date: Wed, 11 Dec 2013 11:44:57 +0700
Message-ID: <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
Content-Type: multipart/alternative; boundary=047d7b34408c4faba704ed3ae5cb
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, Carsten Bormann <cabo@tzi.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Ladislav Lhotka <lhotka@nic.cz>, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 04:45:26 -0000

--047d7b34408c4faba704ed3ae5cb
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Let's not get distracted by the XML Infoset analogy.  If you don't find it
helpful, just ignore it.  It's not my main point.

The concrete benefit to actual JSON users would be better interop. Let's
examine how this might work out for numbers:

- The spec would say that a number token represents the rational number
x/(10^n), where n is a non-negative integer and x is an integer, and x is
not a multiple of 10 unless n is 0.
- The spec would _not_ require conforming parsers to provide this rational
number
- The spec _would_ require conforming parsers to interpret identically two
number tokens that represent the same rational number.

This would address the interop problem Carsten referred to, where you have
a mismatch of expectations between a producer that makes no distinction
between floats and ints, a consumer that does make this distinction.  For
example, a producer generates 1.0 expecting it to be treated the same as 1,
but a consumer treats 1.0 and 1 differently.  With the spec language I am
suggesting, such a consumer would be non-conforming (because the tokens 1.0
and 1 represent the same rational number).  If it treats 1 as an integer,
it would have to also treat 1.0 and 1e0 as integers.

Note that it addresses the interop problem without unnecessarily
constraining implementations: an implementation using IEEE doubles would be
conforming, but it also allows conforming implementations to use alternate
representations.

The other concrete benefit is that it can help avoid duplication and
inconsistency between the IETF and ECMA specs.  Despite claims to the
contrary, the ECMA spec does go beyond syntax and already gets into
specifying how syntax should be interpreted: this is obvious particularly
in the case of strings.  If the ECMA spec gets its act together in a future
revision, then I believe it will contain some sort of abstract data model,
but the data model will be different to the one in the IETF spec (to the
extent that the IETF spec has one).  For example, the ECMA spec needs the
order of key/value pairs in an object to be significant whereas the IETF
spec says it is not.  The way to deal with this is by careful spec layering=
.

James


On Wed, Dec 11, 2013 at 12:33 AM, Tim Bray <tbray@textuality.com> wrote:

> This discussion feels like a waste of time.  The XML Infoset was necessar=
y
> because it was essentially impossible to write specs for XML-based
> languages because the syntax spec didn=92t provide words to talk about th=
em.
>  I have dealt with loads of protocol specs that depend on JSON and the
> equivalent stress doesn=92t exist: =94X will be encoded as an object with=
 the
> following keys required and the following optional=94. =93Y will be encod=
ed as
> a list all of whose members are X=92s=94. =93Y will be a number which can=
 be
> represented in a signed 16-bit integer=94. Etc.
>
> I see no benefits to the actual users of JSON coming out of this.
>
>
> On Tue, Dec 10, 2013 at 4:06 AM, Carsten Bormann <cabo@tzi.org> wrote:
>
>> On 10 Dec 2013, at 12:59, Ladislav Lhotka <lhotka@nic.cz> wrote:
>>
>> > How about =93information model=94/=93data model=94 (cf. RFC 3444)?
>>
>> Well, the information model is the more abstract one, so in this
>> dichotomy today=92s data model would become the information model and th=
e
>> infoset would become the data model.  Ouch.
>>
>> Maybe we can find those terms later instead of muddling our current
>> discussion with the search for terms.  We know exactly what infoset and
>> data model mean in this context, so let=92s continue to use these terms =
until
>> some stroke of genius supplies us with better ones.
>>
>> Gr=FC=DFe, Carsten
>>
>> _______________________________________________
>> json mailing list
>> json@ietf.org
>> https://www.ietf.org/mailman/listinfo/json
>>
>
>

--047d7b34408c4faba704ed3ae5cb
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Let&#39;s not get distracted by the XML Infoset analo=
gy. =A0If you don&#39;t find it helpful, just ignore it. =A0It&#39;s not my=
 main point.</div><div><br></div><div>The concrete benefit to actual JSON u=
sers would be better interop. Let&#39;s examine how this might work out for=
 numbers:</div>

<div><br></div><div>- The spec would say that a number token represents the=
 rational number x/(10^n), where n is a non-negative integer and x is an in=
teger, and x is not a multiple of 10 unless n is 0.</div><div>- The spec wo=
uld _not_ require conforming parsers to provide this rational number=A0</di=
v>

<div>- The spec _would_ require conforming parsers to interpret identically=
 two number tokens that represent the same rational number.</div><div><br><=
/div><div>This would address the interop problem Carsten referred to, where=
 you have a mismatch of expectations between a producer that makes no disti=
nction between floats and ints, a consumer that does make this distinction.=
 =A0For example, a producer generates 1.0 expecting it to be treated the sa=
me as 1, but a consumer treats 1.0 and 1 differently. =A0With the spec lang=
uage I am suggesting, such a consumer would be non-conforming (because the =
tokens 1.0 and 1 represent the same rational number). =A0If it treats 1 as =
an integer, it would have to also treat 1.0 and 1e0 as integers.</div>

<div><br></div><div>Note that it addresses the interop problem without unne=
cessarily constraining implementations: an implementation using IEEE double=
s would be conforming, but it also allows conforming implementations to use=
 alternate representations.</div>

<div><br></div><div>The other concrete benefit is that it can help avoid du=
plication and inconsistency between the IETF and ECMA specs. =A0Despite cla=
ims to the contrary, the ECMA spec does go beyond syntax and already gets i=
nto specifying how syntax should be interpreted: this is obvious particular=
ly in the case of strings. =A0If the ECMA spec gets its act together in a f=
uture revision, then I believe it will contain some sort of abstract data m=
odel, but the data model will be different to the one in the IETF spec (to =
the extent that the IETF spec has one). =A0For example, the ECMA spec needs=
 the order of key/value pairs in an object to be significant whereas the IE=
TF spec says it is not. =A0The way to deal with this is by careful spec lay=
ering.</div>

<div><br></div><div>James</div></div><div class=3D"gmail_extra"><br><br><di=
v class=3D"gmail_quote">On Wed, Dec 11, 2013 at 12:33 AM, Tim Bray <span di=
r=3D"ltr">&lt;<a href=3D"mailto:tbray@textuality.com" target=3D"_blank">tbr=
ay@textuality.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">This discussion feels like =
a waste of time. =A0The XML Infoset was necessary because it was essentiall=
y impossible to write specs for XML-based languages because the syntax spec=
 didn=92t provide words to talk about them. =A0I have dealt with loads of p=
rotocol specs that depend on JSON and the equivalent stress doesn=92t exist=
: =94X will be encoded as an object with the following keys required and th=
e following optional=94. =93Y will be encoded as a list all of whose member=
s are X=92s=94. =93Y will be a number which can be represented in a signed =
16-bit integer=94. Etc.<div>


<br></div><div>I see no benefits to the actual users of JSON coming out of =
this.</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quo=
te"><div><div class=3D"h5">On Tue, Dec 10, 2013 at 4:06 AM, Carsten Bormann=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:cabo@tzi.org" target=3D"_blank">ca=
bo@tzi.org</a>&gt;</span> wrote:<br>


</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div>On 1=
0 Dec 2013, at 12:59, Ladislav Lhotka &lt;<a href=3D"mailto:lhotka@nic.cz" =
target=3D"_blank">lhotka@nic.cz</a>&gt; wrote:<br>



<br>
&gt; How about =93information model=94/=93data model=94 (cf. RFC 3444)?<br>
<br>
</div>Well, the information model is the more abstract one, so in this dich=
otomy today=92s data model would become the information model and the infos=
et would become the data model. =A0Ouch.<br>
<br>
Maybe we can find those terms later instead of muddling our current discuss=
ion with the search for terms. =A0We know exactly what infoset and data mod=
el mean in this context, so let=92s continue to use these terms until some =
stroke of genius supplies us with better ones.<br>



<br>
Gr=FC=DFe, Carsten<br>
</div></div><div><div><br><div class=3D"im">
_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org" target=3D"_blank">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
</div></div></div></blockquote></div><br></div>
</blockquote></div><br></div>

--047d7b34408c4faba704ed3ae5cb--

From sayrer@gmail.com  Tue Dec 10 20:59:47 2013
Return-Path: <sayrer@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CA31AE18F for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 20:59:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
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 PumbfDcLC6IR for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 20:59:45 -0800 (PST)
Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E8CC51AC7F1 for <json@ietf.org>; Tue, 10 Dec 2013 20:59:44 -0800 (PST)
Received: by mail-qe0-f43.google.com with SMTP id 2so5082049qeb.30 for <json@ietf.org>; Tue, 10 Dec 2013 20:59:39 -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:content-type; bh=RY5UENcwEAIn/qARysf9eU0Ua9+aPfgLOtDgR6TeZJw=; b=GZr2WdNKOpeq3UG4jKUC0PdZVXprR9/mz+evATRQ7Xhtkcv9Yz+8mBbnG4XIRVvyP3 fee3Iq0uKKbsMTWO2QOpTmoOzp+GSKPgbxdQ0NFQZp40Elo6+x3p5e3N2R+nxgncDKEj PaZpFc1HdT+W69+DZtmc+a6Mbnr76NKfq0Ln3a5WQhTxj4MLTkIHoaTTS476Pfqz1txr FwYpDb8o2dIpF9U7PpyCnIDXiCNn3otwHF/OiBukpiBxKI1nh3+gVOdwu269GJ/Vjj3J nAPU9McE1icDswHohjuK7t/CEJLNOggLZ3sJhGMn7i59XrGHcCeLNCFilZY+ZXps1wXA xX+w==
MIME-Version: 1.0
X-Received: by 10.224.65.130 with SMTP id j2mr51111022qai.4.1386737979011; Tue, 10 Dec 2013 20:59:39 -0800 (PST)
Received: by 10.140.101.40 with HTTP; Tue, 10 Dec 2013 20:59:38 -0800 (PST)
In-Reply-To: <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com>
Date: Tue, 10 Dec 2013 20:59:38 -0800
Message-ID: <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com>
From: R S <sayrer@gmail.com>
To: James Clark <jjc@jclark.com>
Content-Type: multipart/alternative; boundary=001a11c2c08ca2b68504ed3b1886
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, Ladislav Lhotka <lhotka@nic.cz>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Carsten Bormann <cabo@tzi.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 04:59:47 -0000

--001a11c2c08ca2b68504ed3b1886
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 10, 2013 at 8:44 PM, James Clark <jjc@jclark.com> wrote:

> For example, the ECMA spec needs the order of key/value pairs in an objec=
t
> to be significant
>

I don't think ECMA-404 has such a requirement. In fact, it says otherwise
in at least two places.



> whereas the IETF spec says it is not.
>

Section 4 ("Objects") contains a SHOULD-level requirement on name
uniqueness.



> The way to deal with this is by careful spec layering.
>

An alternative way to deal with this is to write less in the IETF spec, and
use a normative reference to ECMA-404.

- Rob



> James
>
>
> On Wed, Dec 11, 2013 at 12:33 AM, Tim Bray <tbray@textuality.com> wrote:
>
>> This discussion feels like a waste of time.  The XML Infoset was
>> necessary because it was essentially impossible to write specs for
>> XML-based languages because the syntax spec didn=92t provide words to ta=
lk
>> about them.  I have dealt with loads of protocol specs that depend on JS=
ON
>> and the equivalent stress doesn=92t exist: =94X will be encoded as an ob=
ject
>> with the following keys required and the following optional=94. =93Y wil=
l be
>> encoded as a list all of whose members are X=92s=94. =93Y will be a numb=
er which
>> can be represented in a signed 16-bit integer=94. Etc.
>>
>> I see no benefits to the actual users of JSON coming out of this.
>>
>>
>> On Tue, Dec 10, 2013 at 4:06 AM, Carsten Bormann <cabo@tzi.org> wrote:
>>
>>> On 10 Dec 2013, at 12:59, Ladislav Lhotka <lhotka@nic.cz> wrote:
>>>
>>> > How about =93information model=94/=93data model=94 (cf. RFC 3444)?
>>>
>>> Well, the information model is the more abstract one, so in this
>>> dichotomy today=92s data model would become the information model and t=
he
>>> infoset would become the data model.  Ouch.
>>>
>>> Maybe we can find those terms later instead of muddling our current
>>> discussion with the search for terms.  We know exactly what infoset and
>>> data model mean in this context, so let=92s continue to use these terms=
 until
>>> some stroke of genius supplies us with better ones.
>>>
>>> Gr=FC=DFe, Carsten
>>>
>>> _______________________________________________
>>> json mailing list
>>> json@ietf.org
>>> https://www.ietf.org/mailman/listinfo/json
>>>
>>
>>
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>
>

--001a11c2c08ca2b68504ed3b1886
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Dec 10, 2013 at 8:44 PM, James Clark <span dir=3D"=
ltr">&lt;<a href=3D"mailto:jjc@jclark.com" target=3D"_blank">jjc@jclark.com=
</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>For example, the ECMA spec needs the order of key/val=
ue pairs in an object to be significant</div></div></blockquote><div><br></=
div><div>I don&#39;t think ECMA-404 has such a requirement. In fact, it say=
s otherwise in at least two places.=A0</div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div> whereas the IETF spec says it is not. =A0<br></div></div></blockquo=
te><div>
<br></div><div>Section 4 (&quot;Objects&quot;) contains a SHOULD-level requ=
irement on name uniqueness.</div><div><br></div><div>=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<div dir=3D"ltr"><div>The way to deal with this is by careful spec layering=
.</div></div></blockquote><div><br></div><div>An alternative way to deal wi=
th this is to write less in the IETF spec, and use a normative reference to=
 ECMA-404.</div>
<div><br></div><div>- Rob</div><div><br></div><div>=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><span class=3D"HOEnZb"><font color=3D"#888=
888"><div>
James</div></font></span></div><div class=3D"HOEnZb"><div class=3D"h5"><div=
 class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Dec 11, 2=
013 at 12:33 AM, Tim Bray <span dir=3D"ltr">&lt;<a href=3D"mailto:tbray@tex=
tuality.com" target=3D"_blank">tbray@textuality.com</a>&gt;</span> wrote:<b=
r>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">This discussion feels like =
a waste of time. =A0The XML Infoset was necessary because it was essentiall=
y impossible to write specs for XML-based languages because the syntax spec=
 didn=92t provide words to talk about them. =A0I have dealt with loads of p=
rotocol specs that depend on JSON and the equivalent stress doesn=92t exist=
: =94X will be encoded as an object with the following keys required and th=
e following optional=94. =93Y will be encoded as a list all of whose member=
s are X=92s=94. =93Y will be a number which can be represented in a signed =
16-bit integer=94. Etc.<div>



<br></div><div>I see no benefits to the actual users of JSON coming out of =
this.</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quo=
te"><div><div>On Tue, Dec 10, 2013 at 4:06 AM, Carsten Bormann <span dir=3D=
"ltr">&lt;<a href=3D"mailto:cabo@tzi.org" target=3D"_blank">cabo@tzi.org</a=
>&gt;</span> wrote:<br>



</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div><div>On 10 Dec 2013, a=
t 12:59, Ladislav Lhotka &lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_bl=
ank">lhotka@nic.cz</a>&gt; wrote:<br>




<br>
&gt; How about =93information model=94/=93data model=94 (cf. RFC 3444)?<br>
<br>
</div>Well, the information model is the more abstract one, so in this dich=
otomy today=92s data model would become the information model and the infos=
et would become the data model. =A0Ouch.<br>
<br>
Maybe we can find those terms later instead of muddling our current discuss=
ion with the search for terms. =A0We know exactly what infoset and data mod=
el mean in this context, so let=92s continue to use these terms until some =
stroke of genius supplies us with better ones.<br>




<br>
Gr=FC=DFe, Carsten<br>
</div></div><div><div><br><div>
_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org" target=3D"_blank">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
</div></div></div></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
<br></blockquote></div><br></div></div>

--001a11c2c08ca2b68504ed3b1886--

From jjc@jclark.com  Tue Dec 10 21:28:40 2013
Return-Path: <jjc@jclark.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D811AE197 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 21:28:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 ERfGlz8tvxct for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 21:28:38 -0800 (PST)
Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 792161ADFB6 for <json@ietf.org>; Tue, 10 Dec 2013 21:28:38 -0800 (PST)
Received: by mail-vc0-f178.google.com with SMTP id lh4so5237959vcb.23 for <json@ietf.org>; Tue, 10 Dec 2013 21:28:32 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=Vj6g/QLDr8KzkP1PQhElcV1xZsKWuPcjnmGQqyyKplo=; b=AYLXrb9IMgO7EA7fUsocXSk8CFJUtaXzcKaTMcwbV0B7JZTDQ5Pj5tt6XCBlcR/G8R 9N0rmCjVMs+/3dJ9OUx2Wtwj1DLcruzfynZmaLeLvT7ZLUdKBtBs6D0SfxKmNhY/w4VO kPhn35A1usq8PG3w/MsdjZ2ZaFP9sp2HE7QCcBPk5bSi3CqZNZm4Xwwf9G4vGoU5befB +/h4glsGTyzx5aN+wfzP7PxcNji8/70uLkguJVnBSeywE0RWQwbITm/QtiQm9SBcor7J KROQytevgp8hMTMGkAYch1M67o+H+ShCeBTyVEgfa/NDFiSmoZrH58BO2U8825yqcRpn v/dw==
X-Gm-Message-State: ALoCoQllIcBMW0Jqkt44LE4RbY9bwqeQYbhZSMn6ICU/NbwrmTRh0VAgnt823Ik6sew3R7zuvDNQ
X-Received: by 10.220.3.144 with SMTP id 16mr1812019vcn.33.1386739712752; Tue, 10 Dec 2013 21:28:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.164.231 with HTTP; Tue, 10 Dec 2013 21:28:11 -0800 (PST)
In-Reply-To: <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com>
From: James Clark <jjc@jclark.com>
Date: Wed, 11 Dec 2013 12:28:11 +0700
Message-ID: <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com>
To: R S <sayrer@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c3cbcef9957904ed3b7f29
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, Ladislav Lhotka <lhotka@nic.cz>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Carsten Bormann <cabo@tzi.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 05:28:40 -0000

--001a11c3cbcef9957904ed3b7f29
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Dec 11, 2013 at 11:59 AM, R S <sayrer@gmail.com> wrote:

> On Tue, Dec 10, 2013 at 8:44 PM, James Clark <jjc@jclark.com> wrote:
>
>> For example, the ECMA spec needs the order of key/value pairs in an
>> object to be significant
>>
>
> I don't think ECMA-404 has such a requirement. In fact, it says otherwise
> in at least two places.
>

Earlier in this discussion I believe AWB said he thought that ECMA-404
shouldn't say so.

In JavaScript, objects do preserve the order of keys, and many programs
rely on this.  ECMAScript 5 doesn't specify this, but I was under the
impression that TC39 plans to fix this.  The ES6 draft currently depends on
ECMAScript evaluation semantics to determine the value represented by a
JSON text. So assuming TC39 fixes ECMAScript at some point to match the
reality on the Web, JSON.parse will specified to preserve order. I believe
current implementations of JSON.parse already do so.

Maybe I am worrying unnecessarily about this.  It would certainly make life
simpler to be able to say JSON objects are unordered collections without
qualification.  But I suspect that this doesn't reflect reality on the Web.


>  The way to deal with this is by careful spec layering.
>>
>
> An alternative way to deal with this is to write less in the IETF spec,
> and use a normative reference to ECMA-404.
>

That is exactly the kind of layering I think we need.

James

--001a11c3cbcef9957904ed3b7f29
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Dec 11, 2013 at 11:59 AM, R S <span dir=3D"ltr">&lt;<a href=3D"mailto:s=
ayrer@gmail.com" target=3D"_blank">sayrer@gmail.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">


<div dir=3D"ltr"><div>On Tue, Dec 10, 2013 at 8:44 PM, James Clark <span di=
r=3D"ltr">&lt;<a href=3D"mailto:jjc@jclark.com" target=3D"_blank">jjc@jclar=
k.com</a>&gt;</span> wrote:<br></div><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">


<div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>For example, the ECMA spec needs the order of key/val=
ue pairs in an object to be significant</div></div></blockquote><div><br></=
div></div><div>I don&#39;t think ECMA-404 has such a requirement. In fact, =
it says otherwise in at least two places.</div>


</div></div></div></blockquote><div><br></div><div>Earlier in this discussi=
on I believe AWB said he thought that ECMA-404 shouldn&#39;t say so.</div><=
div><br></div><div>In JavaScript, objects do preserve the order of keys, an=
d many programs rely on this. =A0ECMAScript 5 doesn&#39;t specify this, but=
 I was under the impression that TC39 plans to fix this. =A0The ES6 draft c=
urrently depends on ECMAScript evaluation semantics to determine the value =
represented by a JSON text. So assuming TC39 fixes ECMAScript at some point=
 to match the reality on the Web, JSON.parse will specified to preserve ord=
er. I believe current implementations of JSON.parse already do so.</div>


<div><br></div><div>Maybe I am worrying unnecessarily about this. =A0It wou=
ld certainly make life simpler to be able to say JSON objects are unordered=
 collections without qualification. =A0But I suspect that this doesn&#39;t =
reflect reality on the Web.</div>


<div>=A0<span style=3D"color:rgb(80,0,80)">=A0</span></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote">

<div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>The way to deal with this is by careful spec layering=
.</div></div></blockquote><div><br></div></div><div>An alternative way to d=
eal with this is to write less in the IETF spec, and use a normative refere=
nce to ECMA-404.</div>


</div></div></div></blockquote><div><br></div><div>That is exactly the kind=
 of layering I think we need.</div><div><br></div><div>James</div></div><br=
></div></div>

--001a11c3cbcef9957904ed3b7f29--

From sayrer@gmail.com  Tue Dec 10 21:48:18 2013
Return-Path: <sayrer@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3690F1AE377 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 21:48:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] autolearn=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 mwgiw50_4Dq4 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 21:48:17 -0800 (PST)
Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBDC1AE1CC for <json@ietf.org>; Tue, 10 Dec 2013 21:48:17 -0800 (PST)
Received: by mail-qc0-f169.google.com with SMTP id r5so4801351qcx.28 for <json@ietf.org>; Tue, 10 Dec 2013 21:48: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:content-type; bh=O19yP4/9jrdxfGhUoqemrLNVe6SYqXWyjzTWuxEjZKA=; b=bjVwjiC02otKdmMBd439uj/zk9O9NuNg6lBkrQgoCHAO51fI40nilCmGsDmUH5JlDr BLjwYU8Aj0/wNZW7OApi8FSYD/1a+UJJH5fCmyJJ6iyb4H0Q0cvFFW6UYxUhcmqG9l7v uufRk5wQti0fBt04jSw8GeAHv2W98DYF3uI5udzDOPserv5aejJjDdzWW6yutbOsLUtE KO6UABShaAXF95eNHeHqWM/SGmCaQyn84hUkgNsDacq2wsIrvzQrCE9bLHTVM/jTZAuo 66ZMYWgH0GDzaKvb6TG7JBHJWNqY4RHNY3hl7abCOJ1OnA986tRynrxxNPDl0LHM+egx PYVg==
MIME-Version: 1.0
X-Received: by 10.224.22.200 with SMTP id o8mr20863661qab.100.1386740891499; Tue, 10 Dec 2013 21:48:11 -0800 (PST)
Received: by 10.140.101.40 with HTTP; Tue, 10 Dec 2013 21:48:11 -0800 (PST)
In-Reply-To: <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com> <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com>
Date: Tue, 10 Dec 2013 21:48:11 -0800
Message-ID: <CAChr6SxjXGyH3cEa9oJTi69nXC8HiO5VP=5c71uMNED_NixiSg@mail.gmail.com>
From: R S <sayrer@gmail.com>
To: James Clark <jjc@jclark.com>
Content-Type: multipart/alternative; boundary=001a11c2be5a3bc23104ed3bc6c8
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, Ladislav Lhotka <lhotka@nic.cz>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Carsten Bormann <cabo@tzi.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 05:48:18 -0000

--001a11c2be5a3bc23104ed3bc6c8
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Dec 10, 2013 at 9:28 PM, James Clark <jjc@jclark.com> wrote:

> On Wed, Dec 11, 2013 at 11:59 AM, R S <sayrer@gmail.com> wrote:
>
>> On Tue, Dec 10, 2013 at 8:44 PM, James Clark <jjc@jclark.com> wrote:
>>
>>> For example, the ECMA spec needs the order of key/value pairs in an
>>> object to be significant
>>>
>>
>> I don't think ECMA-404 has such a requirement. In fact, it says otherwise
>> in at least two places.
>>
>
> Earlier in this discussion I believe AWB said he thought that ECMA-404
> shouldn't say so.
>
> In JavaScript, objects do preserve the order of keys, and many programs
> rely on this.  ECMAScript 5 doesn't specify this, but I was under the
> impression that TC39 plans to fix this.  The ES6 draft currently depends on
> ECMAScript evaluation semantics to determine the value represented by a
> JSON text. So assuming TC39 fixes ECMAScript at some point to match the
> reality on the Web, JSON.parse will specified to preserve order. I believe
> current implementations of JSON.parse already do so.
>

ECMA-404 is a different document than ES5 or ES6. It is 4 pages long.

- Rob



>
>
>>  The way to deal with this is by careful spec layering.
>>>
>>
>> An alternative way to deal with this is to write less in the IETF spec,
>> and use a normative reference to ECMA-404.
>>
>
> That is exactly the kind of layering I think we need.
>
> James
>
>

--001a11c2be5a3bc23104ed3bc6c8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Dec 10, 2013 at 9:28 PM, James Clark <span dir=3D"ltr">&lt;=
<a href=3D"mailto:jjc@jclark.com" target=3D"_blank">jjc@jclark.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"im">On Wed, Dec 11, 2013 at 11:59 =
AM, R S <span dir=3D"ltr">&lt;<a href=3D"mailto:sayrer@gmail.com" target=3D=
"_blank">sayrer@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">


<div dir=3D"ltr"><div>On Tue, Dec 10, 2013 at 8:44 PM, James Clark <span di=
r=3D"ltr">&lt;<a href=3D"mailto:jjc@jclark.com" target=3D"_blank">jjc@jclar=
k.com</a>&gt;</span> wrote:<br></div><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">



<div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>For example, the ECMA spec needs the order of key/val=
ue pairs in an object to be significant</div></div></blockquote><div><br></=
div></div><div>I don&#39;t think ECMA-404 has such a requirement. In fact, =
it says otherwise in at least two places.</div>



</div></div></div></blockquote><div><br></div></div><div>Earlier in this di=
scussion I believe AWB said he thought that ECMA-404 shouldn&#39;t say so.<=
/div><div><br></div><div>In JavaScript, objects do preserve the order of ke=
ys, and many programs rely on this. =A0ECMAScript 5 doesn&#39;t specify thi=
s, but I was under the impression that TC39 plans to fix this. =A0The ES6 d=
raft currently depends on ECMAScript evaluation semantics to determine the =
value represented by a JSON text. So assuming TC39 fixes ECMAScript at some=
 point to match the reality on the Web, JSON.parse will specified to preser=
ve order. I believe current implementations of JSON.parse already do so.</d=
iv>
</div></div></div></blockquote><div><br></div><div>ECMA-404 is a different =
document than ES5 or ES6. It is 4 pages long.</div><div><br></div><div>- Ro=
b</div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 class=3D"im">


<div>=A0<span style=3D"color:rgb(80,0,80)">=A0</span></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote">


<div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>The way to deal with this is by careful spec layering=
.</div></div></blockquote><div><br></div></div><div>An alternative way to d=
eal with this is to write less in the IETF spec, and use a normative refere=
nce to ECMA-404.</div>



</div></div></div></blockquote><div><br></div></div><div>That is exactly th=
e kind of layering I think we need.</div><span class=3D"HOEnZb"><font color=
=3D"#888888"><div><br></div><div>James</div></font></span></div><br></div>
</div>
</blockquote></div><br></div></div>

--001a11c2be5a3bc23104ed3bc6c8--

From internet-drafts@ietf.org  Tue Dec 10 21:52:02 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7120A1AE1CC; Tue, 10 Dec 2013 21:52:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 B9bAHa89QMrJ; Tue, 10 Dec 2013 21:52:00 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC48E1AE377; Tue, 10 Dec 2013 21:51:59 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131211055159.7776.12906.idtracker@ietfa.amsl.com>
Date: Tue, 10 Dec 2013 21:51:59 -0800
Cc: json@ietf.org
Subject: [Json] I-D Action: draft-ietf-json-rfc4627bis-09.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 05:52:02 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the JavaScript Object Notation Working Group =
of the IETF.

	Title           : The JSON Data Interchange Format
	Author(s)       : Tim Bray
	Filename        : draft-ietf-json-rfc4627bis-09.txt
	Pages           : 15
	Date            : 2013-12-10

Abstract:
   JavaScript Object Notation (JSON) is a lightweight, text-based,
   language-independent data interchange format.  It was derived from
   the ECMAScript Programming Language Standard.  JSON defines a small
   set of formatting rules for the portable representation of structured
   data.

   This document removes inconsistencies with other specifications of
   JSON, repairs specification errors, and offers experience-based
   interoperability guidance.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From tbray@textuality.com  Tue Dec 10 21:53:21 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B961AE386 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 21:53:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
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 pbEWiEj_OYed for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 21:53:20 -0800 (PST)
Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id 150E21AE384 for <json@ietf.org>; Tue, 10 Dec 2013 21:53:18 -0800 (PST)
Received: by mail-vc0-f180.google.com with SMTP id if17so5389826vcb.11 for <json@ietf.org>; Tue, 10 Dec 2013 21:53:12 -0800 (PST)
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:content-type; bh=HDs4HJiM6SuQaXnPFvS6mKye99dlZs1dP23K5yVGxj4=; b=EDfHJsy3VAQW3doK9f3O2/P85ceAHCKgt2vJW1VHkjYBVj/Aiqfg/+i5yfAmgsRU7Q r1yuir5NFrNfjTdy7ivKBRIFdl2ILagR0WuKwUnkMchje/RDO9BTdFQqlW7uS840TS9Z F7rr1MrFPqc0G59MNP2f9l4IErQCrYa7sDSAddY7GoHOvRrMi5ZnJlmEstaShECre8EJ a3PDHL7NudOc/ZL9nm6LcU6PalvPl4QDznnDP28H1LOQpKzv9dzuSnKe+DyCF+HWVJ+T Lx4hB9lbFK+58rkZbocLUuKIUpR5KoZyG29OxrX/Uo8VtxDIBLTRRrQw4S6M5FIiUa2+ Mnwg==
X-Gm-Message-State: ALoCoQmK8u5MDkyKuIXyeRtLFJzHe8/ucTW2I2YKrUlIp1k1gAWV76BsOiDo2O6Ws56Zx10IkeYT
MIME-Version: 1.0
X-Received: by 10.58.248.198 with SMTP id yo6mr1844410vec.40.1386741192459; Tue, 10 Dec 2013 21:53:12 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Tue, 10 Dec 2013 21:53:12 -0800 (PST)
X-Originating-IP: [172.29.162.9]
In-Reply-To: <20131211055159.7776.12906.idtracker@ietfa.amsl.com>
References: <20131211055159.7776.12906.idtracker@ietfa.amsl.com>
Date: Tue, 10 Dec 2013 21:53:12 -0800
Message-ID: <CAHBU6isVbTq9d9b5oDsG69FDRyahcQObZP+y=gAmmHZ0ahRakQ@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: internet-drafts@ietf.org
Content-Type: multipart/alternative; boundary=047d7bdc8f1a2c360b04ed3bd88c
Cc: "json@ietf.org" <json@ietf.org>, i-d-announce@ietf.org
Subject: Re: [Json] I-D Action: draft-ietf-json-rfc4627bis-09.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 05:53:22 -0000

--047d7bdc8f1a2c360b04ed3bd88c
Content-Type: text/plain; charset=UTF-8

A real HTML version is at
https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-09.html


On Tue, Dec 10, 2013 at 9:51 PM, <internet-drafts@ietf.org> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the JavaScript Object Notation Working Group
> of the IETF.
>
>         Title           : The JSON Data Interchange Format
>         Author(s)       : Tim Bray
>         Filename        : draft-ietf-json-rfc4627bis-09.txt
>         Pages           : 15
>         Date            : 2013-12-10
>
> Abstract:
>    JavaScript Object Notation (JSON) is a lightweight, text-based,
>    language-independent data interchange format.  It was derived from
>    the ECMAScript Programming Language Standard.  JSON defines a small
>    set of formatting rules for the portable representation of structured
>    data.
>
>    This document removes inconsistencies with other specifications of
>    JSON, repairs specification errors, and offers experience-based
>    interoperability guidance.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-09
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-json-rfc4627bis-09
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>

--047d7bdc8f1a2c360b04ed3bd88c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A real HTML version is at=C2=A0<a href=3D"https://www.tbra=
y.org/tmp/draft-ietf-json-rfc4627bis-09.html">https://www.tbray.org/tmp/dra=
ft-ietf-json-rfc4627bis-09.html</a></div><div class=3D"gmail_extra"><br><br=
><div class=3D"gmail_quote">
On Tue, Dec 10, 2013 at 9:51 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:i=
nternet-drafts@ietf.org" target=3D"_blank">internet-drafts@ietf.org</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.<br>
=C2=A0This draft is a work item of the JavaScript Object Notation Working G=
roup of the IETF.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : The =
JSON Data Interchange Format<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Tim Bray<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet=
f-json-rfc4627bis-09.txt<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 15<b=
r>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 2013-12-10<br>
<br>
Abstract:<br>
=C2=A0 =C2=A0JavaScript Object Notation (JSON) is a lightweight, text-based=
,<br>
=C2=A0 =C2=A0language-independent data interchange format. =C2=A0It was der=
ived from<br>
=C2=A0 =C2=A0the ECMAScript Programming Language Standard. =C2=A0JSON defin=
es a small<br>
=C2=A0 =C2=A0set of formatting rules for the portable representation of str=
uctured<br>
=C2=A0 =C2=A0data.<br>
<br>
=C2=A0 =C2=A0This document removes inconsistencies with other specification=
s of<br>
=C2=A0 =C2=A0JSON, repairs specification errors, and offers experience-base=
d<br>
=C2=A0 =C2=A0interoperability guidance.<br>
<br>
<br>
The IETF datatracker status page for this draft is:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis" tar=
get=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis<=
/a><br>
<br>
There&#39;s also a htmlized version available at:<br>
<a href=3D"http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-09" target=
=3D"_blank">http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-09</a><br=
>
<br>
A diff from the previous version is available at:<br>
<a href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-09=
" target=3D"_blank">http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4=
627bis-09</a><br>
<br>
<br>
Please note that it may take a couple of minutes from the time of submissio=
n<br>
until the htmlized version and diff are available at <a href=3D"http://tool=
s.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br>
<br>
Internet-Drafts are also available by anonymous FTP at:<br>
<a href=3D"ftp://ftp.ietf.org/internet-drafts/" target=3D"_blank">ftp://ftp=
.ietf.org/internet-drafts/</a><br>
<br>
_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
</blockquote></div><br></div>

--047d7bdc8f1a2c360b04ed3bd88c--

From cabo@tzi.org  Tue Dec 10 21:57:37 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81441AE389; Tue, 10 Dec 2013 21:57:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 nsTT7LVs1eK3; Tue, 10 Dec 2013 21:57:36 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 900B21AD738; Tue, 10 Dec 2013 21:57:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBB5vSSl029313; Wed, 11 Dec 2013 06:57:28 +0100 (CET)
Received: from [192.168.217.105] (p54892614.dip0.t-ipconnect.de [84.137.38.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C6D6582E; Wed, 11 Dec 2013 06:57:27 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAHBU6isVbTq9d9b5oDsG69FDRyahcQObZP+y=gAmmHZ0ahRakQ@mail.gmail.com>
Date: Wed, 11 Dec 2013 06:57:26 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <21BB13F5-1C14-4E71-BD9F-4DD4F2E9F631@tzi.org>
References: <20131211055159.7776.12906.idtracker@ietfa.amsl.com> <CAHBU6isVbTq9d9b5oDsG69FDRyahcQObZP+y=gAmmHZ0ahRakQ@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
X-Mailer: Apple Mail (2.1822)
Cc: i-d-announce@ietf.org, internet-drafts@ietf.org, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] I-D Action: draft-ietf-json-rfc4627bis-09.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 05:57:38 -0000

Good changes.

I=92m growing a little unhappy with Appendix A.
This has editorial changes to the document mixed with our changes to =
JSON.
I think the latter (a very short list) should be separate.

Gr=FC=DFe, Carsten


From cabo@tzi.org  Tue Dec 10 22:06:25 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FE41AE39A for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 22:06:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 7mZWZdHPtb-r for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 22:06:25 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC961AE392 for <json@ietf.org>; Tue, 10 Dec 2013 22:06:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBB668M5018572; Wed, 11 Dec 2013 07:06:08 +0100 (CET)
Received: from [192.168.217.105] (p54892614.dip0.t-ipconnect.de [84.137.38.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 332E4830; Wed, 11 Dec 2013 07:06:08 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com>
Date: Wed, 11 Dec 2013 07:06:06 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8E4C9426-868C-418D-814B-1804070ABCE2@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com> <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com>
To: James Clark <jjc@jclark.com>
X-Mailer: Apple Mail (2.1822)
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 06:06:25 -0000

On 11 Dec 2013, at 06:28, James Clark <jjc@jclark.com> wrote:

> It would certainly make life simpler to be able to say JSON objects =
are unordered collections without qualification.=20

But that *is* true without qualification.

JSON is open to extensions.
Preserving serialization ordering is an extension. =20
JSON the data interchange format doesn=92t require that you have that =
extension.
A specific application employing JSON may very well require that you =
have that extension.

Gr=FC=DFe, Carsten


From cowan@ccil.org  Tue Dec 10 22:07:19 2013
Return-Path: <cowan@ccil.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E96D1AE39C for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 22:07:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 yKsUmrRbYhjD for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 22:07:17 -0800 (PST)
Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 504C91AE398 for <json@ietf.org>; Tue, 10 Dec 2013 22:07:17 -0800 (PST)
Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from <cowan@ccil.org>) id 1Vqcwg-0000Lk-0v; Wed, 11 Dec 2013 01:06:54 -0500
Date: Wed, 11 Dec 2013 01:06:54 -0500
From: John Cowan <cowan@mercury.ccil.org>
To: James Clark <jjc@jclark.com>
Message-ID: <20131211060652.GA27999@mercury.ccil.org>
References: <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <cowan@ccil.org>
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, Ladislav Lhotka <lhotka@nic.cz>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Carsten Bormann <cabo@tzi.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 06:07:19 -0000

James Clark scripsit:

> With the spec language I am suggesting, such a consumer would be
> non-conforming (because the tokens 1.0 and 1 represent the same
> rational number).  If it treats 1 as an integer, it would have to also
> treat 1.0 and 1e0 as integers.

I think that's not what users outside the JavaScript walled garden
expect.  They pretty much expect numerals with decimal points or
exponents to be floats (inexact values) and numerals with neither to
be exact integers.  I think the phrase "similar to that used in most
programming languages" suggests that.

> Note that it addresses the interop problem without unnecessarily
> constraining implementations: an implementation using IEEE doubles
> would be conforming,

IEEE doubles distinguish between 0.0 and -0.0, which your definition
forbids.

-- 
My corporate data's a mess!                     John Cowan
It's all semi-structured, no less.              http://www.ccil.org/~cowan
    But I'll be carefree                        cowan@ccil.org
    Using XSLT
On an XML DBMS.

From cabo@tzi.org  Tue Dec 10 22:24:41 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A217D1AE3AC for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 22:24:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 qbXNv4lGRyTP for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 22:24:40 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 540691AE39E for <json@ietf.org>; Tue, 10 Dec 2013 22:24:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBB6OOTP024324; Wed, 11 Dec 2013 07:24:24 +0100 (CET)
Received: from [192.168.217.105] (p54892614.dip0.t-ipconnect.de [84.137.38.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8B710834; Wed, 11 Dec 2013 07:24:22 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20131211060652.GA27999@mercury.ccil.org>
Date: Wed, 11 Dec 2013 07:24:20 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <BCE116FA-AD60-40ED-B663-C5CE7AFA726A@tzi.org>
References: <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <20131211060652.GA27999@mercury.ccil.org>
To: John Cowan <cowan@mercury.ccil.org>
X-Mailer: Apple Mail (2.1822)
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, James Clark <jjc@jclark.com>, Ladislav Lhotka <lhotka@nic.cz>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 06:24:41 -0000

As I said, there is probably no solution to the number problem that =
doesn=92t break something.
(The obvious solution is to continue staying mute, but that doesn=92t =
really solve anything.)

>> With the spec language I am suggesting, such a consumer would be
>> non-conforming (because the tokens 1.0 and 1 represent the same
>> rational number).  If it treats 1 as an integer, it would have to =
also
>> treat 1.0 and 1e0 as integers.
>=20
> I think that's not what users outside the JavaScript walled garden
> expect.  They pretty much expect numerals with decimal points or
> exponents to be floats (inexact values) and numerals with neither to
> be exact integers. =20

Yes, that is a =93principle of least surprise=94 interpretation for many =
people.
However, we know that it creates interoperability problems.
Interoperability problems, if severe enough, override POLS.

I don=92t think we have done enough of a survey of reality to decide =
either way.
My hunch, however, is that James=92 proposal is on the right side of =
that tradeoff.

> I think the phrase "similar to that used in most
> programming languages" suggests that.

It might be suggestive in that direction, but it can=92t really mean =
that, because JSON has only one kind of numbers.  And note that:
   *The representation of numbers* is similar to that used in most
   programming languages.

So this is talking about the sequence of characters representing =
numbers, not the number data model itself.  (I know most spec readers =
aren=92t up to that level of language lawyering.)

>> Note that it addresses the interop problem without unnecessarily
>> constraining implementations: an implementation using IEEE doubles
>> would be conforming,
>=20
> IEEE doubles distinguish between 0.0 and -0.0, which your definition
> forbids.

Yes, we'll have to add the sign to that pair of integers making up =
x/10^y, making it a triple of a two-value (+/-) sign and two =
non-negative integers.  (And decide pretty much arbitrarily whether -0 =
is not the same as 0 in the same way as -0.0 is not the same as 0.0, and =
what about -0e0 or -0e12.)

Gr=FC=DFe, Carsten


From tbray@textuality.com  Tue Dec 10 22:33:01 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E5C1AE3B3 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 22:33:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 gEUog_XciIeu for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 22:32:59 -0800 (PST)
Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id DC0571AE3BA for <json@ietf.org>; Tue, 10 Dec 2013 22:32:42 -0800 (PST)
Received: by mail-ve0-f181.google.com with SMTP id oy12so5549002veb.40 for <json@ietf.org>; Tue, 10 Dec 2013 22:32:37 -0800 (PST)
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:content-type; bh=VoUbM5pUgmrpRisk7UskbHRRQXiOWEO4Gyc3/CFdx2M=; b=X37tvnYXuvp5e2TsZ+68/k+Y9kDDDfWiHhCFacAZiE06WOEw5LkUfPk/eern+hQWVx TO/HrsOI3tIjqSiR3tCYFSSowPVpu95AQv7yqcpVQ1okwXr62hV2YFvP1Vuw2QbaUQ4P 7I0A78YxjtddnMdAewrGQEjW7ijUzxsaJ4I2eh3DoKVynykg8VPp7dqSVaNof97faxMy iBXGMenDrP3AqaPKF+di6qBLjdWwqUD8Tu6Ln6CI8Z8DzY9Lj7KhXomkUOm0edYCUG8F kQVAOIc51JbzlUKpehbPLbMFEVffinBtUuXHOSG3WwnFVaitFLa/cXGM23Ogr8BLuDBE rQQw==
X-Gm-Message-State: ALoCoQlillvNmxJtuVfJmgcH/UQeTftWWbXMg/VK+b6/yK1Kfd4ZVtf5tQd/kRxkV0bqgVMixxQu
MIME-Version: 1.0
X-Received: by 10.220.184.70 with SMTP id cj6mr2862810vcb.23.1386743557167; Tue, 10 Dec 2013 22:32:37 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Tue, 10 Dec 2013 22:32:36 -0800 (PST)
X-Originating-IP: [24.84.235.32]
Received: by 10.220.198.199 with HTTP; Tue, 10 Dec 2013 22:32:36 -0800 (PST)
In-Reply-To: <BCE116FA-AD60-40ED-B663-C5CE7AFA726A@tzi.org>
References: <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <20131211060652.GA27999@mercury.ccil.org> <BCE116FA-AD60-40ED-B663-C5CE7AFA726A@tzi.org>
Date: Tue, 10 Dec 2013 22:32:36 -0800
Message-ID: <CAHBU6iupyofZgzCVPt6X3NAG9YypufYgAhQ1StKAMsC0B1DbpQ@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Carsten Bormann <cabo@tzi.org>
Content-Type: multipart/alternative; boundary=089e0141a4401eb32904ed3c6531
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, John Cowan <cowan@mercury.ccil.org>, James Clark <jjc@jclark.com>, Ladislav Lhotka <lhotka@nic.cz>, JSON WG <json@ietf.org>, "Matt Miller, \(mamille2\)" <mamille2@cisco.com>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 06:33:01 -0000

--089e0141a4401eb32904ed3c6531
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Dec 10, 2013 10:24 PM, "Carsten Bormann" <cabo@tzi.org> wrote:
>
> As I said, there is probably no solution to the number problem

What number problem? I'm serious. Sanely-designed JSON-based protocols
specify, for numeric values, the expected range and precision, and then
things, in my experience, just work. Anyone who includes a number in a wire
format and doesn't  include those constraints is nuts. JSON doesn't get in
the way of doing the right thing; that's good enough for me.

that doesn=E2=80=99t break something.
> (The obvious solution is to continue staying mute, but that doesn=E2=80=
=99t
really solve anything.)
>
> >> With the spec language I am suggesting, such a consumer would be
> >> non-conforming (because the tokens 1.0 and 1 represent the same
> >> rational number).  If it treats 1 as an integer, it would have to also
> >> treat 1.0 and 1e0 as integers.
> >
> > I think that's not what users outside the JavaScript walled garden
> > expect.  They pretty much expect numerals with decimal points or
> > exponents to be floats (inexact values) and numerals with neither to
> > be exact integers.
>
> Yes, that is a =E2=80=9Cprinciple of least surprise=E2=80=9D interpretati=
on for many
people.
> However, we know that it creates interoperability problems.
> Interoperability problems, if severe enough, override POLS.
>
> I don=E2=80=99t think we have done enough of a survey of reality to decid=
e either
way.
> My hunch, however, is that James=E2=80=99 proposal is on the right side o=
f that
tradeoff.
>
> > I think the phrase "similar to that used in most
> > programming languages" suggests that.
>
> It might be suggestive in that direction, but it can=E2=80=99t really mea=
n that,
because JSON has only one kind of numbers.  And note that:
>    *The representation of numbers* is similar to that used in most
>    programming languages.
>
> So this is talking about the sequence of characters representing numbers,
not the number data model itself.  (I know most spec readers aren=E2=80=99t=
 up to
that level of language lawyering.)
>
> >> Note that it addresses the interop problem without unnecessarily
> >> constraining implementations: an implementation using IEEE doubles
> >> would be conforming,
> >
> > IEEE doubles distinguish between 0.0 and -0.0, which your definition
> > forbids.
>
> Yes, we'll have to add the sign to that pair of integers making up
x/10^y, making it a triple of a two-value (+/-) sign and two non-negative
integers.  (And decide pretty much arbitrarily whether -0 is not the same
as 0 in the same way as -0.0 is not the same as 0.0, and what about -0e0 or
-0e12.)
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json

--089e0141a4401eb32904ed3c6531
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
On Dec 10, 2013 10:24 PM, &quot;Carsten Bormann&quot; &lt;<a href=3D"mailto=
:cabo@tzi.org">cabo@tzi.org</a>&gt; wrote:<br>
&gt;<br>
&gt; As I said, there is probably no solution to the number problem </p>
<p dir=3D"ltr">What number problem? I&#39;m serious. Sanely-designed JSON-b=
ased protocols specify, for numeric values, the expected range and precisio=
n, and then things, in my experience, just work. Anyone who includes a numb=
er in a wire format and doesn&#39;t=C2=A0 include those constraints is nuts=
. JSON doesn&#39;t get in the way of doing the right thing; that&#39;s good=
 enough for me.<br>
</p>
<p dir=3D"ltr">that doesn=E2=80=99t break something.<br>
&gt; (The obvious solution is to continue staying mute, but that doesn=E2=
=80=99t really solve anything.)<br>
&gt;<br>
&gt; &gt;&gt; With the spec language I am suggesting, such a consumer would=
 be<br>
&gt; &gt;&gt; non-conforming (because the tokens 1.0 and 1 represent the sa=
me<br>
&gt; &gt;&gt; rational number). =C2=A0If it treats 1 as an integer, it woul=
d have to also<br>
&gt; &gt;&gt; treat 1.0 and 1e0 as integers.<br>
&gt; &gt;<br>
&gt; &gt; I think that&#39;s not what users outside the JavaScript walled g=
arden<br>
&gt; &gt; expect. =C2=A0They pretty much expect numerals with decimal point=
s or<br>
&gt; &gt; exponents to be floats (inexact values) and numerals with neither=
 to<br>
&gt; &gt; be exact integers.<br>
&gt;<br>
&gt; Yes, that is a =E2=80=9Cprinciple of least surprise=E2=80=9D interpret=
ation for many people.<br>
&gt; However, we know that it creates interoperability problems.<br>
&gt; Interoperability problems, if severe enough, override POLS.<br>
&gt;<br>
&gt; I don=E2=80=99t think we have done enough of a survey of reality to de=
cide either way.<br>
&gt; My hunch, however, is that James=E2=80=99 proposal is on the right sid=
e of that tradeoff.<br>
&gt;<br>
&gt; &gt; I think the phrase &quot;similar to that used in most<br>
&gt; &gt; programming languages&quot; suggests that.<br>
&gt;<br>
&gt; It might be suggestive in that direction, but it can=E2=80=99t really =
mean that, because JSON has only one kind of numbers. =C2=A0And note that:<=
br>
&gt; =C2=A0 =C2=A0*The representation of numbers* is similar to that used i=
n most<br>
&gt; =C2=A0 =C2=A0programming languages.<br>
&gt;<br>
&gt; So this is talking about the sequence of characters representing numbe=
rs, not the number data model itself. =C2=A0(I know most spec readers aren=
=E2=80=99t up to that level of language lawyering.)<br>
&gt;<br>
&gt; &gt;&gt; Note that it addresses the interop problem without unnecessar=
ily<br>
&gt; &gt;&gt; constraining implementations: an implementation using IEEE do=
ubles<br>
&gt; &gt;&gt; would be conforming,<br>
&gt; &gt;<br>
&gt; &gt; IEEE doubles distinguish between 0.0 and -0.0, which your definit=
ion<br>
&gt; &gt; forbids.<br>
&gt;<br>
&gt; Yes, we&#39;ll have to add the sign to that pair of integers making up=
 x/10^y, making it a triple of a two-value (+/-) sign and two non-negative =
integers. =C2=A0(And decide pretty much arbitrarily whether -0 is not the s=
ame as 0 in the same way as -0.0 is not the same as 0.0, and what about -0e=
0 or -0e12.)<br>

&gt;<br>
&gt; Gr=C3=BC=C3=9Fe, Carsten<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; json mailing list<br>
&gt; <a href=3D"mailto:json@ietf.org">json@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/json">https://www.iet=
f.org/mailman/listinfo/json</a><br>
</p>

--089e0141a4401eb32904ed3c6531--

From allen@wirfs-brock.com  Tue Dec 10 22:54:07 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B741AE2B8 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 22:54:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 gg2Hy2A1Vche for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 22:54:05 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 887D51AE2B0 for <json@ietf.org>; Tue, 10 Dec 2013 22:54:05 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1Vqdg6-000BLy-FG; Wed, 11 Dec 2013 06:53:50 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18rJjHy8hSHkhO3IMcS24coVUCUEFp2DIQ=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-195-415728817
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com>
Date: Tue, 10 Dec 2013 22:53:41 -0800
Message-Id: <C57917BE-51AE-40D0-80F9-5443E8D2E694@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com> <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com>
To: James Clark <jjc@jclark.com>
X-Mailer: Apple Mail (2.1085)
Cc: Ladislav Lhotka <lhotka@nic.cz>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Carsten Bormann <cabo@tzi.org>, R S <sayrer@gmail.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 06:54:07 -0000

--Apple-Mail-195-415728817
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Dec 10, 2013, at 9:28 PM, James Clark wrote:

> On Wed, Dec 11, 2013 at 11:59 AM, R S <sayrer@gmail.com> wrote:
> On Tue, Dec 10, 2013 at 8:44 PM, James Clark <jjc@jclark.com> wrote:
> For example, the ECMA spec needs the order of key/value pairs in an =
object to be significant
>=20
> I don't think ECMA-404 has such a requirement. In fact, it says =
otherwise in at least two places.
>=20
> Earlier in this discussion I believe AWB said he thought that ECMA-404 =
shouldn't say so.

No, currently ECMA-404 intentionally does not say that  key/value pairs =
are unordered because there is clearly an ordering to them in a JSON =
text.  it does't say one way or another whether any downstream semantics =
is derived from the ordering.

>=20
> In JavaScript, objects do preserve the order of keys, and many =
programs rely on this.  ECMAScript 5 doesn't specify this, but I was =
under the impression that TC39 plans to fix this.

There is a de facto standard for the ordering of the most common cases.  =
At some point this ordering will probably be included in ECMA-262

>  The ES6 draft currently depends on ECMAScript evaluation semantics to =
determine the value represented by a JSON text.

At this point in time, this is just for economy of specification text as =
we know that for syntactically valid JSON input that object literal =
evaluation produces the same result that JSON.parse needs to produce .  =
In both cases, source code key/value pairs are processed in =
left-to-right source code order and constructs an object whose property =
enumeration order is  derived from the processing order.

> So assuming TC39 fixes ECMAScript at some point to match the reality =
on the Web, JSON.parse will specified to preserve order. I believe =
current implementations of JSON.parse already do so.

yes and even if we changed how we expressed the specification for =
JSON.parse it would still have to preserve the current de facto =
ordering.
>=20
> Maybe I am worrying unnecessarily about this.  It would certainly make =
life simpler to be able to say JSON objects are unordered collections =
without qualification.  But I suspect that this doesn't reflect reality =
on the Web.

and you'd be correct. I think you could get away with recommending that =
applications not depend upon the ordering but i doubt that web =
developers would pay attention.  ECMAScript stated out trying to not =
define a specific enumeration order for object properties.  But =
developers still wrote code that dependent upon the ordering they =
observed in the wild and interoperability pressures have generally =
forced convergence upon the ordering used by the browsers with the most =
market share.=20

>  =20
> The way to deal with this is by careful spec layering.
>=20
> An alternative way to deal with this is to write less in the IETF =
spec, and use a normative reference to ECMA-404.
>=20
> That is exactly the kind of layering I think we need.

It's probably obvious that I'd also agree with that.

Allen


--Apple-Mail-195-415728817
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Dec 10, 2013, at 9:28 PM, James Clark wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On =
Wed, Dec 11, 2013 at 11:59 AM, R S <span dir=3D"ltr">&lt;<a =
href=3D"mailto:sayrer@gmail.com" =
target=3D"_blank">sayrer@gmail.com</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">


<div dir=3D"ltr"><div>On Tue, Dec 10, 2013 at 8:44 PM, James Clark <span =
dir=3D"ltr">&lt;<a href=3D"mailto:jjc@jclark.com" =
target=3D"_blank">jjc@jclark.com</a>&gt;</span> wrote:<br></div><div =
class=3D"gmail_extra"><div class=3D"gmail_quote">


<div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>For example, the ECMA spec needs the order of =
key/value pairs in an object to be =
significant</div></div></blockquote><div><br></div></div><div>I don't =
think ECMA-404 has such a requirement. In fact, it says otherwise in at =
least two places.</div>


</div></div></div></blockquote><div><br></div><div>Earlier in this =
discussion I believe AWB said he thought that ECMA-404 shouldn't say =
so.</div></div></div></div></blockquote><div><br></div><div>No, =
currently ECMA-404 intentionally does not say that &nbsp;key/value pairs =
are unordered because there is clearly an ordering to them in a JSON =
text. &nbsp;it does't say one way or another whether any downstream =
semantics is derived from the ordering.</div><div><br></div><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div><br></div><div>In JavaScript, objects do =
preserve the order of keys, and many programs rely on this. =
&nbsp;ECMAScript 5 doesn't specify this, but I was under the impression =
that TC39 plans to fix this. =
</div></div></div></div></blockquote><div><br></div><div>There is a de =
facto standard for the ordering of the most common cases. &nbsp;At some =
point this ordering will probably be included in =
ECMA-262</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div>&nbsp;The ES6 =
draft currently depends on ECMAScript evaluation semantics to determine =
the value represented by a JSON =
text.</div></div></div></div></blockquote><div><br></div><div>At this =
point in time, this is just for economy of specification text as we know =
that for syntactically valid JSON input that object literal evaluation =
produces the same result that JSON.parse needs to produce . &nbsp;In =
both cases, source code key/value pairs are processed in left-to-right =
source code order and constructs an object whose property enumeration =
order is &nbsp;derived from the processing order.</div><br><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div> So assuming TC39 fixes ECMAScript at some =
point to match the reality on the Web, JSON.parse will specified to =
preserve order. I believe current implementations of JSON.parse already =
do so.</div></div></div></div></blockquote><div><br></div>yes and even =
if we changed how we expressed the specification for JSON.parse it would =
still have to preserve the current de facto ordering.<br><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote">


<div><br></div><div>Maybe I am worrying unnecessarily about this. =
&nbsp;It would certainly make life simpler to be able to say JSON =
objects are unordered collections without qualification. &nbsp;But I =
suspect that this doesn't reflect reality on the =
Web.</div></div></div></div></blockquote><div><br></div><div>and you'd =
be correct. I think you could get away with recommending that =
applications not depend upon the ordering but i doubt that web =
developers would pay attention. &nbsp;ECMAScript stated out trying to =
not define a specific enumeration order for object properties. &nbsp;But =
developers still wrote code that dependent upon the ordering they =
observed in the wild and interoperability pressures have generally =
forced convergence upon the ordering used by the browsers with the most =
market share.&nbsp;</div><div><br></div><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">


<div>&nbsp;<span =
style=3D"color:rgb(80,0,80)">&nbsp;</span></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote">

<div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>The way to deal with this is by careful spec =
layering.</div></div></blockquote><div><br></div></div><div>An =
alternative way to deal with this is to write less in the IETF spec, and =
use a normative reference to ECMA-404.</div>


</div></div></div></blockquote><div><br></div><div>That is exactly the =
kind of layering I think we =
need.</div></div></div></div></blockquote><div><br></div><div>It's =
probably obvious that I'd also agree with =
that.</div><div><br></div><div>Allen</div></div><br></body></html>=

--Apple-Mail-195-415728817--

From cabo@tzi.org  Tue Dec 10 23:04:24 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062161AE3B4 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 23:04:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 gvnH-8yso089 for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 23:04:23 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0E91AE3A8 for <json@ietf.org>; Tue, 10 Dec 2013 23:04:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBB74Bs2013132; Wed, 11 Dec 2013 08:04:11 +0100 (CET)
Received: from [192.168.217.105] (p54892614.dip0.t-ipconnect.de [84.137.38.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 489A684D; Wed, 11 Dec 2013 08:04:06 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAHBU6iupyofZgzCVPt6X3NAG9YypufYgAhQ1StKAMsC0B1DbpQ@mail.gmail.com>
Date: Wed, 11 Dec 2013 08:04:01 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B862465C-A2E8-48A9-BD3E-8093300A8E71@tzi.org>
References: <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <20131211060652.GA27999@mercury.ccil.org> <BCE116FA-AD60-40ED-B663-C5CE7AFA726A@tzi.org> <CAHBU6iupyofZgzCVPt6X3NAG9YypufYgAhQ1StKAMsC0B1DbpQ@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
X-Mailer: Apple Mail (2.1822)
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, John Cowan <cowan@mercury.ccil.org>, James Clark <jjc@jclark.com>, Ladislav Lhotka <lhotka@nic.cz>, JSON WG <json@ietf.org>, "Matt Miller, \(mamille2\)" <mamille2@cisco.com>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 07:04:24 -0000

On 11 Dec 2013, at 07:32, Tim Bray <tbray@textuality.com> wrote:

> What number problem?

I=92m sorry, we were having a conversation that is somewhat off-topic to =
the current charter of the JSON WG.

If someone were to create an =93infoset" style specification based on =
the JSON syntax, there would be a number problem: what part of the =
number representation is syntactic fluff in the same way that  =
whitespace is, and what needs to be in the =93infoset".

Back to JSON the data interchange format: using it for interchanging =
numbers requires some care, as does any (non-trivial) interchange of =
numbers between different platforms.  That is not a problem specific to =
JSON, and not one that can be =93solved=94 by JSON.  I agree we are in =
good shape with the reality of using JSON today, and the spec gives good =
advice.  (The largest obstacle to interoperability I know of that is not =
being addressed in 4627bis is the syntactical integer vs. float =
interpretation issue.  I personally think that adding some explanatory =
and/or normative intent here would be a good thing for a JSON spec, but =
that requires hard decisions and it doesn=92t appear to be something the =
WG is up to right now.)

Gr=FC=DFe, Carsten


From cowan@ccil.org  Tue Dec 10 23:46:48 2013
Return-Path: <cowan@ccil.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FE61AE3EB for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 23:46:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 5xjnPzrFf8Qm for <json@ietfa.amsl.com>; Tue, 10 Dec 2013 23:46:47 -0800 (PST)
Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id F40B11AE3ED for <json@ietf.org>; Tue, 10 Dec 2013 23:46:45 -0800 (PST)
Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from <cowan@ccil.org>) id 1VqeUp-000113-11; Wed, 11 Dec 2013 02:46:15 -0500
Date: Wed, 11 Dec 2013 02:46:15 -0500
From: John Cowan <cowan@mercury.ccil.org>
To: Carsten Bormann <cabo@tzi.org>
Message-ID: <20131211074614.GA1517@mercury.ccil.org>
References: <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <20131211060652.GA27999@mercury.ccil.org> <BCE116FA-AD60-40ED-B663-C5CE7AFA726A@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BCE116FA-AD60-40ED-B663-C5CE7AFA726A@tzi.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <cowan@ccil.org>
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, James Clark <jjc@jclark.com>, Ladislav Lhotka <lhotka@nic.cz>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 07:46:48 -0000

Carsten Bormann scripsit:

> (And decide pretty much arbitrarily whether -0 is not the same as 0 in
> the same way as -0.0 is not the same as 0.0, and what about -0e0 or
> -0e12.)

If we adopt the usual rule for distinguishing integers and floats, then
0 and -0 are the same, but the other pairs are different.  That follows
from the nature of integers as exact numbers and floats as inexact
numbers:  0.0 means any non-negative number less than the smallest
representable positive value, and -0.0 means any non-positive number
greater than the largest representable negative value.

-- 
John Cowan  cowan@ccil.org  http://ccil.org/~cowan
Any sufficiently-complicated C or Fortran program contains an ad-hoc,
informally-specified bug-ridden slow implementation of half of Common Lisp.
        --Greenspun's Tenth Rule of Programming (rules 1-9 are unknown)

From duerst@it.aoyama.ac.jp  Wed Dec 11 01:44:53 2013
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9B71A1F4E for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 01:44:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.092
X-Spam-Level: 
X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=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 KinSUdNNCoDN for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 01:44:51 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id E44F81A1F06 for <json@ietf.org>; Wed, 11 Dec 2013 01:44:49 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id rBB9iXtx023603; Wed, 11 Dec 2013 18:44:33 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 5e31_86b9_d6b38290_6248_11e3_84e2_001e6722eec2; Wed, 11 Dec 2013 18:44:32 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 49649BF548; Wed, 11 Dec 2013 18:44:32 +0900 (JST)
Message-ID: <52A833F1.2030902@it.aoyama.ac.jp>
Date: Wed, 11 Dec 2013 18:44:17 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Brendan Eich <brendan@mozilla.com>
References: <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp> <E19BDE18-DA46-4C00-AA6C-205C348326AD@tzi.org> <52A59337.4050609@it.aoyama.ac.jp> <2AA6AE6A-C76D-4B61-BFE1-0EBDFB715D6D@tzi.org> <8E4C7969-7868-4DE9-A9B0-C7FD484075B1@wirfs-brock.com> <serca9lle8m19n7ikdhf9ldlcoo8b9mpos@hive.bjoern.hoehrmann.de> <52A67552.3070405@mozilla.com>
In-Reply-To: <52A67552.3070405@mozilla.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, www-tag@w3.org, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 09:44:53 -0000

Hello Brendan,

On 2013/12/10 10:58, Brendan Eich wrote:
> http://bugs.ecmascript.org/ -- please use it, you will be amazed at how
> quickly the bug is resolved. Thanks,

Many thanks. As far as I can remember, this is the first time that 
somebody from the EcmaScript side has sent such an invitation.

In retrospective, I think it would have made a lot of sense to send such 
a mail (with a few more pointers) to the IETF JSON WG when ECMA 404 was 
being drafted.

I have checked the bugs that were already there, and submitted two 
additional bugs. I'm sorry I didn't do that yesterday; the confirmation 
mail for the bugzilla signup got delayed by about 20h (see below).

Regards,   Martin.


Excerpt from mail headers (more available on request):

Received: from ecmascript1.community.scl3.mozilla.com 
(ecmascript1.community.scl3.mozilla.com [63.245.223.13])
	by scmailgw02.scop.aoyama.ac.jp (secret/secret) with ESMTP id 
rBADOWwb024274
	for <duerst@it.aoyama.ac.jp>; Tue, 10 Dec 2013 22:24:32 +0900
Received: from ecmascript1.community.scl3.mozilla.com 
(unused-10-2-11-214.mozilla.org [127.0.0.1])
	by ecmascript1.community.scl3.mozilla.com (8.13.8/8.13.8) with ESMTP id 
rBAAOT8Z009320
	for <duerst@it.aoyama.ac.jp>; Tue, 10 Dec 2013 02:24:29 -0800

From duerst@it.aoyama.ac.jp  Wed Dec 11 02:08:21 2013
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A151ADFD5 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 02:08:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.908
X-Spam-Level: 
X-Spam-Status: No, score=0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=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 9hOubqxepAqg for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 02:08:20 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 06C161ADF0E for <json@ietf.org>; Wed, 11 Dec 2013 02:08:19 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id rBBA8DN3007945; Wed, 11 Dec 2013 19:08:13 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 5e31_92df_2590b916_624c_11e3_84e2_001e6722eec2; Wed, 11 Dec 2013 19:08:12 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 1BCBCBF548; Wed, 11 Dec 2013 19:08:13 +0900 (JST)
Message-ID: <52A8397E.8010005@it.aoyama.ac.jp>
Date: Wed, 11 Dec 2013 19:07:58 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <FBA9E9C2-2A93-402B-8E5E-E0C313D65D87@tzi.org> <0D228FA5-D1B6-4CD5-8670-AE68E6435716@wirfs-brock.com> <20131206205613.GA3577@gmail.com> <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp> <E19BDE18-DA46-4C00-AA6C-205C348326AD@tzi.org> <52A59337.4050609@it.aoyama.ac.jp> <2AA6AE6A-C76D-4B61-BFE1-0EBDFB715D6D@tzi.org> <8E4C7969-7868-4DE9-A9B0-C7FD484075B1@wirfs-brock.com> <52A6E807.9050103@it.aoyama.ac.jp> <5D031FF2-D94D-4381-8DA7-DC3195D5E005@wirfs-brock.com>
In-Reply-To: <5D031FF2-D94D-4381-8DA7-DC3195D5E005@wirfs-brock.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: Carsten Bormann <cabo@tzi.org>, JSON WG <json@ietf.org>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 10:08:21 -0000

On 2013/12/11 11:14, Allen Wirfs-Brock wrote:
>
> On Dec 10, 2013, at 2:08 AM, Martin J. D=C3=BCrst wrote:

>> I'll submit some.

Done in the meantime.

>> What about the ECMA people submitting some bug reports on 4627bis in r=
eturn?
>
> Is there a bug tracking system or are perceived bugs simply submitted t=
o the mailing list.

Each WG has an issue tracker instance on the tools site=20
(tools.ietf.org). However, not all WGs use it, and this includes the=20
JSON WG. So just sending mail to this mailing list is enough.

Regards,    Martin.

P.S.: There are also some IETF WGs that use external tools such as the=20
github issue tracker,...

From duerst@it.aoyama.ac.jp  Wed Dec 11 02:41:56 2013
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7542F1AD944 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 02:41:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level: 
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=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 HdhPsTlqCjUD for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 02:41:55 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id BE1601A1F71 for <json@ietf.org>; Wed, 11 Dec 2013 02:41:54 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rBBAfk7M027468; Wed, 11 Dec 2013 19:41:46 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 5e35_248e_d5406c40_6250_11e3_abd4_001e6722eec2; Wed, 11 Dec 2013 19:41:46 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id CCCB4BF548; Wed, 11 Dec 2013 19:41:45 +0900 (JST)
Message-ID: <52A8415B.6050502@it.aoyama.ac.jp>
Date: Wed, 11 Dec 2013 19:41:31 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Carsten Bormann <cabo@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <6B43CA50-6C39-4663-AADC-42830E1AC93C@tzi.org>
In-Reply-To: <6B43CA50-6C39-4663-AADC-42830E1AC93C@tzi.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, James Clark <jjc@jclark.com>
Subject: [Json] Data Model and Infoset (was: Re: Response to Statement from W3C TAG)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 10:41:56 -0000

On 2013/12/10 20:41, Carsten Bormann wrote:
> On 10 Dec 2013, at 07:52, James Clark<jjc@jclark.com>  wrote:
>
>> Most users of XML deal with higher-level semantic abstractions rather =
than directly with the XML Infoset, but it has proven very useful to be a=
ble to specify these higher-level semantic abstractions in terms of the X=
ML Infoset rather than having to specify them directly in terms of the XM=
L syntax.
>
> The XML infoset is very much tied to the needs (and idiosyncrasies) of =
the serialization that XML uses.

Yes indeed. There's a bit more syntactic variety in XML than in JSON. So=20
it's very good to know for sure that
    <a>3</a>
    <a>&#x33;</a>
    <a>&#51;</a>
    <a><![CDATA[3]]></a>
and so on (I hope I got the last one right) are ignorable syntactic=20
differences which will never create semantic differences.

(In an early draft (http://www.w3.org/TR/2001/WD-xml-infoset-20010202/),=20
the last one would have been different, but fortunately, the W3C I18N WG=20
and other sensible folks helped to avoid such a train wreck.)


> The main innovation of JSON was to actually supply such a data model as=
 part of the format.
> I would argue that his property was what made JSON =E2=80=9Cwin=E2=80=9D=
 over XML.

Sorry, but I have to disagree. XML has an (implicit) data model, too. It=20
works very well for documents (e.g. XHTML, TEI, DocBook, DITA,...).

Where it doesn't work that well anymore is for some of the most frequent=20
programming language data structures, such as arrays,=20
hashes/maps/records/..., and to a lesser extent booleans and numbers.

XML was used for data structure transport between programs because it=20
worked better than preexisting alternatives, and because it had the Web=20
cool factor at the time.

When JSON turned up, people quickly understood that it was a better fit=20
for basic data structures, and they started to use it there.


So for data that has arrays and hashes,..., use JSON. For=20
document-structured data, use XML.

For mixed data (both arrays/hashes and document pieces), probably XML=20
works better because arrays and hashes are easier to transfer in XML=20
than document structures in JSON. But your milage may vary.

For more advanced stuff, such as documents with parallel structures,=20
graphs, and so on, you'll suffer both with JSON and with XML.

Regards,   Martin.

From julian.reschke@gmx.de  Wed Dec 11 05:43:48 2013
Return-Path: <julian.reschke@gmx.de>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2E61ADBCC for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 05:43:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 4Iv4nC3ErmPC for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 05:43:46 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3972D1ADBCE for <json@ietf.org>; Wed, 11 Dec 2013 05:43:46 -0800 (PST)
Received: from [192.168.1.38] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MVrQS-1W1eCJ1360-00X5zI for <json@ietf.org>; Wed, 11 Dec 2013 14:43:40 +0100
Message-ID: <52A86C05.1010401@gmx.de>
Date: Wed, 11 Dec 2013 14:43:33 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Tim Bray <tbray@textuality.com>
References: <20131211055159.7776.12906.idtracker@ietfa.amsl.com> <CAHBU6isVbTq9d9b5oDsG69FDRyahcQObZP+y=gAmmHZ0ahRakQ@mail.gmail.com> <21BB13F5-1C14-4E71-BD9F-4DD4F2E9F631@tzi.org>
In-Reply-To: <21BB13F5-1C14-4E71-BD9F-4DD4F2E9F631@tzi.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:pL1GlyuNrtSRsvrhpPLBTj16sEz5J0Erf/A0i9qXnJzgcywxeVZ Iri7o/0iTYo88d227WBZ3rm3IwyffhLF809mn5UmoH+0amDl6+vs/fsGr6JEnKWNtwi0jCL UDrhuVS0xHwJONyjou9bOoIyiY4GVFJgszrw0oJrB0wMYOaZLmvTxapCoSZJis7hbh4dUGl NVgVXw/721PBoiWxfVKUg==
Cc: Carsten Bormann <cabo@tzi.org>, "json@ietf.org" <json@ietf.org>, internet-drafts@ietf.org, i-d-announce@ietf.org
Subject: Re: [Json] I-D Action: draft-ietf-json-rfc4627bis-09.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 13:43:48 -0000

On 2013-12-11 06:57, Carsten Bormann wrote:
> Good changes.
>
> I’m growing a little unhappy with Appendix A.
> This has editorial changes to the document mixed with our changes to JSON.
> I think the latter (a very short list) should be separate.
> ...

+0.5 (#ifitsnottoomuchwork)

Other than that, thanks a lot for addressing my feedback!

Best regards, Julian

From James.H.Manger@team.telstra.com  Wed Dec 11 06:24:38 2013
Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0CB1ADF33 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 06:24:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.202
X-Spam-Level: 
X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=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 XAx3jZQ6LW3Z for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 06:24:37 -0800 (PST)
Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id B1DBF1ADE87 for <json@ietf.org>; Wed, 11 Dec 2013 06:24:36 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.93,872,1378821600"; d="scan'208";a="164228531"
Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 12 Dec 2013 01:24:30 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,7285"; a="134345869"
Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcani.tcif.telstra.com.au with ESMTP; 12 Dec 2013 01:24:30 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Thu, 12 Dec 2013 01:24:29 +1100
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>, JSON WG <json@ietf.org>
Date: Thu, 12 Dec 2013 01:24:19 +1100
Thread-Topic: object element order
Thread-Index: Ac72PcxSE5yz2g/iRCeVKwzzfDCdmQAOfuBg
Message-ID: <255B9BB34FB7D647A506DC292726F6E115373AEB92@WSMSG3153V.srv.dir.telstra.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com> <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com> <C57917BE-51AE-40D0-80F9-5443E8D2E694@wirfs-brock.com>
In-Reply-To: <C57917BE-51AE-40D0-80F9-5443E8D2E694@wirfs-brock.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [Json] object element order
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 14:24:38 -0000

RUNNQVNjcmlwdCBzcGVjcyBhbmQvb3IgaW1wbGVtZW50YXRpb25zIG1heSBoYXZlIHJ1bGVzIGFi
b3V0IHRoZSBvcmRlciBvZiBlbGVtZW50cyBpbiBhbiBvYmplY3QsIGJ1dCB0aGV5IGRvbuKAmXQg
bG9vayBzaW1wbGUuDQoNCkZvciBleGFtcGxlIENocm9tZeKAmXMgY29uc29sZSBnaXZlczoNCg0K
PiBKU09OLnN0cmluZ2lmeShKU09OLnBhcnNlKCd7IjUiOjIyLCJiIjp0cnVlLCIxIjoxMSwgImEi
OmZhbHNlfScpKQ0KICAieyIxIjoxMSwiNSI6MjIsImIiOnRydWUsImEiOmZhbHNlfSINCg0KRnJv
bSBtYW51YWxseSB0cnlpbmcgYSBmZXcgZXhhbXBsZXMsIHRoZSBlbGVtZW50IG9yZGVyaW5nIHJ1
bGVzIHNlZW1zIHRvIGJlOg0KDQoxLiBOYW1lIHN0cmluZ3MgdGhhdCBsb29rcyBsaWtlIG5vbi1u
ZWdhdGl2ZSBpbnRlZ2VycyBsZXNzIHRoYW4gYWJvdXQgMSBiaWxsaW9uICh3aXRoIG5vIGRlY2lt
YWwgcG9pbnQgb3IgZXhwb25lbnQpIGFyZSBwbGFjZWQgYXQgdGhlIGZyb250LCBzb3J0ZWQgYnkg
dGhlaXIgbnVtZXJpYyB2YWx1ZQ0KDQoyLiBBbGwgb3RoZXIgbmFtZSBzdHJpbmdzIGNvbWUgYWZ0
ZXJ3YXJkcywgcHJlc2VydmluZyB0aGVpciByZWxhdGl2ZSBvcmRlcg0KDQpUaGVyZSBpcyBubyB3
YXkgd2Ugd2FudCB0aGF0IHNvcnQgb2YgcnVsZSBpbiB0aGUgYmFzZSBKU09OIHNwZWMsIGVnIGlu
IEVDTUEtNDA0Lg0KDQpJZiB0aGVzZSBydWxlcyBhcmUgaW4gRUNNQVNjcmlwdCwgYSBKU09OIHNw
ZWMgYmV0dGVyIG5vdCBpbXBseSBlbGVtZW50IG9yZGVyIG1hdHRlcnMuDQpBIEpTT04gc3BlYyBu
ZWVkcyB0byBzYXkgb2JqZWN0cyBhcmUgdW5vcmRlcmVkIHNvIG1lc3NhZ2VzIGZyb20gYSBjb21w
bGlhbnQgaW1wbGVtZW50YXRpb25zIGFyZSBub3QgbWlzaW50ZXJwcmV0ZWQgYnkgRUNNQVNjcmlw
dCAod2hpY2ggd2lsbCByZW9yZGVyIGEgIjAiIGVsZW1lbnQgdG8gdGhlIGZyb250LCBmb3IgaW5z
dGFuY2UpLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo=

From Alexandre.Morgaut@4d.com  Wed Dec 11 08:39:43 2013
Return-Path: <Alexandre.Morgaut@4d.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BF21ADF80 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 08:39:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 kwd7Q0DQ6oP0 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 08:39:41 -0800 (PST)
Received: from exchange.4d.com (exchange.4d.com [194.177.35.84]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8451ADEA7 for <json@ietf.org>; Wed, 11 Dec 2013 08:39:40 -0800 (PST)
Received: from 4d-xn1-exch.4d.local ([194.177.35.84]) by 4d-xn1-exch ([194.177.35.84]) with mapi; Wed, 11 Dec 2013 17:29:04 +0100
From: Alexandre Morgaut <Alexandre.Morgaut@4d.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>
Date: Wed, 11 Dec 2013 17:29:03 +0100
Thread-Topic: [Json] object element order
Thread-Index: Ac72jhsP5GanGXBlTdS3ofvtBW19lQ==
Message-ID: <76C7289A-E9E7-412E-A52B-E50C11A3B061@4d.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com> <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com> <C57917BE-51AE-40D0-80F9-5443E8D2E694@wirfs-brock.com> <255B9BB34FB7D647A506DC292726F6E115373AEB92@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115373AEB92@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR, en-US
x-exclaimer-md-config: 2c2e5a05-a47a-4726-b954-105699434113
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] object element order
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 16:39:43 -0000

DQpUaGUgcnVsZSBpbiBFQ01BU2NyaXB0IGlzIHRoYXQgIG9yZGVyIGZvciBvYmplY3QgcHJvcGVy
dGllcyBpcyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYw0KDQoNCiAgICAgICAgVGhlIG1lY2hhbmlj
cyBhbmQgb3JkZXIgb2YgZW51bWVyYXRpbmcgdGhlIHByb3BlcnRpZXMgKHN0ZXAgNi5hIGluIHRo
ZSBmaXJzdCBhbGdvcml0aG0sIHN0ZXAgNy5hIGluIHRoZSBzZWNvbmQpIGlzIG5vdCBzcGVjaWZp
ZWQuDQoNCmh0dHA6Ly93d3cuZWNtYS1pbnRlcm5hdGlvbmFsLm9yZy9lY21hLTI2Mi81LjEvI3Nl
Yy0xMi42LjQNCg0KICAgICAgICBJZiBhbiBpbXBsZW1lbnRhdGlvbiBkZWZpbmVzIGEgc3BlY2lm
aWMgb3JkZXIgb2YgZW51bWVyYXRpb24gZm9yIHRoZSBmb3ItaW4gc3RhdGVtZW50LCB0aGF0IHNh
bWUgZW51bWVyYXRpb24gb3JkZXIgbXVzdCBiZSB1c2VkIHRvIG9yZGVyIHRoZSBsaXN0IGVsZW1l
bnRzIGluIHN0ZXAgMyBvZiB0aGlzIGFsZ29yaXRobS4NCg0KaHR0cDovL3d3dy5lY21hLWludGVy
bmF0aW9uYWwub3JnL2VjbWEtMjYyLzUuMS8jc2VjLTE1LjIuMy43DQoNCiAgICAgICAgSWYgYW4g
aW1wbGVtZW50YXRpb24gZGVmaW5lcyBhIHNwZWNpZmljIG9yZGVyIG9mIGVudW1lcmF0aW9uIGZv
ciB0aGUgZm9yLWluIHN0YXRlbWVudCwgdGhhdCBzYW1lIGVudW1lcmF0aW9uIG9yZGVyIG11c3Qg
YmUgdXNlZCBpbiBzdGVwIDUgb2YgdGhpcyBhbGdvcml0aG0uDQoNCmh0dHA6Ly93d3cuZWNtYS1p
bnRlcm5hdGlvbmFsLm9yZy9lY21hLTI2Mi81LjEvI3NlYy0xNS4yLjMuMTQNCg0KDQoNClRvIGdl
dCBhbiBvcmRlcmVkIGxpc3QsIHRoZSBBcnJheSBzdHJ1Y3R1cmUgaGFzIHRvIGJlIHVzZWQNCg0K
ZXg6DQoNCkpTT04uc3RyaW5naWZ5KEpTT04ucGFyc2UoJ1t7Im5hbWUiOiI1IiwidmFsdWUiOjIy
fSx7Im5hbWUiOiJiIiwidmFsdWUiOnRydWV9LHsibmFtZSI6IjEiLCJ2YWx1ZSI6MTF9LHsibmFt
ZSI6ImEiLCJ2YWx1ZSI6ZmFsc2V9XScpKSwNCg0KLT4gW3sibmFtZSI6IjUiLCJ2YWx1ZSI6MjJ9
LHsibmFtZSI6ImIiLCJ2YWx1ZSI6dHJ1ZX0seyJuYW1lIjoiMSIsInZhbHVlIjoxMX0seyJuYW1l
IjoiYSIsInZhbHVlIjpmYWxzZX1dDQoNCm5vdGUgdGhhdCB5b3UgY2Fubm90IHJlbHkgb24gdGhl
IG9yZGVyIGJldHdlZW4gIm5hbWUiIGFuZCAidmFsdWUiIHByb3BlcnRpZXMsIGJ1dCB0aGUgb3Jk
ZXIgd2lsbCBiZSBwcmVzZXJ2ZWQgZm9yIGFsbCB0aGUgYXJyYXkgZWxlbWVudHMNCg0KDQoNCg0K
T24gMTEgZMOpYy4gMjAxMywgYXQgMTU6MjQsIE1hbmdlciwgSmFtZXMgd3JvdGU6DQoNCj4gRUNN
QVNjcmlwdCBzcGVjcyBhbmQvb3IgaW1wbGVtZW50YXRpb25zIG1heSBoYXZlIHJ1bGVzIGFib3V0
IHRoZSBvcmRlciBvZiBlbGVtZW50cyBpbiBhbiBvYmplY3QsIGJ1dCB0aGV5IGRvbuKAmXQgbG9v
ayBzaW1wbGUuDQo+DQo+IEZvciBleGFtcGxlIENocm9tZeKAmXMgY29uc29sZSBnaXZlczoNCj4N
Cj4+IEpTT04uc3RyaW5naWZ5KEpTT04ucGFyc2UoJ3siNSI6MjIsImIiOnRydWUsIjEiOjExLCAi
YSI6ZmFsc2V9JykpDQo+ICAieyIxIjoxMSwiNSI6MjIsImIiOnRydWUsImEiOmZhbHNlfSINCj4N
Cj4gRnJvbSBtYW51YWxseSB0cnlpbmcgYSBmZXcgZXhhbXBsZXMsIHRoZSBlbGVtZW50IG9yZGVy
aW5nIHJ1bGVzIHNlZW1zIHRvIGJlOg0KPg0KPiAxLiBOYW1lIHN0cmluZ3MgdGhhdCBsb29rcyBs
aWtlIG5vbi1uZWdhdGl2ZSBpbnRlZ2VycyBsZXNzIHRoYW4gYWJvdXQgMSBiaWxsaW9uICh3aXRo
IG5vIGRlY2ltYWwgcG9pbnQgb3IgZXhwb25lbnQpIGFyZSBwbGFjZWQgYXQgdGhlIGZyb250LCBz
b3J0ZWQgYnkgdGhlaXIgbnVtZXJpYyB2YWx1ZQ0KPg0KPiAyLiBBbGwgb3RoZXIgbmFtZSBzdHJp
bmdzIGNvbWUgYWZ0ZXJ3YXJkcywgcHJlc2VydmluZyB0aGVpciByZWxhdGl2ZSBvcmRlcg0KPg0K
PiBUaGVyZSBpcyBubyB3YXkgd2Ugd2FudCB0aGF0IHNvcnQgb2YgcnVsZSBpbiB0aGUgYmFzZSBK
U09OIHNwZWMsIGVnIGluIEVDTUEtNDA0Lg0KPg0KPiBJZiB0aGVzZSBydWxlcyBhcmUgaW4gRUNN
QVNjcmlwdCwgYSBKU09OIHNwZWMgYmV0dGVyIG5vdCBpbXBseSBlbGVtZW50IG9yZGVyIG1hdHRl
cnMuDQo+IEEgSlNPTiBzcGVjIG5lZWRzIHRvIHNheSBvYmplY3RzIGFyZSB1bm9yZGVyZWQgc28g
bWVzc2FnZXMgZnJvbSBhIGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbnMgYXJlIG5vdCBtaXNpbnRl
cnByZXRlZCBieSBFQ01BU2NyaXB0ICh3aGljaCB3aWxsIHJlb3JkZXIgYSAiMCIgZWxlbWVudCB0
byB0aGUgZnJvbnQsIGZvciBpbnN0YW5jZSkuDQo+DQo+IC0tDQo+IEphbWVzIE1hbmdlcg0KPg0K
DQoNCg0KQWxleGFuZHJlIE1vcmdhdXQNCldha2FuZGEgQ29tbXVuaXR5IE1hbmFnZXINCg0KNEQg
U0FTDQo2MCwgcnVlIGQnQWxzYWNlDQo5MjExMCBDbGljaHkNCkZyYW5jZQ0KDQpTdGFuZGFyZCA6
ICszMyAxIDQwIDg3IDkyIDAwDQpFbWFpbCA6ICAgIEFsZXhhbmRyZS5Nb3JnYXV0QDRkLmNvbQ0K
V2ViIDogICAgICB3d3cuNEQuY29tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4ganNvbiBtYWlsaW5nIGxpc3QNCj4ganNvbkBpZXRmLm9yZw0K
PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pzb24NCg0K

From allen@wirfs-brock.com  Wed Dec 11 09:00:50 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A231AE0B5 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 09:00:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 e4sSAa6z8vw2 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 09:00:48 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 766A61AE0A9 for <json@ietf.org>; Wed, 11 Dec 2013 09:00:48 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1Vqn9O-000DYh-J8; Wed, 11 Dec 2013 17:00:42 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1//6f4SC6pQrPKx8p6mOETZ1jIqdk7rk6o=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=windows-1252
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115373AEB92@WSMSG3153V.srv.dir.telstra.com>
Date: Wed, 11 Dec 2013 09:00:34 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <09E2A0C8-C2B6-4104-B208-F1FE5448DF44@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com> <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com> <C57917BE-51AE-40D0-80F9-5443E8D2E694@wirfs-brock.com> <255B9BB34FB7D647A506DC292726F6E115373AEB92@WSMSG3153V.srv.dir.telstra.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>
X-Mailer: Apple Mail (2.1085)
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] object element order
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 17:00:50 -0000

On Dec 11, 2013, at 6:24 AM, Manger, James wrote:

> ECMAScript specs and/or implementations may have rules about the order =
of elements in an object, but they don=92t look simple.
>=20
> For example Chrome=92s console gives:
>=20
>> JSON.stringify(JSON.parse('{"5":22,"b":true,"1":11, "a":false}'))
>  "{"1":11,"5":22,"b":true,"a":false}"
>=20
> =46rom manually trying a few examples, the element ordering rules =
seems to be:
>=20
> 1. Name strings that looks like non-negative integers less than about =
1 billion (with no decimal point or exponent) are placed at the front, =
sorted by their numeric value
>=20
> 2. All other name strings come afterwards, preserving their relative =
order

The ordering for members with  keys that are not integer numeric strings =
is consistent across browser ECMAScript implementations.  This is a =
defacto standard.  There has been some recent divergence from the de =
facto standard WRT integer numeric strings=20

>=20
> There is no way we want that sort of rule in the base JSON spec, eg in =
ECMA-404.
>=20
> If these rules are in ECMAScript, a JSON spec better not imply element =
order matters.
> A JSON spec needs to say objects are unordered so messages from a =
compliant implementations are not misinterpreted by ECMAScript (which =
will reorder a "0" element to the front, for instance).

You can't require that ECMAScript objects do not always have an =
enumeration order of their properties.  They do and you can't change =
that.  You also can't deny that the members of a JSON object occur in a =
specific order.  At most you can recommend that JSON-based protocols not =
depend upon that ordering.

This a all about a language binding and how a particular parser =
translate JSON text into some language specific data structure.

The definition of a well-formed JSON text doesn't need to say anything =
about this. =20

Allen



From allen@wirfs-brock.com  Wed Dec 11 09:04:16 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6001AE02C for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 09:04:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 v1zh1kzjUC-X for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 09:04:15 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0107A1AE0B5 for <json@ietf.org>; Wed, 11 Dec 2013 09:04:15 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1VqnCh-000GfU-Nc; Wed, 11 Dec 2013 17:04:08 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18w0f3ktqwxgj5eZg3iwgp0ulP/BlV+iJw=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <76C7289A-E9E7-412E-A52B-E50C11A3B061@4d.com>
Date: Wed, 11 Dec 2013 09:03:59 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <23238802-6A94-4F57-93A9-82E4763AB95F@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com> <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com> <C57917BE-51AE-40D0-80F9-5443E8D2E694@wirfs-brock.com> <255B9BB34FB7D647A506DC292726F6E115373AEB92@WSMSG3153V.srv.dir.telstra.com> <76C7289A-E9E7-412E-A52B-E50C11A3B061@4d.com>
To: Alexandre Morgaut <Alexandre.Morgaut@4d.com>
X-Mailer: Apple Mail (2.1085)
Cc: "Manger, James" <James.H.Manger@team.telstra.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] object element order
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 17:04:16 -0000

On Dec 11, 2013, at 8:29 AM, Alexandre Morgaut wrote:

>=20
> The rule in ECMAScript is that  order for object properties is =
implementation specific
>=20
>=20
>        The mechanics and order of enumerating the properties (step 6.a =
in the first algorithm, step 7.a in the second) is not specified.
>=20
> http://www.ecma-international.org/ecma-262/5.1/#sec-12.6.4
>=20
>        If an implementation defines a specific order of enumeration =
for the for-in statement, that same enumeration order must be used to =
order the list elements in step 3 of this algorithm.
>=20
> http://www.ecma-international.org/ecma-262/5.1/#sec-15.2.3.7
>=20
>        If an implementation defines a specific order of enumeration =
for the for-in statement, that same enumeration order must be used in =
step 5 of this algorithm.
>=20
> http://www.ecma-international.org/ecma-262/5.1/#sec-15.2.3.14
>=20
> To get an ordered list, the Array structure has to be used
>=20
> ex:
>=20
> =
JSON.stringify(JSON.parse('[{"name":"5","value":22},{"name":"b","value":tr=
ue},{"name":"1","value":11},{"name":"a","value":false}]')),
>=20
> -> =
[{"name":"5","value":22},{"name":"b","value":true},{"name":"1","value":11}=
,{"name":"a","value":false}]
>=20
> note that you cannot rely on the order between "name" and "value" =
properties, but the order will be preserved for all the array elements

Except there is a defacto standard for the ordering of properties such =
as "name" and "value"  (notice they were all ordered the same in the =
output you show).  In the real world some application rely on this =
ordering. =20

Allen


From paul.hoffman@vpnc.org  Wed Dec 11 09:23:59 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA2B1ADFBB for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 09:23:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 kve8WKdeR5fI for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 09:23:58 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 87E2D1ADFA4 for <json@ietf.org>; Wed, 11 Dec 2013 09:23:58 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rBBHNGTc007481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <json@ietf.org>; Wed, 11 Dec 2013 10:23:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D3D0850-BC0E-4065-A71F-6C4EE5485A30@vpnc.org>
Date: Wed, 11 Dec 2013 09:23:15 -0800
To: JSON WG <json@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
X-Mailer: Apple Mail (2.1822)
Subject: [Json] The discussion of Ecma documents
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 17:23:59 -0000

...should happen in Ecma, not in this WG. Ecma has a public mailing list =
for such discussion: <https://mail.mozilla.org/listinfo/es-discuss>.

While the threads here on both ECMA-404 and the upcoming ES6 document =
have been vigorous and interesting, anyone wanting changes in those =
documents should have the discussion where the TC39 members who can make =
those changes are watching, namely the es-discuss mailing list.

--Paul Hoffman=

From tbray@textuality.com  Wed Dec 11 09:57:49 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C171ADF9C for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 09:57:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 CXsW7JPQw9hN for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 09:57:47 -0800 (PST)
Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id E71911ADD02 for <json@ietf.org>; Wed, 11 Dec 2013 09:57:46 -0800 (PST)
Received: by mail-ve0-f181.google.com with SMTP id oy12so6163759veb.26 for <json@ietf.org>; Wed, 11 Dec 2013 09:57:41 -0800 (PST)
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:content-type; bh=PPW+7HkNbVpMv0TjXL5eUjPftulVikxWwUm1xhxEn/A=; b=LhyIaO58/U64D5r0mRQoTdKCGx8Gry7iatbOdJ6/6rjwZFUbp0w3l6Yg48uO8Ssbab /2IZYfvQa0aixuLIHc2h81KsmCCX/W+And9m5EdJYqyQXRMy91zC/K2TDsn05XJ1KAco HFiBh88TPh3tbMungnFmEE0Wxys+Rb5naDntDr9Wwvp74ahimf8lIyL4+eFwJHoU5SlB 68V47LnVfOW8AEbYV3sLsd45m5Iw48Q4gk2QmJo5spthgSKIOrLPLzOOvs06VZrx+1n+ yEJ7mbPkPPLVhBJtk1+RrUkWR55VKCXBDuIanjadDD5+0+99y1DL6L7tmQQQgVvpJkbo /DqA==
X-Gm-Message-State: ALoCoQkFOVMYFnf+4THLPPdkW+2GegAEyp2xPeGFuDJZ8hbcH7TPTku2GlRvIufbbJnNP63cbYru
MIME-Version: 1.0
X-Received: by 10.221.39.137 with SMTP id tm9mr233309vcb.63.1386784661112; Wed, 11 Dec 2013 09:57:41 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Wed, 11 Dec 2013 09:57:41 -0800 (PST)
X-Originating-IP: [172.19.243.70]
In-Reply-To: <CAHBU6isVbTq9d9b5oDsG69FDRyahcQObZP+y=gAmmHZ0ahRakQ@mail.gmail.com>
References: <20131211055159.7776.12906.idtracker@ietfa.amsl.com> <CAHBU6isVbTq9d9b5oDsG69FDRyahcQObZP+y=gAmmHZ0ahRakQ@mail.gmail.com>
Date: Wed, 11 Dec 2013 09:57:41 -0800
Message-ID: <CAHBU6isqVjB7c=2_ckJp3G1n_2mGMM8OutSL3zV4UyRe6e2a1A@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: "json@ietf.org" <json@ietf.org>
Content-Type: multipart/alternative; boundary=001a11339dd81b215504ed45f7af
Subject: Re: [Json] I-D Action: draft-ietf-json-rfc4627bis-09.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 17:57:49 -0000

--001a11339dd81b215504ed45f7af
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Oops, there=E2=80=99s an error in that draft.  In section 1.3 -
http://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-09.html#rfc.section.1.3=
 -
it still says that this spec doesn=E2=80=99t change JSON.  Rob caught this =
in the
intro and I fixed that, but missed it here.  Sorry.

I touched base with the chairs & AD, and they suggested I just bring it up
here, and there=E2=80=99s no point doing another draft just for this; let t=
he RFC
editor clean up.

So, the change is to change the last para of 1.3 to read:

=E2=80=9CThe revision's goal is to apply the errata, remove inconsistencies=
 with
other specifications of JSON, and highlight practices which can lead to
interoperability problems.=E2=80=9D


On Tue, Dec 10, 2013 at 9:53 PM, Tim Bray <tbray@textuality.com> wrote:

> A real HTML version is at
> https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-09.html
>
>
> On Tue, Dec 10, 2013 at 9:51 PM, <internet-drafts@ietf.org> wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>  This draft is a work item of the JavaScript Object Notation Working
>> Group of the IETF.
>>
>>         Title           : The JSON Data Interchange Format
>>         Author(s)       : Tim Bray
>>         Filename        : draft-ietf-json-rfc4627bis-09.txt
>>         Pages           : 15
>>         Date            : 2013-12-10
>>
>> Abstract:
>>    JavaScript Object Notation (JSON) is a lightweight, text-based,
>>    language-independent data interchange format.  It was derived from
>>    the ECMAScript Programming Language Standard.  JSON defines a small
>>    set of formatting rules for the portable representation of structured
>>    data.
>>
>>    This document removes inconsistencies with other specifications of
>>    JSON, repairs specification errors, and offers experience-based
>>    interoperability guidance.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-09
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-09
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> json mailing list
>> json@ietf.org
>> https://www.ietf.org/mailman/listinfo/json
>>
>
>

--001a11339dd81b215504ed45f7af
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Oops, there=E2=80=99s an error in that draft. =C2=A0In sec=
tion 1.3 -=C2=A0<a href=3D"http://www.tbray.org/tmp/draft-ietf-json-rfc4627=
bis-09.html#rfc.section.1.3" style=3D"font-family:arial,sans-serif;font-siz=
e:13px" target=3D"_blank">http://www.tbray.org/tmp/draft-ietf-json-rfc4627b=
is-09.html#rfc.section.1.3</a><span style=3D"color:rgb(80,0,80);font-family=
:arial,sans-serif;font-size:13px">=C2=A0- it still says that this spec does=
n=E2=80=99t change JSON. =C2=A0Rob caught this in the intro and I fixed tha=
t, but missed it here. =C2=A0Sorry.</span><div>
<span style=3D"color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13=
px"><br></span></div><div><span style=3D"color:rgb(80,0,80);font-family:ari=
al,sans-serif;font-size:13px">I touched base with the chairs &amp; AD, and =
they suggested I just bring it up here, and there=E2=80=99s no point doing =
another draft just for this; let the RFC editor clean up. =C2=A0</span></di=
v>
<div><span style=3D"color:rgb(80,0,80);font-family:arial,sans-serif;font-si=
ze:13px"><br></span></div><div><span style=3D"color:rgb(80,0,80);font-famil=
y:arial,sans-serif;font-size:13px">So, the change is to change the last par=
a of 1.3 to read:</span></div>
<div><span style=3D"color:rgb(80,0,80);font-family:arial,sans-serif;font-si=
ze:13px"><br></span></div><div><font color=3D"#500050" face=3D"arial, sans-=
serif">=E2=80=9CThe revision&#39;s goal is to apply the errata, remove inco=
nsistencies with other specifications of JSON, and highlight practices whic=
h can lead to interoperability problems.=E2=80=9D</font><br>
</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">O=
n Tue, Dec 10, 2013 at 9:53 PM, Tim Bray <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:tbray@textuality.com" target=3D"_blank">tbray@textuality.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">A real HTML version is at=
=C2=A0<a href=3D"https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-09.ht=
ml" target=3D"_blank">https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-=
09.html</a></div>
<div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><br>=
<div class=3D"gmail_quote">
On Tue, Dec 10, 2013 at 9:51 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:i=
nternet-drafts@ietf.org" target=3D"_blank">internet-drafts@ietf.org</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.<br>
=C2=A0This draft is a work item of the JavaScript Object Notation Working G=
roup of the IETF.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : The =
JSON Data Interchange Format<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Tim Bray<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet=
f-json-rfc4627bis-09.txt<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 15<b=
r>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 2013-12-10<br>
<br>
Abstract:<br>
=C2=A0 =C2=A0JavaScript Object Notation (JSON) is a lightweight, text-based=
,<br>
=C2=A0 =C2=A0language-independent data interchange format. =C2=A0It was der=
ived from<br>
=C2=A0 =C2=A0the ECMAScript Programming Language Standard. =C2=A0JSON defin=
es a small<br>
=C2=A0 =C2=A0set of formatting rules for the portable representation of str=
uctured<br>
=C2=A0 =C2=A0data.<br>
<br>
=C2=A0 =C2=A0This document removes inconsistencies with other specification=
s of<br>
=C2=A0 =C2=A0JSON, repairs specification errors, and offers experience-base=
d<br>
=C2=A0 =C2=A0interoperability guidance.<br>
<br>
<br>
The IETF datatracker status page for this draft is:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis" tar=
get=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis<=
/a><br>
<br>
There&#39;s also a htmlized version available at:<br>
<a href=3D"http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-09" target=
=3D"_blank">http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-09</a><br=
>
<br>
A diff from the previous version is available at:<br>
<a href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-09=
" target=3D"_blank">http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4=
627bis-09</a><br>
<br>
<br>
Please note that it may take a couple of minutes from the time of submissio=
n<br>
until the htmlized version and diff are available at <a href=3D"http://tool=
s.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br>
<br>
Internet-Drafts are also available by anonymous FTP at:<br>
<a href=3D"ftp://ftp.ietf.org/internet-drafts/" target=3D"_blank">ftp://ftp=
.ietf.org/internet-drafts/</a><br>
<br>
_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org" target=3D"_blank">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--001a11339dd81b215504ed45f7af--

From pfpschneider@gmail.com  Wed Dec 11 11:09:06 2013
Return-Path: <pfpschneider@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3491AE0E9 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 11:09:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 414IejK1Km-H for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 11:09:05 -0800 (PST)
Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAA21AE103 for <json@ietf.org>; Wed, 11 Dec 2013 11:09:04 -0800 (PST)
Received: by mail-qe0-f53.google.com with SMTP id nc12so5558812qeb.40 for <json@ietf.org>; Wed, 11 Dec 2013 11:08:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=ttDz4A+GIm+andXUincZIpU2TALUX0t74fhdkyLNutI=; b=qHKMDsEOj3iS+qL1wNs1/Lz7unH9f4Fid/AbcR9I+FN7Yh+d5J1sWKS62dr+2GLJvA q1Xaf3NOlcr+XSy1A40eG2kV2Ie3M3wjiU/rg7ZeWYfccSGL0LdH+RnbV3SueoNZYDv7 +zyWOhsj5kgF6NFzw58Oezpm2/a3cUtZKIEsmXsQWMR1vVzkoveptoIK/YL64NBj/aky 3PUjwE2t1fxCqMfn2dy6/umRh+uE1QYmeyRpTvygmgmjZftccnw+eoR0p3O1dAz74Rwu yaZh+Pka5+GAv+z+o/02ZVdR8WzfL3K79D9g5svTnt2PqLK6a+qLfZg012KAUTfUQ1WA 4OSw==
X-Received: by 10.224.72.74 with SMTP id l10mr5660704qaj.28.1386788938286; Wed, 11 Dec 2013 11:08:58 -0800 (PST)
Received: from [192.168.95.125] ([199.4.160.88]) by mx.google.com with ESMTPSA id i7sm55230258qeo.7.2013.12.11.11.08.56 for <json@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 11:08:57 -0800 (PST)
Message-ID: <52A8B847.7050606@gmail.com>
Date: Wed, 11 Dec 2013 11:08:55 -0800
From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: JSON WG <json@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Json] surrogate code points in JSON text
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 19:09:06 -0000

IETF RFC4627bis-09 states that strings are sequences of Unicode characters.
The ABNF for unescaped, however, permits any Unicode code point except for
double quote, reverse solidus, and ASCII control characters.  This may be
read to indicate that JSON text can contain surrogate code points (both
paired and unpaired).

Surrogate code points cannot be encoded in UTF-8, UTF-16, or UTF-32 as
Unicode encodings are only defined on Unicode scalar values.

I suggest that RFC4627bis be clarified to explicitly state that JSON texts
do not contain surrogate code points in strings.  This could be done by
modifying the unescaped production to exclude these code points.


Peter F. Patel-Schneider


From julian.reschke@gmx.de  Wed Dec 11 11:24:49 2013
Return-Path: <julian.reschke@gmx.de>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE251AE0CD for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 11:24:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 qA3OvwL67TdW for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 11:24:47 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8155A1AE06F for <json@ietf.org>; Wed, 11 Dec 2013 11:24:47 -0800 (PST)
Received: from [192.168.2.117] ([93.217.81.245]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LgISa-1VE93F01qO-00njz7 for <json@ietf.org>; Wed, 11 Dec 2013 20:24:41 +0100
Message-ID: <52A8BBF7.4090809@gmx.de>
Date: Wed, 11 Dec 2013 20:24:39 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>,  JSON WG <json@ietf.org>
References: <52A8B847.7050606@gmail.com>
In-Reply-To: <52A8B847.7050606@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:SHS64v/0466IQ5hjXOfP+PlGvBrpbczDX0vuyHyZc0iSSVbGZ2f R2PDJGErHPAl8ztNYUA4LhiE/YZ4Tz9Kjoc7fqTXiUqpsEghamdKVElXw/waOBhCmaTukDS iREGssNiGUFiPdsm/ARC0fWBPrTIHjnZPZpvGNqNzJbeCwGxIi8dAydzu3AZDOKbFXdr8yR citP1X3d8Q6UtQLqzuPUA==
Subject: Re: [Json] surrogate code points in JSON text
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 19:24:49 -0000

On 2013-12-11 20:08, Peter F. Patel-Schneider wrote:
> IETF RFC4627bis-09 states that strings are sequences of Unicode characters.
> The ABNF for unescaped, however, permits any Unicode code point except for
> double quote, reverse solidus, and ASCII control characters.  This may be
> read to indicate that JSON text can contain surrogate code points (both
> paired and unpaired).
>
> Surrogate code points cannot be encoded in UTF-8, UTF-16, or UTF-32 as
> Unicode encodings are only defined on Unicode scalar values.
>
> I suggest that RFC4627bis be clarified to explicitly state that JSON texts
> do not contain surrogate code points in strings.  This could be done by
> modifying the unescaped production to exclude these code points.

You realize that the situation is different for unpaired surrogates that 
appear as \u sequences?

Best regards, Julian


From pfpschneider@gmail.com  Wed Dec 11 11:30:25 2013
Return-Path: <pfpschneider@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55D01AE1A1 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 11:30:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 oOq5BzkR0kng for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 11:30:24 -0800 (PST)
Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 22E541AE19C for <json@ietf.org>; Wed, 11 Dec 2013 11:30:24 -0800 (PST)
Received: by mail-qa0-f51.google.com with SMTP id o15so929682qap.3 for <json@ietf.org>; Wed, 11 Dec 2013 11:30:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=WRjWUOrT/8kXT8VNejXYZ6fZ5l7U+DlFfY4C4yaDll0=; b=Vy+vgAEX/4VWWOQrb59NxcqnGd0MlKbmxbg6Jdr07fB//ZIBJhLgePBjQScCYdWbA3 deqH+1oaJIongU4hHRLg6Y2zGaeBfUuGOwz5ERcS1MCAqydlGeFZon8r/4dirZ2hvTkv gBfsqfHqs8Fm4iE6BSxbd1DXl975aak9HK38oDpOCfFh6MDAL/H9IJGLeXm++j3ZcqRM 4/niqMtfSpB4fnw185INTE1kXc7svOMq8EhFZyCT2BbD+5fIBrTNs5M/k7FZCSGKHvBP jX3Dzl6ZmUPvD/68WGS7nUzfSGHW0QT0eNAEgAvI6htu462erGFZZFBEjNhvOMARBXcR rPGw==
X-Received: by 10.224.73.200 with SMTP id r8mr5751466qaj.72.1386790218334; Wed, 11 Dec 2013 11:30:18 -0800 (PST)
Received: from [192.168.95.125] ([199.4.160.88]) by mx.google.com with ESMTPSA id u17sm55420922qeb.4.2013.12.11.11.30.16 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 11:30:17 -0800 (PST)
Message-ID: <52A8BD47.9040404@gmail.com>
Date: Wed, 11 Dec 2013 11:30:15 -0800
From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>, JSON WG <json@ietf.org>
References: <52A8B847.7050606@gmail.com> <52A8BBF7.4090809@gmx.de>
In-Reply-To: <52A8BBF7.4090809@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Json] surrogate code points in JSON text
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 19:30:25 -0000

Yes, this comment is only about surrogate code points that appear directly in 
JSON texts.

peter

On 12/11/2013 11:24 AM, Julian Reschke wrote:
> On 2013-12-11 20:08, Peter F. Patel-Schneider wrote:
>> IETF RFC4627bis-09 states that strings are sequences of Unicode characters.
>> The ABNF for unescaped, however, permits any Unicode code point except for
>> double quote, reverse solidus, and ASCII control characters. This may be
>> read to indicate that JSON text can contain surrogate code points (both
>> paired and unpaired).
>>
>> Surrogate code points cannot be encoded in UTF-8, UTF-16, or UTF-32 as
>> Unicode encodings are only defined on Unicode scalar values.
>>
>> I suggest that RFC4627bis be clarified to explicitly state that JSON texts
>> do not contain surrogate code points in strings.  This could be done by
>> modifying the unescaped production to exclude these code points.
>
> You realize that the situation is different for unpaired surrogates that 
> appear as \u sequences?
>
> Best regards, Julian
>


From cabo@tzi.org  Wed Dec 11 11:36:53 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03011AE1CB for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 11:36:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 1IfwoBL0116O for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 11:36:52 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 189001AE164 for <json@ietf.org>; Wed, 11 Dec 2013 11:36:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBBJae6A004207; Wed, 11 Dec 2013 20:36:40 +0100 (CET)
Received: from [192.168.217.144] (p5489295F.dip0.t-ipconnect.de [84.137.41.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EB209EDA; Wed, 11 Dec 2013 20:36:39 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <52A8BD47.9040404@gmail.com>
Date: Wed, 11 Dec 2013 20:36:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <CC3BF618-93C3-4851-A046-CDD8440AC8A2@tzi.org>
References: <52A8B847.7050606@gmail.com> <52A8BBF7.4090809@gmx.de> <52A8BD47.9040404@gmail.com>
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
X-Mailer: Apple Mail (2.1822)
Cc: Julian Reschke <julian.reschke@gmx.de>, JSON WG <json@ietf.org>
Subject: Re: [Json] surrogate code points in JSON text
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 19:36:53 -0000

On 11 Dec 2013, at 20:30, Peter F. Patel-Schneider =
<pfpschneider@gmail.com> wrote:

> Yes, this comment is only about surrogate code points that appear =
directly in JSON texts.

They can=92t, because JSON is encoded in one of the Unicode CES, and =
those won=92t provide those code points.
(See also section 8.2.)

One could argue that this point should be made more explicit than leave =
it as an exercise to the reader.

When this was last discussed, we were still trying not to change JSON =
from RFC4627.
Since that objective has been abandoned, we might as well fix the =
grammar:

OLD:
      unescaped =3D %x20-21 / %x23-5B / %x5D-10FFFF
NEW:
      unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %E000-10FFFF

Is that what you mean?

Gr=FC=DFe, Carsten


From pfpschneider@gmail.com  Wed Dec 11 11:43:48 2013
Return-Path: <pfpschneider@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6181ADFAD for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 11:43:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 4OdKdirxqYXB for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 11:43:46 -0800 (PST)
Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2661AE01B for <json@ietf.org>; Wed, 11 Dec 2013 11:43:46 -0800 (PST)
Received: by mail-qc0-f178.google.com with SMTP id i17so5643154qcy.9 for <json@ietf.org>; Wed, 11 Dec 2013 11:43:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=T/h2WORya5KQRSU4mJsit3pSmEXj7xoX4bXfUx8wtvo=; b=cS3R61y+gJHFrIg5P1KTjB8GB5e5VHH/epVGWJQAiL8dNgHfNQayoe7PNdIY3sGNHE FJta/NwytqE8+f7C8c7lniNhNO/9bhK2i8XD3Jd1i0BFbLML/IQcvp828BHkXA4CYbqr N8W6TlLqGBQuJ2Wm//JudveHz51QMTbgYhRgnV12+Lt2g/+iSf8SEB0Gd4rfuUVuuBxx y+1a98c4jWrA4NbmiLiHyo0uY6Pynf8wUh4ztt9dfGUzfofB2zfyL2rfovfVr6vjckHN peATszKo+Pm6O2W2RztmApjfTkFgMkaPJwz9uJUJV37HVAhmxq9fKQkqVTA6zFV+GGc/ PJAQ==
X-Received: by 10.224.95.70 with SMTP id c6mr5753054qan.81.1386791020801; Wed, 11 Dec 2013 11:43:40 -0800 (PST)
Received: from [192.168.95.125] ([199.4.160.88]) by mx.google.com with ESMTPSA id d1sm8356638qai.7.2013.12.11.11.43.38 for <json@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 11:43:39 -0800 (PST)
Message-ID: <52A8C069.3040206@gmail.com>
Date: Wed, 11 Dec 2013 11:43:37 -0800
From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: JSON WG <json@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Json] clarify decoding of JSON string escapes
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 19:43:48 -0000

It is not completely clear how to decode the JSON string "\uD834\uDD1E"

One way would be to produce a string containing two Unicode code points.  The 
other way would be to produce a string containing a single Unicode scalar value.

It is fairly obvious that the second is preferred, and some readings of 
rdf4627bis-09 would indicate that the first is not allowed. However, the 
discussion in Section 8.2 seems to indicate that the first way could be 
permissible.

I think that it would be useful to indicate that JSON \u escapes must be 
decoded to produce Unicode scalar values wherever possible.


Peter F. Patel-Schneider

PS:  The discussion in 8.2 could be improved by talking about Unicode scalar 
values instead of Unicode characters.


From jhildebr@cisco.com  Wed Dec 11 11:49:46 2013
Return-Path: <jhildebr@cisco.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FCB1AE1F3 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 11:49:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level: 
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 Rp8rzJNbAyiu for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 11:49:45 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1265A1AE1DB for <json@ietf.org>; Wed, 11 Dec 2013 11:49:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=626; q=dns/txt; s=iport; t=1386791379; x=1388000979; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rZkJvgbpshbs/BKWY0Ahr6kHyhXiAQ2AW9M4w/jBWUY=; b=MTXCcD3Ayel5EBOjZJWm0p4Fi8YFjbjBHsOMiNiIzgg1Xr4XBNGJmcKB 6nVabHQ+s9HcKHtiAwL9r9h+dtzflgajlfr8qjURM9PhDgLaxndlxbB4l 4KgOQ+uM9nQ2mO4deUwv9Tc/+wI7wFEYrmZeqnyqQa/avSb/ECFT70Y4i 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAH/AqFKtJXHB/2dsb2JhbABZgweBC7kZgR0WdIImAQEEOj8QAgEIDigQMiUCBAENBYgCwjcXjwgHhDQEmBSSE4Mpgio
X-IronPort-AV: E=Sophos;i="4.93,873,1378857600";  d="scan'208";a="6077400"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-7.cisco.com with ESMTP; 11 Dec 2013 19:49:39 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBBJndAp010540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 19:49:39 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 13:49:38 -0600
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: Carsten Bormann <cabo@tzi.org>, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
Thread-Topic: [Json] surrogate code points in JSON text
Thread-Index: AQHO9qR2zp7kp11BVkON+j+FjhSBJZpPxJGAgAABkICAAAHIgP//fYOA
Date: Wed, 11 Dec 2013 19:49:37 +0000
Message-ID: <CECE00BB.30680%jhildebr@cisco.com>
References: <52A8B847.7050606@gmail.com> <52A8BBF7.4090809@gmx.de> <52A8BD47.9040404@gmail.com> <CC3BF618-93C3-4851-A046-CDD8440AC8A2@tzi.org>
In-Reply-To: <CC3BF618-93C3-4851-A046-CDD8440AC8A2@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.155.52.161]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <853FD5E58B993241B190B2FFD85B7807@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Julian Reschke <julian.reschke@gmx.de>, JSON WG <json@ietf.org>
Subject: Re: [Json] surrogate code points in JSON text
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 19:49:46 -0000

On 12/11/13 11:36 AM, "Carsten Bormann" <cabo@tzi.org> wrote:

>When this was last discussed, we were still trying not to change JSON
>from RFC4627.
>Since that objective has been abandoned, we might as well fix the grammar:
>
>OLD:
>      unescaped =3D %x20-21 / %x23-5B / %x5D-10FFFF
>NEW:
>      unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %E000-10FFFF
>
>Is that what you mean?

Yes, please.  Strong +1.  If you really want to include an unpaired
surrogate, you MUST escape it.  "\uDEAD" is valid, <0022 DEAD 0022> is
not, because it can't occur in a valid transmitted document.

--=20
Joe Hildebrand




From pfpschneider@gmail.com  Wed Dec 11 11:55:46 2013
Return-Path: <pfpschneider@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022D01AE1C4 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 11:55:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 LvgwodgXfmNP for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 11:55:44 -0800 (PST)
Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCE91AE1BE for <json@ietf.org>; Wed, 11 Dec 2013 11:55:44 -0800 (PST)
Received: by mail-qe0-f46.google.com with SMTP id a11so5648414qen.19 for <json@ietf.org>; Wed, 11 Dec 2013 11:55:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=baJn17qnwWjdpm8bWYiXqAGYhTTRRbQL4zmCkfvKZjg=; b=vRXhYfU1AzbjTcbBhOtMp5FYl8zd041EcNKt0IQghNGjf3pCzvIk2bYlZJD649Zfq4 UCHz++gwghAnsXUFLKRkGpOMDsD3PI5BsMPa5SI/P4ciO4u3Bm8H/kIHfEdA5bC01XSL xP7CHCEUbcCdvK2YD2AIsPTTdtvO/qFaf0zf1ZD/YWJW6zmd/rER7JbDlU8LxqpLZ8TY cc89KU4EKPZvMkeeaxQRGB3NWk7X1sLlUiTvC1jfV0F7K54vO9zAtUxOvyciubtRLjJC h2a5EqgEK171ytMP7w5P1cfxW5bph0ccACOmK+WSsXThKRn+1itpwo3W/rXXQKWNI06J myHw==
X-Received: by 10.224.46.8 with SMTP id h8mr5890664qaf.49.1386791738384; Wed, 11 Dec 2013 11:55:38 -0800 (PST)
Received: from [192.168.95.125] ([199.4.160.88]) by mx.google.com with ESMTPSA id lc1sm10539650qeb.5.2013.12.11.11.55.36 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 11:55:37 -0800 (PST)
Message-ID: <52A8C336.8070605@gmail.com>
Date: Wed, 11 Dec 2013 11:55:34 -0800
From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Carsten Bormann <cabo@tzi.org>
References: <52A8B847.7050606@gmail.com> <52A8BBF7.4090809@gmx.de> <52A8BD47.9040404@gmail.com> <CC3BF618-93C3-4851-A046-CDD8440AC8A2@tzi.org>
In-Reply-To: <CC3BF618-93C3-4851-A046-CDD8440AC8A2@tzi.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Julian Reschke <julian.reschke@gmx.de>, JSON WG <json@ietf.org>
Subject: Re: [Json] surrogate code points in JSON text
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 19:55:46 -0000

Yes, I agree that the best way forward is to make the change to unescaped that 
you suggest (and add some discussion of the change).

However, JSON can exist outside a Unicode encoding, so it is arguable that 
JSON texts can contain surrogate code points.  I say arguable because 
RFC4627bis talks about sequences of Unicode characters, but that would also 
exclude unassigned code points which I don't think is intended.  Of course 
JSON texts containing surrogate characters are not very useful in the IETF 
context as they can only be transferred using some agreement outside RFC4627.

peter


On 12/11/2013 11:36 AM, Carsten Bormann wrote:
> On 11 Dec 2013, at 20:30, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>
>> Yes, this comment is only about surrogate code points that appear directly in JSON texts.
> They can’t, because JSON is encoded in one of the Unicode CES, and those won’t provide those code points.
> (See also section 8.2.)
>
> One could argue that this point should be made more explicit than leave it as an exercise to the reader.
>
> When this was last discussed, we were still trying not to change JSON from RFC4627.
> Since that objective has been abandoned, we might as well fix the grammar:
>
> OLD:
>        unescaped = %x20-21 / %x23-5B / %x5D-10FFFF
> NEW:
>        unescaped = %x20-21 / %x23-5B / %x5D-D7FF / %E000-10FFFF
>
> Is that what you mean?
>
> Grüße, Carsten
>


From jhildebr@cisco.com  Wed Dec 11 12:03:45 2013
Return-Path: <jhildebr@cisco.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1901AE195 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 12:03:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 vQkkzV2EwiFT for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 12:03:44 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 14C9F1AE11C for <json@ietf.org>; Wed, 11 Dec 2013 12:03:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1627; q=dns/txt; s=iport; t=1386792218; x=1388001818; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=TLOLVYh3QOZkT1Zj3A1jN5LnzftZbP5OCgdT7S8D798=; b=UjGZ3YkYteWIxheCII+xMahE2KACpyB0xmjGe4jSbF7E/bGwVEXjirkg UVemeOewSjD90vJIUbTToAmFJK1Tr5F4QUVwF9hn2Nk16M9WpvK3YiBQJ sUBGCdrPdy7cHi0G5emZwctyKpEcpAVDCBQNpKzn245EJ/E+R2U3M6ts3 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAL7EqFKtJV2c/2dsb2JhbABZgweBC7kZgR0WdIImAQEEOk8CAQg2ECERJQIEARKHcAMPuxoNhwoXjHWCGoQ0BJYpgWuMWoU5gymCKg
X-IronPort-AV: E=Sophos;i="4.93,873,1378857600"; d="scan'208";a="290952969"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 11 Dec 2013 20:03:18 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rBBK3Ih7020600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 20:03:18 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 14:03:18 -0600
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, JSON WG <json@ietf.org>
Thread-Topic: [Json] clarify decoding of JSON string escapes
Thread-Index: AQHO9qlPnrtIZUj1QEKeMVVmyyP1x5pPSTSA
Date: Wed, 11 Dec 2013 20:03:17 +0000
Message-ID: <CECE0269.306B2%jhildebr@cisco.com>
References: <52A8C069.3040206@gmail.com>
In-Reply-To: <52A8C069.3040206@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.155.52.161]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2EF2EF8939E4AD42A447340981000AE6@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Json] clarify decoding of JSON string escapes
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 20:03:45 -0000

On 12/11/13 11:43 AM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
wrote:

>It is not completely clear how to decode the JSON string "\uD834\uDD1E"
>
>One way would be to produce a string containing two Unicode code points.
>The=20
>other way would be to produce a string containing a single Unicode scalar
>value.
>
>It is fairly obvious that the second is preferred, and some readings of
>rdf4627bis-09 would indicate that the first is not allowed. However, the
>discussion in Section 8.2 seems to indicate that the first way could be
>permissible.
>
>I think that it would be useful to indicate that JSON \u escapes must be
>decoded to produce Unicode scalar values wherever possible.

I wanted you to be wrong, but in my re-reading of -09, I see text in
section 7 about *generating* escape sequences, but nothing about how to
parse them.  I think we would need text along the lines of:

"""
When parsing a JSON string, if an escaped lead surrogate in the range
\uD800 to \uDBFF is followed immediately by a trail surrogate in the range
\uDC00 to \uDFFF, the two escape sequences combined represent a single
Unicode code point.  Any other combination of \u escapes represent
individual code points.
"""

This could either go in section 7 or section 8.2.


>PS:  The discussion in 8.2 could be improved by talking about Unicode
>scalar
>values instead of Unicode characters.

I think the intent of that section is that things that are currently
assigned characters interop much better than anything else.  As such, I
think the current language is fine.

--=20
Joe Hildebrand




From jhildebr@cisco.com  Wed Dec 11 12:06:36 2013
Return-Path: <jhildebr@cisco.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366E81AE03F for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 12:06:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 VsovbTbHk-cy for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 12:06:35 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id F2C831ADFB8 for <json@ietf.org>; Wed, 11 Dec 2013 12:06:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1008; q=dns/txt; s=iport; t=1386792389; x=1388001989; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zE/fQM27hX2HlFXF+K94gbWrKq6dHg/pz9gn9BaZTaw=; b=Y9hZ1KETF+cDXeNVBCphRTgoBFfOziLBFOtWaThLsF52gtY9hmTY2Rgc pHQdW3nmQlJT10bbszIi0m9ZnV3SbP8Au41ykqjjY4TPjRdmbnsYSyEHW DQvMbfWJpGUAseQ/8v0QSZXGeHcVhnQ2Spw8QN+2WQ4PAabjGgqA4bIVy 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAFnFqFKtJXHA/2dsb2JhbABZgweBC7kZgR0WdIImAQEEOj8QAgEINhAhESUCBAEJBAWHcAMPuxgNhwoXjHWCEweENASWKYFrjFqFOYMpgio
X-IronPort-AV: E=Sophos;i="4.93,873,1378857600"; d="scan'208";a="290913047"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 11 Dec 2013 20:06:29 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rBBK6Tjk022995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 20:06:29 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 14:06:28 -0600
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, Carsten Bormann <cabo@tzi.org>
Thread-Topic: [Json] surrogate code points in JSON text
Thread-Index: AQHO9qR2zp7kp11BVkON+j+FjhSBJZpPxJGAgAABkICAAAHIgIAABUsA//986wA=
Date: Wed, 11 Dec 2013 20:06:28 +0000
Message-ID: <CECE051E.306FF%jhildebr@cisco.com>
References: <52A8B847.7050606@gmail.com> <52A8BBF7.4090809@gmx.de> <52A8BD47.9040404@gmail.com> <CC3BF618-93C3-4851-A046-CDD8440AC8A2@tzi.org> <52A8C336.8070605@gmail.com>
In-Reply-To: <52A8C336.8070605@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.155.52.161]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <630FFD8852324B47980DE1150D4B044E@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Julian Reschke <julian.reschke@gmx.de>, JSON WG <json@ietf.org>
Subject: Re: [Json] surrogate code points in JSON text
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 20:06:36 -0000

On 12/11/13 11:55 AM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
wrote:

>However, JSON can exist outside a Unicode encoding, so it is arguable that
>JSON texts can contain surrogate code points.

Not in 4627bis land.  But I agree that in the internal programming
language representation, there are times when this can happen.

I think we need to make it crystal clear that if you want to transmit one
of those internal representations and call it JSON, the only way it's
going to interop is if you first \u-encode the brokenness.

>I say arguable because
>RFC4627bis talks about sequences of Unicode characters, but that would
>also=20
>exclude unassigned code points which I don't think is intended.  Of
>course=20
>JSON texts containing surrogate characters are not very useful in the
>IETF=20
>context as they can only be transferred using some agreement outside
>RFC4627.

That's not currently correct.  They can be transmitted in escaped form.

--=20
Joe Hildebrand




From jhildebr@cisco.com  Wed Dec 11 12:10:55 2013
Return-Path: <jhildebr@cisco.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656DF1AE1EB for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 12:10:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 eMFpZH8cSBSG for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 12:10:54 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DE4B81AE1E0 for <json@ietf.org>; Wed, 11 Dec 2013 12:10:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1158; q=dns/txt; s=iport; t=1386792648; x=1388002248; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mpuL8ZEsMZ1+t0t9BiUJplov9Hf1Psew+YzldpStepo=; b=RBAAhdgb9/Gd/A/8KESxiToFeaKh795c33aYd0lUbqXpAtw6U5aSm/Xv a9oSebDIpriADi3YKsq7QWQbM8MxHNQJRSRect6KWUbeFdASg99GZdMro TZ/qPYKWVYn/5TlNIH7eZunzGAfOyipU9O63n0JG06Xlpk8fM68BjDTsm s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAInGqFKtJXG8/2dsb2JhbABZgweBC7kZgR0WdIImAQEEOj8QAgEINhAyJQIEDgWIAsIzF48IB4Q0BJQxg2OSE4Mpgio
X-IronPort-AV: E=Sophos;i="4.93,873,1378857600"; d="scan'208";a="290913969"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 11 Dec 2013 20:10:48 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBBKAmQH013581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 20:10:48 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 14:10:47 -0600
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>, "Patel-Schneider, Peter" <Peter.Patel-Schneider@nuance.com>
Thread-Topic: [Json] Fwd: two comments on JSON, ECMA-404, 1st edition / October 2013
Thread-Index: AQHO9q0UWOHIlmQu20S0lXRDAvznWg==
Date: Wed, 11 Dec 2013 20:10:47 +0000
Message-ID: <CECE0606.3071B%jhildebr@cisco.com>
References: <7FD8497D-5E19-4EFE-B66E-538FC42B7478@nuance.com> <7895D7DA-E608-49DF-8984-FFC91AFDBF04@tzi.org> <932988A1-588C-48BF-A35A-829B7CE2021F@nuance.com> <EC9703BD-27A8-4EED-9BAB-2F91660D5330@wirfs-brock.com>
In-Reply-To: <EC9703BD-27A8-4EED-9BAB-2F91660D5330@wirfs-brock.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.155.52.161]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <349E2FAECB07D54C8A43A050377A237D@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Carsten Bormann <cabo@tzi.org>, JSON WG <json@ietf.org>, es-discuss list <es-discuss@mozilla.org>
Subject: Re: [Json] Fwd: two comments on JSON, ECMA-404, 1st edition / October 2013
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 20:10:55 -0000

On 12/10/13 5:29 PM, "Allen Wirfs-Brock" <allen@wirfs-brock.com> wrote:

>The code point sequence <0022, DEAD, 0022> is indeed, and intentionally,
>a a valid JSON text according ECMA-404.  JSON parsers do not exclusively
>operate upon sequences of Unicode scalar values.  From its earliest days
>JSON as been parse using input sources
> (such as program language string abstractions)  that can are actually
>used to encode code points that are not Unicode Scalar Values. (For
>example, JavaScript strings UTF-16 encode supplementary characters but
>also allow unpaired surrogates)  The intent of
> ECMA-404 is to provide a grammar that is usable in such implementation
>as well as implementation that only deal with well formed UTF encodings.

As I've said on the other thread, <0022, DEAD, 0022> may be valid in the
programming model that ECMAscript uses, but when transmitted on the wire
according to 4627bis, it would need to get rendered as "\uDEAD" in order
to be encoded as interoperable UTF8.  CESU-8 has never been a valid
encoding scheme for 4627, and we'd have to have pretty strong consensus to
add it.

--=20
Joe Hildebrand




From pfpschneider@gmail.com  Wed Dec 11 12:48:34 2013
Return-Path: <pfpschneider@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4311AE090 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 12:48:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 Dl_5O2AP1-b6 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 12:48:33 -0800 (PST)
Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4271AE052 for <json@ietf.org>; Wed, 11 Dec 2013 12:48:33 -0800 (PST)
Received: by mail-qa0-f42.google.com with SMTP id k4so5167568qaq.15 for <json@ietf.org>; Wed, 11 Dec 2013 12:48:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZvO+N5D4GVH46zPSuvUGIvGYxj+JZUCHyZA4UNsE4cg=; b=c9YJTwKe7KSTzQn5P2e+aGcrCb13vRvoP9yshMh6XQwZTAfqZASe/Kv10Ig0Rsf8Aq Qnz1NYmjOnxd2ET9FjuestjTTt4/KLftpWPBVQhuBwkH+++tNAZsNwIUnG9xllYbnyTE 6HVoowKa8IaG2IXUgAPicHX317X07pYla0vAxKPI/RvVjHHCwxCwRhm8cnsGHa237iHi 9SundlX4jvkyNsfIJTOeQ2jxR0mNpGEh775z0fDnfEislC02ZFb0Qq6Ns1RDyRCH69t8 kI7vQKxppDuxaRiICQrMmHBuoqHuMtbIdw4k4gzsep6PI1HYgYrOQL1DDgPSWOdafWXa a0kA==
X-Received: by 10.224.51.196 with SMTP id e4mr6413989qag.16.1386794907572; Wed, 11 Dec 2013 12:48:27 -0800 (PST)
Received: from [192.168.95.125] ([199.4.160.88]) by mx.google.com with ESMTPSA id 4sm62871575qak.11.2013.12.11.12.48.22 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 12:48:26 -0800 (PST)
Message-ID: <52A8CF92.1080204@gmail.com>
Date: Wed, 11 Dec 2013 12:48:18 -0800
From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>,  Carsten Bormann <cabo@tzi.org>
References: <52A8B847.7050606@gmail.com> <52A8BBF7.4090809@gmx.de> <52A8BD47.9040404@gmail.com> <CC3BF618-93C3-4851-A046-CDD8440AC8A2@tzi.org> <52A8C336.8070605@gmail.com> <CECE051E.306FF%jhildebr@cisco.com>
In-Reply-To: <CECE051E.306FF%jhildebr@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Julian Reschke <julian.reschke@gmx.de>, JSON WG <json@ietf.org>
Subject: Re: [Json] surrogate code points in JSON text
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 20:48:35 -0000

On 12/11/2013 12:06 PM, Joe Hildebrand (jhildebr) wrote:
> On 12/11/13 11:55 AM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
> wrote:
>
> [...]
>> I say arguable because
>> RFC4627bis talks about sequences of Unicode characters, but that would
>> also
>> exclude unassigned code points which I don't think is intended.  Of
>> course
>> JSON texts containing surrogate characters [code points!] are not very useful in the
>> IETF
>> context as they can only be transferred using some agreement outside
>> RFC4627.
> That's not currently correct.  They can be transmitted in escaped form.
>
Where is the process of escaping a JSON text that contains a surrogate code 
point described?

A JSON text that represents the same sequence of (string) code points can 
sometimes be constructed by using the \u mechanism, but that's not an escaped 
form of the original JSON text.

peter


From pfpschneider@gmail.com  Wed Dec 11 12:57:12 2013
Return-Path: <pfpschneider@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040091ADE85 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 12:57:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 XM4IGvEpLOnA for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 12:57:10 -0800 (PST)
Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id AB8441ADF68 for <json@ietf.org>; Wed, 11 Dec 2013 12:57:10 -0800 (PST)
Received: by mail-qe0-f54.google.com with SMTP id cy11so5986531qeb.27 for <json@ietf.org>; Wed, 11 Dec 2013 12:57:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gsQJ7DcSNoiFB3+Q7nT9L2swTWZTFEUj9cT+ry22Zyc=; b=PSw1uiQz4hl3crbNSpO3zBdGbnsTEVIHyZpOuAl2yHZWjGeckG6SC+1ZG0G+l2kl8S 1vgdd03piezWLi0isYqThTz/xxkylvZRr2eq0HFd97UjwrMcZpcnIqgdJdZw5WcuntRZ Jdzz3jeJpxLrLnjmj/rXjLb9yGzQUkmgkp++nFcgVHm9xyFbvLIrl5VfhAlXwMUQQLH/ SzZk9TXUo2jNEE/XkmnKUwpQU2KNrYIZBYjgwhzj+2IfK6YkRlUqeTUAUtj9RkN0k3Oq aYIIZtIyznqsR1NJStn2L+eaPCyMrDuvP3tg0ZOT6Q5ieQArT91lLieMFVuq+RVPm4Hu t5Og==
X-Received: by 10.49.52.34 with SMTP id q2mr6633958qeo.10.1386795424560; Wed, 11 Dec 2013 12:57:04 -0800 (PST)
Received: from [192.168.95.125] ([199.4.160.88]) by mx.google.com with ESMTPSA id x10sm62985941qas.5.2013.12.11.12.57.03 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 12:57:03 -0800 (PST)
Message-ID: <52A8D19D.9090401@gmail.com>
Date: Wed, 11 Dec 2013 12:57:01 -0800
From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>, JSON WG <json@ietf.org>
References: <52A8C069.3040206@gmail.com> <CECE0269.306B2%jhildebr@cisco.com>
In-Reply-To: <CECE0269.306B2%jhildebr@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Json] clarify decoding of JSON string escapes
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 20:57:12 -0000

On 12/11/2013 12:03 PM, Joe Hildebrand (jhildebr) wrote:
> On 12/11/13 11:43 AM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
> wrote:
> [...]
>
>> PS:  The discussion in 8.2 could be improved by talking about Unicode
>> scalar
>> values instead of Unicode characters.
> I think the intent of that section is that things that are currently
> assigned characters interop much better than anything else.  As such, I
> think the current language is fine.
>

I agree that it is also a good idea to avoid unassigned code points.  However, 
8.2 goes on to contrast this with some talk about unpaired surrogate code 
points, which are the code points that really should be avoided.  If 
unassigned code points are also to be avoided, it would be better to have a 
second example showing this.


This is, however, a relatively minor point.

peter


From cabo@tzi.org  Wed Dec 11 13:01:01 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51A51AE15A for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 13:01:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 Nib6bgTWSwyx for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 13:01:01 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id F3FBD1AE0C2 for <json@ietf.org>; Wed, 11 Dec 2013 13:01:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBBL0mKC023216; Wed, 11 Dec 2013 22:00:48 +0100 (CET)
Received: from [192.168.217.144] (p5489295F.dip0.t-ipconnect.de [84.137.41.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 15E46F22; Wed, 11 Dec 2013 22:00:46 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <52A8CF92.1080204@gmail.com>
Date: Wed, 11 Dec 2013 22:00:43 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9855A90C-DE3E-44CC-96A7-63D9D9D36D41@tzi.org>
References: <52A8B847.7050606@gmail.com> <52A8BBF7.4090809@gmx.de> <52A8BD47.9040404@gmail.com> <CC3BF618-93C3-4851-A046-CDD8440AC8A2@tzi.org> <52A8C336.8070605@gmail.com> <CECE051E.306FF%jhildebr@cisco.com> <52A8CF92.1080204@gmail.com>
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
X-Mailer: Apple Mail (2.1822)
Cc: Julian Reschke <julian.reschke@gmx.de>, "Joe Hildebrand \(jhildebr\)" <jhildebr@cisco.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] surrogate code points in JSON text
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 21:01:01 -0000

On 11 Dec 2013, at 21:48, Peter F. Patel-Schneider =
<pfpschneider@gmail.com> wrote:

> Where is the process of escaping a JSON text that contains a surrogate =
code point described?

Can=92t answer that question, as JSON texts don=92t contain surrogate =
code points.

You mean, how to I encode a string with a surrogate code point?
Well, strings can=92t contain surrogate code points either as they are =
sequences of characters.

So 8.2 may strike the right balance here by describing the phenomenon of =
unpaired surrogate escapes but not really explaining how they are =
created except accidentally:

"Instances of this have been observed, for example when a
   library truncates a UTF-16 string without checking whether the
   truncation split a surrogate pair."

Gr=FC=DFe, Carsten


From paul.hoffman@vpnc.org  Wed Dec 11 13:34:43 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476561AE060 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 13:34:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 IjpNfwqoO_2y for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 13:34:42 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 85E871AE00C for <json@ietf.org>; Wed, 11 Dec 2013 13:34:42 -0800 (PST)
Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rBBLYQVR019223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Dec 2013 14:34:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CECE00BB.30680%jhildebr@cisco.com>
Date: Wed, 11 Dec 2013 13:34:25 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <93B1A528-AA45-4166-BFD7-59DE897F8C17@vpnc.org>
References: <52A8B847.7050606@gmail.com> <52A8BBF7.4090809@gmx.de> <52A8BD47.9040404@gmail.com> <CC3BF618-93C3-4851-A046-CDD8440AC8A2@tzi.org> <CECE00BB.30680%jhildebr@cisco.com>
To: Joe Hildebrand Hildebrand <jhildebr@cisco.com>
X-Mailer: Apple Mail (2.1822)
Cc: Julian Reschke <julian.reschke@gmx.de>, Carsten Bormann <cabo@tzi.org>, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] surrogate code points in JSON text
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 21:34:43 -0000

This was discussed at length earlier, and failed for lack of WG =
consensus. Different people strongly felt that their view of What We Are =
Talking About must be the only right one; the strength of those views =
clearly remain, given the threads from this past week.

The current wording is the best that we could get consensus on.

Seeing this flare up yet again here gives me a bit more compassion for =
TC39...

--Paul Hoffman=

From allen@wirfs-brock.com  Wed Dec 11 13:54:49 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DC11AE11B for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 13:54:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 7jiIeaHciHUP for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 13:54:47 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 76C241AE117 for <json@ietf.org>; Wed, 11 Dec 2013 13:54:47 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1Vqrjo-000OLm-Te; Wed, 11 Dec 2013 21:54:37 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+H0AaOCCJZVMF8ifnMRvUfNNDJOwZ0Yu4=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <CECE0606.3071B%jhildebr@cisco.com>
Date: Wed, 11 Dec 2013 13:54:29 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <B5247C21-FAA2-4738-9560-45E22174D720@wirfs-brock.com>
References: <7FD8497D-5E19-4EFE-B66E-538FC42B7478@nuance.com> <7895D7DA-E608-49DF-8984-FFC91AFDBF04@tzi.org> <932988A1-588C-48BF-A35A-829B7CE2021F@nuance.com> <EC9703BD-27A8-4EED-9BAB-2F91660D5330@wirfs-brock.com> <CECE0606.3071B%jhildebr@cisco.com>
To: Joe Hildebrand (jhildebr) <jhildebr@cisco.com>
X-Mailer: Apple Mail (2.1085)
Cc: es-discuss list <es-discuss@mozilla.org>, Carsten Bormann <cabo@tzi.org>, "Patel-Schneider, Peter" <Peter.Patel-Schneider@nuance.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] Fwd: two comments on JSON, ECMA-404, 1st edition / October 2013
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 21:54:49 -0000

On Dec 11, 2013, at 12:10 PM, Joe Hildebrand (jhildebr) wrote:

> On 12/10/13 5:29 PM, "Allen Wirfs-Brock" <allen@wirfs-brock.com> =
wrote:
>=20
>> The code point sequence <0022, DEAD, 0022> is indeed, and =
intentionally,
>> a a valid JSON text according ECMA-404.  JSON parsers do not =
exclusively
>> operate upon sequences of Unicode scalar values.  =46rom its earliest =
days
>> JSON as been parse using input sources
>> (such as program language string abstractions)  that can are actually
>> used to encode code points that are not Unicode Scalar Values. (For
>> example, JavaScript strings UTF-16 encode supplementary characters =
but
>> also allow unpaired surrogates)  The intent of
>> ECMA-404 is to provide a grammar that is usable in such =
implementation
>> as well as implementation that only deal with well formed UTF =
encodings.
>=20
> As I've said on the other thread, <0022, DEAD, 0022> may be valid in =
the
> programming model that ECMAscript uses, but when transmitted on the =
wire
> according to 4627bis, it would need to get rendered as "\uDEAD" in =
order
> to be encoded as interoperable UTF8.  CESU-8 has never been a valid
> encoding scheme for 4627, and we'd have to have pretty strong =
consensus to
> add it.

So, 4627bis can specify that application/json documents an only contain =
Unicode scalar value code points. That means that a applicaiton/json =
JSON text is a subset of all possible JSON texts defined by ECMA-404.  =
What wrong with that?

Allen=

From jhildebr@cisco.com  Wed Dec 11 14:07:25 2013
Return-Path: <jhildebr@cisco.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBDF1AE0A7 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 14:07:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.902
X-Spam-Level: 
X-Spam-Status: No, score=-8.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=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 rA3zZ_wkE-yR for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 14:07:24 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id D43D81AE09A for <json@ietf.org>; Wed, 11 Dec 2013 14:07:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=752; q=dns/txt; s=iport; t=1386799638; x=1388009238; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HEiYR0LPCckhemHy0ukuCs/VJWF6/bT6O7E4kQZPnTE=; b=QhZNFc5Q/HgUuymBgmC2yqXgGNUKz9tS+xXK4EVZd0foYRYlL1H/O++l gBtmscRJPcY8z9aTCw+cPPO6h4THCjEyZk6oQldqZCyGKlyrKg8OZcush B3B9cdsA0XA1BdTua8HBeDopD7KCrp501RnxRyYPqfDEiFmRa/LCKOpmP 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAFLhqFKtJXG//2dsb2JhbABZgweBC7l6gR0WdIImAQEEOj8QAgEINhAyJQIEDgWIAsIsF48IB4Q0BJgUkhODKYIq
X-IronPort-AV: E=Sophos;i="4.93,874,1378857600";  d="scan'208";a="6112241"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-8.cisco.com with ESMTP; 11 Dec 2013 22:07:18 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBBM7Htd031371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 22:07:17 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 16:07:17 -0600
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Thread-Topic: [Json] Fwd: two comments on JSON, ECMA-404, 1st edition / October 2013
Thread-Index: AQHO9q0UWOHIlmQu20S0lXRDAvznWppP7lyA//99cgA=
Date: Wed, 11 Dec 2013 22:07:16 +0000
Message-ID: <CECE2062.307EC%jhildebr@cisco.com>
References: <7FD8497D-5E19-4EFE-B66E-538FC42B7478@nuance.com> <7895D7DA-E608-49DF-8984-FFC91AFDBF04@tzi.org> <932988A1-588C-48BF-A35A-829B7CE2021F@nuance.com> <EC9703BD-27A8-4EED-9BAB-2F91660D5330@wirfs-brock.com> <CECE0606.3071B%jhildebr@cisco.com> <B5247C21-FAA2-4738-9560-45E22174D720@wirfs-brock.com>
In-Reply-To: <B5247C21-FAA2-4738-9560-45E22174D720@wirfs-brock.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.155.52.161]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F7062258CCBFC744932F4DA2AD4630B7@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: es-discuss list <es-discuss@mozilla.org>, Carsten Bormann <cabo@tzi.org>, "Patel-Schneider, Peter" <Peter.Patel-Schneider@nuance.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] Fwd: two comments on JSON, ECMA-404, 1st edition / October 2013
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 22:07:25 -0000

On 12/11/13 1:54 PM, "Allen Wirfs-Brock" <allen@wirfs-brock.com> wrote:

>So, 4627bis can specify that application/json documents an only contain
>Unicode scalar value code points.

Well, it says: "JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32".
It's not legal to encode any code point between U+D800 and U+DFFF in UTF-8
or UTF-32, and invalid UTF-16 to have them paired incorrectly.  So this
restriction is implicit.

>That means that a applicaiton/json JSON text is a subset of all possible
>JSON texts defined by ECMA-404.  What wrong with that?

Nothing, perhaps.  I do think it would be nice to give a little more
guidance about serializing and parsing ECMA-404 to and from the
transmission form.

--=20
Joe Hildebrand




From allen@wirfs-brock.com  Wed Dec 11 14:53:00 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C07A1AE0FA for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 14:53:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 gaUg-t2lg9On for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 14:52:58 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id CB1251AE099 for <json@ietf.org>; Wed, 11 Dec 2013 14:52:58 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1VqseB-000Hdg-Bk; Wed, 11 Dec 2013 22:52:51 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+oMrpI7qzS5xFy/E/39WY1r1YXB4NQReU=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <CECE2062.307EC%jhildebr@cisco.com>
Date: Wed, 11 Dec 2013 14:52:44 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <8CBF1890-1484-4F95-8470-8A3A91EE7D6C@wirfs-brock.com>
References: <7FD8497D-5E19-4EFE-B66E-538FC42B7478@nuance.com> <7895D7DA-E608-49DF-8984-FFC91AFDBF04@tzi.org> <932988A1-588C-48BF-A35A-829B7CE2021F@nuance.com> <EC9703BD-27A8-4EED-9BAB-2F91660D5330@wirfs-brock.com> <CECE0606.3071B%jhildebr@cisco.com> <B5247C21-FAA2-4738-9560-45E22174D720@wirfs-brock.com> <CECE2062.307EC%jhildebr@cisco.com>
To: Joe Hildebrand (jhildebr) <jhildebr@cisco.com>
X-Mailer: Apple Mail (2.1085)
Cc: JSON WG <json@ietf.org>, Carsten Bormann <cabo@tzi.org>, "Patel-Schneider, Peter" <Peter.Patel-Schneider@nuance.com>, es-discuss list <es-discuss@mozilla.org>
Subject: Re: [Json] Fwd: two comments on JSON, ECMA-404, 1st edition / October 2013
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 22:53:00 -0000

On Dec 11, 2013, at 2:07 PM, Joe Hildebrand (jhildebr) wrote:

> On 12/11/13 1:54 PM, "Allen Wirfs-Brock" <allen@wirfs-brock.com> =
wrote:
>=20
>> So, 4627bis can specify that application/json documents an only =
contain
>> Unicode scalar value code points.
>=20
> Well, it says: "JSON text SHALL be encoded in UTF-8, UTF-16, or =
UTF-32".
> It's not legal to encode any code point between U+D800 and U+DFFF in =
UTF-8
> or UTF-32, and invalid UTF-16 to have them paired incorrectly.  So =
this
> restriction is implicit.
>=20
>> That means that a applicaiton/json JSON text is a subset of all =
possible
>> JSON texts defined by ECMA-404.  What wrong with that?
>=20
> Nothing, perhaps.  I do think it would be nice to give a little more
> guidance about serializing and parsing ECMA-404 to and from the
> transmission form.

Separation of concerns.   application/json is a transmission form but =
not the only possible one so it seems appropriate for it to specify its =
specific restrictions. Also, there are local uses of JSON that don't =
require serialization to a transmission form.

Note that this is not very different from the distinction between RFC =
4329 (Scripting Media Types) and ECMA-262.  (although 4329 is quite out =
of date WRT the corresponding language specifications)

Allen=

From allen@wirfs-brock.com  Wed Dec 11 15:15:24 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19371AE041 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 15:15:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 ze_De3IVtHj4 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 15:15:23 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1B21AE086 for <json@ietf.org>; Wed, 11 Dec 2013 15:15:22 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1Vqszs-000Nzr-PK; Wed, 11 Dec 2013 23:15:17 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18SoAq6QVU1b+ntfFShK4QgZlELRcB8R64=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-197-474616390
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <905fa99h0ub9bu39sj8ada6m4aa6t2actn@hive.bjoern.hoehrmann.de>
Date: Wed, 11 Dec 2013 15:15:09 -0800
Message-Id: <16D48B07-DE25-4E6F-9B39-30C41E28C4FA@wirfs-brock.com>
References: <83EEF8CC-B0BE-4F62-9ACF-73BC90CFEBA0@wirfs-brock.com> <20131207115542.GA4067@localhost> <CCCC4717-8A95-47DE-9F6B-70D971418164@tzi.org> <52A442CF.6060309@it.aoyama.ac.jp> <E19BDE18-DA46-4C00-AA6C-205C348326AD@tzi.org> <52A59337.4050609@it.aoyama.ac.jp> <2AA6AE6A-C76D-4B61-BFE1-0EBDFB715D6D@tzi.org> <8E4C7969-7868-4DE9-A9B0-C7FD484075B1@wirfs-brock.com> <serca9lle8m19n7ikdhf9ldlcoo8b9mpos@hive.bjoern.hoehrmann.de> <1E12FB6A-BD61-4E51-89E9-4398F943FF8F@wirfs-brock.com> <905fa99h0ub9bu39sj8ada6m4aa6t2actn@hive.bjoern.hoehrmann.de>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
X-Mailer: Apple Mail (2.1085)
Cc: "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, www-tag@w3.org, JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from W3C TAG
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 23:15:25 -0000

--Apple-Mail-197-474616390
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Dec 10, 2013, at 3:08 PM, Bjoern Hoehrmann wrote:
> ...
> If things had gone according to plan, it seems likely that Ecma would
> have requested the IANA registration for application/json jointly =
lists
> the IETF and Ecma International has holding Change Control over it, =
and
> it seems unlikely there would have been much disagreement about that.
>=20
> It is normal to award change control to other organisations, for
> instance, RFC 3023 gives change control for the XML media types to the
> W3C. I can look up examples for jointly held change control if that
> would help.

Speaking of media types.  I just noticed that RFC 4329 seems painfully =
out of date WRT application/ecmascript and application/javascript and =
the langauge specification that defines the payload. =20

Perhaps this is another area that needs coordination.

Allen=

--Apple-Mail-197-474616390
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Dec 10, 2013, at 3:08 PM, Bjoern Hoehrmann =
wrote:</div><blockquote type=3D"cite"><div><font =
class=3D"Apple-style-span" color=3D"#000000">...<br></font>If things had =
gone according to plan, it seems likely that Ecma would<br>have =
requested the IANA registration for application/json jointly =
lists<br>the IETF and Ecma International has holding Change Control over =
it, and<br>it seems unlikely there would have been much disagreement =
about that.<br><br>It is normal to award change control to other =
organisations, for<br>instance, RFC 3023 gives change control for the =
XML media types to the<br>W3C. I can look up examples for jointly held =
change control if that<br>would =
help.<br></div></blockquote></div><br><div>Speaking of media types. =
&nbsp;I just noticed that RFC 4329 seems painfully out of date WRT =
application/ecmascript and application/javascript and the langauge =
specification that defines the payload. =
&nbsp;</div><div><br></div><div>Perhaps this is another area that needs =
coordination.</div><div><br></div><div>Allen</div></body></html>=

--Apple-Mail-197-474616390--

From cabo@tzi.org  Wed Dec 11 15:16:12 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630571ADBD1 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 15:16:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 FGZZc4gTPEVv for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 15:16:11 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 10DEF1A1F72 for <json@ietf.org>; Wed, 11 Dec 2013 15:16:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBBNFwNt022268; Thu, 12 Dec 2013 00:15:58 +0100 (CET)
Received: from [192.168.217.105] (p5489295F.dip0.t-ipconnect.de [84.137.41.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DD26AF57; Thu, 12 Dec 2013 00:15:56 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <93B1A528-AA45-4166-BFD7-59DE897F8C17@vpnc.org>
Date: Thu, 12 Dec 2013 00:15:53 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <415EFECE-56C1-4090-B18D-4D30AE12CB02@tzi.org>
References: <52A8B847.7050606@gmail.com> <52A8BBF7.4090809@gmx.de> <52A8BD47.9040404@gmail.com> <CC3BF618-93C3-4851-A046-CDD8440AC8A2@tzi.org> <CECE00BB.30680%jhildebr@cisco.com> <93B1A528-AA45-4166-BFD7-59DE897F8C17@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1822)
Cc: Julian Reschke <julian.reschke@gmx.de>, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, Joe Hildebrand Hildebrand <jhildebr@cisco.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] surrogate code points in JSON text
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 23:16:12 -0000

On 11 Dec 2013, at 22:34, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> This

This thread has already talked about so many different things that I=92m =
not able to find the referent here.

Gr=FC=DFe, Carsten


From pfpschneider@gmail.com  Wed Dec 11 16:02:13 2013
Return-Path: <pfpschneider@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F361AE21A for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 16:02:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 LnG_9cbK91fk for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 16:02:11 -0800 (PST)
Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BC9E51AE1E6 for <json@ietf.org>; Wed, 11 Dec 2013 16:02:11 -0800 (PST)
Received: by mail-qa0-f46.google.com with SMTP id f11so5295181qae.19 for <json@ietf.org>; Wed, 11 Dec 2013 16:02:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=vTgNrjzZUd/GliQfyG1Q6s6PS1nqqSRH9tfK3DKHmdg=; b=UBZcF5/CBcVIht1tbYKlGQJeE3vN8+4/XuwNoxyB+AfY7oxY3jGH6o2uagcSLx3bRQ gyzof8so5nxduv6VfFAKnMgipfJgS6HEX0uHiPFBM8OidsBXbJGpnb5jlcbvo8u4nudC FXLs5kVOvT8Fsa3UOTNDggkmIN2ey0K+bKfvhswgmV+kHHyz1Bn9V6X7Xp0k8jVVWXgT QJh6uuS5iXa0V+qshpDlQqDistKNu2E39Zf3XxXfcEu9cINbEor3HbGwZqyLqZVbhgDt yCyEg0pwKtHLBFRkuxTOWr49j159SLjzIxo0ha+OQ7qYtpF+B9J74lOk3TArkfUQM72N +iAQ==
X-Received: by 10.224.7.10 with SMTP id b10mr7277108qab.12.1386806525899; Wed, 11 Dec 2013 16:02:05 -0800 (PST)
Received: from [192.168.95.125] ([199.4.160.88]) by mx.google.com with ESMTPSA id ki4sm57728960qeb.0.2013.12.11.16.02.03 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 16:02:05 -0800 (PST)
Message-ID: <52A8FCFA.6010003@gmail.com>
Date: Wed, 11 Dec 2013 16:02:02 -0800
From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>,  Joe Hildebrand Hildebrand <jhildebr@cisco.com>
References: <52A8B847.7050606@gmail.com> <52A8BBF7.4090809@gmx.de> <52A8BD47.9040404@gmail.com> <CC3BF618-93C3-4851-A046-CDD8440AC8A2@tzi.org> <CECE00BB.30680%jhildebr@cisco.com> <93B1A528-AA45-4166-BFD7-59DE897F8C17@vpnc.org>
In-Reply-To: <93B1A528-AA45-4166-BFD7-59DE897F8C17@vpnc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Julian Reschke <julian.reschke@gmx.de>, Carsten Bormann <cabo@tzi.org>, JSON WG <json@ietf.org>
Subject: Re: [Json] surrogate code points in JSON text
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 00:02:13 -0000

When reading RFC4627bis-09, one gets the following information:

The sequence %x22.DEAD.22 matches JSON-text.
A JSON parser must accept this sequence.
There is no JSON encoding scheme that can encode this sequence.

 From the discussion on this thread, and the discussion back in June
and July, which I just waded through, I take it that none of these three can
be changed.


peter


On 12/11/2013 01:34 PM, Paul Hoffman wrote:
> This was discussed at length earlier, and failed for lack of WG consensus. Different people strongly felt that their view of What We Are Talking About must be the only right one; the strength of those views clearly remain, given the threads from this past week.
>
> The current wording is the best that we could get consensus on.
>
> Seeing this flare up yet again here gives me a bit more compassion for TC39...
>
> --Paul Hoffman


From James.H.Manger@team.telstra.com  Wed Dec 11 17:07:39 2013
Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936D21ADFC0 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 17:07:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.202
X-Spam-Level: 
X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=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 I1C5E-ZoGftt for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 17:07:37 -0800 (PST)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 598A01AC3DA for <json@ietf.org>; Wed, 11 Dec 2013 17:07:37 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.93,875,1378821600"; d="scan'208";a="172322111"
Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 12 Dec 2013 12:07:31 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,7286"; a="181310121"
Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipccvi.tcif.telstra.com.au with ESMTP; 12 Dec 2013 12:07:31 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Thu, 12 Dec 2013 12:07:30 +1100
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Thu, 12 Dec 2013 12:07:29 +1100
Thread-Topic: [Json] object element order
Thread-Index: Ac72komsWzs7Zn58TgqBF1gSNcs8zQAOENzQ
Message-ID: <255B9BB34FB7D647A506DC292726F6E1153744DB3D@WSMSG3153V.srv.dir.telstra.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com> <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com> <C57917BE-51AE-40D0-80F9-5443E8D2E694@wirfs-brock.com> <255B9BB34FB7D647A506DC292726F6E115373AEB92@WSMSG3153V.srv.dir.telstra.com> <09E2A0C8-C2B6-4104-B208-F1FE5448DF44@wirfs-brock.com>
In-Reply-To: <09E2A0C8-C2B6-4104-B208-F1FE5448DF44@wirfs-brock.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] object element order
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 01:07:39 -0000

PiBZb3UgY2FuJ3QgcmVxdWlyZSB0aGF0IEVDTUFTY3JpcHQgb2JqZWN0cyBkbyBub3QgYWx3YXlz
IGhhdmUgYW4NCj4gZW51bWVyYXRpb24gb3JkZXIgb2YgdGhlaXIgcHJvcGVydGllcy4gIFRoZXkg
ZG8gYW5kIHlvdSBjYW4ndCBjaGFuZ2UNCj4gdGhhdC4gWW91IGFsc28gY2FuJ3QgZGVueSB0aGF0
IHRoZSBtZW1iZXJzIG9mIGEgSlNPTiBvYmplY3Qgb2NjdXIgaW4gYQ0KPiBzcGVjaWZpYyBvcmRl
ci4gIEF0IG1vc3QgeW91IGNhbiByZWNvbW1lbmQgdGhhdCBKU09OLWJhc2VkIHByb3RvY29scw0K
PiBub3QgZGVwZW5kIHVwb24gdGhhdCBvcmRlcmluZy4NCg0KSSBkb24ndCB3YW50IHRvIHByZXZl
bnQgRUNNQVNjcmlwdCBoYXZpbmcgYSBzcGVjaWZpYyBvYmplY3QgZWxlbWVudCBlbnVtZXJhdGlv
biBvcmRlci4NCkkgYWdyZWUgdGhhdCBlbGVtZW50cyBkbyBoYXZlIGFuIG9yZGVyIHdoZW4gd3Jp
dHRlbiBpbiBKU09OIHN5bnRheC4NCg0KPiBUaGlzIGEgYWxsIGFib3V0IGEgbGFuZ3VhZ2UgYmlu
ZGluZyBhbmQgaG93IGEgcGFydGljdWxhciBwYXJzZXINCj4gdHJhbnNsYXRlIEpTT04gdGV4dCBp
bnRvIHNvbWUgbGFuZ3VhZ2Ugc3BlY2lmaWMgZGF0YSBzdHJ1Y3R1cmUuDQo+IA0KPiBUaGUgZGVm
aW5pdGlvbiBvZiBhIHdlbGwtZm9ybWVkIEpTT04gdGV4dCBkb2Vzbid0IG5lZWQgdG8gc2F5IGFu
eXRoaW5nDQo+IGFib3V0IHRoaXMuDQoNCkl0IGRvZXMgbmVlZCB0byBzYXkgc29tZXRoaW5nIHRv
IGdldCBpbnRlcm9wZXJhYmlsaXR5Lg0KDQpJdCBzZWVtcyB0aGF0IEFsbGVuIHdvdWxkIGxpa2U6
DQoxLiBFQ01BLTQwNDogc3ludGF4IG9mIHt9IFtdICIiIC4uLjsgZWxlbWVudHMgaGF2ZSBhbiBv
cmRlcjsgbm8gdW5pcXVlIG5hbWUgY29uc3RyYWludC4NCjIuIEVDTUEtMjYyOiBpZ25vcmUgYWxs
IGJ1dCBsYXN0IHZhbHVlIGZvciBkdXBsaWNhdGUgbmFtZXM7IHNvbWUgb3RoZXIgb3JkZXJpbmcg
cnVsZXMuDQozLiBSRkM0NjI3YmlzOiBhcHBsaWNhdGlvbi9qc29uIGlzIFVURi04IGVuY29kaW5n
IG9mIGFueSBFQ01BLTQwNCB2YWx1ZS4NCg0KTXkgcHJvYmxlbSBpcyB0aGF0IGlmIHdlIGhhZCB0
aG9zZSAzIHNwZWNzLCBwZW9wbGUgZGVzaWduaW5nIG1lc3NhZ2VzIChidXQgbm90IHdyaXRpbmcg
RUNNQVNDcmlwdCBpbXBsZW1lbnRhdGlvbnMpIHdpbGw6IHJlYWQgRUNNQS00MDQ7IGFzc3VtZSB7
ImFyZyI6MiwgIm9wIjoiLyIsICJhcmciOjV9IGlzIHBlcmZlY3RseSBhY2NlcHRhYmxlOyBpbXBs
ZW1lbnQgYSBnZW5lcmF0b3IvcGFyc2VyIGluIHRoZWlyIGZhdm91cml0ZSBsYW5ndWFnZTsgcHVi
bGlzaCB0aGVpciBKU09OIHByb3RvY29sOyBhbmQgY2F1c2UgaW50ZXJvcCBncmllZiBhcyBzbyBt
YW55IG90aGVyIEpTT04gdG9vbHMgZmFpbCB3aXRoIHRoZXNlIEpTT04gbWVzc2FnZXMuIEtub3dp
bmcgYSBwcm90b2NvbCB1c2VzIEpTT04gd291bGQgbm8gbG9uZ2VyIGJlIG1lYW5pbmdmdWwsIHlv
dSB3b3VsZCBuZWVkIHRvIGFzayBpZiBpdCBpcyBKU09OLXdpdGgtb2JqZWN0cy1hcy1tYXBzIG9y
IEpTT04td2l0aC1vYmplY3RzLWFzLWxpc3Qtb2YtZWxlbWVudHMgdG8ga25vdyB3aGljaCB0b29s
cyB3aWxsIHdvcmsuDQoNClByZXN1bWFibHkgcGFydCBvZiB0aGUgcG9pbnQgb2YgKHRoZSBiZWF1
dGlmdWxseSBzaG9ydCkgRUNNQS00MDQgaXMgdGhhdCBhIGxvdCBvZiBwZW9wbGUgKGRlc2lnbmlu
ZyBtZXNzYWdlcykgZG9uJ3QgbmVlZCB0byByZWFkICh0aGUgZXh0cmVtZWx5IGRldGFpbGVkKSBF
Q01BLTI2Mi4gSWYgbWFueSB2YWxpZCBFQ01BLTQwNCBtZXNzYWdlcyBmYWlsIChzaWxlbnRseSkg
d2l0aCBFQ01BLTI2MidzIEpTT04ucGFyc2UoKSBmdW5jdGlvbiB0aGVuIHRoZSBzcGVjcyBoYXZl
IGZhaWxlZCBpbiBteSBvcGluaW9uLg0KDQpQZXJoYXBzIHRoZSBzaW1wbGUgYW5zd2VyIGlzIGZv
ciBFQ01BLTQwNCB0byBpbnRyb2R1Y2UgYSBuZXcgdGVybSwgc2F5ICJHZW5lcmFsaXplZEpTT04i
LiBUaGUgc3BlYyBjb3VsZCBzYXk6DQoNCiAgIkEgR2VuZXJhbGl6ZWRKU09OIHRleHQgY29uZm9y
bXMgdG8gdGhlIHN5bnRheDsgYW55IG51bWJlciBvZiBlbGVtZW50cyBpbiBhbiBvYmplY3QgY2Fu
IGhhdmUgdGhlIHNhbWUgbmFtZSwgYW5kIHRoZSBvcmRlciBvZiBlbGVtZW50cyBpcywgaW4gZ2Vu
ZXJhbCwgc2lnbmlmaWNhbnQuIEEgSlNPTiB0ZXh0IGFsc28gY29uZm9ybXMgdG8gdGhlIHN5bnRh
eCwgYnV0IGluIGNvbnRyYXN0IHRvIGEgR2VuZXJhbGl6ZWRKU09OIHRleHQsIG9ubHkgdGhlIGxh
c3QgZWxlbWVudCB3aXRoIGFueSBnaXZlbiBuYW1lIGluIGFuIG9iamVjdCBpcyBzaWduaWZpY2Fu
dCwgYW5kIG90aGVyIHRoYW4gdGhhdCB0aGUgb3JkZXJpbmcgb2YgZWxlbWVudHMgaXMgaW5zaWdu
aWZpY2FudC4iDQoNClRoYXQgbWFrZXMgaXMgY2xlYXIgdGhhdCBzZXBhcmF0ZSB0eXBlcy9jbGFz
c2VzL2NvZGUgaXMgbmVlZGVkIHRvIGhhbmRsZSBKU09OIGFuZCBHZW5lcmFsaXplZEpTT04uIElm
IGEgcHJvdG9jb2wgc2F5cyBpdCB1c2VzIEdlbmVyYWxpemVkSlNPTiBmb3IgaXQgbWVzc2FnZXMg
aXQgaXMgY2xlYXIgdGhhdCBFQ01BU2NyaXB0J3MgSlNPTi5wYXJzZSgpIGlzIG5vdCBhcHByb3By
aWF0ZS4NCg==

From allen@wirfs-brock.com  Wed Dec 11 18:01:49 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CDC1AE119 for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 18:01:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 8VSxEDDn-aAT for <json@ietfa.amsl.com>; Wed, 11 Dec 2013 18:01:48 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id D3B031AC3DA for <json@ietf.org>; Wed, 11 Dec 2013 18:01:47 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1Vqvav-000335-Eh; Thu, 12 Dec 2013 02:01:41 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19InvJ8nVhrKl45GcmwtIG5foz+Vg4eQ/M=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1153744DB3D@WSMSG3153V.srv.dir.telstra.com>
Date: Wed, 11 Dec 2013 18:01:35 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <E1D0BBBF-77AE-452C-B9E4-CAB3B878DC96@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com> <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com> <C57917BE-51AE-40D0-80F9-5443E8D2E694@wirfs-brock.com> <255B9BB34FB7D647A506DC292726F6E115373AEB92@WSMSG3153V.srv.dir.telstra.com> <09E2A0C8-C2B6-4104-B208-F1FE5448DF44@wirfs-brock.com> <255B9BB34FB7D647A506DC292 726F6E1153744DB3D@WSMSG3153V.srv.dir.telstra.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>
X-Mailer: Apple Mail (2.1085)
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] object element order
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 02:01:49 -0000

On Dec 11, 2013, at 5:07 PM, Manger, James wrote:

>> You can't require that ECMAScript objects do not always have an
>> enumeration order of their properties.  They do and you can't change
>> that. You also can't deny that the members of a JSON object occur in =
a
>> specific order.  At most you can recommend that JSON-based protocols
>> not depend upon that ordering.
>=20
> I don't want to prevent ECMAScript having a specific object element =
enumeration order.
> I agree that elements do have an order when written in JSON syntax.

And I'm pretty sure that you don't want to prevent a streaming parser =
from presenting object members in the order in which they appear in the =
jSON text.=20

>=20
>> This a all about a language binding and how a particular parser
>> translate JSON text into some language specific data structure.
>>=20
>> The definition of a well-formed JSON text doesn't need to say =
anything
>> about this.
>=20
> It does need to say something to get interoperability.
>=20
> It seems that Allen would like:
> 1. ECMA-404: syntax of {} [] "" ...; elements have an order; no unique =
name constraint.
yes
> 2. ECMA-262: ignore all but last value for duplicate names; some other =
ordering rules.
yes, but it is just one of may possible JSON language binding =
specifications.  There can even be (actually there already are) other =
JSON/JavaScript language bindings and parsers.

> 3. RFC4627bis: application/json is UTF-8 encoding of any ECMA-404 =
value.
Not necessarily any ECMA-404 value.   For interchange purposes it is =
acceptable to restrict the possible values.  For example, disallowing =
unpaired surrogates in JSON string values.

>=20
> My problem is that if we had those 3 specs, people designing messages =
(but not writing ECMASCript implementations) will: read ECMA-404; assume =
{"arg":2, "op":"/", "arg":5} is perfectly acceptable; implement a =
generator/parser in their favourite language; publish their JSON =
protocol; and cause interop grief as so many other JSON tools fail with =
these JSON messages. Knowing a protocol uses JSON would no longer be =
meaningful, you would need to ask if it is JSON-with-objects-as-maps or =
JSON-with-objects-as-list-of-elements to know which tools will work.
>=20
> Presumably part of the point of (the beautifully short) ECMA-404 is =
that a lot of people (designing messages) don't need to read (the =
extremely detailed) ECMA-262. If many valid ECMA-404 messages fail =
(silently) with ECMA-262's JSON.parse() function then the specs have =
failed in my opinion.

In general, to use JSON you have to understand the JSON syntax =
(ECMA-404), understand the requirements and limitations of the data =
schemas you plan on interchanging, understand the requirements and =
limitation (eg, character encodings) of a communications channel, and =
understand the a parser/generator API and probably details of a language =
binding.

It's only the first of these that has a single alternative.

>=20
> Perhaps the simple answer is for ECMA-404 to introduce a new term, say =
"GeneralizedJSON". The spec could say:
>=20
>  "A GeneralizedJSON text conforms to the syntax; any number of =
elements in an object can have the same name, and the order of elements =
is, in general, significant. A JSON text also conforms to the syntax, =
but in contrast to a GeneralizedJSON text, only the last element with =
any given name in an object is significant, and other than that the =
ordering of elements is insignificant."
too specific to ECMAScript.  Other language bindings may do different, =
but equally unusual things

>=20
> That makes is clear that separate types/classes/code is needed to =
handle JSON and GeneralizedJSON. If a protocol says it uses =
GeneralizedJSON for it messages it is clear that ECMAScript's =
JSON.parse() is not appropriate.

Note that this really isn't just about ECMAScript's JSON.parse. Every =
language specific parser/generator/language binding has its own =
idiosyncrasies.

A better way to may simply to add some informative notes to ECMA-404

(clause 4)
NOTE Some encodings of JSON texts only accept code points corresponding =
to Unicode Scalar Values

(clause 6)
NOTE Some JSON processors apply special meanings to the ordering of the =
members of a JSON object value and/or the occurrence of multiple object =
members with the same name. Application semantics based upon member =
ordering requirements or the use of duplicate member names should be =
avoid if maximal interoperability is desired.

Allen=

From julian.reschke@gmx.de  Thu Dec 12 00:14:19 2013
Return-Path: <julian.reschke@gmx.de>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9E71ADF96 for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 00:14:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 oybIzfhg2ccE for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 00:14:17 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 337381AE1C9 for <json@ietf.org>; Thu, 12 Dec 2013 00:14:17 -0800 (PST)
Received: from [192.168.2.117] ([93.217.81.245]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LrNoG-1VPZTa02OK-0136WW for <json@ietf.org>; Thu, 12 Dec 2013 09:14:10 +0100
Message-ID: <52A9704E.1080001@gmx.de>
Date: Thu, 12 Dec 2013 09:14:06 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Allen Wirfs-Brock <allen@wirfs-brock.com>,  "Manger, James" <James.H.Manger@team.telstra.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com> <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com> <C57917BE-51AE-40D0-80F9-5443E8D2E694@wirfs-brock.com> <255B9BB34FB7D647A506DC292726F6E115373AEB92@WSMSG3153V.srv.dir.telstra.com> <09E2A0C8-C2B6-4104-B208-F1FE5448DF44@wirfs-brock.com> <255B9BB34FB7D647A506DC292 726F6E1153744DB3D@WSMSG3153V.srv.dir.telstra.com> <E1D0BBBF-77AE-452C-B9E4-CAB3B878DC96@wirfs-brock.com>
In-Reply-To: <E1D0BBBF-77AE-452C-B9E4-CAB3B878DC96@wirfs-brock.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:cQ3WpggAEc3rZGiZqGNkzAQkQv7igXfbOy5TKzWlSNhQZOwEaWJ oqAHdWmarU+DAroHWPGyLbqGdAY9H9rPW4NEFAl/vWyYLbBqrrmLUV5G0yesfXiFRu0hsvV JC1ODpr6YrkepF+8Y2NhEKS+iaQwvog3fYtkjsKg4sHHXw7oy87WntWXefjn+kPR2Vtx+tR +pmHm9O49Ai7+ObU7n+Hw==
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] object element order
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 08:14:19 -0000

On 2013-12-12 03:01, Allen Wirfs-Brock wrote:
> ...
> (clause 6)
> NOTE Some JSON processors apply special meanings to the ordering of the members of a JSON object value and/or the occurrence of multiple object members with the same name. Application semantics based upon member ordering requirements or the use of duplicate member names should be avoid if maximal interoperability is desired.
> ...

For "maximum interoperability" this absolutely is a MUST, not a SHOULD, 
right?

Best regards, Julian

From cabo@tzi.org  Thu Dec 12 01:50:11 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA041AE21A for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 01:50:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 VdYcXm2V0p15 for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 01:50:10 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 055D11AE217 for <json@ietf.org>; Thu, 12 Dec 2013 01:50:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBC9nv96003399; Thu, 12 Dec 2013 10:49:57 +0100 (CET)
Received: from [192.168.217.105] (p54890E24.dip0.t-ipconnect.de [84.137.14.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 781E2155; Thu, 12 Dec 2013 10:49:56 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <E1D0BBBF-77AE-452C-B9E4-CAB3B878DC96@wirfs-brock.com>
Date: Thu, 12 Dec 2013 10:49:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A2CAE03E-1391-4591-A52F-68557CFE0C44@tzi.org>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CAHBU6itM4haCemNe-MzPFwHf659KWfqXA+yACLCyQFfPrw_w2A@mail.gmail.com> <CF7C2C14-996C-4AC4-BBCB-EF4FD46C123C@tzi.org> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com> <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com> <C57917BE-51AE-40D0-80F9-5443E8D2E694@wirfs-brock.com> <255B9BB34FB7D647A506DC292726F6E115373AEB92@WSMSG3153V.srv.dir.telstra.com> <09E2A0C8-C2B6-4104-B208-F1FE5448DF44@wirfs-brock.com> <255B9BB34FB7D647A 506DC292 726F6E1153744DB3D@WSMSG3153V.srv.dir.telstra.com> <E1D0BBBF-77AE-452C-B9E4-CAB3B878DC96@wirfs-brock.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
X-Mailer: Apple Mail (2.1822)
Cc: "es-discuss@mozilla.org list" <es-discuss@mozilla.org>, "Manger, James" <James.H.Manger@team.telstra.com>, JSON WG <json@ietf.org>
Subject: [Json] JSON as an interoperability specification (Re: object element order)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 09:50:11 -0000

On 12 Dec 2013, at 03:01, Allen Wirfs-Brock <allen@wirfs-brock.com> =
wrote:

> And I'm pretty sure that you don't want to prevent a streaming parser =
from presenting object members in the order in which they appear in the =
jSON text.=20

Of course not.  I=92d recommend adding all the whitespace and a bit for =
each character indicating whether it was escaped or not (don=92t laugh, =
there are JSON extensions that use this information).

I think what many people here are saying is a point about =
interoperability, not about what a specific system =93can=94 do.  If you =
want to benefit from the wide availability of JSON implementations, you =
*cannot* make the object member order (or whitespace or escaping) =
significant in your application.  The other side may not have a way to =
generate a specific member order (or form of whitespace or pattern of =
escaping).

Of course, consenting applications can *extend* JSON to make all these =
things significant (and an implementation way want to be prepared for =
these extensions by, say, preserving character escaping information).  =
However, saying that these applications are =93using JSON=94 to =
communicate is inaccurate.  They are using a JSON extension.  It may not =
as obviously be an extension as, say, YAML is (it is still using the =
same grammar), but the fact that some aspects of the serial =
representation have been assigned a meaning that don=92t have one in =
JSON still makes them using an extension.

The fact that a widely used set of JSON implementations allows easy =
access to a JSON extension does not make that particular extension part =
of JSON any more than the convention of escaping the first character in =
a string to make it meta is a part of JSON.  (Within a monoculture, it =
is always tempting to consider the features of that monoculture to be =
universal.  Don=92t yield to that.)

Documenting the syntax of JSON without the attendant semantics is an =
exercise in leading developers on a path where they suddenly think they =
have to preserve all the fluff in the syntax just in case a JSON =
extension might use it.  That=92s not what JSON is about; JSON is about =
enabling parsers to aggressively eliminate the fluff, and enabling =
encoders to generate the fluff in a way that is convenient to them on =
their specific platform.

Gr=FC=DFe, Carsten


From cabo@tzi.org  Thu Dec 12 03:19:30 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9AB1A1F19 for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 03:19:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 sNl25UFBlts0 for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 03:19:29 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEF01AE0D5 for <json@ietf.org>; Thu, 12 Dec 2013 03:19:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBCBJIki004632 for <json@ietf.org>; Thu, 12 Dec 2013 12:19:18 +0100 (CET)
Received: from [192.168.217.105] (p54890E24.dip0.t-ipconnect.de [84.137.14.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AF528259; Thu, 12 Dec 2013 12:19:17 +0100 (CET)
From: Carsten Bormann <cabo@tzi.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Date: Thu, 12 Dec 2013 12:19:15 +0100
To: JSON WG <json@ietf.org>
Message-Id: <70DE471B-0B77-4A59-B85E-12463A072E64@tzi.org>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
X-Mailer: Apple Mail (2.1822)
Subject: [Json] Effects of changing JSON on existing specifications
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 11:19:30 -0000

I recently reviewed draft-ietf-appsawg-json-merge-patch and I stumbled
over some text that didn't make sense until I realized that it was
assuming RFC 4627 JSON.  That text can easily be fixed (and the
missing specification text generated in kind).  But it made me wonder
whether we have a little piece of "unscheduled work" here.

Now that we are changing JSON, we need to check for the impact of this
change on other IETF specs.

The effect of the changes can be:

-- spec breaks horribly, no repair (rare, I hope)
-- spec breaks, but there is an obvious fix
   -> can be documented in an informal way up to a revision
-- spec breaks, and there is at more than one conceivable fix
   -> it needs to be documented which one should be chosen
-- spec is fine.

I'm not trying to be Phil Nesser here (some people in this community
have done the Y2K search work that culminated in RFC2626 and we need
to do that, too =97 on a much smaller scale and without generating an
RFC, I hope).

So a quick check of the RFCs yields this list of grep hits (annotated
with my hypotheses, if I have any):

Grep hits:

-- RFC 4627.  Taken care of :-)
** RFC 5552, defines a way to put JSON in a URI.  Needs check.
-- RFC 6202, uses JSONP.
-- RFC 6208, several CDMI media types (specified externally) use JSON.
++ RFC 6231, talks about "complex ECMAScript value" only, probably OK
-- RFC 6392, just mentions that JSON will be used.
++ RFC 6415, defines JRD as a single JSON object.  Fine.
-- RFC 6573, mentions Collection+JSON.
++ RFC 6749, seems to be a single JSON object (called a JSON structure =
here).  Fine.
-- RFC 6819, mentions JWT.  Fine.
-- RFC 6839, defines +json (and thinks UTF-8 JSON is 8bit compatible, =
oops).
** RFC 6901, defines JSON pointer.  Any fix needed is probably obvious.
** RFC 6902, defines JSON patch.  Any fix needed is probably obvious.
++ RFC 6962, defines log messages as JSON objects.  Should be fine.
-- RFC 7009, mentions JSONP.
++ RFC 7033, defines JRD as a JSON object.  Fine.
++ RFC 7049, defines a mapping from and to JSON.  Seems fine.
-- RFC 7069, mentions JSON for CDMI.
++ RFC 7071, defines a reputon as a JSON object.  Should be fine.
-- RFC 7072, mentions RFC 7071.

I haven't checked the RFC editor queue or any other I-Ds.

It would be best it the authors of these specs did a quick check.
This needs to be coordinated and the results collected in some form.

Gr=FC=DFe, Carsten


From cowan@ccil.org  Thu Dec 12 07:18:00 2013
Return-Path: <cowan@ccil.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3058F1ADF47 for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 07:18:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 3uN-2C56FiXE for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 07:17:56 -0800 (PST)
Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 876001A1F56 for <json@ietf.org>; Thu, 12 Dec 2013 07:17:56 -0800 (PST)
Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from <cowan@ccil.org>) id 1Vr814-0002Of-3H; Thu, 12 Dec 2013 10:17:30 -0500
Date: Thu, 12 Dec 2013 10:17:30 -0500
From: John Cowan <cowan@mercury.ccil.org>
To: Carsten Bormann <cabo@tzi.org>
Message-ID: <20131212151730.GE363@mercury.ccil.org>
References: <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com> <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com> <C57917BE-51AE-40D0-80F9-5443E8D2E694@wirfs-brock.com> <255B9BB34FB7D647A506DC292726F6E115373AEB92@WSMSG3153V.srv.dir.telstra.com> <09E2A0C8-C2B6-4104-B208-F1FE5448DF44@wirfs-brock.com> <E1D0BBBF-77AE-452C-B9E4-CAB3B878DC96@wirfs-brock.com> <A2CAE03E-1391-4591-A52F-68557CFE0C44@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <A2CAE03E-1391-4591-A52F-68557CFE0C44@tzi.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <cowan@ccil.org>
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, JSON WG <json@ietf.org>, "Manger, James" <James.H.Manger@team.telstra.com>, "es-discuss@mozilla.org list" <es-discuss@mozilla.org>
Subject: Re: [Json] JSON as an interoperability specification (Re: object element order)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 15:18:00 -0000

Carsten Bormann scripsit:

> (Within a monoculture, it is always tempting to consider the features
> of that monoculture to be universal.  Don’t yield to that.)

That kind of ignorance is forgivable and resolvable.  It is the absolute
indifference to other cultures, and the conviction that the way they
see and do things does not matter, that is truly toxic.

> Documenting the syntax of JSON without the attendant semantics is an
> exercise in leading developers on a path where they suddenly think
> they have to preserve all the fluff in the syntax just in case a
> JSON extension might use it.  

+1

-- 
John Cowan    cowan@ccil.org    http://ccil.org/~cowan
The whole of Gaul is quartered into three halves.
        --Julius Caesar

From allen@wirfs-brock.com  Thu Dec 12 08:22:55 2013
Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B311AE013 for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 08:22:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 iwMY_1IJXKmX for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 08:22:53 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3184E1ADFB7 for <json@ietf.org>; Thu, 12 Dec 2013 08:22:52 -0800 (PST)
Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.26]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1Vr92C-0000Hn-GN; Thu, 12 Dec 2013 16:22:44 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 69.64.236.244
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19k1beE1I3e2Ohay3B//zZxIPlkvmxWCjk=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <52A9704E.1080001@gmx.de>
Date: Thu, 12 Dec 2013 08:22:36 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <1E1F2032-868B-437C-82C4-40BE24C08D61@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com> <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com> <C57917BE-51AE-40D0-80F9-5443E8D2E694@wirfs-brock.com> <255B9BB34FB7D647A506DC292726F6E115373AEB92@WSMSG3153V.srv.dir.telstra.com> <09E2A0C8-C2B6-4104-B208-F1FE5448DF44@wirfs-brock.com> <255B9BB34FB7D647A506DC292 726F6E1153744DB3D@WSMSG3153V.srv.dir.telstra.com> <E1D0BBBF-77AE-452C-B9E4-CAB3B878DC96@wirfs-brock.com> <52A9704E. 1080001@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1085)
Cc: "Manger, James" <James.H.Manger@team.telstra.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] object element order
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 16:22:55 -0000

On Dec 12, 2013, at 12:14 AM, Julian Reschke wrote:

> On 2013-12-12 03:01, Allen Wirfs-Brock wrote:
>> ...
>> (clause 6)
>> NOTE Some JSON processors apply special meanings to the ordering of =
the members of a JSON object value and/or the occurrence of multiple =
object members with the same name. Application semantics based upon =
member ordering requirements or the use of duplicate member names should =
be avoided if maximal interoperability is desired.
>> ...
>=20
> For "maximum interoperability" this absolutely is a MUST, not a =
SHOULD, right?
>=20

Simply as a mater of style, within a TC39 spec. we wouldn't normative =
verb forms in an informative note.  A different restatement of the last =
sentence is:

Application semantics that assign meaning to member ordering or the use =
of duplication member names are less interoperable.

Allen


From nico@cryptonector.com  Thu Dec 12 08:29:43 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC2C1AE014 for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 08:29:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 JxtNU8njEAdH for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 08:29:42 -0800 (PST)
Received: from homiemail-a85.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6161ADDA0 for <json@ietf.org>; Thu, 12 Dec 2013 08:29:42 -0800 (PST)
Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id AF588BC033 for <json@ietf.org>; Thu, 12 Dec 2013 08:29:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=u1Ct+D1GkytnBquYDdeP 5KLrD6o=; b=YdhAHyAqvpJFPd430/aF4EuAeXD1aIN1MRBUXZvdHGwrErOIlgC/ aMfx/D/c5qZ11rpY/4tB8aBUsAWw4ITKFu6uGMA0CVi6b3RuMMkO3JAS2EMb20Bk 2nYKSyQrYBtfw0JPLINi7gB4dxGBGpZZMusP70cpy6Ir+rZ85hMgnAg=
Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 6072BBC040 for <json@ietf.org>; Thu, 12 Dec 2013 08:29:36 -0800 (PST)
Received: by mail-wg0-f46.google.com with SMTP id m15so679558wgh.25 for <json@ietf.org>; Thu, 12 Dec 2013 08:29:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PrX2pWmwJwO4kbXHePqjH2nuspb0swbaAnSQJt7ECJA=; b=eHdVW9tSMlTieJtDcrvRsu2egfUnnStprkdCFKqnRJZwlJS0azxE71pw+582d4Pl3G ABLzz0ddoXC9kXCf8N+V3cEHbcBN+eaSFWCThY99rdyv1sMxI4h/YXX9L99OeWa/ZY8F N96Dtb5baks2wx7hyOWQb5Ihi+98n7/LhUhcMK3Ydg8SXJyY5WDllsd4OnJHYRDuhcUC lbMQnd+4zTpSSYCtVnAc4wRSBgrtqHzgjgXsPHYMH0sC11zA+vqWDibV/Ox4gNpCk2ip ppC3QMV41naEHlznbA/bTo6M2N1lv02yoG9QPZNZ0xMmjV1AF3AZH1PNjg8BostjR/Kc ZvbA==
MIME-Version: 1.0
X-Received: by 10.194.171.34 with SMTP id ar2mr634918wjc.81.1386865774778; Thu, 12 Dec 2013 08:29:34 -0800 (PST)
Received: by 10.217.10.6 with HTTP; Thu, 12 Dec 2013 08:29:34 -0800 (PST)
In-Reply-To: <1E1F2032-868B-437C-82C4-40BE24C08D61@wirfs-brock.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com> <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com> <C57917BE-51AE-40D0-80F9-5443E8D2E694@wirfs-brock.com> <255B9BB34FB7D647A506DC292726F6E115373AEB92@WSMSG3153V.srv.dir.telstra.com> <09E2A0C8-C2B6-4104-B208-F1FE5448DF44@wirfs-brock.com> <E1D0BBBF-77AE-452C-B9E4-CAB3B878DC96@wirfs-brock.com> <52A9704E.1080001@gmx.de> <1E1F2032-868B-437C-82C4-40BE24C08D61@wirfs-brock.com>
Date: Thu, 12 Dec 2013 10:29:34 -0600
Message-ID: <CAK3OfOhLg5_abLQDErOP9y9vXXXyst9ekJ4Ds8urDMMb9OA7Dw@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Content-Type: text/plain; charset=UTF-8
Cc: Julian Reschke <julian.reschke@gmx.de>, "Manger, James" <James.H.Manger@team.telstra.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] object element order
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 16:29:43 -0000

On Thu, Dec 12, 2013 at 10:22 AM, Allen Wirfs-Brock
<allen@wirfs-brock.com> wrote:
> On Dec 12, 2013, at 12:14 AM, Julian Reschke wrote:
>> For "maximum interoperability" this absolutely is a MUST, not a SHOULD, right?
>>
>
> Simply as a mater of style, within a TC39 spec. we wouldn't normative verb forms in an informative note.  A different restatement of the last sentence is:

The normative part of JSON we have consensus for has no requirements
language as it's just syntax, and the ABNF suffices for the purpose of
normative language.  The interoperability recommendations are not
really normative, but they are recommendations, and "SHOULD" is a
recommendation.  We should not use MUST/REQUIRED for any of it (sad
though that makes me).

> Application semantics that assign meaning to member ordering or the use of duplication member names are less interoperable.

We know what an interoperable least common denominator looks like.  We
should document it rather than hint at it -- leaving the reader to
read whatever semantics they'd like into the syntax hasn't worked out
too well, so let's not repeat that.

Perhaps we have two interoperable least common denominators (where the
difference is about object name order preservation).  If so we should
document them both.

Nico
--

From tbray@textuality.com  Thu Dec 12 09:19:17 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906D31AE368 for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 09:19:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 DW6ipTAf6XXa for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 09:19:14 -0800 (PST)
Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id 08F4A1AE059 for <json@ietf.org>; Thu, 12 Dec 2013 09:19:13 -0800 (PST)
Received: by mail-ve0-f173.google.com with SMTP id oz11so550619veb.32 for <json@ietf.org>; Thu, 12 Dec 2013 09:19:07 -0800 (PST)
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:content-type; bh=SkJp0cl8pNVNom9O+sq5uyjYCuAFAVAw2B5X25DFZ0k=; b=kfZA+ukAJc36aNrkNyl61I/t2drPYEZ+0yhTzpeO40bsBGtnM4VAWJrsrbi73Gq4hm +M2C+EFfu9JIF6j+iJdEhGzk9UPfYDsnO+DxyA8gmsfOO0fFgidI9Yb3rbXRuljL+9NK 5YGA6fyKLAzMHAEMbUCcaIdSG9gEkISgdsLcf6T3NQ+/Vy1rnIx5AmLLiYYiOal+WL98 HAVuMvcPjKlnauRkakqeYPBFU+PxyPyeb9a233QeJFilo/5egZoYnT37Oa0k03s/9Y/+ f7gZrbnmsUvRLwZpfVqfz+woR/kr/yn4Xv1drMwy/FZRkinuzVHXzUjNddjktkGpHgTO 1V4A==
X-Gm-Message-State: ALoCoQljs/qn/VRxs4zCIOBKJhKgyXXfZkKXptjC174zP5cSicl23w8e93Du9pN8DdhyM6h47Chd
MIME-Version: 1.0
X-Received: by 10.220.168.65 with SMTP id t1mr78299vcy.76.1386868747823; Thu, 12 Dec 2013 09:19:07 -0800 (PST)
Received: by 10.220.198.199 with HTTP; Thu, 12 Dec 2013 09:19:07 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <CAK3OfOhLg5_abLQDErOP9y9vXXXyst9ekJ4Ds8urDMMb9OA7Dw@mail.gmail.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com> <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com> <C57917BE-51AE-40D0-80F9-5443E8D2E694@wirfs-brock.com> <255B9BB34FB7D647A506DC292726F6E115373AEB92@WSMSG3153V.srv.dir.telstra.com> <09E2A0C8-C2B6-4104-B208-F1FE5448DF44@wirfs-brock.com> <E1D0BBBF-77AE-452C-B9E4-CAB3B878DC96@wirfs-brock.com> <52A9704E.1080001@gmx.de> <1E1F2032-868B-437C-82C4-40BE24C08D61@wirfs-brock.com> <CAK3OfOhLg5_abLQDErOP9y9vXXXyst9ekJ4Ds8urDMMb9OA7Dw@mail.gmail.com>
Date: Thu, 12 Dec 2013 09:19:07 -0800
Message-ID: <CAHBU6ivQikEs=HneNa-B=XoacZZiSNzirvm3SANnEE1ZgpFjqw@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary=001a11c189fe10817204ed598b2b
Cc: Julian Reschke <julian.reschke@gmx.de>, Allen Wirfs-Brock <allen@wirfs-brock.com>, "Manger, James" <James.H.Manger@team.telstra.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] object element order
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 17:19:17 -0000

--001a11c189fe10817204ed598b2b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

4627 says =E2=80=9CAn object is an unordered collection of zero or more nam=
e/value
pairs=E2=80=9D, which seems crystal-clear to me. I don=E2=80=99t think this=
 needs to be
either weakened or repeated.


On Thu, Dec 12, 2013 at 8:29 AM, Nico Williams <nico@cryptonector.com>wrote=
:

> On Thu, Dec 12, 2013 at 10:22 AM, Allen Wirfs-Brock
> <allen@wirfs-brock.com> wrote:
> > On Dec 12, 2013, at 12:14 AM, Julian Reschke wrote:
> >> For "maximum interoperability" this absolutely is a MUST, not a SHOULD=
,
> right?
> >>
> >
> > Simply as a mater of style, within a TC39 spec. we wouldn't normative
> verb forms in an informative note.  A different restatement of the last
> sentence is:
>
> The normative part of JSON we have consensus for has no requirements
> language as it's just syntax, and the ABNF suffices for the purpose of
> normative language.  The interoperability recommendations are not
> really normative, but they are recommendations, and "SHOULD" is a
> recommendation.  We should not use MUST/REQUIRED for any of it (sad
> though that makes me).
>
> > Application semantics that assign meaning to member ordering or the use
> of duplication member names are less interoperable.
>
> We know what an interoperable least common denominator looks like.  We
> should document it rather than hint at it -- leaving the reader to
> read whatever semantics they'd like into the syntax hasn't worked out
> too well, so let's not repeat that.
>
> Perhaps we have two interoperable least common denominators (where the
> difference is about object name order preservation).  If so we should
> document them both.
>
> Nico
> --
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>

--001a11c189fe10817204ed598b2b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">4627 says =E2=80=9CAn object is an unordered collection of=
 zero or more name/value pairs=E2=80=9D, which seems crystal-clear to me. I=
 don=E2=80=99t think this needs to be either weakened or repeated.</div><di=
v class=3D"gmail_extra"><br>
<br><div class=3D"gmail_quote">On Thu, Dec 12, 2013 at 8:29 AM, Nico Willia=
ms <span dir=3D"ltr">&lt;<a href=3D"mailto:nico@cryptonector.com" target=3D=
"_blank">nico@cryptonector.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div class=3D"im">On Thu, Dec 12, 2013 at 10:22 AM, Allen Wirfs-Brock<br>
&lt;<a href=3D"mailto:allen@wirfs-brock.com">allen@wirfs-brock.com</a>&gt; =
wrote:<br>
&gt; On Dec 12, 2013, at 12:14 AM, Julian Reschke wrote:<br>
</div><div class=3D"im">&gt;&gt; For &quot;maximum interoperability&quot; t=
his absolutely is a MUST, not a SHOULD, right?<br>
&gt;&gt;<br>
&gt;<br>
&gt; Simply as a mater of style, within a TC39 spec. we wouldn&#39;t normat=
ive verb forms in an informative note. =C2=A0A different restatement of the=
 last sentence is:<br>
<br>
</div>The normative part of JSON we have consensus for has no requirements<=
br>
language as it&#39;s just syntax, and the ABNF suffices for the purpose of<=
br>
normative language. =C2=A0The interoperability recommendations are not<br>
really normative, but they are recommendations, and &quot;SHOULD&quot; is a=
<br>
recommendation. =C2=A0We should not use MUST/REQUIRED for any of it (sad<br=
>
though that makes me).<br>
<div class=3D"im"><br>
&gt; Application semantics that assign meaning to member ordering or the us=
e of duplication member names are less interoperable.<br>
<br>
</div>We know what an interoperable least common denominator looks like. =
=C2=A0We<br>
should document it rather than hint at it -- leaving the reader to<br>
read whatever semantics they&#39;d like into the syntax hasn&#39;t worked o=
ut<br>
too well, so let&#39;s not repeat that.<br>
<br>
Perhaps we have two interoperable least common denominators (where the<br>
difference is about object name order preservation). =C2=A0If so we should<=
br>
document them both.<br>
<br>
Nico<br>
--<br>
<div class=3D"HOEnZb"><div class=3D"h5">___________________________________=
____________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
</div></div></blockquote></div><br></div>

--001a11c189fe10817204ed598b2b--

From stefan@drees.name  Thu Dec 12 09:27:01 2013
Return-Path: <stefan@drees.name>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011A01ADEA7 for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 09:27:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 xianNGwzsE_c for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 09:26:59 -0800 (PST)
Received: from mout.web.de (mout.web.de [212.227.15.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8731ADE84 for <json@ietf.org>; Thu, 12 Dec 2013 09:26:59 -0800 (PST)
Received: from newyork.local.box ([93.197.208.250]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0LuqfJ-1VQFGX0Jhh-01023G for <json@ietf.org>; Thu, 12 Dec 2013 18:26:52 +0100
Message-ID: <52A9F1D9.4080106@drees.name>
Date: Thu, 12 Dec 2013 18:26:49 +0100
From: Stefan Drees <stefan@drees.name>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Tim Bray <tbray@textuality.com>,  Nico Williams <nico@cryptonector.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com> <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com> <C57917BE-51AE-40D0-80F9-5443E8D2E694@wirfs-brock.com> <255B9BB34FB7D647A506DC292726F6E115373AEB92@WSMSG3153V.srv.dir.telstra.com> <09E2A0C8-C2B6-4104-B208-F1FE5448DF44@wirfs-brock.com> <E1D0BBBF-77AE-452C-B9E4-CAB3B878DC96@wirfs-brock.com> <52A9704E.1080001@gmx.de> <1E1F2032-868B-437C-82C4-40BE24C08D61@wirfs-brock.com> <CAK3OfOhLg5_abLQDErOP9y9vXXXyst9ekJ4Ds8urDMMb9OA7Dw@mail.gmail.com> <CAHBU6ivQikEs=HneNa-B=XoacZZiSNzirvm3SANnEE1ZgpFjqw@mail.gmail.com>
In-Reply-To: <CAHBU6ivQikEs=HneNa-B=XoacZZiSNzirvm3SANnEE1ZgpFjqw@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:ngqDrI3S4CxDRAYONnBjCcLjFeAOuwF1XjoKdT0gA++pNp2cif0 MoqQp97RqXMwun8ZmaUeMZxs0t7F9nvs4RPfNlI0HNVKXsTpZH4zovnmk32NOsz1GFt9vCN QjH/WemV6POPBUj2KiV9XBy9gpZjp5BVSuCPXBqcpWOPAXFe9co7jl/ZNDavAaoLv9H3cVq T4GT8HLxVSD1q0W69lCBg==
Cc: Julian Reschke <julian.reschke@gmx.de>, Allen Wirfs-Brock <allen@wirfs-brock.com>, "Manger, James" <James.H.Manger@team.telstra.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] object element order
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: stefan@drees.name
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 17:27:01 -0000

On 2013-12-12 18:19 +01:00, Tim Bray wrote:
> 4627 says “An object is an unordered collection of zero or more
> name/value pairs”, which seems crystal-clear to me. I don’t think this
> needs to be either weakened or repeated.

+1 and yes please neither weaken nor repeat.



> On Thu, Dec 12, 2013 at 8:29 AM, Nico Williams <nico@cryptonector.com
> <mailto:nico@cryptonector.com>> wrote:
>
>     On Thu, Dec 12, 2013 at 10:22 AM, Allen Wirfs-Brock
>     <allen@wirfs-brock.com <mailto:allen@wirfs-brock.com>> wrote:
>      > On Dec 12, 2013, at 12:14 AM, Julian Reschke wrote:
>      >> For "maximum interoperability" this absolutely is a MUST, not a
>     SHOULD, right?
>      >>
>      >
>      > Simply as a mater of style, within a TC39 spec. we wouldn't
>     normative verb forms in an informative note.  A different
>     restatement of the last sentence is:
>
>     The normative part of JSON we have consensus for has no requirements
>     language as it's just syntax, and the ABNF suffices for the purpose of
>     normative language.  The interoperability recommendations are not
>     really normative, but they are recommendations, and "SHOULD" is a
>     recommendation.  We should not use MUST/REQUIRED for any of it (sad
>     though that makes me).
>
>      > Application semantics that assign meaning to member ordering or
>     the use of duplication member names are less interoperable.
>
>     We know what an interoperable least common denominator looks like.  We
>     should document it rather than hint at it -- leaving the reader to
>     read whatever semantics they'd like into the syntax hasn't worked out
>     too well, so let's not repeat that.
>
>     Perhaps we have two interoperable least common denominators (where the
>     difference is about object name order preservation).  If so we should
>     document them both.
>
>     Nico
>     --
>     _______________________________________________
>     json mailing list
>     json@ietf.org <mailto:json@ietf.org>
>     https://www.ietf.org/mailman/listinfo/json
>
>
>
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>


From pfpschneider@gmail.com  Thu Dec 12 09:44:38 2013
Return-Path: <pfpschneider@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3EAF1AE02C for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 09:44:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 dw0gpFavWRoD for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 09:44:37 -0800 (PST)
Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 446B91ADFD4 for <json@ietf.org>; Thu, 12 Dec 2013 09:44:37 -0800 (PST)
Received: by mail-qc0-f174.google.com with SMTP id n7so572748qcx.19 for <json@ietf.org>; Thu, 12 Dec 2013 09:44:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=z92R+MC+S41ylhfDB5e/l3c+RnsdcwKFIFBNldplg8s=; b=r4rTZCCgbpptkgEkfxcshYtjSis3obmJciMRSeOMTKnzE26i8t05jcHSSwFvRLPazv 2ZqE3eGUGdLWQfICISUWXh2wP7DtfbvjChKb3BotMYI/RKHlxem97hExrZ7DxafTJYAw d3xwI5ifwmxW2ZLwm9AVB2KJH8q3M/EM8rpgJs4O2FNSCnj1anFu05wEvzMv68LLjRvm B0iX6GbOfeB3SbWdbnKbATxugKJMIsG5z51BHO8spQcEHnXd2PuDfYOK9q9Wx+kr6gUg p+pJusj26e0OF0wsZ+stPfDuQXyVL2cBWvBDDCFrIWJNfgydPDpuxiZGfi8bRG+7wf9f RmlA==
X-Received: by 10.49.12.102 with SMTP id x6mr15661507qeb.5.1386870270120; Thu, 12 Dec 2013 09:44:30 -0800 (PST)
Received: from [192.168.95.125] ([199.4.160.88]) by mx.google.com with ESMTPSA id a5sm46271230qae.2.2013.12.12.09.44.27 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Dec 2013 09:44:29 -0800 (PST)
Message-ID: <52A9F5F9.1000704@gmail.com>
Date: Thu, 12 Dec 2013 09:44:25 -0800
From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: stefan@drees.name, Tim Bray <tbray@textuality.com>,  Nico Williams <nico@cryptonector.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com> <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com> <C57917BE-51AE-40D0-80F9-5443E8D2E694@wirfs-brock.com> <255B9BB34FB7D647A506DC292726F6E115373AEB92@WSMSG3153V.srv.dir.telstra.com> <09E2A0C8-C2B6-4104-B208-F1FE5448DF44@wirfs-brock.com> <E1D0BBBF-77AE-452C-B9E4-CAB3B878DC96@wirfs-brock.com> <52A9704E.1080001@gmx.de> <1E1F2032-868B-437C-82C4-40BE24C08D61@wirfs-brock.com> <CAK3OfOhLg5_abLQDErOP9y9vXXXyst9ekJ4Ds8urDMMb9OA7Dw@mail.gmail.com> <CAHBU6ivQikEs=HneNa-B=XoacZZiSNzirvm3SANnEE1ZgpFjqw@mail.gmail.com> <52A9F1D9.4080106@drees.name>
In-Reply-To: <52A9F1D9.4080106@drees.name>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Julian Reschke <julian.reschke@gmx.de>, Allen Wirfs-Brock <allen@wirfs-brock.com>, "Manger, James" <James.H.Manger@team.telstra.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] object element order
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 17:44:39 -0000

If only the statement was true, I would be so much happier.

peter

On 12/12/2013 09:26 AM, Stefan Drees wrote:
> On 2013-12-12 18:19 +01:00, Tim Bray wrote:
>> 4627 says “An object is an unordered collection of zero or more
>> name/value pairs”, which seems crystal-clear to me. I don’t think this
>> needs to be either weakened or repeated.
>
> +1 and yes please neither weaken nor repeat.
>
>
>


From mmorley@mpcm.com  Thu Dec 12 10:06:06 2013
Return-Path: <mmorley@mpcm.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606001ADDCA for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 10:06:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 UgnWieTRlu-d for <json@ietfa.amsl.com>; Thu, 12 Dec 2013 10:06:03 -0800 (PST)
Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id 84DC31AE3A1 for <json@ietf.org>; Thu, 12 Dec 2013 10:06:03 -0800 (PST)
Received: by mail-la0-f43.google.com with SMTP id n7so607495lam.30 for <json@ietf.org>; Thu, 12 Dec 2013 10:05:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rzFH0xIENu9Tah/3MeB9oz0mpBajY2HFfe83bntGE7E=; b=I5hcq91f7qnCf0oZLctaUV5oDmRoo9ud3ON41ahE733ysGg8b7OjKOV6Ukt2dEPm6v ClgeAtmWA6CbLBL39ONkpoq1vFBRY2eCYbsAMM1uVcp+JzQj5beClMgWY+1xc7zDWPM6 0ikiAMzZd1yP/e3cHsOo+GQOztQDR8Nq8wK78Xojvi6qnZ6R5k/YhvNPABS1ejV6d4T4 iAGYhIr2PymPL1xVPH2208ciybAjsUEUlWoyMdoBEvU1WWr7J7TflFoBbJNBpHj9GiTV i+euJiGv3e06+wMWbQYPX/18zkaonVNfjwWWOdgiBTRqIZQ8G3EiFhrTq5J6A9YN0lhM ZBiQ==
X-Gm-Message-State: ALoCoQlEbOxeDzrbMQeW5axwtBNv0/O6lVEeZ3djVhwjC0A9q+hFsU7vnLgYGMusDMBNg61uSfgD
MIME-Version: 1.0
X-Received: by 10.152.21.3 with SMTP id r3mr4531390lae.15.1386871556802; Thu, 12 Dec 2013 10:05:56 -0800 (PST)
Sender: mmorley@mpcm.com
Received: by 10.114.2.239 with HTTP; Thu, 12 Dec 2013 10:05:56 -0800 (PST)
In-Reply-To: <CAHBU6ivQikEs=HneNa-B=XoacZZiSNzirvm3SANnEE1ZgpFjqw@mail.gmail.com>
References: <799C8AFA-53C3-4698-A14A-96CB79981DE5@cisco.com> <25E6CD28-632C-4F44-9C7D-35AA3537DFA8@wirfs-brock.com> <CANz3_EbQrfoCTgFWD89VSX2CcC03-n0uch_z8FiJLWsDiwkqtg@mail.gmail.com> <48FA08CB-BF27-46D6-B730-19E168F61B41@tzi.org> <CANz3_EZAbwuUaYVvgpmQHpgTYehcEC=_KyX+UwGo62A+pvb5+Q@mail.gmail.com> <3A00115D-7D5D-4EE8-B842-1198F921CEDD@nic.cz> <A5663677-512D-43E1-8AD5-751CF88C6C98@tzi.org> <CAHBU6ivh67D0+GpoQh2-2dneAarYGzUd50j6Km3_xLSRvJdCBw@mail.gmail.com> <CANz3_EZ1VGzVAnBa03naoy_gT-e-MMr70hJZPN2GCJUBKieZCQ@mail.gmail.com> <CAChr6SxT-Cs4T1gbwxwJCThnrCiNbaZ6=Y660Vc3S8bScM9=iA@mail.gmail.com> <CANz3_Eb7QxhMn_2oAqysFYc-G0GkzZ4FW-+dyP_bW_rKUeHYZQ@mail.gmail.com> <C57917BE-51AE-40D0-80F9-5443E8D2E694@wirfs-brock.com> <255B9BB34FB7D647A506DC292726F6E115373AEB92@WSMSG3153V.srv.dir.telstra.com> <09E2A0C8-C2B6-4104-B208-F1FE5448DF44@wirfs-brock.com> <E1D0BBBF-77AE-452C-B9E4-CAB3B878DC96@wirfs-brock.com> <52A9704E.1080001@gmx.de> <1E1F2032-868B-437C-82C4-40BE24C08D61@wirfs-brock.com> <CAK3OfOhLg5_abLQDErOP9y9vXXXyst9ekJ4Ds8urDMMb9OA7Dw@mail.gmail.com> <CAHBU6ivQikEs=HneNa-B=XoacZZiSNzirvm3SANnEE1ZgpFjqw@mail.gmail.com>
Date: Thu, 12 Dec 2013 13:05:56 -0500
X-Google-Sender-Auth: 6DspJ1hqtjaOv2mfGlzpHU9Nxlg
Message-ID: <CAOXDeqpnb_QSTu6sDaLddTAAH7ZdmhQYKp4ttUpDuGATeX_CXw@mail.gmail.com>
From: Matthew Morley <matt@mpcm.com>
To: Tim Bray <tbray@textuality.com>
Content-Type: multipart/alternative; boundary=089e014942f67e18ec04ed5a3267
Cc: Julian Reschke <julian.reschke@gmx.de>, Nico Williams <nico@cryptonector.com>, JSON WG <json@ietf.org>, "Manger, James" <James.H.Manger@team.telstra.com>, Allen Wirfs-Brock <allen@wirfs-brock.com>
Subject: Re: [Json] object element order
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 18:06:06 -0000

--089e014942f67e18ec04ed5a3267
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 12, 2013 at 12:19 PM, Tim Bray <tbray@textuality.com> wrote:

> 4627 says =93An object is an unordered collection of zero or more name/va=
lue
> pairs=94, which seems crystal-clear to me. I don=92t think this needs to =
be
> either weakened or repeated.
>

+1



>
> On Thu, Dec 12, 2013 at 8:29 AM, Nico Williams <nico@cryptonector.com>wro=
te:
>
>> On Thu, Dec 12, 2013 at 10:22 AM, Allen Wirfs-Brock
>> <allen@wirfs-brock.com> wrote:
>> > On Dec 12, 2013, at 12:14 AM, Julian Reschke wrote:
>> >> For "maximum interoperability" this absolutely is a MUST, not a
>> SHOULD, right?
>> >>
>> >
>> > Simply as a mater of style, within a TC39 spec. we wouldn't normative
>> verb forms in an informative note.  A different restatement of the last
>> sentence is:
>>
>> The normative part of JSON we have consensus for has no requirements
>> language as it's just syntax, and the ABNF suffices for the purpose of
>> normative language.  The interoperability recommendations are not
>> really normative, but they are recommendations, and "SHOULD" is a
>> recommendation.  We should not use MUST/REQUIRED for any of it (sad
>> though that makes me).
>>
>> > Application semantics that assign meaning to member ordering or the us=
e
>> of duplication member names are less interoperable.
>>
>> We know what an interoperable least common denominator looks like.  We
>> should document it rather than hint at it -- leaving the reader to
>> read whatever semantics they'd like into the syntax hasn't worked out
>> too well, so let's not repeat that.
>>
>> Perhaps we have two interoperable least common denominators (where the
>> difference is about object name order preservation).  If so we should
>> document them both.
>>
>> Nico
>> --
>> _______________________________________________
>> json mailing list
>> json@ietf.org
>> https://www.ietf.org/mailman/listinfo/json
>>
>
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>
>

--089e014942f67e18ec04ed5a3267
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Dec 12, 2013 at 12:19 PM, Tim Bray <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:tbray@textuality.com" target=3D"_blank">tbray@textuality.com</a>&gt;</s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">4627 says =93An object is a=
n unordered collection of zero or more name/value pairs=94, which seems cry=
stal-clear to me. I don=92t think this needs to be either weakened or repea=
ted.</div>
</blockquote><div><br>+1<br></div><div>=A0</div><div>=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gma=
il_extra">

<br><div class=3D"gmail_quote">On Thu, Dec 12, 2013 at 8:29 AM, Nico Willia=
ms <span dir=3D"ltr">&lt;<a href=3D"mailto:nico@cryptonector.com" target=3D=
"_blank">nico@cryptonector.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div>On Thu, Dec 12, 2013 at 10:22 AM, Allen Wirfs-Brock<br>
&lt;<a href=3D"mailto:allen@wirfs-brock.com" target=3D"_blank">allen@wirfs-=
brock.com</a>&gt; wrote:<br>
&gt; On Dec 12, 2013, at 12:14 AM, Julian Reschke wrote:<br>
</div><div>&gt;&gt; For &quot;maximum interoperability&quot; this absolutel=
y is a MUST, not a SHOULD, right?<br>
&gt;&gt;<br>
&gt;<br>
&gt; Simply as a mater of style, within a TC39 spec. we wouldn&#39;t normat=
ive verb forms in an informative note. =A0A different restatement of the la=
st sentence is:<br>
<br>
</div>The normative part of JSON we have consensus for has no requirements<=
br>
language as it&#39;s just syntax, and the ABNF suffices for the purpose of<=
br>
normative language. =A0The interoperability recommendations are not<br>
really normative, but they are recommendations, and &quot;SHOULD&quot; is a=
<br>
recommendation. =A0We should not use MUST/REQUIRED for any of it (sad<br>
though that makes me).<br>
<div><br>
&gt; Application semantics that assign meaning to member ordering or the us=
e of duplication member names are less interoperable.<br>
<br>
</div>We know what an interoperable least common denominator looks like. =
=A0We<br>
should document it rather than hint at it -- leaving the reader to<br>
read whatever semantics they&#39;d like into the syntax hasn&#39;t worked o=
ut<br>
too well, so let&#39;s not repeat that.<br>
<br>
Perhaps we have two interoperable least common denominators (where the<br>
difference is about object name order preservation). =A0If so we should<br>
document them both.<br>
<br>
Nico<br>
--<br>
<div><div>_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org" target=3D"_blank">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
<br></blockquote></div><br></div></div>

--089e014942f67e18ec04ed5a3267--

From pfpschneider@gmail.com  Mon Dec 16 16:45:56 2013
Return-Path: <pfpschneider@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FA21ADBCB for <json@ietfa.amsl.com>; Mon, 16 Dec 2013 16:45:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
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 1r4b91vk1DXy for <json@ietfa.amsl.com>; Mon, 16 Dec 2013 16:45:54 -0800 (PST)
Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 77E7A1ADF95 for <json@ietf.org>; Mon, 16 Dec 2013 16:45:54 -0800 (PST)
Received: by mail-yh0-f48.google.com with SMTP id f73so4400553yha.21 for <json@ietf.org>; Mon, 16 Dec 2013 16:45:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=SrqtDld08Wqh1t08h6wJWmSt7sNb+JtBfEczw4mwo20=; b=SjSOULYn13D0M6C7Lsx5A9iplsRpxiSBX4XVRIoLp8zuXRLWDGOH9/1lc94LPg+u7s 2GEnlJi2GpJLsxOSmvLeeSEYxtJYmV/Xzxc8FZxkkVFLl+Uso9PFkTwLKGB8FlT/4poP K4aPdOKfzVCkChdbG3UaO7DEyYq/gdD2hL7Jc/Hn0jX+S5eBE7JznbD/GXNwmOEEXvPi JIZnG4sAXkrDlgWNbNWpm04iMO6Fp14DXQeAVEBjbxTq7mlGoqx0yuIQwEg0EpVUKLCK B8NIFTDHmn5nRBxHiPMK24YWx83k/bIDrnt97iadwtM73vkx1ttQyReA3LVjFsEJVX0C N9uQ==
X-Received: by 10.236.20.75 with SMTP id o51mr9321122yho.65.1387241153595; Mon, 16 Dec 2013 16:45:53 -0800 (PST)
Received: from [192.168.94.58] ([199.4.160.88]) by mx.google.com with ESMTPSA id n48sm21793880yho.24.2013.12.16.16.45.51 for <json@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Dec 2013 16:45:52 -0800 (PST)
From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D6CF8C8C-FAF2-4F06-B6DC-8EEA8879185F"
Message-Id: <1C243234-CA6E-4EE1-A4AA-DEC175A23AEC@gmail.com>
Date: Mon, 16 Dec 2013 16:46:03 -0800
To: JSON WG <json@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Subject: [Json] problem with using code units to define comparison of Unicode code points
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2013 00:45:56 -0000

--Apple-Mail=_D6CF8C8C-FAF2-4F06-B6DC-8EEA8879185F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I do not think that the following wording in rfc4627bis-09 is correct:

8.3. String Comparison

Software implementations are typically required to test names of object =
members for equality. Implementations which transform the textual =
representation into sequences of Unicode code units, and then perform =
the comparison numerically, code unit by code unit, are interoperable in =
the sense that implementations will agree in all cases on equality or =
inequality of two strings. For example, implementations which compare =
strings with escaped characters unconverted may incorrectly find that =
"a\\b" and "a\u005Cb" are not equal.


A naive implementation of this process will result in different answers =
for UTF-16 code units from UTF-8 and UTF-32 code units because UTF-16 =
must encode extended characters as two code units so the string =
containing U+1D11E will compare equal to the string containing =
U+D834,U+DD1E but in UTF-8 and UTF-32 the naive implementation would =
result in inequality.


This is separate from the issue that no UTF encoding scheme can encode =
surrogate code points.

peter


--Apple-Mail=_D6CF8C8C-FAF2-4F06-B6DC-8EEA8879185F
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><h1 id="rfc.section.8.3">I do not think that the following wording in rfc4627bis-09 is correct:</h1><h1 id="rfc.section.8.3"><a href="https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-09.html#rfc.section.8.3">8.3.</a> String Comparison</h1><p id="rfc.section.8.3.p.1">Software implementations are typically 
required to test names of object members for equality.  Implementations 
which transform the textual representation into sequences of Unicode 
code units, and then perform the comparison numerically, code unit by 
code unit, are interoperable in the sense that implementations will 
agree in all cases on equality or inequality of two strings.  For 
example, implementations which compare strings with escaped characters 
unconverted may incorrectly find that "a\\b" and "a\u005Cb" are not 
equal.</p><div><br></div><div>A naive implementation of this process will result in different answers for UTF-16 code units from UTF-8 and UTF-32 code units because UTF-16 must encode extended characters as two code units so the string containing U+1D11E will compare equal to the string containing U+D834,U+DD1E but in UTF-8 and UTF-32 the naive implementation would result in inequality.</div><div><br></div><div><br></div><div>This is separate from the issue that no UTF encoding scheme can encode surrogate code points.</div><div><br></div><div>peter</div><div><br></div></body></html>
--Apple-Mail=_D6CF8C8C-FAF2-4F06-B6DC-8EEA8879185F--

From cabo@tzi.org  Mon Dec 16 22:26:06 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1646A1AE0D1 for <json@ietfa.amsl.com>; Mon, 16 Dec 2013 22:26:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 ILIQ6cBdBjei for <json@ietfa.amsl.com>; Mon, 16 Dec 2013 22:26:04 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 46D2A1AE0CE for <json@ietf.org>; Mon, 16 Dec 2013 22:26:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBH6Q0ZU016198; Tue, 17 Dec 2013 07:26:00 +0100 (CET)
Received: from [192.168.217.105] (p548930A5.dip0.t-ipconnect.de [84.137.48.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40DFB69B; Tue, 17 Dec 2013 07:26:00 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <1C243234-CA6E-4EE1-A4AA-DEC175A23AEC@gmail.com>
Date: Tue, 17 Dec 2013 07:25:58 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <CC8E2B9B-D91D-429B-B085-3E1B67B0EA1A@tzi.org>
References: <1C243234-CA6E-4EE1-A4AA-DEC175A23AEC@gmail.com>
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
X-Mailer: Apple Mail (2.1827)
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] problem with using code units to define comparison of Unicode code points
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2013 06:26:06 -0000

I believe this is simply a bug.  s/code unit/code point/g and the text =
makes sense.

Gr=FC=DFe, Carsten

On 17 Dec 2013, at 01:46, Peter F. Patel-Schneider =
<pfpschneider@gmail.com> wrote:

> I do not think that the following wording in rfc4627bis-09 is correct:
>=20
> 8.3. String Comparison
>=20
> Software implementations are typically required to test names of =
object members for equality. Implementations which transform the textual =
representation into sequences of Unicode code units, and then perform =
the comparison numerically, code unit by code unit, are interoperable in =
the sense that implementations will agree in all cases on equality or =
inequality of two strings. For example, implementations which compare =
strings with escaped characters unconverted may incorrectly find that =
"a\\b" and "a\u005Cb" are not equal.
>=20
>=20
> A naive implementation of this process will result in different =
answers for UTF-16 code units from UTF-8 and UTF-32 code units because =
UTF-16 must encode extended characters as two code units so the string =
containing U+1D11E will compare equal to the string containing =
U+D834,U+DD1E but in UTF-8 and UTF-32 the naive implementation would =
result in inequality.
>=20
>=20
> This is separate from the issue that no UTF encoding scheme can encode =
surrogate code points.
>=20
> peter
>=20
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json


From pfpschneider@gmail.com  Mon Dec 16 22:37:22 2013
Return-Path: <pfpschneider@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1A11AE0E0 for <json@ietfa.amsl.com>; Mon, 16 Dec 2013 22:37:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 hLt5ipsMtft3 for <json@ietfa.amsl.com>; Mon, 16 Dec 2013 22:37:20 -0800 (PST)
Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9D91ACCE4 for <json@ietf.org>; Mon, 16 Dec 2013 22:37:20 -0800 (PST)
Received: by mail-qe0-f48.google.com with SMTP id gc15so4830613qeb.35 for <json@ietf.org>; Mon, 16 Dec 2013 22:37:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Nka9h2CTjM7H666y0pt1ZFOhxvy55kNcDLAEIViNfEE=; b=rv7DQ9b6NO1+obUsZWEkwvVnPd12c3s7qpe5nhOtr4ou1op+4zyocqaGDGhNBaIME3 aais2vGNfAWYr1F7Ml6KcQ0n11k88y0YboNYHjotO/5sywVEci3m1Fp0zdhT8AF9DFD4 Tm7yPYBPmLopu8Xc6VA11r6zVMOPLraKuWoYYk1h806BqKPvc47Ax84C+z7nUlShXn9o uEXFLptLEMILbMPtO2iHvlDkVSMJAV4eVXTQDL2O1GWJ/oitSUgJArd3BvuLKh1jkHqD SH6AjqCf53KW+WAZ1DBJfrxrWj8H0jbXjMLU5TAlPsEGUjravZlkAupFCYMYO43btkiz W3ww==
X-Received: by 10.224.95.70 with SMTP id c6mr40140656qan.81.1387262239186; Mon, 16 Dec 2013 22:37:19 -0800 (PST)
Received: from [192.168.89.3] ([199.4.160.88]) by mx.google.com with ESMTPSA id i7sm48378703qeo.7.2013.12.16.22.37.17 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Dec 2013 22:37:18 -0800 (PST)
Message-ID: <52AFF11C.3030303@gmail.com>
Date: Mon, 16 Dec 2013 22:37:16 -0800
From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Carsten Bormann <cabo@tzi.org>
References: <1C243234-CA6E-4EE1-A4AA-DEC175A23AEC@gmail.com> <CC8E2B9B-D91D-429B-B085-3E1B67B0EA1A@tzi.org>
In-Reply-To: <CC8E2B9B-D91D-429B-B085-3E1B67B0EA1A@tzi.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] problem with using code units to define comparison of Unicode code points
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2013 06:37:22 -0000

That would certainly be better, but then the problem that the unescaping 
process is not fully specified would still arise.

peter

PS:  This problem is that the encoding process produces the same escaped 
sequence for multiple sequences of code points.


On 12/16/2013 10:25 PM, Carsten Bormann wrote:
> I believe this is simply a bug.  s/code unit/code point/g and the text makes sense.
>
> Grüße, Carsten
>
> On 17 Dec 2013, at 01:46, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>
>> I do not think that the following wording in rfc4627bis-09 is correct:
>>
>> 8.3. String Comparison
>>
>> Software implementations are typically required to test names of object members for equality. Implementations which transform the textual representation into sequences of Unicode code units, and then perform the comparison numerically, code unit by code unit, are interoperable in the sense that implementations will agree in all cases on equality or inequality of two strings. For example, implementations which compare strings with escaped characters unconverted may incorrectly find that "a\\b" and "a\u005Cb" are not equal.
>>
>>
>> A naive implementation of this process will result in different answers for UTF-16 code units from UTF-8 and UTF-32 code units because UTF-16 must encode extended characters as two code units so the string containing U+1D11E will compare equal to the string containing U+D834,U+DD1E but in UTF-8 and UTF-32 the naive implementation would result in inequality.
>>
>>
>> This is separate from the issue that no UTF encoding scheme can encode surrogate code points.
>>
>> peter
>>
>> _______________________________________________
>> json mailing list
>> json@ietf.org
>> https://www.ietf.org/mailman/listinfo/json


From cabo@tzi.org  Mon Dec 16 23:02:12 2013
Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF1C1AE0E9 for <json@ietfa.amsl.com>; Mon, 16 Dec 2013 23:02:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 npEfolSPDucS for <json@ietfa.amsl.com>; Mon, 16 Dec 2013 23:02:11 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 27A7F1AE0E7 for <json@ietf.org>; Mon, 16 Dec 2013 23:02:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBH724jN028435; Tue, 17 Dec 2013 08:02:04 +0100 (CET)
Received: from [192.168.217.105] (p548930A5.dip0.t-ipconnect.de [84.137.48.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4D8806AB; Tue, 17 Dec 2013 08:02:04 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <52AFF11C.3030303@gmail.com>
Date: Tue, 17 Dec 2013 08:02:02 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <22F1E0F6-F94B-4182-BDDC-CEC6D8B0C078@tzi.org>
References: <1C243234-CA6E-4EE1-A4AA-DEC175A23AEC@gmail.com> <CC8E2B9B-D91D-429B-B085-3E1B67B0EA1A@tzi.org> <52AFF11C.3030303@gmail.com>
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
X-Mailer: Apple Mail (2.1827)
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] problem with using code units to define comparison of Unicode code points
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2013 07:02:12 -0000

On 17 Dec 2013, at 07:37, Peter F. Patel-Schneider =
<pfpschneider@gmail.com> wrote:

> That would certainly be better, but then the problem that the =
unescaping process is not fully specified would still arise.

While it is not fully specified, combining the definition of a string, =
the definition of escaping, and the (implicit but obvious) requirement =
for round-tripping leaves you with exactly one way to do the unescaping.
It may not be nice to leave this for the implementer to figure out, but =
it doesn=92t seem to me the spec has an actual hole.

> PS:  This problem is that the encoding process produces the same =
escaped sequence for multiple sequences of code points.

That is just a result of the fact that UTF-16 cannot represent all =
sequences of code points, and JavaScript is stuck on UTF-16, which =
bleeds through to JSON through the escape convention.
So I don=92t know how this could be fixed in a JSON spec.  (It is not =
much of a problem in practice, where we encode sequences of characters =
[scalar values], which do decode the same.)

Gr=FC=DFe, Carsten


From internet-drafts@ietf.org  Thu Dec 19 14:55:00 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525911AEB85; Thu, 19 Dec 2013 14:55:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 2qH_5LNqP9OX; Thu, 19 Dec 2013 14:54:59 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BFA1AEB8A; Thu, 19 Dec 2013 14:54:58 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.84
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131219225458.2774.99071.idtracker@ietfa.amsl.com>
Date: Thu, 19 Dec 2013 14:54:58 -0800
Cc: json@ietf.org
Subject: [Json] I-D Action: draft-ietf-json-rfc4627bis-10.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2013 22:55:00 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the JavaScript Object Notation Working Group =
of the IETF.

	Title           : The JSON Data Interchange Format
	Author(s)       : Tim Bray
	Filename        : draft-ietf-json-rfc4627bis-10.txt
	Pages           : 14
	Date            : 2013-12-19

Abstract:
   JavaScript Object Notation (JSON) is a lightweight, text-based,
   language-independent data interchange format.  It was derived from
   the ECMAScript Programming Language Standard.  JSON defines a small
   set of formatting rules for the portable representation of structured
   data.

   This document removes inconsistencies with other specifications of
   JSON, repairs specification errors, and offers experience-based
   interoperability guidance.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From tbray@textuality.com  Thu Dec 19 14:56:35 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A94D1AEB9A for <json@ietfa.amsl.com>; Thu, 19 Dec 2013 14:56:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 qZSIn9dRpILY for <json@ietfa.amsl.com>; Thu, 19 Dec 2013 14:56:33 -0800 (PST)
Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id 643471AEB99 for <json@ietf.org>; Thu, 19 Dec 2013 14:56:33 -0800 (PST)
Received: by mail-la0-f43.google.com with SMTP id n7so759208lam.2 for <json@ietf.org>; Thu, 19 Dec 2013 14:56:30 -0800 (PST)
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:content-type; bh=1xvq1vPKSoRnaPTkH/nySugdbBJFQ7vOHPl3sZFfaIs=; b=Zcab6aQvLjic5QI2KUqGHFrfnRXB75nDUeD2PX/dCjsSkWCw9wXEL7PCZh8wjXwaR8 SZVbxpips13TV+pJTFuK6IkzxiKU5Yuc5i52t6v42NxlFJceNTamo6L/FZFH36JcWKf/ uG7QBPNbMBm4Y8JMQHHj708tmPqcYiN79VKk30O8bHSoazmNnxbSNrDjkFhD+FfF49s7 KkYAA8wWMu2bBv6vnfX+udrhrAGHHa/OhejBF3ZTtzSiFlXgpFnlYJkZgVYWJaI6uNvh vY37ThOUIfk8+Cc8B5iDChyJ19Zk4ED+PPW3tDnTI809nNL/HU3UUToPllhJLpDWxaPZ p4hA==
X-Gm-Message-State: ALoCoQmkN/m933JDSTh5siEAx1PRUH0CTD+4B2bxz5LKVEs56p6FCl/D/ieZeCosQX2+UeKqg9D9
MIME-Version: 1.0
X-Received: by 10.152.22.201 with SMTP id g9mr2028756laf.27.1387493790782; Thu, 19 Dec 2013 14:56:30 -0800 (PST)
Received: by 10.114.24.6 with HTTP; Thu, 19 Dec 2013 14:56:30 -0800 (PST)
X-Originating-IP: [96.49.81.176]
In-Reply-To: <20131219225458.2774.99071.idtracker@ietfa.amsl.com>
References: <20131219225458.2774.99071.idtracker@ietfa.amsl.com>
Date: Thu, 19 Dec 2013 14:56:30 -0800
Message-ID: <CAHBU6iun_0jZ5NsybVGCSOAPdmL7crhao0dCKM4B3KvN6hAa+A@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: "json@ietf.org" <json@ietf.org>
Content-Type: multipart/alternative; boundary=089e0158c3088728ae04edeb1203
Subject: Re: [Json] I-D Action: draft-ietf-json-rfc4627bis-10.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2013 22:56:35 -0000

--089e0158c3088728ae04edeb1203
Content-Type: text/plain; charset=UTF-8

Real HTML at https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-10.html


On Thu, Dec 19, 2013 at 2:54 PM, <internet-drafts@ietf.org> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the JavaScript Object Notation Working Group
> of the IETF.
>
>         Title           : The JSON Data Interchange Format
>         Author(s)       : Tim Bray
>         Filename        : draft-ietf-json-rfc4627bis-10.txt
>         Pages           : 14
>         Date            : 2013-12-19
>
> Abstract:
>    JavaScript Object Notation (JSON) is a lightweight, text-based,
>    language-independent data interchange format.  It was derived from
>    the ECMAScript Programming Language Standard.  JSON defines a small
>    set of formatting rules for the portable representation of structured
>    data.
>
>    This document removes inconsistencies with other specifications of
>    JSON, repairs specification errors, and offers experience-based
>    interoperability guidance.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-10
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-json-rfc4627bis-10
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>

--089e0158c3088728ae04edeb1203
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Real HTML at=C2=A0<a href=3D"https://www.tbray.org/tmp/dra=
ft-ietf-json-rfc4627bis-10.html">https://www.tbray.org/tmp/draft-ietf-json-=
rfc4627bis-10.html</a></div><div class=3D"gmail_extra"><br><br><div class=
=3D"gmail_quote">
On Thu, Dec 19, 2013 at 2:54 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:i=
nternet-drafts@ietf.org" target=3D"_blank">internet-drafts@ietf.org</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.<br>
=C2=A0This draft is a work item of the JavaScript Object Notation Working G=
roup of the IETF.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : The =
JSON Data Interchange Format<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Tim Bray<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet=
f-json-rfc4627bis-10.txt<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 14<b=
r>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 2013-12-19<br>
<br>
Abstract:<br>
=C2=A0 =C2=A0JavaScript Object Notation (JSON) is a lightweight, text-based=
,<br>
=C2=A0 =C2=A0language-independent data interchange format. =C2=A0It was der=
ived from<br>
=C2=A0 =C2=A0the ECMAScript Programming Language Standard. =C2=A0JSON defin=
es a small<br>
=C2=A0 =C2=A0set of formatting rules for the portable representation of str=
uctured<br>
=C2=A0 =C2=A0data.<br>
<br>
=C2=A0 =C2=A0This document removes inconsistencies with other specification=
s of<br>
=C2=A0 =C2=A0JSON, repairs specification errors, and offers experience-base=
d<br>
=C2=A0 =C2=A0interoperability guidance.<br>
<br>
<br>
The IETF datatracker status page for this draft is:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis" tar=
get=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis<=
/a><br>
<br>
There&#39;s also a htmlized version available at:<br>
<a href=3D"http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-10" target=
=3D"_blank">http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-10</a><br=
>
<br>
A diff from the previous version is available at:<br>
<a href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-10=
" target=3D"_blank">http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4=
627bis-10</a><br>
<br>
<br>
Please note that it may take a couple of minutes from the time of submissio=
n<br>
until the htmlized version and diff are available at <a href=3D"http://tool=
s.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br>
<br>
Internet-Drafts are also available by anonymous FTP at:<br>
<a href=3D"ftp://ftp.ietf.org/internet-drafts/" target=3D"_blank">ftp://ftp=
.ietf.org/internet-drafts/</a><br>
<br>
_______________________________________________<br>
json mailing list<br>
<a href=3D"mailto:json@ietf.org">json@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/json" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/json</a><br>
</blockquote></div><br></div>

--089e0158c3088728ae04edeb1203--

From paul.hoffman@vpnc.org  Thu Dec 19 14:57:23 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2D61AEB9B for <json@ietfa.amsl.com>; Thu, 19 Dec 2013 14:57:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 k2I_lbjdh8uf for <json@ietfa.amsl.com>; Thu, 19 Dec 2013 14:57:22 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B4D271AEB9A for <json@ietf.org>; Thu, 19 Dec 2013 14:57:22 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rBJMvI5S075944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Dec 2013 15:57:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 19 Dec 2013 14:57:18 -0800
Message-Id: <D8593C53-AB4A-4C19-BF28-4B69CAB46E8A@vpnc.org>
To: JSON WG <json@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
X-Mailer: Apple Mail (2.1827)
Cc: Pete Resnick <presnick@qti.qualcomm.com>
Subject: [Json] Diffs requested by the IESG for -10
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2013 22:57:23 -0000

Greetings again. As you can see, our esteemed editor has pushed out a =
new -10. The changes were requested by the IESG during their final =
review of the draft.

The changed text is visible here: =
<tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-10.txt>. =
Please let us know soon if any of the changes are technically incorrect =
or are for other reasons completely unlivable.

--Paul Hoffman=

From cowan@ccil.org  Thu Dec 19 15:05:35 2013
Return-Path: <cowan@ccil.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23C11AEB84 for <json@ietfa.amsl.com>; Thu, 19 Dec 2013 15:05:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.138
X-Spam-Level: 
X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham
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 HJVXHLRnaMzh for <json@ietfa.amsl.com>; Thu, 19 Dec 2013 15:05:32 -0800 (PST)
Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id EB1B81AEBD2 for <json@ietf.org>; Thu, 19 Dec 2013 15:05:30 -0800 (PST)
Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from <cowan@ccil.org>) id 1Vtmel-0005Ms-0e; Thu, 19 Dec 2013 18:05:27 -0500
Date: Thu, 19 Dec 2013 18:05:27 -0500
From: John Cowan <cowan@mercury.ccil.org>
To: Tim Bray <tbray@textuality.com>
Message-ID: <20131219230526.GC29284@mercury.ccil.org>
References: <20131219225458.2774.99071.idtracker@ietfa.amsl.com> <CAHBU6iun_0jZ5NsybVGCSOAPdmL7crhao0dCKM4B3KvN6hAa+A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHBU6iun_0jZ5NsybVGCSOAPdmL7crhao0dCKM4B3KvN6hAa+A@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <cowan@ccil.org>
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] I-D Action: draft-ietf-json-rfc4627bis-10.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2013 23:05:35 -0000

Tim Bray scripsit:

> Real HTML at https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-10.html

The (admittedly non-normative) claim that "all texts which were legal
JSON remain so" has been removed.  Is it no longer true?  If not,
I think it should return.

Otherwise +1 to all changes.

-- 
John Cowan <cowan@ccil.org>             http://www.ccil.org/~cowan
Fundamental thinking is ha-ard.  Let's go ideology-shopping.
                        --Philosopher Barbie

From stefan@drees.name  Fri Dec 20 09:50:50 2013
Return-Path: <stefan@drees.name>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD0F1ADF5C for <json@ietfa.amsl.com>; Fri, 20 Dec 2013 09:50:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 qyP4HJ8ZuVmH for <json@ietfa.amsl.com>; Fri, 20 Dec 2013 09:50:49 -0800 (PST)
Received: from mout.web.de (mout.web.de [212.227.17.12]) by ietfa.amsl.com (Postfix) with ESMTP id 079941A1F62 for <json@ietf.org>; Fri, 20 Dec 2013 09:50:48 -0800 (PST)
Received: from newyork.local.box ([80.187.100.72]) by smtp.web.de (mrweb103) with ESMTPSA (Nemesis) id 0MWS3S-1W1LKB3H9W-00Xg0F for <json@ietf.org>; Fri, 20 Dec 2013 18:50:45 +0100
Message-ID: <52B48375.4010303@drees.name>
Date: Fri, 20 Dec 2013 18:50:45 +0100
From: Stefan Drees <stefan@drees.name>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Tim Bray <tbray@textuality.com>, "json@ietf.org" <json@ietf.org>
References: <20131219225458.2774.99071.idtracker@ietfa.amsl.com> <CAHBU6iun_0jZ5NsybVGCSOAPdmL7crhao0dCKM4B3KvN6hAa+A@mail.gmail.com>
In-Reply-To: <CAHBU6iun_0jZ5NsybVGCSOAPdmL7crhao0dCKM4B3KvN6hAa+A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:gYzK6+/lCo1ArACkGo79Jn+6BeHepJyYTKlrBgRBwxMnxCK0BpE A2JlIDSIIS5Ff0h+nEIzBslJWqN2BCBFH78Edui/g2QK3jh3AeNNd7Bn/yotClrdbRU1jf2 dK6JHVIRfZbGMaFfVI/fbkw9mM5znIE4WfAYOo+wrAw3dlJ+Q51fTZEBZ2nKRP9LC2yHR5X trzQrAfjpenW1CVtnqpLw==
Subject: Re: [Json] I-D Action: draft-ietf-json-rfc4627bis-10.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: stefan@drees.name
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Dec 2013 17:50:50 -0000

On 2013-12-19 23:56 +01:00, Tim Bray wrote:
> Real HTML at https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-10.html

all changes but one look good to me. Like John Cowan I *really* miss the 
revision-9 upfront "all texts which were legal JSON remain so, and none 
which were not JSON become JSON." in all it's 
non-normative-but-nicely-explicit glory.
Could we get that one back in? I think this would be good.

All the best,
Stefan.

From tbray@textuality.com  Fri Dec 20 09:54:25 2013
Return-Path: <tbray@textuality.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6579B1ADF73 for <json@ietfa.amsl.com>; Fri, 20 Dec 2013 09:54:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 QAZKz248uMGl for <json@ietfa.amsl.com>; Fri, 20 Dec 2013 09:54:24 -0800 (PST)
Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id A9CAA1ADF6E for <json@ietf.org>; Fri, 20 Dec 2013 09:54:23 -0800 (PST)
Received: by mail-lb0-f173.google.com with SMTP id z5so1249347lbh.18 for <json@ietf.org>; Fri, 20 Dec 2013 09:54:20 -0800 (PST)
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:content-type; bh=11osRO5nWkrbEnfRG2U0ZQOwxCRvSvHc2GCh7w/8tq4=; b=Oi4DKj7rCViMG0hhPOLpaKhDCiqRNtRtHQb9NzPZRBymokpyPluChlM2n5UiaPfuZA xOABGgsffws+7sw0A7BWKTHNOoepQ3kIpUIumKTML/23f1GUxV9fRy4Oaa2dq1lXWEhx Q4C7bTn0KnHrq7QD0rmY5pmoJ7O8Yaq0rqanrpSvoHQeMoYgvx6P3NQp3bd6sf2L7MXy X3NtufyR0bkIWp8H4vOV9sp3023K8IBd0RhXwFRwUnzkgoX71zSAcgsmXvDFudJTl+VX iwKO5dTr5sXfCQWc//Sc5zz4B3KeuUWO86xc4j/M4YBVbH6lOYzW4Quu7y2imY4cGgP4 lBoA==
X-Gm-Message-State: ALoCoQkZ8kQ+/eK2Ii7bnnDpFW6VSD2HSNqAM2T8DTSGsJmrfTfOZxu7q7QJYEtvPmTtlvJwjuJ9
MIME-Version: 1.0
X-Received: by 10.152.21.3 with SMTP id r3mr4268862lae.15.1387562060791; Fri, 20 Dec 2013 09:54:20 -0800 (PST)
Received: by 10.114.24.6 with HTTP; Fri, 20 Dec 2013 09:54:20 -0800 (PST)
X-Originating-IP: [24.84.235.32]
In-Reply-To: <52B48375.4010303@drees.name>
References: <20131219225458.2774.99071.idtracker@ietfa.amsl.com> <CAHBU6iun_0jZ5NsybVGCSOAPdmL7crhao0dCKM4B3KvN6hAa+A@mail.gmail.com> <52B48375.4010303@drees.name>
Date: Fri, 20 Dec 2013 09:54:20 -0800
Message-ID: <CAHBU6iviBpLCSPv+jSvd581JzinWSK4CC3AD2hKXX8GUQg-bJQ@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Stefan Drees <stefan@drees.name>
Content-Type: multipart/alternative; boundary=089e014942f6bcd12704edfaf729
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] I-D Action: draft-ietf-json-rfc4627bis-10.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Dec 2013 17:54:25 -0000

--089e014942f6bcd12704edfaf729
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Well... unfortunately a bunch were formerly not JSON now are, see the last
3 examples in section 13.  Given that, the statement that no legal JSON
became illegal feels superfluous.  Anyhow, read what Paul said; now that
the IESG has signed off we really can=E2=80=99t touch this any more unless
something is broken in an actively harmful way.


On Fri, Dec 20, 2013 at 9:50 AM, Stefan Drees <stefan@drees.name> wrote:

> On 2013-12-19 23:56 +01:00, Tim Bray wrote:
>
>> Real HTML at https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-10.htm=
l
>>
>
> all changes but one look good to me. Like John Cowan I *really* miss the
> revision-9 upfront "all texts which were legal JSON remain so, and none
> which were not JSON become JSON." in all it's non-normative-but-nicely-ex=
plicit
> glory.
> Could we get that one back in? I think this would be good.
>
> All the best,
> Stefan.
>

--089e014942f6bcd12704edfaf729
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Well... unfortunately a bunch were formerly not JSON now a=
re, see the last 3 examples in section 13. =C2=A0Given that, the statement =
that no legal JSON became illegal feels superfluous. =C2=A0Anyhow, read wha=
t Paul said; now that the IESG has signed off we really can=E2=80=99t touch=
 this any more unless something is broken in an actively harmful way.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Dec 2=
0, 2013 at 9:50 AM, Stefan Drees <span dir=3D"ltr">&lt;<a href=3D"mailto:st=
efan@drees.name" target=3D"_blank">stefan@drees.name</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On 2013-12-19 23:56 +01:00, Tim Bray wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Real HTML at <a href=3D"https://www.tbray.org/tmp/draft-ietf-json-rfc4627bi=
s-10.html" target=3D"_blank">https://www.tbray.org/tmp/<u></u>draft-ietf-js=
on-rfc4627bis-10.<u></u>html</a><br>
</blockquote>
<br></div>
all changes but one look good to me. Like John Cowan I *really* miss the re=
vision-9 upfront &quot;all texts which were legal JSON remain so, and none =
which were not JSON become JSON.&quot; in all it&#39;s non-normative-but-ni=
cely-<u></u>explicit glory.<br>

Could we get that one back in? I think this would be good.<br>
<br>
All the best,<br>
Stefan.<br>
</blockquote></div><br></div>

--089e014942f6bcd12704edfaf729--

From stefan@drees.name  Fri Dec 20 11:54:11 2013
Return-Path: <stefan@drees.name>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0ED1AE111 for <json@ietfa.amsl.com>; Fri, 20 Dec 2013 11:54:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 DtrfJsi7w2ZE for <json@ietfa.amsl.com>; Fri, 20 Dec 2013 11:54:11 -0800 (PST)
Received: from mout.web.de (mout.web.de [212.227.17.11]) by ietfa.amsl.com (Postfix) with ESMTP id ABD861AE010 for <json@ietf.org>; Fri, 20 Dec 2013 11:54:10 -0800 (PST)
Received: from newyork.local.box ([80.187.100.72]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0LuuSf-1VTsCM1KEr-0108Mh for <json@ietf.org>; Fri, 20 Dec 2013 20:54:07 +0100
Message-ID: <52B4A05E.8030901@drees.name>
Date: Fri, 20 Dec 2013 20:54:06 +0100
From: Stefan Drees <stefan@drees.name>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Tim Bray <tbray@textuality.com>
References: <20131219225458.2774.99071.idtracker@ietfa.amsl.com>	<CAHBU6iun_0jZ5NsybVGCSOAPdmL7crhao0dCKM4B3KvN6hAa+A@mail.gmail.com>	<52B48375.4010303@drees.name> <CAHBU6iviBpLCSPv+jSvd581JzinWSK4CC3AD2hKXX8GUQg-bJQ@mail.gmail.com>
In-Reply-To: <CAHBU6iviBpLCSPv+jSvd581JzinWSK4CC3AD2hKXX8GUQg-bJQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:kUsGx94MZ77wAaYNuC9d92kBALNjBFUlaIvtoJ89leg2Uo1Oio+ +F5xhEG2wL54Wqk0hLdygB8GZcscjWJmIyfszrpaMxTVo42rPHSXqFpl/5azT5j6z63BMO2 ogdMmrgs+tI3WNNsq6X50gYj+mQ8srN9kyva7Sou0Jae8Z6uss2nuUzobfglVpmexPnFtLE YkmXvkpYMDp+vUsKTPkZw==
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] I-D Action: draft-ietf-json-rfc4627bis-10.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: stefan@drees.name
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Dec 2013 19:54:12 -0000

On 2013-12-20 18:54 +01:00, Tim Bray wrote:
> Well... unfortunately a bunch were formerly not JSON now are, see the
> last 3 examples in section 13.  Given that, the statement that no legal
> JSON became illegal feels superfluous.  Anyhow, read what Paul said; now
> that the IESG has signed off we really can’t touch this any more unless
> something is broken in an actively harmful way.

I am a bit astonished, that any "statement that no legal JSON became 
illegal" might appear superfluous. I thought that would be the core of 
downward compatibility, but even an old dog can learn new tricks ;-)

At least Section 2. JSON Grammar somehow hints at it: "Note that certain 
previous specifications of JSON constrained a JSON text to be an object 
or an array. Implementations which generate only objects or arrays where 
a JSON text is called for will be interoperable in the sense that all 
implementations will accept these as conforming JSON texts."

All the best,
Stefan.
>
> On Fri, Dec 20, 2013 at 9:50 AM, Stefan Drees <stefan@drees.name
> <mailto:stefan@drees.name>> wrote:
>
>     On 2013-12-19 23:56 +01:00, Tim Bray wrote:
>
>         Real HTML at
>         https://www.tbray.org/tmp/__draft-ietf-json-rfc4627bis-10.__html
>         <https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-10.html>
>
>
>     all changes but one look good to me. Like John Cowan I *really* miss
>     the revision-9 upfront "all texts which were legal JSON remain so,
>     and none which were not JSON become JSON." in all it's
>     non-normative-but-nicely-__explicit glory.
>     Could we get that one back in? I think this would be good.
>
>     All the best,
>     Stefan.
>
>


From duerst@it.aoyama.ac.jp  Fri Dec 20 18:43:52 2013
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CBB1AE252 for <json@ietfa.amsl.com>; Fri, 20 Dec 2013 18:43:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.371
X-Spam-Level: 
X-Spam-Status: No, score=0.371 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538] autolearn=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 WWZLphgdUPn5 for <json@ietfa.amsl.com>; Fri, 20 Dec 2013 18:43:50 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 699721AD9AE for <json@ietf.org>; Fri, 20 Dec 2013 18:43:49 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id rBL2hU1N003304; Sat, 21 Dec 2013 11:43:30 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 3451_eb9d_ad24b50e_69e9_11e3_9396_001e6722eec2; Sat, 21 Dec 2013 11:43:29 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id CEB8ABF54B; Sat, 21 Dec 2013 11:43:29 +0900 (JST)
Message-ID: <52B5003E.2060300@it.aoyama.ac.jp>
Date: Sat, 21 Dec 2013 11:43:10 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: stefan@drees.name
References: <20131219225458.2774.99071.idtracker@ietfa.amsl.com>	<CAHBU6iun_0jZ5NsybVGCSOAPdmL7crhao0dCKM4B3KvN6hAa+A@mail.gmail.com>	<52B48375.4010303@drees.name> <CAHBU6iviBpLCSPv+jSvd581JzinWSK4CC3AD2hKXX8GUQg-bJQ@mail.gmail.com> <52B4A05E.8030901@drees.name>
In-Reply-To: <52B4A05E.8030901@drees.name>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Barry Leiba <barryleiba@computer.org>, Tim Bray <tbray@textuality.com>, Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] I-D Action: draft-ietf-json-rfc4627bis-10.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Dec 2013 02:43:52 -0000

It's very clear to me that in the last revision, removing the "none=20
which were not JSON become JSON" was the goal, and the removal of "all=20
texts which were legal JSON remain so" was just an unintended side=20
effect and clerical error.

While we shouldn't continue to willy-nilly tweak the spec after IESG=20
approval, I have seen many examples where fixes like this were done e.g.=20
by an AD note to the RFC editor, and I think in the case at hand, that=20
would be highly appropriate.

Regards,   Martin.

On 2013/12/21 4:54, Stefan Drees wrote:
> On 2013-12-20 18:54 +01:00, Tim Bray wrote:
>> Well... unfortunately a bunch were formerly not JSON now are, see the
>> last 3 examples in section 13. Given that, the statement that no legal
>> JSON became illegal feels superfluous. Anyhow, read what Paul said; no=
w
>> that the IESG has signed off we really can=E2=80=99t touch this any mo=
re unless
>> something is broken in an actively harmful way.
>
> I am a bit astonished, that any "statement that no legal JSON became
> illegal" might appear superfluous. I thought that would be the core of
> downward compatibility, but even an old dog can learn new tricks ;-)
>
> At least Section 2. JSON Grammar somehow hints at it: "Note that certai=
n
> previous specifications of JSON constrained a JSON text to be an object
> or an array. Implementations which generate only objects or arrays wher=
e
> a JSON text is called for will be interoperable in the sense that all
> implementations will accept these as conforming JSON texts."
>
> All the best,
> Stefan.
>>
>> On Fri, Dec 20, 2013 at 9:50 AM, Stefan Drees <stefan@drees.name
>> <mailto:stefan@drees.name>> wrote:
>>
>> On 2013-12-19 23:56 +01:00, Tim Bray wrote:
>>
>> Real HTML at
>> https://www.tbray.org/tmp/__draft-ietf-json-rfc4627bis-10.__html
>> <https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-10.html>
>>
>>
>> all changes but one look good to me. Like John Cowan I *really* miss
>> the revision-9 upfront "all texts which were legal JSON remain so,
>> and none which were not JSON become JSON." in all it's
>> non-normative-but-nicely-__explicit glory.
>> Could we get that one back in? I think this would be good.
>>
>> All the best,
>> Stefan.
>>
>>
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json

From stefan@drees.name  Sat Dec 21 02:29:50 2013
Return-Path: <stefan@drees.name>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8368C1AC82A for <json@ietfa.amsl.com>; Sat, 21 Dec 2013 02:29:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level: 
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 WdXTIho4qgFu for <json@ietfa.amsl.com>; Sat, 21 Dec 2013 02:29:49 -0800 (PST)
Received: from mout.web.de (mout.web.de [212.227.15.4]) by ietfa.amsl.com (Postfix) with ESMTP id A97EB1AC7F1 for <json@ietf.org>; Sat, 21 Dec 2013 02:29:48 -0800 (PST)
Received: from newyork.local.box ([80.187.101.68]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0M8i11-1VYgK445vH-00wCbm for <json@ietf.org>; Sat, 21 Dec 2013 11:29:45 +0100
Message-ID: <52B56D95.2080704@drees.name>
Date: Sat, 21 Dec 2013 11:29:41 +0100
From: Stefan Drees <stefan@drees.name>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
References: <20131219225458.2774.99071.idtracker@ietfa.amsl.com>	<CAHBU6iun_0jZ5NsybVGCSOAPdmL7crhao0dCKM4B3KvN6hAa+A@mail.gmail.com>	<52B48375.4010303@drees.name> <CAHBU6iviBpLCSPv+jSvd581JzinWSK4CC3AD2hKXX8GUQg-bJQ@mail.gmail.com> <52B4A05E.8030901@drees.name> <52B5003E.2060300@it.aoyama.ac.jp>
In-Reply-To: <52B5003E.2060300@it.aoyama.ac.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:xvYupR8ga+CnwFhwO8+TLA0flUkD+cmRVVtRHrV03i3kUW2Thbs qRh1nTRJkAu/HJ3+FxurkyraUxYFG8USujxGqyWTT67j9ZmKhfSs/pbCQQJ7sKPotmblRfx GZScUv3yXIw17mdnJFuNQSfQ9KEF42DsOMGgHx1OSewok5HfqRr8C3MoAFrbc4FE+v+a3A5 khIgz5WAbsAcNtiT/jsGQ==
Cc: "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Barry Leiba <barryleiba@computer.org>, Tim Bray <tbray@textuality.com>, Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] I-D Action: draft-ietf-json-rfc4627bis-10.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: stefan@drees.name
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Dec 2013 10:29:50 -0000

On 2013-12-21 03:43 +01:00, Martin J. Dürst wrote:
> It's very clear to me that in the last revision, removing the "none
> which were not JSON become JSON" was the goal, and the removal of "all
> texts which were legal JSON remain so" was just an unintended side
> effect and clerical error.
>
> While we shouldn't continue to willy-nilly tweak the spec after IESG
> approval, I have seen many examples where fixes like this were done e.g.
> by an AD note to the RFC editor, and I think in the case at hand, that
> would be highly appropriate.

+1 from my side for following this suggested path to explicitely restate 
the downward compatibility in a prominent place.

All the best,
Stefan.


> Regards,   Martin.
>
> On 2013/12/21 4:54, Stefan Drees wrote:
>> On 2013-12-20 18:54 +01:00, Tim Bray wrote:
>>> Well... unfortunately a bunch were formerly not JSON now are, see the
>>> last 3 examples in section 13. Given that, the statement that no legal
>>> JSON became illegal feels superfluous. Anyhow, read what Paul said; now
>>> that the IESG has signed off we really can’t touch this any more unless
>>> something is broken in an actively harmful way.
>>
>> I am a bit astonished, that any "statement that no legal JSON became
>> illegal" might appear superfluous. I thought that would be the core of
>> downward compatibility, but even an old dog can learn new tricks ;-)
>>
>> At least Section 2. JSON Grammar somehow hints at it: "Note that certain
>> previous specifications of JSON constrained a JSON text to be an object
>> or an array. Implementations which generate only objects or arrays where
>> a JSON text is called for will be interoperable in the sense that all
>> implementations will accept these as conforming JSON texts."
>>
>> All the best,
>> Stefan.
>>>
>>> On Fri, Dec 20, 2013 at 9:50 AM, Stefan Drees <stefan@drees.name
>>> <mailto:stefan@drees.name>> wrote:
>>>
>>> On 2013-12-19 23:56 +01:00, Tim Bray wrote:
>>>
>>> Real HTML at
>>> https://www.tbray.org/tmp/__draft-ietf-json-rfc4627bis-10.__html
>>> <https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-10.html>
>>>
>>>
>>> all changes but one look good to me. Like John Cowan I *really* miss
>>> the revision-9 upfront "all texts which were legal JSON remain so,
>>> and none which were not JSON become JSON." in all it's
>>> non-normative-but-nicely-__explicit glory.
>>> Could we get that one back in? I think this would be good.
>>>
>>> All the best,
>>> Stefan.
>>>
>>>
>>
>> _______________________________________________
>> json mailing list
>> json@ietf.org
>> https://www.ietf.org/mailman/listinfo/json


From huangng@gmail.com  Mon Dec 23 05:54:45 2013
Return-Path: <huangng@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C521AE022 for <json@ietfa.amsl.com>; Mon, 23 Dec 2013 05:54:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
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 y8qld9YtLc-5 for <json@ietfa.amsl.com>; Mon, 23 Dec 2013 05:54:43 -0800 (PST)
Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 289521ADDBD for <json@ietf.org>; Mon, 23 Dec 2013 05:54:43 -0800 (PST)
Received: by mail-vb0-f49.google.com with SMTP id x11so2726284vbb.22 for <json@ietf.org>; Mon, 23 Dec 2013 05:54:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qSIZmI/GXLANtMoOpcPLu0g6GRfLZdd4ulZUkTNoFuU=; b=hhjaKNqdxRDg8JZX5C5lIzwXReRnuMgznhz9wGzqUXo4sU1iVl/0y2c/XzbOTDmn6V Ch+vOv2J6024NADLoQGn49OMee2eF8mJj90w5uJganwuqPdmhIwkLdGPkLcca49YQvdN LA51aeVnEGhbppj7bJvnCppCScqwm6DBk6Nl6J98vsmrh+zsBGRcWdkWCzNLr2VRYQ6U 5rL/xxt/DpKJ2uaOlu3hecYjhUz4js0eFkYLLgfrS3ucQsinfneDIYRzMT9kPuBxGSoF tYowHubf71O9sdaWBvyA7/13wNGQQGji98rYurATzv8Y4z7JeD7w8+gMcAiut1g3Vkbx h7gw==
MIME-Version: 1.0
X-Received: by 10.58.187.81 with SMTP id fq17mr14362457vec.14.1387806879687; Mon, 23 Dec 2013 05:54:39 -0800 (PST)
Received: by 10.52.116.166 with HTTP; Mon, 23 Dec 2013 05:54:39 -0800 (PST)
Date: Mon, 23 Dec 2013 21:54:39 +0800
Message-ID: <CAATpOdohu26M_R+eUrcxj7ZED1ae+yCKkMmaFUe7vRcKL3OffQ@mail.gmail.com>
From: Neng Geng Huang <huangng@gmail.com>
To: json@ietf.org
Content-Type: multipart/alternative; boundary=047d7b6dcfe214ab1104ee33f8f0
Subject: [Json] I-D draft-huangng-idtp-01.txt
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Dec 2013 13:54:45 -0000

--047d7b6dcfe214ab1104ee33f8f0
Content-Type: text/plain; charset=ISO-8859-1

Hello, are there any one who interested in a new submittted Internet-Draft
IDTP?

IDTP uses JSON data format for transferring.

Filename:        draft-huangng-idtp
Revision:        01
Title:           Identifier Tracing Protocol (IDTP)
Creation date:   2013-12-02
Group:           Individual Submission
Number of pages: 38
URL:
http://www.ietf.org/internet-drafts/draft-huangng-idtp-01.txt
Status:          http://datatracker.ietf.org/doc/draft-huangng-idtp
Htmlized:        http://tools.ietf.org/html/draft-huangng-idtp-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-huangng-idtp-01

Abstract:
   The Identifier Tracing Protocol (IDTP) is an application-level
   protocol for distributed and collaborative information systems. It
   is a generic communication protocol which can be used for many tasks
   with two types of forwarding mechanisms to achieve traceability by
   using Universal Traceable Identifier (UTID) [I-D-UTID] which
   contains two types of forwarding messages.

   This document provides the specification of IDTP, including syntax,
   data format, and the guidelines for their use, too.

Thanks

Huang

-- 
------------------------------
Mr. Huang Neng Geng
------------------------------
Associate Professor
School of the Internet of Things
Wuxi Institute of Technology
Wuxi, Jiangsu, China, 214121
Mobile: 86-13921501950
email: huangng@gmail.com

--047d7b6dcfe214ab1104ee33f8f0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello, are there any one who interested in a new subm=
ittted Internet-Draft IDTP?</div><div><br></div><div>IDTP uses JSON data fo=
rmat for transferring.</div><div><br></div><div>Filename: =A0 =A0 =A0 =A0dr=
aft-huangng-idtp</div>
<div>Revision: =A0 =A0 =A0 =A001</div><div>Title: =A0 =A0 =A0 =A0 =A0 Ident=
ifier Tracing Protocol (IDTP)</div><div>Creation date: =A0 2013-12-02</div>=
<div>Group: =A0 =A0 =A0 =A0 =A0 Individual Submission</div><div>Number of p=
ages: 38</div><div>URL: =A0 =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.ietf.=
org/internet-drafts/draft-huangng-idtp-01.txt">http://www.ietf.org/internet=
-drafts/draft-huangng-idtp-01.txt</a></div>
<div>Status: =A0 =A0 =A0 =A0 =A0<a href=3D"http://datatracker.ietf.org/doc/=
draft-huangng-idtp">http://datatracker.ietf.org/doc/draft-huangng-idtp</a><=
/div><div>Htmlized: =A0 =A0 =A0 =A0<a href=3D"http://tools.ietf.org/html/dr=
aft-huangng-idtp-01">http://tools.ietf.org/html/draft-huangng-idtp-01</a></=
div>
<div>Diff: =A0 =A0 =A0 =A0 =A0 =A0<a href=3D"http://www.ietf.org/rfcdiff?ur=
l2=3Ddraft-huangng-idtp-01">http://www.ietf.org/rfcdiff?url2=3Ddraft-huangn=
g-idtp-01</a></div><div><br></div><div>Abstract:</div><div>=A0 =A0The Ident=
ifier Tracing Protocol (IDTP) is an application-level</div>
<div>=A0 =A0protocol for distributed and collaborative information systems.=
 It</div><div>=A0 =A0is a generic communication protocol which can be used =
for many tasks</div><div>=A0 =A0with two types of forwarding mechanisms to =
achieve traceability by</div>
<div>=A0 =A0using Universal Traceable Identifier (UTID) [I-D-UTID] which</d=
iv><div>=A0 =A0contains two types of forwarding messages.</div><div><br></d=
iv><div>=A0 =A0This document provides the specification of IDTP, including =
syntax,</div>
<div>=A0 =A0data format, and the guidelines for their use, too.</div><div><=
br></div><div>Thanks</div><div><br></div><div>Huang</div><div><br></div>-- =
<br><div dir=3D"ltr">------------------------------<br>Mr. Huang Neng Geng<=
br>
------------------------------<br>Associate Professor<br>School of the Inte=
rnet of Things<br>Wuxi Institute of Technology<br>Wuxi, Jiangsu, China, 214=
121<br>Mobile: 86-13921501950<br>email: <a href=3D"mailto:huangng@gmail.com=
" target=3D"_blank">huangng@gmail.com</a><div>
<br></div></div>
</div>

--047d7b6dcfe214ab1104ee33f8f0--