From nobody Wed Sep  2 13:08:12 2015
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 204431B345F for <json@ietfa.amsl.com>; Wed,  2 Sep 2015 13:08:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.622
X-Spam-Level: 
X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 CZuSUKNpgrIa for <json@ietfa.amsl.com>; Wed,  2 Sep 2015 13:08:10 -0700 (PDT)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A071B337F for <json@ietf.org>; Wed,  2 Sep 2015 13:08:09 -0700 (PDT)
Received: by lbcjc2 with SMTP id jc2so12801652lbc.0 for <json@ietf.org>; Wed, 02 Sep 2015 13:08:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:date:message-id:subject:from:to:content-type;  bh=/M7fpuIK8p+Th4I5/g7RFd3tpdaETos/gTnMRm7V9qc=; b=xr6tPCF68Nq6KkFnOiukpMt5Gq/zrTms6PB7i3TM4mLrd3GzsGh7SwN94kbw3l8lTg poPZ5PpgAELWbVjL9BP5nh8tcwo+b9v3VETc/Qcf7Ix42SaKy2SjpIltQ1ZIIbBeImLx 7qHkuW0JP9tNsqvORV6tPL6cY3G8AscsFYh0C8ig0QMR5v4U79f/RQQY0Rj8Xzzq9gGw NwXW0IvVEy09Pe9y5McJuEU/uHESlbBhBHud20MvVS51WONhbJV0TMcrViO2YyA1M6Ef QPNJGo8GHeGntvAz2EPUooEln1gzpahUwaSbFcYG8+JSmHgLFlgA5y2laIeVVJhOPg1P XNfA==
MIME-Version: 1.0
X-Received: by 10.112.160.98 with SMTP id xj2mr17913214lbb.124.1441224488075;  Wed, 02 Sep 2015 13:08:08 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.203.163 with HTTP; Wed, 2 Sep 2015 13:08:08 -0700 (PDT)
Date: Wed, 2 Sep 2015 16:08:08 -0400
X-Google-Sender-Auth: sJ3sFK4DxKfptRERUi0jCf-H3Nk
Message-ID: <CAMm+Lwh8-F0mwKJNYGHmwQP9Dw+7F4DsedveQy38T1G=k6QiWw@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: JSON WG <json@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c3421ca749cf051ec939a5
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/kCAn-cLn0PcKLLaXOfDtW6dTErE>
Subject: [Json] Secure JSON Procedure Call
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: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Sep 2015 20:08:12 -0000

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

Looking to see if there is interest in specifying a standard approach to
writing a secure RPC call mechanism using JSON as the encoding.

The key here is 'secure'. Every message must be authenticated and validated
in a consistent fashion. The idea being that at a certain layer of
abstraction, every protocol can be reduced to a caller API and a symmetric
dispatch class.

So for the mesh service I am just writing, I have a class:

    /// <summary>
/// The new base class for the client and service side APIs.
    /// </summary>
    public abstract partial class MeshService : Goedel.Protocol.JPCService {

        /// <summary>
        /// The caller session context.
        /// </summary>
        public JPCSession Session;

        /// <summary>
/// Base class for implementing the transaction.
        /// </summary>
        public virtual VersionResponse Version (
                VersionRequest Request) {
            var Response = new VersionResponse ();
            // Do stuff.
            return Response;
            }
        ...
        }

There is a client class that inherits from this and adds the bits a caller
needs on the caller side (i.e. identify the service to bind to, the account
and credential) and the bits that are needed on the server side (was the
message authenticated, what account is it bound to, what stream, etc.)

While this is very close to traditional RPC. As with the difference between
JSON and XML, what is thrown away is the important part.

SOAP was designed to provide an all-singing, all-dancing remote procedure
call for remotting COM objects over the Web. That might not be what people
thought they were trying to do but it was what they ended up doing. And a
lot of the complexity of the WS-* stack with SOAP, WSDL, WS-Security, etc.
all layering on top of each other come from the fact that this is a layer
that has to be transparent and invisible to the calling applications.


That is not how we write network protocols. Well, not good ones. The
'signature' (as in schema, not digital signature) of an API call and a
network protocol have a similar function but one describes a representation
in computer memory, the other describes a serialization to be sent on a
wire.

That has some important consequences. We don't really care about the
difference between int and Int32. Int64, UInt64, etc. in the network
version. All we care about is that we can represent the data we expect to
see comfortably in whatever language we choose to use and respond
gracefully otherwise.

Another big difference is that on the net, there is no difference between
an array and a list or a set.


Where XML RPC like things go wrong is that they are attempts to replicate
the in-memory representation of the data structure at another place. And
the in-memory data structure has a lot of material that is really not
suited to being replicated. We have pointers off to objects that haven't
been transmitted yet or may not be needed at all. An in-memory list is
likely indexed with some sort of hash dictionary for fast access. But on
the wire it is just a list. Rebuilding the index at the other end is easier
than sending it on the wire.


Anyone else thinking on these lines? I have some tools I am building and it
would be nice if we could get to some consistency.

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

<div dir=3D"ltr">Looking to see if there is interest in specifying a standa=
rd approach to writing a secure RPC call mechanism using JSON as the encodi=
ng.<div><br></div><div>The key here is &#39;secure&#39;. Every message must=
 be authenticated and validated in a consistent fashion. The idea being tha=
t at a certain layer of abstraction, every protocol can be reduced to a cal=
ler API and a symmetric dispatch class.</div><div><br></div><div>So for the=
 mesh service I am just writing, I have a class:</div><div><br></div><div><=
div>=C2=A0 =C2=A0 /// &lt;summary&gt;</div><div><span class=3D"" style=3D"w=
hite-space:pre">	</span>/// The new base class for the client and service s=
ide APIs.</div><div>=C2=A0 =C2=A0 /// &lt;/summary&gt;<span class=3D"" styl=
e=3D"white-space:pre">		</span></div><div>=C2=A0 =C2=A0 public abstract par=
tial class MeshService : Goedel.Protocol.JPCService {</div><div><br></div><=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 /// &lt;summary&gt;</div><div>=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 /// The caller session context.</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 /// &lt;/summary&gt;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 publi=
c JPCSession Session;</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
/// &lt;summary&gt;</div><div><span class=3D"" style=3D"white-space:pre">		=
</span>/// Base class for implementing the transaction.</div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 /// &lt;/summary&gt;<span class=3D"" style=3D"white-sp=
ace:pre">		</span></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 public virtual Ver=
sionResponse Version (</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 VersionRequest Request) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 var Response =3D new VersionResponse ();</div><div>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Do stuff.</div><div>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return Response;</div><div>=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 }</div></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<br>=
</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }</div><div><br></div><div>There is =
a client class that inherits from this and adds the bits a caller needs on =
the caller side (i.e. identify the service to bind to, the account and cred=
ential) and the bits that are needed on the server side (was the message au=
thenticated, what account is it bound to, what stream, etc.)</div><div><br>=
</div><div>While this is very close to traditional RPC. As with the differe=
nce between JSON and XML, what is thrown away is the important part.</div><=
div><br></div><div>SOAP was designed to provide an all-singing, all-dancing=
 remote procedure call for remotting COM objects over the Web. That might n=
ot be what people thought they were trying to do but it was what they ended=
 up doing. And a lot of the complexity of the WS-* stack with SOAP, WSDL, W=
S-Security, etc. all layering on top of each other come from the fact that =
this is a layer that has to be transparent and invisible to the calling app=
lications.</div><div><br></div><div><br></div><div>That is not how we write=
 network protocols. Well, not good ones. The &#39;signature&#39; (as in sch=
ema, not digital signature) of an API call and a network protocol have a si=
milar function but one describes a representation in computer memory, the o=
ther describes a serialization to be sent on a wire.</div><div><br></div><d=
iv>That has some important consequences. We don&#39;t really care about the=
 difference between int and Int32. Int64, UInt64, etc. in the network versi=
on. All we care about is that we can represent the data we expect to see co=
mfortably in whatever language we choose to use and respond gracefully othe=
rwise.</div><div><br></div><div>Another big difference is that on the net, =
there is no difference between an array and a list or a set.</div><div><br>=
</div><div><br></div><div>Where XML RPC like things go wrong is that they a=
re attempts to replicate the in-memory representation of the data structure=
 at another place. And the in-memory data structure has a lot of material t=
hat is really not suited to being replicated. We have pointers off to objec=
ts that haven&#39;t been transmitted yet or may not be needed at all. An in=
-memory list is likely indexed with some sort of hash dictionary for fast a=
ccess. But on the wire it is just a list. Rebuilding the index at the other=
 end is easier than sending it on the wire.</div><div><br></div><div><br></=
div><div>Anyone else thinking on these lines? I have some tools I am buildi=
ng and it would be nice if we could get to some consistency.</div><div><br>=
</div><div><br></div><div><br></div><div><br></div></div>

--001a11c3421ca749cf051ec939a5--


From nobody Tue Sep 29 14:53:43 2015
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 9AE6A1B5255 for <json@ietfa.amsl.com>; Tue, 29 Sep 2015 14:53:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 HlnSqqllE7IL for <json@ietfa.amsl.com>; Tue, 29 Sep 2015 14:53:41 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9681B5203 for <json@ietf.org>; Tue, 29 Sep 2015 14:53:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1572; q=dns/txt; s=iport; t=1443563621; x=1444773221; h=from:to:subject:date:message-id:mime-version; bh=FGQvBVETTDKVrZrOjWtWllVZP8i2WPPoUSqotY+5YDU=; b=i9E097fJy+jbD9ePnbqM11QbkDd7ROoCBUtyBZ6JZe812fOGhbb+a7Ax Va3Jpj0wpdX3dEAq1W4ZnUEul7YLU6dbC2nh13eD0Ddwj3bxybRhkzfXr vBibtbTBxEjJDvCgsMZnsuS3oaWJImqcikxYs4kN9C48KudIc0UW7uTku M=;
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DkBQDSBwtW/51dJa1EGoMkVGkGvWMOgXuHTjgUAQEBAQEBAX8LQQSDZoELAYEAJwQhiCANO6ZupE8BAQEBAQEEAQEBAQEBAQEBFQSJAosagRQFlXQBgkqBYWqHfZtDAR8BQ4QBcQGEZYMzgQUBAQE
X-IronPort-AV: E=Sophos;i="5.17,609,1437436800";  d="asc'?scan'208";a="191901183"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 29 Sep 2015 21:53:40 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t8TLrefw027075 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <json@ietf.org>; Tue, 29 Sep 2015 21:53:40 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 29 Sep 2015 16:53:40 -0500
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.000; Tue, 29 Sep 2015 16:53:39 -0500
From: "Matt Miller (mamille2)" <mamille2@cisco.com>
To: "json@ietf.org" <json@ietf.org>
Thread-Topic: Kicking Off JSONbis
Thread-Index: AQHQ+wFMLqPttJCICkCj26yPdE/GxA==
Date: Tue, 29 Sep 2015 21:53:39 +0000
Message-ID: <DB74C466-D542-42D6-95B0-690A564435A9@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-pgp-agent: GPGMail 2.5.2
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.129.24.119]
Content-Type: multipart/signed; boundary="Apple-Mail=_ACFDA40C-3E0E-4E5C-ACEB-206AAC4DF96E"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/ioTX6COmyM6hbJiUF-3qCMaXMhg>
Subject: [Json] Kicking Off JSONbis
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: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2015 21:53:42 -0000

--Apple-Mail=_ACFDA40C-3E0E-4E5C-ACEB-206AAC4DF96E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hello all,

Welcome to the JSONbis working group!

The WG charter is at < https://datatracker.ietf.org/wg/jsonbis/charter/ =
>.

In a nutshell, the goal of this effort is to produce a bis to 7159 that:

* promotes JSON to IETF Internet Standard
* references ECMA-404 and is a reference for ECMA-404

Tim Bray has agreed to edit 7159bis.

As a start, I propose we start with rfc7159 and:

1) Apply verified errata from < =
https://www.rfc-editor.org/errata_search.php?rfc=3D7159 >
2) Change the reference to ECMA-404 from informative to normative


-  JSONbis Chair


--Apple-Mail=_ACFDA40C-3E0E-4E5C-ACEB-206AAC4DF96E
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

iQEcBAEBCgAGBQJWCwhjAAoJEDWi+S0W7cO1RDsIAJrj6XJiBJ3TpRMnMNGqD0vX
mZRL4tVjOlRcHQeEKvljq1wL1E2RKYHRttqNRU3hiWm0BESOSsZMXyGCuApbPwtJ
uYWwGfDh3yEfe13Y7InIamXW6o8D0XppCDuAD1ZbGUkb2Oiiu3QfsEFE6dxR5Bdb
B3PWTAzt/p42+x+HYqxAWFJWzM89Y2UwugtHZmzoS2NTr4f0pZt8gew/kqgtRDPS
EaDyu7LUb6zS5GQ4taSFis0lBlCSF1+sNie4SXbhsJHP3XZRcLOC9wwtsE274/LA
3ZWkFe4yzMLra5+ec/PM92J5+sxSjKha/k7LvJZ01rKWwpJibKHFEnUNWhAJE0k=
=SkIk
-----END PGP SIGNATURE-----

--Apple-Mail=_ACFDA40C-3E0E-4E5C-ACEB-206AAC4DF96E--


From nobody Tue Sep 29 15:10:48 2015
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 9F46A1B53B4 for <json@ietfa.amsl.com>; Tue, 29 Sep 2015 15:10:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.349
X-Spam-Level: 
X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35] 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 MdVKVfdGe2cg for <json@ietfa.amsl.com>; Tue, 29 Sep 2015 15:10:45 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22DEA1B53B1 for <json@ietf.org>; Tue, 29 Sep 2015 15:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t8TMAcmK012079; Wed, 30 Sep 2015 00:10:38 +0200 (CEST)
Received: from alma.local (p5DC7F6AE.dip0.t-ipconnect.de [93.199.246.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nQZfQ28qwz4pSp; Wed, 30 Sep 2015 00:10:38 +0200 (CEST)
Message-ID: <560B0C5C.2060807@tzi.org>
Date: Wed, 30 Sep 2015 00:10:36 +0200
From: Carsten Bormann <cabo@tzi.org>
User-Agent: Postbox 4.0.5 (Macintosh/20150923)
MIME-Version: 1.0
To: "Matt Miller (mamille2)" <mamille2@cisco.com>
References: <DB74C466-D542-42D6-95B0-690A564435A9@cisco.com>
In-Reply-To: <DB74C466-D542-42D6-95B0-690A564435A9@cisco.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/ud6MfsFBXbSLdoeGhCKNyWST3bk>
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Kicking Off JSONbis
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: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2015 22:10:46 -0000

Matt Miller (mamille2) wrote:
> 2) Change the reference to ECMA-404 from informative to normative

Maybe you can say a bit more about this cross-referencing business.

Right now, I don't need to follow railroad tracks to implement JSON.
Will the normative reference to ECMA-404 change that?
How will the differences in coverage be resolved?

Grüße, Carsten


From nobody Tue Sep 29 15:41:05 2015
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 029AE1B3448 for <json@ietfa.amsl.com>; Tue, 29 Sep 2015 15:41:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ZuPq7HqbA2Dc for <json@ietfa.amsl.com>; Tue, 29 Sep 2015 15:41:02 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD7F1B3443 for <json@ietf.org>; Tue, 29 Sep 2015 15:41:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2163; q=dns/txt; s=iport; t=1443566462; x=1444776062; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aHTMahhSzbjRi/jI3K12g/cT2U0XiA6Ri26edG0msNQ=; b=HIOGzLJ05aCxVu6K2jsQ1hPjjiJXC7EODs5FCHB8/VpqMCbnqT1FSw1L QoSp7ZwIbJZAsX3f2Rq9BgACGGXvgaKarTqGRlXSEtQ0RzABpR7fp+iZX 5dOU9ZfrHvYOvDqm/M3xcpSsDWTkl5vvrVMw9XuX8lNPpHynozAUEwbU5 Q=;
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CoAgCeEgtW/49dJa1egySBPQa9Yw6HdAKBUzgUAQEBAQEBAYEKhCQBAQEDASNWBQsCAQYCDgoqAgIyJQIEDgUOiBgImW+dLJRqAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4kCgm6FDQeCaS+BFAEEhzeKeINFAYJKgWGIZ4odkSYBHwFDhAFxiBmBBQEBAQ
X-IronPort-AV: E=Sophos;i="5.17,609,1437436800";  d="asc'?scan'208";a="192925501"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP; 29 Sep 2015 22:41:01 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t8TMf1kJ006106 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 29 Sep 2015 22:41:01 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 29 Sep 2015 17:41:00 -0500
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.000; Tue, 29 Sep 2015 17:41:00 -0500
From: "Matt Miller (mamille2)" <mamille2@cisco.com>
To: Carsten Bormann <cabo@tzi.org>
Thread-Topic: [Json] Kicking Off JSONbis
Thread-Index: AQHQ+wFNtMRdQTHPQkS2mYrhXeCPSJ5UZSQAgAAIfgA=
Date: Tue, 29 Sep 2015 22:41:00 +0000
Message-ID: <54B074D6-D16F-4A65-ACF2-985095AE30D0@cisco.com>
References: <DB74C466-D542-42D6-95B0-690A564435A9@cisco.com> <560B0C5C.2060807@tzi.org>
In-Reply-To: <560B0C5C.2060807@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-pgp-agent: GPGMail 2.5.2
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.129.24.119]
Content-Type: multipart/signed; boundary="Apple-Mail=_9FD2F58A-FECA-44D7-8764-2B3222922D62"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/NBsOZVm6YcMvVl_yDflQYMhbd4U>
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Kicking Off JSONbis
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: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2015 22:41:04 -0000

--Apple-Mail=_9FD2F58A-FECA-44D7-8764-2B3222922D62
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Sep 29, 2015, at 16:10, Carsten Bormann <cabo@tzi.org> wrote:
>=20
> Matt Miller (mamille2) wrote:
>> 2) Change the reference to ECMA-404 from informative to normative
>=20
> Maybe you can say a bit more about this cross-referencing business.
>=20
> Right now, I don't need to follow railroad tracks to implement JSON.
> Will the normative reference to ECMA-404 change that?
> How will the differences in coverage be resolved?
>=20
> Gr=C3=BC=C3=9Fe, Carsten

The IETF-to-Ecma Liaison Manager[*] will be helping to coordinate with =
Ecma TC39 editors.  It may be some text talking about the racetracks, or =
it may be something more.  The details do need to be worked out.

/me doffs hat

ECMA-404 is concerned about the model, and 7159bis can be focused on =
what that means on the wire.  I can see pointing slightly more into =
ECMA-404 on syntax, and the dragons that the original effort documented =
remaining in 7159bis.  Personally, I don't see the ABNF being removed =
from 7159bis, since that definitely impacts what's on the wire.


--
- m&m

Matt Miller <mamille2@cisco.com>
Cisco Systems, Inc.

[*] Who is also the JSONbis WG Chair

--Apple-Mail=_9FD2F58A-FECA-44D7-8764-2B3222922D62
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

iQEcBAEBCgAGBQJWCxN9AAoJEDWi+S0W7cO1F6oIAKpm/jjPRIQr47zko07ip056
kEsb7WSdUbT2Xsh9aIRy4sJPQ9ulNNojAgQugcl9GtiTkSi56LxfsT8MRF3E2aO+
/9RcAIzSkDr5xqnFSyf5Mg5Do8ZxAELJoAFPzssCn6Xbfqlja04cAWahT0C4kNDY
ptPNqNo3+dsKo6YuqnsXdoTtwuA64TO6kzUawg/rxvNI8TaMLSogs0WWRHd3zSRA
wXJufpR+X/B6NCLLn9jEEzjBMIbjInKp8gxAz82PtRBceZcGNYBN9x7G/armSyFf
bIKQjDRbT5sEXGdoFLqBHFVS7UX54XULbCDNlWCLuu1X3LYtgLJWTs58t9cQO+c=
=Lf4X
-----END PGP SIGNATURE-----

--Apple-Mail=_9FD2F58A-FECA-44D7-8764-2B3222922D62--


From nobody Tue Sep 29 19:22:28 2015
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 933571B597C for <json@ietfa.amsl.com>; Tue, 29 Sep 2015 19:22:27 -0700 (PDT)
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 XSXT4oPSGoDz for <json@ietfa.amsl.com>; Tue, 29 Sep 2015 19:22:23 -0700 (PDT)
Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498FA1B5982 for <json@ietf.org>; Tue, 29 Sep 2015 19:22:23 -0700 (PDT)
Received: by ioii196 with SMTP id i196so32292841ioi.3 for <json@ietf.org>; Tue, 29 Sep 2015 19:22:22 -0700 (PDT)
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=5LRuBCj6c6ZUqnRdTVdDbtcOVJ8B5M2g8PCd4hWjGko=; b=RDEt2k/LEEJAPNuSbWoAYVrKMHpCyHw8gBg7n6JaryVjo6pkj8dw4ui0NNNHnD10ad qD6oTD39Om0RxlE7fmIiqSms5jaxPr+rLkZL8qtPf8rhh0Pnto0PSaHI/AHySMyrUqGq UoR8Dskl94FV2V8KzbyuYrAYLX1bLuAnatkt6/G6AoPXD5SGih70IVL++9759+46YMl6 C2Voqin7NuVDc+OlT67MlaLXY+2sHtDX8+y1vmrBgsLv0W9MAcRlJPWG/rWm78ZpCuiI /cXDSF1WouSJVOxiy0xpTspfaM8og9ZFlkz+7fxZ2PvFm0ulkpNzmsjOMs77H5PCPbWM AQog==
X-Gm-Message-State: ALoCoQm95QZeOtsAh3R6npyKVrOk76uOaV8qDdWfedwtCDS+DN3Tuk8mLjJL9gvId7eUtBZLAfkg
X-Received: by 10.107.163.204 with SMTP id m195mr2273183ioe.65.1443579742476;  Tue, 29 Sep 2015 19:22:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.30.4 with HTTP; Tue, 29 Sep 2015 19:22:03 -0700 (PDT)
X-Originating-IP: [24.84.248.61]
In-Reply-To: <DB74C466-D542-42D6-95B0-690A564435A9@cisco.com>
References: <DB74C466-D542-42D6-95B0-690A564435A9@cisco.com>
From: Tim Bray <tbray@textuality.com>
Date: Tue, 29 Sep 2015 19:22:03 -0700
Message-ID: <CAHBU6iuoYwK31Kd0qudGvuUUkofc0bYag3hdJBojmHvy6P2HgQ@mail.gmail.com>
To: "Matt Miller (mamille2)" <mamille2@cisco.com>
Content-Type: multipart/alternative; boundary=001a1140fb70c18ef20520ed9941
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/Qid4jSLvAFxVKpFYzJWrFRAisZ8>
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Kicking Off JSONbis
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: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 02:22:27 -0000

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

On Tue, Sep 29, 2015 at 2:53 PM, Matt Miller (mamille2) <mamille2@cisco.com=
>
wrote:
=E2=80=8B=E2=80=8B


> =E2=80=8B=E2=80=8B
> * references ECMA-404 and is a reference for ECMA-404
>
=E2=80=8B=E2=80=8B
I note that RFC7159 already has an informative reference to ECMA-404. I
take it that the proposal is to have a normative reference?  Query: is the
reference on normative vs informative
https://www.ietf.org/iesg/statement/normative-informative.html
authoritative?

Quoting from that document: =E2=80=9CNormative references specify documents=
 that
must be read to understand or implement the technology in the new RFC, or
whose technology must be present for the technology in the new RFC to work.=
=E2=80=9D

I=E2=80=99d like to hear some reasoning on how ECMA-404 meets either of tho=
se
criteria.

[Yes, I agreed to edit.  While I=E2=80=99m highly unconvinced on the merits=
 of
7159bis approach, if the WG chooses to move ahead with this plan, I=E2=80=
=99ll put
the angle brackets in the right places.]

--=20
- Tim Bray (If you=E2=80=99d like to send me a private message, see
https://keybase.io/timbray)

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">On =
Tue, Sep 29, 2015 at 2:53 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><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><div><div class=3D"gmail_default" style=3D"font-size:small;displa=
y:inline">=E2=80=8B=E2=80=8B</div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=3D"gmail_default" style=3D"font-size:small;display:inline">=E2=
=80=8B=E2=80=8B</div>* references ECMA-404 and is a reference for ECMA-404<=
br></blockquote><div><div class=3D"gmail_default" style=3D"font-size:small"=
>=E2=80=8B=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-size:sm=
all">I note that RFC7159 already has an informative reference to ECMA-404. =
I take it that the proposal is to have a normative reference?=C2=A0 Query: =
is the reference on normative vs informative=C2=A0<a href=3D"https://www.ie=
tf.org/iesg/statement/normative-informative.html">https://www.ietf.org/iesg=
/statement/normative-informative.html</a> authoritative?<br></div></div><di=
v><div class=3D"gmail_default" style=3D"font-size:small"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-size:small">Quoting from that document: =
=E2=80=9C<span style=3D"color:rgb(0,0,0);font-family:Verdana,Arial,Helvetic=
a,sans-serif;font-size:12.6666669845581px">Normative references specify doc=
uments that must be read to understand or implement the technology in the n=
ew RFC, or whose technology must be present for the technology in the new R=
FC to work.=E2=80=9D</span></div><div class=3D"gmail_default" style=3D"font=
-size:small"><span style=3D"color:rgb(0,0,0);font-family:Verdana,Arial,Helv=
etica,sans-serif;font-size:12.6666669845581px"><br></span></div><div class=
=3D"gmail_default"><font color=3D"#000000" face=3D"Verdana, Arial, Helvetic=
a, sans-serif"><span style=3D"font-size:12.6666669845581px">I=E2=80=99d lik=
e to hear some reasoning on how ECMA-404 meets either of those criteria.</s=
pan></font></div><div class=3D"gmail_default" style=3D"font-size:small"><br=
></div><div class=3D"gmail_default" style=3D"font-size:small">[Yes, I agree=
d to edit.=C2=A0 While I=E2=80=99m highly unconvinced on the merits of 7159=
bis approach, if the WG chooses to move ahead with this plan, I=E2=80=99ll =
put the angle brackets in the right places.]</div></div></div><div><br></di=
v>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div>- Tim Bray (I=
f you=E2=80=99d like to send me a private message, see <a href=3D"https://k=
eybase.io/timbray" target=3D"_blank">https://keybase.io/timbray</a>)</div><=
/div></div>
</div></div>

--001a1140fb70c18ef20520ed9941--


From nobody Tue Sep 29 22:29:47 2015
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 748131B5C4D for <json@ietfa.amsl.com>; Tue, 29 Sep 2015 22:29:45 -0700 (PDT)
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] 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 xDgOuEGRiskU for <json@ietfa.amsl.com>; Tue, 29 Sep 2015 22:29:44 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2D91B5C53 for <json@ietf.org>; Tue, 29 Sep 2015 22:29:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t8U5TbRi004955; Wed, 30 Sep 2015 07:29:37 +0200 (CEST)
Received: from alma.local (p5DC7F6AE.dip0.t-ipconnect.de [93.199.246.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nQmNx2whRz4pQV; Wed, 30 Sep 2015 07:29:37 +0200 (CEST)
Message-ID: <560B72F4.8030307@tzi.org>
Date: Wed, 30 Sep 2015 07:28:20 +0200
From: Carsten Bormann <cabo@tzi.org>
User-Agent: Postbox 4.0.5 (Macintosh/20150923)
MIME-Version: 1.0
To: "Matt Miller (mamille2)" <mamille2@cisco.com>
References: <DB74C466-D542-42D6-95B0-690A564435A9@cisco.com> <560B0C5C.2060807@tzi.org> <54B074D6-D16F-4A65-ACF2-985095AE30D0@cisco.com>
In-Reply-To: <54B074D6-D16F-4A65-ACF2-985095AE30D0@cisco.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/5r45Si1oASnVu3mZyKbYPPXmWBA>
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Kicking Off JSONbis
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: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 05:29:45 -0000

Matt Miller (mamille2) wrote:
> ECMA-404 is concerned about the model

That is an interesting assessment.
If you are talking about the data model, my impression was that ECMA-404
(unsuccessfully) attempted to rid itself of considerations about the
data model.  But I'm not an expert on ECMA-404 exegesis.

Grüße, Carsten


From nobody Tue Sep 29 23:44:05 2015
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 6C9C41A024E for <json@ietfa.amsl.com>; Tue, 29 Sep 2015 23:44:03 -0700 (PDT)
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 MXCu4odCOmnA for <json@ietfa.amsl.com>; Tue, 29 Sep 2015 23:44:01 -0700 (PDT)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04071A0217 for <json@ietf.org>; Tue, 29 Sep 2015 23:44:01 -0700 (PDT)
Received: by igcrk20 with SMTP id rk20so95007833igc.1 for <json@ietf.org>; Tue, 29 Sep 2015 23:44:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aqH1eNlzJgDEaQOOQi2waXuag0ay5gOTvdFwNxmx48g=; b=V63K3HRxF8SH8biuOF7p6qr2glUZIgFQtB6x43XUdWw7TsepBEqDm9LljlrHEjY4Zx tfucC5L2N8pqG+fG8uCRqZO23MnobiEN8Lu+JmisGmyYGB+zSxen4Extky0H/uPTorrs GzV2aI9ZXWViPaVhxC4IBR73uhfK/O9v0M+mBq64Zeq59QMxW/hjlCqRGie4TNWt4zmm 4/L5ckUyNImX5A3feRDyYdVngCV+V1nBjlOYXmz67wdGvQYDugcTeRvOLusCwILd8hpp YECKuFr9ZbdWKDIR6KQme1dQmb31Cfxi3kJFqfOHg/Y9miJMbPTiyPoFNHpnI8r5KjGz FTxQ==
MIME-Version: 1.0
X-Received: by 10.50.43.170 with SMTP id x10mr2896447igl.12.1443595441199; Tue, 29 Sep 2015 23:44:01 -0700 (PDT)
Received: by 10.107.184.67 with HTTP; Tue, 29 Sep 2015 23:44:01 -0700 (PDT)
In-Reply-To: <CAHBU6iuoYwK31Kd0qudGvuUUkofc0bYag3hdJBojmHvy6P2HgQ@mail.gmail.com>
References: <DB74C466-D542-42D6-95B0-690A564435A9@cisco.com> <CAHBU6iuoYwK31Kd0qudGvuUUkofc0bYag3hdJBojmHvy6P2HgQ@mail.gmail.com>
Date: Tue, 29 Sep 2015 23:44:01 -0700
Message-ID: <CAChr6Syi3v8jWark294pMGB=HDt9bEco=vCQAvcTmrnxrk0xSQ@mail.gmail.com>
From: Rob Sayre <sayrer@gmail.com>
To: Tim Bray <tbray@textuality.com>
Content-Type: multipart/alternative; boundary=089e01176cad78e0d50520f14170
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/RnY2-UCJWMZJ32T0C2Uj1oEJVv4>
Cc: "json@ietf.org" <json@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>
Subject: Re: [Json] Kicking Off JSONbis
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: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 06:44:03 -0000

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

On Tue, Sep 29, 2015 at 7:22 PM, Tim Bray <tbray@textuality.com> wrote:

> On Tue, Sep 29, 2015 at 2:53 PM, Matt Miller (mamille2) <
> mamille2@cisco.com> wrote:
> =E2=80=8B=E2=80=8B
>
>
>> =E2=80=8B=E2=80=8B
>> * references ECMA-404 and is a reference for ECMA-404
>>
> =E2=80=8B=E2=80=8B
> I note that RFC7159 already has an informative reference to ECMA-404. I
> take it that the proposal is to have a normative reference?  Query: is th=
e
> reference on normative vs informative
> https://www.ietf.org/iesg/statement/normative-informative.html
> authoritative?
>
> Quoting from that document: =E2=80=9CNormative references specify documen=
ts that
> must be read to understand or implement the technology in the new RFC, or
> whose technology must be present for the technology in the new RFC to wor=
k.=E2=80=9D
>
> I=E2=80=99d like to hear some reasoning on how ECMA-404 meets either of t=
hose
> criteria.
>
> [Yes, I agreed to edit.  While I=E2=80=99m highly unconvinced on the meri=
ts of
> 7159bis approach, if the WG chooses to move ahead with this plan, I=E2=80=
=99ll put
> the angle brackets in the right places.]
>

To me, it seems like a political or diplomatic gesture that helps the
Internet to move forward.

Framing it in technical or standards-wonk terms seems counterproductive. I
don't think there are substantive issues in those areas that would be
resolved by objecting to the plan in the charter.

- Rob

--089e01176cad78e0d50520f14170
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=
ue, Sep 29, 2015 at 7:22 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><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 dir=3D"ltr"><span class=3D""><div style=
=3D"font-size:small">On Tue, Sep 29, 2015 at 2:53 PM, Matt Miller (mamille2=
) <span dir=3D"ltr">&lt;<a href=3D"mailto:mamille2@cisco.com" target=3D"_bl=
ank">mamille2@cisco.com</a>&gt;</span> wrote:<br></div></span><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><div><div style=
=3D"font-size:small;display:inline">=E2=80=8B=E2=80=8B</div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex">
<div style=3D"font-size:small;display:inline">=E2=80=8B=E2=80=8B</div>* ref=
erences ECMA-404 and is a reference for ECMA-404<br></blockquote></span><di=
v><div style=3D"font-size:small">=E2=80=8B=E2=80=8B</div><div style=3D"font=
-size:small">I note that RFC7159 already has an informative reference to EC=
MA-404. I take it that the proposal is to have a normative reference?=C2=A0=
 Query: is the reference on normative vs informative=C2=A0<a href=3D"https:=
//www.ietf.org/iesg/statement/normative-informative.html" target=3D"_blank"=
>https://www.ietf.org/iesg/statement/normative-informative.html</a> authori=
tative?<br></div></div><div><div style=3D"font-size:small"><br></div><div s=
tyle=3D"font-size:small">Quoting from that document: =E2=80=9C<span style=
=3D"color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;font-si=
ze:12.6667px">Normative references specify documents that must be read to u=
nderstand or implement the technology in the new RFC, or whose technology m=
ust be present for the technology in the new RFC to work.=E2=80=9D</span></=
div><div style=3D"font-size:small"><span style=3D"color:rgb(0,0,0);font-fam=
ily:Verdana,Arial,Helvetica,sans-serif;font-size:12.6667px"><br></span></di=
v><div><font color=3D"#000000" face=3D"Verdana, Arial, Helvetica, sans-seri=
f"><span style=3D"font-size:12.6667px">I=E2=80=99d like to hear some reason=
ing on how ECMA-404 meets either of those criteria.</span></font></div><div=
 style=3D"font-size:small"><br></div><div style=3D"font-size:small">[Yes, I=
 agreed to edit.=C2=A0 While I=E2=80=99m highly unconvinced on the merits o=
f 7159bis approach, if the WG chooses to move ahead with this plan, I=E2=80=
=99ll put the angle brackets in the right places.]</div></div></div></div><=
/div></blockquote><div><br></div><div class=3D"gmail_extra" style=3D"font-s=
ize:12.8px">To me, it seems like a political or diplomatic gesture that hel=
ps the Internet to move forward.</div><div class=3D"gmail_extra" style=3D"f=
ont-size:12.8px"><br></div><div class=3D"gmail_extra" style=3D"font-size:12=
.8px">Framing it in technical or standards-wonk terms seems counterproducti=
ve. I don&#39;t think there are substantive issues in those areas that woul=
d be resolved by objecting to the plan in the charter.</div><div class=3D""=
 style=3D"font-size:12.8px"></div><div><br></div><div>- Rob=C2=A0</div></di=
v></div></div>

--089e01176cad78e0d50520f14170--


From nobody Wed Sep 30 00:00:57 2015
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 E4A041A0AF8 for <json@ietfa.amsl.com>; Wed, 30 Sep 2015 00:00:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 aE1MH1zgfpPH for <json@ietfa.amsl.com>; Wed, 30 Sep 2015 00:00:54 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76AD11A066B for <json@ietf.org>; Wed, 30 Sep 2015 00:00:54 -0700 (PDT)
Received: from [192.168.178.20] ([84.187.51.65]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M6jIK-1adQo946Fw-00wWsQ; Wed, 30 Sep 2015 09:00:50 +0200
To: Rob Sayre <sayrer@gmail.com>, Tim Bray <tbray@textuality.com>
References: <DB74C466-D542-42D6-95B0-690A564435A9@cisco.com> <CAHBU6iuoYwK31Kd0qudGvuUUkofc0bYag3hdJBojmHvy6P2HgQ@mail.gmail.com> <CAChr6Syi3v8jWark294pMGB=HDt9bEco=vCQAvcTmrnxrk0xSQ@mail.gmail.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <560B88A1.3010007@gmx.de>
Date: Wed, 30 Sep 2015 09:00:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CAChr6Syi3v8jWark294pMGB=HDt9bEco=vCQAvcTmrnxrk0xSQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:Rv+EhWmTp28/Ah/N8zRr1N5rekNe8R8In6y0w14eU5ZVI4kwF4y QsL0YmiB+4OQg+mPgOiy4oeMKX5hP7PygZMRdFQDeK1fQg9hVd+yV6DAxUxNR8GgEvXuARS S20u5EtDZIUrFPObyPvzuUazsRttfgGH85i9V0MxFKEGbB4gs3vKXHypKniINJvWrVAortx KadsEZ6EeDjEjzbjhfY4g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:IfjPTbNYEU0=:3ALnYNYykfNwGQK2d9S5di HLAT0aRVBgle3soKMZxLRJTqs6rDufpY3RqvkMw/oiJVm4cNVL3zqjEnJlaTaPqD8IgIrSSrw toXF09pBcp/EeNQjkPKfmTAfVjc3P0H0xmCDhl7fo4aCiUdrnopMF+hSCvtm8EE3JpFo9XSRM IJsrd8jmHyuusv/fjv8VYmz9yDC53KlOBuucNWofroBVQ6Z8bxCGfTd2cCS+ztB0d+cXw59Pq ztJiwiiip2DdQvuS9VoIZedrxpmKVEGn/aNaKlp1v6ZuvNJ2FiBUAyaTnr3pCQCYwTnHr0D4E u34zDScAUwKqDD1wa05aQQgWsBjYJV7OW4amMPiVfzSTCad8gjOanrA/FbTmFdWMfvdYj4n0X SxBtOxwQ4QBvjlYWpnc9wRe47NlBpTqnf3dlXivpERv94zS1YLPkq5cNXNbt0gxF6yaOsKmVP C9Y76sLolr/JF8kK7zz/aK78XBypxVZVMMMncwBOLv8OtyDW8bBdVlt7Wncqhi48g+0CciV41 uVUM7G0eh4/MTFqyDw12F0R7N428ViSREGTRxwRfEraqghcUgCtG58OoZoGaEQRY9q1mtgUsf fO4kv+BeCUWIxhs+iY1WQAykndOXnO0Gs8WstTvwmHFOyRNB0Dr3481PtuSSJav/MCkNWpEAg BU1qY/56jAjfpjQbaqUWI+77KjKBVLvlg0hs+lZWMLK7WeuuEYtpjZjxJXdc8emUjfjb1ndEp BN1/JIkvFWhv7rwkFBj5C504d1aUvDVwFIJxKaMRc8RSYb/Ut/z4GOe3D4UXEthVyYXYIgsAl onGx7Gc
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/MSf_UF8yci7PTOPCWuiRm9HNGgg>
Cc: "Matt Miller \(mamille2\)" <mamille2@cisco.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Kicking Off JSONbis
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: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 07:00:56 -0000

On 2015-09-30 08:44, Rob Sayre wrote:
 > ...
 > To me, it seems like a political or diplomatic gesture that helps the
 > Internet to move forward.

Right.

 > Framing it in technical or standards-wonk terms seems counterproductive.
 > I don't think there are substantive issues in those areas that would be
 > resolved by objecting to the plan in the charter.
 > ...

But then the charter doesn't mention the suggested change explicitly.

Best regards, Julian


From nobody Wed Sep 30 18:27:53 2015
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 5E7E61ACE25 for <json@ietfa.amsl.com>; Wed, 30 Sep 2015 18:27:52 -0700 (PDT)
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 h1xMbjNalLMF for <json@ietfa.amsl.com>; Wed, 30 Sep 2015 18:27:51 -0700 (PDT)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4CE1ACE24 for <json@ietf.org>; Wed, 30 Sep 2015 18:27:50 -0700 (PDT)
Received: by igxx6 with SMTP id x6so4343891igx.1 for <json@ietf.org>; Wed, 30 Sep 2015 18:27:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=Zjb5ajZJXBEO/XZYLDdslwz7q7Wz8a9IXBtvmwn26L4=; b=qurrzXjoKziLtwBHcxwf+BA+1ymIoKmuDXw2hvVqVHBxKL5rX/sJOXKWZzy611jwBt +BrpO4weQNP0PH5zDD3+o8O5ch1byp1brlkqBa3KQIgQyTdxYN+Vn2TdV+Br3T4pS5Bq TDQi1jJ5YnnbsvUdLFaMcPtAvpiYM4oBI8hArK+tZ6s/4aN7rJEoiHCCukDei5oE6y/y 3UhYFRzGvIW8o/a5wvgy9ujqpJqEX2VN8gnjEU7k7Q6M73vhMcD4ihVIW6e2bYms+H/i Tpr0PMz1gQ+yieqsBcVyr3wNpO/oBqc5zmwTLtoQLV7QXe6G110iB5QobqrU8HyeqWnD I8kA==
X-Received: by 10.50.79.167 with SMTP id k7mr394343igx.67.1443662870163; Wed, 30 Sep 2015 18:27:50 -0700 (PDT)
Received: from idefix.nuance.com ([184.151.36.114]) by smtp.gmail.com with ESMTPSA id e19sm222198igo.14.2015.09.30.18.27.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Sep 2015 18:27:49 -0700 (PDT)
To: "Matt Miller (mamille2)" <mamille2@cisco.com>, "json@ietf.org" <json@ietf.org>
References: <DB74C466-D542-42D6-95B0-690A564435A9@cisco.com>
From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
X-Enigmail-Draft-Status: N0000
Message-ID: <560C8C12.2010805@gmail.com>
Date: Wed, 30 Sep 2015 18:27:46 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <DB74C466-D542-42D6-95B0-690A564435A9@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/z8p1MrPG7TOps8tqQoOvXSsClW8>
Subject: Re: [Json] Kicking Off JSONbis
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: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2015 01:27:52 -0000

On 09/29/2015 02:53 PM, Matt Miller (mamille2) wrote:
> Hello all,
> 
> Welcome to the JSONbis working group!
> 
> The WG charter is at < https://datatracker.ietf.org/wg/jsonbis/charter/
> >.
> 
> In a nutshell, the goal of this effort is to produce a bis to 7159 that:
> 
> * promotes JSON to IETF Internet Standard * references ECMA-404 and is a
> reference for ECMA-404
> 
> Tim Bray has agreed to edit 7159bis.
> 
> As a start, I propose we start with rfc7159 and:
> 
> 1) Apply verified errata from <
> https://www.rfc-editor.org/errata_search.php?rfc=7159 > 2) Change the
> reference to ECMA-404 from informative to normative
> 
> 
> -  JSONbis Chair

I must admit that I am puzzled as to how ECMA-404 can be a normative
reference for any document that is a minor change from rfc7159.  What in
ECMA-404 is needed to understand or implement what is in rfc7159?

As has been stated, rfc7159 already references ECMA-404.  A conservative way
to make a closer connection from rfc7159 to ECMA-404 would be to state that
ECMA-404 has an alternative description of JSON that is extremely close to
the definition in rfc7159.

Peter F. Patel-Schneider
Nuance Communications