Re: [Json] Proposed document set from this WG

"Joe Hildebrand (jhildebr)" <jhildebr@cisco.com> Wed, 20 February 2013 16:51 UTC

From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>, R S <sayrer@gmail.com>
Thread-Topic: [Json] Proposed document set from this WG
Thread-Index: AQHODzYd4GSxDud/oEmpRv3zklbNKpiDUnUA//+TRwA=
Date: Wed, 20 Feb 2013 16:51:05 +0000
Message-ID: <A723FC6ECC552A4D8C8249D9E07425A70F89AF14@xmb-rcd-x10.cisco.com>
In-Reply-To: <734F6B55-2AA7-44A6-A636-7221C8518479@vpnc.org>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.1.130117
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7BDEBE6F9B041740A2B85A531BA0DCFB@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Proposed document set from this WG
Precedence: list

+1, with one caveat.  What if we find ECMAScript 5 and 4627 to be in
conflict in some way?

In particular, I find:

15.12: "Conforming implementations of JSON.parse and JSON.stringify must
support the exact interchange format described in this specification
without any deletions or extensions to the format. This differs from RFC
4627 which permits a JSON parser to accept non-JSON forms and extensions."

15.12.1.1: The ABNF is constructed differently.  Hopefully in a completely
compatible way (looks that way with a couple of minutes analysis), but we
all know how finicky even small changes to ABNF can be.

15.12.1.2: JSONText can be any value, not just object or array.  I think
this would be a positive change for 4627bis, perhaps with a note that
older processors are likely to reject any top level that is not an object
or array.

On 2/20/13 9:20 AM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:

>On Feb 19, 2013, at 10:47 PM, R S <sayrer@gmail.com> wrote:
>
>> My suggestion is for the WG to target this use case only, and to treat
>> the JSON processing rules in ECMAScript 5, Section 15.12 (The JSON
>> Object) as the baseline for rules regarding encoding and decoding,
>> rather than RFC4627.
>
>It feels weird to be agreeing with Rob so early in the discusson, but I
>agree on both parts.
>
>- Charter 4627bis *and nothing else*, so that the 4627bis work is done
>without distraction. It is really clear that canonicalization and
>schema/description have the *high* potential for distraction.
>
>- Say that the base for that one charter item is RFC 4627 *and*
>ECMAScript 5, which seems to be widely-deployed.
>
>- Say that the WG is likely to recharter while 4627bis is under review by
>the IESG to discuss schema/description.
>
>- Given the recent consensus, don't mention canonicalization in the
>charter at all unless another WG or SDO has specifically asked us to work
>on it.
>
>--Paul Hoffman
>_______________________________________________
>json mailing list
>json@ietf.org
>https://www.ietf.org/mailman/listinfo/json
>

-- 
Joe Hildebrand

Re: [Json] Proposed document set from this WG Paul Hoffman
[Json] Proposed document set from this WG Paul Hoffman
Re: [Json] Proposed document set from this WG Francis Galiegue
Re: [Json] Proposed document set from this WG Mike Jones
Re: [Json] Proposed document set from this WG R S
Re: [Json] Proposed document set from this WG Tony Hansen
Re: [Json] Proposed document set from this WG Joe Hildebrand (jhildebr)
Re: [Json] Proposed document set from this WG Tim Bray
Re: [Json] Proposed document set from this WG Paul Hoffman
Re: [Json] Proposed document set from this WG Francis Galiegue
Re: [Json] Proposed document set from this WG Bjoern Hoehrmann
Re: [Json] Proposed document set from this WG Gonzalo Salgueiro
Re: [Json] Proposed document set from this WG Robert Sayre
Re: [Json] Proposed document set from this WG R S