Subject: [Json] Minimal edit proposal, second round

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Jun 2013 08:47:21 -0700

<chair hats on>

The thread the last few days showed some confusion about what Rob's proposal was. This new thread is an attempt to clarify so that we can see if there is enough agreement to go down this path for the WG's first document. This message is *not* to say "we will go that way instead of the previous way", but instead to ask "does the WG want to go this way, given more explicit information".

First, the proposal is an alternative to the proposals so far in the WG, not in addition to them. That is, the list of changes in the proposal would be the *entire* set of changes; even the current document title remains the same. If there is consensus to go this way, we drop all the current consensus calls. We have made that clearer below.

Second, it is quite clear that there is disagreement on what RFC 4627 means with respect to the content of strings. Many people have forcefully asserted what RFC 4627 meant, and yet many of them disagree. Thus, we think it would be valuable to capture the fact that there is disagreement in a factual manner. We have changed the proposed wording for this below.

Third, the WG's charter is clear that we don't get to start work on additional documents until we finish 4627-bis. Having said that, there seems to be near-universal agreement that an implementation guidance document is needed. (I don't want to use the IETF-centric term "best practices" because we don't have consensus on which practice is best.) We can assume that the document will be produced, even if it isn't in the charter and we have not agreed to the content of that document.

Fourth, we have incorporated the editorial changes from the thread.

The proposal below, then, is meant to be a way to determine if the WG wants to go down the "minimal edit" route, or return to what we were doing before, making non-minimal additions to the document by WG consensus.

Thoughts?

--Matt Miller and Paul Hoffman

Begin with http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-02.

Change Section 1.2, "Changes from RFC 4627", to read:

 This section lists all changes between this document and the text in
 RFC 4627.

 - Applied erratum #607 from RFC 4627 to correctly align the artwork for the definition of
   "object".

 - Applied erratum #3607 from RFC 4627 by removing the security consideration that begins "A JSON
   text can be safely passed" and the JavaScript code that went with that consideration.

 - Added Section 1.3, "Differences from the JSON Definition in ECMAScript".

 - Updated the [ECMA] reference, and changed the [UNICODE] references to be
   non-version-specific.

Add Section 1.3, "Differences Between This Document the JSON Definition in ECMAScript"

 The following lists the known major differences between this document and the definition of JSON
 in Section 15.12 of [ECMA].

 - ECMAScript implementations produce and consume primitive JSON values at the root level of JSON
   documents.

 - ECMAScript implementations can generate and consume all code points in JSON strings, while there
   is disagreement about whether this document prohibits some specific code points in JSON strings.

 - When there are duplicate names within an object, ECMAScript JSON parsers overwrite the value
   corresponding to such names with the value that appears last in the serialization.

In Section 6, remove "A JSON text can be safely passed" and the JavaScript code in the following
paragraph.

In Section 9, change the title in the reference to [ECMA] to be to the latest version with JSON:

 [ECMA]    Ecma International, "ECMAScript Language Specification, 5.1 Edition / June 2011",
           <http://www.ecma-international.org/publications/files/ecma-st/ECMA-262.pdf>.

In Section 9, change the reference to [UNICODE] to be be non-version-specific:

 [UNICODE]  The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.

---

From: Stephan Beal <[email-masked]>
Date: Wed, 26 Jun 2013 18:01:45 +0200

On Wed, Jun 26, 2013 at 5:47 PM, Paul Hoffman <[email-masked]> wrote:

> Having said that, there seems to be near-universal agreement that an
> implementation guidance document is needed. (I don't want to use the
> IETF-centric term "best practices" because we don't have consensus on which
> practice is best.)

+1! Most excellently worded :).

-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal

---

From: Vinny A <[email-masked]>
Date: Wed, 26 Jun 2013 11:09:55 -0500

On Jun 26, 2013, at 10:47 AM, Paul Hoffman <[email-masked]> wrote:

> <chair hats on>.

+1 to minimal edit. The proposal looks good as well.

-----------------
Vinny
www.jsontest.com

---

From: "Markus Lanthaler" <[email-masked]>
Date: Wed, 26 Jun 2013 18:25:50 +0200

On Wednesday, June 26, 2013 5:47 PM, Paul Hoffman wrote:
>  - ECMAScript implementations can generate and consume all code points
>    in JSON strings, while there is disagreement about whether this
>    document prohibits some specific code points in JSON strings.

I'm wondering what the point is of updating the document if things like
these are not clarified. Why are we not just reclassifying RFC 4627 from
Informational to Standard and be done then? Apparently the RFC has been good
enough to make JSON one of the most widely adopted data formats.

--
Markus Lanthaler
@markuslanthaler

---

From: John Cowan <[email-masked]>
Date: Wed, 26 Jun 2013 12:29:36 -0400

> enough to make JSON one of the most widely adopted data formats.

+1 to that, and -1 to the proposal: it does not do enough to be worth doing.

-- 
Values of beeta will give rise to dom!          John Cowan
(5th/6th edition 'mv' said this if you tried    http://www.ccil.org/~cowan
to rename '.' or '..' entries; see              [email-masked]
http://cm.bell-labs.com/cm/cs/who/dmr/odd.html)

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Jun 2013 09:36:01 -0700

<hat on>

On Jun 26, 2013, at 9:25 AM, Markus Lanthaler <[email-masked]> wrote:

> Informational to Standard and be done then?

Because the WG's charter (<http://datatracker.ietf.org/wg/json/charter/>) requires us to do more:

All differences between RFC 4627 or the current ECMAScript specification will be documented in the new RFC.

--Paul Hoffman

---

From: John Cowan <[email-masked]>
Date: Wed, 26 Jun 2013 12:41:18 -0400

> will be documented in the new RFC.

Presumably, however, we are not actually mandated to issue a new RFC;
we could adjourn without doing anything.  No?

-- 
Kill Gorgun!  Kill orc-folk!            John Cowan
No other words please Wild Men.         [email-masked]
Drive away bad air and darkness         http://www.ccil.org/~cowan
with bright iron!   --Ghan-buri-Ghan    http://www.ccil.org/~cowan

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Jun 2013 18:42:35 +0200

On Jun 26, 2013, at 17:47, Paul Hoffman <[email-masked]> wrote:

> there is disagreement about whether this document prohibits 

I'm not sure that we should have a standards track document where we can't figure out what it means.
(Explicitly stating that then just adds insult to injury.)

1) The confusion needs to be captured.

a) Then, if we really can't nail the specific items down, we at least need to say which alternative interpretations there are.
b) We probably need to give names to the various JSONs resulting, and 
c) specify them in enough detail that there is no further seed for divergence.

2) Simply always choosing the widest possible interpretation is exactly the way soup is being made.
In this context, condoning the widest possible interpretation is equivalent to choosing it. *)

3) The discussion MUST NOT be based on what weird interpretations can be assigned to existing words, but instead of what the interoperability implications are.

Grüße, Carsten

*) Today, if someone sends me a document with duplicate keys, I'll say "this has duplicate keys, can you send me valid JSON please?".  Once the standards track specification condones duplicate keys, that feature has effectively become part of "JSON", and (outside tightly managed environments) *all* receivers will have to adapt.  That is the soup process of protocol evolution at work.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 26 Jun 2013 18:59:40 +0200

* Paul Hoffman wrote:
>[...]

I think the Working Group should attempt to standardize JSON in one
document that obsoletes RFC 4627. That requires finding a consensus
around issues like whether to allow strings at the top level and if
Unicode signatures are permitted in application/json entities. It'd
be quite unfortunate for the group to decide not to try to do so. I
think the only problem so far was the choice of process that mainly
lead to editorial discussions without providing much insight on the
running code and rough consensus side of the substantive issues.

I think it would be helpful, for instance, to conduct an off-list
straw poll collecting data on where people stand on issues like if
UTF-8 encoded application/json entities may start with `EF BB BF`,
whether `["\uDFFF"]` is ("should be defined as valid") JSON and so
on. Ideally with some data on what implementations and JSON forks
do and corresponding rationale available beforehand. When we have
that, we might find that there is no rough consensus on the issues,
and might decide to do only a minimal bugfix revision, but we are
not there yet.

In http://www.ietf.org/mail-archive/web/json/current/msg00193.html
I said pretty much the same during the chartering discussions.
-- 
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: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Wed, 26 Jun 2013 18:08:50 +0000

On 6/26/13 11:47 AM, "Paul Hoffman" <[email-masked]> wrote:

>First, the proposal is an alternative to the proposals so far in the WG,
>not in addition to them. That is, the list of changes in the proposal
>would be the *entire* set of changes; even the current document title
>remains the same. 

With that clarification, I'm full -1.  Someone else will just have to fix
the problems in 4627ter one day, and they're not going to have any easier
of a time doing it that today.

There's hard work ahead.  We're the right people for the job.  Let's stop
trying to avoid our duty.

-- 
Joe Hildebrand

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Jun 2013 20:11:37 +0200

> trying to avoid our duty.

This.

Grüße, Carsten

---

From: Tim Bray <[email-masked]>
Date: Wed, 26 Jun 2013 11:15:50 -0700

Yeah, but our charter clearly doesn’t let us fix JSON.  What we need is to
do something like this, then re-charter to produce a doc that provides real
guidance, so that, as someone in this thread pointed out, other Working
Groups will have something to point to and won’t, as is currently happening
in Jose, have to write explicit language forbidding dupes, etc, into their
drafts.  So I’m in favor of doing this minimal point-out-the-problems work
and moving on. -T

On Wed, Jun 26, 2013 at 11:08 AM, Joe Hildebrand (jhildebr) <
[email-masked]> wrote:

> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: John Cowan <[email-masked]>
Date: Wed, 26 Jun 2013 14:23:06 -0400

> drafts.  So I’m in favor of doing this minimal point-out-the-problems work

If we do that, we will have an ambiguous document on the standards track.
The problem with implementation guidance is that it isn't normative:
nobody can insist on compliance with it.  If there's really no choice
except to dissolve and recharter, or to pass this farce, +1 for dissolution.

-- 
Using RELAX NG compact syntax to        John Cowan <[email-masked]>
develop schemas is one of the simple    http://www.ccil.org/~cowan
pleasures in life....
        --Jeni Tennison                 <[email-masked]>

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Wed, 26 Jun 2013 18:24:13 +0000

If we have a path forward on JSON+ (or JSON- for that matter), then I
guess I could be ok with this change as a step toward that.  However, I
won't be +1 on the minimal set of known-broken changes until I see the
path for how we're going to get *that* doc completed.

However, I'd almost rather declare defeat on the current charter and skip
to writing the doc that I thought we were signing up for.

On 6/26/13 2:15 PM, "Tim Bray" <[email-masked]> wrote:

>Yeah, but our charter clearly doesn¹t let us fix JSON.  What we need is
>to do something like this, then re-charter to produce a doc that provides
>real guidance, so that, as someone in this thread pointed out, other
>Working Groups will have something
> to point to and won¹t, as is currently happening in Jose, have to write
>explicit language forbidding dupes, etc, into their drafts.  So I¹m in
>favor of doing this minimal point-out-the-problems work and moving on. -T
>
>
>
>On Wed, Jun 26, 2013 at 11:08 AM, Joe Hildebrand (jhildebr)
><[email-masked]> wrote:
>

-- 
Joe Hildebrand

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Wed, 26 Jun 2013 18:25:19 +0000

>except to dissolve and recharter, or to pass this farce, +1 for

John said what I was trying to much more clearly.

-- 
Joe Hildebrand

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Jun 2013 11:45:23 -0700

<no hat>

> If we do that, we will have an ambiguous document on the standards track.

We currently have an ambiguous document *that everyone has used for six years* as the de facto standard. No one noticed this ambiguity (at least in public) until *after* we started this WG.

I claim that leaving the long-unnoticed ambiguity in and slightly calling it out will do no harm to the people who use the standard.

> nobody can insist on compliance with it.  

If the implementation guidance is written carefully (and, given the high interest in this topic in the past month, I bet it will be), someone can insist on compliance to section 3.2.1's interpretation instead of 3.2.2's interpretation.

> If there's really no choice

<hat>

We don't have to dissolve in order to recharter. In fact, we are better off if we don't.

--Paul Hoffman

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 26 Jun 2013 12:57:19 -0600

On 6/26/13 12:45 PM, Paul Hoffman wrote:
> We currently have an ambiguous document *that everyone has used for
> six years* as the de facto standard. No one noticed this ambiguity
> (at least in public) until *after* we started this WG.

And further: the fact that the sky hasn't fallen yet indicates to me
that developers are sensibly following the lead of the tremendous amount
of running code out there, and not getting confused about some edge-case
ambiguities in the formal spec. Rechartering seems like an extreme
reaction here.

Steady on.

Peter

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

---

From: R S <[email-masked]>
Date: Wed, 26 Jun 2013 13:00:46 -0700

This looks good to me. +1.

- Rob

On Wed, Jun 26, 2013 at 8:47 AM, Paul Hoffman <[email-masked]> wrote:

> <chair hats on>
>
> The thread the last few days showed some confusion about what Rob's
> proposal was. This new thread is an attempt to clarify so that we can see
> if there is enough agreement to go down this path for the WG's first
> document. This message is *not* to say "we will go that way instead of the
> previous way", but instead to ask "does the WG want to go this way, given
> more explicit information".
>
> not in addition to them. That is, the list of changes in the proposal would
> be the *entire* set of changes; even the current document title remains the
> same. If there is consensus to go this way, we drop all the current
> consensus calls. We have made that clearer below.
>
> Second, it is quite clear that there is disagreement on what RFC 4627
> means with respect to the content of strings. Many people have forcefully
> asserted what RFC 4627 meant, and yet many of them disagree. Thus, we think
> it would be valuable to capture the fact that there is disagreement in a
> factual manner. We have changed the proposed wording for this below.
>
> Third, the WG's charter is clear that we don't get to start work on
> additional documents until we finish 4627-bis. Having said that, there
> seems to be near-universal agreement that an implementation guidance
> document is needed. (I don't want to use the IETF-centric term "best
> practices" because we don't have consensus on which practice is best.) We
> can assume that the document will be produced, even if it isn't in the
> charter and we have not agreed to the content of that document.
>
> The proposal below, then, is meant to be a way to determine if the WG
> wants to go down the "minimal edit" route, or return to what we were doing
> before, making non-minimal additions to the document by WG consensus.
>
> Thoughts?
>
>            <
> http://www.ecma-international.org/publications/files/ecma-st/ECMA-262.pdf
> >.
>
>  [UNICODE]  The Unicode Consortium, "The Unicode Standard", <
> http://www.unicode.org/versions/latest/>.

---

From: Nico Williams <[email-masked]>
Date: Wed, 26 Jun 2013 15:07:16 -0500

On Jun 26, 2013 2:15 PM, "Tim Bray" <[email-masked]> wrote:
>
> Yeah, but our charter clearly doesn’t let us fix JSON.  What we need is
to do something like this, then re-charter to produce a doc that provides
real guidance, so that, as someone in this thread pointed out, other
Working Groups will have something to point to and won’t, as is currently
happening in Jose, have to write explicit language forbidding dupes, etc,
into their drafts.  So I’m in favor of doing this minimal
point-out-the-problems work and moving on. -T

We could also re-charter now (or conclude w/o producing any docs, as
someone else pointed out).  There's no dishonor in acknowledging that the
current charter is unsatisfactory, if we so conclude.

I'm for a minimal edit that describes the different interpretations of the
old text that we have seen.  We could also note that there is a subset of
JSON that will (MUST) interop (no dup names, smallish integers, only
Unicode character data and unassigned code points), though we can't rewrite
that encoders restrict themselves to that subset.  Then we can look at
implementation guidance (e.g., parser options) and best practices.

Nico
--

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 26 Jun 2013 22:18:34 +0000

> implementation guidance (e.g., parser options) and best practices.

/me doffs hat

I think the minimal edit useful as a way to move forward: it notes the original had warts, that "properly" (for varying definitions of "properly") correcting those warts could cause worse conditions, but that there are a plethora of implementations that coexist with very few reported problems.  I think the edits do bring to the surface information that has been unspoken for a long time.  I could easily live with it, and leave the definitive "this is what JSON software ought to do from this point forward" for a separate document.

- m&m

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

- m&m

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

---

From: John Cowan <[email-masked]>
Date: Wed, 26 Jun 2013 20:30:00 -0400

> (at least in public) until *after* we started this WG.

What do you call "public"?  Mr. Crockford and I were discussing this
for the second time more than two years ago on the JSON Yahoo list:
see <http://tech.groups.yahoo.com/group/json/message/1600> et seqq.

> We don't have to dissolve in order to recharter. In fact, we are better

Ah, good.

-- 
[W]hen I wrote it I was more than a little              John Cowan
febrile with foodpoisoning from an antique carrot       [email-masked]
that I foolishly ate out of an illjudged faith          http://ccil.org/~cowan
in the benignancy of vegetables.  --And Rosta

---

From: Eliot Lear <[email-masked]>
Date: Thu, 27 Jun 2013 08:17:48 +0200

Matt,
On 6/27/13 12:18 AM, Matt Miller (mamille2) wrote:
> I think the minimal edit useful as a way to move forward: it notes the
> original had warts, that "properly" (for varying definitions of
> "properly") correcting those warts could cause worse conditions, but
> that there are a plethora of implementations that coexist with very
> few reported problems. I think the edits do bring to the surface
> information that has been unspoken for a long time. I could easily
> live with it, and leave the definitive "this is what JSON software
> ought to do from this point forward" for a separate document. -

I think you have to go one step further.  You have to explain how to
avoid the warts.  We have normative language for that purpose.

Eliot

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 28 Jun 2013 12:34:32 +1000

-1
Too minimal to provide any value (and certainly not enough value to overcome the pain of introducing a second RFC number for referring to JSON).

P.S. Surely we don't need to explicitly mention that an update fixes editorial errata (#607).

--
James Manger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Hoffman
> Sent: Thursday, 27 June 2013 1:47 AM
...
>  The following lists the known major differences between this document
> and the definition of JSON  in Section 15.12 of [ECMA].
> 
> in JSON strings, while there
> In Section 6, remove "A JSON text can be safely passed" and the
> JavaScript code in the following paragraph.
> 
>  [UNICODE]  The Unicode Consortium, "The Unicode Standard",
> <http://www.unicode.org/versions/latest/>.