Re: [Json] Two Documents

"Joe Hildebrand (jhildebr)" <jhildebr@cisco.com> Wed, 19 June 2013 15:00 UTC

Return-Path: <jhildebr@cisco.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CDD21F9C03 for <json@ietfa.amsl.com>; Wed, 19 Jun 2013 08:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level:
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9aFPvqlMZg6 for <json@ietfa.amsl.com>; Wed, 19 Jun 2013 08:00:24 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id ED9A121F9C9E for <json@ietf.org>; Wed, 19 Jun 2013 08:00:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3230; q=dns/txt; s=iport; t=1371654024; x=1372863624; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=JRsk7eXHiKeYSyRELmC2zVsgt9VjQRMKBBR0Dq1mtWs=; b=FxLsknJu6ek/Sk1iMNSDeutMNXFBw6QFa4TRDYo8ktCnsSSzykMiUFq6 3vcxYnEX+DPPpx8ADF6hM75r1Ez/eDnzioEOzQ6sbMAg/NSElw6o285Yi zqZp8CceGR6K9mWt5VToCpQFhaTXcv/W25xD7WDnUGtjKUczUTfQgzMwX A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnMFAJrGwVGtJV2Z/2dsb2JhbABagwkxSb8bgQAWdIIjAQEBBAEBAWsLEgEIDgoKSwslAgQBDQUIiAYMu0kEjw8CMQeDAGEDiGiLB5UWgw+CKA
X-IronPort-AV: E=Sophos;i="4.87,896,1363132800"; d="scan'208";a="224906673"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 19 Jun 2013 15:00:23 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5JF0N2N028733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 15:00:23 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 19 Jun 2013 10:00:22 -0500
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: Tim Bray <tbray@textuality.com>, Douglas Crockford <douglas@crockford.com>
Thread-Topic: [Json] Two Documents
Thread-Index: AQHObJG5Rm5370xVp0OPDNBuVIl6G5k9bpOA//+i9AA=
Date: Wed, 19 Jun 2013 15:00:22 +0000
Message-ID: <A723FC6ECC552A4D8C8249D9E07425A70FC5A4C1@xmb-rcd-x10.cisco.com>
In-Reply-To: <CAHBU6isgo-pLBUHM-6ix3eChD4khMgFBEyf6pDYzU3-oteAD=g@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.4.130416
x-originating-ip: [10.129.24.242]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <6E38EC419DD0B0478ACA2CDF28247B13@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Matt Miller \(mamille2\)" <mamille2@cisco.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Two Documents
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Jun 2013 15:00:31 -0000

I agree with Tim.  I think we can make it crystal clear with wording and
structural changes at what point a person that already has a stream of
codepoints (rather than a stream of octets) starts implementing.

Of course, I want to make sure we don't *prohibit* more performant
processors that both decode and parse in one pass, but that won't work for
JSON.parse unless ECMA allows JSON.parse to also take a typed array in
addition to a string or adds JSON.parseBuffer.


On 6/19/13 8:33 AM, "Tim Bray" <tbray@textuality.com> wrote:

>Let¹s take a moment to consider who our audience is.  The RFC will be
>used almost exclusively by JSON parser and generator implementors. Out in
>the general population of JSON users, the only docs they look at are the
>docs for the parser/generator library
> they¹re using.
>
>
>And if I¹m an implementor writing a JSON parser or generator, well, yeah,
>I care about the abstract grammar and the security issues, but I also
>care about what the incoming sequence of bytes is going to look like, and
>what the outgoing sequence of bytes needs
> to look like.
>
>
>So I think it would be abusive to our customers to make them read two
>documents to get their jobs done.  I¹m scratching my head to think of
>anyone who would read one of these documents but not the other, and I¹m
>coming up empty.
>
>
> -Tim
>
>
>
>On Tue, Jun 18, 2013 at 7:06 PM, Douglas Crockford
><douglas@crockford.com> wrote:
>
>On 6/17/2013 5:14 PM, Matt Miller (mamille2) wrote:
>
>Hello Douglas,
>
>In order for the WG to fully understand your proposal, we need a more
>definitive list of what to expect in each document.
>
>As a starting point, can you describe which sections of the current
>RFC4627 would be in "JSON Data Interchange Format" and which would be in
>the JSON best practices document?  Clearly the latter will have many
>additions from the recent discussions, but it is
> less clear which portions of the current text goes into which document.
>
>
>
>
>Please excuse the lateness of this reply. I am traveling.
>
>I am proposing that The JSON Data Interchange Format document contain
>only the material that is universal to all applications of JSON. So, for
>example, the only dependency on any character encoding is the
>interpretation of the four hex digits in the \u notation,
> where Unicode determines the meaning of the numbers.
>
>It includes an abstract, an introduction, the detailing of the elements
>(object, array, string, etc), and security considerations. No parsers or
>generators, no octets, no MIME types.
>
>This provides a standard description of JSON that all other standards and
>practices may refer to. I think this is the standard that ECMA wants to
>publish.
>
>We can then consider other documents that constrain or interpret JSON for
>specific purposes. The poorly named application/json is one. JSON as a
>file format, JSON as a streaming format, and JSON as an embedded data
>representation are others.
>
>_______________________________________________
>json mailing list
>json@ietf.org
>https://www.ietf.org/mailman/listinfo/json
>
>
>
>
>
>
>
>


-- 
Joe Hildebrand