Subject: [Json] Last call: JSON charter

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Fri, 29 Mar 2013 17:39:10 +0000

Please review and send your final comments on the proposed charter for a
potential JSON working group:

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

If you have been participating on the list, please chime in on this thread
even if you have already said you agree with that text.

Note that I'll be stepping aside for real working group chairs as soon as
possible, so the apparea ADs (Barry in particular) are going to be the
first judges of consensus, followed of course by the IESG as they decide
whether to form a WG.

-- 
Joe Hildebrand

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 29 Mar 2013 11:03:41 -0700

> even if you have already said you agree with that text.

The proposed text as it stands today seems fine to me.

(To reiterate what I said to Larry's proposal: I would likely object to adding wording about other SDOs to this charter.)

--Paul Hoffman

---

From: "Markus Lanthaler" <[email-masked]>
Date: Fri, 29 Mar 2013 19:08:47 +0100

On Friday, March 29, 2013 7:04 PM, Paul Hoffman wrote:

> > If you have been participating on the list, please chime in on this
> > thread even if you have already said you agree with that text.
> 

+1

Cheers,
Markus

--
Markus Lanthaler
@markuslanthaler

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 29 Mar 2013 11:11:06 -0700

I have no objections.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Joe
> Hildebrand (jhildebr)
> Sent: Friday, March 29, 2013 10:39 AM
> To: [email-masked]
> Cc: Barry Leiba
> Subject: [Json] Last call: JSON charter
> 
even if
> you have already said you agree with that text.
> 
first
> judges of consensus, followed of course by the IESG as they decide whether
to
> form a WG.
> 
> --
> Joe Hildebrand
> 
> 
> 
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Fri, 29 Mar 2013 14:12:38 -0400

WFM too.

Gonzalo

---

From: Tim Bray <[email-masked]>
Date: Fri, 29 Mar 2013 11:22:22 -0700

Works for me -T

---

From: Ed Summers <[email-masked]>
Date: Fri, 29 Mar 2013 14:46:51 -0400

Looks good to me.

//Ed

On Fri, Mar 29, 2013 at 2:22 PM, Tim Bray <[email-masked]> wrote:
> Works for me -T
>
>
> On Fri, Mar 29, 2013 at 10:39 AM, Joe Hildebrand (jhildebr)
> <[email-masked]> wrote:
>>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Mar 2013 20:49:59 +0100

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

I like the current text.

Particularly:
- its focus on the technical independence from its former parent language JavaScript, and
- the strong mission statement not to break implementations (as opposed to language-lawyering around the current specifications).

Grüße, Carsten

---

From: Larry Masinter <[email-masked]>
Date: Fri, 29 Mar 2013 15:04:46 -0700

So if TC 39 asks nicely for a minor  change to the document that would
otherwise prevent  them from using the new RFC as a normative  reference -- 
even if the change makes no technical change to the specification -- 
such requests should be rejected because they aren't " minimal change" or 
correcting errors?

(see http://masinter.blogspot.com/2013/03/standardizing-json_25.html 

Anne van Kesteren: 
"FWIW, XMLHttpRequest references TC39's version of JSON which is completely self-contained and without known errors. Not really sure why the IETF feels there's a need to publish that version independently."

http://www.w3.org/TR/XMLHttpRequest/

at least some of the commenters wanted to make sure there was
only one JSON standard, not two.

> Paul Hoffman
> Sent: Friday, March 29, 2013 11:04 AM
> To: [email-masked]
> Subject: Re: [Json] Last call: JSON charter
> 
> (To reiterate what I said to Larry's proposal: I would likely object to adding
> wording about other SDOs to this charter.)
> 
> --Paul Hoffman
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 29 Mar 2013 15:40:00 -0700

> such requests should be rejected because they aren't " minimal change" or 

Strawman: wind. Can you give an example of a "minor change" that is not a "minimal change"? It's kind of hard to parse your objection to the proposed charter if you use vague hypotheticals like that. More directly: can you point to specific words in the proposed charter that indicate we would reject input from anyone about correcting errors?

> "FWIW, XMLHttpRequest references TC39's version of JSON which is completely self-contained and without known errors. Not really sure why the IETF feels there's a need to publish that version indepe…

Anne is welcome (and in fact invited!) to read this mailing list for the answer to that.

> only one JSON standard, not two.

There are currently at least three that have differences: json.org, RFC 4627, and ECMAScript.

--Paul Hoffman

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 30 Mar 2013 11:37:15 +1100

Hi Joe,

> even if you have already said you agree with that text.

I haven't been following closely.

Two things in the charter don't make much sense to me:

> During that work, the working group may collect change requests, and
> may choose to propose a more significant revision of the JSON specification
> if there is rough consensus to do so.  Proceeding with such a revision
> will require a recharter to get community and IESG review of the proposal.

A "more significant revision" of JSON than that described before this text will, by its nature, not be backwards compatible, so it won't be JSON.

If people want to start work on a JSON-inspired syntax and call it something else, that's fine. However, using the good name of JSON to try to get leverage for something new and born in the IETF isn't, and given the experience of the recent OAUTH debacle, I'm surprised it's come up again so soon. Haven't we learned that particular lesson?

I think this paragraph should be deleted.

> There are also various proposals for JSON extensions and related standards.
> The working group will consider those proposals only after the initial work
> is done, and must recharter with specific work items for any additional work
> it might select.

At the risk of repeating myself, I do not think that a generic "JSON Working Group" that takes on any work that happens to use this format is good engineering. I know that this text is only advisory, but it's tilting the table in that direction.

I think this paragraph should be deleted. Alternatively, the phrase "JSON extensions and related standards" should be changed to something like "JSON extensions for reuse by other standards" or similar. I.e., "related standards" is a charter license too far.

The charter already says: 

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

I agree with the sentiment, but isn't the review function already fulfilled by the apps directorate? 

Regards,

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

---

From: R S <[email-masked]>
Date: Fri, 29 Mar 2013 21:25:05 -0700

On Fri, Mar 29, 2013 at 3:40 PM, Paul Hoffman <[email-masked]> wrote:

> Strawman: wind. Can you give an example of a "minor change" that is not a
> "minimal change"? It's kind of hard to parse your objection to the proposed
> charter if you use vague hypotheticals like that. More directly: can you
> point to specific words in the proposed charter that indicate we would
> reject input from anyone about correcting errors?

I don't understand the concern here, either. The charter looks fine to me.

> > Anne van Kesteren:
> > "FWIW, XMLHttpRequest references TC39's version of JSON which is
> completely self-contained and without known errors. Not really sure why the
> IETF feels there's a need to publish that version independently."
>

Aside from differences, RFC 4627 covers character sets, and ECMAScript does
not. It may be that an updated RFC should insist on whatever the union of
XMLHttpRequest and ES5 is. Even if that is the case, it is worth writing
down.

- Rob

---

From: Vinny A <[email-masked]>
Date: Sat, 30 Mar 2013 02:52:09 -0500

> even if you have already said you agree with that text.

+1 Text came out great.

-Vinny

---

From: Barry Leiba <[email-masked]>
Date: Sat, 30 Mar 2013 10:16:46 -0400

> A "more significant revision" of JSON than that described before this text will,
> by its nature, not be backwards compatible, so it won't be JSON.
...
> I think this paragraph should be deleted.

I agree.  Actually, I put that paragraph in during the very earliest
stab at a charter, mostly to head off demands for major changes by
setting them as out of scope and saying that we'd have to recharter if
anyone wanted to do that.  As it turns out, we don't have those
demands, or don't seem to, and I think the rest of the charter says
what needs to be said about the sorts of changes that are in scope.

> At the risk of repeating myself, I do not think that a generic "JSON Working Group"
> that takes on any work that happens to use this format is good engineering. I know
> that this text is only advisory, but it's tilting the table in that direction.
>
> I think this paragraph should be deleted. Alternatively, the phrase "JSON extensions
> and related standards" should be changed to something like "JSON extensions for
> reuse by other standards" or similar. I.e., "related standards" is a charter license
> too far.

This text is acknowledging that there are a bunch of proposals, and
saying that none of them are in scope for this.  If any of them are to
be done, they'd be done in either a rechartered working group or a new
working group.

You're saying, I guess, that one or more new working groups that are
focused on specific proposals are better than something generic to
address "a bunch of JSON-related work", and I agree with that.  About
the specific text that's in the charter, I'm ambivalent: I have no
problem with leaving it there, but I agree that the charter already
constrains the work.  We usually put this sort of text in there to
help the chairs, by giving them something clear to point to that says,
"I'm sorry, but your proposal is explicitly out of scope in our
charter.  Maybe we can discuss it later, after we get our chartered
work done."

In any case, given that we're really pushing to make chartering easier
and faster, the need to recharter working groups for follow-on work,
rather than chartering anew for that work, is lessened.

> I agree with the sentiment, but isn't the review function already fulfilled

Not as I see it.  The Apps Directorate mostly provides a review or two
during last call, where we try to select reviewers who have at least
some expertise in the topic that especially needs review.  The
paragraph you cite is stating a need for much broader review than
that, and for review and participation throughout the development, not
just at the end.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Sat, 30 Mar 2013 10:19:52 -0400

I meant to say, in my other note just now, that we did send a
liaison-like note to ECMA, and are currently in conversation with the
chair of ECMA TC 39 about where the standardization of JSON belongs.
We won't be proceeding with the charter process for this until that
conversation has settled on something.

Barry, Applications AD

---

From: Anne van Kesteren <[email-masked]>
Date: Sun, 31 Mar 2013 14:47:35 +0100

> XMLHttpRequest and ES5 is. Even if that is the case, it is worth writing

Maybe the RFC should cover resource encapsulation and TC39 should
remain in charge of parsing the resource. XMLHttpRequest mandates
utf-8 for what it's worth, nothing else will work. MIME type can be
anything.

--
http://annevankesteren.nl/

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 31 Mar 2013 07:40:11 -0700

> utf-8 for what it's worth, nothing else will work. MIME type can be

Please look at the definition of JSON in ECMAScript. The parser has *two* arguments, not just one. That would make every implementation of JSON today that was not in ECMAScript non-compliant with a new definition of JSON from ECMAScript. That is, when I parse JSON today in Python, I only give the parser one argument, just the JSON text. If we go with the ECMAScript definition of parsing, my current programs would be non-compliant until I added the second argument for filtering.

What is the advantage of going down that path?

--Paul Hoffman

---

From: Anne van Kesteren <[email-masked]>
Date: Sun, 31 Mar 2013 15:47:40 +0100

On Sun, Mar 31, 2013 at 3:40 PM, Paul Hoffman <[email-masked]> wrote:
> The parser has *two* arguments, not just one.

The parser *API* has a second optional argument. The JSON grammar is
still simply a grammar.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 31 Mar 2013 08:05:31 -0700

> The parser *API* has a second optional argument. The JSON grammar is

Quite true, but you had said:

On Mar 31, 2013, at 6:47 AM, Anne van Kesteren <[email-masked]> wrote:

> remain in charge of parsing the resource. 

Do you want to just use ECMAScript for the JSON *grammar*, and the IETF gets to specify the *parsing rules*? Or something else?

FWIW, the ECMAScript grammar and the RFC 4627 grammar are identical (as far as anyone has said), other than it's harder to figure out the ECMAScript grammar because you have to jump around the ECMAScript document.

--Paul Hoffman

---

From: Anne van Kesteren <[email-masked]>
Date: Sun, 31 Mar 2013 16:14:32 +0100

> Do you want to just use ECMAScript for the JSON *grammar*, and the IETF gets to specify the *parsing rules*? Or something else?

I'd like if we deferred as much as possible to the ECMAScript variant.
That should probably include parsing, but it does not seem necessary
to make that the entire API that is provided to ECMAScript. Just
parsing JSONText seems sufficient.

> FWIW, the ECMAScript grammar and the RFC 4627 grammar are identical (as far as anyone has said), other than it's harder to figure out the ECMAScript grammar because you have to jump around the ECMA…

That's false.

JSONText is a JSONValue in ECMAScript. In RFC 4627 it's either a
JSONObject or a JSONArray.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 31 Mar 2013 10:38:11 -0700

> parsing JSONText seems sufficient.

That works for me, as does us doing what we did in RFC 4627.

> JSONObject or a JSONArray.

Hrm. I consider "a JSON text is X" to be a parser rule, not a grammar rule, but I can see that it could be either.

--Paul Hoffman

---

From: Anne van Kesteren <[email-masked]>
Date: Sun, 31 Mar 2013 18:42:27 +0100

> Hrm. I consider "a JSON text is X" to be a parser rule, not a grammar rule, but I can see that it could be either.

I'm not really sure how you distinguish the two to be honest. In any
event, a resource such as

Content-Length:5
Content-Type: application/json

false

will not result in a parse error when accessed via XMLHttpRequest's
JSON mechanism (it will give you the boolean value false).