Subject: Re: [Json] Comments on proposed charter for JSON

From: Barry Leiba <[email-masked]>
Date: Fri, 1 Mar 2013 08:49:30 -0500

> I suggest against having an initial list.  It's difficult to predict whether
> people will have the energy to review once the charter has been approved.

Specifically, then, you suggest that there be only the one item: make
4627 Standards Track?  And then require recharter to add any other
items, which would be listed as individual work items in any recharter
proposal?

Barry

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 Mar 2013 07:33:31 -0800

> items, which would be listed as individual work items in any recharter

That seems reasonable, given how excited people get about the "any other work items" and how that excitement could delay or derail the main reason you wanted the WG. The recharter effort can start after 4627bis document is in IETF Last Call. It's not like we're in any new rush for particular work.

--Paul Hoffman

---

From: Barry Leiba <[email-masked]>
Date: Fri, 1 Mar 2013 10:58:02 -0500

> That seems reasonable, given how excited people get about the "any other
> work items" and how that excitement could delay or derail the main reason
> you wanted the WG. The recharter effort can start after 4627bis document
> is in IETF Last Call. It's not like we're in any new rush for particular work.

I've edited the charter proposal on the appsawg wiki:
http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 01 Mar 2013 09:02:52 -0700

On 3/1/13 8:58 AM, Barry Leiba wrote:
>>>> I suggest against having an initial list.  It's difficult to
>>>> predict whether people will have the energy to review once
>>>> the charter has been approved.
>>> 
>>> Specifically, then, you suggest that there be only the one
>>> item: make 4627 Standards Track?  And then require recharter to
>>> add any other items, which would be listed as individual work
>>> items in any recharter proposal?
>> 
>> That seems reasonable, given how excited people get about the
>> "any other work items" and how that excitement could delay or
>> derail the main reason you wanted the WG. The recharter effort
>> can start after 4627bis document is in IETF Last Call. It's not
>> like we're in any new rush for particular work.
> 

+1 modulo a few typos here and there. Mind if I fix them on the wiki page?

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Barry Leiba <[email-masked]>
Date: Fri, 1 Mar 2013 11:05:33 -0500

> +1 modulo a few typos here and there. Mind if I fix them on the wiki page?

Of course not: go for it.

Barry

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 1 Mar 2013 16:05:46 +0000

> http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON

It looks good to me.  Get the bare minimum done first, and only then consider additional work.

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: SM <[email-masked]>
Date: Fri, 01 Mar 2013 07:01:12 -0800

Hi Barry,
>items, which would be listed as individual work items in any recharter

Yes to both questions.

Regards,
-sm

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 Mar 2013 09:31:42 -0800

I made two more small changes to the proposed charter; comments are welcome.

- Changed the community review sentence to say "There are also a number of other JSON-related proposals for Standards Track that would benefit from review from both the IETF and the larger JSON-using communities created by a working group focused on JSON" to indicate that we would benefit from JSON-using developers who are currently not active in the IETF.

- Changed the "breaking compatibility" sentence to say "Any changes that break compatibility with existing implementations will need to have very strong justification and broad support, and will have to be documented in the new RFC" to make it clear that the resulting RFC should make any changes clear.

--Paul Hoffman

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 01 Mar 2013 10:33:18 -0700

On 3/1/13 10:31 AM, Paul Hoffman wrote:
> - Changed the community review sentence to say "There are also a
> number of other JSON-related proposals for Standards Track that
> would benefit from review from both the IETF and the larger
> JSON-using communities created by a working group focused on JSON"
> to indicate that we would benefit from JSON-using developers who
> are currently not active in the IETF.
> 
> - Changed the "breaking compatibility" sentence to say "Any changes
> that break compatibility with existing implementations will need to
> have very strong justification and broad support, and will have to
> be documented in the new RFC" to make it clear that the resulting
> RFC should make any changes clear.

Those changes seem fine to me.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 1 Mar 2013 17:36:41 +0000

> - Changed the "breaking compatibility" sentence to say "Any changes that break compatibility with existing implementations will need to have very strong justification and broad support, and will ha…

+1

- m&m

---

From: "Markus Lanthaler" <[email-masked]>
Date: Fri, 1 Mar 2013 19:00:53 +0100

+1

--
Markus Lanthaler
@markuslanthaler

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Fri, 1 Mar 2013 18:06:35 +0000

(individual)
I'm fine with the text as it currently sits.

(chair)
Does the current text give anyone heartburn?  I'll start another thread
mid-next week to make sure.

On 3/1/13 10:31 AM, "Paul Hoffman" <[email-masked]> wrote:

>- Changed the community review sentence to say "There are also a number
>of other JSON-related proposals for Standards Track that would benefit
>from review from both the IETF and the larger JSON-using communities
>created by a working group focused on JSON" to indicate that we would
>benefit from JSON-using developers who are currently not active in the
>IETF.
>
>- Changed the "breaking compatibility" sentence to say "Any changes that
>break compatibility with existing implementations will need to have very
>strong justification and broad support, and will have to be documented in
>the new RFC" to make it clear that the resulting RFC should make any
>changes clear.
>
>--Paul Hoffman
>_______________________________________________
>json mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/json
>

-- 
Joe Hildebrand

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 01 Mar 2013 20:15:11 +0100

>mid-next week to make sure.

The way I look at this, there is a very small subset that works reliably
(only UTF-8, no Unicode signature, all keys are unique, the top level is
either array or object, and probably some other restrictions) but beyond
that JSON is a highly fragmented and in need of standardisation, and the
current proposal does not really convey that state of affairs and does
really say what the Working Group would be expected to do about it.

To illustrate, http://www.w3.org/TR/2012/WD-XMLHttpRequest-20121206/ has
a JSON loading feature that treats all JSON documents as UTF-8 encoded,
even RFC 4627-compliant UTF-16-encoded ones, requires to ignore the
UTF-8 BOM which normally breaks RFC 4627-compliant decoders, it allows
strings and other things at the top-level that cannot be used in RFC
4627-compliant JSON, it requires to recover from UTF-8 errors in a
certain way, ...

If I want to implement a JSON decoder that behaves like XMLHttpRequest,
then RFC 4627 cannot be used as a reference in any notable way, and if
the Working Group makes all the changes needed to do exactly what the 
XMLHttpRequest feature does, then that's not "minimal" and does "break
compatibility" and goes well beyond simply putting JSON on the standards
track, as far as I am concerned. And if it doesn't do this and XHR isn't
changed (and XMLHttpRequest is just an example, all sorts of libraries
and other things have similar inconsistencies) then we'll have W3C-JSON
and IETF-JSON and more, outside the common subset noted above.
-- 
Björn Höhrmann · mailto:[email-masked] · 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: Robert Sayre <[email-masked]>
Date: Fri, 1 Mar 2013 14:47:46 -0600

> mid-next week to make sure.

I agree with Bjoern that the charter isn't specific enough wrt the delta
between ES5 and the RFC. Adopting the changes in ES5 would seem to be the
best way get consistency.

However, it sounds like some folks on this list would rather standardize a
narrow RFC4267-derived update. I do not think that work would be valuable.

- Rob

>
> On 3/1/13 10:31 AM, "Paul Hoffman" <[email-masked] <javascript:;>>
> wrote:
>
> >[email-masked] <javascript:;>
> [email-masked] <javascript:;>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Mar 2013 10:57:05 -0800

On Mar 1, 2013, at 12:47 PM, Robert Sayre <[email-masked]> wrote:

> I agree with Bjoern that the charter isn't specific enough wrt the delta between ES5 and the RFC.

I think the charter is specific enough...

> Adopting the changes in ES5 would seem to be the best way get consistency.

...while agreeing with you that adopting the changes in ECMAscript 5 is the best way to get consistency with the current deployed browsers, which seems like a reasonable target for our efforts.

I *do* want to see browser folks familiar with the ECMAscript spec to start working on a specific list of differences between it and RFC 4627. If y'all can do that before the BoF meeting next week, it will help the charter discussion.

> However, it sounds like some folks on this list would rather standardize a narrow RFC4267-derived update. I do not think that work would be valuable.

I'm not sure what that means. Adopting the changes in ECMAscript *is* a narrow RFC4267-derived update.

--Paul Hoffman

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 04 Mar 2013 20:12:08 +0100

* Paul Hoffman wrote:
>I *do* want to see browser folks familiar with the ECMAscript spec to 
>start working on a specific list of differences between it and RFC 4627. 
>If y'all can do that before the BoF meeting next week, it will help the 
>charter discussion.

That's already been done in the ecmascript specification:

  15.12 The JSON Object

  The JSON object is a single object that contains two functions, parse
  and stringify, that are used to parse and construct JSON texts. The
  JSON Data Interchange Format is described in RFC 4627
  <http://www.ietf.org/rfc/rfc4627.txt>. The JSON interchange format
  used in this specification is exactly that described by RFC 4627 with 
  two exceptions:

    * The top level JSONText production of the ECMAScript JSON grammar
      may consist of any JSONValue rather than being restricted to being
      a JSONObject or a JSONArray as specified by RFC 4627.

    * 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.

See e.g. <http://www.ecma-international.org/ecma-262/5.1/#sec-15.12>.
Again, the ecmascript specification defines JSON to explain the behavior
of the API, it does not define an on-the-wire format; accordingly issues
like those around character encodings are not addressed there.
-- 
Björn Höhrmann · mailto:[email-masked] · 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 <[email-masked]>
Date: Mon, 4 Mar 2013 11:15:44 -0800

> That's already been done in the ecmascript specification:

Incompletely. Have you already forgotten about:

NOTE In the case where there are duplicate name Strings within an object, lexically preceding values for the same key shall be overwritten.

--Paul Hoffman

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 04 Mar 2013 20:57:27 +0100

* Paul Hoffman wrote:
>NOTE In the case where there are duplicate name Strings within an 
>object, lexically preceding values for the same key shall be 
>overwritten.

I do not regard that as a difference beyond that ecmascript defines an
API while RFC 4627 a data format. What would be the change here that
could be adopted? Require implementations to ignore lexically preceding
values, i.e., they must not be reported to higher-level applications and
implementations must not treat duplicates as an error of any kind?
-- 
Björn Höhrmann · mailto:[email-masked] · 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 <[email-masked]>
Date: Mon, 4 Mar 2013 15:24:07 -0800

> implementations must not treat duplicates as an error of any kind?

RFC 4627 is not purely a data format: there are implied parsing rules. For all the parts of 4627 format that are MUST-level, the implied parsing rules are clear for developers; where there are SHOULD-level rules in the format, the parsing rules become indeterminate.

It would make sense for 4627bis to deal with parsing rules in a way that matches ECMAscript (minus the optional reviver). It can do this by making everything MUST-level, or it can have a short set of parsing rules. I *thin* that the only change that is needed would be to add the "NOTE" above because that is the only "SHOULD" in 4627, but I want to hear from people who have spent much more time with ECMAscript to be sure.

--Paul Hoffman